Most technology initiatives struggle not because they are difficult to build, but because the underlying problem was never clearly framed. By the time delivery begins, assumptions have already hardened, scope has narrowed prematurely, and important trade-offs have been made implicitly rather than deliberately.
This page describes how I approach problem framing and discovery, not as a phase to rush through, but as the work that determines whether everything that follows will remain coherent over time.
When a problem is framed too late, teams inherit constraints they did not choose. Delivery becomes reactive, architecture becomes defensive, and systems accumulate complexity that feels unavoidable but is often self-inflicted.
Effective framing creates space to:
This work is quiet, but its absence is usually felt months or years down the line.
Discovery is not a requirements gathering exercise, and it is not a design sprint aimed at producing solutions quickly.
Instead, discovery focuses on:
The outcome is not a specification, but a shared understanding of intent.
In complex environments, ambiguity is unavoidable. The goal is not to eliminate it prematurely, but to work with it deliberately.
During discovery, I help stakeholders:
This often feels counter-intuitive in delivery-driven cultures, but it is where the most leverage usually sits.
While discovery is primarily about understanding, it does produce concrete artefacts that support later work. These may include:
These outputs are deliberately lightweight. Their purpose is clarity, not completeness.
Problem framing and discovery often precede longer engagements, but they can also stand alone.
In some cases, the result of discovery is a clear path forward. In others, it reveals that a proposed initiative should be reshaped, delayed, or stopped altogether.
In all cases, the aim is the same. To ensure that subsequent delivery effort is spent in service of the right problem, rather than compensating for early uncertainty.