‍Reading time: 7–8 min 

The most expensive mistake in venture building is solving the wrong problem well. The Double Diamond framework exists to prevent exactly that — by forcing you to stay in the problem space long enough to actually understand it before you collapse into solutions.

The Framework and Where It Came From

The Double Diamond is a design process framework developed by the British Design Council in 2005, through research across major companies including LEGO, Sony, Microsoft, and Starbucks. It has become one of the most widely used models in design thinking, product development, and innovation — not because it is sophisticated, but because it is honest about something uncomfortable: the problem you start with is almost never the real problem.

The framework describes two diverge-then-converge cycles — hence two diamonds:

‍

First Diamond: Find the Right Problem

Discover → Define

Broad exploration, open questions, research

Resist the urge to jump to solutions

Output: A clear, validated problem statement

Tools: interviews, ethnography, JTBD, observation

‍

Second Diamond: Find the Right Solution

Develop → Deliver

Generate multiple solution directions

Test and refine before committing

Output: A tested, iterable solution

Tools: prototyping, usability testing, pilots

‍

The sequence is critical. You cannot effectively design the second diamond until you have done the work of the first. Most teams collapse both diamonds into one — they arrive with a solution in mind and define the problem to match it. The Double Diamond is a structural reminder that these are two different activities, and that collapsing them produces products nobody wants.

The First Diamond — Discover

The Discover phase is the most commonly skipped stage in startup building. It feels like procrastination. You have an idea. You want to build it. Research feels like delay.

It is not delay. It is the work that determines whether everything that comes after is pointing in the right direction.

In the Discover phase, you are opening up your understanding of the problem space. You are not looking for your answer — you are trying to understand the landscape well enough to know which problem is worth solving. This means:

• Talking to people who experience the problem, without leading them toward any particular solution.
• Observing behavior in the environment where the problem occurs, not just in interviews.
• Mapping the full ecosystem — who is involved, what they each want, where friction occurs, and why.
• Actively seeking perspectives that contradict your initial assumptions.

The Discover phase should make you uncomfortable. If all your research is confirming what you already believed, you are not discovering — you are shopping for evidence.

The First Diamond — Define

After the Discover phase, you converge into a Define phase. You are synthesising what you found and articulating a specific problem statement that is worth solving.

A good problem statement has three qualities:

• It is specific enough to be falsifiable — you could test whether a solution actually solves it.
• It is grounded in evidence — it comes from your research, not your intuition.
• It is worth solving — the people who experience it care about it enough to change their behavior or pay for a solution.

What you are explicitly not doing in the Define phase is specifying your solution. The problem statement should be solution-agnostic. 'Small restaurant owners in Bangkok spend 3–5 hours per week manually managing ingredient orders across 8–12 different suppliers, with no visibility into price changes or inventory levels' is a problem statement. 'We need to build a procurement app' is a solution statement dressed as a problem.

The difference matters enormously. A clear problem statement allows you to evaluate multiple potential solutions. A solution statement locks you into one approach before you know whether it is the right one.

Define the problem before you define the solution. A sharp problem statement is worth more than a polished prototype.

The Second Diamond — Develop

The Develop phase is where you allow yourself to generate solutions — but the key word is generate, plural. The Develop phase should produce multiple candidate approaches, not one fixed design.

Techniques common in this phase include:

• Brainstorming and ideation sprints — generating quantity before quality.
• How Might We (HMW) questions — reframing the problem statement into prompts for solution thinking. 'How might we reduce the time restaurant owners spend on supplier management?' opens more doors than 'build an app.'
• Concept sketches and low-fidelity prototypes — making ideas visible and testable before they are expensive.
• Analogous inspiration — looking at how similar problems have been solved in adjacent industries or markets. A supply chain visibility problem for restaurants might find useful analogies in logistics, hospital procurement, or hotel operations.

The Google Ventures Design Sprint — made popular by Jake Knapp's book Sprint — is a structured five-day process for running through the second diamond in an accelerated timeframe. It has been used by hundreds of companies to rapidly prototype and test ideas before committing significant resources. The process compresses diverge-and-converge into one intensive week with specific daily activities.

The Second Diamond — Deliver

The Deliver phase is where you converge from multiple solution directions into a tested, refined approach. The word tested is critical: the Deliver phase does not mean finished, it means validated to a sufficient standard to justify continued investment.

In early-stage venture building, Deliver means:

• You have a working prototype or minimum viable product that real customers have used.
• You have specific evidence — not assumptions — that the solution resolves the problem defined in Diamond One.
• You know the main objections or limitations and have a plan for addressing them.

Deliver does not mean perfect. It means sufficiently tested to make the next decision — whether to continue building, pivot, or stop — with evidence rather than hope.

Where Design Thinking Sits in Startup Practice

Design Thinking is the broader philosophy in which the Double Diamond lives. It is a human-centered approach to problem solving that prioritises deep empathy with users, rapid experimentation, and iteration over premature optimisation.

Its five stages — Empathize, Define, Ideate, Prototype, Test — map closely to the Double Diamond, with an explicit emphasis on empathy as the foundation of everything. You cannot design for someone you do not understand. The empathy work is what makes the research in Block C non-negotiable, not optional.

How Design Thinking Differs From Traditional Analysis

Traditional analytical approaches move linearly: define the problem, generate solutions, evaluate options, select the best one. Design thinking assumes the problem definition itself is uncertain and treats the entire process as iterative. You define, test, learn, redefine, test again.

This is why early-stage research should inform your problem statement rather than simply validate it. If your customer interviews are changing your understanding of the problem, that is the process working correctly. If your customer interviews are confirming exactly what you expected, either you started with genuinely strong insight, or you are not listening carefully enough.

The Practical Pattern in GVP

The Block C work you are doing right now is the first diamond. You are in Discover and Define. The interviews, the JTBD exercise, the competitive map — these are all discovery tools. The problem brief you will write is your Define output.

You will not do the second diamond fully until later blocks, when you have validated the problem well enough to start generating and testing solutions. This is not a curriculum design choice — it is the correct order of operations. Founders who jump to the second diamond too early build products that are well-designed solutions to the wrong problem.

The GVP Rhythm and the Double Diamond

• Block C (Discover / Define): Research, interviews, JTBD, problem brief — stay in the problem space.
• Block D (Develop): BMC, Lean Canvas, business model thinking — now you can start designing.
• Block E (Develop / Deliver): MVP, prototype, UVP — test your solution concept with real people.
• Block F–G (Deliver): Growth model, pitch, final presentation — converge on a validated direction.

The Common Mistake: Skipping to the Solution

I have seen it in every cohort: a team arrives to Block C with their product already half-designed in their heads. They go through the interviews looking for confirmation. They write a problem statement that is really a feature list. They skip the real work of discovery because they are impatient to build.

The teams that do this consistently produce pitches in Block G that sound confident but fall apart under one or two honest questions. The problem is shallow. The customer insight is thin. The solution cannot be distinguished from a dozen similar products.

The teams that do the double diamond properly — staying genuinely uncomfortable in the Discover phase, writing a problem statement that is specific and evidence-based — produce pitches that are different. They know their customer more precisely. Their solution is more targeted. They can answer hard questions because they have already asked harder ones of themselves.

Discovery is not delay. It is the investment that makes everything after it faster.

‍

✎  A Note for GVP Students

• Your Block C work is the first diamond. Do not rush into solutions yet.
• When you write your problem brief, check: is this actually a problem statement, or is it a solution statement with a problem attached? If you can describe the problem without mentioning your solution, you are in the right territory.
• The Double Diamond tells you what order to work in. Discover first. Define before you develop. Develop before you commit to delivery. Each stage informs the next.
• If your customer interviews are changing your understanding of the problem, that is the process working. Resist the urge to lock down your problem statement too early — the real insight often appears in the fourth or fifth interview, not the first.
• In the second diamond (Blocks D–E), your job is to generate multiple possible solutions before committing to one. Build the habit of asking 'what else could solve this?' before you default to the first idea.

‍