一文详解产品经理工作流程

这是John几年前收藏的一张图。
几乎所有的公司都会有这样的问题，这种现象已经渐渐成为了互联网公司的一种常规病，那么这样的产品流程问题如何解决呢？
之前John写过
《你凭什么能做产品经理？
》
，今天John也想结合产品经理工作流一起来聊下。

John给大家准备了产品经理工作流的一张图片：

一、了解业务——了解业务是做产品的基石

做产品最基本的是需要去了解业务，无论是公司层面上的业务需求还是产品层面上的业务需求都可以用一句话来概括：
我需要一个什么样的工具，来满足我要做什么的诉求？
所以在John看来可以总结一个公式来拆分下：

了解业务=产品定位+产品规划+竞品分析+历史版本梳理

1.产品定位：定位是产品的骨架

产品定位最主要的还是解决以下4个问题：

满足谁的需要？
—-辐射的用户群体；
他们有些什么需要?—-用户需求；
我们提供的是否满足需要?—-能否解决用户痛点；
这些需要如何有效实现?—-具体实现方案。

这里John根据自己的想法举个例子：

所以对外产品定位总结起来就是一句话：【用户群体】【使用需求】【产品属性】。

（PS：John以前面试别人问你的产品定位是什么？有的小伙伴说了10分钟都没有说清楚，最后John帮他总结了）

2.产品规划：规划是产品的血肉

产品规划并不是做一些精美的PPT用来吹牛用的。
而是真真实实的落实到业务的根上。
做好产品规划有几个好处：

第一：
清晰的产品线规划，可以让一个企业保持无比清晰的头脑。
除了在攻打市场的时候，有的放矢，还可以让在竞争的时候，保持自己的节奏，攻防自如。
很多企业，尤其是行业老大，因为不清楚的自己的产品组合，没有清晰的产品策略，总是被行业老二，或者是市场新的竞争对手带偏。

第二：
让团队可以明确在不同的阶段需要做什么，暂时不需要做什么，以及在什么时间段该做什么；

第三：
在某些公司产品线众多，梳理产品规划更主要的是资源的协调。
即明确分配资源，包括人力资源、开发资源以及运营资源等；

第四：
依托于产品业务的模型。
产品生命周期一般是四个阶段：
孕育期（种子期）、成长期、成熟期和衰退期。
不同产品依托于不同的业务模型更新换代的速度或长或短都会产生不一样的效果，所以目的就是为了在不同的阶段合理分配好时间选择，达到产品在周期中的健壮性；

所以产品规划总结起来也是一句话：在【产品生命周期/不同时间节点】需要达到【目标】。

John在历史文章写过产品规划——
《一文理清产品规划究竟怎么做（内附案例剖析）》
，也可以去看看。

3.竞品分析：竞品是产品的风向标

竞品分析真的很重要。
哪怕你的竞品和你的用户量不是一个级别，利润是竞品的几十倍，也得去研究研究。
毕竟蚊子也是肉嘛。
分析竞品有几个重要的点：

第一是可以为产品制定可行的办法;

第二是随时了解随时了解竞争对手的产品和市场动态，如果挖掘数据渠道可靠稳定，根据相关数据信息可判断出对方的战略意图和最新调整方向;

第三是可掌握竞争对手资本背景、市场用户细分群体的需求满足和空缺市场;包括产品运营策略;

第四是自我快速调整、以保持自身产品在市场的稳定性或者快速提升市场占有率;

第五是新的产品、拍脑袋想出来的(很危险，指的是对新接触的行业没有积累和沉淀)没有形成较为有效完整的系统化思维和客观准确方向的。

所以从竞品分析来说，并不是洋洋洒洒写了几万字就证明了你把竞品给拆解透了，而是带着有目标的思考：
为什么竞品在这个版本做这个内容？他的产品路线图为什么这么走？（结合所处市场来分析，会更加清晰）

4.历史版本梳理

梳理已上线的历史版本就是对业务最好的解读。
清晰的描绘历史版本路线图，更好追根溯源达到快速梳理清楚业务并了解产品目前“优势”、“劣势”、“机会”和“威胁”（SWOT分析法）。

以上是了解业务清晰的基本公式。
当然最后别忘记输出业务需求了。
分析业务需求的时候，可以通过流程管理六要素进行分析：
输入、输出、活动、关系、客户、价值。

输入：
从业务角度来说指的是业务流程输入跑起来所必须的资源。
也是流程启动的触发原因。

输出：
指的是流程完毕后所得到的产物，整个业务流程流转到最后的产出。

活动：
指的是业务流程流转的过程中各个环节，如何有机的调动整个业务流程运作起来的核心关键点。

关系：
指的是各个环节即上述的活动直接的联系，以及相互承载使整个业务流程可以串起来的节点。

用户：
指的是流程服务的对象。

价值：
指的是这一套业务流程跑完后，得到了什么，有什么意义，同时这也是为什么要有这么一套流程的意义所在。

整体总结起来，业务流程就是：
为一组存在相互“关系”的“活动”将“输入”转化成为对“客户”有“价值”的“输出”的工作。

John在刚开始写这个公众号的前几篇文章就写了《
产品经理规划产品之了解业务
》，可以去看看案例分析。

这四个层面做完了其实就是整体对业务有比较清晰的了解。
当然和业务同事更多的沟通是一定的。
有的小伙伴就说：
我都懂这些，但是还是不了解。
听John一句劝：
对业务不熟的产品经理，充其量只是原型仔。

二、产品基本功六部曲：产品模块、产品功能、产品流程、产品原型、产品逻辑和PRD

产品的基本功可以分为这六步：

1.当梳理清楚业务需求，辨别真伪需求后，每个业务对应的产品模块要清晰；

2.当梳理清楚对应的产品模块后，根据需求对应产品模块下的产品功能要清晰；

3.当梳理清楚对应的产品功能后，功能之间相关的功能流程图要清晰；

4.当梳理清楚功能流程图后，每个功能流程落地的页面原型要清晰；

5.当梳理清楚页面原型后，每个页面对应的页面逻辑要清晰；

6.当前面五步清晰后，就可以着手写PRD了。

John用了一个案例：
推荐体系来聊聊

三、开发阶段——实现产品的生命力

1.产品评审

产品提审主要有这个目的：

让与会者清晰的了解需求是什么，需求从哪里来，对现有业务有什么影响，预期收益是什么；

让技术及测试对产品方案有详细的了解，以便后续开发更高效，没有谁愿意在后续的编写测试用例及开发阶段再去反复沟通确认，毕竟那是非常低效的做法，当然，特殊情况除外；

让与会者清晰的知道自己在整个方案落地过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期；

评估产品方案的技术难度及实现周期，一期实现，还是分期实现，投入产出比怎么样？
毕竟互联网产品讲究小步快跑，快速验证迭代，怎么样权衡产品设计（用户体验），技术成本以及商业利益是产品经理主要工作之一。

John之前也写过产品评审相关的文章，可以去看下产品评审具体怎么操作——
产品经理如何避免需求评审会背锅？

2.研发编码

这玩意产品经理也暂时帮不了什么忙。
但是需要实时的和技术去沟通反馈。
跟进项目管理。

3.测试上线

产品测试是产品上线前最后一道门槛。
所以严格把关很重要。
测试一般针对于产品功能测和性能测。
针对于功能测试会具体分为常规流程测试和边界测试。
John之前其实写了
《不吹不擂，产品自查表看完这篇就够了》
，帮助了至少几十位产品经理找到了处理边界逻辑的方法。

你可能就会问了，测试用例不应该是测试小伙伴的事情么？
但是作为产品经理，对应的功能测试肯定需要去了解下。

作为产品，功能性测试文档也不需要太复杂，直接使用excel编撰就可以了。
具体的字段：

序号：
不用说，就是按顺序下去的。
模块：
该功能点具体属于哪个模块的，填写这个主要是方便查找，如：
注册/登录模块。
编号：
对每个用例进行编号，方便后期跟进。
毕竟用文字说，容易口误。
不过此处建议编号设计的有点规则，方便快速定位查找。
如：
A0001。
其中A表示注册/登录模块。
00表示账号登录，01 表示账号密码登录下的第一个测试用例。
功能点：
具体指某个功能，如：
账号登录、首页、发布等。
子功能点：
具体指功能点，如：
账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
用例名称：
具体测试用例的名称。
如：
输入账号、输入密码、密码不合规等等。
前置条件：
指要达到预期测试结果，需要满足那些条件才能达到。
如：
账号密码不一致时，就需要登录失败，那么此时就得保
证账号正确或密码正确以及账号正确时是存在的。
操作步骤：
指要达到预期测试结果，需要按这些步骤来。
最好说明在什么页面，点击或操作什么内容，输入什么内容。
预期结果：
说明按照前面写的应该呈现出怎样的结果。
测试结果：
如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO。
结果描述：
如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。
测试人员：
填写测试人的名字，方便后期跟踪BUG。
测试日期：
填写测试的时间，方便后期查询。
BUGID：
跟测试编号一样，自己设定ID规则，方便快速查询。
BUG负责人：
此处应该有技术那边填写，具体落实到某个人身上，才能更好的解决到问题。