prd-writing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Writing

PRD撰写

When to Use

适用场景

Activate when a founder or PM needs to turn a product idea, feature request, or strategic initiative into a structured Product Requirements Document. This includes situations where the user says things like "write a PRD," "spec out this feature," "define requirements for X," or "I need to document what we're building."

当创始人或产品经理（PM）需要将产品想法、功能需求或战略举措转化为结构化的产品需求文档（PRD）时启用。这包括用户提出诸如“撰写PRD”、“梳理该功能的规范”、“定义X的需求”或“我需要记录我们要开发的内容”等需求的场景。

Context Required

所需背景信息

From startup-context: company stage, target customer segments, current product state, team size, technical constraints.
From the user: the feature or initiative to spec, known user problems it addresses, any prior research or customer feedback, desired timeline, and scope preference (lightweight vs. full PRD).

创业公司背景： 公司阶段、目标客户群体、当前产品状态、团队规模、技术约束。
用户提供信息： 要梳理规范的功能或举措、其解决的已知用户问题、任何前期研究或客户反馈、期望时间线，以及范围偏好（轻量型 vs 完整版PRD）。

Workflow

工作流程

Clarify scope level -- Ask whether this needs a lightweight PRD (early-stage exploration, 2-3 pages) or a full PRD (committed initiative, 5-8 pages). Default to lightweight if the company is pre-product-market-fit.
Gather inputs -- Collect the problem statement, target users, any existing research, success criteria, and known constraints. Identify key contacts and their roles.
Draft the 8-section PRD -- Write each section sequentially using the template below. Use accessible language suitable for a broad audience including engineering, design, and leadership.
Flag assumptions -- Explicitly list key assumptions underlying each section. For each, state what evidence supports it and what would invalidate it.
Review and refine -- Present the draft, invite feedback, and iterate on specific sections. State the PRD version and last-updated date.

明确范围层级 —— 询问用户需要的是轻量型PRD（早期探索阶段，2-3页）还是完整版PRD（已确定的举措，5-8页）。如果公司尚未达成产品-市场匹配（PMF），默认采用轻量型。
收集输入信息 —— 收集问题陈述、目标用户、现有研究成果、成功标准以及已知约束条件。确定关键联系人及其角色。
撰写8节式PRD —— 按照下方模板依次撰写每个章节。使用通俗易懂的语言，确保适合工程师、设计师和管理层等广泛受众阅读。
标记假设条件 —— 明确列出每个章节背后的关键假设。针对每个假设，说明支持它的证据以及会推翻它的情况。
审核与优化 —— 提交草稿，收集反馈，并针对特定章节进行迭代更新。标注PRD版本和最后更新日期。

Output Format

输出格式

A structured PRD document with 8 sections:

包含8个章节的结构化PRD文档：

Section Template

章节模板

Summary -- 2-3 sentence overview of what is being built and why it matters. Write for a broad audience.
Contacts -- Key stakeholders with their roles and relevant context about their involvement.
Background -- Context on the problem space: why now, what changed, what enables this initiative. Include competitive context on how others handle the same problem.
Objective -- Goals, business and customer benefits, and strategic alignment. Define SMART success metrics tied to OKRs. Use the format: "Enable [user segment] to [action] resulting in [measurable outcome]."
Market Segment(s) -- Define target users by problems and needs, not demographics. Describe primary and secondary segments with size estimates.
Value Proposition(s) -- Map customer jobs addressed, gains provided, and pain points eliminated. Show competitive differentiation using frameworks like Value Curve analysis.
Solution -- Feature descriptions, UX/prototypes, wireframes, user flows, and technology details when relevant. Include out-of-scope items explicitly. Document assumptions. Enumerate at least 5 edge cases.
Release -- Phased rollout plan using relative timeframes (not exact dates). Define MVP vs. future iterations, feature flags, rollback criteria, and review checkpoints.

For lightweight PRDs, sections 2, 3, and 8 can be condensed to 2-3 sentences each.

摘要 —— 用2-3句话概述要开发的内容及其重要性。面向广泛受众撰写。
联系人 —— 关键利益相关者及其角色，以及他们参与的相关背景。
背景 —— 问题领域的背景：为何此时推进、发生了哪些变化、哪些因素支撑该举措。包括竞品在处理同一问题时的相关情况。
目标 —— 目标、业务与客户收益，以及战略对齐情况。定义与OKRs绑定的SMART成功指标。采用格式：“使[用户群体]能够[执行操作]，从而实现[可衡量的结果]。”
市场细分 —— 根据用户的问题和需求而非人口统计特征定义目标用户。描述主要和次要细分群体，并给出规模估算。
价值主张 —— 梳理所解决的用户任务、提供的收益以及消除的痛点。使用价值曲线分析等框架展示竞争差异化。
解决方案 —— 功能描述、用户体验/原型、线框图、用户流程，以及相关的技术细节。明确列出不属于范围的内容。记录假设条件。列举至少5个边缘案例。
发布计划 —— 使用相对时间范围（而非具体日期）的分阶段推出计划。定义MVP与未来迭代版本、功能开关、回滚标准以及审核检查点。

对于轻量型PRD，第2、3、8章节可简化为各2-3句话。

Frameworks & Best Practices

框架与最佳实践

Problem before solution. Spend 40% of the document on sections 1-5 (the "why") before touching section 7 (the "what"). A PRD that jumps to the solution is a spec, not a PRD.
One objective, not five. A PRD with multiple objectives is multiple PRDs. Split them. Each PRD should have a single primary metric it moves.
Market segments defined by needs. Describe who this is for based on the problems they face and jobs they hire the product to do, not by demographics or firmographics alone.
Value Proposition clarity. For each segment, explicitly state the customer jobs addressed, gains provided, and pains eliminated. Use the Value Curve to show where you differentiate from competitors.
Data-driven specificity. Replace vague language with specific numbers. "Improve retention" is not a metric; "Increase D7 retention from 25% to 35% within 8 weeks of launch" is.
Scope creep guard. Explicitly list what is NOT in scope. Revisit the out-of-scope list when stakeholders propose additions.
Relative timeframes over dates. Use phases and relative windows rather than exact calendar dates. This prevents false precision and allows flexibility.
Assumption tracking. List the top 3 assumptions underlying the PRD. For each, state supporting evidence and what would invalidate it.
Audience awareness. Engineers need technical constraints and edge cases. Designers need user flows and personas. Executives need the summary and metrics. Write for all three in a single document.
Living document. State the PRD version and last-updated date. PRDs that never change were never read.
Lightweight PRD triggers: pre-PMF exploration, hackathon projects, internal tools, experiments with <2 week timelines.
Full PRD triggers: cross-team initiatives, features with external dependencies, anything touching payments or compliance.

先问题后解决方案。在触及第7章（“是什么”）之前，将文档40%的篇幅用于第1-5章（“为什么”）。直接跳到解决方案的文档是规格说明，而非PRD。
单一目标，而非多个。包含多个目标的PRD实际上是多个PRD，应拆分。每个PRD应对应一个核心指标。
按需求定义市场细分。根据用户面临的问题和他们雇佣产品完成的任务来描述目标用户，而非仅依赖人口统计或企业统计特征。
价值主张清晰化。针对每个细分群体，明确说明所解决的用户任务、提供的收益以及消除的痛点。使用价值曲线展示与竞品的差异化之处。
数据驱动的精准性。用具体数字替代模糊表述。“提升留存率”不是指标；“在上线后8周内将7日留存率从25%提升至35%”才是。
防范范围蔓延。明确列出不在范围内的内容。当利益相关者提出新增需求时，重新审视该列表。
相对时间范围优先于具体日期。使用阶段和相对窗口而非精确的日历日期。这避免了虚假的精准性，同时保留灵活性。
假设跟踪。列出PRD背后的3个核心假设。针对每个假设，说明支持证据以及会推翻它的情况。
受众意识。工程师需要了解技术约束和边缘案例。设计师需要用户流程和用户画像。高管需要摘要和指标。在同一文档中兼顾这三类受众的需求。
活文档。标注PRD版本和最后更新日期。从未修改过的PRD等于没人阅读过。
轻量型PRD触发场景：未达成PMF的探索阶段、黑客松项目、内部工具、周期<2周的实验。
完整版PRD触发场景：跨团队举措、存在外部依赖的功能、涉及支付或合规的任何内容。

Related Skills

Examples

示例

Example 1: Lightweight PRD prompt

示例1：轻量型PRD提示词

User: "We need a PRD for adding Slack notifications to our project management tool."

Good output excerpt:

Summary: Add configurable Slack notifications so that teams using ProjectFlow are alerted to task updates, mentions, and deadline changes without leaving their primary communication tool. This addresses the #1 feature request from our Q3 customer survey (38% of respondents).

Objective: Enable team leads on paid plans to receive real-time project updates in Slack, resulting in a 20% reduction in average response time to task assignments within 6 weeks of launch.

Market Segment: Teams of 10+ coordinating across tools, whose primary pain is context-switching between project management and communication platforms.

Out of scope: Microsoft Teams integration, custom notification templates, Slack bot commands.

用户：“我们需要一份为项目管理工具添加Slack通知功能的PRD。”

优质输出节选：

摘要： 添加可配置的Slack通知功能，让使用ProjectFlow的团队无需离开主要沟通工具即可收到任务更新、提及提醒和截止日期变更通知。这是我们Q3客户调研中排名第一的功能需求（38%的受访者提出）。

目标： 让付费版的团队负责人能够在Slack中接收实时项目更新，从而在上线后6周内将任务分配的平均响应时间缩短20%。

市场细分： 规模10人以上、跨工具协作的团队，他们的核心痛点是在项目管理和沟通平台之间切换上下文。

非范围内容： Microsoft Teams集成、自定义通知模板、Slack机器人命令。

Example 2: Full PRD prompt

示例2：完整版PRD提示词

User: "Write a full PRD for our new self-serve onboarding flow. We're losing 60% of signups before they complete setup."