How to do discovery research

Name the number the research could move

Discovery is not a standing activity.

Open the epic and write three figures at the top of the research file: the outcome's currency target, the epic's planned share of it, and the threshold at which your decision changes. Something like: below £120k this epic leaves Q3. Without that threshold you will produce findings nobody can act on, because no result is ever obviously bad enough. If the epic does not exist yet, this is outcome shaping rather than discovery, and the question is whether the outcome can carry a credible number at all.

Write the hypothesis so it can fail

State the belief in one sentence with the number attached: trade customers reorder near-identical baskets often enough that one-tap templates lift repeat order rate by two points, worth £300k of gross profit this quarter. Underneath it write the kill condition as a measurable result, not a mood: fewer than four of eight interviewees rebuild orders from history, or under a quarter of accounts show repeat baskets in the data. Have product and engineering sign off both before fieldwork starts. Arguing about what would change your mind is cheap beforehand and impossible afterwards.

Timebox discovery against the quarter

The roadmap is one quarter, twelve to thirteen weeks, and the epic has to ship inside it.

Cap discovery at two weeks, one week for anything under roughly £100k of planned value, and put the end date on the epic before you start. If two weeks cannot answer the question, that is itself a finding: either the epic is too speculative for this quarter and moves out, or you cut the question down to the single assumption that most threatens the number and answer only that. Open-ended research is how epics quietly leave the roadmap without anyone deciding they should.

Pick methods that can return a no

Match the method to the risk.

For desirability, six to eight interviews with people who have the problem and are not your fans, recruited on day one from support tickets, churned accounts and lapsed users rather than the customer advisory board. For the size of the prize, query behaviour you already hold: order history, funnel drop-off, ticket volumes, cancellation reasons, and pull the denominator first so you know how many people the epic can reach. For feasibility, put an engineer in the room for an afternoon. Run at least one method that returns a number; interviews alone will not defend a currency figure at the gate.

Build the evidence corpus in markdown

Convert every source into markdown in a repository the whole team and your models can read: interview transcripts in full, the query you ran alongside its output, ticket exports, competitor behaviour described in prose. One source per file, each opening with a date, who or what it came from, and how it was collected. Do not summarise on the way in. A tidy summary written during collection is where the inconvenient quote disappears, and it strips out the raw material the next step works on. Name files so a person and a model can both tell what is inside without opening them.

Run a contradiction pass, then check it

Ask a model to read the whole corpus and return, with file and line references, what the evidence supports, what it contradicts, and where it is silent. Silence is the useful category: it tells you which part of your number nothing in the corpus touches. Then open every reference and confirm the quote exists and says what the summary claims. Expect to reject some of it, and record which claims you dropped and why, because that record is what stops the same claim reappearing at the gate. Synthesis across forty documents is what AI is good at. Being the only reader of the evidence is what it is not.

Re-price the epic in the open

Discovery ends with a number, not a narrative.

Take the epic's planned share and confirm it, change it, or set it to zero and close the epic. Show the arithmetic in four lines: how many people the behaviour applies to, the adoption or conversion rate the evidence supports, value per event, and the realisation factor your own delivery history justifies. If you land seventy per cent of what you plan, apply seventy per cent now rather than discovering it in month three. Record the baseline the epic starts from as well, because validation cannot prove a lift without one. A smaller number is a successful discovery.

Write the decision and clear the gate

Discovery is finished when a written decision sits on the epic: proceed at this number, reshape to this smaller scope, or stop.

Underneath it, list the questions you knowingly proceeded without and name who owns each one. Proceeding on an unanswered question is a decision someone owns, not an omission nobody noticed. Then take it through the gate your team's mode requires. In an AI-augmented team the discovery output becomes the first product-approved story attached to the epic, which ready-for-dev demands alongside product and engineering approval. If the epic cannot clear the gate, say so in the decision rather than letting it drift.

Book the rematch at outcome validation

Write the discovery estimate, in currency, into the epic itself, so outcome validation reads it without archaeology.

Every live outcome is validated monthly, and the epic sits in value monitoring until its value is confirmed or deliberately written off. When that happens, compare what landed against what discovery predicted and record the ratio as a single number. After three or four quarters you have a calibration curve built from your own work, and discovery stops being an argument about optimism and becomes an argument about your own history. This is the loop almost nobody closes, and it is what makes the next discovery cheaper.