Double Diamond Design Framework: A Product Manager's Guide

Quick Answer (TL;DR)

The Double Diamond is a visual framework from the British Design Council that structures product work into two phases: finding the right problem and finding the right solution. Each phase follows a diverge-then-converge pattern. In the first diamond, you research broadly (Discover), then narrow to a specific problem statement (Define). In the second diamond, you explore multiple solutions (Develop), then refine and ship the best one (Deliver). The power of the framework is in its insistence that you spend real time in the problem space before jumping to solutions. For guidance on choosing between frameworks, see our Double Diamond vs Design Sprint comparison.

What Is the Double Diamond?

The Double Diamond was first published by the British Design Council in 2005, based on studying how designers at companies like Starbucks, Sony, and LEGO actually worked. The council observed that effective design processes all share the same shape: a period of expansion followed by a period of focus, repeated twice.

For product managers, the Double Diamond solves a specific and common failure mode: teams that jump straight from a vague problem to building a solution, skipping the critical work of understanding the problem deeply and exploring multiple approaches. When a VP says "we need a better onboarding experience," the instinct is to start wireframing. The Double Diamond forces you to first ask: what specifically is broken about onboarding, for whom, and why?

The framework is deceptively simple. Four phases, two diamonds. But the discipline it requires, particularly staying in the problem space long enough before moving to solutions, is where most teams struggle.

The Four Phases

         PROBLEM SPACE                    SOLUTION SPACE
    ┌─────────────────────┐          ┌─────────────────────┐
    │     DISCOVER        │          │     DEVELOP          │
    │   (Diverge)         │          │   (Diverge)          │
    │                     │          │                      │
   ╱ ╲                   ╱ ╲        ╱ ╲                   ╱ ╲
  ╱   ╲                 ╱   ╲      ╱   ╲                 ╱   ╲
 ╱     ╲               ╱     ╲    ╱     ╲               ╱     ╲
╱       ╲             ╱       ╲  ╱       ╲             ╱       ╲
 ╲       ╱             ╲       ╱  ╲       ╱             ╲       ╱
  ╲     ╱               ╲     ╱    ╲     ╱               ╲     ╱
   ╲   ╱                 ╲   ╱      ╲   ╱                 ╲   ╱
    ╲ ╱                   ╲ ╱        ╲ ╱                   ╲ ╱
    │     DEFINE          │          │     DELIVER          │
    │   (Converge)        │          │   (Converge)         │
    │                     │          │                      │
    └─────────────────────┘          └─────────────────────┘

  Diamond 1: Find the Right Problem    Diamond 2: Find the Right Solution

Phase 1: Discover (Diverge)

The goal of Discover is to build a broad, deep understanding of the problem space. You're not looking for solutions yet. You're trying to understand the people you serve, the context they operate in, and the real challenges they face.

Activities:

• User interviews (5-15 participants across segments)
• Contextual inquiry and observation (watching users in their actual workflow)
• Support ticket and NPS analysis
• Competitive landscape research
• Stakeholder interviews to understand business constraints
• Data analysis: funnel metrics, drop-off points, usage patterns

Output: A rich, unfiltered collection of insights, observations, and data points. At this stage, quantity matters more than organization. The Product Discovery Handbook covers these research techniques in depth, including interview scripts and synthesis methods.

Common PM mistake: Treating Discover as a checkbox. "We did 3 interviews, we're done." Effective discovery requires enough data to challenge your assumptions, not just confirm them.

Phase 2: Define (Converge)

Define takes the broad insights from Discover and synthesizes them into a clear, specific problem statement. This is where you answer: "Of everything we've learned, what is the most important problem to solve, and for whom?"

Activities:

• Affinity mapping (grouping insights into themes)
• "How Might We" question framing
• Problem statement writing: "[Persona] needs a way to [need] because [insight]"
• Prioritization: which problem, if solved, would create the most value?
• Stakeholder alignment on the chosen problem

Output: A well-defined problem statement that the team agrees on. This becomes the brief for the second diamond. A strong problem statement is specific enough to guide ideation but open enough to allow creative solutions.

Use the Assumption Mapper to identify which beliefs about the problem are validated by evidence and which are still assumptions that need testing.

Common PM mistake: Defining the problem in terms of a solution. "We need a better dashboard" is a solution statement. "Managers can't identify at-risk customers until it's too late because usage data is scattered across 4 tools" is a problem statement.

Phase 3: Develop (Diverge)

With a clear problem statement in hand, Develop is where you explore multiple possible solutions. The emphasis is on generating many ideas, not committing to one.

Activities:

• Ideation sessions (brainwriting, crazy 8s, SCAMPER)
• Concept sketches and low-fidelity wireframes
• Competitive solution analysis (how do others solve this?)
• Technical feasibility checks with engineering
• Concept testing with users (show 3 rough concepts, get reactions)
• Prototyping the top 2-3 concepts

Output: Multiple solution concepts at various levels of fidelity, with early user feedback on each. The goal is to have at least 3 distinct approaches before narrowing down.

Common PM mistake: Generating one idea and iterating on it. That's refinement, not ideation. If your Develop phase produces a single concept, you haven't diverged enough.

Phase 4: Deliver (Converge)

Deliver takes the most promising solution concept and refines it through testing, iteration, and implementation. This is where prototypes become products.

Activities:

• Usability testing with interactive prototypes
• A/B testing key design decisions
• Engineering implementation with iterative review
• Beta testing with a subset of users
• Performance monitoring and analytics instrumentation
• Launch planning and rollout

Output: A shipped product or feature that solves the problem defined in Phase 2, validated by real user behavior.

Common PM mistake: Treating Deliver as a one-way door. If user testing reveals the solution doesn't work, loop back to Develop (or even Define). The double diamond is iterative, not purely sequential.

How to Apply the Double Diamond in Practice

Mapping to Product Development Cycles

The Double Diamond maps to how modern product teams already work, but it makes the phases explicit:

Teams practicing continuous discovery (as described by Teresa Torres) essentially run the first diamond on an ongoing basis, maintaining an always-on pipeline of validated problems that feed into solution development.

Combining with Other Frameworks

The Double Diamond provides structure but doesn't prescribe specific methods. Fill each phase with the techniques that work for your team:

• Discover: Use Jobs to Be Done interviews to uncover underlying motivations, not just surface-level complaints
• Define: Apply Design Thinking synthesis methods like empathy maps and journey maps
• Develop: Run Google Ventures-style design sprints to compress ideation and prototyping. See the comparison between design thinking and design sprints for when each approach fits
• Deliver: Use agile delivery practices. The Lean vs. Agile comparison covers how these methodologies complement the Double Diamond's delivery phase

A Practical SaaS Example

Context: You're a PM at a project management SaaS. Monthly active users are growing, but 7-day retention has dropped from 68% to 54% over two quarters. Leadership wants to "fix retention."

Diamond 1: Find the Right Problem

Discover (2 weeks):

• Analyze cohort data: retention drops primarily in the "team admin" role, not individual contributors
• Run 12 user interviews with churned team admins and 8 with retained ones
• Review 200 cancellation survey responses
• Map the admin journey from signup through week 4

Define (1 week):

• Insight cluster: team admins spend 3+ hours per week on setup and configuration tasks that individual contributors never see
• Problem statement: "Team admins at companies with 10-50 users lose confidence in the product during weeks 2-3 because configuring permissions, integrations, and workflows for their team requires expertise they don't have and support resources that are too slow to help."
• Validated with 3 stakeholder interviews. Sales team confirms: "We hear this exact complaint during renewal calls."

Diamond 2: Find the Right Solution

Develop (2 weeks):

• Concept A: guided setup wizard that walks admins through configuration step by step
• Concept B: "admin copilot" that auto-suggests configurations based on team size and industry
• Concept C: dedicated human onboarding specialist for teams with 10+ users (service, not software)
• Concept tested with 6 admins. Concept B generated the strongest positive reactions; Concept C was valued but seen as unsustainable

Deliver (6 weeks):

• Built Concept B as an MVP: auto-suggested permissions templates and integration configurations based on a 5-question onboarding survey
• Beta tested with 15 new teams
• Measured: admin setup time dropped from 3.2 hours to 45 minutes. 7-day retention for the beta cohort was 71%.
• Rolled out to all new teams

The Double Diamond made the team resist the initial instinct ("add more help docs") and instead discover the real problem (admin burden, not information gaps) before designing the right solution.

When to Use the Double Diamond

• Ambiguous, high-impact problems. When the problem is not well understood and the stakes are high enough to justify a structured approach.
• Cross-functional initiatives. The framework creates natural handoff points between research, design, engineering, and product.
• New product areas. When entering a new market or building a new product line where you lack existing data and domain knowledge.
• Redefining underperforming areas. When a feature or product isn't working and the team doesn't agree on why.

When Not to Use It

• Well-defined problems with known solutions. If the problem is clear and the solution is obvious, the Double Diamond adds unnecessary process. Just build it.
• Quick fixes and maintenance. Bug fixes, performance improvements, and small iterations don't need two diamonds.
• Time-critical decisions. If you need to ship something in a week, you can't spend two weeks in Discover. Scale the framework to the time available, or skip it entirely and rely on experienced judgment.

Common Mistakes

Collapsing both diamonds into one. Teams that jump from a few interviews directly to wireframes are doing one diamond, not two. The gap between "I talked to users" and "I have a clear problem statement" is where the real insight work happens.

Spending too long in Discover. Research can become a form of procrastination. Set a timebox. If you haven't learned something meaningfully new in the last 5 interviews, you probably have enough data to move to Define.

Stakeholder pressure to skip Diamond 1. Executives often arrive with a solution in mind. "Build feature X." The PM's job is to validate whether X solves a real problem before committing engineering resources. Frame it as risk reduction, not bureaucracy: "Let's spend a week confirming this is the right approach before investing 3 months of engineering."

No explicit transition between phases. Each phase should end with a clear artifact and a team decision to proceed. Discover ends with a research synthesis. Define ends with an agreed problem statement. Without these checkpoints, phases blur together and the framework loses its value.

Limitations

The Double Diamond assumes you have time and resources for structured discovery and iteration. Early-stage startups operating under extreme time pressure may need to compress or skip phases. The framework works best when there's enough organizational patience to invest in understanding problems before solving them.

The model is also linear in its visual representation, which can mislead teams into thinking the process is strictly sequential. In practice, you'll often loop back. A prototype test in Deliver might reveal that the problem was defined too narrowly, sending you back to Define. Treat the phases as a guide, not a rail.

Finally, the Double Diamond doesn't prescribe specific methods for any phase. That's both a strength (flexibility) and a weakness (teams need to bring their own toolkit of research, ideation, and testing methods). Pair it with specific techniques from frameworks like Design Thinking and JTBD to fill in the how.

Related Comparisons

• Double Diamond vs Design Sprint