How to balance discovery and delivery
It is the question clients ask me most, and the honest answer irritates people: there is no fixed ratio. An early-stage team and a scale-up should be spending their weeks completely differently, and the thing that decides it is not your process. It is how much you still do not know.
"How do we balance discovery and delivery?"
It is the single most common question I get from clients, and people want a number back. One discovery day per sprint. A 70/30 split. A standing Wednesday.
There is a number. It is just not a constant, and adopting someone else's is how teams end up doing discovery theatre.
Early stage: roughly 80% discovery
If you are pre Product-Market Fit, most of your team's effort should go into working out what is worth building at all. Around 80/20 in favour of discovery is what I recommend, and it surprises founders every time.
The reason is not that building is bad. It is that you are in unknown territory and nearly every assumption you hold is untested. The goal at this stage is not a shipped feature. It is to establish that the problem is worth solving and that the people you picked are frustrated enough to change what they currently do.
Build before that and you are not moving fast, you are committing early. Most of what you write gets thrown away, and you learn very little from throwing it away, because a feature shipped without a hypothesis behind it tells you nothing when it flops.
As you mature, the ratio flips
Once the problem space is genuinely understood, invert it. Roughly 20% discovery, 80% delivery.
You are no longer asking whether the category exists. You know who the customer is, you know the core job, and the work is optimising, extending, and serving more of them properly. Keep running an 80% discovery operation at that point and you are re-answering questions you settled two years ago while competitors ship.
What that 20% looks like matters more than the number itself. It is not a research function parked off to one side, producing decks. It is the trio spending part of every week in front of customers so the next bet is not a guess: small, continuous, and attached to work actually in flight.
Both numbers are rules of thumb from my own engagements, not a benchmark. Treat them as an opening position to argue with, not a target to hit.
The actual rule: split on risk, not on the calendar
Stage is only a proxy. Risk is the real variable.
This is why a fixed split fails even inside one company. A mature team building a payments integration they have built twice before needs almost no discovery. The same team entering a new segment next quarter is back to 80/20, no matter how old the company is.
It also explains why "one discovery day a sprint" is such a comfortable answer. It is stable, it fits the calendar, and it is completely disconnected from where the risk actually sits.
How to set your ratio this quarter
Take an hour with your product trio and do this. It is not complicated. It is just rarely done.
- List the bets on your roadmap for the next quarter. Not tasks. Bets: things you believe will move an outcome.
- Write the assumption each one rests on, then mark how much evidence you actually hold. "Three sales calls mentioned it" is not evidence.
- Sort by how expensive it would be to be wrong. A two-week build on a shaky assumption outranks a two-month build you have already validated.
- Look at where the hours went last month and compare. The gap between the two lists is your answer, and it is usually embarrassing.
Teams that run this rarely land on a tidy number. They land on something like "our top three bets are unvalidated and we spent last month on the fourth one", which is far more useful than any ratio.
The two ways this goes wrong
The delivery treadmill. Discovery gets scheduled and then cut, every sprint, because delivery has a date and discovery does not. This is how a team quietly becomes a feature team rather than a product team: busy, on time, and unable to name what changed for a customer.
Discovery theatre. The opposite failure, and it is more common in teams who recently read a good book about this. Interviews get run, boards get filled, nothing gets decided, nothing ships. Discovery that does not end in a decision is a research hobby.
The tell for both is identical: nobody can name the decision that last month of work produced.
The fix is the same in both directions, and it is not a calendar block. Attach the discovery hours to a named decision with a date on it. "We decide by the 20th whether to build the approvals flow, and here is what we need to know before then" survives a busy sprint. "Discovery Wednesday" does not, because nobody can say what skipping it costs.
Why the split is worth arguing about
The case for putting real hours into discovery is not philosophical. Teams that do it properly cut their risk of failure by around 75%, products developed with discovery succeed around 83% of the time against roughly a coin flip without it, and you save about half of the avoidable rework. That last one is the version finance understands.
Those numbers come from doing discovery in proportion to your actual risk, though. Not from booking a Wednesday.
If the split keeps collapsing back to delivery no matter what the team agrees in the retro, the problem is not discipline. It is the operating model around them, which is what a Product Model Transformation is for. And if you are earlier than that, still trying to find a problem worth solving, start with discovering what to build before you code it.
.svg)
.svg)
