Module 6: Writing Product Requirements & User Stories
- Write a clear user story with acceptance criteria
- Distinguish a requirement (the what) from a solution (the how)
- Avoid common ambiguity that causes rework
A user story is a short, structured way of describing a feature from the user's perspective, typically in the form "As a [type of user], I want [goal], so that [reason/benefit]" which keeps the focus on the underlying need rather than jumping straight to a specific implementation. Each story needs clear acceptance criteria: specific, testable conditions that define when the story is genuinely done, which prevents the frustrating cycle of a feature being marked complete but not actually meeting expectations. A common and costly PM mistake is writing the solution ("add a blue button that opens a modal") instead of the requirement ("the user needs to confirm an action before it's irreversible"), which removes engineering's ability to propose a better technical approach.
1. Acceptance criteria exist primarily to:
2. A well-formed user story typically follows the structure:
3. Writing 'add a blue button that opens a modal' instead of describing the underlying user need is a common mistake because it: