就像产品经理一样，产品需求文档需要同时有效地执行许多不同的角色。该文档将由设计师，营销人员和工程团队使用，并且需要传达他们所需的所有必要信息。
参考上面的漫画，我们的产品要求文档有助于确保每个人都在看同一棵树。您需要做的只是思考读者，并避免他们提出的问题。
像任何一本好书一样，此文档应易于搜索和扫描。
此部分可以包括版本号，参与人员，重要日期以及设计的链接URL。
这就是产品背后的原因。要有主见，但要简短描述。
如果可能，请提供一些数据或估算，例如：
“预计该功能将为运营团队每月节省10个小时”
要么“……将参与率提高了30％”
对于更复杂的产品-您需要包括有关当前状态的数据。
例如：如果您正在重新设计结帐流程，请描述当前付款渠道行为和每一步的流失率。
作为（什么用户角色），想要做（什么操作），这样做他得到了什么（益处）。
您应该能够轻松判断出用户故事是否令人满意。
将您的高级目标分解，为其组成故事，并简要描述实现逻辑。
为每个故事分配优先级。高优先级的故事会更详细。
这是产品需求文档中最关键的部分，开发人员将在其中花费最多的时间。
绘制出用户流程，原型设计，如果可以，请链接至高保真模型。
写上可能出现的错误，和极端的情况如何处理。
例如：您可能选择实现一种付款流程，在该流程中，用户无需在付款前创建帐户-只需输入他们的电子邮件即可。
基本假设是用户不会故意使用未知人的电子邮件地址付款。如果用户错误地输入了错误的电子邮件并付款，则运营团队将手动进行纠正。
当用户与您的功能交互时，请描述您希望如何存储此信息。
无论是在您自己的数据库中还是在第三方工具中。
作为一名PM，了解此数据的存储方式也是有益的，以便您以后可以跟踪此功能的性能。
这对于开发人员和质量检查工程师来说至关重要-因为他们将使用此编写测试用例。
良好的书面接受标准应为：易于阅读，带有“完成”的明确定义
完成于什么-而不是如何完成。它应该描述意图而不是解决方案
专注于您希望通过功能改进的一项主要指标。
例如，如果您正在重新设计结帐页面，则应跟踪付款渠道转换率。
您可以提及可能会受到更改影响的其他辅助指标，例如页面停留时间，平均订单价值等。
写上您希望统计的数据。
