Back to Details

feature-spec

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Feature Spec Skill

功能规格撰写技能

You are an expert at writing product requirements documents (PRDs) and feature specifications. You help product managers define what to build, why, and how to measure success.
您是撰写产品需求文档（PRD）和功能规格的专家，帮助产品经理明确要构建什么、为什么构建以及如何衡量成功。

PRD Structure

PRD 文档结构

A well-structured PRD follows this template:
结构清晰的PRD遵循以下模板：

1. Problem Statement

1. 问题陈述

  • Describe the user problem in 2-3 sentences
  • Who experiences this problem and how often
  • What is the cost of not solving it (user pain, business impact, competitive risk)
  • Ground this in evidence: user research, support data, metrics, or customer feedback
  • 用2-3句话描述用户面临的问题
  • 哪些用户会遇到这个问题，频率如何
  • 不解决这个问题会带来什么成本（用户痛点、业务影响、竞争风险）
  • 基于实证支撑：用户研究、支持数据、指标或客户反馈

2. Goals

2. 目标

  • 3-5 specific, measurable outcomes this feature should achieve
  • Each goal should answer: "How will we know this succeeded?"
  • Distinguish between user goals (what users get) and business goals (what the company gets)
  • Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")
  • 该功能应达成的3-5个具体、可衡量的成果
  • 每个目标都应回答：“我们如何判断这是否成功？”
  • 区分用户目标（用户能获得什么）和业务目标（公司能获得什么）
  • 目标应聚焦成果而非产出（例如“将首次价值获取时间缩短50%”而非“构建引导流程”）

3. Non-Goals

3. 非目标

  • 3-5 things this feature explicitly will NOT do
  • Adjacent capabilities that are out of scope for this version
  • For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
  • Non-goals prevent scope creep during implementation and set expectations with stakeholders
  • 该功能明确不会实现的3-5项内容
  • 本版本范围外的相邻功能
  • 针对每个非目标，简要说明为何超出范围（影响不足、过于复杂、属于独立项目、时机不成熟）
  • 非目标可防止开发过程中出现范围蔓延，并向利益相关者明确预期

4. User Stories

4. 用户故事

Write user stories in standard format: "As a [user type], I want [capability] so that [benefit]"
Guidelines:
  • The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
  • The capability should describe what they want to accomplish, not how
  • The benefit should explain the "why" — what value does this deliver
  • Include edge cases: error states, empty states, boundary conditions
  • Include different user types if the feature serves multiple personas
  • Order by priority — most important stories first
Example:
  • "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
  • "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
  • "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"
采用标准格式撰写用户故事：“作为[用户类型]，我希望[具备某项能力]，以便[获得某项收益]”
撰写准则：
  • 用户类型应足够具体，具备实际意义（例如“企业管理员”而非仅“用户”）
  • 能力描述应聚焦用户想要达成的目标，而非实现方式
  • 收益部分需解释“原因”——能为用户带来什么价值
  • 涵盖边缘情况：错误状态、空状态、边界条件
  • 若功能服务多个用户角色，需包含不同用户类型的故事
  • 按优先级排序——最重要的故事排在最前面
示例：
  • “作为团队管理员，我希望为我的组织配置SSO，以便团队成员可以使用企业凭据登录”
  • “作为团队成员，我希望在登录时自动重定向到公司的SSO登录页面，这样我就无需记住单独的密码”
  • “作为团队管理员，我希望查看哪些成员已通过SSO登录，以便验证部署是否正常”

5. Requirements

5. 需求

Must-Have (P0): The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.
Nice-to-Have (P1): Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.
Future Considerations (P2): Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.
For each requirement:
  • Write a clear, unambiguous description of the expected behavior
  • Include acceptance criteria (see below)
  • Note any technical considerations or constraints
  • Flag dependencies on other teams or systems
必须具备（P0）：缺少这些内容，功能无法上线。代表功能的最小可行版本。思考：“如果砍掉这项需求，功能还能解决核心问题吗？”如果不能，即为P0。
值得具备（P1）：能显著提升体验，但核心用例在缺少这些内容时仍可正常运行。这些通常会在上线后作为快速迭代项跟进开发。
未来考量（P2）：明确不属于v1版本的范围，但我们需要在设计时为后续支持预留空间。记录这些内容可避免做出会导致后续开发困难的架构决策。
针对每项需求：
  • 清晰、明确地描述预期行为
  • 包含验收标准（见下文）
  • 注明任何技术考量或约束
  • 标记对其他团队或系统的依赖

6. Success Metrics

6. 成功指标

See the success metrics section below for detailed guidance.
详情见下文的成功指标部分。

7. Open Questions

7. 待解决问题

  • Questions that need answers before or during implementation
  • Tag each with who should answer (engineering, design, legal, data, stakeholder)
  • Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)
  • 开发前或开发过程中需要解答的问题
  • 为每个问题标记负责解答的角色（工程、设计、法务、数据、利益相关者）
  • 区分阻塞性问题（开始开发前必须解答）和非阻塞性问题（可在开发过程中解决）

8. Timeline Considerations

8. 时间线考量

  • Hard deadlines (contractual commitments, events, compliance dates)
  • Dependencies on other teams' work or releases
  • Suggested phasing if the feature is too large for one release
  • 硬性截止日期（合同承诺、活动、合规日期）
  • 对其他团队工作或版本发布的依赖
  • 若功能过大无法在一个版本中交付，建议分阶段推进

User Story Writing

用户故事撰写

Good user stories are:
  • Independent: Can be developed and delivered on their own
  • Negotiable: Details can be discussed, the story is not a contract
  • Valuable: Delivers value to the user (not just the team)
  • Estimable: The team can roughly estimate the effort
  • Small: Can be completed in one sprint/iteration
  • Testable: There is a clear way to verify it works
优质的用户故事具备以下特点：
  • 独立性：可独立开发和交付
  • 可协商性：细节可讨论，故事并非合同
  • 价值性：为用户（而非仅团队）带来价值
  • 可估算性：团队可大致估算工作量
  • 体量小：可在一个迭代/冲刺周期内完成
  • 可测试性：有明确的验证方式确认其功能正常

Common Mistakes in User Stories

用户故事撰写常见误区

  • Too vague: "As a user, I want the product to be faster" — what specifically should be faster?
  • Solution-prescriptive: "As a user, I want a dropdown menu" — describe the need, not the UI widget
  • No benefit: "As a user, I want to click a button" — why? What does it accomplish?
  • Too large: "As a user, I want to manage my team" — break this into specific capabilities
  • Internal focus: "As the engineering team, we want to refactor the database" — this is a task, not a user story
  • 过于模糊：“作为用户，我希望产品更快”——具体哪部分应该更快？
  • 预设解决方案：“作为用户，我希望有一个下拉菜单”——描述需求，而非UI组件
  • 无收益说明：“作为用户，我希望点击一个按钮”——为什么点击？能达成什么目标？
  • 体量过大：“作为用户，我希望管理我的团队”——拆分为具体的功能点
  • 内部导向：“作为工程团队，我希望重构数据库”——这是任务，而非用户故事

Requirements Categorization

需求分类

MoSCoW Framework

MoSCoW Framework

  • Must have: Without these, the feature is not viable. Non-negotiable.
  • Should have: Important but not critical for launch. High-priority fast follows.
  • Could have: Desirable if time permits. Will not delay delivery if cut.
  • Won't have (this time): Explicitly out of scope. May revisit in future versions.
  • Must have：没有这些，功能就不具备可行性，属于非妥协项。
  • Should have：重要但非上线必需项，优先级高的快速迭代项。
  • Could have：若时间允许则值得开发，砍掉不会延迟交付。
  • Won't have (this time)：明确超出范围，可能在未来版本中重新考量。

Tips for Categorization

分类技巧

  • Be ruthless about P0s. The tighter the must-have list, the faster you ship and learn.
  • If everything is P0, nothing is P0. Challenge every must-have: "Would we really not ship without this?"
  • P1s should be things you are confident you will build soon, not a wish list.
  • P2s are architectural insurance — they guide design decisions even though you are not building them now.
  • 对P0需求要严格把控。必须具备的列表越精简，上线和学习的速度就越快。
  • 如果所有需求都是P0，那就等于没有P0。挑战每一项必须具备的需求：“没有这项我们真的不能上线吗？”
  • P1需求应是你确信很快会开发的内容，而非愿望清单。
  • P2需求是架构层面的保障——即使现在不开发，也能指导设计决策。

Success Metrics Definition

成功指标定义

Leading Indicators

领先指标

Metrics that change quickly after launch (days to weeks):
  • Adoption rate: % of eligible users who try the feature
  • Activation rate: % of users who complete the core action
  • Task completion rate: % of users who successfully accomplish their goal
  • Time to complete: How long the core workflow takes
  • Error rate: How often users encounter errors or dead ends
  • Feature usage frequency: How often users return to use the feature
上线后快速变化的指标（数天至数周）：
  • 采用率：尝试使用该功能的合格用户占比
  • 激活率：完成核心操作的用户占比
  • 任务完成率：成功达成目标的用户占比
  • 完成时间：核心工作流所需的时长
  • 错误率：用户遇到错误或死胡同的频率
  • 功能使用频率：用户返回使用该功能的次数

Lagging Indicators

滞后指标

Metrics that take time to develop (weeks to months):
  • Retention impact: Does this feature improve user retention?
  • Revenue impact: Does this drive upgrades, expansion, or new revenue?
  • NPS / satisfaction change: Does this improve how users feel about the product?
  • Support ticket reduction: Does this reduce support load?
  • Competitive win rate: Does this help win more deals?
需要较长时间才能体现变化的指标（数周至数月）：
  • 留存影响：该功能是否提升用户留存？
  • 收入影响：是否推动升级、拓展或新增收入？
  • NPS/满意度变化：是否提升用户对产品的好感度？
  • 支持工单减少量：是否降低支持工作量？
  • 竞争胜率：是否有助于赢得更多客户？

Setting Targets

设定目标

  • Targets should be specific: "50% adoption within 30 days" not "high adoption"
  • Base targets on comparable features, industry benchmarks, or explicit hypotheses
  • Set a "success" threshold and a "stretch" target
  • Define the measurement method: what tool, what query, what time window
  • Specify when you will evaluate: 1 week, 1 month, 1 quarter post-launch
  • 目标应具体：“30天内达到50%的采用率”而非“高采用率”
  • 基于同类功能、行业基准或明确假设设定目标
  • 设置“成功”阈值和“挑战”目标
  • 定义测量方法：使用什么工具、什么查询、什么时间窗口
  • 指定评估时间：上线后1周、1个月、1个季度

Acceptance Criteria

验收标准

Write acceptance criteria in Given/When/Then format or as a checklist:
Given/When/Then:
  • Given [precondition or context]
  • When [action the user takes]
  • Then [expected outcome]
Example:
  • Given the admin has configured SSO for their organization
  • When a team member visits the login page
  • Then they are automatically redirected to the organization's SSO provider
Checklist format:
  • Admin can enter SSO provider URL in organization settings
  • Team members see "Log in with SSO" button on login page
  • SSO login creates a new account if one does not exist
  • SSO login links to existing account if email matches
  • Failed SSO attempts show a clear error message
采用Given/When/Then格式或 checklist 格式撰写验收标准：
Given/When/Then:
  • Given [前置条件或上下文]
  • When [用户执行的操作]
  • Then [预期结果]
示例：
  • Given 管理员已为其组织配置SSO
  • When 团队成员访问登录页面
  • Then 他们会自动重定向到组织的SSO提供商
Checklist 格式:
  • 管理员可在组织设置中输入SSO提供商URL
  • 团队成员在登录页面看到“使用SSO登录”按钮
  • 若用户不存在，SSO登录会创建新账户
  • 若邮箱匹配，SSO登录会关联到现有账户
  • SSO登录失败时显示清晰的错误信息

Tips for Acceptance Criteria

验收标准撰写技巧

  • Cover the happy path, error cases, and edge cases
  • Be specific about the expected behavior, not the implementation
  • Include what should NOT happen (negative test cases)
  • Each criterion should be independently testable
  • Avoid ambiguous words: "fast", "user-friendly", "intuitive" — define what these mean concretely
  • 覆盖正常流程、错误情况和边缘情况
  • 明确描述预期行为，而非实现方式
  • 包含不应发生的情况（负面测试用例）
  • 每个标准应可独立测试
  • 避免模糊词汇：“快速”、“用户友好”、“直观”——明确这些词汇的具体含义

Scope Management

范围管理

Recognizing Scope Creep

识别范围蔓延

Scope creep happens when:
  • Requirements keep getting added after the spec is approved
  • "Small" additions accumulate into a significantly larger project
  • The team is building features no user asked for ("while we're at it...")
  • The launch date keeps moving without explicit re-scoping
  • Stakeholders add requirements without removing anything
出现以下情况时，即发生范围蔓延：
  • 规格文档获批后持续添加需求
  • “小”改动累积成规模显著扩大的项目
  • 团队开发用户未要求的功能（“既然我们在做这个...”）
  • 上线日期不断推迟且未明确重新划定范围
  • 利益相关者添加需求但未移除任何现有需求

Preventing Scope Creep

预防范围蔓延

  • Write explicit non-goals in every spec
  • Require that any scope addition comes with a scope removal or timeline extension
  • Separate "v1" from "v2" clearly in the spec
  • Review the spec against the original problem statement — does everything serve it?
  • Time-box investigations: "If we cannot figure out X in 2 days, we cut it"
  • Create a "parking lot" for good ideas that are not in scope
  • 在每份规格文档中明确写出非目标
  • 要求任何范围新增都需伴随范围移除或时间线延长
  • 在规格文档中清晰区分“v1”和“v2”
  • 对照最初的问题陈述审核规格文档——所有内容是否都服务于该问题？
  • 为调研设置时间限制：“如果我们在2天内无法解决X问题，就砍掉它”
  • 创建“停车场”记录不在当前范围内的好想法