User Stories and Requirements

Translating User Needs into Build Instructions

One of the PM's most fundamental skills is translating user needs and business goals into requirements that engineering and design teams can act on. This is harder than it sounds.

Requirements that are too vague ("Make the onboarding better") leave engineers guessing. Requirements that are too prescriptive ("Add a blue button with 14px Montserrat text in the top right") prevent engineers from finding better solutions.

Good requirements communicate the goal clearly, explain the user context, and leave room for the team to find the best implementation.

User Stories: The Standard Format

A user story is a short, plain-language description of a feature from the user's perspective. The standard format is:

As a [type of user],
I want to [action or goal],
So that [benefit or reason].

Examples:

Poor user story (too vague):

As a user, I want to see my transactions.

Better user story (specific, with context):

As a registered customer,
I want to view my last 30 days of transactions with the ability
to filter by merchant and date range,
So that I can quickly verify specific payments and track my spending patterns.

The difference: the better version tells engineers the time range, filtering capability, and why the user needs it. This allows better design decisions.

Acceptance Criteria: Defining "Done"

Every user story needs acceptance criteria -- specific, testable conditions that must be met for the story to be considered complete. These are the pass/fail tests for the feature.

Format: "Given [context], when [action], then [expected outcome]."

Example: Transaction history user story

ACCEPTANCE CRITERIA:

Given the user is logged in and navigates to the Transactions screen,
When they load the page,
Then they see a list of all transactions from the last 30 days, sorted by date descending.

Given the user applies a merchant filter,
When they select "Shoprite" from the filter menu,
Then only transactions from Shoprite are displayed.

Given the user has no transactions in the selected date range,
When they view the transactions list,
Then they see an empty state message: "No transactions found for this period."

Given the user has more than 20 transactions,
When they scroll to the bottom of the list,
Then additional transactions load automatically (infinite scroll).

Acceptance criteria remove ambiguity. Engineers know exactly what to build. QA knows exactly what to test. The PM knows exactly when to approve.

The Product Requirements Document (PRD)

For larger features, PMs write a PRD (Product Requirements Document) that provides full context for the feature. A typical PRD structure:

1. Overview

What is this feature? One paragraph summary.

2. Problem Statement

What problem does this solve? Why are we building this now? What happens if we do not?

3. User Research

What did we learn from users? What evidence supports this feature?

4. Goals and Success Metrics

What does success look like? What will we measure?

5. User Stories

The full list of user stories for this feature.

6. Out of Scope

Explicitly list what is NOT included in this version. This prevents scope creep.

7. Design

Link to the relevant Figma designs.

8. Open Questions

Things that still need to be decided or researched.

Epics vs Stories vs Tasks

Requirements are organised in a hierarchy:

Epic: A large body of work that represents a significant product capability. Cannot be completed in one sprint.

• Example: "User Authentication System"

User Story: A single piece of user functionality that delivers value. Should be completable in one sprint.

• Example: "As a new user, I want to register with my email address and password."

Task/Sub-task: A specific technical or design activity needed to complete a story.

• Example: "Design the registration form screen", "Implement email validation", "Write unit tests for registration API"

Most teams use Jira, Linear, or Notion to manage this hierarchy.

Definition of Ready vs Definition of Done

Two important concepts for managing quality in Agile teams:

Definition of Ready (DoR)

The conditions a user story must meet before it can be picked up by engineering:

• User story is written in the standard format
• Acceptance criteria are defined and approved
• Design mockups are available or not needed
• Dependencies are identified
• Story has been estimated (or is not needed for estimation)

Definition of Done (DoD)

The conditions that must be met for a story to be considered complete:

• All acceptance criteria pass
• Code has been reviewed by another engineer
• Tests are written and passing
• Feature works in staging environment
• PM has reviewed and approved
• Documentation is updated if needed

Having explicit DoR and DoD prevents stories from being rushed into development (not ready) or marked done prematurely (not actually done).

Writing Better Requirements: Common Mistakes

1. Requirements that specify implementation

Bad: "Add a dropdown menu in the top right corner." Better: "Users need a way to access account settings without leaving their current page."

Let the design and engineering team figure out the best implementation. Your job is to communicate the need.

2. Missing the "why"

Without context for why the feature matters, engineers cannot make good trade-off decisions. Always include the user and business context.

3. Requirements that cannot be tested

"The checkout flow should be smooth" is untestable. "Users should be able to complete checkout in fewer than 4 steps" is testable.

4. Scope creep through implied requirements

If the feature only includes X, explicitly write "Y is out of scope for this release." What you do not say can be misinterpreted as implied.

Prioritisation: Deciding What to Build Next

With many potential user stories, prioritisation is one of the PM's most critical (and most debated) responsibilities.

The RICE Framework

Scores features on four dimensions:

• Reach: How many users does this affect per time period?
• Impact: How much does it improve the experience for affected users? (1=minimal, 3=massive)
• Confidence: How confident are you in these estimates? (percentage)
• Effort: How many person-weeks does this take?

RICE Score = (Reach x Impact x Confidence) / Effort

The MoSCoW Method

Categorises requirements into:

• Must have: Core features without which the product cannot function
• Should have: Important but not critical; include if possible
• Could have: Nice to have; only if time allows
• Won't have: Out of scope for this release

Using explicit prioritisation frameworks makes decisions transparent and defensible, reducing endless debates about what to build next.