| name | pm-requirements |
| description | Write market-driven, prioritized product requirements (a Market Requirements Document / MRD) the Pragmatic Institute way. Use when the PM asks for "requirements", "an MRD", "what should we build", "prioritize features", "market requirements", or wants development to stop saying "requirements aren't specific enough". Articulates each requirement as a persona's problem, prioritizes with Market Evidence × Impact, and groups them for delivery. Produces a Market Requirements Document as a Markdown or Word .docx artifact. |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep |
Market Requirements (Pragmatic Framework: Planning → Requirements)
Rule: market problems drive requirements that work. A requirement articulates a
problem, not a solution — the what (owned by the PM), never the how (owned by
the team). Write every requirement as:
[persona] has [problem, described in a use scenario] with [frequency].
If personas or use scenarios aren't ready, run pm-personas and pm-use-scenarios first.
See ../pm-copilot/references/framework.md.
Prioritize objectively (never High/Med/Low or voting)
Priority = Market Evidence × Impact.
- Market Evidence — a tally of documented occurrences across inputs (discovery
interviews, surveys, sales calls, support tickets, win/loss, analyst reports,
reviews, usage data). "How many times have we seen it? What % experience it?"
- Impact — an objective 1–5 scale (adapt to your strategy) plus a 99999
contractual override:
| Impact | Definition |
|---|
| 99999 | Contractual obligation |
| 5 | Minimum purchase criteria (evaluator) |
| 4 | Potentials lose time or money due to the problem |
| 3 | Difficult for customers to achieve a primary goal |
| 2 | Customers have difficulty with a non-primary goal |
| 1 | Not in the target market segment |
Advanced — the Four Forces (BUVC):
Priority = Evidence × Impact × (B + U + C + V)
Buying (what the buyer needs to make the sale), Using (what the user needs to solve
their problem), Vision (long-term strategic goals), Competitive (stay competitive).
Apply as per-criterion multipliers (example weights B=2, U=1, C=1, V=1).
Group & Group Order: a Group is two or more requirements that make sense to solve
together; Group Order + Priority set the sequence handed to development. "Deliver 100%
of something, not 70% of everything."
Interview the user (batch questions)
- The target release goal and what market forces / content is driving it.
- The personas involved (link or summarize).
- The list of problems (persona's first person) + the evidence count for each.
- Impact rating per problem (use the scale) and any contractual must-haves (99999).
- Which problems naturally group together.
Artifact template — Market Requirements Document (MRD)
# <Product Name> — Market Requirements Document
*This document is confidential and subject to change. For internal use only. No external
commitments can be made based on this document since it is in early planning stages.
Content and timing are very likely to change.*
**Company:** <company> · **Feature / Product:** <product name>
**Author:** <author> · **Contact:** <email> · **Date created:** <date> · **Date last updated:** <date>
## Overview of Target Release
<What is the goal for this release? What market forces are driving this project? What
other artifacts have been created? Are we driven primarily by ?>
has with .
25 (inputs) × 4 (impact) = 100
has with .
× =
…
| Name | Market Evidence | Impact | Priority (Evidence × Impact) | Group Name | Group Order |
| :--- | ---: | ---: | ---: | :--- | ---: |
| | 25 | 4 | 100 | | 1 |
<!-- Sort by Group Order ascending, then Priority descending. -->
| Name | Title | Date | Signature |
| :--- | :--- | :--- | :--- |
| | Systems Architect | | |
| | Interaction Designer | | |
| | Product Manager | | |
| | Development Manager | | |
| | Quality Assurance Lead | | |
| | Project Manager | | |
| Version | Date | Changes | Reason |
| :--- | :--- | :--- | :--- |
| 1.0 | | Initial draft | — |
Deliver the artifact
Follow ../pm-copilot/references/artifact-output.md: confirm inputs, ask Markdown
or .docx, write the .md, convert to .docx on request via your environment's native document-creation capability. Then offer the next stages: add context with pm-use-scenarios,
assemble a full pm-prd, or commit an increment with pm-release-plan.
