What it does

Creates product requirements documents through structured interviews instead of template-filling. Separates product decisions (what and why) from engineering decisions (how), producing focused specs that do not prescribe implementation.

The pattern

The core rule: zero technical content in the PRD. No database schemas, no API designs, no architecture diagrams. The PRD defines the problem, the users, the outcomes, and the constraints. Engineering figures out the rest.

Five interview rounds:

1. Problem space. What problem exists? Who has it? How do they cope today? What is the cost of the status quo?

2. Users and use cases. Who are the distinct user types? What does each one need to accomplish? Map the primary workflows as user stories, not system flows.

3. Success metrics. What number changes if this works? Define exactly one primary metric and up to three supporting metrics. If you cannot name a metric, the project is not ready for a PRD.

4. Requirements and acceptance criteria. What must be true for this to ship? Write acceptance criteria as testable statements: "A user can complete X in under Y seconds" not "the system should be fast."

5. Risks and open questions. What could go wrong? What do we not know yet? What assumptions are we making? Listing these explicitly prevents them from becoming surprises later.

Two tiers based on project scope:

• Lightweight (6 sections). Problem, users, requirements, success metrics, scope boundaries, open questions. Covers most projects.
• Full (12 sections). Adds competitive context, phased rollout plan, data requirements, accessibility needs, legal/compliance, and sunset criteria. Use for cross-system or high-risk projects.

Formatting rules: Delete sections you do not use. No "TBD" placeholders. If a section cannot be filled, either remove it or flag it as a blocker that must be resolved before work begins.

Key decisions

Interview over template. Templates encourage filling in boxes. Interviews force you to think through each question with a specific project in mind. The conversation surfaces assumptions that templates miss.

No technical content. Mixing product and engineering concerns in one document creates confusion about who owns what. Product owns the PRD. Engineering owns the technical design doc. Keep them separate.

Delete unused sections. A PRD with 8 "TBD" sections signals that the project is not ready, but in practice people just skip past them. Removing empty sections makes the document honest about what is known and what is not.

When to use it

Before starting any project that involves more than one person or more than one week of work. The interview process takes 30-60 minutes and prevents weeks of building the wrong thing. Skip it for bug fixes, one-day tasks, and pure technical debt work.