What happens when you narrow the options

The bootcamp has been running for a few months now. Strategic Behavioural Design. Multi-day sessions with practitioners from different organisations, sectors, and levels of seniority. Change managers, service designers, product leads, L&D professionals, the occasional policy officer.

I'm learning something about how the system travels when it leaves my desk.

The Drive Grid lands fastest. Always. The 3x3 structure is intuitive in a way that surprises me every time. Within half an hour, a team has filled in the canvas with a rough map of what's driving the behaviour they care about. Red for hindering. Green for enabling. The diagnostic questions do their job without much prompting. "What do people feel about this?" "What are the unwritten rules of the group?" "What barriers stop people from acting?" Teams answer those questions with real specificity, and by the end of the exercise they have a picture of their problem that most of them have never had before.

That part of the system carries itself. I facilitate, but the grid is doing the thinking. Someone with no behavioural science background can use it and come out the other side with a genuine diagnosis.

The pattern selection is where things slow down.

Fifty-two patterns, grouped into ten strategies. Even with the groupings, the choice is daunting. I keep hearing the same question: "These all look relevant. How do I narrow it down?"

And here's the thing I've been noticing more and more carefully. When someone asks that question in the bootcamp, I do something quite specific. I look at the grid. I look at which cells are red. I think about the mechanisms I've seen in similar projects. I mentally run through the connection chain. And then I say: "Based on what you've described, I'd start with this one. Here's why."

Three things happen in the room when I do that.

First, relief. Visible, physical relief. The team was staring at fifty-two options and feeling the weight of all that possibility. Now they have one. They can breathe.

Second, trust. The recommendation came with reasoning. I didn't just pick a card at random. I explained the chain: this driver, through this mechanism, suggests this strategy, which points to this pattern. The reasoning is transparent. They can see why I'm recommending what I'm recommending.

Third, action. They can actually go and try something on Monday. The pattern has a structure. It has a mechanism. It has examples. They know what to do, why it might work, and what to watch for. The gap between "we've diagnosed the problem" and "we know what to try" has been closed.

Those three reactions, relief and trust and action, feel like the core of what BehaviourKit should deliver. They're the emotional signature of a good recommendation. And right now, they happen because of me, in the room, doing the narrowing.

Which means they don't happen when I'm not there.

If fifty people go through the bootcamp, all fifty leave with the ability to diagnose. They can use the grid. They can identify the red zones. They can describe what's driving the behaviour they're working on. That skill transfers.

What doesn't transfer is the routing. The bit where the diagnosis becomes a recommendation. That stays with me, because it lives in my judgement, my experience, and my familiarity with the patterns. The moment I leave the room, the system reverts to: here are fifty-two options, choose wisely.

I've started writing this observation down more formally, because I think it points to the most important thing I need to build. The system needs to do what I do. Take the diagnosis. Consider the relevant mechanisms. Navigate the chain. Recommend a starting point. Explain why that starting point is the right one. And do all of that without a facilitator present.

That's a recommendation engine. Which is a very different kind of product from a card deck.

There's a parallel in the wider design world that I find useful. Service design has matured to the point where the thinking is often excellent but the tooling hasn't kept pace. Teams can map systems, identify pain points, and articulate problems with impressive clarity. But the transition from "we understand the problem" to "we know what to do about it" is still dependent on experienced practitioners making connections that the methodology doesn't encode.

BehaviourKit has the same gap. The diagnosis methodology is strong. The intervention library is strong. The connection between them runs through a person.

I need to make the connection run through the system instead.

Go deeper into the Building BehaviourKit series: