In his TED talk Life lessons from an ad man, Rory Sutherland tells a story about the Eurostar. Billions were spent on new tracks to remove about 40 minutes from the journey between London and Paris.
His deliberately ridiculous alternative was to spend a fraction of that money making the journey more enjoyable. The train would not arrive sooner, but passengers might value the time more.
The point is not that faster trains are a bad investment. It is that the metric we can measure most easily is not always the outcome people care about most.
I see the same risk in business technology. A faster system, a new platform or an AI tool can look convincing in a proposal. But if it does not remove the friction people experience, the business may improve the metric without improving the work.
A technical improvement is not automatically a business improvement
Technology projects often begin with a solution already in mind:
- Replace the CRM.
- Move to a new platform.
- Automate the approval process.
- Add AI to customer service.
- Upgrade the network because people say the system is slow.
Each idea may be reasonable. The problem is starting there.
“Slow” can mean several things. The software may take too long to load. It may also mean staff enter the same information twice, wait for an unclear approval, search for the latest document or ask three people who owns the next step.
A faster application will help with the first problem. It may do nothing for the others.
That is why I prefer to start with the work. What is the person trying to achieve? Where does the delay occur? What information is missing? Who makes the decision? What happens when the normal process does not fit?
Only then can we decide whether the answer is configuration, clearer ownership, process improvement, training, integration, automation or genuinely new technology.
Why the bigger solution often feels safer
Large technology proposals tend to arrive with numbers. There is a project plan, a feature list, a delivery date and a return-on-investment calculation.
Smaller operational improvements can look less impressive. Remove an approval. Clarify who owns a customer record. Configure a feature the business already pays for. Stop copying information from one system to another.
These ideas may be harder to present because they do not come in a new box. They can also require people to question how the work is currently organised.
Sutherland’s wider point is useful here. Rational, engineering-led ideas are often treated as though their logic is enough. Creative or behavioural ideas are expected to prove themselves first.
Both should face the same test: what problem does this solve, for whom, and how will we know?
A familiar example: the CRM that is “too slow”
Imagine a typical 30-person firm considering a new CRM.
The sales team says the current system slows them down. Management sees an opportunity to move to a newer platform with more automation and better reporting.
Before comparing products, I would want to understand what “slow” means in practice.
Perhaps staff are entering customer details in both the CRM and the accounting system. Perhaps nobody agrees when an opportunity should move to the next stage. Perhaps reports are unreliable because fields are used differently by each person. Perhaps approvals happen through email and cannot be seen in the system.
A new CRM might be justified. But moving those same rules, habits and gaps into a new platform will not remove them. It may simply make the old confusion more expensive.
This is where Process and Workflow Optimisation matters. Understand and improve the process first. Then choose the technology that supports it.
Four questions to ask before approving new technology
1. What problem does the team actually experience?
Describe it without naming a product. “We need a new CRM” is a proposed solution. “Sales staff enter the same customer information twice and cannot see who owns the next action” is a problem we can investigate.
2. Which outcome matters to the business?
Faster processing may matter. So might fewer errors, less rework, clearer ownership, better customer communication or reduced risk. Choose the outcome before choosing the tool.
3. What can the current environment already do?
Established businesses often own useful capability they have not configured, connected or adopted properly. That does not mean the current platform must stay forever. It means replacement should earn its place.
4. How will we measure the change?
Record an appropriate baseline before implementation. If the goal is to reduce duplicated work, measure that. If the goal is to shorten an approval, measure the elapsed time and the exceptions. Do not rely only on whether the project was delivered on schedule.
Sometimes the right answer is still new technology
Optimising what exists is not the same as refusing to change.
A platform may no longer be supported. It may create unacceptable risk, prevent an important process from working or cost more to maintain than a justified replacement. The current provider may not be able to deliver what the business now needs.
In those cases, change can be the sensible answer.
The difference is that the decision follows the evidence. The business understands the problem, the current environment and the outcome it expects. The technology is chosen to support that result—not because a new platform was the easiest idea to put in a spreadsheet.
What to do this week
Take one technology improvement currently being discussed and remove the product name from the proposal.
Write down:
- The problem staff or customers experience.
- The business outcome that should improve.
- What has already been tried.
- What the current tools can and cannot do.
- How you will measure the result.
If the proposal is still clear after that exercise, it is probably ready for a more detailed assessment. If it becomes difficult to explain, the business may be jumping to a solution too early.
A Business Technology Review gives you a documented view of your spend, systems, providers and digital processes before change is recommended. The aim is simple: keep what works, optimise what can work better, and implement something new only where it is justified.
Source
Rory Sutherland, Life lessons from an ad man, TEDGlobal 2009.
