Menu

Digital Transformation

Why starting with technology is the fastest way to fail

When technology becomes the starting point, it quietly defines the solution before the problem has been properly understood.

Why digital work that begins with platforms and systems often ends up constrained by them, and why better strategy starts with the problem instead.

05 August 20244 min read

In short

Why digital work that begins with platforms and systems often ends up constrained by them, and why better strategy starts with the problem instead.

Why technology feels like the sensible place to start

There's usually pressure to move forward, to make something tangible, and technology provides something concrete to anchor that momentum. Discussions quickly centre around , , , and capabilities, and from that point on, the direction begins to form around what those systems can support.

This creates an immediate sense of progress. There are options to compare, to evaluate, and decisions that feel actionable. From the outside, it looks structured and purposeful. But that structure is being built on an assumption that the problem is already understood, when in reality it has often been defined indirectly through the lens of the technology itself.

There is usually an organisational reason for it as well. Technology has an owner, a budget line and a procurement . Problem definition has none of those things, so it belongs to nobody in particular and is easy to skip past on the way to something that can be approved.

Starting with technology creates momentum quickly, but it often means the shape of the solution is being set before the problem is properly understood.

How the technology starts shaping the problem

As a result, the conversation shifts away from understanding and towards adaptation. Instead of asking what the business is trying to achieve or where users are experiencing , the focus moves to how those needs can be accommodated within the chosen . Requirements start to emerge based on what the technology allows, rather than what is actually required. Over time, the begins to reflect the capabilities and limitations of the platform rather than the outcomes it was originally intended to support.

Because this happens incrementally, it rarely feels like a conscious trade-off. Each decision is justified in isolation, and each step appears reasonable when viewed on its own. But the cumulative effect is that the work becomes increasingly constrained by choices made before the problem was properly understood.

The clearest symptom is the language changing. Discussions that started with what customers are struggling with turn into discussions about what the supports out of the box. Once requirements are being written as configuration decisions, the problem has quietly been redefined as whatever the can already do.

Key takeaway

When technology comes first, the strategy often ends up adapting to the system instead of defining what the system needs to support.

What changes when technology enters at the right stage

When technology is introduced at the appropriate stage, it plays a fundamentally different role. The work begins with a clear understanding of what needs to improve, where the exists, and what outcomes are being targeted. Only once that foundation is established does the conversation move towards selecting the technology that can best support it.

Technology is no longer driving the direction, but supporting it. become explicit rather than implicit, and are understood in relation to the problem rather than discovered during . The strategy remains aligned to its original intent, and the technology becomes an enabler rather than a limiting factor.

Most digital initiatives don't fail because of the technology itself, but because it was introduced before there was sufficient around what needed to be solved. Starting with technology creates a sense of momentum, but it often to decisions that are difficult to unwind and a direction that becomes increasingly constrained over time.

This does not mean spending months on before anyone is allowed to mention a vendor. It means being able to state, in a sentence or two, what has to be true for the work to have been worth doing, before the shortlist is drawn up. That sentence is what a selection should be judged against.

It also gives you a way to say no later. When the cannot do something, the question stops being whether to work around it and becomes whether the thing it cannot do was one of the outcomes that justified the investment. Without that reference point, every compromise looks equally reasonable.

Written by Andy Scott

Strategic design, UX and digital transformation thinking from real projects.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services.

Previous feedback

I had a fantastic experience working with Andy. One of his most impressive achievements during our time at NHS HEE was masterminding a deeply complex information architecture for a new platform that brought together a large number of legacy websites.

Will Parkhouse

Senior Content Designer