写在前面：
此指南基于 Martin Cagan的 How To Write a Good PRD 和之前写文档暴露出来的主要问题。希望通过规范文档书写，重视起基础能力的培养。
PM需要意识到：具备基础能力未必能够打造出优秀的产品，但是基础能力的缺失只能导致产品的失败，并将你和你的团队拖入泥潭。
产品价值
即便是再细微的功能点也有其存在的价值。通常可以描述为「为WHO解决WHAT」，WHO包括外部客户、公司、部门或岗位(如有可能应当尽量详细定义)，WHAT指此类用户所遭遇到的具体问题，避免使用「提升用户体验」这样笼统的用词。
产品目标
无法被评估的价值没有意义。目标就是衡量产品价值的标准，同时也是激励团队实现产品价值的灯塔，目标描述应遵循S.M.A.R.T.原则，对已有产品的优化应当放出参考数据以做对比。需要注意的是：有些产品的价值通过累积体现，避免使用「上线后」这样笼统的用词，更为严谨的定义为「上线一周后日均」
产品发布时间
将此点纳入产品文档是因为目前普遍缺乏项目管理意识，团队前松后紧，Deadline一拖再拖。PM应当在项目启动时就宣布期望ReleaseDay(即便这是一个没有经过评估的日期)，避免使用「8月下旬」这样笼统的用词。以帮助团队提升紧迫感；技术评审后通常会得到更准确的开发和测试评估，PM 应尽快更新文档并告知团队
数据需求
PM对数据需求的重视程度不应亚于功能需求。功能需求上线后才开始规划数据需求并不是迭代。衡量数据需求的标准在于是否能够全面、准确和细致的计算产品目标。合格的数据需求应该包括：提供哪些数据？这些数据的定义和源是什么？以什么方式提供？从什么时间开始提供？
更新记录
借助协同办公软件，我们可以快速查阅产品文档的修订记录。PM需要做的是将重要信息及时更新到文档，以便于自己和他人日后查阅，并避免无谓的争议。重要信息包括：一、需求和方案变更，包括：需求、流程、逻辑、文案和设计稿；二、产品优化，包括：原因、方案；三、数据 Review，包括：数据明细，是否达到预期目标及原因分析，以及下一步动作。数据Review通常在产品上线1周、2周和1月进行，我们强烈建议PM从产品上线后第一个工作日开始关注数据，并每天在项目组内进行分享。
公共规则
在产品定义涉及多产品线的公共规则时，请尽量与公共规则保持一致；如因特殊原因需要单独定义，需要在文档中说明原因，并确保已与相关PM沟通。一个可以参考的案例：移动端关注功能已经上线，对于关注房源的展示数量上限设定为200，网站端关注功能尚未上线，产品文档中将展示数量上限设定为99，两端的规则差异并无存在意义。
