A discovery that actually ships

Discovery is only useful if it changes what you ship.

Here’s a lightweight structure we’ve found reliable when time is tight and stakes are real.

The goal

A discovery is successful when you leave with:

• a clear problem statement (what is broken and for whom)
• a short list of risks worth testing
• a first shippable slice you can build next

Not: a perfect roadmap.

What we do (in 5 parts)

1) Define the decision

What decision are we trying to make by the end of discovery?

Examples:

• Should we rebuild the flow or patch it?
• Which part of the funnel is actually the bottleneck?
• What’s the smallest version we can ship safely?

2) Find the constraints

Constraints are design inputs, not blockers.

We look for:

• compliance and data retention needs
• operational dependencies
• integration points that are fragile
• performance budgets

3) Choose the few metrics that matter

Pick a small set you can measure reliably (even if imperfect).

Typical:

• time-to-complete
• drop-off at key steps
• error rate
• support tickets per week

4) Prototype the riskiest thing

A prototype can be:

• a click-through flow
• a thin vertical slice
• an internal tool stub
• a flagged UI with logging

The point is to learn quickly, not to be pretty.

5) Commit to a first slice

We end discovery by defining:

• what we’ll ship first
• what we’ll measure
• what we’ll cut (on purpose)

A simple rule

If the output doesn’t change the next sprint, it isn’t discovery—it’s documentation.