How to Write a Product Discovery Brief: Steps, Examples and Checklist

Capture why discovery is being commissioned — the trigger, the background, what is already known. Then do the brief's central work: convert a vague ambition into a small set of specific, answerable questions, ranked by which would change the most. Define the audience and problem area, bound the scope so the work cannot sprawl, and match each question to the cheapest activity that could answer it. Finish by naming the decision the findings will feed, so discovery ends in a choice rather than a deck.

By Gensudo Team · Updated 23 July 2026

When you need this document

Write a discovery brief before research or concepting time is spent — at the point someone says 'we should look into this' and before anyone books an interview. It earns its keep most when the ask is fuzzy, the sponsor's expectations are unstated, or a team is prone to open-ended research that ends in interesting findings and no decision. If the questions are already answered and evidenced, skip to an opportunity assessment; discovery without genuine unknowns is procrastination with a research budget.

Gather these first

The trigger: the event, signal or executive question that put this on the agenda
What is already known — prior research, support themes, data, past attempts at the same question
The audience or segment the discovery concerns
The sponsor's actual expectation: what they think this work will produce
Constraints: time, budget, access to customers, and anything already decided
The decision or document the findings are supposed to feed

Step by step

Record the trigger and what is already known
Start with why this discovery exists now: the churn spike, the sales pattern, the executive question, the competitor move. Then audit existing knowledge — past research, support themes, analytics, previous attempts at the same question — before commissioning new work. Teams routinely rediscover what the organisation already knew, at full price. The gap between what is known and what is needed is precisely what the brief scopes.
What good looks like: A reader understands why this matters now, and no question in the brief is one the organisation has already answered.
Turn the ambition into answerable questions
This is the heart of the brief. Convert 'explore the SMB opportunity' into questions discovery can actually settle: who in this segment has the problem, how are they solving it today, what would trigger them to switch, what would they pay? Good discovery questions are specific enough to design an activity around and neutral enough not to presuppose the answer. Three to six is usually right; more means you have not chosen.
What good looks like: Each question could be given to a researcher, who could design an activity to answer it without coming back for clarification.
Rank the questions by what would change the most
Not all unknowns are equal. Order the questions by decision leverage: which answer, if it surprised you, would most alter what happens next? That question gets researched first and deepest — and if time is cut short, it is the one that still gets answered. Ranking also exposes questions that are merely curiosities: if no plausible answer would change anything, the question does not belong in the brief.
What good looks like: The team can say which single question matters most and why, and would cut from the bottom of the list, not the top.
Define the audience and bound the scope
Specify whose problem space you are exploring — segment, role, situation — and then draw the edges: which markets, user groups and question areas are out, and what is already decided and therefore not up for re-examination. Unbounded discovery expands to fill all available time, because everything connects to everything. The exclusions will feel arbitrary to write and prove invaluable in week three when the work tries to wander.
What good looks like: The scope names its exclusions explicitly, and settled decisions are marked as not being re-opened by this work.
Match each question to the cheapest activity that answers it
Plan the discovery work backwards from the questions: interviews for motivation and context, analytics for actual behaviour, competitor teardowns for the alternative landscape, quick prototype tests where reaction matters. Resist the standard-package instinct — eight interviews and a survey regardless of what is being asked. Note the sequencing too: some answers change which question comes next, and a good plan says where it might branch.
What good looks like: Every activity in the plan traces to a specific question, and no question is left without a planned way to answer it.
Name the decision the findings will feed, and what done looks like
State where the outputs land: the decision to be made, who makes it, and which document the findings feed — an opportunity assessment, a validation plan, a concept choice. Define what finished discovery looks like: questions answered to a stated confidence, not a deliverable produced. This is the difference between discovery that ends in a decision and discovery that ends in a well-attended readout and a quiet fade.
What good looks like: The brief names the decision, the decision-maker and the receiving document, so the findings have a destination before work begins.

Common mistakes

The brief states a topic, not questions — 'explore AI opportunities' — so the work sprawls and the findings answer nothing in particular. — Force the conversion to three to six specific, answerable questions before any research is booked. If a question cannot be answered by an activity you can name, it is still a topic.
The questions smuggle in the answer — 'validate that SMBs want feature X' — so discovery becomes evidence-collection for a decision already made. — Phrase questions neutrally and check each one has at least two plausible answers the team would genuinely accept. If only one answer is acceptable, you need a validation plan and honesty about it, not discovery.
No decision is attached, so discovery concludes with an interesting readout, a round of nods, and no change to anything. — Write the destination into the brief: the decision, the decision-maker, the receiving document, the date. Discovery findings without a landing place become trivia within a month.
Existing knowledge is never audited, and the team spends four weeks rediscovering what support tickets and a two-year-old research deck already showed. — Spend the first day of discovery in your own archives — prior research, analytics, win/loss notes, support themes. Brief only the genuine gaps; the rest is free.

Before you call it done

The trigger for discovery is recorded, with what is already known audited first
The brief contains three to six specific, answerable, neutrally-phrased questions
Questions are ranked by decision leverage, and mere curiosities are cut
Audience, scope edges and not-being-reopened decisions are explicit
Every question has a matched activity; every activity has a matching question
The receiving decision, decision-maker and destination document are named
Done is defined as questions answered to stated confidence, not deliverables produced

Frequently asked questions

How is a discovery brief different from an opportunity assessment?

Direction of travel. The discovery brief is written before investigation: it defines the questions, scope and activities for work about to happen. The opportunity assessment is written after enough evidence exists: it weighs a specific opportunity and recommends whether to validate further. In a healthy sequence, the brief commissions the learning and the assessment spends it — the brief's questions often become the assessment's evidence sections.

How long should discovery run before it reports back?

Long enough to answer the ranked questions to a usable confidence, and no longer — which the brief itself should determine, since the activity plan implies a duration. The practical discipline is a checkpoint tied to the highest-leverage question: report as soon as it is answered, because that answer may redirect or end the remaining work. Open-ended discovery is where research budgets go to be comfortable.

Who should write and approve the discovery brief?

The product manager typically drafts it, but the two signatures that matter are the sponsor — confirming these questions, once answered, will actually settle their ask — and the people doing the research, confirming the questions are answerable with the planned activities and access. A brief the sponsor has not agreed produces findings the sponsor did not want; both failure modes are cheaper to fix on paper.

What if we discover something important outside the brief's scope?

Log it, do not chase it. The brief exists so the team makes a deliberate choice about detours rather than drifting into them mid-interview. Significant out-of-scope findings go to the sponsor with a recommendation: extend this discovery, brief a separate one, or park it with the evidence attached. That keeps serendipity — often where the best insights come from — without letting it quietly replace the commissioned work.

Start from the structured template

See the full Product Discovery Brief for Product Managers template and structure, or draft it in Gensudo with cited evidence.

Get started