How I think about UX strategy, design leadership, and the work of building products that genuinely matter to the people using them.
Most product organisations have learned how to ship software efficiently. Sprints run on time. Tickets close. Features arrive on roadmaps and leave them again. The question is whether the things being built are actually worth building, and whether everyone in the organisation has a clear, shared answer to it.
On direction
The dominant pressure in tech right now is for speed. Engineering teams are being asked to ship faster. AI tools are compressing delivery cycles. Throughput is up across the board. All of this is genuinely great. The problem is that the conversation about what we’re shipping, and why, has not kept pace with the conversation about how quickly.
A team running fast in the wrong direction will arrive at the wrong place faster than a slower team. This isn’t a complicated observation, but it’s the one that product organisations most consistently fail to act on. They treat the velocity question as solvable through better tooling and the direction question as something that will work itself out. It doesn’t.
Providing direction is the most valuable thing a mature UX function can do. It means answering, with the team and the leadership, the questions that delivery alone can’t: which problems are worth solving, who exactly we’re solving them for, and what success would actually look like in the lives of those people. When those answers are clear, delivery speed becomes useful. When they aren’t, more delivery just compounds the underlying confusion.
On the unit of work
The standard way of measuring product work is by what gets shipped. Features delivered, tickets closed, releases pushed. These are easy to count, which is why they dominate dashboards. They are also, by themselves, almost useless as indicators of whether the work mattered.
Shipping a feature isn’t the achievement. The achievement is the desired change in the customer’s behaviour, which translates into the business outcomes you care about. The only way to produce that behaviour change is through a change in the customer’s experience — which is what the feature was meant to deliver. Did this user’s life actually get easier? Did this customer find what they needed faster than they used to? Did the thing we were trying to solve actually get solved? Those are the questions that should follow every release. When the team can’t answer them, the team has a much bigger problem than its backlog.
Reorienting a team around outcomes for the user rather than the fact of delivery changes a lot of things. It changes what gets measured, what gets prioritised, what gets celebrated. It also tends to be uncomfortable, because outcome-driven work makes it visible when shipped features didn’t move anything. That visibility is exactly what the team needs. Most product organisations are full of features that didn’t work and quietly got absorbed into the system, never properly examined, because nobody was looking at outcomes.
On knowing customers
The most consistent gap I find inside product organisations is between how well the team thinks it understands its customers and how well it actually does — at the level required to make confident product decisions and stand behind the business outcomes those decisions are meant to produce. Teams have data — usage analytics, support tickets, satisfaction scores. They have personas, sometimes from years ago, sometimes recently refreshed. They have an internal sense, often confidently held, of who their users are and what they want.
Almost none of this is the same as understanding customers. Real understanding comes from sustained attention to small numbers of real people in their actual contexts — watching them use the product, listening to what they say when they aren’t being asked the right questions, observing not only their experience of using your product, but the moments that lead into and out of that interaction. This is slow, expensive in attention, and impossible to scale through dashboards. It’s also the only thing that produces the kind of insight that reshapes a roadmap.
All kinds of aggregate experience or satisfaction metrics — NPS, CSAT, SUS, CES, and other single-number experience scores — are worse than useless. They feel legitimate because they’re easy to collect and produce a trackable number, but the underlying claim — that customer experience can be compressed into a single value that means something — doesn’t hold up under examination. Two products with identical NPS scores can have completely different things going on underneath. The score moves up and the team has no idea what changed; the score moves down and they don’t know either. Once it becomes a target, the team starts optimising for the score, which usually means making the score more flattering rather than the experience better. The metric stops measuring anything except how good the team has gotten at gaming it.
Companies that build sustained competitive advantage through experience are almost always the ones that take qualitative customer understanding seriously. It’s the work most companies skip, because it’s harder to defend in a budget meeting than a survey platform. That’s exactly why it’s valuable.
On the role of design
The version of design I keep encountering inside companies is the executional one. Product decides what’s needed, engineering decides how to build it, design decides what it should look like and how it should work for the user. This is design as the polish layer. It’s still the version most non-design executives have in mind when they think about UX, and it consistently underuses what design can actually contribute.
Design’s most valuable contribution lives upstream of execution. What’s the actual problem here? Whose problem is it? Is this the right problem to solve? Is this the right way to solve it, or just the first plausible way we thought of? Designers, when they’re doing strategic work, ask these questions before the build starts. The answers shape what gets built, not just how it looks when it’s done.
This does not mean designers need to be running product strategy single-handedly. It’s an argument for designers running it jointly with their counterparts — with product, who carry the view on which directions are most viable for the business; with engineering, who carry the view on what’s actually feasible and at what cost; and with the customer-facing teams, who have the most direct connection to the real users and what their experience is actually like. Design, on its own, has the methodological apparatus for systematically working out what’s right for the user. The other functions have what design needs to turn that into something the company can actually build and sell. The strategic decision is what emerges when these views are brought together — not handed down by one of them and executed by the others.
On working across functions
Strategic UX work doesn’t happen inside a design team. It can’t. The work requires understanding things that no single function holds — the customer, the business, the technical reality, the operational constraints, what’s actually happening in support tickets and sales calls. A strategy that emerges from any one of these in isolation will be incomplete in predictable ways.
What this means in practice is that the cross-functional condition has to be set up deliberately. Heads of product, design, engineering, and customer-facing teams have to be in the same room — not occasionally, not as a stakeholder courtesy, but as the actual unit of strategic decision-making. This is harder than it sounds. Functions have their own pressures, their own metrics, their own internal cultures. Getting them aligned around a shared picture of where the product needs to go requires structure and patience.
Most of the work I do — particularly the Programme and the Workshop — is about creating the conditions under which this kind of work becomes possible. The structure is the thing. Without it, even the best-intentioned cross-functional efforts dissolve back into siloed conversation within a few months.
On UX maturity
A real UX practice isn’t a property of the design team, but a property of the organisation. It means the whole company — not just designers, not just product — has shared, current understanding of who the customers are and what their experience is like. It means strategic decisions get made with that understanding present in the room. It means qualitative research isn’t a service that gets occasionally requested, but a habit that the organisation runs on.
Most companies are nowhere near this. A few teams have built up real customer understanding, while the rest of the organisation operates on a mix of outdated assumptions and confident guesses, and the gap between them is treated as a personnel issue rather than a structural one. Closing that gap is slow work, but it’s the work that produces durable advantage. Companies that do it become genuinely difficult for competitors to displace, because they’re operating from a level of customer understanding that takes years to build.
This is the underlying purpose of the Residency — to give a company a senior practitioner in place long enough for that maturity to start growing, before they hire permanently into the role. Maturity grows over time. It can’t be installed.
None of this is novel. Most of it is what serious practitioners have been arguing for decades. The gap is between knowing it and acting on it — between agreeing that, say, qualitative customer understanding matters and actually structuring an organisation around it. Closing that gap is the work KSLV exists to do.
If any of this resonates and you’d like to talk about your situation, the three ways I work with companies covers most of what I’m offering, or schedule a call and we can start there.