Continuous Discovery For Delivery Teams

Most organisations that say they do discovery do it as a phase. There is a period at the front where a product person and perhaps a designer talk to customers, produce findings, convert them into a defined scope, and hand that scope to a delivery team. The phase has a start, an end, a deliverable and a gate. It is structurally the requirements stage of a waterfall, and it produces the same failure: decisions made at the moment of maximum ignorance, treated as settled by the time evidence starts arriving.

The alternative is not more discovery. It is discovery that never stops and never blocks. Teresa Torres's formulation of continuous discovery — a small trio of product, design and engineering making weekly contact with customers in service of a specific outcome — is the clearest statement of the practice, and its most important claim is about frequency rather than method. A team that speaks to two customers every week accumulates a different kind of knowledge from one that runs a six-week research project annually, even if the annual project is more rigorous. The weekly team is never more than seven days from correcting a wrong belief. The annual team can be wrong for eleven months.

This is harder than it sounds, for reasons that have almost nothing to do with research skill and almost everything to do with delivery pressure, calendar politics and, in enterprise contexts, genuine difficulty getting near a customer. What follows is about making it work under those conditions.

Discovery as a phase is still waterfall

The tell is the handover. Somebody produces an artefact — a research report, a set of requirements, a validated design — and somebody else receives it and builds from it. Four problems follow.

The people who built the understanding are not the ones making the thousand small interpretive decisions during implementation, so the understanding degrades in transit. Engineers, frequently the best source of cheap alternative solutions, are absent from the conversation where alternatives were considered. Evidence arriving after the gate has no route back, because reopening agreed scope is politically expensive. And the queue between phases becomes a place where work sits waiting — the ordinary batch and queue problem applied to knowledge rather than code.

Run continuously, none of those four happen, because there is no gate to accumulate them. Ideas are tested small and cheaply, in a stream, by the people who will build them.

Weekly contact with customers

The highest-return practice is unglamorous: at least one conversation with a real user or buyer every week, involving the product person and ideally a designer and an engineer.

The frequency does most of the work. Weekly contact changes the conversation: you are not gathering requirements in a set-piece session where the customer feels obliged to produce a wish list, you are maintaining a relationship in which you can ask a small question, get an answer, and ask a better one next week. Small and frequent beats large and occasional for the same reason it does in delivery — smaller batches, faster feedback, less sunk cost in any single wrong belief.

Three rules make these conversations useful rather than merely frequent.

Ask about the past, not the future. People are unreliable predictors of their own behaviour and reliable reporters of what they actually did. "Would you use a feature that did X" produces polite affirmation. "Walk me through the last time you had to do X" produces data. This is the core of the jobs-to-be-done interviewing style, and it is the difference between research that validates your existing plan and research that changes it.

Recruit continuously, not per study. The largest cost in customer contact is arranging it. Teams that book interviews only when they have a question will do it rarely, because the setup cost always exceeds this week's curiosity. Build a standing schedule — same slot every week, a pool of participants recruited in advance — and the marginal cost of the next conversation falls to nearly nothing. This is a flow problem: remove the setup cost so the batch can shrink.

Bring an engineer. Not as an observer. Engineers hear different things, because they are listening for what is technically cheap. A team whose engineers have heard the customer describe the problem in their own words makes better implementation decisions all week, without anyone having to write those decisions down.

The opportunity solution tree

Weekly conversations produce a lot of material and no structure. Without something to organise it, teams accumulate a pile of anecdotes and revert to deciding by opinion — usually the opinion of whoever is most senior in the room.

The opportunity solution tree is the most useful structuring device in common use. At the root sits the outcome you are trying to move, expressed as a measurable change in behaviour. Beneath it sit opportunities: the customer needs and pain points you have actually heard, clustered where they relate. Beneath each opportunity sit candidate solutions, and beneath each solution the experiments that would test it.

The structure buys you three things.

Solutions must attach to an opportunity, and opportunities to an outcome. A solution with no parent is somebody's preference. This is where most stakeholder requests reveal themselves — not as bad ideas, but as ideas with no traceable connection to what the team is trying to achieve, which makes them a conversation about strategy rather than about the backlog.

The choice becomes explicit at the opportunity level. The important decision is not which of three solutions to build; it is which customer problem to attack first. Teams that skip it end up efficiently delivering a solution to a problem that was never worth solving.

Genuine alternatives appear. Once an opportunity is named, a team can generate several candidate solutions against it, which is the only condition under which choosing one means anything. A single idea taken straight to build is not a decision, it is an assumption.

Keep the tree visible and living. It is not a deliverable. Its value is that it changes weekly as new conversations land, and a tree unchanged for a month means discovery has stopped even if the interviews are still happening.

Assumptions and the riskiest-assumption test

Every candidate solution carries a set of beliefs that must all hold for it to work. Assumption mapping is the practice of writing them down before building, and it takes about half an hour. For a given solution, list what must be true across five categories.

Desirability. Do customers want this enough to change what they currently do?

Viability. Does it work for the business — commercially, legally, and in terms of who supports it?

Feasibility. Can we build it with what we have, at a cost proportionate to the return?

Usability. Can people work out how to use it without help?

Ethics and second-order effects. What happens to the people this is not designed for, and what behaviour does it encourage at scale?

Then place each assumption on two axes: how critical it is — does the whole solution collapse if it is wrong — and how much evidence you have. Those that are both critical and unevidenced are worth testing, and there are usually only one or two. The rest can be assumed and revisited if the thing fails.

Test the riskiest with the cheapest instrument that would genuinely change your mind. That phrase is doing the work. A test you would rationalise away on a negative result is not a test; it is a procurement exercise for permission you have already granted yourself. Decide the rule before you run it: if fewer than this many, we stop.

Assumption type	Cheap tests that actually discriminate
Desirability	Interview about past behaviour; offer the thing and see who takes it; a landing page with a real commitment attached
Viability	Pricing conversation with a real buyer; walk the support and legal path end to end
Feasibility	Timeboxed technical spike against the hard part, not the easy part
Usability	Prototype in front of five users; count how many complete the task unaided

Running discovery alongside delivery

This is where most implementations break. A team is told to do discovery, protects some capacity for it, and within two sprints has reconstructed a phase gate — discovery runs a sprint ahead, produces a specification, hands it over. Same waterfall, shorter iterations. Four things keep the streams genuinely parallel.

Same people, different activity. Discovery is not a separate team or squad. It is a trio drawn from the delivery team, spending a modest, protected share of the week on it. The moment discovery has its own headcount it acquires its own deliverables and its own handover.

No handover artefact. The output is not a specification. It is a shared understanding, a tree everyone can see, and a few decisions. If the transition requires a document to carry the meaning, you have a phase.

Decouple the cadences. Discovery does not run on the sprint boundary. Conversations happen weekly, tests take as long as they take, decisions land when they land. Forcing discovery into a sprint container creates artificial batch boundaries and pressure to conclude before the evidence is in.

Accept a variable lead. Some discovery work will be ready long before there is capacity; some will not be ready when the team wants it. Both are fine. What is not fine is a rule that delivery may only build things that have completed discovery, because that rule creates the queue.

A well-run team is not building only validated things. It is running a portfolio in which the size of the bet is proportional to the confidence: low confidence, small bet; high confidence, larger commitment. Discovery's job is not to eliminate uncertainty before building. It is to make sure the size of what you build matches how much you actually know.

When you are B2B and access is scarce

The standard advice assumes a consumer product with thousands of reachable users. Enterprise teams often have a few hundred customers, an account management function guarding them, contractual constraints, and users who are not the buyers. The practice still works; the instruments change.

Use the contact your organisation already has. Support tickets, implementation calls, onboarding sessions, account reviews, the sales cycle. Your organisation speaks to customers constantly; those conversations are simply not routed to the product team. Putting an engineer onto weekly support triage, or a product person onto sales discovery calls, requires no new access and provides a steady stream of unfiltered problem statements.

Negotiate with account management rather than around them. The protectiveness is usually rational — they own a relationship a badly run research call can damage. The workable arrangement is that they attend, they approve the participant list, and you commit to never using the session to sell or to promise. Most will accept that trade once, and once a customer has enjoyed the conversation the objection disappears.

Build a customer advisory group. A standing group of a dozen or so customers who have agreed to regular contact converts recruitment from a per-conversation negotiation into a fixed arrangement. It is the highest-return investment available to an enterprise product team and typically takes a quarter to establish.

Separate the buyer from the user and talk to both. The person who signs is rarely the person who uses it daily, and their problems differ. Discovery that speaks only to buyers produces products that demo well and are resented in use; discovery that speaks only to users misses the commercial reality that determines renewal.

Substitute instrumentation for volume. With few customers, product analytics carry more weight per observation and are often underused. Knowing which accounts abandoned a workflow at which step tells you where to point the next conversation, which makes a scarce interview slot far more valuable.

Treat one customer's request as a hypothesis, not a requirement. The characteristic enterprise failure is that a large customer asks for something and it enters the backlog as a commitment. Sometimes that is correct — a renewal genuinely depends on it. Often it is one organisation's local workaround, and building it adds a permanent maintenance cost every other customer pays for. Ask what problem sits underneath, and whether anyone else has it.

What to do on Monday

Book three customer conversations for the next three weeks — same slot, same day, whoever you can reach. Do not design a research programme or write a discussion guide beyond three questions about what the person did last time they faced the problem, and take an engineer to each one. The habit is the thing; rigour comes later, and comes naturally once the habit exists.

Then take the largest item in your backlog and spend half an hour writing down everything that must be true for it to deliver the value claimed for it, marking each as evidenced or assumed. If the critical ones are assumed, test one before another line of code is written against it.