Double Diamond: Process Framework, Not Prioritisation—And It Needs a Time-Box

This is one of RoadmapOne ’s articles on Objective Prioritisation frameworks .

The British Design Council formalised the Double Diamond in 2005, and it’s been a design and product staple ever since. Two diamonds: the first explores the problem space (Discover → Define), the second explores the solution space (Develop → Deliver). Diverge to explore, converge to decide. Twice.

The framework is everywhere—design sprints, discovery workshops, product strategy decks. Here’s what it isn’t: a prioritisation framework. Double Diamond describes how to approach problem-solving. It doesn’t tell you which problem to solve first.

Sign up now (free) to allocate discovery capacity explicitly

The Two Diamonds

First Diamond: Problem Space

Discover (Diverge): Explore the problem space broadly. Customer research, stakeholder interviews, competitive analysis, data mining, ethnographic observation. You’re trying to understand the landscape without prematurely narrowing.

Define (Converge): Synthesise discoveries into a clear problem statement. What’s the specific problem worth solving? Who has it? Why does it matter? The output is a focused problem definition that constrains the second diamond.

Second Diamond: Solution Space

Develop (Diverge): Explore potential solutions broadly. Brainstorming, ideation workshops, concept sketches, prototypes, benchmarking. Generate options without committing.

Deliver (Converge): Select and refine the best solution. Test, iterate, build, ship. The output is a delivered solution that addresses the defined problem.

The Shape Matters

The diamond shape is instructive. Each phase starts narrow (what do we know?), expands to explore (what could we learn/try?), then narrows again (what did we decide?).

Divergence is exploration. Convergence is decision. You need both. Teams that only diverge never ship. Teams that only converge build the wrong thing.

Balance exploration and execution in RoadmapOne’s capacity grid

What Double Diamond Does Well

Shared Vocabulary

When product and design teams align on Double Diamond, they have common language:

• “We’re still in Discover—we haven’t talked to enough customers yet”
• “We’re in Define—we need to commit to a problem statement by Friday”
• “We’re entering Develop—let’s brainstorm solutions before evaluating”
• “We’re in Deliver—it’s time to converge and ship”

This clarity prevents friction. When engineering asks “What are we building?” and design says “We’re still discovering,” Double Diamond vocabulary makes clear that’s a phase, not avoidance.

Permission to Explore

Many organisations pressure teams to jump to solutions immediately. “We have a roadmap commitment—just build it.” Double Diamond provides intellectual cover for exploration: “We’re in the first diamond. If we skip to solutions, we’ll build the wrong thing.”

That permission matters, especially for teams recovering from feature factory culture.

Preventing Premature Convergence

The diamond shape reminds teams to diverge before converging. Don’t lock in a problem statement before you’ve explored the space. Don’t lock in a solution before you’ve generated alternatives.

Premature convergence is one of the most common failure modes in product development—and Double Diamond explicitly guards against it.

What Double Diamond Doesn’t Do

It’s Not Prioritisation

Double Diamond describes how to approach a problem. It doesn’t tell you which problem to approach first.

You might have five potential problem areas to explore. Double Diamond can guide discovery for each. But which one deserves discovery resources this quarter? That’s a prioritisation question the framework doesn’t answer.

Use RICE , BRICE , or another framework to decide which problems deserve discovery investment. Then use Double Diamond to guide that discovery.

It Doesn’t Impose Time Constraints

The diamond shape implies you should spend time diverging before converging. It doesn’t say how much time.

This is the framework’s biggest weakness. Teams without discipline will diverge indefinitely:

“We’re still in Discover. We need more customer interviews.”

Six months later:

“We’re still exploring. The problem space is complex.”

The diamond shape describes phases but doesn’t impose deadlines. Without external constraints, discovery becomes a permanent state.

It Doesn’t Produce Prioritised Backlogs

Double Diamond produces understanding (first diamond) and a solution (second diamond). It doesn’t produce a ranked list of opportunities or a prioritised feature backlog.

For that, you need frameworks like Opportunity Solution Trees (which generate candidate solutions) and RICE/BRICE (which rank them).

The Time-Boxing Fix

Double Diamond needs time constraints to be useful. Without them, divergence never ends.

Time-boxed discovery solves this. “We have two sprints for the first diamond—explore the problem space, then commit to a problem definition by sprint end.”

The diamond shape tells you what to do. The time-box tells you when to stop.

In RoadmapOne

In capacity-based planning , you allocate squad-sprints explicitly. Discovery work gets explicit allocation:

“Squad A, Sprints 3-4: First diamond for Objective X. By end of Sprint 4, we’ll have a defined problem statement.”

“Squad A, Sprints 5-7: Second diamond. Generate solutions, prototype, converge on MVP scope.”

“Squad A, Sprints 8-12: Delivery. Build the solution we’ve validated.”

The roadmap shows capacity allocation, not process phases. The board doesn’t need to know you’re in “Discover” versus “Define”—they need to know you’ve allocated specific sprints to discovery before delivery begins.

Allocate discovery capacity explicitly in RoadmapOne

Double Diamond in Context

With Opportunity Solution Trees

OST structures the output of Double Diamond:

• First diamond (Discover/Define) produces the Outcome and Opportunities
• Second diamond (Develop/Deliver) produces Solutions and tests via Experiments

Double Diamond is the process. OST is the artifact that captures what you learned.

With Impact Mapping

Impact Mapping can structure discovery within the first diamond:

• Who are the Actors?
• What Impacts (behaviour changes) would achieve the goal?

Then the second diamond explores deliverables that create those impacts.

With GIST

GIST’s confidence meter tracks learning across diamonds. An idea starts at low confidence in early Discover, increases through Define as the problem clarifies, increases further in Develop as solutions validate, and reaches high confidence by Deliver.

Where Double Diamond Fails

Endless Discovery

The failure mode I see most often: teams use Double Diamond to justify never committing. “We’re still in the first diamond” becomes a perpetual state.

At some point, discovery has to produce outputs that feed planning. The problem statement has to get defined. The solution has to get selected. Delivery has to happen.

Time-boxing is the cure. If you’re still in Discover after the allocated sprints, you’ve either scoped the problem too broadly or you’re avoiding commitment.

Process Theatre

Some teams adopt Double Diamond vocabulary without the discipline. They say “we’re in Develop” while actually just building whatever was already planned. The diamonds become labels for phases that were happening anyway, not a genuine shift in how work happens.

Double Diamond only works if teams actually diverge before converging—genuinely exploring alternatives rather than rubber-stamping predetermined solutions.

Doesn’t Connect to Capacity

“We’re in the second diamond” tells your team where you are. It doesn’t tell the organisation how much capacity you need or how long delivery will take.

For planning purposes, you need to translate Diamond phases into sprint allocations that connect to capacity reality. “Two sprints for first diamond, three sprints for second diamond, five sprints for delivery” is actionable. “We’re doing Double Diamond” is not.

Practical Implementation

Set explicit phase durations. Before starting, decide: “First diamond: 2 weeks. Second diamond: 3 weeks. Delivery: 6 weeks.” The diamonds become time-boxes, not open-ended explorations.

Define phase exit criteria. What does “done with Discover” look like? A documented problem statement? A defined target user segment? Specific metrics for success? Make convergence concrete.

Allocate capacity in RoadmapOne. Discovery is real work that consumes real capacity. Allocate squad-sprints for each phase. Show the board that discovery has defined scope, not infinite horizon.

Use other frameworks within diamonds. Double Diamond describes phases. Use Impact Mapping or customer research frameworks within Discover. Use OST to structure outputs. Use RICE/BRICE to prioritise solutions in Develop.

Treat Deliver as delivery, not discovery. Once you’re in the second convergence, you’re committing. Resist the urge to “keep exploring” once you’ve entered Deliver.

The Bottom Line

Double Diamond is a process framework, not a prioritisation framework. It describes how to approach discovery—diverge to explore, converge to decide, twice—but doesn’t tell you which problems deserve discovery or which solutions deserve delivery.

Use it for shared vocabulary between product and design teams. Use it to protect exploration time from premature convergence. Use it to structure your thinking about problem space versus solution space.

But time-box the diamonds. Allocate discovery capacity explicitly in RoadmapOne. Connect process phases to sprint allocations and capacity reality. And use RICE , BRICE , or another framework for actual prioritisation.

Double Diamond tells you how to explore. RoadmapOne tells you how much capacity you have for exploration. Together, they connect process discipline to delivery reality.

Get started with RoadmapOne (free) and connect discovery to delivery

References

• Design Council, The Double Diamond — Original framework
• Opportunity Solution Trees — Structuring discovery outputs
• Impact Mapping — Structuring problem exploration
• GIST Framework — Confidence tracking across phases
• Capacity-Based Planning — Allocating discovery capacity
• Objective Prioritisation Frameworks — Complete guide to all frameworks