What Should a Software Discovery Phase Actually Deliver?_

A software discovery phase is often sold as a set of workshops before development begins. That description focuses on activity rather than outcome.

The purpose of discovery is to reduce the most important uncertainty before the organisation commits to a larger investment. It should make the problem, first useful outcome, delivery approach and major risks clearer. If the phase ends with attractive diagrams but no better decision, it has not done its job.

Discovery Is Not Detailed Specification of Everything

Trying to specify an entire complex system in advance creates false certainty. Important details change when users see working software, integrations are tested and the team learns how the organisation actually operates.

Discovery should go deep where uncertainty is expensive and remain light where learning can happen safely during delivery.

Useful questions include:

• Which assumptions could invalidate the investment?
• Which dependency could block the first release?
• Which business rule has the highest cost of misunderstanding?
• Which user behaviour must be observed rather than guessed?
• Which technical choice is difficult to reverse?
• Which compliance or operational requirement affects the architecture?

The goal is not to remove all uncertainty. It is to decide which uncertainty must be reduced now.

Deliverable 1: A Clear Problem and Desired Outcome

Discovery should state:

• who experiences the problem;
• how it is handled today;
• what business impact it creates;
• why solving it now matters;
• which outcomes would indicate improvement;
• which goals are explicitly outside the first phase.

"Build a new portal" is not an outcome. "Reduce manual partner onboarding and make application status visible" is closer to one.

A clear outcome helps the team reject technically interesting work that does not contribute to the business result.

Deliverable 2: A Prioritised First Production Scope

Discovery should identify the smallest credible version that can be used in a real environment and produce learning or value.

This is not necessarily a minimal interface or a demo. A production slice may need authentication, data migration, monitoring, support processes and integration work. The scope should be small in business breadth but complete enough to operate.

The output should describe:

• target users;
• the end-to-end workflow;
• acceptance criteria;
• required integrations and data;
• operational responsibilities;
• what is deliberately postponed.

Deliverable 3: Evidence About Users and Processes

Stakeholder opinions are useful, but they do not always describe actual work. Discovery should include direct evidence such as user interviews, observation, process data, support tickets or examples of real cases.

Look for gaps between the official process and reality:

• spreadsheets used outside the main system;
• manual checks that prevent errors;
• unofficial communication channels;
• repeated copying of data;
• exceptions handled by one experienced employee;
• reports created because the system cannot answer a basic question.

These details often define the real software problem.

Deliverable 4: A Technical and Integration Assessment

The technical output should be proportionate to the decision. It may include:

• current system and data landscape;
• critical integrations;
• security and compliance constraints;
• architecture options and trade-offs;
• data migration risks;
• environments and deployment needs;
• observability and support requirements;
• experiments or prototypes for high-risk assumptions.

A good assessment explains why a direction is recommended and which choices can be postponed. It should not choose technologies merely to make the document appear complete.

Deliverable 5: An Explicit Risk Register

Discovery should surface risks that influence value, cost or delivery. Each major risk needs:

• a clear description;
• probability and impact;
• evidence or uncertainty behind the assessment;
• an owner;
• a mitigation or validation action;
• a point at which the decision will be revisited.

Common risks include data quality, third-party dependencies, unavailable domain experts, regulatory interpretation, unrealistic migration windows and missing operational ownership.

Deliverable 6: A Delivery and Governance Model

The organisation should know how work will be decided and reviewed after discovery.

Define:

• product ownership;
• technical decision responsibility;
• stakeholder involvement;
• expected team capabilities;
• feedback and demonstration rhythm;
• release and acceptance process;
• cost and progress reporting;
• escalation path;
• definition of a completed increment.

A good plan does not pretend to predict every future feature. It explains how the team will make reliable decisions as new information appears.

Deliverable 7: A Cost and Timeline Range with Assumptions

Early estimates should be ranges, not promises. They need to state:

• what is included;
• what remains unknown;
• the assumptions that affect the range;
• the confidence level;
• the cost of the first production milestone;
• which evidence will improve the estimate;
• what could cause the organisation to stop or change direction.

A single precise number at the end of discovery is often less honest than a range connected to explicit assumptions.

Deliverable 8: A Decision

The most important deliverable is a recommendation:

• proceed with the proposed first scope;
• run a targeted experiment before committing;
• buy or configure an existing product;
• change the business process instead of building software;
• postpone until a dependency is resolved;
• stop because the value does not justify the cost.

Discovery has value even when the answer is not to build. Avoiding the wrong investment is a successful outcome.

How Long Should Discovery Take?

Length depends on risk and complexity, not the eventual size of the system. A focused internal tool may require days. A regulated platform with migration and multiple integrations may require several weeks.

Timebox the phase, but do not force every project into the same package. The right endpoint is reached when the next investment decision is supported by enough evidence.

How to Judge the Quality of Discovery

At the end, decision-makers should be able to answer:

• What problem are we solving and for whom?
• What is the first real outcome?
• What did we verify rather than assume?
• What are the largest risks?
• Who owns the necessary decisions?
• What will the first phase cost and what affects that range?
• How will we know whether to continue?

If these answers are clearer, discovery has reduced uncertainty. If the organisation merely owns more documentation, it has not.