很多独立开发者不喜欢写 PRD，觉得那是大公司产品经理才需要的东西。一个人做产品，想法都在脑子里，直接开干最快。于是需求、页面、流程、数据、边界、定价都边做边想，做着做着发现自己不断改方向，甚至忘了最初到底要验证什么。
PRD 的价值不是让你写一份很厚的文档，也不是为了显得专业。它的作用是把产品决策写清楚：服务谁，解决什么问题，第一版交付什么结果，不做什么，怎么判断成功。对于独立开发者来说，PRD 越短越好，但关键决策不能缺。
第一次写 PRD，不要追求模板完整，而要追求行动清楚。它应该像一张施工图，让你或 AI 编程工具知道该做什么、不该做什么、先做什么、做到什么程度算完成。
PRD 先写问题，不先写功能
很多 PRD 一上来就是功能列表：登录、首页、生成、导出、历史记录、支付、后台。这样的文档看起来具体，但很容易跑偏。因为你还没说清楚用户为什么需要这些功能，功能就变成了自我合理化。
好的 PRD 第一部分应该写问题：目标用户是谁？他在什么场景下遇到什么困难？现在怎么解决？现有方案哪里不满意？这个问题如果不解决，会造成什么成本？这些内容决定了后面所有功能的取舍。
比如不是写“做一个竞品监控功能”，而是写“Shopify 卖家每周手动查看 10 个竞品店铺，复制上新和价格变化到表格，耗时 2 小时，而且容易漏掉重要变化”。这个问题写清楚以后，功能自然会更聚焦。
PRD 的第一目标，是防止你忘记产品为什么存在。
写清楚第一版核心结果
PRD 里最重要的一句话，是第一版要交付什么结果。不是愿景，不是长期路线，而是用户第一次使用后能拿到什么。结果越具体，开发越不容易跑偏。
可以用这个句式：
第一版只帮助 [目标用户] 在 [具体场景] 得到 [核心结果]。比如“第一版只帮助独立开发者在产品上线前生成一份发布检查清单”。有了这句话，你就能判断哪些功能不该做。团队协作、历史版本、模板市场、自动排期，也许以后有价值，但第一版不是为了它们。
核心结果也是验收标准。只要用户能得到这个结果，第一版就可以上线验证；如果得不到，其他功能做得再好也没意义。
写用户流程，而不是只写页面
页面是静态的，流程才是用户真正经历的东西。第一次写 PRD，不需要画复杂流程图，但至少要写清楚用户从进入到完成结果的步骤。
比如：用户打开页面，选择产品类型，填写上线日期，点击生成，看到清单，复制或下载，留下邮箱接收后续提醒。每一步都要说明用户输入什么、系统输出什么、失败时怎么办。
流程写出来以后，你会发现很多页面其实不需要，也会发现很多隐藏边界。比如用户不填日期怎么办？生成失败怎么办？结果太长怎么办？用户能不能不登录就导出？这些问题如果不提前写，开发时会不断打断你。
PRD 不需要把每个按钮写得像法律条文，但核心路径必须清楚。路径越清楚，开发越快，测试越容易。
明确不做什么
第一次写 PRD，最容易缺少“不做什么”。没有不做清单，功能会不断膨胀。任何看起来有用的想法都能塞进来，最后第一版又变大。
不做清单可以很简单：本版本不做登录、不做团队协作、不做历史记录、不做在线支付、不做多语言、不做复杂后台、不做自定义模板。写出来以后，你就能抵抗开发过程中的功能冲动。
不做不是永远不做，而是当前不做。可以把它们放到后续版本。这样既保留想法，也保护当前版本的边界。
对独立开发者来说，不做清单比功能清单更重要。功能清单告诉你要做什么，不做清单保护你不要做太多。
写成功指标
PRD 最后要写成功指标。没有指标，产品上线后你只能凭感觉判断。觉得页面不错、朋友说可以、有人访问，这些都不是足够清楚的结论。
第一版指标可以很简单：多少人完成核心动作，多少人留下邮箱，多少人愿意再次使用，多少人愿意付费，多少人愿意回复反馈。指标不需要多，但必须和核心假设相关。
比如一个发布清单工具，指标可以是：100 个目标用户访问，30 人生成清单，10 人复制或下载，5 人留下邮箱，3 人回复反馈。如果这些行为都没有出现，就说明问题、表达、渠道或结果需要调整。
指标让 PRD 从“我要做什么”变成“我要验证什么”。这才是早期 PRD 的真正价值。
一个最小 PRD 模板
第一次写 PRD，可以只保留 8 个部分：
1. 背景：为什么要做 2. 目标用户：服务谁 3. 用户问题：什么场景下有什么痛点 4. 核心结果：第一版交付什么 5. 用户流程：用户如何完成这个结果 6. 功能范围：本版本做什么 7. 不做范围：本版本不做什么 8. 成功指标：上线后看什么数据这份 PRD 不需要很长。每个部分写 3 到 5 行就够。它的目标不是覆盖所有细节，而是让产品边界清楚，让开发过程少返工。
如果你用 AI 辅助开发，这份 PRD 也会非常有用。AI 最怕需求模糊，PRD 写清楚以后，它更容易生成符合目标的代码、页面和数据结构。
总结
第一次写 PRD，不要把它当成大公司流程，而要把它当成独立开发者的防跑偏工具。它不需要厚，但要清楚；不需要华丽，但要能指导开发。
好的 PRD 会回答五个问题：为谁做，解决什么，第一版交付什么，不做什么，怎么判断成功。只要这五件事写清楚，你的产品设计就已经比“想到哪做到哪”稳很多。
作业
- 为你的产品写一句核心结果：第一版只帮助谁，在什么场景，得到什么结果。
- 按 8 个部分写一份一页 PRD，每部分不超过 5 行。
- 列出至少 5 个本版本不做的功能。
- 写 3 个上线后一周内要观察的成功指标。
下一节课
用户流程图怎么设计：把页面连接起来之前，先把用户完成结果的路径画清楚。
原文链接：第一次写 PRD 应该怎么写 | Harries Blog™
