Digital transformations often stall because of sequence.
The firm starts in the wrong place. By the time anybody notices, it has spent months building something technically sound and operationally sensible that has made little difference to clients or the people serving them.
The usual debate presents two directions. Inside-out starts with systems, data and internal processes. Outside-in starts with the experience and outcome a client needs. Neither direction is inherently right. The useful strategy connects the two and chooses the smallest foundation required to improve a valuable journey.
The gravitational pull of inside-out
I understand why firms look inward first. The CRM is a mess. The intranet has barely changed in years. Finance runs on spreadsheets that would make a first-year analyst wince. Three systems do not talk to one another, and the workaround involves somebody called Dave exporting CSV files every Thursday.
Those problems are visible to leadership and colleagues. They have owners, costs and established solution categories. A CRM replacement can feel like a prerequisite for everything else, so the firm migrates, cleans data and works through adoption. It then resurfaces to find the website still undersells the work, clients still return PDF forms by email and onboarding still crosses several disconnected teams.
The internal programme may have been worthwhile. The mistake was the assumption that it had to be finished before any external experience could improve. Internal estates are never "finished". If client value waits for perfect foundations, it waits indefinitely.
What outside-in means in practice
Starting outside-in means opening with a different question: what is the client trying to achieve, what do they experience today and where does that journey fail?
The answer may involve a website, a portal, advice, a colleague, an internal workflow or all five. Outside-in is not a coat of attractive interface paint over a broken process. It traces the desired client outcome back through the operation and technology needed to support it.
A mid-market management consultancy we worked with initially saw knowledge management as its digital priority. Finding documents was difficult and onboarding consultants took too long. Those were legitimate issues. Looking at the prospect journey exposed a different constraint: the firm had invested heavily in useful thinking, yet referred prospects struggled to find relevant evidence of its expertise online.
That observation changed the first phase. The firm improved the structure and discovery of its content and connected useful prospect signals to its relationship process. Seeing the journey changed the sequence, while knowledge management remained on the roadmap.
Outside-in work should begin with evidence:
- interviews and observation across the client journey;
- behavioural and operational data, including abandonment and waiting;
- complaints, avoidable contacts and manual workarounds;
- the commercial or service outcome the journey supports;
- the internal dependencies that cause or constrain the problem.
This prevents "client-centric" becoming a slogan used to justify a preselected website project.
When foundations genuinely come first
Sometimes the internal foundation is causing the client problem. Fixing it is then part of outside-in delivery, even when most of the work happens behind the scenes.
We have seen client applications generate persistent errors because an external user was forced through a workflow designed around internal processing. A new front end alone could not solve the policy, data and process conflict underneath it.
Foundation work should lead when it is necessary to address a material constraint such as:
- unsafe or unreliable handling of client or personal data;
- a security, accessibility or regulatory risk requiring prompt remediation;
- data quality that makes the intended service misleading or unworkable;
- an integration or identity gap blocking a critical journey;
- resilience problems that put service continuity at unacceptable risk;
- an operating process that repeatedly creates errors, delay or unfair outcomes.
This is triage, rather than a licence to rebuild the entire estate before releasing value. Define the minimum condition the foundation must meet, the journey it enables and the evidence that will allow the programme to move on.
Internal inconvenience matters too. Repeated manual work, poor knowledge access and fragile spreadsheets can consume capacity and create risk. Compare them with client-facing opportunities using the same criteria instead of assuming either direction wins by default.
Use a journey-to-foundation map
The binary question becomes more useful when turned into a map.
Start with one priority journey and intended outcome. Break the journey into important moments. For each moment, show the people, policy, data, systems and suppliers required behind it. Mark which dependencies are adequate, which need a contained change and which genuinely block progress.
For example, improving client onboarding may require:
- clearer expectations before instruction;
- a simpler way to provide information and documents;
- identity and access controls suited to the risk;
- data moving into the case or CRM system without rekeying;
- operational ownership for exceptions;
- status updates that make waiting understandable.
The first release might improve expectations, remove duplicated questions and connect one critical data flow. It does not need to replace every system involved. Equally, redesigning the form while leaving manual rekeying and unexplained exceptions untouched would be a shallow version of outside-in.
Minimum viable foundation, then visible value
For many firms, the practical approach is "minimum viable foundation, then outside-in for everything else". This is how we frame sequencing through Distinction's WHNN framework: What and How, for the Now and the Next.
Identify the foundation changes that are necessary for the chosen experience. Fix those to a standard that is safe, supportable and extensible enough for the next known step. Then release a meaningful improvement and learn from it before widening the programme.
"Minimum viable" does not mean minimum security, governance or accessibility. It means resisting speculative foundation work whose connection to a priority journey is weak. An identity service needed for onboarding is a dependency. A complete enterprise data model that might support personalisation one day is a separate investment decision.
Visible progress can build confidence, although visibility should not be confused with superficiality. A client may never see an integration, yet notice that information no longer needs repeating. A relationship partner may never see the data model, yet receive more useful context before a conversation. Define visibility as an observable service change.
Keep two horizons connected
A sequence becomes dangerous when the contained first phase creates another dead end. Use two horizons.
Now contains the journey improvement and necessary foundations the firm can deliver and learn from soon. It has clear owners, measures and decision points.
Next records the capabilities likely to follow, the uncertainty around them and the architectural or organisational choices the current work must preserve. It is directional enough to prevent short-term fixes from closing valuable options, without pretending distant scope is settled.
Review both horizons at an agreed cadence. If evidence changes the journey priority, say so. If a foundation dependency expands, challenge whether the first outcome can be reached another way. If a visible improvement performs poorly, investigate before funding the next release.
This avoids two common traps: an internal programme that never reaches the client and a series of front-end changes built on increasingly fragile operations.
A mistake worth preserving
Early in my career, I persuaded a professional-services firm to start with a full CRM overhaul before touching anything client-facing. The logic was coherent and the execution was competent. Eighteen months later, partners were asking why nothing felt different. Clients had noticed no improvement.
We had built a tidy engine room for a ship that was still losing passengers over the side. I would sequence that work differently now.
The lesson is not that CRM work lacks value. We had failed to define which client or colleague behaviour the new foundation would improve first, so adoption and value were deferred until after a large technical milestone. A journey-led sequence would have exposed the minimum CRM changes needed and delivered them alongside a visible service improvement.
The sequencing question is the strategy question
Inside-out versus outside-in is a strategic choice about where value, risk and learning should appear first.
Use four questions to decide:
- Which client or business outcome matters now, and what evidence shows the constraint?
- Is an internal dependency actively causing or blocking that outcome?
- What is the smallest safe foundation change that enables meaningful progress?
- What will clients or colleagues be able to do differently, and how will we know?
Sometimes the responsible first move is invisible infrastructure. Sometimes it is a client-facing improvement with very little platform change. Most often it is a deliberate combination.
The useful test is broader than "will clients notice?" Ask whether somebody will experience a meaningful improvement, whether material risk will fall, or whether the firm will learn enough to make the next decision better. If none is true, you may be building in the wrong direction.
I have written separately about diagnosing whether the client experience is costing the firm business. That is where an outside-in view begins. Once the direction is clearer, use the guide on how to scope the first phase to turn it into a contained piece of work.
