Exercise One: Simple Feature PRD

Document Title: Author: Status: Version: Last Updated: Stakeholders:

Ask yourself: who needs to know this feature is being built? Who needs to approve it? Who will be affected by it beyond the engineering and design team?

Overview

Write two to three paragraphs. What is being built? Why now? What user problem does it address at a high level? What is the scope of this feature in a sentence?

Problem Statement

Complete this section using the framework from Module Two. Name the specific user experiencing the problem. Describe what they experience. Provide the evidence. State the impact of leaving it unsolved. Do not mention the solution here.

We have observed that __________________

We know this because __________________

The impact of leaving this problem unsolved is __________________

Goals

Write three goals. Each goal must describe an outcome, a change in user behaviour or business performance, not a feature or deliverable. Ask yourself: if this feature succeeds, what will be measurably different?

1. Goal 1:
2. Goal 2:
3. Goal 3:

Success Metrics

Define one primary metric. Define two to three secondary metrics. Define at least one guardrail metric. For each metric, state how it will be measured and the timeframe for evaluation.

Primary Metric:

Secondary Metrics:

Guardrail Metrics:

Evaluation Timeframe:

Ask yourself: what would tell you this feature failed? What would tell you it succeeded? Are these the same metric or different ones?

User Stories

Write three user stories using the format: As a [specific user], I want to [accomplish something] so that [I can achieve this outcome]. Make each story specific. Avoid writing generic users or vague goals.

1. User Story 1:
2. User Story 2:
3. User Story 3:

Ask yourself: are these the same user in different contexts, or genuinely different users with different needs? Does each story add something the others do not?

Functional Requirements

Organise your requirements into Must Have, Should Have, and Nice to Have. Write each requirement as a specific, testable behaviour. Name the user, the action, the condition, and the expected system response.

Must Have

Should Have

Nice to Have

Ask yourself: if you had to ship in half the time, what could you remove without breaking the core value? That is your Should Have and Nice to Have list. What cannot be removed is Must Have.

Non-Functional Requirements

Address at least four of the following: performance, reliability, security, accessibility, privacy, compliance. Be specific. Avoid vague statements like "the system should be fast."

1. Performance:
2. Accessibility:
3. Privacy:
4. Other:

Out of Scope

List at least three things this feature will explicitly not include in this version. Be specific. These should be things a stakeholder might reasonably expect to be included.

Dependencies

What does this feature depend on that is outside your direct control? Think about other teams, existing infrastructure, third-party services, or data availability.

Risks

Name two to three risks. For each one, state what could go wrong, how likely it is, and what you would do to reduce the impact.

Open Questions

What do you not yet know that you would need to find out before development begins? For each question, name who should answer it and by when.

Reflection Questions

When you have finished your draft, sit with these questions before you move on.

1. Does your problem statement contain a solution anywhere? If yes, remove it.
2. Can every goal in your goals section be evaluated with a number? If not, rewrite it.
3. Can every functional requirement be tested with a clear pass or fail? If not, add specificity.
4. Is there anything in your out-of-scope section that a stakeholder might have assumed was included? If not, you may have missed something.
5. If a new engineer joined the team tomorrow and read only this document, would they understand what they are building and why? If not, identify which section needs more clarity.