The Double Diamond: solve the right problem, then solve it right

Somewhere in the first meeting of almost every engagement, a client walks in holding a solution. It arrives fully formed - 'we need an app', 'we need a portal', 'we need AI in the onboarding' - and it's held with real conviction, because someone senior has usually been carrying it around for months. The hardest and most valuable thing we do in that meeting is not say yes, and the framework that gives us permission to not say yes (politely, and with a plan) is the Double Diamond.

The model has been around since 2005, when the British Design Council drew it after studying how good design teams actually worked across eleven very different companies. It's older than the iPhone and it looks like something you'd sketch on a serviette, which is roughly why it's survived - the ideas that last in this industry tend to be the ones simple enough to draw and hard enough to actually do.

Two diamonds, four stages

Picture two diamond shapes side by side. The first diamond is about the problem, the second is about the solution, and each one opens wide before it narrows - which is the whole trick, and we'll get to it. Reading left to right, you pass through four stages.

1. Discover - go wide on the problem. Talk to customers, pull the data, watch how the work actually happens. You're gathering evidence, not confirming the brief.
2. Define - converge on the problem that matters. All that discovery gets distilled into one sharp, agreed statement of what's actually broken and for whom.
3. Develop - go wide on solutions. Sketch several genuinely different answers to the defined problem, prototype the risky ones, let weak ideas fail cheaply on paper.
4. Deliver - converge on the answer. Build the solution that survived, test it against reality, and ship it in slices that keep teaching you.

The first diamond ends with a problem definition, and the second ends with a shipped product, and the model's one commandment is that you're not allowed to start the second diamond until the first one has closed. Solve the right problem, then solve it right - in that order, every time.

The discipline is in the shape

What makes the Double Diamond useful isn't the four labels (any process has labels), it's the alternation of two opposite modes of thinking. Diverging and converging are different muscles, and most teams are naturally good at only one of them. The diamonds force you to use both, twice, at the right moments.

Diverging means deliberately holding the space open - more interviews than feel necessary, more sketches than you'll ever build, ideas from the quiet people in the room and not just the confident ones. Converging means the opposite: killing options, writing the one-sentence problem statement, choosing. Teams that only diverge produce workshops and wall art, teams that only converge produce the first idea anyone had, built efficiently - and honestly, of the two failure modes, the second one is more expensive, because it ships.

Teams that only converge ship the first idea anyone had. Efficiently.

Where it goes wrong in practice

Having run this model across a decade of engagements, we've learned that it fails in predictable ways, and knowing them is most of the craft. The first failure is skipping the first diamond entirely - the client arrives with the solution, the timeline is tight, and discovery gets waved through as a formality. Six months later the thing launches, works exactly as specified, and doesn't move the number, because the specification answered a question nobody had validated.

The second failure is fake divergence, where the team goes through the workshop motions while the decision has already been taken upstairs - you can tell, because the 'options' are one real idea flanked by two straw men. The third is the opposite: discovery that never closes, research compounding on research, because converging means committing and committing means being wrong in public if it doesn't work. Define is the stage where courage lives, which is exactly why it's the stage that gets skipped.

The fix for all three is the same, and it's unglamorous: make the gates explicit. We write the problem statement down and get it signed before any solution work starts, we require genuinely different options at the develop stage (different enough that they'd cost different amounts), and we timebox discovery so it converges by appointment rather than by exhaustion.

How it runs inside our engagements

In practice, our first diamond usually runs as a discovery sprint - a few weeks of interviews, analytics work and journey mapping that ends with the problem definition and, importantly, a number attached to it (what the problem costs, what solving it would earn). That number does a lot of quiet work later: it ranks the solution options in the second diamond, it sizes the budget honestly, and it gives everyone a shared definition of 'worked' long before launch day.

The second diamond then runs as design and build in slices, and the model blends into how we ship anyway - prototypes before commitments, the riskiest assumption tested first, delivery in increments that go live early rather than a single reveal at the end. The diamonds aren't a ceremony we perform before the real work; they're the reason the real work points somewhere.

None of this is complicated, which is rather the point. The Double Diamond is a twenty-year-old drawing that fits on a serviette, and it survives because it encodes the two hardest sentences in product work: 'we don't know yet' at the start, and 'we've decided' at the middle. Get comfortable saying both at the right moments and the drawing takes care of the rest - and if you arrive at our first meeting holding a solution, now you know why we'll smile, put it carefully to one side, and ask what problem it was meant to solve.