产品需求文档需要注意10件事

01什么是完美的产品需求文档（PRD）？

---

就像产品经理一样，产品需求文档需要同时有效地执行许多不同的角色。该文档将由设计师，营销人员和工程团队使用，并且需要传达他们所需的所有必要信息。

参考上面的漫画，我们的产品要求文档有助于确保每个人都在看同一棵树。您需要做的只是思考读者，并避免他们提出的问题。

02文档目录

---

像任何一本好书一样，此文档应易于搜索和扫描。

此部分可以包括版本号，参与人员，重要日期以及设计的链接URL。

03背景和动机

---

这就是产品背后的原因。要有主见，但要简短描述。

如果可能，请提供一些数据或估算，例如：

“预计该功能将为运营团队每月节省10个小时”

要么“……将参与率提高了30％”

04现有数据和用户研究

---

对于更复杂的产品-您需要包括有关当前状态的数据。

例如：如果您正在重新设计结帐流程，请描述当前付款渠道行为和每一步的流失率。

05用户故事

---

作为（什么用户角色），想要做（什么操作），这样做他得到了什么（益处）。

您应该能够轻松判断出用户故事是否令人满意。

将您的高级目标分解，为其组成故事，并简要描述实现逻辑。

为每个故事分配优先级。高优先级的故事会更详细。

06设计规格

---

这是产品需求文档中最关键的部分，开发人员将在其中花费最多的时间。

绘制出用户流程，原型设计，如果可以，请链接至高保真模型。

07写上可能的错误情况

---

写上可能出现的错误，和极端的情况如何处理。

例如：您可能选择实现一种付款流程，在该流程中，用户无需在付款前创建帐户-只需输入他们的电子邮件即可。

基本假设是用户不会故意使用未知人的电子邮件地址付款。如果用户错误地输入了错误的电子邮件并付款，则运营团队将手动进行纠正。

08数据存储和第三方集成

---

当用户与您的功能交互时，请描述您希望如何存储此信息。

无论是在您自己的数据库中还是在第三方工具中。

作为一名PM，了解此数据的存储方式也是有益的，以便您以后可以跟踪此功能的性能。

09验收标准

---

这对于开发人员和质量检查工程师来说至关重要-因为他们将使用此编写测试用例。

良好的书面接受标准应为：易于阅读，带有“完成”的明确定义

完成于什么-而不是如何完成。它应该描述意图而不是解决方案

10写上需要统计的数据指标

---

专注于您希望通过功能改进的一项主要指标。

例如，如果您正在重新设计结帐页面，则应跟踪付款渠道转换率。

您可以提及可能会受到更改影响的其他辅助指标，例如页面停留时间，平均订单价值等。

写上您希望统计的数据。

记得

---

产品需求文档应该是产品经理的思想-在许多方面都是活的东西。

尽可能简洁，富有同理心和详尽无遗，

尽可能简洁，富有同理心和详尽无遗，

尽可能简洁，富有同理心和详尽无遗，

您合作的同事会为此而爱上您。