pm-prd — Generate a structured PRD

Part of the Personal Corp framework — running a one-person business through AI agents. Generate a delivery-ready Product Requirements Document from a feature description. Branches by product type — B2C, B2B, internal tool, platform — with each type emphasizing different modules. Includes a 10-item quality self-check that runs after generation.

Inputs

| Field | Required | Notes | |---|---|---| | Feature description | yes | What the feature does and what problem it solves; one sentence minimum | | Target user | no | Who it's for; inferred from the feature if not given | | Business goals | no | Expected business metrics (DAU, conversion, revenue, etc.) | | Product type | no | B2C / B2B / internal / platform; auto-detected if not given | | Constraints | no | Tech limits, deadlines, resource limits | | Depth | no | Outline (for review) / detailed (for development); default detailed |

If the user only says "write a PRD" with no feature, ask for the feature description. If they give feature + user + goals, go straight to generation.

Step 1 — Parse input and branch by product type

| Product type | PRD emphasis | Key differentiators | |---|---|---| | B2C | UX flow, growth metrics, A/B test plan | Heavy on interaction, heavy on data, write user journeys | | B2B | Permission model, multi-tenancy, SLA, integration APIs | Heavy on completeness, security, API contracts | | Internal tool | Operational efficiency, integration with existing systems, training cost | Heavy on practicality, light on visuals | | Platform | Multi-role interaction, supply-demand matching, ecosystem rules | Heavy on role separation, rules engine |

Auto-detection rules: mentions of "user / member / loyalty / marketplace" → B2C; "enterprise / SaaS / CRM / admin panel" → B2B; "internal / management system / ticketing" → internal tool; "platform / marketplace / two-sided" → platform.

B2B PRDs must additionally cover:

• Permission matrix (role × feature × data scope)
• Multi-tenant data isolation approach
• Integration interfaces with the customer's existing systems

Platform PRDs must additionally cover:

• Independent feature view per role (supplier / consumer / platform ops)
• Matching rules and ranking strategy
• Commission / take-rate / settlement rules

Step 2 — Structured requirement breakdown

Three-method feature decomposition:

1. User journey: trace the user's path from entry to goal completion; each node = one feature point
2. Role split: list every role involved (end user, admin, ops); each role's actions = one feature module
3. CRUD: for each core data object, walk through create / read / update / delete

For every feature module, fill:

• Feature description (one sentence)
• User story (As a {role}, I want to {action}, so that {value})
• Business rules (exhaustive — no "etc." or "other cases")
• Interaction (entry point → steps → success/failure feedback)
• Exception handling (timeouts, data anomalies, permission denied, edge cases)

Step 3 — Generate the PRD

Use this template. Comments next to each placeholder describe the fill logic.

markdown
# PRD: {feature name}

**Version:** v1.0
**Author:** {PM name, or [TBD]}
**Date:** {today}
**Status:** Draft

---

## 1. Background and Goals

### 1.1 Background
<!-- Answer three questions: why now? what happens if we don't? what changes if we do? -->
{problem state + user pain + why this is the right moment}

### 1.2 Target users
<!-- Use [role] + [trait] + [scenario]. Never write "all users". -->
| User role | Trait | Core need | Use scenario |
|---|---|---|---|

### 1.3 Business goals and success metrics
<!-- Each goal must be SMART — specific number + deadline. -->
| Goal | Metric | Target | Tracking method |
|---|---|---|---|

## 2. Requirement Overview
<!-- One paragraph, 30 words max, summarizing the core requirement. -->

## 3. Detailed Feature Design

### 3.1 {Module 1}
**Description:** {what it does}
**User story:** As a {role}, I want {action}, so that {value}
**Priority:** P0 (must launch) / P1 (strongly recommended) / P2 (nice-to-have)

**Business rules:**
1. {rule 1 — clear trigger condition + processing logic}
2. {rule 2}

**Interaction flow:**
<!-- Start at entry point, end at task completion, cover happy path + exception branches. -->
1. User enters from {entry}
2. {steps}
3. Success: {feedback}
4. Failure: {error message and handling}

**Exception handling:**
| Scenario | Handling | User-facing message |
|---|---|---|

(repeat format for each module)

## 4. Non-Functional Requirements
<!-- B2C → emphasize performance and experience; B2B → emphasize security and availability. -->
| Category | Requirement | Acceptance criterion |
|---|---|---|
| Performance | {e.g. page load time} | {e.g. < 2s} |
| Security | {e.g. data encryption} | {e.g. TLS 1.2+ in transit} |
| Compatibility | {browsers / devices} | {Chrome, Safari, mobile webview} |

## 5. Data Requirements (Analytics Events)
<!-- List every event to capture. Format: event name + trigger + attributes + purpose. -->
| Event | Trigger | Key attributes | Purpose |
|---|---|---|---|

## 6. Acceptance Criteria
<!-- At least 3 ACs per feature module, in Given-When-Then format. -->
| ID | Scenario | Given | When | Then |
|---|---|---|---|---|

## 7. Schedule
<!-- Break into design / dev / integration / launch. -->
| Phase | Estimate | Dependency | Risk |
|---|---|---|---|

## 8. Risks and Dependencies
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|

## Appendix
- Related documents
- Competitor references
- Design files

Step 4 — Quality self-check

Run this 10-point checklist after generating. Flag any failed item with a fix suggestion.

| # | Check | Pass criterion | |---|---|---| | 1 | Background not vague | Answers "why do this?" not just "we need to do this" | | 2 | Goals quantified | At least one numeric success metric | | 3 | Personas concrete | No "all users" / "everyone" | | 4 | Business rules exhaustive | No "etc.", "other cases", "and so on" | | 5 | Exception flows covered | Every feature has ≥2 exception scenarios | | 6 | Acceptance testable | Given-When-Then format used | | 7 | Analytics complete | All core action paths have events | | 8 | No tech implementation | PRD describes "what", not "how to build" | | 9 | Priorities assigned | Every module tagged P0/P1/P2 | | 10 | Schedule grounded | Estimate covers design + dev + test + integration |

Common PRD anti-patterns

| Anti-pattern | What it looks like | Fix | |---|---|---| | Gold-plating | 50 features in v1 | Split MVP / v1.1 / v2; v1 keeps 3-5 core features | | Fake requirement | "Users might want…" with no data | Tag every requirement with source: feedback / analytics / competitor / hypothesis | | Design overreach | PRD specifies button color, font size, layout | Describe info hierarchy and interaction logic only; visuals → designer | | Tech overreach | PRD specifies Redis, MySQL, framework choice | Describe perf requirements (e.g. "<2s") only; implementation → engineering | | Rule blackhole | "Per business rules" without listing them | Enumerate every rule's trigger, logic, edge values |

Red lines

1. PRD does not specify implementation — no DB type, language, framework
2. PRD does not replace design specs — no detailed UI layout, colors, sizes
3. No fabricated data — for any business data the user didn't provide (DAU, conversion), write [TBD]
4. No missing roles — for multi-role features, every role's perspective must be covered

When input is incomplete

• Just "write a PRD" with no requirement → ask for the feature description with an example
• One-sentence requirement ("build a marketplace") → produce an outline-level PRD framework, mark [needs input] on critical missing pieces
• Requirement too large → suggest splitting into multiple PRDs; agree on MVP scope first

Related skills

• /pm-user-stories — after PRD review, break features into developable User Stories
• /pm-competitive — run before PRD to gather competitor references
• /pm-prioritize — when multiple requirements compete, rank with RICE first