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

齐进取 2023-07-21 15:23:06

写在前面

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

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

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

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

一、需求挖掘与分析

关键词：需求辨别

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

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

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

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

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

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

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

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

关于优先级的确认：

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

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

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

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

关于竞品分析：

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

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

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

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

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

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

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

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

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

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

文档书写的一些Tips：

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

三、产品方案评审

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

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

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

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

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

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