PO：产品经理( Product Owner )
定义：从职业角度来说，产品经理是为终端用户服务，负责整个产品交付过程全生命周期的人，产品经理的职责是确保团队能交出靠谱的产品，把抽象需求，化为具体方案，从需求语言到系统语言的转化，构思设计到用户实际使用，产品经理要负责整个流程，包括需求分析、范围评估、功能规划、制品迭代、测试验证、培训交付等 。
⚖️ 履职规范
一、售前支持
1. 提供解决方案和功能评估
场景：👀
销售有需求线索，告知在潜在客户对产品表现出兴趣，但还没有深入了解的时候，产品经理协助销售参与到与客户的沟通中，通过面对面交流、问卷调查、电话访谈等方式，收集客户对于产品功能、性能、价格、服务等方面的期望和要求，当然最后，我们每个产品都应该具备方案宣讲的能力。
🦴 输入
这个阶段, 可能只是项目线索, 会有销售提供的 客户文档, 功能清单, 规划方案, 技术协议 ,竞品调研等...
🎗️ 输出
01-项目方案-建议书|02-方案宣讲ppt|03-功能范围评估表|04-客户信息资料记录归档
2. 行业类品研究和竞品调研（产品化前身）
场景：👀
关注本行业及潜行业的市场动态，学习行业产品、定期同行同事研讨交流等。例如，在接到一个非钢项目线索或者客户需求时。不但要关注同行业竞争对手的产品动态，对于跨行业与我类同项目产品化的产品，也要分析其优势和不足，提升自身产品力。
🦴 输入
这里其实回归到了产品本身，无论是从解决用户聚焦的痛点场景而提供解决方案也好，还是从项目产品化转型也好，它都是一个相辅融合的过程，通过整合 同行业务产品分析、自身项目案例沉淀、跨行业标品调研 等。
🎗️ 输出
05-产品方案白皮书 ppt|06-产品方案白皮书 word
3. 售前培训
场景：👀
产品经理为销售团队提供关于产品功能、特点、使用方法、适用场景等全方位的知识培训。培训形式可以是方案宣讲、文档视频、操作手册等多种方式。
🦴 输入
一方面来自销售部门的培训诉求，另一方面来自客户对接的培训需要。
🎗️ 输出
07-培训计划（售前）|08-培训资料
二、产品规划与设计
1. 解决方案定制（常态）
场景：👀
对于一些有特殊需求的客户，产品经理需要根据客户的业务流程、组织架构、资源等情况，结合产品的功能特点，为客户定制一套完整的解决方案。这通常涉及到多个产品模块的组合、配置，甚至可能需要与其他第三方系统集成。
2. 用户需求调研
场景：👀
通过多种方式收集用户需求，如用户访谈、问卷调查、焦点小组等。例如，对于一个新的项目需求，产品经理与不同干系人进行面对面沟通，了解他们需求的痛点和期望，比如业务流程健壮性，操作的便捷性、客户场景体验性等。
🦴 输入
这个节点，可能是一些项目线索，也可能是一些客户的需求文档，也可能是一些客户的反馈，更甚可能是预立项的项目，需要提前介入实施确定项目范围和实施计划的阶段，并且调研中，要逐步输出和完善每一阶段的需求调研报告。
🎗️ 输出
09-需求调研计划|10-需求调研报告
3. 产品功能规划
场景：👀
基于用户需求和产品策略，规划产品的功能模块和特性。以物流产品为例，产品经理确定包括车辆管理、司机管理、运输计划、电子围栏等功能模块。根据客户反馈和业务需求的响应，对功能进行优先级排序，优先开发核心功能和对用户价值高的功能。
🦴 输入
根据调研摸排的情况，整理的资料，客户项目信息的收集，需求点的佐证和确认，原系统建设的参考，客户业务的闭环等。
🎗️ 输出
11-需求规格说明书|12-详细设计说明书
4. 产品功能设计
场景：👀
为了更好的为客户负责，也为了更好的服务于研发团队，优质是产品功能设计是必不可少的环节，也是考究一个产品经理把控细节的能力体现。例如：同样对于一个物流系统，产品经理对它的整体产品架构、功能模块、业务流程、原型交互、数据字段设计等。
🦴 输入
根据整体跟客户梳理确认需求规格说明书，亦或详细设计文档，从点到面，也从面到点，形成闭环。
🎗️ 输出
13-功能模块清单|14-产品原型图|15-产品流程图|16-产品架构图
三、产品协同与推进
1. 制定产品计划
场景：👀
在产品开发前，与开发团队、测试团队等相关人员共同确定项目的产品计划。明确项目的各个阶段、里程碑和交付时间。例如，对于一个软件升级项目，在项目开发阶段，每个阶段设定具体的时间节点和交付物。确定项目所需的资源，包括人力、物力、财力等，并进行合理分配，避免过渡设计。如根据开发任务的难度和工作量，按时衔接对应的产品迭代。
🦴 输入
根据项目计划，规划产品计划，也可以通过客户整体计划，倒排产品计划，侧推项目计划。
🎗️ 输出
17-产品计划
2. 创建产品需求
场景：👀
在软件开发过程中，每个角色的实施动作，都有一个源头，对于我们产品驱动的项目而言，需求就是源头，需要产品经理，根据产品计划，分解创建对应的产品需求，以便于各角色基于产品需求，开展项目上下游的协同工作。
🦴 输入
基于用户需求，规划创建产品需求（研发需求）。
🎗️ 输出
18-产品需求(禅道)
3. 需求评审
场景：👀
由产品经理作为主持人，开展需求评审工作，向研发人员详细阐述产品的需求和功能设计，确保他们理解产品的目标和业务逻辑。例如，对于一个新的软件功能模块，产品经理与研发团队进行需求评审会议，讲解功能的具体要求、业务流程和技术实现要点。在开发过程中，及时解答研发人员的疑问，协调解决技术难题。同时，根据研发进度和实际情况，合理调整产品需求和计划，确保项目的顺利进行。
🦴 输入
基于项目计划，迭代计划，产品计划，变更需求，研发诉求等输出禅道评审流程的记录。
🎗️ 输出
19-评审记录（禅道)
3. 需求变更
场景：👀
在开发过程中，作为桥梁解决角色之间需求阻塞的问题。例如，当需求出现变更问题时，产品经理提供必要的需求讲解和禅道变更记录，推动问题的解决和开发工作有效推进。
🦴 输入
基于变更需求的场景，输出禅道变更评审流程的记录，包括蓝湖原型的变更记录和变更内容标记。
🎗️ 输出
20-变更记录（禅道 & 蓝湖)
4. 需求关闭
场景：👀
完成测试的迭代模块，产品经理需要验证确认，完成功能闭环的，要及时关闭需求，同项目经理达成一致。
🦴 输入
产品需求完成，测试通过以后，产品经理经过验证，符合需求关闭条件，应及时关闭相关需求。
🎗️ 输出
21-关闭需求 CLOSED（禅道)
四、产品上线与跟踪
1. 产品上线准备
场景：👀
在产品开发完成后，协助项目经理，组织相关人员进行上线前的准备工作。与开发团队、运维团队合作，确保产品的稳定性和可靠性。进行最后的测试和验证，包括功能测试、性能测试、安全测试等。同时，进行产品的上线文档编写和发布，以便客户能够快速了解和使用产品。
🦴 输入
产品需求完成，测试通过以后，产品经理经过验证，符合需求关闭条件，应及时关闭相关需求。
🎗️ 输出
22-操作使用说明书|23-客户培训计划及签到表
2. 上线跟踪和反馈收集分析
场景：👀
产品上线后，持续关注和跟踪客户的反馈和评价。通过客户反馈，收集客户的意见和建议，完善及维护需求池。对客户反馈进行分类和分析，找出共性问题和关键需求，及时反馈给开发团队进行优化和改进。
🦴 输入
上线跟踪阶段，输入的需求信息更多来源于业务方的反馈，测试的跟踪验证。
🎗️ 输出
24-需求池
五、数据的分析
1. 数据指标定义与监测
场景：👀
如果是使用我们的平台作为基座，根据产品的目标和业务需求，确定关键的数据指标，如用户活跃度、功能使用率等。例如，对于一款业务系统，实时或定期收集和分析这些数据。这一块的功能平台已做了插件实现，产品关注即可。
🦴 输入
通过统一平台集成的系统，根据产品的设计或者业务的观测点，可以深层柯厘度的进行埋点统计，我们的产品需要有这样的一个意识形态就好，对于这个输出，不做强求，但希望有这样的意识。
🎗️ 输出
25-数据分析表和结论（非平台集成不强求）
六、关于定位的问题
知乎上有个比较精简的分类，我觉得还是比较贴切，可以适当照照镜子。
图：产品定位分类浅析1、产品视角
产品视角来看，产品经理首先要懂用户，理解用户，会做用户调研和访谈，会构建用户画像。
其次，他是一个需求分析师，要能挖掘用户潜在需求或真实需求，能对需求的价值进行判断。
最后，他是一个产品设计师，要会画原型图、会写文档，对需求进行评审和交付。
2、职业视角
职业视角来看，产品经理首先是一个需求管理者，内部外的所有需求都会汇集到产品经理这里，需要产品经理对需求进行真伪判断、价值评估、优先级排序、评审、研发、上线等管理工作。
其次，他是一个产品管理者，负责多个产品线的规划。
最后他可能是一个项目管理者，负责全过程对需求分析、方案评审、研发追踪、上线验收等。
3、自我视角
自我视角来看，产品经理是一个产品工作者，负责分析用户需求，或把有价值的需求设计成产品；或者是一个产品缔造者，与完成本职工作相比，还融入了一些自己价值的需求。像 乔布斯 这样伟大都产品经理，用他的产品改变了世界。
不论选择从哪个视角看待产品经理，都需要将自己的角色定位搞清楚，而不仅仅只会画原型、写文档的工具型 产品经理。
TIP
😊 未完待续，专业的人干专业的事，更深度的解读和定义，我希望我们的产品伙伴，共勉之。
✨ 产品 Leader
产品负责人不再是长期陷入某一个点的时间周期内，而是需要整合产品资源，基于整体层面的动态调配和支撑产品组的输入输出，围绕公司及部门整体需求下的，售前支撑，项目建设，项目产品化沉淀，以及产品组培训管理等内建工作。
要求及期许：
由组长拟定小组管理体系和考核标准，明确小组的职责和目标，上报部门确认，最终完成小组管理标准化体系化落地，评审定版，版本管理，上传语雀，上报公司归档批复，部门对小组预期要求，应包括但不限于如下内容；
1. 管理思想
场景：👀
管理是一种行为和动作，执行的目的和过程，应该都有相应的理论作为指导和参考依据。认知，执行，验证缺一不可，我们的管理人员，需要做好角色转变，首先要提升和改变自己的认知，然后要去理顺章程，理顺了，再去说，人、事、物如何去有效调配管理，管理不能仅浮于表面，也不是某一个点的问题，而是基于面的，网状的，立体而发散的，要尽量的让自己知其然，知其所以然，用好的，优秀东西，同化和影响，引导，做这些之前，你可能需要深入了解被管理的人员，他们的能力，擅长的领域，工作的安排，专业的输入输出，优点以及缺点，甚至是他们的诉求和成长以及发展和价值。
🦴 输入
公司及部门对于专业组管理要求，年底公司各组织人员的人才盘点动作，但希望各负责人把这一块做的超出预期，莫要流于形式的交作业，而是真的在其位谋其政，有一些自己的思考，沉淀，总结和章程在里面。
🎗️ 输出
01-人才盘点章程|02-人才模型（方法）|03-人才分类（依据）|04-小组管理办法|05-考核标准
尔后由 TEC 小组参与评审后定稿公司级终审。
2. 管理动作
场景：👀
小组管理应该做哪些事情呢？应该有哪些事件源和动作协同呢？如何穿针引线的去引导和合力呢？对管理动作的执行，有哪些动机和预判呢？对于认知和能力，如何扁平化达成共识呢？我们的管理者，不妨好好思考一下，它应包含但不限于以下内容。
🦴 输入
可能是售前的需要，可能是标准化体系的内建，可能是能力成长的需要，也可能是工作的把控、成员的援助诉求、业务支撑点的洞察、离散性的产品问题等等，不一而足；
🎗️ 输出
06-小组分享培训计划|07-小组双周会及成员问题跟进表
分享培训频次（至少月度 2 次），主题方向（方法论，工作流，业务方案等等），分享资料归档并上传语雀，成员分享培训评价管理，汇总归档；
小组双周会，成员两周工作情况互通，遇到的问题，需要协助解决的事项，输出待解决事项清单（提出人，内容类别，内容详情，解决时间，解决人），上传归档及跟进解决，双周会不要求会议纪要，但是要有 成员问题跟进表。
3. 管理人员
场景：👀
部门计划将人员调配的权限，逐步下放到专业组负责人手里，后面组织结构的响应公司战略部署部门做动态调整，拉通专业组和项目组的高效协同，使小组管理者对成员工作有直观的洞察（能力/态度），建立 T 型管理梯队。
🦴 输入
人员的调动依据一定是项目计划和调动事件源，根据项目计划调动的人员安排，需上报部门记录和确认，同时，要去识别人员空闲率。避免忙的忙死，闲的闲死，后续根据职级跟指标相挂钩。
🎗️ 输出
08-项目人员配置表|09-资源日历表
4. 培养和晋升
场景：👀
每个人的认知，能力，经历，沟通力，理解力，学习力都不一样，我们的管理者，如何把这些基于点的优点，树立榜样，作为标品和基线，提升和补缺典型的缺点，并且在这个过程中，为组织产出和留存，可识别的，直观的，有价值的沉淀，思考，和创新。比如一个产品，方案编写和演讲的能力，就是一个典型，如何去培养典型的能力。
小组成员能力培养，要定指标，定要求，有培养计划和课题，结果可验证，如业务域，演讲能力，方案能力，需求管理能力等等，用输出沉淀和结果说话（也会作为晋升依据）；专业管理人员，需跟成员明确梯队匹配分级，未来我们配合人力资源把人员职级细化，明确晋升路径。
Core
TIP
对于一个合格且优秀的组长，一定要是制度流程的坚定拥护者和执行者，上传下达，上行下效，尽力尽心尽责的做好职能管理，树立好的标杆典型，杜绝劣币淘汰良币的情况发生，所以在这个过程中，就要做好检查，有效监督，积极纠偏，努力去做提升。把事、人、情分开来看。我们的组长，不但要对项目的输入输出有哪些洞若观火，还应该对输入输出到什么程度了如指掌，再好的制度、流程、规范，没有检查监督，纠偏和优化，最后就会不了了之流于形式。管理角色需要提升自己的认知，打败自己心理的矫情和软弱，规避本位主义的趋利避害，才是迈向管理角色坚实的一步，应该用更健康的心态去看待和开展管理工作，最终的目的，都是为了精益赋能，降低沟通和试错成本，而不是为管理而管理。