Lifecycle · Phase 4 of 8

Define: turn priorities into clear requirements

Definition turns agreed priorities into clear requirements, user stories and creative direction that teams can confidently build from. 39 governed templates help remove ambiguity and keep every specification decision-grade.

Get StartedBrowse the document library

What Define is

Define turns agreed priorities into a clear specification for what will be built. Requirements, user stories and creative direction are documented in enough detail for designers and engineers to work without having to guess. The aim is to make the scope clear, measurable and agreed before delivery begins.

What gets decided in Define

By the end of Define, the team should be clear on:

  • Exactly what is being built, feature by feature
  • How each part will be assessed, including acceptance criteria and what good looks like
  • The creative and brand direction the work needs to follow
  • What is explicitly out of scope for the release

The documents in the Define phase

Gensudo includes 39 Define templates, with the Creative Director using 12 and the Product Manager 11. This reflects the importance of bringing product and creative direction together before work moves into build. Key documents include the Product Requirements Document (PRD), User Stories and Creative Brief. Each template also includes section-level source expectations, showing where supporting evidence should come from, whether that is project context, standard practice, research or input only the team can provide. Missing information is clearly identified so it can be addressed when needed.

A typical Define sequence

  1. 1

    Write the PRD

    Capture what's being built and why in a Product Requirements Document, drawing on the decisions and evidence already established in planning — not restating them from memory.

  2. 2

    Break it into User Stories

    Decompose the requirements into stories with acceptance criteria a tester could actually apply. A story without a testable "done" is a conversation deferred to the worst possible moment.

  3. 3

    Set the creative direction

    Write the Creative Brief: the look, voice and feel this work must carry. Creative direction that lives in someone's head doesn't survive contact with a deadline.

  4. 4

    Close the gaps and sign off

    Walk the specification end to end, resolve open questions, and get explicit sign-off. Where something genuinely can't be known yet, say so plainly in the document rather than hiding it.

You’re ready to move on from Define when:

  • Engineers can estimate the work without needing further clarification
  • Every user story has clear, testable acceptance criteria
  • Creative direction is documented and agreed
  • Out-of-scope items are clearly listed for the release
  • Requirements link back to evidence and decisions from earlier phases
  • The right people have reviewed and approved the final documents

Define phase questions

What should a PRD contain?

A Product Requirements Document should state what's being built and why, who it's for, the requirements themselves with acceptance criteria, what's explicitly out of scope, and how success will be judged. The "why" should trace to evidence from discovery and validation rather than being reasserted. Gensudo's PRD template carries per-section prompts and guidance on what good looks like, so the structure does some of the thinking with you.

What's the difference between a PRD and user stories?

The PRD is the whole argument — what's being built, why, for whom, and with what boundaries. User stories are the working units it decomposes into: individual slices of behaviour, each with acceptance criteria a tester can apply. You need both; a pile of stories without a PRD has no spine, and a PRD without stories never quite reaches the build.

How detailed should definition be?

Detailed enough that the people building it can act without guessing — and no further. Over-specification is its own failure mode: it slows the phase down and gets ignored anyway. A practical test is estimation: if engineers and designers can size the work and start it without a clarifying meeting, the definition is detailed enough.

Why is the Creative Director so active in Define?

Because creative ambiguity is just as expensive as functional ambiguity. Of the 39 Define-phase templates, 12 belong to the Creative Director — briefs and direction documents that pin down look, voice and feel before build starts. When creative intent isn't written down, it gets reinvented under deadline pressure, and the result rarely matches what anyone meant.

Keep moving

Back: Plan

Definition specifies what planning prioritised. If you're unsure what to define, the ordering conversation belongs a phase earlier.

Revisit the Plan phase

Next: Build

With the specification agreed, delivery begins — and the documents shift from describing intent to keeping it honest.

Go to the Build phase

Specify once, build without guessing

PRDs, user stories and creative briefs with per-section prompts, sign-off guidance and honest-gap handling built in.

Get Started