Blog · Personal ·
Discovery Is the Real Work, Not the Delay Before It
Most SaaS fails because founders assume too much and test too little. Real discovery means actively trying to prove your idea wrong before spending money to bui
Every studio has a version of the same story. Someone gets excited about an idea, the team gets a wireframe up in a week, and within a month there's a working prototype nobody asked for. It feels like progress. It looks like progress. Everyone's busy, the Figma file has forty screens in it, and the momentum is genuinely intoxicating. That's the problem, actually. Momentum is not the same thing as being right.
I think the seduction of building is that it's the part everyone knows how to do. You can hire for it, you can timebox it, you can point at it in a standup and feel good. Discovery, done properly, doesn't give you any of that comfort. It's slow, it's uncomfortable, and half the time it tells you the thing you wanted to build shouldn't exist. Nobody puts "discovered our idea was wrong" on a highlight reel. So teams skip past it, or worse, they do a fake version of it and call it done.
Here's the fake version, and you've probably sat through it: a two-week wireframe sprint, some user interviews that ask leading questions, a demo that gets polished until it looks inevitable. That's not discovery. That's theatre with a Miro board. Real discovery is trying, actively and uncomfortably, to prove your idea wrong before you spend real money building it. It's asking questions you're scared of the answer to. It's talking to people who have every reason to say no, and actually listening when they do.
Most SaaS doesn't fail because the code was bad. It fails because founders assumed too much and tested too little. That's it. That's the whole postmortem for half the startups you've watched disappear. They built the thing before they knew if anyone wanted it, and by the time they found out, they'd already spent the runway convincing themselves otherwise.
So what does pressure-testing actually look like? There are five assumptions that matter more than any others, and if you haven't tested them, you haven't done discovery, you've done vibes.
First: does the problem actually hurt enough for someone to change behaviour? Not "would be nice to have", not "interesting", but painful enough that they're already cobbling together a bad workaround. Second: will they pay for it? Not "would you use this if it were free", but an actual commitment, actual money, actual friction accepted. Ten people willing to pay is the only validation that means anything. Everything before that is opinion.
Third: can you reach these people without heroics? A brilliant product that requires a miracle of distribution to find its market is not a business, it's a hobby with better branding. Fourth: is the timing right, or are you early in the "we were right but broke" sense? Being early feels identical to being wrong until the money runs out. And fifth: is there a reason this doesn't get eaten by someone bigger, faster, or already trusted in the space? Not a moat in the grand strategic sense, just a plain answer to "why you, why now".
None of these get resolved by building faster. That's the trap. Founders conflate build speed with discoverability, as if shipping quicker somehow answers whether anyone's looking for what you've shipped. They're separate games entirely. You can ship in a weekend and still be invisible to the market for a year. Speed doesn't fix a discoverability problem, it just lets you fail at it more efficiently.
Studios, though, are in a strange and genuinely useful position here. Most founders treat discovery as something that happens to them, a passive waiting phase where they put something out and hope the market responds. That's where they lose. Discovery has to be active: chasing the answer down, not waiting for it to arrive in the inbox.
Studios have an incentive most founders don't, which is that they bear the downstream cost of being wrong across multiple projects, not just one. A single founder gets one shot at their idea, emotionally invested past the point of good judgement. A studio watching its fourth or fifth build fail for the same avoidable reason has to get rigorous, or it stops being a studio and starts being an expensive hobby with a nice office. That accountability, weirdly, is the advantage. It's also why studios can test market fit on their own internal projects before ever risking someone else's capital or someone else's dream. You get to be wrong cheaply, on your own time, before you're wrong expensively on someone else's.
Which brings us to the actual hard part: knowing when to kill it versus when to pivot the scope. Killing an idea feels like failure, but it's usually the cheapest good decision available. If the core assumption is broken, the pain isn't real, nobody will pay, you can't reach them, timing's wrong, there's no reason it's you: kill it. Don't rescue it with a smaller version of the same mistake.
Pivoting scope is different. That's for when the assumption holds but the shape is wrong. The pain is real but the audience is narrower than you thought. People will pay, just not for what you built first. That's not failure, that's discovery doing its job.
The uncomfortable truth is that discovery isn't the thing that slows you down before the real work starts. It is the real work. Building is just the part that photographs well.