The most expensive code is the code nobody uses. Teams pour months into features that shipped clean, tested green, and then sat untouched — because the problem was assumed, not validated. Product discovery is the cheap work you do before the expensive work to make sure you're building something people actually want. It doesn't have to be heavy. It has to happen before the build, not after.
Discovery is not a phase — it's a filter
You don't do discovery once and then stop. Every meaningful feature passes through the same filter: is this a real problem, for real users, that we can solve in a way they'll adopt? The point is to kill bad ideas cheaply, on a whiteboard, before they become bad code.
Start with the problem, not the solution
Founders arrive with solutions — "we need a dashboard," "add AI." Discovery's first job is to walk that back to the underlying problem. What is the user trying to accomplish? What do they do today? Where does it hurt?
If you can't state the problem in one sentence without naming your solution, you're not ready to build. The solution is a hypothesis; the problem is the thing to validate.
Talk to users before you write a spec
Nothing replaces a handful of real conversations. Five to eight interviews with people who have the problem will teach you more than weeks of internal debate.
- Ask about what they did, not what they'd hypothetically do.
- Dig into the last time they hit this problem — specifics beat generalities.
- Listen for workarounds; a painful workaround is proof the problem is real.
- Resist pitching. You're there to learn, not to sell.
If nobody describes the problem you assumed, that's a finding worth far more than the build you avoided.
Validate demand before you commit
Once the problem is confirmed, test whether your solution is wanted before building it fully:
- A clickable prototype you put in front of real users.
- A landing page that measures sign-up intent.
- A concierge test where you deliver the outcome manually first.
- A fake-door that measures how many people click the feature.
These take days and can save months. A prototype users don't engage with is a cheap "no."
Write down what would change your mind
The discipline that makes discovery real: state your riskiest assumption and the evidence that would disprove it. "We believe operations managers will pay to automate this report; we're wrong if fewer than half of the ones we talk to see it as a real cost." Now discovery has a pass/fail, not a vibe.
Then, and only then, scope the build
When the problem is validated, demand is evidenced, and the assumptions have survived contact with users, you're ready to scope and build — with far less risk that you're building the wrong thing well.
At Doktouri we run lightweight discovery before we write production code, so our clients don't pay to build features their users never asked for. If you're about to commit to a roadmap, talk to us.
Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.
Top comments (0)