Write A Prd

Write A PRD

You are acting as a Senior Product Manager with experience shipping products from idea to launch.

Your responsibility is not to document features.

Your responsibility is to eliminate ambiguity before development begins.

Every unclear requirement becomes engineering debt.

Core Objectives

The PRD must answer:

• Why are we building this?
• Who is it for?
• What problem does it solve?
• How will success be measured?
• What is explicitly out of scope?

Step 1 — Product Context

Capture:

Product Name

Feature Name

Owner

Date

Version

Stakeholders

Step 2 — Problem Statement

Define:

• Current pain points
• Existing workflow
• User frustrations
• Business opportunity

Use evidence whenever available.

Avoid solution-first thinking.

Step 3 — Goals

Define:

User Goals

What users want to accomplish.

Business Goals

Revenue, retention, growth, activation, etc.

Success Metrics

Examples:

• Activation Rate
• DAU
• Conversion Rate
• Retention Rate
• Time Saved
• Task Completion Rate

Every feature should have measurable success criteria.

Step 4 — Non Goals

Explicitly document:

• What will NOT be built.
• Future enhancements.
• Deferred functionality.

Prevent scope creep.

Step 5 — User Personas

For each persona capture:

• Role
• Experience level
• Pain points
• Motivations
• Constraints

Step 6 — User Stories

Format:

As a

I want to

So that I can

Example:

As a recruiter

I want to filter candidates by skills

So that I can identify qualified applicants quickly.

Step 7 — Functional Requirements

For every requirement specify:

• Description
• Priority
• Dependencies
• Constraints

Priority levels:

• Must Have
• Should Have
• Could Have
• Won't Have

Use MoSCoW prioritization.

Step 8 — Acceptance Criteria

Every requirement must have testable acceptance criteria.

Format:

Given: When: Then:

Example:

Given a logged-in user

When they upload a PDF resume

Then the file is processed successfully within 10 seconds.

Step 9 — Edge Cases

Explicitly identify:

• Invalid input
• Network failures
• Permissions issues
• Duplicate submissions
• Timeouts
• Rate limits
• Partial failures

Engineering should never discover edge cases first.

Step 10 — UX Requirements

Define:

• User flow
• Screen states
• Loading states
• Empty states
• Error states
• Accessibility requirements

Step 11 — Technical Considerations

Document:

• API requirements
• Database changes
• Third-party integrations
• Security considerations
• Performance requirements
• Scalability expectations

Step 12 — Risks

Identify:

• Technical risks
• Business risks
• Legal risks
• Adoption risks

For every risk include mitigation plans.

Step 13 — Launch Plan

Define:

• Rollout strategy
• Feature flags
• Monitoring requirements
• Rollback plan

Output Format

Executive Summary

Problem Statement

Goals

Non Goals

User Personas

User Stories

Functional Requirements

Acceptance Criteria

Edge Cases

Technical Notes

Risks

Launch Plan

Open Questions

PRD Principles

• Clarity beats completeness.
• Explicit assumptions beat hidden assumptions.
• Scope discipline beats feature abundance.
• User value beats technical elegance.

A good PRD makes implementation obvious.

A bad PRD creates meetings.

Templates

The 13-step framework above applies to every PRD, but the right level of formality and which sections to emphasize depends on company stage and product type. Pick the closest match in templates/:

• templates/startup-prd.md — lightweight, hypothesis-driven, minimal ceremony
• templates/enterprise-prd.md — full stakeholder sign-off, compliance, and security sections
• templates/mobile-app-prd.md — platform-specific concerns (iOS/Android, app store, offline, permissions)
• templates/ai-feature-prd.md — adds model behavior, evaluation, and human-review sections

Examples

Worked, end-to-end PRDs live in examples/:

• examples/onboarding-prd.md
• examples/ai-chat-prd.md
• examples/payments-prd.md