product-prd

name	product-prd
description	Interview-first PRD skill with integrated product validation. Use when the user asks to write, refine, review, or structure a PRD / 产品需求文档, make a product decision ("要不要做这个"), plan a new feature, or evaluate a product idea. Triggers: "写 PRD", "做需求文档", "要不要做XX", "写个 PRD", "产品决策", "新功能规划", "市场分析", "优化这份 PRD", "把 MRD 转成 PRD", "先访谈再写需求".

Product PRD

v2.0 — Interview-first PRD with product validation gate.

Combines structured PM interview methodology with product validation forcing questions. Interview first, validate demand, draft second.

---

Entry Routing

Determine which path the user needs before starting:

Entry scenario	Handling
Product decision ("要不要做XX", "有个想法")	Run Product Validation (Phase 0) first, then interview if validated
Write PRD from scratch ("写 PRD", "做需求文档")	Full interview workflow
Improve or review existing PRD	Read quality-rubric.md, diagnose, supplement-interview gaps
Convert MRD / BRD / brief → PRD	Extract confirmed decisions, interview for missing details
Derive from research / competitive analysis	Summarize inputs, confirm with user, interview for scope

If the user's intent is ambiguous, ask which path they want.

---

Phase 0: Product Validation (for Product Decision entry)

When the user is exploring whether to build something — not yet committed to building it — run these 6 forcing questions before entering the full PRD interview. These questions expose fatal assumptions early.

Q1: Demand Reality

"Who specifically needs this? Not 'developers' or 'businesses.'
Name the person. What is their job title? What did they do
in the last 48 hours that made them wish this existed?"

Testing: Does real demand exist, or is this a solution looking for a problem?

Red flags: "Everyone could use this" / Cannot name a specific person / Pain is theoretical.

Q2: Status Quo

"What do they do TODAY to solve this problem? How much time/money
does the current solution cost them? Why haven't they switched
to something better already?"

Testing: Is the pain acute enough to drive behavior change?

Red flags: "There's nothing out there" / "They use spreadsheets" / Cannot describe switching cost.

Q3: Desperate Specificity

"If this product only worked for ONE specific use case,
what would that use case be? Describe it in one sentence.
Now: would that alone be worth paying for?"

Testing: Can the idea survive radical scope reduction?

Red flags: Cannot narrow to one use case / Narrow version is not independently valuable.

Q4: Narrowest Wedge

"What is the smallest possible version that delivers real value?
Not an MVP with 20 features. The single thing you could build
in a weekend that someone would use on Monday."

Testing: Can you ship something useful FAST?

Red flags: "We need X, Y, and Z before it's useful" / Smallest version is still 3 months.

Q5: Observation Over Opinion

"Have you seen someone struggle with this problem firsthand?
Not 'I imagine people struggle' — have you WATCHED someone
fail at this? What happened?"

Testing: Is this insight based on observation or imagination?

Red flags: "I assume..." / No first-hand observation / Pain inferred from articles.

Q6: Future-Fit

"In 3 years, will AI, market changes, or platform shifts
make this problem disappear on its own? If the problem still
exists in 3 years, will your solution still be the right shape?"

Testing: Is this a durable opportunity or a timing window?

Red flags: AI could trivially solve this by next year / Depends on a fragile platform.

Validation Verdict

After the 6 questions, produce a validation summary:

Verdict	Criteria	Next Step
VALIDATED	Strong answers to Q1, Q2, Q5; clear wedge (Q3, Q4); durable (Q6)	Proceed to full PRD interview
CONDITIONAL	Some signals but key questions unanswered or weak	Log concerns, proceed with assumptions flagged
NOT VALIDATED	Multiple red flags, no observed demand, no clear wedge	Recommend parking. "The demand signal is not strong enough. Talk to 3 potential users first."

For Strategic-size requirements, Product Validation is mandatory. For all other sizes, it is recommended when the user's intent includes "要不要做".

---

Workflow (Full PRD Interview)

Follow this sequence. Do not skip to drafting unless the user explicitly provides validated inputs.

1. Confirm the task is PRD-like and determine the entry path.
2. Ask whether to use the built-in default template or a custom template. Default: use built-in default-prd-template.md.
3. Classify requirement size and choose interview depth.
4. Run structured interview following pacing rules below.
5. After interview, produce 需求理解摘要 and get user confirmation.
6. Propose requirement priority (MoSCoW or RICE).
7. Draft PRD against the template. Read default-prd-template.md or user's custom template.
8. Run quality gate. Read quality-rubric.md and prd-antipatterns.md.
9. Present draft with self-assessment summary and 风险 / 待确认 / 后续动作 section.
10. Enter revision loop.

---

Interview Pacing Rules

The 3-Question Rule

• Each round: no more than 3 questions, all logically related to one theme.
• Give each round a theme label: 【第3轮：用户场景与规模】.
• End each round with a brief synthesis sentence.
• Unlimited rounds — continue until all critical areas covered.

Skip and Track

• If user cannot answer now, mark as 暂时跳过 and move on.
• Maintain a Skipped Questions Tracker. Re-introduce naturally every 3-4 rounds.
• Before requirement summary, present all remaining skipped questions for final resolution.
• Unresolved questions appear in PRD as 待确认.

Answer Quality Assessment

• Vague or overly brief answers get follow-ups:
  • Narrowing: 你指的是 A 还是 B？
  • Concrete: 能举一个实际场景吗？
  • Boundary: 这个规则在 [边界情况] 下也成立吗？
• If user requests speed, switch to rapid mode: state assumptions, mark clearly.

Structured Interview Record

Maintain a running 需求要素表 updated after each round:

【需求要素表】（第 N 轮后更新）

已确认事项：
- [事项]（来源：第X轮）

假设事项：
- [事项]（假设原因：[reason]）

待确认事项：
- [问题]（阻塞原因：[reason]，建议确认人：[who]）

已解决的矛盾：
- [矛盾]（结论：[resolution]，确认于第X轮）

跳过的问题：
- [问题]（跳过原因：[reason]，计划在第X轮回带）

---

Interview Depth Selection

Read interview-depth.md for the full question bank.

Size	Rounds	Questions	When to Use
Tiny	2-3	5-8	Copy changes, single-rule updates
Small	3-5	8-14	One feature, clear ownership
Medium	5-8	14-22	Multi-page or multi-role features
Large	8-12	22-30	Platform features, migrations, monetization
Strategic	10+	Open	0-to-1, business model changes. Phase 0 mandatory.

When uncertain, bias one level deeper.

---

Core Interview Frame

Every interview covers these lenses. Read interview-depth.md for detailed question banks. For requirement-type-specific questions, read interview-by-type.md.

Product Three Questions

1. What is the real root goal?
2. Who are the target users, what do they need, how large is the population?
3. What solution is proposed, why this one, what is the ROI?

5W2H

• Why: business driver, user pain, urgency, opportunity cost
• What: scope, non-scope, success criteria, acceptance bar
• Who: personas, roles, stakeholders, internal teams
• When: milestone, dependencies, temporal constraints
• Where: platform, scenario, touchpoints, entry/exit points
• How: user flow, business rules, permissions, exception handling
• How much: value, effort, cost, scale, ROI, operational burden

Strong-PM Additions

Weave into relevant interview rounds:

• problem framing: current state, why now, evidence quality, assumptions
• anti-goals: what this should NOT solve
• alternatives: at least one rejected option and why
• tradeoffs: speed vs quality, short vs long term
• dependency map: design, eng, data, ops, legal, finance, vendor
• risk register: implementation, adoption, abuse, support, data risk
• stakeholder alignment: surface conflicts, force prioritization
• launch strategy: dark launch, whitelist, phased rollout, experiment, fallback
• measurement plan: north-star metric, guardrail metrics, instrumentation
• operational readiness: support SOP, enablement, monitoring, alerting
• decision log: fixed, assumed, open
• de-scope logic: what to cut if time slips
• sunset / migration plan: coexistence and off-ramp for replaced flows
• compliance and trust: privacy, permission, audit, content moderation

---

Conflict Resolution

When contradictory information across rounds:

1. Quote the earlier statement, point out the contradiction.
2. Ask user to confirm which version is correct.
3. Update requirement summary, mark in decision log.

When stakeholders have conflicting priorities:

1. List each position clearly.
2. Ask user to rank priorities.
3. Document rejected positions as anti-goals.

---

Before Drafting

Output a 需求理解摘要:

• objective
• target users
• main scenario
• proposed solution direction
• scope / out-of-scope
• module list with priority (Must / Should / Could / Won't)
• success metrics
• dependencies
• open questions
• explicit assumptions
• decision log

Get user confirmation before drafting.

---

Quality Gates

Read quality-rubric.md and prd-antipatterns.md.

Gate 1: Pre-Draft

Verify requirement summary covers all essential inputs. Missing items → supplement-ask or mark TBD.

Gate 2: Post-Draft

1. Quality rubric self-assessment. Score below 3 → flag with recommendation.
2. Anti-pattern scan. Replace detected anti-patterns before presenting.
3. Completeness check via prd-content-checklist.md.

Gate 3: Pre-Final

Output 产出物质量摘要: rubric scores, remaining 待确认, remaining assumptions, risk and follow-up.

---

Revision Loop

1. Ask user for feedback.
2. Classify: 事实修正 → update + change log | 范围变更 → re-interview | 表述优化 → rewrite.
3. Re-run quality gate on changed sections.
4. Repeat until user confirms final.

---

Drafting Rules

Read template-binding.md for template adaptation. Default: default-prd-template.md.

• Follow template headings and ordering exactly.
• Fill missing sections with TBD / Assumption / Not applicable.
• Write acceptance criteria in Given-When-Then format.
• Avoid generic PM filler. Read prd-antipatterns.md.

---

Non-Negotiables

• Never open with a full PRD draft.
• Never silently change template structure.
• Distinguish facts, assumptions, and recommendations. Always label which is which.
• If user gives incomplete inputs, draft with explicit assumptions and blocking-items list.

---

Output

Write PRD to docs/prds/{name}-prd.md (or location specified by user).

For product validation (Phase 0), write validation summary to docs/prds/{name}-validation.md.

---

Completion Status

Status	When
DONE	PRD produced, quality gates passed, user confirmed final
DONE_WITH_CONCERNS	PRD produced but key assumptions unvalidated
BLOCKED	Cannot proceed without research or stakeholder input
NEEDS_CONTEXT	User's domain requires more information
NOT_VALIDATED	Phase 0 verdict: demand not validated, recommend parking