What to resolve before starting a software build

A discovery phase is useful when it changes a decision. Producing a large document without resolving the difficult questions simply moves uncertainty into delivery. The aim is to understand the users, business rules, technical constraints, and assumptions well enough to choose a sensible first release.

Observe a real journey

Ask someone to demonstrate how the work happens today. Follow one request from its origin through approvals, exceptions, and completion. Pay attention to spreadsheets and messages outside the main system; they often reveal missing capabilities. Record the reason behind each step before deciding whether it should be automated or removed.

Test the riskiest assumption early

Not every question deserves the same effort. An unfamiliar integration, uncertain data quality, or a workflow that stakeholders describe differently may determine whether the project is feasible. Use a small prototype, sample migration, or structured workshop to test that assumption. A prototype should answer a specific question and should not quietly become unsupported production code.

Define the first usable outcome

A feature list is not a release plan. Identify a complete path that a real user can finish, including errors, permissions, and support. Agree on acceptance criteria and how feedback will be collected. Document what is excluded so the team does not discover scope differences after implementation starts.

A practical next step

Create an uncertainty list with three columns: question, consequence if wrong, and cheapest useful test. Rank it together and resolve the highest-impact item before expanding the delivery estimate.