被喷惨的 PRD 长啥样？
早上帮我们星球同学看了一份 PRD，也就是产品需求文档。这是一份已经参加过评审会的文档，而且被喷得很惨。
这位做产品的同学觉得有点冤，于是来问我到底问题出在哪。
我看了整篇文档，总结了以下几个问题，或许对你们有一定的参考作用。
第一个问题，没有背景，功能先行。
经常有读者问我，有没有合适的 PRD 模板？
对于这个问题，我的观点一向很明确，模板不是目的，但针对每一个问题可以制定不同的模板。
这句话听起来可能有点绕，但实际情况的确如此。
如果我给你一份完整的 PRD 文档，里面会有各种需要完善补充的结构，但如果此时你遇到的只是一个交互优化需求，那么模板中的很多结构就会出现空白。
这会导致一个问题，看 PRD 的人需要从模板中找关键信息。相比之下，直接把方案呈现出来反而更直接。
但是，只写方案不写背景也会出问题，那就是看文档的人会主观质疑方案的合理性。
比如我看的这份 PRD，一上来就是功能逻辑介绍，直接把之前刚开发完的功能做了至少 60% 的修改。
关键在于，对为什么要修改的原因只字不提。如果我是程序员，看了也会恼火。
因此，任何呈现在 PRD 里的改动或者新增都需要补充背景，重点不是怎么做，而是为什么要这么做。
关于这部分内容，可以在 PRD 一开头用「需求背景」或者「业务背景」这样的结构呈现出来。
没有背景，功能先行，这样的 PRD 铁定会受到质疑，不冤。
第二个问题，只看大路，不管小路。
在这份 PRD 里我还看到一个问题，就是关于产品方案的描述只有主干逻辑，也就是大路通畅，但是缺乏分支逻辑的梳理，也就是不管小路。
正向来看是没啥问题，但一旦进入开发环节，程序员在代码实施阶段就会遇到很多卡点。
作为一个有经验的程序员，在方案初期是能够看出这些卡点的，这也是为什么很多产品经理想不到的问题程序员能顾及到。
要解决需求方案考虑不全面的问题，我一直建议产品经理可以利用一些工具，比如 UML 图。
例如，时序图可以帮你梳理单个功能点的各项逻辑，状态图可以帮你梳理一个业务规则下的所有可能情况。
当然，像流程图这样的常规工具都是必备的，一图胜千言呐。
把这些图学会了，然后在 PRD 里加以运用和呈现，相信我，你的 PRD 质量一定会提升不少，程序员也会对你刮目相看。
要看大路，同时也要管好小路。
第三个问题，始于想象，终于限制。
关于这份被喷惨的 PRD，其实我觉得最大的问题在于产品经理极大发挥了自己的想象力，但没有考虑客观情况。
在功能逻辑调整中，其中有一项是对原有数据结构做改变的，那这会产生一个问题，兼容性。
产品经理没有考虑到线上多个版本并存的情况，而修改后的逻辑会对之前的所有版本产生兼容性问题，是不可用的。
虽然围绕这个点的修改罗列了很多具体逻辑和方案，但就是因为技术事实上的限制，导致基于这个点的所有发散都是失效的。
其实要解决这个问题，产品经理就得把工作做到前面，不要拿着自己以为的方案去做评审，而是在 PRD 定稿前提前和程序员或者技术负责人做可行性探讨。
某种程度上说，PRD 是一个共识备忘录，而不是产品经理单方面出具的方案细节。
所谓共识备忘录，其实是原子沟通结果的汇总，每一个方案、每一个改动、每一个可能涉及的变化，都需要与利益相关人取得共识。
不仅是技术上的共识，还有设计、运营、法务等不同职能角色的共识。
因此，产品经理的沟通工作是很重的，这是必然。没有谁拿出一个方案就能力压全场，都是不断扩大共识的结果。
如果你平时产出的 PRD 也有上述三个问题，不妨好好复盘一下。
有则改之，无则加勉。
如果你在工作中遇到 PRD 拿不准的问题，或者上评审会前心里打颤，不妨带着你的 PRD 来星球里问我，我会提前给你一些建议。
还不知道怎么加入星球的读者，入口在下面👇🏻
