A software request is often a symptom written in the language of a solution. The useful work begins one level earlier: understanding what is failing, for whom, and why it persists.
The request is not the diagnosis
Organisations usually arrive with a noun: a portal, an app, a dashboard, an AI assistant. Nouns feel decisive. They create the impression that the hard thinking is finished and delivery can begin.
But the noun may be only the most visible interpretation of the problem. A request for a dashboard might be a trust problem between teams. A request for automation might be an ownership problem. A request for a new platform might be a service model that has never been made explicit.
If the diagnosis is wrong, excellent execution only makes the wrong answer more expensive. The system can be beautifully designed, technically sound and still leave the original constraint untouched.
Look at four layers before choosing a response
A useful diagnosis moves through four connected layers. Start with the outcome: what is becoming slow, unreliable, expensive or difficult to trust? Then inspect the workflow that produces it, the information moving through that workflow, and the people who must operate it.
This matters because technology changes all four layers at once. A new interface changes behaviour. A new data model changes what can be measured. Automation changes where judgement sits. None of those are purely technical decisions.
- Outcome — the visible consequence that matters to the organisation or its customers.
- Workflow — the sequence of decisions, handoffs and exceptions producing that outcome.
- Information — what people know, where it lives and when it becomes available.
- Capability — who owns the work and what the team can realistically sustain.
A practical diagnostic sequence
Begin with the current state, not the imagined future. Follow one real piece of work from beginning to end. Notice where it waits, where it is re-entered, where someone has to interpret an unwritten rule, and where the official process differs from what people actually do.
Then name the constraint in plain language. If the sentence still contains the name of a product or technology, go one level deeper. ‘We need a CRM’ is not a constraint. ‘Nobody can see the full history of a client decision, so three teams act on different information’ is.
Finally, test whether the constraint can be reduced through a decision, role, policy or smaller process change. Technology becomes valuable when it carries a sound operating choice—not when it substitutes for one.
- Observe one real workflow rather than relying only on the documented process.
- Separate recurring constraints from one-off frustrations.
- Identify the decision or behaviour that must change.
- Test the smallest non-technical intervention that could clarify the problem.
- Choose technology only after the required change is understood.
What a good diagnosis produces
The output is not necessarily a requirements document. It is a shared account of the current system, the constraint worth addressing, the change that would matter and the evidence that would show progress.
Sometimes that leads to a product build. Sometimes it leads to integration, configuration, a clearer operating rule or no technology project at all. That range of possible answers is a sign that the diagnosis is doing real work.