Memstack Product Prd Writer

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

Common Mistakes

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:

markdownCopy code
## 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:

markdownCopy code
### 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:

MoSCoW definitions:

Non-functional requirements:

Requirement writing rules:

• Each requirement should be testable (you can verify it's done)
• Use "User can [action]" or "System [behavior] when [condition]"
• Never combine two requirements in one row
• Include "Won't" items explicitly, prevents scope creep conversations later

Step 5: Define User Flows

For each Must requirement, document the primary user flow:

User flow template:

markdownCopy code
### Flow: [Action Name]

**Trigger:** [What initiates this flow]
**Actor:** [Which persona]
**Preconditions:** [What must be true before this flow starts]

**Happy path:**
1. User [action]
2. System [response]
3. User [action]
4. System [response]
5. User sees [outcome/confirmation]

**Error states:**
- If [condition], show [error message] and [recovery action]
- If [condition], redirect to [fallback]

**Edge cases:**
- [Edge case 1: what happens when...]
- [Edge case 2: what happens when...]

Step 6: Define Success Metrics

Metric rules:

• 1 primary metric (the North Star for this product/feature)
• 2-3 secondary metrics (supporting indicators)
• 1 guardrail metric (something that must NOT get worse, e.g., page load time)
• All metrics must have current baselines and targets with timeframes

Step 7: Outline Timeline & Dependencies

Phase breakdown:

Key dependencies:

• [Dependency 1: Design mockups for [flow]: needed by [date]]
• [Dependency 2: API endpoint from [team]: needed by [date]]
• [Dependency 3: Third-party integration approval: needed by [date]]

Risks:

Output Format

markdownCopy code
# PRD: [Product Name]

**Author:** [Name]
**Date:** [Date]
**Version:** [1.0]
**Status:** [Draft / In Review / Approved]

## 1. Problem Statement
[From Step 2]

## 2. User Personas
[From Step 3]

## 3. Requirements
### 3.1 Functional Requirements
[MoSCoW table from Step 4]
### 3.2 Non-Functional Requirements
[NFR table from Step 4]

## 4. User Flows
[From Step 5]

## 5. Success Metrics
[From Step 6]

## 6. Timeline & Dependencies
[From Step 7]

## 7. Open Questions
[Anything unresolved that needs stakeholder input]

## 8. Appendix
[Wireframes, research data, competitive context]

Completion

Copy code
PRD Writer: Complete!

Product: [Name]
Problem: [One-line summary]
Personas: [Count]
Must-have requirements: [Count]
Total requirements: [Count]
Phases: [Count]
Estimated timeline: [X weeks]

Next steps:
1. Review with engineering for feasibility and estimates
2. Review with design for user flow validation
3. Get stakeholder sign-off on MoSCoW priorities
4. Break Phase 1 "Must" requirements into user stories (use User Story Generator)
5. Schedule kickoff meeting

Level History

• Lv.1: Base: Problem statement template with evidence/impact/opportunity, persona template (goals, pains, behaviors, quote), MoSCoW functional requirements table, non-functional requirements (10 categories), user flow template with error states and edge cases, success metrics with baselines/targets/timeframes, phased timeline with dependencies and risk matrix. (Origin: MemStack Pro v3.2, Mar 2026)