Hello friends,

Welcome to Theory of Change where, for the next 12 editions, we’re taking a different approach. 

You see, I’ve spent years steeped in Silicon Valley mythology from my product days, and just as long inside the nonprofit sector. And, frankly, both can be as bad as each other when it comes to worshipping dubious ideas. 

So for this upcoming season we’re going to take some of the most criminally misunderstood, misused, or overhyped frameworks and mental models, pull them apart, and see what survives. The useful parts will be rebuilt for purpose-driven work in complex, human settings. The rest will be thrown in the sea.

(If you are new here, you can join a load of other brilliant nonprofit leaders, funders, creators, and social entrepreneurs by subscribing).

Without further ado, let’s get into it, for this week I’ll be slaying one of my favourite dragons: the design sprint.

🌒 DESIGN SPRINTS 🌒 

“Design sprint” used to mean something. A tightly choreographed, five-day pressure cooker from Google Ventures: all the decision-makers trapped in one room, moving from problem to prototype in a week. No slack, no drift, and no "you're on mute, Mike" optional Zoom attendance.

Now? It’s become a shorthand for vague innovation theatre: a jumble of Post-its, breakout groups, and someone (usually a white dude) confidently drawing a rectangle on a whiteboard and calling it “the app.”

Done properly, a design sprint can be thrilling. Done badly, it’s just a meeting with expensive office stationary tastes. And in the purpose-led world, that can do more than waste time (or, indeed, stationary). It can erode trust, flatten complexity, and leave the very people you’re trying to serve feeling like props in someone else’s performance.

What it’s supposed to be

The original recipe, as Jake Knapp published it, is simple enough to write on the back of a Blue Bottle napkin:

1. Map the problem.

2. Sketch solutions.

3. Decide.

4. Prototype.

5. Test with users.

It’s mostly facilitated in a “move fast and break things” kind of way. In Silicon Valley, that often means breaking things that belong to other people (e.g. privacy, trust, livelihoods) and calling it innovation. Which I, as you will learn, don’t much care for.

Where it falls apart

Look, when you unthinkingly drop the design sprint into purpose-driven, community, or political work, cracks appear. Why? Well, because…

• It prioritises speed over consent. Five days pushes for fast decisions, not thorough ones.

• It flattens complexity. “Manageable” often means cutting out essential context.

• It assumes trust exists. In communities with histories of exclusion or harm, you can’t schedule genuine candour on demand.

• It’s expensive. A room, all key people, five full days - plus paying community participants - adds up quickly.

• It’s a cargo cult. The props get copied; the discipline doesn’t. The result is sprint cosplay: all the fluorescence, none of the substance.

A better way to think about it

Strip away the hype and the props, and a design sprint is really made up of a few valuable core elements:

• A fixed block of protected time (no interruptions, no competing priorities. Everyone’s here for this and nothing else).

• A clear, bounded challenge (not “solve poverty,” but a specific question you can prototype answers to).

• A shared decision-making arc (Starting wide with possibilities, narrowing deliberately to one chosen path).

• A tangible output (Something concrete at the end that can be tested, even if it’s rough).

• An immediate feedback loop (Real-world input on the output while it’s still fresh enough to adapt).

In the purpose-led world, those are the bits worth keeping. They create focus, momentum, and prevent endless, circular debate. The rest you can drop without guilt: the five-day limit, the rigid GV script, the fetish for speed, and the assumption that everyone’s ready to bare their soul, unpaid, in a group exercise.

Try it this week

If you want the focus and momentum of a sprint without the baggage, start small:

1. Block real time. Protect a half-day or two short sessions; no phones, no emails, no split attention.

2. Pick one sharp question. It should be small enough to prototype and test without cutting out the complexity that matters.

3. Do a trust check. Privately confirm that people feel safe contributing. If not, fix that first.

4. Get the right authority in the room. Someone who can make decisions stick, not just take notes for “the real meeting.”

5. Prototype and test fast. Create something tangible, get immediate feedback, and adapt while it’s still warm.

Think of it as a contained burst rather than a five-day sprint. You keep the best bits (focus, bounded scope, tangible output, feedback loop) and ditch the bits that break trust, burn money, or reward speed over substance.

🌊 WAVE GOODBYE 🌊

The original design sprint was a love letter to speed. But we’re living through a pile-up of crises - political instability, AI upheaval, climate breakdown, etc. etc. - where speed is often the enemy. The “f**k it, ship it” mindset that works for apps can sink real people in the real world.

Instead: know when to move, and when to listen. That’s the skill worth stealing from the design sprint methodology. Not the props, not the stopwatch, not the breathless urgency.

*

Thanks for making it this far. If you read last week’s newsletter, then you know I’m off the socials (I don’t count YouTube as social media - ha!). Therefore, your shares of this newsletter are hugely, hugely appreciated.

I hope you enjoyed the launch edition of this new season. Next week: Start With Why

Take care,

Adam

p.s. If someone forwarded you this: welcome! Sign up here to get the next one.
p.p.s If you are into the weirder side of my creative output, I've a new video out for my ambient music project!