Does the Double Diamond need fixing?
TL;DR: No—but let’s talk about how to make it work in practice.
First, a quick overview of the Double Diamond:
1️⃣ Discover: Understand what the problem is, usually by talking to or observing customers.
2️⃣ Define: Use discovery insights to reframe and define a clear problem statement.
3️⃣ Develop: Co-create and explore different solutions with relevant people.
4️⃣ Deliver: Test solutions at a smaller scale, discard what doesn’t work, and iterate on what does.
Makes a lot of sense, doesn’t it?
Yet, not everyone thinks so. Some experts have pushed back on the model with arguments like:
❌ It’s too linear and lacks feedback loops.
❌ It doesn’t explicitly include critique or iterations for improvement.
❌ It oversimplifies the messy, iterative reality of product discovery and design.
I don’t believe these arguments hold up. However, it’s true that many teams struggle to apply the Double Diamond, falling into the very pitfalls critics highlight.
Here’s the reality:
1️⃣ Teams and organizations need structure.
Linear, repeatable processes provide clarity. They’re easy to understand, learn, and apply consistently across teams.
Wait what? I just said I don’t agree with the critique that the Double Diamond is too linear. Keep reading.
2️⃣ Creativity thrives within boundaries.
A system for creativity that is reliable and repeatable gives teams a shared language and method to collaborate effectively without stifling ideas. Not everyone can “play Steve Jobs” and hope for magic to happen.
But the Double Diamond can feel rigid if you don’t layer in practical methods that account for iteration, critique, and collaboration.
Making the Double Diamond work in practice:
➡️ Problem Framing: To explore the problem space and define clear problem statements grounded in customer and business needs.
➡️ Design Sprints: To explore the solution space, run experiments, and establish confidence.
Yes, these methods are linear. But they inherently incorporate iteration and flexibility.
Problem statements defined in Problem Framing remain hypotheses until tested, which happens quickly in a Design Sprint. Afterward, you either iterate on the solution or revisit your problem statement or target audience—enabling fast, focused cycles of improvement.
Why these methods work:
✅ They’re prescriptive, making them easy to learn and scale across teams.
✅ They’re fast—no waiting six months to figure out if a solution will work.
✅ They produce tangible outcomes: clear problem statements or customer-tested prototypes.
✅ They’re collaborative, involving the right people at the right time: stakeholders for problem definition and experts for solution exploration.
✅ They force customer-centricity: problems are defined based on insights, and solutions are validated with customers.
It’s the best of both worlds: navigating the messy, iterative process of product development using common-sense, step-by-step methods that don’t rely on luck or genius.
No alternative text description for this image
