Organisations are very good at solving problems:
- A process is too slow, so we automate it.
- A system isn’t delivering, so we replace it.
- A transformation programme is struggling, so we add governance.
- Teams aren’t collaborating, so we restructure.
Each response seems perfectly reasonable but there’s a question we often skip:
What if the problem we’re solving isn’t actually the problem?
The things we notice inside organisations are often symptoms - a slow process, poor-quality data, frustrated employees, delayed decisions or underperforming technology tell us that something isn’t working but it doesn’t necessarily tell us why.
When we move too quickly from identifying a symptom to implementing a solution, we can spend considerable time and money solving the wrong thing… sometimes we even make the original problem worse.
Follow the problem
Imagine customer enquiries are taking too long to reach the sales team - from the outside, the problem seems relatively straightforward.
A potential customer submits an enquiry through the website but too much time passes before it reaches the right salesperson.
The obvious response might be to automate more of the process but before automating anything, follow the enquiry.
A relatively simple customer journey might look something like this:
Customer → Website → Marketing Automation → CRM → Lead Routing → Sales
At each stage, something happens to the information…
The website captures it, marketing automation may enrich or categorise it, CRM stores it.
Routing rules determine where it should go and eventually, somebody in sales receives it and decides what to do next.
Suddenly there are quite a few questions worth asking:
- Is the website collecting the information needed to route the enquiry correctly?
- Is marketing automation adding useful information or simply adding another step?
- Does the CRM contain accurate enough data to determine where the enquiry should go?
- Have routing rules become increasingly complicated as exceptions have been added over time?
- What happens when an enquiry doesn’t fit those rules?
- Who owns it then?
- Do marketing and sales even agree on what constitutes a qualified lead?
Perhaps the enquiry reached sales perfectly quickly but sat untouched because the salesperson didn’t recognise its importance.
All of those situations could produce essentially the same visible symptom:
Customer enquiries are taking too long to reach sales.
But they represent very different problems and would require very different interventions.
- Replacing the CRM wouldn’t fix unclear ownership.
- Automation wouldn’t resolve disagreement between marketing and sales.
- Adding more routing rules might actually make an already complicated process worse.
- And training salespeople wouldn’t help if they aren’t receiving the information they need in the first place.
The important thing is to resist the temptation to decide what the problem is before understanding how the system actually behaves - that doesn’t necessarily require months of analysis or an enormous discovery programme.
- Talk to the people doing the work.
- Follow the process from beginning to end.
- Look at the information moving through it.
- Understand where decisions are made, where ownership changes and where people have created workarounds to compensate for something that doesn’t work.
Before trying to fix the problem, follow it through the system.
Separate observation from explanation
There’s another important distinction that’s easily missed though - consider these two statements:
- Observation: Customer enquiries take an average of 36 hours to reach the appropriate salesperson.
- Explanation: Our CRM and lead-routing process is inefficient.
They might sound like two descriptions of the same problem but they’re not.
- The first describes something we can observe and potentially measure.
- The second is a hypothesis about why it is happening.
That hypothesis might ultimately prove to be correct but until we’ve investigated it, that’s all it is.
This distinction matters because organisations can become remarkably good at turning explanations into facts: A project begins because the technology is outdated, a process is redesigned because people aren’t following it correctly, more governance is introduced because teams aren’t communicating and training is commissioned because users don’t understand the system.
Before long, the assumed cause becomes embedded in the language surrounding the problem and the organisation starts designing solutions around something it hasn’t actually established to be true.
A useful first step is therefore surprisingly simple: Describe what is happening without explaining why it is happening.
Once we can separate what we know from what we think we know, we have somewhere much better to begin the investigation.
Challenge what you think you know
Once we’ve separated what we know from what we think we know, it’s tempting to start looking for evidence that proves our explanation is correct.
If we believe the CRM is causing the delay, every awkward workflow, incorrect field or complicated routing rule suddenly becomes evidence that the CRM is the problem.
But finding evidence that supports an explanation isn’t the same as proving it - instead, we should also ask:
What would we expect to see if our explanation was wrong?
Let’s Go back to our customer enquiry example.
- Perhaps some enquiries move through exactly the same system in minutes while others take two days.
- Perhaps one sales team receives enquiries almost immediately while another experiences significant delays.
- Perhaps manually routed enquiries are no faster than automated ones.
- Perhaps the data shows that enquiries reach the salesperson within minutes - and most of the delay happens afterwards.
Each of those observations challenges our original explanation and gives us somewhere else to look.
That might take us into the process itself, the information being captured, the decisions being made, ownership between teams, the technology supporting them or the way people actually work around the system.
The point isn’t to examine every part of the organisation - it’s to follow the evidence.
- Ask what supports our explanation but also what contradicts it.
- Look at where the problem occurs and where it doesn’t.
- Talk to the people experiencing it and understand what they see that we might not.
The purpose of diagnosis isn’t to prove that our first explanation was right. It’s to understand the problem well enough that we know what actually needs to change.
This matters because the solution might still be automation, it might still be the CRM, it might require a process change, clearer ownership, better information or a different decision.
Now we’re solving something we’ve taken the time to understand rather than something we’ve simply assumed.
Sometimes the most valuable question isn’t “How do we fix this?” It’s “What exactly are we trying to fix?”
