On Time, On Budget, and a Waste of Both – The difference between an inside-out and an outside-in organisation.

Many moons ago I worked for a large UK organisation, which shall remain nameless, that had grown fast by acquisition, leaving behind a tangle of systems held together with Sellotape and good intentions. Inevitably, it affected customers.

Imagine you are one of them. You ring up with a problem. The advisor confidently says the fix is in one of our stores, “pop along and all will be well”. So, you drive half an hour, pay for fuel and parking, and are met with a blank look. Sorry, there are no notes on your account… Hilarity ensues as you are bounced backwards and forwards between departments, where you have likely retold the story multiple times, as well as wasted a trip and potentially hours of your life! Sound familiar?

These experiences damage trust, erode loyalty and drive negative word of mouth. They also cost a fortune, because every one of those failed contacts must be staffed, in the contact centre, online, in store, and by the chatbots that irritate everyone.

There is real money in getting it right first time, and more in removing the need for the query at all!

So, very sensibly, the powers that be decided to do something about it. We were brought into a room and shown our new shining star: a new IT stack (ohhh shiny). Those of us who had started in grassroots roles knew exactly what it was like to serve customers with the old systems. So, we were delighted.

Good Intentions, Wrong Direction

The customer experience team were asked to define what good looked like, and they did a fine job. The problem was that their work was then popped in a drawer and left there.

The real work began in the requirements workshops, where we were given a clear KPI: “deliver on time and on budget”. Sensible enough, you might think. Those sessions ran for a long time, years if memory serves. The KPI never changed. The world, however, did.

So important was that KPI that requirements began to be descoped. Small things. Things that didn’t really matter. Except that those of us who had sat with customers were worried and raised it: “Can we talk about this one, it meets a real customer need?” The reply came back: “Don’t be a pain, that’s scope slip, we need to progress.” (Where was the psychological safety? That is another article, albeit one very relevant to transformation.)

And there was the problem. The original shining star, a better experience at a lower cost to serve, which is that rare thing benefiting customer and business alike, had been replaced by a new one: deliver the chosen system, on time and on budget, even as the world changed around it. And the result? The system was delivered. It did not, however, meet customers’ expectations. It failed publicly enough that newspapers took an interest, the next phase was cancelled, and it became a cautionary tale across our markets.

Inside-Out Versus Outside-In

Why this happens is well documented. The Standish Group has tracked large projects for decades and the picture is consistently sobering, with roughly seven in ten failing or significantly underperforming [1]. Research points repeatedly to the same thing: success criteria that measure delivery rather than outcome [2].

Our flawed perspective was, let us replace the system. The outside-in version would have been, let us understand our customers’ problems (outside), design the processes that solve them, and only then work backwards to find the technology that fits.

Instead, and this happens everywhere, organisations run an RFP (inside), look at what competitors have bought, and start building. It becomes internal navel gazing rather than an exercise in external customer empathy. We ultimately started with the IT stack and worked backwards, despite the good intentions of a lot of very capable people.

Start outside-in and the question becomes much clearer: how do we build an organisation where customers feel known, and never have to explain themselves twice? Design for that, and your systems, processes and teams may end up looking very different.

You Can Be Inside-Out While Doing Research

This is not only a technology problem, and it is not solved by quantitative research alone. In 1985 Coca-Cola reformulated its flagship product on the back of roughly 200,000 taste tests. That is not a shortage of customer input. But the sip test measured taste, and taste was not the job the product was doing. What people bought when picking up a can of Coke was familiarity, identity and continuity, and none of that was on the questionnaire. Garbage in, garbage out. The reformulation lasted less than three months.

In the Jobs to Be Done model [4], customers hire a product to do a job, and misreading the job means building the wrong thing, however polished. That is the trap. It is easy to look from the inside and, frankly, you are the worst people to ask. You are intrinsically biased. You have spent far too long looking at the painting to see what it is any more.

With the AI explosion this could not be more relevant. Everyone and their consultant is telling you that you need it, and perhaps you do, but what for, and at what cost, metaphorically and literally? If you cannot name the customer need it serves, you are building inside-out with a better logo on it. This is where I find the Kano Model [3] useful. It separates the basics people simply assume you have done (your notes being visible to whoever they speak to next), from performance needs that scale with satisfaction, to delighters that offer unexpected value. Applied well, it creates a halo effect that lasts years and makes customers far more forgiving of the odd problem, provided the service meets their key needs. Misread the tiers and you will polish something nobody asked for.

How to Stay Outside-In

Knowing this and holding onto it are different problems. Pressures mount, budgets tighten, timelines compress, and that is exactly when organisations slip and start cutting the very requirements that would have made the difference. If you do one thing, put the white coat on and go and observe your customers. Not a survey, but proper one to one conversations with a decent cross section of them. Quant is a measurement tool; it tells you something is wrong, rarely why. You are listening for two needs: the functional one, which is the task they are trying to complete, and the emotional one, which is what they want to feel while doing it.

Design for the functional alone and you get New Coke, technically better, but it left customers feeling “betrayed” (yes, that is the word they used) and was reversed in three months… Design for both and you get something people defend on your behalf. This costs very little. The expensive part is skipping it. Then protect it. Make the customer outcome a governance KPI alongside time and cost rather than as their poorer cousin, and when a requirement is descoped, record which customer need went with it and who signed that off. It sounds bureaucratic. It is the cheapest insurance you will ever buy, because it makes the drift visible while it is still reversible. Service design offers a fuller toolkit [5], but the principle matters more than the method.

The Learning

I am pleased to say that my mystery organisation learned from it. They cancelled the planned rollout, pivoted, and went on to build a very strong customer experience programme, which I was delighted to help lead. So you could argue it was not a failure, but only because they were brave enough to stop. An expensive bump in the road, but a valuable one.

So, over to you hand on heart: are you outside-in or inside-out? Do you really know who your customers are, and what they need you to solve? Is that understanding working backwards through your organisation into what you deliver? Or has something else accidentally become the shining star?