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

Moon
5395 阅读
10


01什么是完美的产品需求文档(PRD)?


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

0.jpg


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



02文档目录


image.png

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

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



03背景和动机


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

如果可能,请提供一些数据或估算,例如:

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

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



04现有数据和用户研究


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

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


05用户故事


作为(什么用户角色),想要做(什么操作),这样做他得到了什么(益处)。


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

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

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


06设计规格


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

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


07写上可能的错误情况


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

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

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


08数据存储和第三方集成


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

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

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



09验收标准


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

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

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


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


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

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

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

写上您希望统计的数据。


记得


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

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

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

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

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