Don’t call it "discovery"
You’re not exploring. You’re just agreeing to build someone’s best guess.
We like to romanticize the word “discovery.” It sounds curious. Open. Thoughtful. Like we’re off on an expedition to uncover hidden truths.
But let’s be honest. Most “discovery” processes aren’t discovery at all.
They’re translation.
Stakeholders hand us opinions, preferences, requests, and constraints. And we, the business analysts, shape them into something buildable in good faith. We capture the need. We document the requirement. We write the story. And then we hand it to delivery like it’s the truth.
But how often do we stop and really dig deep to ask:
Is this even the right problem?
Do we have proof it exists?
What if this isn’t what they actually need?
Usually, we don’t. Because we can’t. Because the clock is ticking. Delivery wants something to build. So we move fast, act confident, and call it done.
The problem with “discovery”
Real discovery should challenge assumptions. It should make us uncomfortable. It should uncover what doesn’t belong in the backlog, not just what does.
But most teams don’t have the time, space, or structure for that. So “discovery” becomes a ceremony. A short detour before we start building what we were going to build anyway.
We pretend we explored. But we never questioned the premise.
Rehearsing a play you’re not allowed to rewrite
Most discovery sessions feel less like exploration, and more like dress rehearsal. The script is already written. The roles are already cast. You, the business analyst, are just being asked to read the lines with energy.
Maybe you tweak the phrasing. Maybe you suggest a better costume. But the story? That’s locked.
And if you dare to suggest rewriting a scene?
“We don’t have time for that.”
“Let’s just get the MVP out.”
“It’s too late to rethink it now.”
So you perform. You refine. You deliver. And later, when it flops? Everyone wonders why the plot didn’t land.
Discovery that doesn’t invalidate anything… isn’t discovery
If your team’s discovery phase never kills a bad idea, never reveals a contradiction, never invalidates a long-held assumption — then it’s not discovery.
It’s compliance.
You’re just stress-testing how fast you can align around a hunch. And in that case, the word “discovery” is just branding.
What it should be
Discovery should feel like pressure testing. You should leave with fewer ideas, not more. You should leave with clearer thinking, not just longer documentation. And you should be able to say:
“This thing we thought was a need? It’s not.”
“This feature request? It’s a workaround for something deeper.”
“This constraint? Turns out, it’s not real at all.”
That’s the kind of clarity that saves you three months and two failed sprints.
Why Proof Sprint exists
I didn’t create Proof Sprint because I love discovery. I created it because I got tired of pretending we were doing it.
Tired of acting like documenting a request counted as understanding the need.
Tired of building what we never proved.
Tired of finding out after the build that we were wrong.
So I built something leaner. Sharper. Honest.
Not a phase. A mindset.
Not a process. A set of thinking tools.
Discovery that actually discovers.
Try this
Before your next planning session, ask one question:
What would we stop building if we found out we were wrong about this?
That’s where real discovery begins.
Liked this piece? Here are a few ways to go deeper:
See it live: Join a free Proof Lab to catch one of the tools in action.
Read more stories: Subscribe to this newsletter.
Explore the method: Visit proofsprint.com for the full toolkit.