/defining-requirements

name: defining-requirements
description: |
    Skill to define requirements effciently as a product manager.

How to Define Requirements

Defining requirements is one of the most critical—and misunderstood—responsibilities of a product manager. The traditional "hand over a 50-page PRD and disappear" approach is broken. Modern product managers define requirements **collaboratively, iteratively, and with a focus on outcomes, not just outputs.**

Here is a practical guide to the **good ways** product managers can define requirements today.

---

1. Shift from “Documentation” to “Continuous Discovery”

Before picking a template, shift your mindset. Requirements are not a one-time artifact; they are a **shared understanding** that evolves.

**Good:** You refine requirements continuously through customer interviews, usability tests, and stakeholder feedback. **Bad:** You write a spec, throw it over the wall, and move to the next thing.

> **Principle:** The goal is not a perfect document—it’s a shared mental model.

---

2. Use User Stories, Not Just Feature Lists

User stories are the industry standard because they focus on **who, what, and why**.

**Format:** > As a **[type of user]** , I want **[some goal]** so that **[some reason]** .

**Example:** > As a **frequent traveler**, I want to **save my payment details** so that **I can book flights faster**.

**Why it works:**

• It keeps the user at the center.
• It defers implementation details (the *how*).
• It fits nicely into agile iterations.

**But caution:** User stories are placeholders for conversation, not contracts. Don’t just write them and walk away.

---

3. Write Acceptance Criteria in “Given‑When‑Then” (Gherkin)

This is the **Behavior‑Driven Development (BDD)** technique we discussed earlier. It is not just for testers—it is the clearest way for a PM to define **precise, testable requirements**.

**Format:**

Scenario: Save payment details
  Given I am a logged-in user
  When I enter valid credit card information
  And I check "Save this card for future use"
  And I submit the payment
  Then my card should be securely saved
  And I should see it as an option on my next booking

**Why PMs should write these:**

• Forces you to think through concrete examples before development.
• Eliminates ambiguity (“secure saved” vs. “encrypted token”).
• Becomes the test case—developers and QA run it.
• You can review it with stakeholders who understand plain English.

**Tooling:** Cucumber, SpecFlow, Behave, or even simple checklists in Jira.

---

4. Use Story Mapping to See the Big Picture

User stories alone can create a fragmented view. **User Story Mapping** (Jeff Patton) helps you visualize the entire user journey and prioritize ruthlessly.

**How it works:** 1. Map the user’s steps horizontally (backbone). 2. Break each step into detailed tasks (stories) vertically. 3. Slice releases vertically by value, not horizontally by layer.

**Why it’s good:**

• Prevents building features in isolation.
• Shows dependencies and gaps.
• Helps PMs define the Minimum Viable Product (MVP) slice.

**Tool:** Miro, MURAL, or physical sticky notes.

---

5. Consider “Job Stories” for JTBD Practitioners

If your product is used in varied contexts, **Job Stories** (from Intercom) are often more flexible than User Stories.

**Format:** > When **[situation]** , I want to **[motivation]** so I can **[expected outcome]** .

**Example:** > When **I’m booking a last‑minute trip**, I want to **skip entering my payment details** so I can **complete the booking in under 30 seconds**.

**Why:** It doesn’t assume a specific user role; it focuses on the **context** and **causal mechanism**.

---

6. Prototype + Annotate (The “Spec-Lite” Approach)

Sometimes a picture is worth a thousand user stories.

**Good:** A clickable Figma prototype with **annotated requirements** attached to specific UI elements. **Even better:** A prototype linked to the actual user story in your project management tool.

**Why:** Developers see exactly what to build, designers see the interaction, and QA can trace the requirement to the screen.

**Common format:**

• Prototype (Figma, Sketch, Axure)
• Side‑by‑side acceptance criteria (e.g., “When user clicks X, Y happens”)
• Edge cases noted in comments

---

7. Frame Requirements as Hypotheses (Lean Startup)

In high‑uncertainty environments, defining requirements as **hypotheses** changes the conversation from “build this” to “test this”.

**Format:** > We believe that **[building this feature]** will achieve **[this outcome]** . > We will know we are successful when **[measurable signal]** .

**Example:** > We believe that **allowing guests to checkout without an account** will **reduce cart abandonment**. > We will know we are successful when **guest checkout conversion is ≥ 65%** and **account sign‑ups drop by less than 10%** .

**Why it’s good:**

• Shifts focus to learning, not shipping.
• Encourages building the smallest thing to test the idea.
• Aligns PM, dev, and business on success metrics.

---

8. Collaborate with the “Three Amigos”

Don’t write requirements in a silo. Before development starts, sit down with:

• **A developer** – to surface technical constraints and feasibility.
• **A tester/QA** – to uncover edge cases you never considered.
• **A designer** – to validate usability.

This is the **Three Amigos** meeting from BDD. It is the single highest‑leverage activity a PM can do to improve requirement quality.

---

9. Keep a Living Glossary / Domain Language

Ambiguity kills requirements. Define the key terms your team uses—especially if you work in a complex domain (finance, healthcare, logistics).

**Example:**

• What exactly is an “active user”?
• What does “processed” mean in the order lifecycle?

Store these definitions in a **wiki** or directly in your specification tool. This prevents developers from making incorrect assumptions.

---

10. Avoid