产品经理成长之路：完成比完美更重要

对B端产品经理来说，日常工作中的流程一般是什么呢？工作的时候又要注意哪些要点，避开哪些坑呢？笔者结合自己的实践经验为大家分享以上问题的答案。

写在前面

经过了几个月的产品实习，感慨万千，十分想将自己的经验，或者说是经历分享给大家，一来想和广大产品新人共同进步，二来也希望能够从产品前辈处得到一些批评指正。

我进行的是面向B端的中台产品实习生，所以需要在熟悉公司业务的基础上，考虑产品实现的逻辑，产品的用户也是公司内部人员。所以我的经验分享也主要是从B端产品的角度来进行，当然我相信和C端产品也**有共通之处，比如在沟通、紧急事件处理等方面，是属于在日后各类工作中可以进行复用的经历。

文章将按照产品经理进行工作的大致流程进行叙述，架构如下：

• 一、需求挖掘与分析
• 二、产品方案的思考与撰写
• 三、产品方案评审
• 四、跟进开发进度直至验收上线
• 五、用户操作手册撰写
• 六、数据指标分析
• 七、复**
• 八、其他Tips

一、需求挖掘与分析

关键词：需求辨别

B端产品的需求大多数直接来自于业务方，少部分可能是产品经理自主挖掘，尤其涉及到整体逻辑的重构或是一个全新的项目开展，往往是产品提出的需求。C端产品的需求基本上都要产品经理自主去挖掘，借助问卷调查、用户评论、数据埋点分析、竞品分析等方法。但无论是C端还是B端产品在遇到各类需求时，都需要具备需求辨别能力。良好的需求辨别能力能够让你迅速分辨出哪些是该做的需求，哪些是没必要的需求；哪些需求优先级更高，必须尽快实现，哪些需求可以暂放，后续慢慢实现等等。

在拿到一个需求时，至少要进行如下几方面思考：

1. 需求的场景，为什么提出这样的需求，解决什么问题？
2. 有多少用户有这样的需求，是否值得实现？
3. 实现后能带来的什么样的收益？比如用户使用次数增多、人效提高等，并不仅仅指金钱收益。
4. 如何实现这一需求，如何既能满足需求又能简化实现方式与过程？
5. 这一需求是否对其他模块造成影响，影响的评估？
6. 这一需求的优先级，实现的紧迫性？

在整个需求分析过程中，我们都要多角度思考，既要站在用户角度看问题，也要站在研发角度看问题，更要站在产品角度看问题。

要学**跳出来看问题，不能被用户提出的需求受限，我们要考虑一个需求优化的外延性和其他可能性，要比用户考虑的更前一步，不能只看眼前优化的点，要考虑前后变动，不同业务、产品之间的关联，无论是系统和APP都要具有一定的灵活性与柔性，才能更好的支撑后续的优化与改进。

产品经理要摒弃一些想当然的想法，比如不能用户希望实现的功能就一定实现，必须考虑必要性（合理性）、可行性、收益；比如不能开发说不能实现就不去尝试，尤其对于不太懂技术的产品来说，千万不要抱有这样的想法，无论是否真的能实现，我们都要提出自己的看法，进行质疑与沟通，不要害怕说错话被嘲笑，永远不说不表达，永远也不**有成长。

另外我们还需要将所有的需求进行梳理，借助表格的形式，生成需求池，对需求进行分类、描述优化内容、优先级判断、目前的实现状态记录等等。

借助需求池，我们能大致知道一个产品在迭代过程中优化了哪些需求，还有哪些需求没有实现，哪些需要我们尽快实现。

关于优先级的确认：

B端的需求优先级不单单是由产品经理来决定的，而是要根据当前的项目饱和状态、具体使用时间等和业务方共同确认。

一般来说**影响当前使用、线上bug、时间紧急的需求必然优先级**高一些，而单纯的没有影响使用并且只涉及到少部分人的需求，优先级可能**低一些，但是还是要根据具体情况灵活判断。

如果有些需求临近使用，优先级是可以自动提升的，这个也是需要相关的产品经理自己注意这些时间节点，不能等到用户提醒才想起这些需求，然后导致紧急开发上线或是只能再次搁置。

我们也可以借助时间管理中的四象限法则：重要且紧急、重要不紧急、紧急不重要、不紧急不重要，来对需求进行大致的分类，并确定优先级。

关于竞品分析：

做竞品分析是属于需求挖掘的一种，通过与竞品的对比，优势继续发扬，短板进行补足，互相竞争才有长足发展。

相较而言，C端产品进行竞品分析**容易许多，因为可以直接获取到要分析的竞品产品，而B端产品往往很难接触到竞品公司的内部业务，所以较难分析。

但是有一点就是B端用户的用户其实也是C端，所以也可以借助相关C端产品的分析，但是关注的点可能**比较不一样，比如C端竞品**考虑功能结构、用户体验等等，但是B端产品在进行竞品分析时，要透过现象看本质，在体验相关的C端产品时要更多的去考虑这个产品背后公司的业务构成与逻辑。

二、产品方案的思考与撰写

关键词：全面、准确、无歧义、可读、不要拖延

在对当前需要做的需求有了大致的想法后，就可以开始撰写文档了，记住千万不要等全部都想好了才开始写，而是有思路就要动笔，后面再逐步的完善细节。

在deadline横行的时代，越来越多人选择在最后一刻完成任务，其实这样并不是最好的方式，并且很多情况下提交的东西也不**是我们自己特别满意的东西。

所以其实最好的做法是，从最开始就记录自己的想法，先将文档整体的框架搭出来，对于一些不能够确认的细节，或是暂时未发现的问题，再一步步的去解决优化，可以借助脑图的形式将考虑到的各种场景记录下来，然后逐步判断方案是否能够满足这些场景的需求。

不要妄想一口气吃个胖子，也不要妄想一次完美的解决掉所有的问题，扔掉完美主义与拖延，完成比完美更重要。

一份文档大致包含的内容有相关的项目背景、存在的问题、项目的目标、相关的部门、产品方案的概述、具体的优化需求描述等等，可能根据不同项目的特点与阶段**结合进竞品分析、项目风险、埋点需求等等，有时关于竞品和数据分析的部分也**单独抽离出来。

文档书写的一些Tips：

1. 文档描述要全面，写清楚哪些没有变动，变动部分的如何变动
2. 文档描述要准确无歧义
3. 灵活借助目录、图示、表格、文档修订记录等来使文档可读性更高
4. 根据方案长短灵活添加产品方案概述，总结方案中优化的点
5. 存在的问题与项目目标基本是相对的，分点进行阐述，对于每个点进行简单总结，再具体描述，尽可能使用数据指标来衡量
6. 涉及较多界面与交互的方案，除了产品经理自己制作原型外，最好也与专门的交互和UI设计师合作
7. 做原型时要尽可能保持风格一致，但不意味着交互必须完全相同，因为可能有些之前存在的交互方式就不是最优的，要灵活判断
8. 涉及逻辑、校验较多的方案，一定要配上流程图，**比文字更清晰易懂
9. 可以模仿公司其他产品前辈的文档书写模式，要多看，看得多了就知道原来这里这样描述更好。接触到的越好，成长的越快。这也是为什么大家都希望能够进大厂实习，榜样越强大，成长的越快。

三、产品方案评审

关键词： 多次沟通反馈机制 

其实方案的撰写与评审是交叉的关系，在不断的沟通中，方案也**根据实现的难度、时间等原因进行调整，直至最终确定并进入开发。（方案评审-修改-评审-修改-评审-确定-开发）

撰写一份严谨的PRD是产品经理的必备技能，但是能够清楚的向各方人员阐述自己的方案是更加重要的技能。

在进行方案评审时，一定要交代清楚这个方案涉及的项目背景、存在的问题，我们为什么要解决这样的问题，解决了能带来怎样的收益，我们如何解决，涉及哪些模块，进行了哪些改动，从什么改成什么等等。

在这一过程中，往往很容易出现各方人员对同一句话理解不一致的情况，这种时候最好的方式是能够说出具体的场景，进行举例。

我们要学**建立起一种多次沟通反馈机制，在每次方案评审后，要及时记录**议纪要并同步给相关人员，包含需要修改的部分、存疑的部分等等，将确认修改的部分同步在文档中，对于存疑的部分，在下次沟通时进行二次确认，因为有时一次评审可能研发老师还没能彻底理解我们的方案，可能需要一点时间理解相关的业务场景，判断代码上实现的可行性。通过多次的沟通反馈，保证相关人员都能够理解并确定下来最终方案。

四、跟进开发进度直至验收上线

关键词：提早介入、进度同步、仔细验收、持续监控、查明问题原因

在进行完方案评审并确定可以开发的情况下，首先需要前后端、测试人员给出具体排期、上线时间。根据排期时间，产品经理要不断地跟进和推动整个项目开发上线的进度。尤其对于比较大型、逻辑复杂的项目，更要提早介入开发与测试，定期询问状态，避免到最后验收阶段才爆发各种问题与风险。

有时产品经理可能**遇到项目进度推动难或是bug修复进展慢的情况，对于这类情况，首先要辨别一下原因，是由于相关人员手中工作量过于饱和、其他更高优先级项目抢占研发资源、项目实现起来比预期困难或是某方人员不够重视该项目导致的等等。

根据不同的情况，灵活的处理与报备。如果发现以你的身份层级已经推动得很艰难，一定要尽早借助leader的力量去推动，并且要及时同步相关人员目前的进度情况。

作为产品经理要连接前后端、测试多方人员，必须协调和同步好时间，要确保各方均已知晓，不然就**出现信息不对称，时间不统一的尴尬情况。

在正式上线前，产品经理**进行验收，验收时切记不可马虎大意，要针对文档中相关优化的点进行一一验收，在测试环境无法完全验收或是在线上不方便进行验收的部分，正式上线后也要持续进行监控。

也就是说上线并不意味着结束，因为有时到了真实环境，大量的数据运行起来，可能**爆发测试、验收过程中没有发现的问题。

这种时候首先要判断这一问题的影响，是属于方案漏洞还是研发处理上的bug，目前能够采取什么应急方案先进行修补，并且要让开发、测试人员及时进行bug的修复，或是紧急完善相关的方案，提高当前项目优先级，协调开发、测试资源继续支持，迅速迭代。

这种时候其实最重要的是不能慌乱。对于发现的问题，一定要查明原因并记录下来，避免后续再出现同样的问题。对于采取应急措施解决但实际没能复现的bug，千万不能忽视，一定要让开发人员进行复**，查明原因，避免留下隐患。

直到负责的项目稳定运行一段时间后，这一版的优化才算告一段落。而下一版优化的需求梳理、方案撰写等流程在这一版进入开发时，就已经可以开始准备了。

五、用户操作手册撰写

关键词：用户角度

在项目临近上线前，产品经理就可以开始撰写用户操作手册了，撰写的角度是从用户操作使用的角度，一般借助PPT的形式。如果是面向公司内部人员的产品，还要对相关用户进行使用培训。

六、数据指标分析

关键词：核心数据指标确定、透过数据看本质

一个项目完成的是否符合预期，是可以从数据层面来进行衡量的，也就是文档中衡量项目目标的数据指标部分，数据指标提升得好，也是对产品经理工作的肯定。

一方面我们可以在项目开始前，借助之前的数据，分析挖掘相关的需求，并以此衡量我们的项目目标，进行结果导向；另一方面在过程中也可以借助数据分析来查明一些问题的原因；在项目运行一段时间后，可以再次收集相关的数据进行分析，评判本次优化的效果。

产品经理要培养数据思维与数据感，确定核心数据指标，然后借助合理的工具与方法，进行数据采集与分析，并得出相关的结论，结论不应当仅仅是数据层面的占比，而是要透过数据看本质，分析导致数据表象的真实原因。

七、复**

关键词：PDCA循环 

大大小小的项目都需要复**，将做得好的部分整理成可以复用的经验，做得不好的部分分析原因，进行记录，避免再犯。

其实犯错误、出问题不可怕，可怕的是一直犯同样的错误、一直出同样的问题。在这里有一种方法可以借鉴，叫做PDCA循环法：P是计划，D是执行，C是检查，A是行动，在这里面最重要的是在每一轮循环中通过Check，采取一定的Action，好的进行“奖励”，坏的进行“惩罚”，再复用进下次PDCA循环中。

八、其他Tips

1. 每句话都要说到位，谨言慎行，对自己所的每句话负责
2. 对于不同身份职位的人以什么口吻、从什么角度去沟通是值得不断学习的事情
3. 建立多次沟通反馈机制，避免出现“知识的诅咒”
4. 所有变动和沟通及时记录在文档或是**议纪要中，不要用脑子，用文字
5. 提升自己的思维运转，要保持质疑与思考
6. 一定要熟悉你的业务、文档，这样出现问题时才能更快的定位
7. 学**目标拆分，最基本最核心的目标、其他有优化余地的目标等等

写在最后

其实上面阐述的流程是基于已有项目的优化，因为实习生一般不太**直接负责一个新产品或是新项目的搭建。

如果一个项目是从0-1的话，要进行更多的工作，比如项目立项、更多层面的竞品分析、产品框架与边界确定、功能结构图等等。

作为产品新人，还有很多要学习的地方，也还有很大的成长空间。未来还有很多的“坑”需要我去踩，也希望我能分享出更多有价值的经验。

人人都是产品经理，但不是人人都能够理解产品经理。曾经有人对我说，产品经理就是传话的，但我想说如果没有产品经理在中间“传话”，那么工作将无法顺利进行。

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

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