Pm Prd

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

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

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.

# 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.

Common PRD anti-patterns

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