Blog · Personal ·
Discovery Is the Only Cheap Insurance You'll Ever Buy
Building feels like progress, but discovery prevents expensive mistakes—proper validation of core assumptions before development saves studios time, money, and
Discovery Is the Only Cheap Insurance You'll Ever Buy
Every studio team has felt it. Someone pitches an idea in a Monday meeting, everyone nods, and by Wednesday there's a Figma board and someone's already talking sprint velocity. It feels productive. It feels like momentum. It's usually the most expensive mistake a studio can make, and it happens because building feels like progress and thinking doesn't.
That's the trap. Building gives you something to show. Discovery gives you something to know. Founders and studio operators are wired to prefer the former, because a wireframe looks like proof of work and a validated assumption just looks like a Google Doc nobody reads. So teams skip the boring part and jump straight to the fun part, and then spend the next six months discovering, slowly and expensively, all the things a week of proper discovery would have told them for almost nothing.
The seductive shortcut
Here's why it happens. Build feels like control. You can point at a sprint board and say "we shipped this." You can't point at a validated assumption in the same way, it just sits there quietly not causing problems, which is a much less satisfying thing to report to a partner or an investor. So there's a bias baked into the incentive structure itself: activity is visible, rigour isn't.
There's also a comforting story teams tell themselves, which is that you'll "figure it out as you build." Sometimes that's true. Mostly it's a way of avoiding a conversation nobody wants to have, which is: what if this doesn't work? Better to be busy than to sit with that question for two weeks.
What real discovery actually looks like
A two-week wireframe sprint is not discovery. It's a very expensive way of drawing a picture of an assumption. Real discovery doesn't produce a deliverable that looks impressive in a deck. It produces evidence, uncomfortable evidence usually, about whether the underlying premise of the business survives contact with actual humans and actual constraints.
Proper discovery means talking to the people who'd supposedly pay for this, not the people who'd politely admire a prototype. It means mapping who actually holds budget, and how deep the workflow you're trying to replace or improve really goes, because most ideas die not on the "does anyone want this" question but on the "who's allowed to say yes" question. It means testing the riskiest assumption first, not the easiest one to mock up. A wireframe sprint tests "can we design this." Discovery tests "should this exist at all." Those are different questions, and only one of them is expensive to get wrong later.
Five assumptions worth pressure-testing before you build anything
There's a short list that matters more than the rest, and it's worth going through properly rather than assuming it's obvious.
First: who has the problem, specifically, and is it their problem or someone else's problem they're describing on behalf of a colleague. Second: what they currently do instead, because "nothing" is a red flag and "a janky spreadsheet that works fine" is an even bigger one. Third: who actually controls the budget and whether that person has ever been in the room you've been having conversations in. Fourth: what would need to be true for someone to switch away from their current workaround, not what would make them say something's "interesting." And fifth: whether the cost of being wrong compounds. Some mistakes are cheap to unwind. Others quietly poison the codebase, the team's morale, and the runway, all at once.
Get these wrong and no amount of good engineering saves you. You just built the wrong thing well.
Why studios, specifically, have no excuse here
This is where studios are different from a lone founder chasing conviction. A studio isn't betting on one idea, it's building a portfolio of bets, and it bears the downstream cost of being wrong across every single one of them: the engineering time, the reputational cost with investors, the opportunity cost of a team that could've been on the next thing. That structural exposure should make studios the most rigorous discovery practitioners in the industry, not the most eager to skip it.
And yet. Because studios move fast by design, there's a temptation to treat discovery as a formality, something you nod through on the way to build. That's backwards. The studio model only works if the discovery phase is genuinely allowed to kill ideas, not just refine them. If every idea that enters discovery survives it, you're not doing discovery, you're doing decoration.
Knowing when to kill it versus when to shrink it
Not every failed assumption means the idea's dead. Sometimes it means the scope was wrong, not the premise. If the core problem is real but the audience is smaller than you thought, that's a pivot: narrow the wedge, find the real buyer, cut the parts of the vision that were aspirational rather than validated.
But if the core assumption fails, if nobody actually has the problem in the way you imagined, or the workaround they've got is good enough that switching costs will never clear, that's not a scope problem. That's a kill. And killing it early, before a team's spent months and a chunk of runway proving what a fortnight of proper conversations would've shown, is the single highest-leverage decision a studio makes all year.
Nobody celebrates the idea that got killed in week two. There's no demo day for it. But it's the cheapest win available, and studios that treat discovery as a genuine gate, rather than a rubber stamp on the way to the build queue, are the ones who stop paying for the same mistake twice.