What technical discovery should answer

Technical discovery is useful when an unresolved question could change whether or how a team should build. It should end with enough evidence to choose a next step, including the option not to proceed.

The question may concern users, data, integration access, architecture or cost. A short investigation is worthwhile when acting on the wrong assumption would be expensive. It is less useful when the task is already understood and the remaining questions can be resolved through ordinary implementation.

Start by naming the decision. That gives the work a purpose, a sensible scope and a stopping point.

Choose the question that controls the next step

“Assess the opportunity” can expand indefinitely. A more useful question might be whether an existing product can support the workflow, whether a provider can supply the required data, or which first product slice is worth testing.

Identify who needs to decide and what they need to know. A product owner, technical lead and budget owner may have different questions. Connect their decisions without assuming that one report settles them all.

Write down the known constraints and the consequence of a wrong assumption. Investigate first what could remove an option or materially change the scope, sequence or cost.

Agree what can remain uncertain. Some questions need a prototype, a vendor process or evidence from real operation. Discovery should identify those dependencies rather than promise to eliminate every unknown.

Gather evidence at the right level

Read existing material before requesting new workshops or access. A brief, sample workflow and system documentation may be enough to identify the decisive gap.

Different evidence answers different questions. API documentation can describe an endpoint; it does not establish that the intended account can use it. Source code can show an implementation; it does not prove that people use it successfully. An interview can describe a process; a walkthrough can reveal steps that were left out.

Keep important observations, assumptions and interpretations distinct. Record the source and consequence of error without creating a large register for every minor detail.

Use the least sensitive evidence that can answer the question. Approved examples, redacted records and read-only checks often suffice. Any live access should have a clear purpose and handling boundary.

Where the question concerns actual work, building software alongside its users offers a practical way to investigate it.

Compare credible options

Consider improving the existing process, configuring a product, adding an integration, or building new software. Include delay or a smaller experiment when those are reasonable choices.

Give each credible option enough attention to compare it fairly. A detailed preferred design beside two vague alternatives creates the appearance of choice without the substance.

Compare what each option solves, what remains manual, and what the organisation must maintain. Include data access, integrations, security, accessibility and the team's ability to operate the result where they affect feasibility.

Estimate from those responsibilities. Separate implementation from recurring services, support and internal effort. Use ranges when uncertainty warrants them, and state the assumptions that would change the range. An early estimate is useful when its basis is clear; extra decimal places do not improve weak evidence.

Keep diagrams tied to a question. A context view can explain system boundaries; a data flow can expose where information leaves an organisation. Neither needs to become a complete enterprise architecture exercise to be useful.

Test the assumption that matters

A technical spike should investigate the difficult part rather than reproduce easy screens. Define the result that would support or rule out the proposed route before building it.

As a constructed example, suppose a team is deciding between connecting an existing application and replacing it. The controlling question may be whether a provider can expose the records with stable identifiers and suitable access.

A small read-only test could establish what data is available, how records match and where conflicts remain. That evidence may justify the integration, reveal a need for manual review, or show that the route cannot meet the requirement.

The test has limits. A successful request does not establish production reliability or permission for every future use. Record what was exercised, what was simulated and which conditions remain unresolved.

For an AI feature, the most useful early output may be a representative evaluation set and a comparison with the current process. Evaluating an AI feature before release explains how to make that comparison meaningful.

Leave a recommendation someone can act on

The final output can be concise. It should connect the question, evidence, options and recommendation so that the next team can understand the reasoning.

Include:

• the preferred route and why it fits;
• the assumptions and unresolved questions that affect it;
• the first useful scope, including exclusions;
• the expected effort and cost basis;
• the result needed before committing further;
• the person responsible for the next decision.

The recommendation can be conditional. State the condition concretely: access to a particular source, confirmation from its owner, or a test result that the design depends on. Avoid a broad “subject to further investigation” that leaves the original question untouched.

Implementation requirements, estimates and decisions have different roles. Keep them connected without treating a proposed plan as permission to start every phase.

Stop when the evidence is enough

Stop when the decision can be made, when evidence rules out the opportunity, or when the remaining question belongs in a separate test or approval process. If the controlling question changes, revise the scope openly.

Further research can cost more than it changes. Ask whether the next activity could alter the recommendation or is merely adding detail to a choice already supported.

A useful discovery leaves a team able to explain what it will do next and why. The output may be a build, a smaller experiment, an internal improvement or no project. Its value lies in making that choice clearer before more resources are committed.