Discovery outputs that hold up
Discovery isn’t a mood board. It’s the work that turns unknowns into decisions you can defend.
When people say they “need a timeline,” they usually mean something more specific:
They need to know what they can tell other humans without being embarrassed later.
Discovery is how we earn that.
Constraints
Discovery fails in a few common ways:
- It produces a narrative, not a plan.
- It avoids hard choices (“we’ll decide later”) when the choice is the work.
- It ends with a single confident date, not a list of the unknowns that control the date.
If discovery doesn’t change what we’re willing to commit to, it didn’t do its job.
What we changed
We started treating discovery as a small delivery with explicit outputs.
At the end, we try to ship:
- A boundary: what’s in, what’s out, what we are explicitly not doing.
- A risk list: the top unknowns, and how we plan to collapse each one (spike, prototype, data pull, vendor test).
- A decision log: the decisions we made, the assumptions we’re relying on, and what would force a re-plan.
- A thin slice: a small vertical path that proves something real (integration, data shape, auth, performance constraint).
- Options: a few scoped options with trade-offs (time vs scope vs operational risk), not one “magic” plan.
Those outputs make it harder to lie accidentally. They also give stakeholders a way to participate: not by demanding certainty, but by choosing trade-offs.
What “hold up” looks like
We try to produce an artifact you can forward without adding an interpreter.
A minimal discovery doc we’re happy with has:
- a one-paragraph problem statement
- an explicit boundary (in/out)
- the top risks with the next test for each
- 2–3 options with trade-offs (time vs scope vs operational risk)
- a recommendation and the reason it’s defensible
- the next checkpoint date (what will be different then)
Making each output concrete
A boundary isn’t “MVP.” It’s sentences like:
- “We will support CSV import, not Google Sheets sync.”
- “We will ship admin-only access first; self-serve permissions are out of scope.”
A risk list isn’t “things that could go wrong.” It’s a plan to collapse uncertainty:
- “Vendor API rate limits: run a production-volume sample; decide on batching by Tuesday.”
- “Data shape: pull 200 real rows; build the mapping; count failures; decide whether cleanup is required.”
A decision log doesn’t need to be fancy. It needs to answer: what did we decide, why, and what would change our mind?
A thin slice isn’t a demo. It’s a vertical path that proves a hard thing: auth, integration, performance constraint, or data correctness.
Options aren’t wish lists. They’re choices you can explain later without rewriting history.
If discovery ends with a single confident date and no named unknowns, it didn’t do discovery work. It did comfort work.
A small but useful closing move is to write the current range and the next narrowing step:
- “We believe 3–6 weeks is plausible after discovery.”
- “The range collapses after we prove the integration and run a real data sample.”
That gives everyone something honest to repeat.
It also makes the next week legible: we are not “building.” We are collapsing the thing that controls the timeline.
One more thing that helps: write the options as trade-offs, not as features.
- Option A: smaller scope, lower operational risk, earlier ship
- Option B: bigger scope, higher risk, later ship
Then pick.
Stakeholders usually don’t need certainty.
They need to know which choice they’re making.
A discovery output we like is a short “risk table” where each risk has a next step and a date.
If you can’t say when you’ll know, you’re not managing risk. You’re hoping.
We also treat the thin slice as a proof, not a prototype:
- a real request through the integration
- a real sample of data in the new shape
- a dashboard that answers “did it work?”
The thin slice doesn’t have to be shippable.
It has to be real enough that it changes what you believe.
Results / Measurements
The best result is fewer mid-project resets.
We also see fewer status updates that are really just anxiety management.
When discovery produces a boundary and a risk list, the update becomes: “we tested the thing that controls the schedule; here’s what changed.”
That’s the difference between motion and progress.
When risks are named early, “surprises” become planned work. When scope boundaries are explicit, it’s easier to trade features for schedule without drama.
A proxy we like is the number of times we have to answer “wait, I thought this was included.” If that question shows up late, discovery didn’t surface a boundary.
Another proxy: how often discovery ends with a real decision.
If you leave discovery with “we’ll decide later” on every hard choice, you didn’t do discovery. You deferred it.
A clean ending is: a boundary, a range, and a next checkpoint.
Not a vibe.
If you can write those three lines, you can usually defend the plan in a meeting.
And you can update it without pretending the original plan was ever certain.
That’s what makes it hold up.
It gives you something you can re-check when reality changes.
Takeaways
Discovery is the work that makes a commitment defensible.
If you can’t name the top unknown, you’re not estimating—you’re hoping.
If you can’t write down the boundary, you don’t have a scope.