Blog · Personal ·
The Discovery Ritual Nobody Actually Does
Most studios skip real discovery or fake it with sticky notes and assumptions. Here's what actual discovery looks like and why studios can't afford to skip it.
Every studio founder says they believe in discovery. Almost none of them do it properly. What they do instead is a two-week sprint with some sticky notes and a Figma file, and they call that "de-risking the idea", and then they build the thing anyway because, deep down, everyone in the room already wanted to build the thing. That's not discovery. That's a ritual you perform before doing what you were always going to do.
I get why. Building feels like progress. Discovery feels like stalling. You've got a team on the clock, a founder who's read too many "ship fast" tweets, and a backlog itching to be populated with tickets. Sitting in a room asking uncomfortable questions about whether anyone actually wants this thing feels, frankly, like admitting weakness. So teams skip it, or fake it, and the fake version is almost worse than skipping it entirely, because it gives everyone false confidence. You did "the discovery phase". Box ticked. Nobody has to feel bad about what happens next.
Here's the uncomfortable bit: real discovery is slower, less flattering, and far more likely to end in "don't build this" than a wireframe sprint ever will. A wireframe sprint is designed to produce artefacts. Real discovery is designed to produce answers, and sometimes the answer is no.
What real discovery actually looks like
A two-week wireframe sprint gives you a clickable prototype and a deck of assumptions dressed up as insights. It feels rigorous because there are Post-its involved. But nobody in that room has spoken to a person who might actually pay for the thing. Nobody has tried to sell it before it exists. The team has designed a solution to a problem it hasn't confirmed.
Real discovery starts further back than that. It starts with the assumption that you might be wrong about everything, including the problem. It means talking to the people who'd supposedly buy this, not to validate the pitch but to actively try to break it. It means looking at what they currently do instead (because they're doing something, even if that something is a spreadsheet and a prayer), and understanding why that alternative, bad as it is, still wins. It means testing willingness to pay before there's anything to pay for. And it means being genuinely willing to walk away, which a sprint, by design, never is. You don't run a two-week design sprint and conclude "let's not". The format doesn't allow for that ending.
Five assumptions worth pressure-testing before you build anything
First: someone has this problem badly enough to change behaviour for it. Not "would find it useful", not "can see the appeal". Badly enough to actually do something differently.
Second: the problem is frequent or costly enough to justify a new tool, rather than a workaround. Plenty of real problems aren't big enough to build a company around.
Third: you can reach the people who have this problem without spending more to acquire them than they'll ever be worth. This one gets skipped constantly, because it's a distribution question, not a product one, and product people love skipping distribution questions.
Fourth: the current alternative, whatever hacky thing people use instead, is actually beatable. Sometimes it isn't. Sometimes the spreadsheet wins.
Fifth: you (or the studio backing you) can build this credibly, with the team and the access and the domain knowledge required, not just build "a version of it" that looks fine in a demo and falls apart the moment someone enterprise-grade kicks the tyres.
Most teams test none of these before writing code. Most teams test maybe one, if they're being honest with themselves.
Why studios, specifically, have no excuse
Here's the thing about studios that makes this non-negotiable rather than nice-to-have: you bear the downstream cost of being wrong in a way a lone founder chasing their own idea doesn't. A founder can burn their own year on a bad thesis and that's a personal tragedy. A studio does this repeatedly, with its own capital, its own reputation, and its own team's morale on the line every single time. If discovery is sloppy, the studio isn't failing once. It's failing on a schedule.
That ought to make studios the most rigorous discovery practitioners in the industry, not the most trigger-happy builders. A studio has done this before, which means it has patterns to check ideas against, and a portfolio's worth of scar tissue about what "looks validated" but isn't. That's leverage most solo founders don't have. Use it, instead of treating it as an argument for moving faster because "we've done this before, we'll just know."
Knowing when to kill it versus when to shrink it
Not every dead end means the idea is dead. Sometimes the problem is real but the scope is wrong, the audience is wrong, or the timing is wrong, and the right move is to shrink the thing down to something narrower and provable, not scrap it outright.
Kill it when the core assumption fails, when nobody's actually in pain, when the willingness to pay isn't there even from people who claim to love the concept. Pivot the scope when the pain is real but the wedge is off, when you've been trying to boil the ocean and a much smaller version of the idea would actually get traction.
The discipline is in telling the difference, and that discipline is the whole job. Anyone can build. Knowing when not to is the expensive skill, and it's the one worth actually paying for.