Working out what the strategy actually asks of the experience

For a long time I thought of strategy as something that arrived from elsewhere and then got translated into design work. A plan would land, and my job was to work out what it meant for the journeys, the pages and the product roadmap.

That version of the job is fine, and I did it for years. It also has an obvious limit, which is that you inherit assumptions you haven't tested and you build against them at speed.

The Level 7 programme I completed with Corndel and Imperial College London changed how I think about this. Looking properly at organisational performance, finance and transformation made me realise that strategy is mostly a set of choices about where money and attention go, and that experience decisions are one of the places those choices become real.

A strategy that people can't picture doesn't get delivered. In my experience the failure is rarely disagreement, it's that nobody can see what the words mean for the thing they're working on next week.

So a lot of what I do is translation. I take an ambition like growing repeat purchase or entering a new market and work out which parts of the customer experience have to change for that to be plausible.

That usually produces a much shorter list than people expect. It also tends to expose the parts of the plan that were never going to work, which is uncomfortable but useful to find early rather than halfway through a build.

Strategy conversations get stuck when everyone in the room is offering a view and nobody has anything to point at. I have sat in plenty of those.

At Selfridges I built the research function from nothing, partly because I wanted a way to settle those arguments with something other than seniority. Getting from roughly three studies a year to weekly experimentation on a £60k annual research budget meant we could answer questions in days instead of quarters.

It doesn't remove judgement. It just means the judgement is applied to something real, and you find out sooner when you were wrong.

I'm still fairly prone to over-designing the strategy itself. There's a temptation to produce something coherent and complete when what the organisation needed was a decision and a first move.

I've also learned that a strategy delivered without changing how teams work is mostly decoration. Introducing product and agile ways of working at Selfridges, moving from ad-hoc projects to sprint-based delivery, probably did more for delivery than any document I wrote in the same period.

So I now spend more time on the operating side than I used to. Who decides, how often, with what information, and what happens when the answer is no.