How to run product discovery research

Two weeks at most, and one week for anything under roughly £100k of planned value. The constraint is not research quality but the quarter. The epic has to ship inside the same twelve to thirteen weeks, so every day in research is a day off the build. Tenhaw's own evidence work runs in that box, and a proof of concept for a London specialty insurance business took PDFs through to business intelligence on Azure in a fortnight, over ground the client had circled for roughly a year. If two weeks cannot answer the question, reduce the question to the single assumption that most threatens the number, or move the epic out of the quarter and say why.

No. Discovery is for epics whose planned currency share rests on an assumption you cannot evidence. If the behaviour is already visible in your data, the value is a rate change you can calculate, and nothing you could learn would change the scope or the number, skip it and build. Running discovery on an epic whose answer is already known is the most common way a research phase turns into a parking bay.

The product manager who owns the epic, with an engineer present for at least one session and a second person reading the raw evidence. Whoever wants the epic to succeed should not be the only one reading the transcripts. Tenhaw staffs its own engagements the same way, with teams of two or three senior people and partner oversight on every one, so the second reader is a named person rather than a spare pair of hands. It is the same reason the kill condition is written and signed off before fieldwork rather than after the results arrive.

It can do the synthesis, which is the slow part, reading forty documents and returning what they support, contradict and leave silent, with references. Tenhaw runs the same split on paid work, a model doing the corpus pass and a named person checking every reference, with partner oversight on every engagement. It cannot be the only reader. Models compress away the outlier, and the outlier is often the finding. Ask for file and line references, open them, and treat anything without a traceable source as not yet true.

A kill condition is the measurable result that would make you stop or reshape the work, written down before the research starts. It has to be a number, not a mood. Fewer than four of eight interviewees rebuild orders from history, say, or under a quarter of accounts show the behaviour in the data. Product and engineering sign it off before fieldwork begins, because agreeing what would change your mind is cheap beforehand and nearly impossible once the results are in. Without one, no finding is ever obviously bad enough to act on, and discovery drifts into confirming what the team already wanted to build.

You change the number in the open and treat that as a success, because a smaller honest figure beats a large fiction discovered in month three. Tenhaw reports a month that delivers no measurable value as a failed month. Show the arithmetic in four lines: how many people the behaviour reaches, the adoption rate the evidence supports, value per event, and the realisation factor your delivery history justifies. If the revised figure still clears the threshold you set at the start, proceed at the new number and re-sequence it against the other epics. If it falls below that threshold, the epic leaves the quarter, and the gap it leaves in the outcome's target gets argued in week three rather than week thirteen.

Attached to the epic it belongs to, in a markdown repository the whole team and your models can read, not in a shared drive nobody revisits. One source per file: full interview transcripts, the query you ran alongside its output, ticket exports, each opening with a date, where it came from and how it was collected. Do not summarise on the way in, because a tidy summary written during collection is where the inconvenient quote disappears. The approval gate and monthly outcome validation both look for evidence on the epic, so keeping it anywhere else guarantees archaeology later.

Not if the output has to defend a currency figure. Interviews are the right tool for desirability, six to eight with people who actually have the problem, recruited from support tickets, churned accounts and lapsed users rather than your fans. But at least one method has to return a number, which means querying the behaviour you already hold, order history, funnel drop-off, ticket volumes, and pulling the denominator first so you know how many people the work can reach. People also say things their behaviour contradicts; in one worked example, two interviewees praised a proposed template feature and then explained they would order weekly whatever happened. The data settles it.

A realisation factor is the share of planned value your team historically delivers, applied to every new estimate before anyone commits to it. If your last four quarters landed seventy per cent of what was planned, apply seventy per cent now rather than discovering the shortfall in month three. You build it by closing the loop: write the discovery estimate into the epic, compare what landed at outcome validation, and record the ratio. Tenhaw publishes the method in full, free to adopt, so a team can run that loop without hiring anyone. After three or four quarters you have a calibration curve built from your own work, and estimating stops being an argument about optimism and becomes an argument about your own history.

No. Discovery ends in a revised number and a written decision on the epic: proceed at this figure, reshape to a smaller scope, or stop. Underneath the decision, list the questions you knowingly proceeded without and name who owns each one, because proceeding on an unanswered question is a decision someone owns, not an omission nobody noticed. The 500-team target operating model James Rooney co-led at HSBC Global Payment Solutions was piloted rather than presented. A report is where findings go to be admired; a decision is something the approval gate can act on. If the research cannot yet produce one, say that plainly and move the epic out of the quarter rather than letting it sit in research looking busy.

They do different jobs, and the timeboxed pass is the one an approval gate can act on. A continuous habit keeps a research cadence running whatever the roadmap is doing, which is useful for building a picture of your users over time. The timeboxed pass runs inside one epic's research phase, is capped at two weeks and at one week for anything under roughly £100k of planned value, and ends by confirming, changing or zeroing that epic's planned share of the outcome's currency target. Its trigger is narrower too. If no finding would change the number, the scope or the decision to build, you skip it and start building.

It is good evidence of interest and weak evidence of value, so discount it hard before it reaches the number. In one worked example a save-as-template button shown to 900 accounts for two weeks was clicked by 31 per cent, and the re-price used 20 per cent sustained use instead, because a click costs nothing and changing how you order every week costs something. Pair it with behaviour you already hold, such as order history or funnel drop-off, then apply the realisation factor your own delivery history justifies. A click-through rate carried straight into a currency figure is the quickest route to arriving short in month three.

Eight steps inside the box, plus a rematch at outcome validation later. 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. State the hypothesis with a measurable kill condition and have product and engineering sign both off before fieldwork starts. Put the end date on the epic, recruit interviewees on day one, and run at least one method that returns a number rather than only conversations. Convert every source into markdown, run the contradiction pass and check its references yourself, re-price the epic, then write the decision on it. The worked example lands in nine working days of the two-week box.

No, that is outcome shaping, and it is a different question. Discovery tests whether an epic's planned share of a priced outcome survives contact with reality, so it cannot start until you can 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. If nothing has been priced, the question in front of you is whether the outcome can carry a credible number at all. Set the outcome first, break it into epics, then run discovery on the ones whose share rests on something you cannot yet evidence. Fieldwork first produces interesting findings and no decision.

Yes, and it changes the fieldwork rather than just the write-up. In an AI-augmented team, where a developer writes the code and the model assists, this guide runs as written. In an AI-native team there is no child story to hold the detail, so discovery has to produce the key user journeys and the test requirements that go into the outcome ticket itself. That means capturing the sequence people actually follow, the edge cases and the failure states, not sentiment about whether they would like the feature. It raises the bar on the evidence corpus, because the same markdown files are what the model builds from. Tenhaw's engineering handbook targets that reader, 72 rules on GitHub written to be enforced by an agent.

Because you are already in the data, and nobody goes back for it later. Discovery predicts a two-point lift, the epic ships, and if nobody recorded what the rate was the week before, validation four months on has a number with nothing to compare it against and the epic gets closed on an argument instead of evidence. Record it in the same pass that produces the denominator and the adoption rate, and write it into the epic beside the revised currency figure. The worked example on this page notes a 21 per cent repeat order rate over the prior 90 days, because a lift needs a starting point.

Pull the denominator before you count anything else. Query behaviour you already hold, order history, funnel drop-off, ticket volumes or cancellation reasons, and start from the total population the epic could ever touch, so every percentage after it has a ceiling. In one worked example that is 4,200 active trade accounts, of which 1,600, or 38 per cent, place orders where at least 80 per cent of lines match a previous order. The 1,600 is the reachable group, not the value. Adoption, the share of that group whose behaviour actually changes, and value per event come after it. Skip the denominator and you finish with a rate and no idea what it applies to.