/prd-writer

name: memstack-product-prd-writer
description: "Use this skill when the user says 'PRD', 'product requirements', 'requirements document', or needs a complete engineering-ready PRD with problem statement, personas, MoSCoW features, and success metrics. Do NOT use for single feature specs or user story backlogs."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

PRD Writer: Writing product requirements document...

*Generates a complete engineering-ready PRD with problem statement, user personas, functional and non-functional requirements, MoSCoW prioritization, success metrics, and implementation timeline.*

Activation

When this skill activates, output:

`PRD Writer: Writing product requirements document...`

Then execute the protocol below.

Context Guard

| Context | Status | |---------|--------| | User says "PRD", "product requirements", "requirements document" | ACTIVE | | User wants a full product spec for engineering handoff | ACTIVE | | User is planning a new product or major feature set | ACTIVE | | User wants a spec for ONE feature | DORMANT: use Feature Spec | | User wants user stories for sprint planning | DORMANT: use User Story Generator |

Common Mistakes

| Mistake | Why It's Wrong | |---------|---------------| | "Start with the solution" | Start with the problem. Requirements without clear problems lead to building the wrong thing. | | "List every possible feature" | A PRD with 50 features is a wish list, not a plan. MoSCoW forces hard trade-offs. | | "Skip non-functional requirements" | Performance, security, and scalability are invisible until they break. Spec them upfront. | | "No success metrics" | Without measurable outcomes, you can't tell if the product succeeded. Define metrics before building. | | "Write it alone" | PRDs need input from engineering, design, and stakeholders. Write the draft, then review together. |

Protocol

Step 1: Gather Product Context

If the user hasn't provided details, ask:

> 1. **Product name**: what are you building? > 2. **Problem statement**: what problem does this solve? For whom? > 3. **Target users**: who are the primary and secondary users? > 4. **Business context**: why now? What's the opportunity? > 5. **Scope**: is this a new product, a major feature set, or a v2? > 6. **Constraints**: timeline, budget, team size, tech stack?

Step 2: Write Problem Statement

**Problem statement template:**

## Problem Statement

### The Problem
[Target users] struggle with [specific problem].

Currently, they [workaround or current behavior], which results in
[negative consequences: wasted time, lost revenue, frustration, errors].

### Evidence
- [Data point 1: user research, support tickets, survey results]
- [Data point 2: market data, competitor traction, industry trends]
- [Data point 3: internal metrics showing the gap]

### Impact
If unsolved, this problem costs [users/business] approximately
[quantified impact: time, money, churn rate, opportunity cost].

### Opportunity
By solving this problem, we can [positive outcome for users]
and [positive outcome for the business: revenue, retention, growth].

**Problem statement rules:**

• Be specific, "Users struggle with X" not "The experience could be better"
• Include evidence: data, quotes, or research that proves the problem exists
• Quantify the impact: makes prioritization decisions easier
• Separate the problem from the solution (no feature names here)

Step 3: Define User Personas

Create 2-3 personas (no more):

**Persona template:**

### Persona: [Name]: [Role/Title]

**Demographics:** [Age range, job title, company size, tech savviness]

**Goals:**
1. [Primary goal, what they're trying to achieve]
2. [Secondary goal]

**Pain points:**
1. [Frustration 1, related to the problem statement]
2. [Frustration 2]
3. [Frustration 3]

**Current behavior:**
- Currently uses [tool/process] to [accomplish task]
- Spends [X hours/week] on [manual process]
- Workaround: [How they hack around the limitation]

**Success criteria:**
- This persona succeeds when they can [measurable outcome]

**Quote:** "[A sentence that captures their frustration in their own words]"

**Persona rules:**

• Primary persona: The person the product is primarily designed for (gets priority in trade-offs)
• Secondary persona: Benefits from the product but doesn't drive design decisions
• Anti-persona: Who this product is NOT for (prevents scope creep)

Step 4: List Requirements (MoSCoW)

**Functional requirements:**

| ID | Requirement | Priority | Persona | Notes | |----|------------|----------|---------|-------| | FR-001 | [User can do X] | Must | [Persona] | [Context] | | FR-002 | [System does Y when Z] | Must | [Persona] | [Context] | | FR-003 | [User can configure W] | Should | [Persona] | [Context] | | FR-004 | [System supports V] | Could | [Persona] | [Context] | | FR-005 | [User can do U] | Won't (this version) | [Persona] | [Context] |

**MoSCoW definitions:**

| Priority | Meaning | Rule of Thumb | |----------|---------|--------------| | **Must** | Product doesn't work without it | 60% of effort | | **Should** | Important but not blocking launch | 20% of effort | | **Could** | Nice to have, include if time allows | 15% of effort | | **Won't** | Explicitly out of scope for this version | 5% (spec only, don't build) |

**Non-functional requirements:**

| ID | Category | Requirement | Target | |----|----------|------------|--------| | NFR-001 | Performance | Page load time | <2 seconds (p95) | | NFR-002 | Performance | API response time | <500ms (p95) | | NFR-003 | Scalability | Concurrent users | [X] users | | NFR-004 | Availability | Uptime SLA | 99.9% | | NFR-005 | Security | Authentication | [Method: OAuth, JWT, etc.] | | NFR-006 | Security | Data encryption | At rest + in transit | | NFR-007 | Accessibility | WCAG compliance | Level AA | | NFR-008 | Compatibility | Browser support | [List of