看了这份 PRD 后，我给绝对好评！
前几天星球里有个同学向我提问，让我帮忙看下他的 PRD。说实话，看完后我会给出好评。
原本我以为他工作至少也有三年以上了，可事后才发现，他是 19 年毕业的新人。而且，大学专业是广告学。
我看过的 PRD 也不少，但很久没看到这么完整、清晰、整洁的 PRD 了。在征得这位同学的同意后，我截取了一部分跟你们分享下。
在之前的文章里我也说过，我不太喜欢所谓的 PRD 模板，因为用模板写 PRD 就好像是在做填空题。而实际遇到的产品需求更像是开放性问题，有时候一些解决方案并不需要套用模板解决。
所以，我一直认为 PRD 的目的是结合文字和图片去描述一个问题并表达一个解决方案。只要达到这个目的，就是一份好 PRD。
先看下他的 PRD 结构，这款产品是一个面向海外用户的游戏秘钥商城，B2C 模式，核心竞争力就是从特定渠道拿到价格更低的秘钥并向用户出售。
这个结构相对来说是比较完整的 PRD 目录了，有产品背景说明、结构设计、流程设计、原型设计等，应付大部分需求场景也是绰绰有余。当然，肯定还有更完整的结构。
在产品和技术这个范畴内，产品经理对需求的信息完整度是肯定要超过技术的。所以，如果一份 PRD 只有产品经理自己能看明白，显然是不合格的。还别说，这样的 PRD 我见过不少。
什么叫只有产品经理自己能看懂呢？
简单说就是你看到了大海，但你只画出了一个小池塘。而技术实际能获取的信息很可能就是一条小水沟，这就是信息的逐级递减。
作为一个新项目，这位同学 PRD 里有几点我认为是做的比较好的，这里详细说一下。
第一，对产品所在的市场做了详细的分析，包括行业现状、业务模式、产业链结构以及当前产品所处的产业链节点。
这个说明能让 PRD 读者很快了解到这个产品是在哪个领域的哪个细分方向上竞争，即明确自己在哪个赛道。
第二，通过几个同类产品的竞品分析，突出当前产品的差异化定位，即明确自己有什么优势。
第三，区分了用户特征和用户画像，通过具体的用户画像来描述产品目标用户的具体情况，即明确了自己是为谁服务的。
这一点很关键，有些产品之所以上线后没有效果，很大程度上都是不知道自己到底为谁解决了什么具体问题。
第四，构建了用户体验地图。
这是从更微观的层面对用户行为和需求以及产品存在的机会点进行剖析，对后面提出具体的产品方案做好了信息铺垫。
其实用户体验地图能比较完整的还原出用户在使用产品过程中的操作以及情绪变化，这个工具对产品体验设计非常有帮助。
第五，业务流程图清晰、规范。
这里特别要提一下，虽然很多 PM 都知道怎么看流程图，但很多人的流程图实际上都不规范。
举个例子，我发现很多人在使用流程图的时候都没有开头或结束，全部都是长方形的节点。此外，很多人分不清流程图的各种图例代表什么意思，经常乱用。
这份 PRD 里的流程图，我看下来是非常舒服也是非常清晰的。
另外，一些具备订单或者工单模块的业务里，产品在各个阶段的订单或工单状态定义是非常重要的。
如果没有一个全局说明，在开发过程中技术可能就会经常找产品经理问，用这种订单状态机来描述就能很好的解决这个问题。
第六，原型图描述突出了逻辑，而不只是状态的堆砌。
很多 PM 画的原型普遍存在一个问题，就是只描述状态，不描述逻辑。
举个例子，校验用户名和密码正确后即登录成功并进入产品首页，这就是状态变化。而登录成功后要更新用户信息、获取最新的用户状态、或者是要发送其他请求，这些都是状态背后的隐藏逻辑。
只有把状态和逻辑完整梳理清楚，技术在开发过程中才不会遗漏功能细节，测试时也会少很多问题。
其实原型并不需要多么花哨，像这样把关键信息描述清楚，让别人看完后既知道流程，也知道状态和逻辑就可以了。
相对来说，这份 PRD 我还是比较认可的。当然，提升的空间也是有的，这里说几点。
第一，涉及到复杂业务流程和逻辑的产品设计，可以尝试用 UML 图来表达，既简单又清晰。
第二，作为一款新开发产品的 PRD，可以补充业务预期目标以及产品验证指标，这样后期可以量化结果。
第三，在产品关键路径上的数据埋点以及事后做数据分析的指标定义也可以补充上。
PRD 的好坏不在于好不好看，而是信息传递的完整性和准确性，让一个完全没有接触过这款产品的人看了也能了解清楚。
作为一个刚毕业一年左右的新人，能做出这样的 PRD，还是值得点赞的。
如今的后浪，正以我们预期外的速度在成长。
················· 唐韧出品 ·················