Process
What discovery actually decides
Discovery is often treated as a formality before the real work. In practice it decides the shape, cost and risk of everything that follows.
- Process
Most software projects begin with a request that sounds like a solution: a portal, an app, a new CRM. Discovery exists to find the problem behind that request before anyone commits to building it.
Three decisions discovery makes
- What success looks like, stated in terms the business already measures.
- Which constraints are real: existing systems, regulation, team capacity and timing.
- Where the uncertainty is highest, so it can be tackled first instead of last.
None of these decisions requires a long engagement. They do require conversations with the people who do the work today, a look at the systems they use and the discipline to write the findings down.
What good discovery produces
The output is short: a problem statement everyone recognises, a list of scope boundaries and a list of open questions. When those three exist, estimates become meaningful and the first release can be planned around real priorities.
When they are skipped, the same questions surface during development, where every answer is more expensive.
