如何编写开发人员可以从中发货的 PRD

大多数产品需求文档都因同样的原因而失败：它们描述的是功能而不是问题和结果。 一位产品经理写道“系统应该有一个带有图表的仪表板。” 一位工程师读到后问道：什么图表？ 什么数据？ 为了谁？ 为什么要用图表而不是表格、导出或自动电子邮件？

PRD 成为功能愿望清单。 工程师的解释与 PM 的意图不同。 范围同时向三个方向扩展。 两个月后，团队构建了一些技术上符合规范但没有解决任何人问题的东西。

一个好的产品需求文档模板可以很好地完成一件事：它为工程师提供了足够的背景信息来做出数千个微观决策，而无需为每个决策都返回给 PM。 它在回答“什么”之前先回答“为什么”，在“如何”之前回答“为谁”。

这是我们使用的格式萨维在我们期间Discovery & PRD phase。 我们已经从这些文档中发送了复杂的产品，包括费纳多人工智能，一个代理平台，可将文本提示转变为可运行的网络应用程序，目前为 50,000 名用户提供服务。

您的 PRD 需要的 7 个部分

有用的产品需求文档模板有七个部分。 每个部分都强调特定类型的清晰度。 跳过一个，就会造成一个空白，并在开发过程中用假设来填充。

1.问题陈述

根据经历特定疼痛的特定人来陈述问题。 本节由三个问题构成：

• 谁有这个问题？说出人物名称。 “拥有 50-200 名司机的物流公司的运营经理”很有用。 “用户”不是。
• 有多痛苦？量化成本。 浪费时间、损失金钱、产生错误。 “调度员每天要花3个小时手动分配路线”是一个值得解决的问题。 “路线分配可以改进”对工程师来说没有任何意义。
• 他们现在做什么？描述当前的解决方法。 如今，人们正在解决这个问题，即使他们的解决方案很慢、需要手动或容易出错。 了解解决方法可以告诉工程师“足够好”是什么样子以及标准在哪里。

问题陈述是基础。 如果工程部门能够很好地理解问题，他们将做出更好的设计权衡，而无需升级决策。 如果不这样做，则规范中的每个歧义都会出现一条 Slack 消息。

2. 成功指标

用具体数字定义“完成”是什么样子。 像“改善用户体验”这样模糊的目标无法衡量，也无法实现。 比较这两个：

• 模糊的：“让入职更快”
• 具体的：“通过消除手动数据导入步骤，将新用户入职时间从 3 天减少到 2 小时”

具体版本告诉工程师应该关注哪里。 他们知道数据导入步骤是瓶颈。 他们知道目标是 2 小时，而不是 2 分钟，这改变了值得构建的自动化程度。 包括 3 到 5 个指标。 不仅如此，您一次会针对太多结果进行优化，这意味着您不会针对其中任何一个进行优化。

3. 按角色分组的用户故事

按执行操作的人而不是按功能区域对故事进行分组。 这让工程师思考工作流程而不是屏幕。 用户故事遵循以下格式：“作为一个[角色]，我想要[行动]以便[结果]。”

出租车预订 SaaS 的示例：

• 乘客：“作为乘客，我希望在预订前获得票价预估，以便比较价格。”
• 司机：“作为司机，我希望在地图上看到上车地点，这样我就可以在不打电话给乘客的情况下进行导航。”
• 操作员：“作为车队运营商，我希望在一个视图中查看所有活动的行程，以便在有人取消行程时我可以重新分配司机。”

三个不同的人，三种不同的需求，三种不同的界面。 按角色分组可以防止构建一个屏幕试图为所有三个人提供服务却无法很好地服务于他们的常见错误。

4.范围边界（你不构建的东西）

本节与功能列表一样重要。 范围边界是关于产品在此阶段不会做什么的书面协议。 如果没有它，范围从第一天起就会缩小，因为每个利益相关者都认为他们喜欢的功能都包含在内。

写出明确的排除：

• “v1 中没有移动应用程序。仅具有响应式设计的 Web 应用程序。”
• “在第二阶段之前不会提供多语言支持。”
• “付款由 Stripe Checkout 重定向处理；无自定义付款流程。”
• “管理面板仅供内部使用；没有针对租户的白标。”

每次排除都会阻止对话，否则会在冲刺中期有人说“等等，我以为我们也在构建它”时发生对话。 将艰难的决定预先放在文档中，而不是三周后的站立会议中。

5. 技术限制

列出限制产品构建方式的不可协商因素。 这些不是实现细节（不要在此处指定数据库或框架）。 这些是工程人员在选择方法之前需要了解的业务和合规性要求。

• 集成：“必须通过 RFC 从客户现有的 SAP 系统中提取库存数据。” 工程师在设计数据层之前需要了解第三方依赖关系。
• 表现：“仪表板必须在 2 秒内加载 10,000 行数据。” 此约束驱动有关缓存、分页以及是否预聚合数据的决策。
• 遵守：“所有患者数据在静态和传输过程中都必须进行加密。需要符合 HIPAA 要求。” 这句话改变了整个基础设施的方式。
• 数据驻留：“用户数据必须保留在欧盟数据中心内。” 这消除了某些云提供商和区域。

技术限制使工程人员无法构建在阶段中有效但在生产中失败的产品，因为直到第六周才提到 SAP 集成。

6. 线框图或用户流程

线框不需要看起来很光滑。 他们需要清楚。 Figma 原型可以工作，用手机摄像头拍摄的手绘图也可以工作。 重要的是该文档显示了用户如何逐个屏幕地在系统中移动。

至少包括：

• 每个角色的幸福路径（没有出问题时的预期流程）
• 错误状态和边缘情况（付款失败、数据丢失、用户失去连接时会发生什么）
• 入口点（用户是如何第一次遇到这个功能的？）

用户流程暴露了文本描述隐藏的复杂性。 您可以用两句话描述结帐过程。 当你绘制它时，你会发现有七个屏幕、三个分支路径和两个集成点。 这种视觉迫使我们进行诚实的估计。

7. 具有验收标准的里程碑

将项目分解为 2 到 4 周的里程碑。 每个里程碑都会带来一个利益相关者可以看到和测试的工作增量。 对于每个里程碑，编写二元验收标准：通过或失败、完成或未完成。

• 里程碑 1（第 1-2 周）：用户可以注册、登录并查看空的仪表板。 接受：身份验证流程适用于电子邮件/密码和 Google OAuth。 仪表板以零状态消息传递呈现。
• 里程碑 2（第 3-4 周）：用户可以创建和编辑项目。 验收：CRUD 操作工作正常。 表单验证捕获空字段和重复名称。 数据在会话之间持续存在。
• 里程碑 3（第 5-6 周）：用户可以邀请团队成员并分配角色。 接受：邀请电子邮件在 30 秒内发送。 受邀用户可以接受并以正确的权限访问该项目。

里程碑为纠正方向创造了自然的检查点。 如果里程碑 2 需要四个星期而不是两周，那么您在里程碑 3 开始之前就知道了。 您可以在超支化合物之前调整范围、时间表或预算。

破坏 PRD 的常见错误

写了 40 页没人读

如果你的 PRD 超过 10 页，工程师会略读它。 他们会阅读第一部分，跳到与他们的冲刺相关的部分，并错过将他们的工作与产品目标联系起来的上下文。 一份简洁的文档胜过 Google 云端硬盘中的一份全面的文档。 目标是 5 到 10 页，并为需要深度的人提供补充材料（线框图、研究数据、竞争分析）的链接。

指定实施细节

PRD 应描述产品的用途及其原因。 它不应该指定后端使用具有特定模式的 PostgreSQL，或者前端使用 React 和 Redux。 这些是属于工程团队的工程决策。 当产品经理指定实施细节时，会发生两件事：工程师感到受到微观管理，并且产品被锁定在没有完整技术背景的情况下做出的技术决策。 说明约束（“必须处理 10,000 个并发用户”）并让工程师选择工具。

无范围边界

这是最昂贵的错误。 如果没有书面的范围边界，利益相关者会对所包含的内容做出不同的假设。 首席执行官希望有一个移动应用程序。 销售副总裁期望 CRM 集成。 首相两者都没有预料到。 当这些假设浮出水面时，团队已经花了三个星期的时间在错误的方向上进行建设。 写下排除的内容。 签署排除条款。 当有人问“我们还可以添加......”时请参考它们

列出功能而不解释原因

“系统应该有一个通知中心。” 为什么？ 谁正在被通知？ 关于什么？ 这些通知有多紧急？ 用户是否需要对它们采取行动，或者它们只是提供信息？ 没有“为什么”的功能是根据工程师的解释构建的，这可能不符合用户的需求。 将功能与用户故事和成功指标联系起来。 如果某个功能未映射到用户故事，请询问它是否属于此阶段。

产品需求文档模板

复制此模板并填写到您的下一个项目中。 每个部分都包含指导您写作的提示。

Savi 如何在发现和 PRD 阶段使用 PRD

当你开始一个项目时萨维，我们的第二步过程是Discovery & PRD。 我们一起定义范围、功能和技术架构。 在编写任何代码之前，您会获得一份详细的产品需求文档，其中包含里程碑和定价。

这不是一种形式。 PRD 是您的期望与我们构建的内容之间的合同。 PRD 中的每个功能、里程碑和验收标准都成为项目计划中的一个行项目。 开发过程中遇到问题，我们先查PRD，然后再讨论。 这将反馈循环从几天缩短到几分钟。

以下是我们的发现和 PRD 流程的涵盖范围：

• 问题验证：我们挑战您的假设。 如果您描述的问题与用户体验不符，那么快速构建错误的解决方案比缓慢构建正确的解决方案更糟糕。
• 谈判范围：我们研究哪些内容属于 v1，哪些内容应该等待。 为了费纳多人工智能，这意味着从单页应用程序生成开始，然后扩展到具有数据库模式和 API 路由的全栈输出。 第一个版本证明了核心价值； 第二个版本对此进行了扩展。
• 技术架构示意图：在估算之前，我们概述系统架构。 这会尽早发现危险信号：集成复杂性、性能瓶颈、改变基础设施方法的合规性要求。
• 固定价格里程碑：珠三角的每个里程碑都对应一个固定价格。 在工程开始之前，您就知道为每个交付成果支付的费用。 没有意外的按小时计费，没有无限的时间表。

发现和 PRD 阶段需要 3 到 5 个工作日。 输出是一个文档，您可以将其交给任何工程团队，而不仅仅是我们的工程团队，他们将有足够的背景来估计、计划和构建。 这是对优秀 PRD 的考验：一位从未与您交谈过的有能力的工程师能否阅读此文档并构建正确的产品？

编写 PRD 是第一个工程决策

PRD 不是您在工程开始之前编写的文档。 这是第一个工程决策。 产品需求文档的质量决定了您的团队是否花时间构建产品或讨论产品应该是什么。

使用七个部分。 每一项都要具体。 写下您没有构建的内容。 用数字定义成功。 当您遇到无法填写的部分时，这就是在编写更多代码之前进行更多研究的信号。

回答正确问题的 5 页 PRD 的效果会优于回答错误问题的 40 页 PRD。

常见问题