What does a discovery phase actually produce?

Discovery converts assumptions into decisions

Discovery is a short investigation before committed delivery, not a ceremonial preface to coding. It identifies the business change being attempted, the people and systems affected, and the constraints that cannot be negotiated. Interviews alone are insufficient. Claims are checked against workflows, source data, existing interfaces, policies and representative transactions. The resulting material should let another competent team understand what is being built, why the proposed boundary is sensible and where uncertainty remains. If discovery merely rewrites the initial brief, it has not reduced delivery risk.

The work begins with outcomes and measures rather than a feature inventory. A request for an approval dashboard may conceal a need to shorten a controlled decision, prove segregation of duties or remove duplicate entry. Mapping the current event from trigger to final record exposes hand-offs, exceptions and unofficial spreadsheets. The future process can then state which responsibilities change and which controls remain. This prevents a polished interface from preserving the same ambiguity underneath and gives acceptance testing a business meaning beyond whether individual controls respond.

The core set of outputs

Useful outputs are concise enough to maintain and specific enough to make decisions. They normally include a problem statement, stakeholder and responsibility map, current and proposed process flows, domain model, system context, interface inventory, data assessment and non-functional requirements. Important decisions belong in an architectural decision record with alternatives and consequences. The proposed release is represented as prioritised capabilities with acceptance evidence, dependencies and exclusions. Wireframes or prototypes are included where interaction or terminology is uncertain, not as decoration or a substitute for system design.

• A release boundary that distinguishes required capability from later options.
• A system and data model showing ownership, flows and trust boundaries.
• Evidence from prototypes or technical spikes for high-risk assumptions.
• A migration and integration approach grounded in inspected source systems.
• A sequenced estimate with assumptions, dependencies and explicit exclusions.

Different uncertainties need different evidence

A prototype answers whether users can understand an unfamiliar interaction. A technical spike answers whether a protocol, library or performance approach behaves under representative conditions. Data profiling answers whether legacy fields carry the meaning assumed by the target model. These activities should have a question, time boundary and recorded result. Prototype code is normally disposable unless it was built to production standards. Treating every experiment as the application encourages accidental architecture; treating every question as a workshop opinion leaves technical risk untouched until delivery.

How estimates emerge

The estimate is derived from a proposed sequence of complete capabilities, not a total page count. Each slice includes domain logic, user experience, interfaces, permissions, data, tests, deployment and operational support. Uncertainty is attached to the assumption causing it, such as unavailable vendor documentation or unknown data quality. A range is more honest than a precise date while those assumptions remain open. Discovery should also identify decisions required from the organisation and include their lead time; engineering effort cannot compensate for delayed policy, content or process ownership.

What good handover looks like

Discovery artefacts should be stored in accessible, versioned formats and reviewed with the people who will deliver and operate the system. Terms must be defined consistently across process maps, data models and interface contracts. Open questions need owners and decision dates. The presentation at the end is a review, not the deliverable itself; editable source files, research notes, decision records and prototype findings remain available. Commercial continuation should not be required to interpret the work, although estimates naturally need revisiting if assumptions, scope or external conditions change.

When discovery is complete

Discovery is complete when the organisation can make a reasoned investment decision. That may be to proceed, change the release boundary, buy an existing product, address data problems first or stop. The team should be able to explain the operating change, demonstrate risky assumptions, identify the authoritative data and systems, and show how delivery will be accepted and run. A backlog with many detailed tickets is not evidence of readiness if core ownership or architecture remains unresolved. Completion is therefore a decision threshold, not a predetermined document count.