Pm requirements

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)

1. The target release goal and what market forces / content is driving it.
2. The personas involved (link or summarize).
3. The list of problems (persona's first person) + the evidence count for each.
4. Impact rating per problem (use the scale) and any contractual must-haves (99999).
5. 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 content or by a target date?>

## Requirements

### GROUP #1 — <Group Name>
<Short description of the group.>

**Requirement #1 — <problem>**
<Persona> has <problem, described in a use scenario> with <frequency>.
**Priority:** 25 (inputs) × 4 (impact) = 100

**Requirement #2 — <problem>**
<Persona> has <problem> with <frequency>.
**Priority:** <evidence> × <impact> = <priority>

### GROUP #2 — <Group Name>
…

## Persona Details
<Full personas, one per page or linked.>

## Requirements Summary
| Name | Market Evidence | Impact | Priority (Evidence × Impact) | Group Name | Group Order |
| :--- | ---: | ---: | ---: | :--- | ---: |
| <req> | 25 | 4 | 100 | <group> | 1 |
<!-- Sort by Group Order ascending, then Priority descending. -->

## Approvals
| Name | Title | Date | Signature |
| :--- | :--- | :--- | :--- |
| | Systems Architect | | |
| | Interaction Designer | | |
| | Product Manager | | |
| | Development Manager | | |
| | Quality Assurance Lead | | |
| | Project Manager | | |

## Change Tracking
| Version | Date | Changes | Reason |
| :--- | :--- | :--- | :--- |
| 1.0 | <date> | 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.