writing-prds

撰写产品需求文档

定义清晰的问题和边界明确的解决方案，以最大化团队速度和创意产出。

利用来自 Lenny's Podcast 和 Newsletter 中 14 位嘉宾和文章的见解，帮助用户撰写产品需求文档。

如何帮助

1. 起草核心问题 - 协助阐述简洁的问题陈述，不依赖任何特定解决方案。
2. 建立成功指标 - 帮助定义具体、可衡量的成果，作为未来功能请求的筛选条件。
3. 定义项目边界 - 使用塑形技术，引导用户将模糊的请求缩小为有边界的概念。
4. 审查清晰度 - 审核现有草稿的简洁性、可读性和技术意识，防止微观管理。

核心原则

为功能原型设计

Jenny Wen："我们过去会制定两年、五年甚至十年的愿景。现在愿景变成了三到六个月，不一定要制作精美的幻灯片，有时只需创建一个原型，为团队指明方向。"

设计应侧重于短期功能原型，而非静态的长期规划，以跟上 AI 驱动的工程速度。

尽早塑造项目边界

Ryan Singer："在塑形会议中，我们需要拿出某种图表，让工程、产品和设计团队都说'我们理解了'。所以第一件事是，除非我们能从一开始就看到终点，否则我们不会开始。"

使用高强度的协作会议，与设计和工程团队共同在开发开始前建立对边界的共识。

文档以问题为中心

摘自《一页纸和 PRD 的示例与模板》："以问题为导向：用几句有力的句子阐明要解决的问题——最好放在文档顶部——让每个团队成员的大脑都聚焦在同一方向。"

成功的 PRD 从清晰定义的问题和具体的成功指标开始，确保团队在讨论'做什么'之前先对齐'为什么'。

通过简洁迫使清晰

摘自《我最喜欢的产品管理模板》："提醒自己，至少一开始将文档控制在一页内是多么有价值。"

将初始项目文档限制在一页内，迫使团队专注于核心目标，并有助于避免早期复杂性。

通过文档从混乱走向清晰

Melanie Perkins："所以我们有从混乱到清晰的概念，每个想法都始于混乱的一面，然后你必须努力到达另一面，即清晰。混乱可以是一个想法、一个问题、一种哲学或一种信念。"

将抽象想法写下来是将其转化为可执行项目的重要第一步。

避免创意微观管理

摘自《令人讨厌的产品经理的五个习惯》："在阐述项目规格的重要细节和用三页纸解释一个按钮之间有一条微妙的界限。这种讨厌的习惯可能出现在项目开始时，告诉设计师和工程师功能的具体实现方式，也可能出现在项目结束时，你花几天时间详细说明每个功能。"

过度指定功能会扼杀工程师和设计师的创造力。文档应促进对话，而非取代对话。

使用 AI 自动化技术文档

摘自《AI 将如何影响产品管理》："用人类语言描述你想要的内容，获得 80% 完整的草稿，完善它，然后发布。这已经在 ChatPRD 等工具中实现了。"

使用 AI 工具生成大部分技术文档，让产品经理专注于最终的完善和战略细节。

模板与框架

• Lenny 的一页纸模板（一页纸和 PRD 的示例与模板） - Lenny 在启动新项目时使用的个人模板
• 优秀一页纸/PRD 的五个要素（一页纸和 PRD 的示例与模板） - 评估产品规格有效性的评价标准，用于撰写和审查 PRD
• AI 提示：撰写 PRD（产品经理是一个不公平的角色。所以要不公平地工作。） - 一个 ChatGPT 提示模板（GPT-4o 及以上），通过语音转文字口述上下文来起草 PRD
• 面包板与粗马克笔草图（Ryan Singer） - 两种用于塑形会议的协作技术，比线框图更详细，但比 Figma 更粗糙——旨在清晰传达想法
• PRD 和功能工作的技术 PM 问题（成为更懂技术的产品经理） - PM 在撰写 PRD 或处理功能时应问的问题，以展示技术意识并改善协作
• 强问题陈述的五个属性（解决问题的三步框架 👌） - 评估问题陈述是否精心设计的标准，用于撰写一页纸的问题部分
• PRD 审查清单（源自 Lenny 的评论）（一页纸和 PRD 的示例与模板） - 源自 Lenny 对四个真实世界示例的评估，识别常见陷阱以供检查
• 多邻国一页纸模板（多邻国如何构建产品） - 多邻国用于早期产品审查一页纸的模板，以获取功能想法的反馈

详见 references/artifacts.md 获取完整列表及详情。

帮助用户的问题

• "这个项目为用户解决的最重要的问题是什么？"
• "我们将使用哪些具体指标来判断这个项目是否成功？"
• "哪些功能或任务明确不在本版本的范围内？"
• "你是否已经收集了工程团队关于技术约束的反馈？"
• "我们愿意在这个问题上花费多少时间，然后才转向其他事情？"
• "这份文档是否足够简洁，让整个团队都会真正阅读它？"

需要标记的常见错误

• 使用“只是”这个词 - 这会削弱工程师的专业性，并可能因不切实际的快速修复承诺而导致他们倦怠。
• 过早的高保真原型 - 在团队充分探索问题空间或技术约束之前，就将他们锁定在特定解决方案上。
• 忽略非目标 - 未能明确不构建的内容会导致范围蔓延，并失去对主要问题的关注。
• 瀑布式交接 - 将设计师和工程师排除在早期规划之外会导致效率低下，并错失创新机会。

深入阅读

有关 14 位嘉宾的 24 条见解来源，请参阅 references/guest-insights.md

相关技能

• 交付速度
• AI 辅助原型设计
• 使用 AI 代理构建
• 产品工具栈