京东产品经理工作流程 大揭秘

▲ 点击上方“李宽wideplum”关注公众号

点击发消息，回复“微信”，加我的个人微信

hello大家好，我是薛老板。最近遇到很多想做产品经理的在校大学生以及社招想要转行产品经理的人。

 

他们在下定决心之前会非常纠结，因为不知道产品经理的工作流程是什么样子的，也就没办法判断自己到底喜不喜欢这个岗位，所以迟迟不敢采取行动。

 

这个视频就跟大家简单介绍一下京东产品经理日常的工作流程是什么样子的。

 

其实，不同行业、不同公司、不同业务线、不同类型的产品经理的工作流程都会存在一定的差异，不能一概而论。接下来我说的工作流程，对绝大多数产品经理都适用的，普适性比较高，这样对于想做产品经理的你来说可能帮助会更大：

 

产品经理工作流程

第一步：需求收集（也就是需求来源）

产品经理一切工作的本源是：需求。所以我们从需求来源开始讲产品经理完整的工作流程。互联网需求来源一般有以下几类：

1、产品相关需求：产品经理通过数据分析、用户调研、竞品分析等方法验证通过的需求，这叫产品需求。

2、运营等业务部门提交的需求：比如以京东为例，服饰业务部/生鲜业务部/家电事业部的运营、采销等人员出于提升业务指标的角度会提出各种需求，这个一般叫做业务需求。

3、老板的需求：领导从外部合作的角度或者产品战略的角度也会给手下的产品经理提一些需求，比如我还接到过大Boss和老板娘的需求。当然在小公司，这种情况会非常常见，因为老板就是公司最大的产品经理。

4、Bug修复等技术方面的需求：在工作中修复BUG是一件比较常见的事情，影响面大的BUG会走紧急修复流程，也就是会为了修复一个BUG单独上线一个版本，所以大家在七麦或者酷传看产品的版本迭代记录的时候，经常会看到两个版本间隔一两天，迭代的内容几乎一致的情况，这种情况一般都是重大BUG的紧急修复。当然还有一些技术自己的需求，比如系统改造、后台优化等需求。

二、需求池的管理

通过以上几种方法收集到的需求会统一放到需求池中，此时就进入到第二阶段：需求池的管理阶段。需求池大家可以理解为所有需求的集合（包含待确认、设计中、待排期、开发中、已上线等所有状态的需求都会在里面），就类似于一个蓄水池。后面每个版本要做什么需求，都是从需求池里面捞取。

一般来说，使用execl表格管理需求池即可，按照各种需求状态进行分类展示，就会非常清晰。当然在有些公司所有产品经理共同使用一个需求池，这时候就需要用到协作软件的帮助了。

三、需求优先级

刚才我们讲到，所有的需求都会放到需求池里，所以需求会非常多，但是每个迭代的时间是有限的，也就是研发资源是有限的，比如现在大部分互联网公司都讲究敏捷迭代，也就是2周左右的时间上线一个新版本，在这么短的时间内，可以做的需求会比较少。

所以导致我们只能从需求池中挑选出少量需求放到一个版本中开发，从而诞生了需求优先级的概念，也就是先做什么后做什么。这个阶段就是第三阶段：优先级的排定。

一个迭代中肯定优先做优先级高的需求！这是无可置疑的。

那如何排定需求优先级呢？

一般来说有两个场景：

1、从0到1设计一款产品

这就是我们涅槃计划做得事情，带着大家从0到1做一款产品出来。这时候需求来源基本上都是产品需求。建议大家去了解一下KANO模型，这个场景下的需求优先级一般来说是：基本型需求>期望型需求>兴奋型需求。

 

2、在原有产品基础上优化

这种场景的需求来源会非常广泛，可能之前讲到的4种来源都会涉及，那如何排定需求优先级呢？一般按照产品价值和实现成本两个维度。

产品价值又可以分为两类：业务价值和用户价值。

• 业务价值：也可以称为商业价值，体现在能给业务带来多少收益。
• 用户价值：对于使用者来说，能给他带来的价值，比如说能减少操作步骤。

在这种方法下，优先级的排序逻辑是：产品价值大实现成本低>产品价值大实现成本高>产品价值小实现成本低>产品价值小实现成本高。

 

以上就是两种非常常用的优先级排定的方法。

四、需求确认

当梳理完需求优先级之后，我们就挑选优先级高的前几个功能组成新版本/新迭代周期的需求列表中。需求列表也可以直接通过execl表格梳理。

梳理完需求列表之后一般要跟直属领导当面沟通一版，进入到第四个阶段：叫做需求确认。

 

在这个阶段要做好挨批、被怼的准备。领导会从各个维度“挑战”你需求的合理性。所以大家在找领导前一定要多思考几遍，尽量多用客观数据以及缜密的思维去说服领导。

 

如果你成功的说服了领导，所有需求确认通过，会进入到第五个阶段：产品设计阶段。

五、产品设计

产品设计阶段会包含如下几个小阶段：

1、使用产品脑图梳理产品/功能结构框架，特别是对一些逻辑复杂的新产品/新功能，一定要画脑图。

2、使用产品流程图梳理产品/功能核心业务逻辑。流程图的梳理尽量详细，各种异常场景的判断一定要在流程图中有所体现。对于涉及多个参与方的业务，可能还要梳理泳道图。

3、使用墨刀/axure等原型工具输出产品原型。原型是产品逻辑的可视化表现，也是产品经理最最基本的基本功。当然像策略产品经理等特殊岗位是不需要画原型的。

4、撰写产品说明文档（PRD）。PRD是产品详细逻辑的最终呈现，也是内部沟通的标准文档，一定要把所有产品逻辑撰写清楚。

 

PRD撰写完成之后就可以进入到第六个阶段：需求评审阶段

六、需求评审

需求评审是指产品经理要向UI、交互、研发、测试等内部人员讲解产品逻辑，保证产品逻辑在内部传输过程中不失真。

需求评审的过程中，有4点需要注意：

1、评审的时候，先讲需求背景。即这一版本为什么要做这需求？做完以后预计会达到什么效果？让相关参与方从心理上认同做这件事的价值。

大家想一个场景，领导想让你做什么事情的时候，是不是先给你画个大饼？就是说做完这件事之后有什么什么好处，其实类似的作用。但是我们产品经理这个不是画大饼，预期效果都是经过严格数据推导出来的。

2、在讲具体需求的时候，按照对应的责任人进行拆解。比如在讲解功能A的实现逻辑时，我一般会说客户端需要完成的内容是1、2、3；服务端需要完成的工作是4、5、6；算法侧的工作是7、8、9等等。

3、存在争议的地方先记录下来，评审结束后再细化。不然的话，会导致整个评审时间非常长，耽误其他人的时间。

4、就是评审结束以后要追排期。即作为产品经理你要盯着研发Leader，设计Leader，测试Leader让他们出需求排期，以此保证项目按时上线。

七、项目管理

需求评审完成之后，项目经理会输出详细的项目排期表，当然大部分公司项目经理是由产品经理兼任的。此时正式进入第七个阶段：项目管理阶段。项目所有相关人员会按照项目排期表有条不紊的协作。项目管理的详细流程也跟大家简单说一下：

八、数据分析

产品上线之后，进入到第八个阶段：数据分析阶段。上线之后产品经理一定要做数据分析工作，以验证产品/功能是否达到预期目标。咱们刚才讲到在需求评审的时候不是要向项目组的人说，项目上线后的预期目标吗？这时就到了验证你当时是不是吹牛的时候了。

如果数据达到预期目标，产品经理需要向全体组员发送产品上线数据报告，这个报告大家一定要发，因为任何一个版本的上线，都凝聚了项目组所有人员的心血，上线之后的数据表现理应通知他们。

 

如果数据不达预期，就要进行深入的分析内在原因是什么，然后数据分析的结论很可能是下一迭代的需求来源，从而开始一个新的迭代周期。

 

以上，就是绝大多数产品经理完整的工作流程，希望对大家有所帮助。我是薛老板，后续会持续输出关于产品经理的相关视频，期待大家的点赞、再看、转发。

 

李宽视频号

我上线了视频号，每期和你一起学习、探讨B端产品经理的方方面面。

今天，与 24590 位读者一起见证彼此成长

后台回复“微信”，可加我个人微信

推荐阅读

思考产品架构的4个视角：业务、场景、数据/功能、实现

B端运营：比产品更懂业务，业务更懂产品