A discovery that ends in a slide deck nobody reads was theater. A real discovery ends in artifacts a team can execute against: a system map, a risk register, a sequenced plan, and a price you can defend.
There are two kinds of discovery in enterprise software. The first is a formality from the sales process: a few calls, a capabilities deck, and a number borrowed from comparable projects. It exists to get a signature. The second is an engineering instrument: a short, senior-led investigation that turns a vague initiative into a plan a team can execute. It exists to make the delivery boring.
You can tell them apart by what they produce. Theater produces a proposal. A real discovery produces artifacts.
What a real discovery produces
A map of the current systems, built from the systems themselves and the people who run them, not from the org chart's imagination. A constraint inventory covering security, compliance, data residency, and operations, gathered from the teams who can block the project later. A risk register with owners and mitigations, where every unknown from the estimate becomes a named and sized item. A sequenced roadmap that says what happens first and why. And costed options, because one price is a demand and three scoped options are a decision.
Each artifact is executable. A team that did not run the discovery should be able to pick it up and start building.
Discovery protects both sides
The client learns how the delivery team thinks before committing to how it builds. The delivery team learns whether it can honestly help. A good partner says so when the answer is no, and when the real problem is smaller than the proposed budget. The principle is simple: everything either side learns after the contract was learnable before it. Someone chose not to look.
It also changes the commercial conversation. A costed plan with a risk register can be defended in front of a CFO. A day rate times a team size cannot.
How long it should take
Two to four weeks, staffed by senior people, with real access to systems and stakeholders. Longer than that and it has become a project. Shorter and it has become a guess. The output should be useful enough that you could hand it to any competent team, including a competitor, and it would still work. That is the standard we hold our own discovery work to, and it is the standard worth demanding from anyone who proposes to build for you.
Next Step
Sound like your situation?
We apply this thinking inside real engagements every week. Bring us the constraint you're working around, and we'll show you how we'd approach it.
Take the Leap