oldwinter 编写PRD
定义明确的问题和有限的解决方案，以最大限度地提高团队速度和创造性产出。
利用 14 位嘉宾的见解以及 Lenny 的播客和时事通讯中的帖子，帮助用户编写PRD。
如何提供帮助
- 起草核心问题 - 协助阐明简洁的问题陈述，该陈述与任何具体解决方案无关。
- 建立成功指标 - 帮助定义具体的、可衡量的结果，这些结果将充当未来功能请求的过滤器。
- 定义项目边界 - 引导用户使用塑造技术将模糊请求缩小为有界概念。
- 审查清晰度 - 审核现有草案的简洁性、可读性和技术意识，以防止微观管理。
核心原则
功能原型设计
Jenny Wen: "We used to go off and make this two-year, five-year, 10-year vision even. Now it becomes a vision that's three to six months out, and isn't necessarily creating this beautiful deck, sometimes just creating a prototype that points people in the right direction."
设计应侧重于短期功能原型设计，而不是静态的长期规划，以跟上AI驱动的工程速度。
尽早确定项目边界
Ryan Singer: "What we need to do in a shaping session is we come out with some kind of diagram where engineers, product and design, they're saying, "We understand that." So the first thing is we are not going to start something unless we can see the end from the beginning."
在开发开始之前，与设计和工程部门进行高强度的协作会议，以建立对边界的共同理解。
集中解决问题的文档
From "Examples and templates of 1-Pagers and PRDs": "Problem-oriented: They crystallize the problem being solved in a few strong sentences—ideally near the top of the document—to focus the brainpower of every teammate in the same direction."
成功的 PRD 从明确定义的问题和具体的成功指标开始，以确保团队在“为什么”和“做什么”之间保持一致。
通过简洁强制清晰
From "My favorite product management templates": "A reminder of how valuable it is to keep these to one page, at least to start"
将初始项目文档限制在一页内可以迫使团队专注于核心目标，并有助于防止早期的复杂性。
文档从混乱走向清晰
Melanie Perkins: "So we have this concept of chaos to clarity and every idea starts in the chaos side, and then you have to work all the way to the other side, which is clarity. And so chaos can be an idea, it can be a problem, it can be a philosophy or a belief."
写下抽象的想法是将无定形概念转化为可操作项目的第一步。
避免创造性的微观管理
From "Five habits of highly annoying product managers": "There’s a fine line between articulating the important details of a project spec and spending three pages explaining one button. This annoying habit can apply to both the beginning of a project, telling designers and engineers exactly how a feature needs to work, and also at the end when you spec out each feature for days."
过度指定功能会扼杀工程师和设计师的创造力。文档应该促进对话而不是取代对话。
利用 AI 实现技术写作自动化
From "How AI will impact product management": "Describe what you want in human language, get an 80% complete draft, refine it, and then ship. This is already happening with tools like ChatPRD."
使用AI工具生成大部分技术文档，以便产品经理可以专注于最终的改进和战略细微差别。
模板和框架
- Lenny 的 1-Pager 模板（1-Pagers 和 PRD 的示例和模板）- Lenny 的个人模板在他开始新项目时使用
- 优秀 1-Pager/PRD 的 5 个要素（1-Pager 和 PRD 的示例和模板）- 使产品规范有效的评估标准，可用于编写和审查 PRD
- AI 提示：编写 PRD （产品经理是一个不公平的角色。因此工作不公平。） - ChatGPT 提示模板（GPT-4o 及更高版本），用于通过语音转文本来指示上下文来起草 PRD。
- 面包板和脂肪标记草图 (Ryan Singer) - 两种用于塑造会话的协作技术，比线框更详细，但不如 Figma 精致 - 旨在清晰地传达想法
- 关于 PRD 和功能工作的技术 PM 问题（成为技术性更强的产品经理）- PM 在编写 PRD 或开发功能时应提出的问题，以展示技术意识并改善协作
- 强有力的问题陈述的五个属性（解决问题的三步框架👌） - 评估问题陈述是否精心设计的标准，在编写单页纸的问题部分时使用。
- PRD 审查清单（源自 Lenny 的批评）（1-Pagers 和 PRD 的示例和模板）- 源自 Lenny 对四个现实世界示例的评估的清单，确定了要检查的常见陷阱
- Duolingo 单页模板（Duolingo 如何构建产品）- Duolingo 用于早期产品审核单页模板，以获取有关功能想法的反馈
有关详细信息的完整列表，请参阅 references/artifacts.md。
帮助用户的问题
- “这个项目为用户解决的最重要的问题是什么？”
- “我们将使用哪些具体指标来确定该项目是否成功？”
- “哪些功能或任务明确超出了此版本的范围？”
- “我们已经收集了工程部门关于技术限制的反馈了吗？”
- “在我们继续前进之前，我们愿意花多少时间来解决这个问题？”
- “这份文件是否足够简短，以至于整个团队都会真正阅读它？”
标记的常见错误
- 使用“just”这个词 - 它会削弱工程师的专业知识，并有可能让他们因不切实际的快速修复承诺而精疲力尽。
- 过早的高保真模拟 - 它在团队充分探索问题空间或技术限制之前将其固定在特定的解决方案上。
- 忽略非目标 - 未能确定您不构建的内容会导致范围蔓延并失去对主要问题的关注。
- 瀑布式交接 - 将设计师和工程师排除在早期规划之外会导致效率低下并错失创新机会。
深入探讨
有关 14 位嘉宾的全部 24 条见解，请参阅 references/guest-insights.md
相关skill
- 交付速度
- AI辅助原型设计
- 与AI代理一起构建
- 产品工具栈