Discovery Loop": Everyone Skips This Step. It's Quietly Killing Your Results
In this article
**Bottom line:** The "discovery loop" — the practice of testing a product assumption with real users before and during building, not just after launch — is the first thing teams cut when a deadline gets tight.
Standish Group's long-running CHAOS research, cited for years by product leaders like Marty Cagan, puts the number of shipped software features that go rarely or never used at roughly 64%.
Teresa Torres' "Continuous Discovery Habits" (2021) built an entire framework around fixing this with weekly customer touchpoints, and the teams that adopt it consistently ship fewer, sharper features.
Skipping discovery doesn't make you faster. It makes you busy.
Stop calling it "moving fast." I'm serious.
What most teams call speed is actually just skipping the one step that tells you whether you're building the right thing — and I've watched it happen at three different companies I've covered this year.
I've spent the better part of a decade writing about how tech teams actually work, not how they say they work in the all-hands deck.
And the pattern is so consistent it's almost boring: the team that ships the most features is rarely the team that wins. It's the team that ships the fewest features that actually get used.
The Sacred Cow: "We Don't Have Time to Validate"
Here's the conventional wisdom, and I get why it's seductive. Engineering time is expensive. Every sprint spent "talking to users" feels like a sprint not spent shipping.
Product managers get judged on velocity. Executives want a roadmap with dates on it, not a roadmap with question marks.
So the instinct is completely rational: **skip the loop, build the thing, find out later.**
Five years ago, in a zero-interest-rate world where growth funded almost anything, this actually kind of worked. You could ship ten mediocre features, let two of them stick, and call it a strategy.
Nobody was counting the cost of the other eight.
That world is gone. Budgets tightened, teams got smaller, and every unused feature is now a visible tax on a shrinking engineering org.
The math that used to hide behind growth is now sitting right there on the P&L.
The Evidence: What Skipping Discovery Actually Costs
This isn't a vibes-based argument. The data on wasted build effort has been sitting in plain sight for years — most teams just don't want to look at it.
The 64% problem
The Standish Group's CHAOS research — the same body of work that tracks software project success and failure rates across thousands of projects — has repeatedly found that **around 64% of features built into software products are rarely or never used.** Marty Cagan, founder of the Silicon Valley Product Group and one of the most cited voices in product management, has referenced this figure for over a decade to make one point: most engineering effort at most companies produces nothing of value.
Sit with that. Not "underperforms." Not "needs iteration." *Never used.*
The interview gap
Teresa Torres surveyed product teams while researching "Continuous Discovery Habits" and found something almost funny in how consistent it was: teams that talk to customers on a **weekly** cadence make dramatically better prioritization calls than teams that run discovery in occasional bursts — a big research push before a redesign, then silence for two quarters.
The weekly habit isn't about volume of insight. It's about never letting the gap between "what we believe" and "what's true" get wide enough to build something disastrous on top of it.
The rebuild tax
Ask any senior engineer off the record and you'll hear the same story with different names attached. A feature ships.
It flops quietly — not enough to trigger a postmortem, just enough to sit there unused in the product.
Six months later, someone rebuilds a version of it, slightly different, because nobody wrote down that the first version already answered the question.
**The cost of skipped discovery doesn't show up as a line item. It shows up as déjà vu.**
The "loud user" trap
Teams that skip structured discovery don't skip user input entirely — they just get it from whoever's loudest. The enterprise customer with the VP's cell phone number.
The support ticket that got escalated.
The one Slack message from a PM's friend who happens to use the product. **That's not discovery. That's whoever screamed last, mistaken for market signal.**
The Real Problem Nobody Talks About
Here's the part that stings: the discovery loop isn't skipped because teams don't know it exists. Every PM has read the blog post. Every engineering leader has sat through the workshop.
It's skipped because **discovery makes uncertainty visible, and visible uncertainty is career-risky.**
A roadmap with dates on it looks like leadership. A roadmap that says "we're going to spend two weeks finding out if anyone wants this" looks like you don't have a plan.
So teams perform certainty they don't have, because the org chart rewards the performance more than the accuracy.
This is the actual disease.
Not laziness, not ignorance — **incentive structures that punish honesty about what you don't know yet.** A PM who says "I need to validate this" in a quarterly planning meeting is taking a bigger political risk than a PM who confidently commits to a date and quietly hopes it works out.
We built entire management cultures that reward the second person and sideline the first.
And the irony is brutal: the teams performing the most certainty are usually the ones producing the most waste, because confidence without validation is just a guess wearing a suit.
What You Should Do Instead
You don't need a research department. You don't need a six-week discovery sprint before every ticket. Here's what actually works, based on what the teams doing this well have in common.
**Talk to five users a week, every week, no exceptions.** Torres' research is specific about this — not a big quarterly study, a small continuous habit. Thirty-minute calls.
Same day each week if you can manage it, so it becomes infrastructure instead of an event.
**Write the assumption down before you write the code.** One sentence: "We believe [type of user] will do [specific behavior] if we build [specific thing]." If nobody can write that sentence, nobody actually knows what they're building yet.
**Ship the smallest possible test of that assumption.** Not the full feature — a fake door, a concierge version, a landing page, a Wizard-of-Oz prototype where a human fakes the automation behind the scenes.
Cagan's SVPG teams call this "the smallest thing that tells us we're wrong fast."
**Kill ideas in the doc, not in production.** It is dramatically cheaper to be wrong on a whiteboard than to be wrong in a shipped feature that now needs a deprecation plan, a migration path, and an apology to whoever built on top of it.
The Uncomfortable Truth
The teams that skip the discovery loop aren't moving faster than everyone else.
They're just moving the cost of being wrong to a later date, when it's more expensive, harder to trace, and easier to blame on "the market" instead of the decision that actually caused it.
**Speed without discovery isn't velocity. It's debt with a delayed invoice.**
So here's the question worth sitting with: how much of what your team shipped this year would survive a single honest conversation with the people who were supposed to use it?
Has your team ever quietly killed a feature nobody used — or worse, kept maintaining one nobody asked for? I want to hear the story in the comments.
---
