<aside> 📌

最重要的，PRD 是写给别人看的，需考虑读者的感受，要换位思考，想想看，看的人需要知道什么？

</aside>

• PRD 是产研达成共识之后的需求细节阐述
  • 达成共识之前一般写 Proposal ，相当于功能提案，介绍大概的思路和多种方案，但不详尽
  • 每个 PM 也需要对自己的产品有持续的完整思考，这种一般叫 Product Deck，更形而上一些，但也是为了将想法显性化，也是为了统一团队认知
• PRD 怎么写呢？
  • 思路之一，减少分歧，需要介绍需求相关的背景，比如实体模型关系和概念定义
  • 思路之二，按照功能的使用旅程来写，比如当前功能的开始、运行直到结束，拆解并分块撰写
  • 思路之三，完备性很重要，每个 PM 都需要一个逐步积攒的产品检查清单，每次写完之后都需要检查，常见的比如，断网弱网怎么办？
  • 思路之四：一图胜千言，除非团队配合极致默契，最好有一些原型图、流程图、概念图来辅助表达，但只有图是不行的。
  • 思路之五：不做什么与做什么同等重要，都要写在里面
• PRD 是一个过程，存在于需求从拆解到开发到上线的全流程
  • 每一次达成的新的共识，必须反映在 PRD 里，并同步给所有人
  • 即写即更新
  • 凡是能够促进需求上线的资源、背景、上下文都可以塞在里面
• PRD 没有准确的模板，底线是只要表达清晰且符合共识就可以
  • 尽量用自己所在团队既有的模板
  • 调整模块，要与相关干系人告知
  • 不要过于频繁调整模板，可能让协作的上下游感到迷茫
  • 不用拘留于形式，纯粹的思维导图或者原型图也是可能的
  • 如果一定要一个模板，可以考虑类似下面的模块划分