Discovery has a reputation problem, and it is largely earned. Too many discovery phases produce a summary of things the client already knew, a diagram, and an estimate arrived at by the same intuition that would have been used without it.
A discovery that was worth running produces specific artefacts, and each one should be capable of changing a decision.
A problem statement someone would argue with
"Improve the customer experience" is not a problem statement. "Forty percent of applications are abandoned at the income verification step, mostly on mobile" is, because it is falsifiable, measurable, and points at where to work.
If the statement could describe any company in the sector, discovery has not finished.
A map of what already exists
Which systems hold the data, which are authoritative, what integrations exist, and what the awkward parts are. This is where estimates are actually determined, because it is where the surprises live.
It also frequently reveals that part of the requested work is unnecessary, which is the highest-return finding discovery can produce.
A sequenced plan with decision points
Not a list of features but an order, with dependencies, and explicit points where the next phase should be reconsidered based on what the previous one showed.
A plan with no decision points is a plan that expects to learn nothing.
A range, with the drivers named
An estimate expressed as a range, with the specific unknowns that would move it and what it would cost to resolve each one. That lets a client decide whether to buy certainty before buying the build.
The risks, written down plainly
Including the uncomfortable ones: the dependency on a team that is already overloaded, the data that may not be good enough, the possibility that the approach is wrong. Risks surfaced in discovery are cheap. The same risks surfaced in month five are not.
The test is simple. If nothing about the plan changed as a result of discovery, it was documentation rather than discovery.