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