What does Adaptive Edge do?

Adaptive Edge is a UK strategy and innovation consultancy. We help organisations decide what to change, then make the change real: strategy built with the people who must carry it, AI adoption inside real work, and behaviour change that sticks.

How is Adaptive Edge different from a traditional strategy consultancy?

We do not hand over a deck and leave. Strategy is made in working sessions with your own teams, so the people who must deliver it own it from day one. We prove an approach in one team before asking the whole organisation to change.

Who does Adaptive Edge work with?

Global organisations across healthcare, industrials, media, retail technology and financial services, including ITAB Group, Freudenberg, Sky and Sandvik Coromant. Engagements run across Europe and beyond, remote and on site.

How does Adaptive Edge approach AI adoption?

We put AI to work inside real workflows rather than running abstract training. Teams learn on their own live work, we measure what actually changes, and we scale only what proves useful.

What does a typical engagement look like?

Most engagements combine focused research, co-created working sessions, and hands-on tools built for your context. They range from a single workshop to a multi-phase transformation programme.

How do we start a conversation?

Use the contact form on the site. We usually begin with a short call to understand the decision you are facing, and we will tell you plainly if we are not the right fit.

How Might They

By Nathan Waterhouse · 2026-06-17

"How might we" is one of the most useful tools I carry into work with teams. It comes from design thinking, which is one method among several I draw on, but of all the bits and pieces that survive a project, this is the one that tends to stick. Months after we've worked together, it's the phrase I hear people reach for instinctively when they're framing a problem. It does real work. It opens a problem up where other questions close it down.

It took me a long time to notice the trap inside it. I'd watched teams write hundreds of these questions before I worked out what was going wrong in a lot of them. And the more I looked, the more I saw it wasn't really about the question. Let me show you what I mean, with one that caught my eye last week.

"How might we provide an additional offer to a customer moving to SaaS?"

On the face of it, it feels like a great HMW: it's human-centred, it uses the "how might we" construct. But there are four problems contained within it. The first is visible to anyone who has done design work. The others sit deeper, and I want to unpack all four, but let's start with the obvious one.

1. The solution was already in the question

Look at who's doing the work in the question. The team is the active party, providing and offering, and the customer is the place the offering lands. The answer is sitting in the question too: "provide an additional offer" isn't a problem to explore, it's a solution. The team had decided what to build before they'd established what the customer was struggling with, and the HMW construct had let them do it without anyone noticing.

I asked them a different question. Not what we might provide, but what the customer moving to SaaS was actually trying to do, and what was making it hard. The benefit, rather than the offer. The next version was harder to answer, which was the point. They no longer had the answer ready. They had to go and find out.

That is the first problem, and if you've done any design work you'll have named it already: there's a solution baked into the question. It's the standard diagnosis, and it isn't wrong. It's just where most people stop. Telling a team to take the solution out doesn't explain why it got in, or why it keeps getting in when everyone in the room already knows it shouldn't. To understand that, you have to go down a layer.

2. The adjustment that ends too early

The team knew, in principle, not to bake a solution in. Knowing the rule turned out not to stop them breaking it. The problem isn't ignorance, it's that knowing a thing doesn't always lead to acting on it.

What gets in the way is a piece of cognitive labour we're all bad at sustaining. Nicholas Epley, Boaz Keysar and colleagues set it out in a 2004 paper, Perspective Taking as Egocentric Anchoring and Adjustment. We don't arrive at another person's point of view directly. We tune in first to our own, which is the automatic default, and only then adjust towards theirs, slowly and with effort. The adjustment ends early. We stop scanning the moment we catch something that sounds plausible, not when we reach the answer that's actually right. The team did exactly this: they tuned to their own reading, caught "provide an additional offer," and it sounded close enough to stop on.

3. Our own view is the loud one

Effort alone doesn't explain it, because we stop early even when we have time and want to do well. Something makes the customer's view harder to pick up than mere distance would suggest. Our own perspective is loud, and theirs is faint.

Our own situation arrives for free. We know our targets, our constraints, the thing we were already half-planning to build, and all of it is immediate and present in the room. The customer's experience has to be assembled out of fragments, a few interviews, some half-remembered data, an act of imagination. One is a thing you can simply hear. The other is a thing you have to construct, and a construction never sounds as real as the thing playing directly in your own head. When the two compete, and they always compete, the loud one wins. The customer doesn't drop out of the question because we forgot them. They go faint because, next to our own concerns, they were never as audible in the first place.

4. The accent you can't hear

This is the root of it, the part that makes the whole thing so hard to coach out of a team. We don't experience our own perspective as a perspective. We experience it as the way things are.

Think about your own accent. You don't have one, as far as you can tell. Other people have accents; you just speak normally. It takes a recording, or a stranger's reaction, to confront you with the fact that the neutral, unmarked, plainly-correct way of speaking you walk around inside is, to everyone else, a particular sound from a particular place. Your accent is inaudible to precisely one person in the world: you.

An organisation's view of the world works the same way. From inside it, your assumptions about what customers want, what the market is, what a good product looks like, don't feel like assumptions. They sound like plain sense, the obvious neutral truth any reasonable person would share. The customer's quite different reading of the same situation sounds, from where you stand, slightly off, a bit naive, not quite how things really are. Perspective-taking isn't simply effortful, then. We often don't register that there's another perspective to take at all, because our own has stopped sounding like one. You can't tune away from a frequency you can't hear.

The layers sit one on top of the next, and now the whole stack is audible. We don't hear our own frame as a frame, so we don't know an adjustment is needed. The customer's view is faint, so even attempted adjustment is hard. The adjustment is costly, so we stop it early. And what we stop on, the plausible answer close to home, is the solution already sitting in the question. The fault everyone can see turns out to be the top of a column that runs a long way down, and all of it is working on a team the moment they pick up a marker. It's a reminder that the tool was never the thing that mattered most. The mindset is, and the tool can just as easily reinforce the wrong one.

A cross-section showing the four problems stacked beneath the question: solution already chosen, adjustment ends too early, our priorities were louder, our assumptions sounded like reality.

How might they

The word I've been circling brings me back to the construct itself. The "how might we" form was coined by Min Basadur at Procter & Gamble in the early 1970s, and his insight was a good one: swapping "can" or "should" for "might" takes the judgement out of the question and opens it to possibility. The verb stopped doing harm.

I wouldn't drop the "we." It's there for a reason: it makes the work feel collective, shared, owned by the room. The trap is in what it also does. In a setting where the organisation's own frame is already the loudest thing present, and already inaudible to the people inside it, putting "we" at the head of the question places us, grammatically, at the centre of the very sentence that's supposed to be about someone else. The pronoun isn't the cause of the problem. It's the internal frame showing up in the grammar, our own voice taking the subject position out of habit, one more turn towards ourselves at the moment we meant to turn outward.

I've written recently about how the shape of a question changes what a room can think: first about whether you ask the reflective question at all, then about what a premortem does that a risk discussion doesn't. This is the third turn of the same screw, and the one that reaches furthest past the question into the place the question comes from.

When the customer says no

Here's the part that should worry anyone who's ever shipped something. The wrong question doesn't get caught at the whiteboard. It gets caught much later, by the customer, in the one moment that should set everything right and usually doesn't.

You frame the question from your own side, build what it points you at, take it to the customer, and they don't want it. That rejection is the most valuable signal the whole process produces: the customer's actual perspective, arriving at last, unmistakable. The exact thing you couldn't hear at the start, said out loud. But you have to be ready to hear it, to really listen.

The same view that wrote the question discards it. The rejection rarely lands as "we built from the wrong question." It lands as "the customer didn't get it." They weren't ready, they didn't see the value, they'll come round. The accent we couldn't hear in our own mouth, we now hear as mispronunciation in theirs. And it can't tell the difference between a customer who genuinely hasn't understood something good and one who simply doesn't want it, because it has no position outside itself from which to check. Sometimes they really haven't understood. But you can't know that from in here, and it is very good at assuring you it's always the former.

The discipline, then, isn't writing a better question, though that helps. It's treating the customer's "no" as information about you, not about them. The teams who learn anything can hear a rejection and wonder what they missed the first time. The ones who worry me are already explaining, with confidence, why the customer was wrong.