In software delivery, difficulties rarely arise because teams are incapable of building what has been asked for.
In most cases, the problem lies elsewhere.
More often, the issue is that what was asked for was never quite the right thing to build.
This usually becomes clear only after time has been spent delivering something that works as specified, but does not materially improve the situation it was intended to address.
At the centre of this sits a distinction that is easy to acknowledge in theory, and surprisingly difficult to manage in practice: the difference between what a client believes they need, and what they actually need.
What Clients Think They Need
Clients generally approach a project with a solution already in mind.
This is not unusual, and it is not a failing. In fact, it would be unrealistic to expect otherwise.
They are close to their organisation, its processes, and its problems. They experience the friction of day-to-day work directly, often over long periods of time. In many cases, they have already attempted to resolve the issue themselves, using the tools and knowledge available to them.
By the time a conversation begins, a great deal of thinking has usually already taken place.
What this tends to produce is a request that takes the form of a solution:
- a particular feature
- a new system
- a revised workflow
- a replacement for something that no longer feels fit for purpose
These requests are typically well-intentioned and grounded in genuine experience. They reflect how the problem currently presents itself to the people living with it.
However, they are still interpretations.
They represent one possible way of addressing an issue, rather than a precise statement of the issue itself.
What Clients Actually Need
What a client actually needs is often harder to articulate.
It tends to sit beneath the proposed solution, and is usually concerned with effects rather than mechanisms.
In practice, this might involve things like:
- reducing the amount of manual intervention required
- increasing confidence in the accuracy of information
- making it easier to understand what is happening, and why
- enabling decisions to be made with less effort or delay
These needs are rarely expressed directly, particularly once a solution has already taken shape in someone’s mind.
As soon as a concrete idea exists, conversation tends to move towards how that idea might be implemented, rather than whether it is the most appropriate response to the underlying problem.
Over time, the solution and the need become conflated.
Why the Difference Exists
This difference between assumed and actual need is not the result of poor communication or lack of diligence.
It exists because clients and delivery teams approach the same situation from different positions.
Clients understand the operational context in detail. They know where time is lost, where errors occur, and where work feels unnecessarily difficult. What they do not always have is the distance required to step back and examine whether the structure of the problem itself could be altered.
Delivery teams, conversely, are trained to turn requests into systems. They are accustomed to working with defined inputs and producing concrete outputs. Without careful attention, it is easy for a suggested solution to be treated as a fixed requirement.
Neither perspective is wrong. They are simply incomplete on their own.
The Consequences of Taking Requests Literally
When a proposed solution is accepted without sufficient examination, delivery can proceed smoothly while still missing the point.
The system is built. The features function. The acceptance criteria are met.
And yet, once the software is in use, familiar patterns re-emerge:
- users bypass parts of the system
- workarounds appear
- additional processes are layered on top
In these cases, the software has done what it was designed to do. The difficulty is that it was designed around an assumption rather than a need.
Over time, this leads to increasing complexity, not because the team made poor technical decisions, but because the original framing of the problem was never quite right.
Why This Matters Early On
The distinction between assumed and actual need influences decisions long before any code is written.
It affects:
- what is prioritised
- how flexible the system needs to be
- where effort is invested
- how success is ultimately judged
If this distinction is not addressed early, delivery becomes an exercise in refinement rather than understanding. Progress is made, but in a direction that may not be especially helpful.
Correcting course later is possible, but it is rarely cheap.
Assumptions as a Starting Point
Assumptions are not something to be eliminated. They are inevitable, and often useful.
They provide insight into how a problem is currently understood, and where attention is likely to be required.
What matters is that they are treated as provisional.
Examining assumptions carefully creates space to ask whether the proposed solution genuinely addresses the issue at hand, or whether it simply reflects the shape the problem has taken so far.
This work is rarely visible, but it is rarely wasted.
The Work That Matters Most
Much of the most valuable work in software delivery happens before anything tangible exists.
It happens in the careful examination of what is being asked for, and in the effort to understand what lies beneath that request.
This is not about slowing things down unnecessarily. It is about ensuring that time and effort are spent in service of the right problem.
Closing
Building software is, in many cases, the straightforward part.
Understanding what should be built, and why, takes longer. It requires patience, attention, and a willingness to sit with uncertainty for a while.
That effort is rarely dramatic. It does not produce immediate artefacts.
But it is what allows the resulting system to be genuinely useful, rather than merely complete.