作者结合工作经验，分享了产品从收集需要到方案发布的优化流程。

产品岗位所需要学习的技能十分庞杂，需求的收集与分析、各样的用户调研方式、数据的整理与分析、文档写作与管理、项目管理、团队协作、复盘总结等等，每一项工作又会有多样的方法论，如此庞杂的技能树，需要一个主干串起来，这是写作本文的目的。

本文为对自己过往产品工作方法的一个总结，写作过程感知到还是存有缺陷，其一：个人经验有限，本文必有不足之处，若您有不同见解，十分欢迎留言讨论；其二：本文主要围绕产品优化工作的主干流程，对于一些支点的涉及常会有一笔带过的情况，出现此情况是因为具体的落地方案多局限具体的需求场景，全部描述出来实在过于繁杂，便不再展开论述。

产品优化流程说明

流程图主干：

1. 需求收集：广泛收集需求，优化工作的源头；
2. 需求筛选：过滤需求，分类处理；
3. 深度分析：深入分析需求背后的原因；
4. 指标体系：建立需求对应的观测数据，确保过程可视化和结果可量化；
5. 优化方案：具体的落地执行方案，如：原型文档；
6. MVP：最小成本验证，快递迭代收割成果。

一、需求收集

产品的成长过程中就是在不断地满足用户的需求，产品优化工作的开端就是收集需求，如何收集？

从需求来源的主动性区分，可以分为被动来源和主动来源。

1. 被动来源

被动来源主要包含上级、用户反馈、产品关联人员三类，这里需要重点对待的是来自上级的需求，上级更关注公司整体层面的指标，需求一般影响面很大，也是一个很好的机会去要求资源积累项目经验；

用户主动反馈的意见大多是bug问题或者投诉，因此需要每天定期快速处理；

来自产品相关岗位人员的需求大多是产品在某方面影响到他们的正常工作或考核指标，产品的工作是需要团队协调配合的，因此多沟通，不要轻易回绝，即使回绝也要有充足的理由或替代方案。

2. 主动来源

主动来源就是主动收集需求，产品需要保持对用户的时刻关注和对市场的前瞻性视野，所以主动寻找一切关于用户的渠道，保持对用户理解的广度和深度就尤为重要，比如腾讯产品的10/100/1000，就是一项很基础但很有效的需求收集方式，其它的方式见图，不一一做展开论述。

这里我们产出的是需求收集表，主要记录需求的来源、时间、原始描述，这是一项高频率的日常工作事务，建议简洁为主，确保能养成习惯。

二、需求筛选

需求收集好了，我们会发现需求量大且杂，需要对其进行筛选，概括起来三步：1）去掉不合理；2）划分颗粒度；3）排出优先级；

1. 去掉不合理

不是每个需求都是合理的！我们首先需要筛去一些不贴合实际的需求，如何筛选？

首先明确什么是不合理？

可以进行三级评定：1）是否符合产品定位；2）是否符合当前战略方向；3）是否符合当前岗位职责；

明确产品定位我常用的方法是回答问题——用什么方式解决什么用户的什么问题？通过这个问题可以明确我们的用户群体，用户核心诉求，链接用户的产品媒介；

当前战略方向则在每年的年度规划中有明确的说明；岗位职责则可以查看KPI或OKR指标；

通过以上的步骤可以帮助我们明确一个需求界限，使需求的筛选更加聚焦；

然后继续分析需求会影响什么？

还是进行三级分析：1）影响哪些用户？2）影响用户量有多少？3）影响哪些指标？

哪些用户？影响的用户是否在目标用户群体内；用户量有多少？影响程度大小；哪些指标？是否影响战略指标，岗位考核指标；

解答以上问题的过程，不合理的需求会大概率剔除出去。

2. 划分颗粒度

需求需要论证再去实现，才能尽量避免走弯路，但每一个需求都去做详尽的分析，这会耗尽我们大量的精力，而且对于小颗粒的需求带来的收益来说，很不贴合实际，因此我们需要对需求进行颗粒度的划分，小颗粒度的可以走快速上线验证，能保证产品的成长速度。

划分依据可以从影响程度和预估开发量来考量。

日常我们会收到很多提升体验的优化需求，但提升体验这是一个很主观的判断依据，容易陷入一种自己就是用户的误区，最好的方式就是量化这种优化结果，在不断的优化—量化反馈中积累对用户的感觉，也是新产品人员的一种低成本快速成长的锻炼方式。

3. 优先级排序

需求总是做不完的，我们不能一次处理所有的需求，为了确保效益最大化，我们需要优先处理能带来最大收益的需求，也就是对需求进行优先级排序。

排序考虑的因素核心两点：效益、成本

效益：有哪些效益指标？最直接就是产品的KPI指标，KPI来自战略方向的拆解，能保证执行方向和可量化。把需求的收益与目标关联起来就能有个大概的评估了，比如电商的主要指标GMV，如果需求是优化新用户的下单率，那么依据公式：GMV=注册量*新用户下单率*ARPU值，就可以估算出新用户下单率对GMV的影响程度。其他的比如交易纠纷指标也可以进行类似的推算。

成本：主要考虑预算投入和开发投入量，这个需要依据具体的需求和开发团队效率来进行评估。

以上不需要精确的分析，重点是区分出不同需求的一个影响程度范围，可以给出一个划分优先级的量化参考指标。

通过这一步产出一份待优化的需求表，明确了需求的重要程度，帮助我们规划接下来的工作目标。

三、深入分析

当一个产品的用户量达到一定规模后，用户会开始出现明显的分化问题；一个需求的满足，是各类用户在各个节点的决策过程，我们需要去深入分析才能找出解决方案。

如何分析？分为两步：定性分析和定量分析。定性分析是明确原因类型，定量分析是明确原因类型占比。

1. 定性分析

2. 定量分析

通过以上两步，我们会产出一份分析报告，报告包含需求中用户的行为路径图，路径的终点就是需求的目的，在这条路径上包含多个转化点，我们明确了各转化点的转化情况和流失原因类型、占比，再对这些原因进行归类和排序，排出优化顺序即可。

四、指标体系

为了优化过程可视化和结果可量化，我们需要建立一套数据指标体系。

指标的观测分为优化前、优化中、优化后，优化前的数据为了确保后期有数据进行对比分析；优化中为了及时观测数据异动和确保优化方向不偏离；优化后则是用于总结优化效果是否符合预期。

观察指标类型和产出总结如下：

五、优化方案

有了详细的需求分析和评定指标，接下来就是明确怎么做，也就是执行方案。

互联网程序员中有一句很有名的话叫“不要重复造轮子”，在产品中也是可以拿来使用的，那就是收集竞品的解决方案，竞品说明我们有着相似需求的用户群体，若对方已经在线上投入使用了，大概率也是适合自己的产品的。

这里我的方法就是长期的竞品跟踪和多体验不同的产品，这给我积累了很多的灵感。

在这一步我们产出可以交付开发的原型文档，关于文档的书写和绘制主要关注两点：1、开发人员是这份文档的直接用户，确保用户能轻松看懂；2、保持良好的文档管理习惯，便于日后查阅和新进人员了解产品。

总结如下：

六、MVP

MVP——最小化可行产品，低成本快速验证方案的可行性。

如何进行？分为两步：1）可行性测试；2）快速迭代；

1. 可行性测试

2. 快速迭代

这个环节需要产出整个项目的复盘总结，包含前期的调研、分析、可行性测试、结论数据说明等内容。

以上就是对产品优化工作从需求收集到上线总结的全过程。

七、产品能力

产品优化流程更多是方法的探讨，但要落实这套方法还需要执行人有特定的能力，最后谈下，产品工作对个人的能力要求，也是一些个人感悟。

产品经理最初产自于宝洁公司的对产品销售的一次岗位创新尝试，由个人来负责一款产品的方方面面，落实了产品的业绩责任，也为其提供极大的操作空间，我们可以简单类比于事业部经理。

随着互联网行业的兴起，这一职位重要性得到了急速的抬升和扩散，但进入的门槛却比过往降低了不少，常常听到是“人人都是产品经理”、“什么都不会，就做产品经理吧”之类的论调。

在我就职的几年内，个人感受就是产品团队内的确存在能力差距大，靠拍脑门提需求，没有一套完善的评定标准，团队内争执现象严重，但随着产品行业发展，也能看到不断的有普遍认可的行业理论和各类分析方法论的出现，开始脱离野蛮生长的困境，逐渐走向正规化，门槛也越来越高，对产品个人的能力要求也在逐渐清晰。

以下是个人认为产品岗位非常需要的几点能力。

1. 学习能力

互联网的一大特点就是变化快，每年都会有一些新兴商业模式和技术突然爆发，产品之间的竞争不再局限于与你同赛道的对手，受益于互联网环境的快速传播能力，产品从0到1再从1到无穷大的记录不断被打破。

身边优秀的产品，基本都保持有阅读的习惯，面对不断变化的环境，让自己保持充沛的学习能力也许是最好的办法。

2. 执行力

产品工作的执行过程，其实就是一个不断受挫的过程。一个需求从提出那一刻开始就在面对不断的挑战：团队成员质疑你的需求不合理，开发认为技术难以实现，用户反对你的改版。

每前进一步都会遇到不同的问题，这是产品工作的常态，如何合理的解决问题，推动方案落地，这是产品人员很重要的一项能力。

3. 责任感

产品的所有问题都能跟产品经理关联起来，我想这与产品的工作流程不无关系，各岗位的需求都要经过产品的审核再派发出去落地执行，到最后若出现问题，自然免不了落到产品的头上。

保持对产品的责任感是一项很高的能力要求，团队内其它岗位需要产品来推动，那么产品的动力更多的是一份自驱力，这份自驱力就来自对产品负责的责任感。

4. 领导力

最后说领导力，我认为这是最难的一点，前面的只是要求自己，但领导力要求我们通过影响别人来完成任务。

一个产品的诞生是多个岗位配合的产物，有配合就会有冲突，这里面含有大量的人员协调工作，而作为第一责任人，这统筹工作自然就落到了产品的头上。

产品经理是一个无实权的岗位，但却要通过协调一个团队来完成工作，对领导能力的要求自然就变得重要了。

以上，感谢阅读。

作者： Rimon，5年产品工作经验

本文由 @ Rimon 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。