This same problem keeps showing up with almost every team I work with. Their delivery is genuinely good: increments flow to production, the demos land, the commitments hold. Fourteen demos in a row without a miss. And eighteen months in, the product is going nowhere. Usage is flat, the customers who asked for those features barely touch them, and nobody can point to a single failure — because there wasn’t one. Every decision was executed faithfully. The decisions were just… old.
That team doesn’t have a delivery problem. Delivery is the half they mastered. What’s missing is the other half: a standing way to test whether what they decided to build is still worth building. A way to avoid building the wrong things. I wrote about the symptom in You delivered every feature and nobody’s happy. This article is about fixing the problem.
If you’re new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.
The playbook calls the solution “continuous discovery.” It’s wired through every chapter as a first-class practice. What I’ll describe here is what that solution looks like: why front-loaded discovery quietly fails, how the two-track model works, and the machinery — the loop, the hypothesis log and the smallest version of the practice you can start right away.
Discovery isn’t a phase
If you’ve run the playbook’s early activities you’ve done real discovery. Value mapping, event storming, personas, use cases — good workshops that produce a rich picture of the domain and a stack of decisions what’s valuable.
Now look at what those outputs actually are. A value map points to where the value lives. A persona defines who your user is and what they need. A use case describes how they’ll behave. Claims — every one of them. Hypotheses stated with the confidence born from a workshop decision. And hypotheses decay: markets shift, users change and the product itself changes the behavior it was modeled on. The half-life of a workshop decision is shorter than your roadmap.
Front-loaded discovery treats those claims as settled the day the workshops end. From there, most teams iterate hard on build decisions — smaller stories, faster pipelines, cleaner increments — while the what-to-build decisions age. The choice was made, never revisited. A team that discovered once and delivers forever is a feature team with good-looking paperwork.
Five signs it’s already costing you
The absence of discovery doesn’t announce itself loudly or early. It shows up sideways, after you’ve already paid the high price of delivering a stale product:
The value map hasn’t changed since its workshop. Value mapping re-runs every increment; if its inputs never move, the team is iterating on build decisions while the what-to-build decisions get stale.
The backlog says “the customer asked for it.” A request is a signal, not evidence. More on that below — the worked example show exactly this.
Demos land flat. The team ships what was specified and the reaction is underwhelming. The gap between specified and wanted is what weekly customer contact would have closed.
Prioritization runs on opinion. When nobody holds fresh evidence, the loudest voice wins. Real discovery gives the product manager standing to say “we disproved that” instead of “I think.”
The designer’s calendar is all production work. If every hour goes to delivery artifacts, nobody owns learning.
Two or three of those and you don’t have a prioritization problem or a communication problem. You have a discovery gap. The playbook has always been iterative — the subway map draws the feedback channels right on it — but channels only help if fresh evidence rides them. That’s the gap the discovery track closes, and closing it makes the playbook’s product-operating-model claim true rather than cosmetic.
Two tracks, one team
The model is simple to state. The delivery track ships increments. The discovery track runs ahead of and alongside it, continuously validating what to build next, so that by the time work reaches increment selection there’s evidence behind it.
The idea has a lineage worth knowing. Marty Cagan described the parallel structure back in 2012, under a name Jeff Patton coined, “dual-track Scrum.” Cagan later retired the label — it pulled attention toward process and away from the principle — and settled on the terms the playbook uses: continuous discovery and continuous delivery.1
Ownership matters more than mechanics here. Discovery belongs to the product trio: the product manager and product designer run it as a pair, and the tech lead joins when the question is feasibility. It is not a separate research function, not a quarterly study and emphatically not an upstream “product office” that hands validated features to delivery teams.
I’ve seen operating models built on exactly that split — discovery in an office, delivery in the team, “validated features” as the handoff — and failure showing up in twos. Downstream, teams become order-takers: accountable for output, disconnected from the customer, unable to push back with evidence because they never touch any. Upstream, the office detaches: it validates features against research instead of against a shipping product, and its confidence grows precisely as its feedback loop lengthens. Both failures come from the same decision: separating the people who learn from the people who build. Keep discovery in the team and neither problem gets a foothold.
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
Killed experiments are wins
Here’s what makes the whole practice pay off: the cheapest feature is the one you never build.
Consider what a feature actually costs. Weeks of the team’s capacity to build it. Code and complexity you carry forever. A slot on the roadmap that something better didn’t fill. And the slow erosion that comes from shipping things nobody cares about. It might not be a bad feature, but it’s not a good feature.
Now price the alternative: the same idea, written as a testable claim and killed a week later, after an interview and a prototype. Same outcome for the product — the feature doesn’t exist — at a fraction of a percent of the cost.
The economics compound with time, too. Boehm’s cost-of-change curve — the exponential behind How to fix a $25 bug before it becomes a $37,500 problem — applies to misconceived features exactly as it does to defects. An idea killed in discovery costs an interview and a prototype. The same idea killed after release has already burned more time and effort than it ever should have.
That’s why a healthy discovery practice treats killed hypotheses as wins, counts them and says so out loud. A team that kills nothing has stopped discovering and started confirming: it runs just enough research to bless decisions already made. And if killing an idea is embarrassing, people stop proposing testable ideas at all, which quietly ends discovery while the meetings continue.
Making that culture real takes machinery: a loop that generates cheap, fast verdicts and an artifact that keeps them honest and visible. That’s the rest of this article.
