Ask Why Until Everyone's Uncomfortable: My Take on Discovery-Driven Development
Ask Why Until Everyone's Uncomfortable: My Take on Discovery-Driven Development
My guiding mantra is simple: if it doesn't make a user's Tuesday easier, it's probably scope creep. The fastest way I've found to tell the difference is to ask why until everyone in the room is a little uncomfortable. Discovery-Driven Development isn't a phase I run before building, it's the habit that decides whether the thing I build is worth building at all.
The first answer is never the real one
"We need a new screen." "Can we automate this approval?" "Add a dashboard." Every request arrives pre-packaged as a solution, and the solution is usually someone's best guess wearing the costume of a requirement. My job is to unwrap it.
So I keep asking. What decision does this help someone make? What breaks if we don't build it? Who is the unhappy user here? By the third or fourth why, the request has usually changed shape entirely, and the real problem, the one actually worth solving, finally shows up. That moment is uncomfortable because it means the original ask was wrong. Good. Better to find that out in a conversation than three sprints later.
Discovery is cheaper than a roadmap mistake
Building legal, claims, and contracts workflows taught me that the cost of guessing wrong compounds. These are not throwaway features, they sit in the critical path of how a business handles risk. Ship the wrong abstraction and you don't just disappoint a user, you bake friction into a process hundreds of people touch every day.
That's why I treat discovery as the cheapest insurance I can buy. A week of uncomfortable questions, a few rounds of "show me how you actually do this today," and a hard look at the messy edge cases will save a quarter of rework. Discovery feels slow right up until you remember what the alternative costs.
Discovery doesn't stop when execution starts
The mistake I see most is treating discovery and delivery as separate stages, figure it all out, then go build. Real workflows don't cooperate with that. You learn the most the moment something half-real is in front of a user, when they say "oh, but what about the cases where the contract is disputed?"
So I keep a foot in discovery all the way through execution. Strategic OKRs, roadmaps, and execution aren't a straight line, they're a circle, and each loop teaches me something the last one couldn't. The roadmap is a hypothesis, not a contract, and I'd rather adjust it on evidence than defend it out of pride.
Why the discomfort is the point
Asking why until everyone's uncomfortable isn't about being difficult. It's about refusing to let a fuzzy assumption survive into code. The discomfort is just the sound of a weak idea being tested, and the strong ideas come out the other side sharper.
When I get discovery right, execution gets quiet. Fewer surprises, fewer re-litigated decisions, fewer "wait, why did we build this" moments. That calm isn't luck. It's the dividend of every uncomfortable question I asked before anyone wrote a line of code.
Sachin skipped presentations and built real AI products.
Sachin Kumar was part of the April 2026 cohort at Curious PM, alongside 18 other talented participants.