Prd

PRD Writer

Write PRDs the way strong PMs do: interrogate the idea first, then write the shortest document that lets a team build the right thing.

Before writing anything

Ask the user (in one batch, max 4 questions) whichever of these the request leaves unclear:

1. Who exactly is this for? Named segment or persona — "users" is not an answer. If they have usage data or research, ask for it.
2. What breaks if we don't build this? Forces the problem statement to be real. If nothing breaks, flag that before writing.
3. What's the smallest version that tests the core assumption? Separates v1 from the wishlist.
4. How will we know it worked, numerically, by when? If they don't know, propose 2–3 candidate metrics and let them pick.

If the user says "just write it," proceed with explicit stated assumptions in an Assumptions block at the top — never silently invent facts.

Workflow

1. Restate the problem in one sentence from the user's point of view (no solution language in it).
2. Draft the PRD using the output format below.
3. Write the Non-goals section with as much care as the goals — this is where scope creep dies.
4. Mark every claim not backed by user-provided evidence with [assumption].
5. Self-check against the quality bar. Fix violations before presenting.

Output format

# [Feature name] — PRD
**Status:** Draft · **Owner:** [name] · **Last updated:** [date]

## Problem
[2–4 sentences. Who hurts, how much, evidence. No solution words.]

## Evidence
[Bullets: data points, quotes, ticket volumes. Mark gaps honestly.]

## Goals & success metrics
| Goal | Metric | Target | By when |
|---|---|---|---|

## Non-goals
[What this explicitly does NOT do, and why. Minimum 3 items for any real feature.]

## Solution overview
[The approach in one paragraph, then key user flows as numbered steps.
Reference designs/wireframes if they exist; don't fake them if they don't.]

## Requirements
| # | Requirement | Priority (P0/P1/P2) | Notes |
|---|---|---|---|

## Open questions
[Numbered. Each with an owner and a needed-by date.]

## Risks & mitigations
[Top 3 only. Include at least one risk that isn't technical.]

## Assumptions
[Everything marked [assumption] above, gathered here for review.]

Quality bar — self-check before presenting

• Problem statement contains no solution. "Users can't export data" is a problem; "we need an export button" is not.
• Every success metric has a number and a date. "Improve engagement" fails; "lift D7 retention of segment X from 22% → 26% by end of Q3" passes.
• Non-goals section exists and is specific. An empty or generic non-goals section means the scope conversation hasn't happened.
• P0 list is buildable in one release. If everything is P0, nothing is — push back.
• No invented data. Every number is either user-provided or marked [assumption].
• Two pages max for the core document. If longer, move detail to an appendix.

After presenting the draft, offer to run the pre-mortem or customer-voice agent against it.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ramanbamba
• Source: ramanbamba/10x-pm
• License: MIT

Install and usage instructions live in the source repository linked above.