The Double Diamond Is an Elimination Tool

The Double Diamond gives you two shots at being right, and most teams waste both. Not because the model is wrong, but because they run it as a research process when it was designed as a decision process. Every workshop, every divergent sticky-note session, every convergent synthesis exists to produce two commitments. Teams collect the inputs and skip the commitments, then wonder why six weeks of discovery left them exactly where they started.

Two Problems Wearing One Costume

Product work contains two distinct problems, and they are not the same problem at different stages. The first is whether you are solving the right thing. The second is whether you are building the right solution. These fail independently. You can pick a real problem and build the wrong answer to it. You can build an elegant answer to a problem nobody has.

Most teams collapse the two into a single question, "what should we build?", and lose the ability to tell which half is broken when the work underperforms. The Double Diamond separates them on purpose. The first diamond owns problem selection. The second owns solution selection. This is the same instinct behind the five frames every PM uses to see a product clearly: pick the right lens for the question in front of you instead of mashing every question into one. The separation is the entire point; treat them as one and the model gives you nothing a Gantt chart wouldn't.

flowchart LR
    A[Explore Problems] --> B[Pick the Right Problem]
    B --> C{Closure Gate\nOne sentence?}
    C -->|No| A
    C -->|Yes| D[Explore Solutions]
    D --> E[Pick the Right Solution]
    E --> F{Closure Gate\nOne sentence?}
    F -->|No| D
    F -->|Yes| G[Ship]

The First Diamond Ends With a Sentence

Discover, then Define. You expand to understand the problem space, then you converge to commit to one direction. The expansion is the easy half. Everyone enjoys interviews, surveys, and the wall of insights that follows. The convergence is where the work actually happens, and where most teams quietly opt out. The expansion is also where inherited assumptions sneak through unchallenged, which is why research before building means stress-testing what you were handed, not just gathering more of it.

A closed first diamond is not a list of insights. It is not five user quotes arranged on a board. It is one problem statement your team will defend when a stakeholder pushes on it next quarter. If what you have at the end of the first diamond is a synthesis document, you have not closed the diamond. You have filed the research. The signals that should drive that statement are often hiding in plain sight; what support tickets taught me about prioritization is a reminder that the sharpest problem definitions come from evidence you already own.

A diamond closes when you can name the decision it produced in one sentence. If you cannot, the diamond is still open, no matter how much work sits inside it.

The Second Diamond Is Where You Say No

Develop, then Deliver. You expand to explore solutions, then you converge to eliminate. This is the part the name "Double Diamond" obscures and the part this whole piece is about. The second diamond is not where you launch. It is where you decide what you are not building. Deciding what to leave out is a discipline of its own; negative prompts are a PM skill makes the same case in a different domain, that naming what you reject is how you sharpen what you keep.

Convergence in the second diamond means killing options that survived the expansion. Three solution directions enter; one leaves. The two you drop are not failures of the process. They are the output of it. A team that reaches Deliver with every option still technically alive has not converged. It has deferred. And deferred decisions do not disappear; they resurface mid-build, when reversing them is expensive, as the "quick pivot" that quietly burns a sprint.

This is the take a manager might dispute: the value of the second diamond is the elimination, not the delivery. Shipping is the consequence of having eliminated well. Most roadmaps treat delivery as the achievement and elimination as overhead, which is exactly backward, and exactly why so many teams ship things they cannot defend.

How a Diamond Actually Breaks

Here is the failure in its most common form. Six weeks of discovery. Forty sticky notes. No committed direction. Everyone calls it thorough. It is not thorough. It is research theatre, motion mistaken for progress.

It usually breaks for one specific reason: someone in the room already had the answer before discovery started. When the conclusion is predetermined, the first diamond never had a chance. The expansion becomes a search for evidence that confirms the existing answer, and the convergence becomes a formality. You can run the entire ritual (the workshops, the affinity mapping, the synthesis readout) and produce nothing, because the decision was made before the diamond opened.

The tell is not the volume of research. It is the absence of a decision at the end of it. A diamond can hold a hundred insights and still be open. A diamond can hold three interviews and be genuinely closed. The insight count tells you how much input went in. It tells you nothing about whether a commitment came out.

The Test, and the Loop

There is one test for each diamond, and it is unforgiving. Can your team name, in a single sentence, the decision that closed it? Not summarize the research. Not present the findings. Name the decision. If the answer is a document, a deck, or a Miro board, the diamond is open and you should go back before you spend another week building on top of it.

And the diamonds loop, which most renderings of the model leave out. Deliver can send you back to Discover. Reaching the end is not proof you were right. It is the point where you find out. A solution that fails on contact with users is not a failure of execution; it is the second diamond telling you the first one closed on the wrong problem. The loop is a feature. Teams that treat the Double Diamond as a one-way pipeline lose the one thing it was built to give them: a structured way to discover they were wrong early enough to do something about it. Closing the loop honestly means reading the live signal for what it is, the way AARRR works as a diagnostic, not a metric: the numbers tell you which diamond to reopen.

The cost of running the Double Diamond as a research process is not wasted time, though there is plenty of that. It is the illusion of rigor. Forty sticky notes look like diligence. They give a team and its stakeholders the comfortable sense that careful work was done, right up until the moment someone asks what was decided, and the room goes quiet.

Related Articles

• The Five Frames Every PM Uses to See a Product Clearly
• Research Before Building: Stress-Testing Inherited Assumptions
• AARRR Is Not the Metric, It's the Diagnostic