Skip to main content
Next Step PM
Back to the library

Define · Core

Write a product brief (PRD)

A product brief, often called a PRD, brings the problem, users, goals, scope and open questions into one short document. It becomes the place the whole team goes to understand why you are building this and what is in and out.

About 2-4 daysEvergreenLast reviewed 5 November 2026

Who this applies to

Skills it builds
Communication and influenceDelivery and execution
PM types
All
Product types
All
Starting points
All
Ways of working
All
Experience
All
Size of organisation
All

Steps, by experience

Beginner (under 1 year)

  1. Start with a template: background, problem, users, goals and metrics, scope, out of scope, assumptions, open questions, and links.
  2. Copy in your problem statement and success metrics rather than rewriting them.
  3. Describe the main users and what they need to be able to do, in plain language.
  4. List what is in scope for the first release and, just as important, what is not.
  5. Add the open questions and who will answer each one.
  6. Share it for comments with design, engineering and key stakeholders, and keep it up to date as decisions are made.

Intermediate (1 to 4 years)

  1. Write a short brief covering problem, users, goals, metrics, scope, non-goals and open questions.
  2. Link out to research, designs and the backlog rather than copying detail in.
  3. Review with the team and stakeholders and resolve major comments.
  4. Keep it as a living document with a change log.

Experienced (5+ years)

  1. Write it as a narrative that a senior reader can understand in ten minutes, leading with the customer and the why.
  2. Make trade-offs, non-goals and risks explicit so they can be challenged early.
  3. Use the review to surface disagreement and force decisions.
  4. Keep the brief at the right level, leaving solution detail to designers and engineers.

Who can do this

Owner: Product manager

Can be delegated to

  • Business Analyst: Draft the scope, requirements and open questions sections
  • Content Designer: Edit the brief so it is short and clear
  • Tech Lead: Add technical constraints and dependencies

Reviewed by: Tech Lead, UX Designer, Policy / Legal / Compliance

Tool examples

Confluence
Use the product requirements template and link each requirement to its Jira epic.
Notion
Create the brief as a page with linked databases for open questions and decisions.
Google Docs
Ask reviewers to use comments and resolve each one with a decision.
SharePoint / Word
Keep one shared version and turn on tracked changes for the review round.
Claude
Paste your notes and ask it to draft the brief in your template, then ask it to list what a sceptical engineer would challenge.

Definition of done

  • Brief covers problem, users, goals, metrics, scope, non-goals and open questions
  • Reviewed by design, engineering and key stakeholders
  • Major comments resolved and owners assigned to open questions

Common pitfalls

  • Writing a long specification nobody reads
  • Leaving out what is not in scope
  • Letting the brief go out of date after the first review

If you lead the team

What good looks like: Briefs are short, current and used: they hold the problem, goals, scope and open questions in one place.

Ask your PM

  • What's in and out of scope, and who agreed it?
  • Which open questions could still change the plan?

Warning signs

  • The brief is long, out of date or unread.
  • Scope grows with no record of why.

Do these first

Sources