defining-requirements - SKILL.md Agent Skill

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:

Map the user’s steps horizontally (backbone).
Break each step into detailed tasks (stories) vertically.
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 Common Pitfalls

Pitfall	Better Approach
Writing implementation details (“Use a dropdown”)	Describe the user need (“Select one of up to five options”)
Over‑specifying the UI	Use wireframes or low‑fidelity prototypes
Mixing business rules with UI text	Separate the logic from the copy
No negative scenarios	Always ask: “What if it fails?”
Requirements that can’t be tested	Write acceptance criteria that are verifiable

Summary: A Good Requirements Workflow

Discover: User interviews, data analysis, stakeholder input.
Frame: Write user stories or job stories with clear value.
Refine: Three Amigos session → add Gherkin scenarios.
Visualize: Sketch flows or link to low‑fidelity prototypes.
Validate: Test assumptions with a prototype or a tiny experiment.
Hand over: Short, living document + acceptance criteria + mockups.
Iterate: Update requirements as you learn from development and testing.

Final thought: The best way to define requirements is not to define them once—it’s to create a shared understanding that evolves until the feature is in the user’s hands. Tools and templates help, but conversation and collaboration are what make requirements truly “good.”