产品经理工作分享一

不同阶段产品经理

第一阶段产品助理（0-1年）

第二阶段初级产品经理（1-3年）

第三阶段高级产品经理（3-5年）

第四阶段产品专家（5-8年）

第五阶段产品总监（8年以上）

第一阶段产品助理（0-1年）

较好的执行力，可根据产品经理的要求，完成产品原型、输出功能需求。

可配合产品经理完成用户研究与项目跟进工作。

具备较好的互联网产品学习能力与主动性，具备产品敏感度。

第二阶段初级产品经理（1-3年）

可熟练完成产品原型、功能需求描述以及流程图、时序图、状态机、用例图等各类图表。

可更好的对开发、设计岗位传达需求，跟进进度。

可根据数据对产品进行迭代优化。

可对功能进行具体业务逻辑、使用场景分析。

了解用户心理，可根据用户需求，优化产品用户体验。

第三阶段高级产品经理(3-5年）

可设计出满足公司商业需求与用户需求的产品或功能。

熟悉 PRD 规范，并能够输出整套 PRD 文档。

对行业、市场有了一定了解，可开始进行业务、策略规划。

具备用户洞察力，可深入用户研究，采集并分析用户需求 。

第四阶段产品专家（5-8年）

对产品业务、运营和产业有很深了解，可规划出满足公司商业需求与用户需求的产品或功能。

可通过数据分析，协助产品总监挖掘盈利模式。

对产品数据规划有较深了解，可规划整套数据平台。

可以根据运营数据找到产品的问题，设计优化方案，数据赋能业务、驱动业务增长 。

第五阶段产品总监监（8年以上）

具备整个行业宏观市场的分析与洞察力。

深入了解公司战略决策与业务方向。

具备全栈产品规划能力，根据公司战略，规划产品方向与布局把控产品全生命周期。

具备产品团队管理能力，擅于对上沟通管理。

可跨部门管理并协调产品资源，包括人力、物力、时间成本等。

-----------------------------------------------------------------------------------------------------------

产品经理能力：业务、开发、设计、运营、用户、需求、产品、数据、商业、项目 。

业务：具备行业洞察力、了解整体宏观市场环境、熟悉业务逻辑，可进行业务策略研究。

开发：懂技术工作原理，可更好与开发、测试对接，准确一致的传达需求。

设计：懂交互、 UI 设计工作原理，可为设计提供产品思路、参考，描述设计想法 。

运营：懂运营工作原理，可分析运营数据，与运营对接优化产品。

用户：具备用户洞察力，可深入用户研究，了解用户需求，可优化产品用户体验。

需求：可设计产品原型，输出功能需求，交互设计说明，分析功能业务、使用场景 。

产品：产品管理力，对整个产品生命周期负责，从产品设计到上线，迭代，运营推广全生命周期跟进，并持续对团队进行产品价值传递。

数据：具备数据分析能力，通过数据找到产品问题，可搭建产品数据平台。

商业：具备商业洞察力，可挖掘产品的商业价值，设计产品盈利模式。

项目：项目沟通协作，把控项目进度与质量，协调各部门资源与关系，组织评审会，推进团队完成项目，并对产品与过程风险具备识别和管控能力 。

-----------------------------------------------------------------------------------------------------------

产品经理晋升述职：展示能力已到达某一个阶段职级要求，展示项目成果与规划。

工作／绩效表现

对阶段工作的重要成果，如完成重大项目，获得的产品数据。

突出的绩效评估结果。

完成的产品功能，结合产品原型讲解，描述产品的使用场景、满足的业务需求以及功能逻辑。

上线数据分析，如何与运营对接，分析数据迭代优化。

项目管理，如何推进项目，项目管理各图表展示，推进中的问题如何解决。

产品复盘，产品设计过程中碰到的问题，如何解决，下一步的计划规划，展现产品经理的应变、协调以及产品整体大局观与规划能力。

个人规划

个人职业发展目标，职业规划，如希望在产品经理岗位上进一步成长，达到专家级。

为个人职业规划的学习计划，先提升什么，再提升什么。

-----------------------------------------------------------------------------------------------------------

总结

产品经理能力方向：业务、开发、设计、运营、用户、需求、产品、数据、商业、项目

不同阶段产品经理：产品助理、初级产品经理、高级产品经理、产品专家、产品总监

产品经理晋升述职：自我介绍、工作／绩效表现、项目成果展示、自我评价、个人规划

-----------------------------------------------------------------------------------------------------------

需求来源

来自 BOSS 的需求并不一定是真需求

 BOSS 很多需求并一定经过严密思考，包括业务场景、开发难度、开发周期等，甚至可能是伪需求，盲目开发可能产品经理会左右为难。

产品经理收到 BOSS 需求，应先加入需求池，再进行需求分析，包括业务模式、使用场景、需求价值（解决问题），再通过需求评审会确定开发难度、

开发周期，最后汇报 BOSS 结果。

不从业务、场景开始，直接画原型，写功能

功能和原型的背后是业务逻辑与使用场景，只有先分析清楚业务需求、使用场景，才能准确判断原型或功能的价值、解决的问题，从而影响功能逻

辑、原型设计。如购物车是让用户把有兴趣的商品暂时放入保存或集中结算；购物车还需要提升商品成交率，所以在购物车商品展示促销活动，

降价通知，可领优惠券。

对用户来说，需求是无限的，碰到付款的需求大部分都是不想要，产品经理应优先考虑业务需求，满足商业模式，再考虑如何让用户认可产品价值，

引导、优化用户体验。如电商 VIP 会员开通，一要增加 VIP 会员展示入口，二要展示 VIP 权益价值，从而提升用户对 VIP 权益的认可，提升开通率 。

总想把产品做得很完美

总觉得产品可以满足用户很多需求很多使用场景，最后期望堆积成行业的 BAT ，导致产品定位不清晰，功能过多场景过多设计混乱，难以运营。

产品首先确定定位与边界，做什么的（主线分线），用户群，解决问题以及最后的边界，以及公司的现有可投入的资源。功能较多，

可划分版本计划通过敏捷式开发逐步实现。如滴滴的主线是打车，首先满足打车叫车需求，再通过版本迭代，

发展到与车相关的分线拼车、代驾、卖车等 。

-----------------------------------------------------------------------------------------------------------

因 PRD 需求歧义或不详细背锅

 PRD 要达到真正详细的程度，需要耗费产品经理大量的精力，但事实项目过程不可能预留足够时间给产品经理，同时过于详细的 PRD 也会让开发看得头疼。

对 PRD 也可以采取敏捷式，确定整体框架后，先开发模块输出，开发过程中再按优先级推出其它模块需求。

对于常用需求，如表格组件等，可以汇总复用。

部分已形成团队共同习惯的需求可以简化 。

需求更改频繁

需求更改来源有时是 BOSS ，有时是需求部门或来自产品自己，但背锅的还是产品经理。首先过于频繁的修改需求，会让开发团队疲惫并开始怀疑产品经理的能力。

产品经理对于初级需求应加入需求池，再定期组织评审会决定需求更改。而对于临时的更改，可临时组织评审会，通过后，及时更新修订记录，保证文档的规范。

忌讳把所有需求更改的矛盾转移到 BOSS 或需求部门，既让开发团队认为自己无法把控需求，也让开发团队负面情绪影响开发周期。

工作的工具高于详细的文档：文档不管是撰写还是维护，都需要花费大量时间精力，项目管理工具相对文档更灵活轻量且高效。但不等于要舍弃

文档，而是在快速迭代时让文档尽量精简，复盘回顾时进行详细补充 。

-----------------------------------------------------------------------------------------------------------

敏捷式开发：将项目拆分为多个可独立开发的子项目，并分别按项目计划开发实现，在此过程中，产品一直处于可使用状态 。

特点迭代：不断根据市场反馈进行改进优化。

增量式开发：不断增加子模块，集成为一个维度丰富的产品。

Scrum 敏捷式开发

Scrum 敏捷式开发，专注于管理工作流程，是一种増量迭代式的开发过程。

以跨职能团队的形式，像橄榄球队般。围绕统一的目标，紧密协作。

敏捷式价值观

个体和互动高于流程和工作：要想为产品持续做出正确的决策是很困难的，我们需要跨部门面对面的沟通交流，同时，让团队熟悉掌握项目本身、进展情况，帮助成员清晰了解全局，而不是一层一层地隔断信息，却要求成员们具有全局观。

响应变化高于遵循计划：敏捷式开发就是为了快速响应市场变化，以真实的反馈去衡量、决策，而不是遵循计划。所以我们的产品设计要考虑后期的拓展性，尽量避免变化导致返工。

瀑布式开发：线性流程，它把整个开发过程分成了需求、设计、编码、测试、发布等阶段，只有上个阶段达成后才能进入下个阶段。

瀑布式开发的问题

上一个流程延期，导致下一流程无法开展，导致项目周期延长。

项目需求的变化可能导致涉及多个模块多岗位调整，项目更改成本过高，无法快速适应市场变化。

各岗位之间缺乏业务交流，导致细节疏漏，理解偏差。

瀑布式与敏捷式

瀑布式开发适合需求明确、稳定、简单、易于理解的小型产品。

敏捷式开发适合需求起步不明确、新型、复杂的大型产品。

总结

敏捷式开发：将项目拆分为多个可独立开发的子项目，并分别按项目计划开发实现，在此过程汇总，产品一直处于可使用状态。

瀑布式开发：线性流程，它把整个开发过程分成了需求、设计、编码、测试、发布等阶段，只有上个阶段达成后才能进入下个阶段。