PRD Write

Write a new PRD for a product, feature, or platform initiative through guided discovery. The skill drives a multi-phase conversation, anchors the document in your product context, and produces a publishable PRD or a draft.

When to use

• Starting a new feature or module
• Reworking or replatforming an existing product
• Scoping a new platform initiative before kicking off design or dev
• Drafting a PRD before a leadership or product review

For reviewing an existing PRD, use product-prd-review instead.

Input

A subject line as argument, e.g. "billing module rework", "new onboarding flow". If no argument: ask what the PRD is about.

Optional follow-up flags from the user:

• "from [URL]" → seed from an existing draft or brief
• "draft only" → output a local draft, do not publish
• "express" → run a condensed version (skip phases 2 and 5)

Workflow

Phase 1 — Frame the project

Ask the user, one question at a time when needed, otherwise group into a single message:

1. One-liner: in one sentence, what is this project?
2. Trigger: why now? (commercial pressure, competitive threat, user pain, technical debt, regulation)
3. Scope hint: feature, module, platform, full rework?
4. Stakeholders: who is the sponsor? Who decides go/no-go?
5. Deadline or window: any hard date (review, event, contract)?

Capture the answers as working notes. If the user is vague, push back once with a concrete prompt; do not loop.

Phase 2 — Load context

Read whatever product context the user can provide and keep it in working memory for the rest of the session. Skip in express mode.

• Company and product overview
• Product portfolio and modules
• Catalog or pricing reference
• Competitive landscape
• Team structure (sponsor, owners)

Search for prior art in the user's existing docs (wiki, knowledge base, notes): existing PRDs, briefs, post-mortems, or decisions touching the same module or flow.

If existing PRDs are found, read them. Decide: extend, replace, or fork. Tell the user what you found and confirm direction.

Phase 3 — Discovery (interactive)

Run a structured discovery dialog. Ask focused questions, group when possible. Stop when each section has enough material.

Grill mode (optional): by default, batch questions as above. Switch to grill mode when the user asks for it or when a section is hard (fuzzy problem, contested scope, ambiguous personas). In grill mode:

• Ask one question at a time, wait for the answer before the next.
• Always propose your own recommended answer with each question.
• Walk the decision tree by dependency (each answer opens the next branch), not the checklist in order.
• If the answer already exists in loaded context or docs, use it instead of asking.
• Actively challenge the loaded references: point out contradictions.
• Invent 2-3 edge scenarios to force precision on concept boundaries.

3.1 Problem statement

• What is the customer problem? Who feels it?
• What evidence do we have? (tickets, churn, NPS, sales feedback, lost deals, support load)
• How is it handled today? (workaround, manual ops, missing entirely)
• Quantified impact if known

3.2 Personas Identify every layer the product touches:

• Buyer / decision-maker persona: who pays or signs off?
• End-user persona: who actually uses it day to day?
• Internal user: support, sales, ops — if applicable

3.3 Goals and non-goals

• 3 to 5 outcome goals (not features)
• Explicit non-goals: what we will NOT do in this scope

3.4 Solution direction

• High-level approach (not detailed design yet)
• Alternatives considered and why rejected
• Key design principles

3.5 Success metrics Pick the framework that fits:

• NSM (North Star Metric) for platform or business-level initiatives
• AARRR for adoption funnels
• HEART for UX or engagement focus
• OKR for strategic alignment

Always include:

• A leading indicator (early signal, weeks)
• A lagging indicator (real outcome, quarters)
• Baseline value if available

3.6 User stories

• 3 to 8 core stories in As a [persona], I want [action], so that [outcome] format
• Mark each: must / should / could

Phase 4 — Draft the PRD

Write the PRD using the structure below. Be dense, factual, no filler.

# PRD — [Product / Feature Name]

**Author**: [Name]
**Status**: Draft / In review / Approved
**Date**: YYYY-MM-DD
**Sponsor**: [Name]
**Target date**: [date or quarter]

## 1. Executive summary
[3 to 5 lines. Problem, proposed solution, expected outcome, why now.]

## 2. Context and problem
### Problem
[What is broken, for whom, with evidence]

### Current state
[How it works today, why it's insufficient]

### Why now
[Trigger: commercial, competitive, technical, regulatory]

## 3. Personas
### Buyer / decision-maker
[Type, size, maturity, role in the flow]

### End-user
[Profile, context, expectations]

### Internal user (if applicable)
[Support, sales, ops]

## 4. Objectives
### Goals (outcomes)
- [Outcome 1]
- [Outcome 2]
- [Outcome 3]

### Non-goals
- [What we explicitly do NOT cover]

## 5. Solution
### Overview
[High-level approach]

### Design principles
- [Principle 1]
- [Principle 2]

### Alternatives considered
| Option | Pros | Cons | Verdict |
|--------|------|------|---------|
| ... | ... | ... | ... |

## 6. User stories
| # | Persona | Story | Priority |
|---|---------|-------|----------|
| US-1 | ... | As a... I want... so that... | Must |

## 7. Requirements
### Must
- [REQ-M-1] ...

### Should
- [REQ-S-1] ...

### Could
- [REQ-C-1] ...

## 8. Success metrics
### Framework
[NSM / AARRR / HEART / OKR + rationale]

### Indicators
| Metric | Type | Baseline | Target | Horizon |
|--------|------|----------|--------|---------|
| ... | Leading/Lagging | ... | ... | ... |

## 9. UX / Design
[Principles, key flows, references to mockups if any. Not detailed mockups.]

## 10. Technical considerations
- **Architecture**: [services impacted]
- **Data**: [model, migration, retention]
- **Performance / scale**: [SLO, expected load]
- **Security**: [auth, data classification, compliance]
- **Dependencies**: [teams, services, vendors]

## 11. Product / catalog fit
- **Module**: [where it sits in the product]
- **Pricing / packaging**: [model]
- **Impact on existing modules**: [list]

## 12. Go-to-market enablement
- **Communication**: [channels]
- **Training**: [support team, sales]
- **Documentation**: [help center articles, sales kit]

## 13. Rollout
- **Phase 1 — Beta**: [scope, users, duration]
- **Phase 2 — GA**: [criteria to ship]
- **Feature flag**: [yes/no, scope]
- **Rollback plan**: [how to pull back]

## 14. Risks
| Risk | Type | Severity | Mitigation |
|------|------|----------|------------|
| ... | Commercial/Tech/Coherence/Timing/Support | High/Medium/Low | ... |

## 15. Dependencies and assumptions
### Dependencies
- [team, service, decision]

### Assumptions
- [assumption + how we'll validate it]

## 16. Open questions
- [Question + owner + due date]

## 17. Timeline and milestones
| Milestone | Target date | Owner |
|-----------|-------------|-------|
| Kickoff | ... | ... |
| Design freeze | ... | ... |
| Beta | ... | ... |
| GA | ... | ... |

Phase 5 — Validate

Before publishing, run a self-check on the draft. Skip in express mode.

Quality gates:

• Problem is described with evidence, not anecdote
• All relevant personas are explicit (buyer, end-user, internal)
• Non-goals are listed
• At least one leading and one lagging metric, with baseline if available
• Product and pricing fit is covered
• Risks are scored, not just listed
• Open questions have owners and due dates

If 3+ gates fail, loop back to phase 3 with the user on the gaps.

Pre-mortem (recommended for high-stakes projects): Before locking the PRD, run a pre-mortem. Prompt yourself: "Assume this project has failed 6 months after launch. Write the post-mortem as if it already happened. List the top 3 most likely failure reasons, ordered by probability. Be specific and brutal — not generic risks but this project's real blind spots." Surface hidden assumptions and second-order effects. Feed the output back into section 14 (Risks) and section 15 (Assumptions), and flag anything new as an open question.

Phase 6 — Publish

Ask the user where to publish:

1. Team wiki / knowledge base (default for finalized PRDs)

   • Title format: PRD — [Product Name]
   • Return the URL

2. Local draft (for early WIP or draft only)

   • Filename: YYYY-MM-DD - PRD - [Product Name].md

3. Both — common case for projects that need iteration

After publishing, suggest next steps:

• Run product-prd-review on the freshly published PRD for a second pass
• Open a tracking epic linked to the PRD
• Schedule the kickoff or product review

Rules

• Be direct and dense. No filler, no AI slop.
• Never invent data. If a metric, baseline, or competitive insight is missing, mark it as an open question.
• A PRD is a contract for alignment, not a creative essay. Brevity wins.
• If a section has nothing meaningful to say, write "TBD" with an owner and a date, not filler.
• Quote real signals when available (analytics, existing docs, customer feedback).
• Stop and ask the user when a strategic call is needed (scope, sponsor, priority). Do not guess.