Product discovery frameworks compared: Double Diamond, Lean UX and continuous discovery

There is no shortage of frameworks for figuring out what to build. The trouble is that each one covers a different slice of the work, and none of them is a complete recipe on its own.

For my MSc thesis I reviewed the main approaches and looked at where each helps and where it runs out. Here is a plain comparison.

Framework	Best for	Where it falls short
Double Diamond	A shared map of the whole process	Too abstract for day-to-day decisions
Lean UX	Fast, outcome-driven loops	Needs strong alignment to work
Agile discovery	Tight delivery feedback loops	Little room for upfront research
Continuous discovery	Staying close to customers weekly	Time-consuming and hard to sustain

First, what is product discovery?

Before comparing frameworks it helps to agree what they are frameworks for. Münch, Trieflinger and Heisler describe product discovery as six stages: alignment on strategy and success metrics, research into user problems, ideation, creation of prototypes, validation with users, and refinement. The outcome you want is a confirmed product backlog that can support a real roadmap.

Frameworks alone do not fix discovery. Herbig surveyed 75 product managers on what prevents effective discovery, and the top four blockers were not enough access to users and research, no clarity on priorities, confirmation bias and predetermined solutions from management, and no clear product strategy. Keep that in mind as you read: most of these are organisational problems, not process problems.

The Double Diamond

The Double Diamond was created by the UK Design Council in 2003 and 2004, led by Richard Eisermann, their Director of Design and Innovation at the time, and influenced by earlier diamond-shaped models from IDEO and Whirlpool. It has four phases across two diamonds: Discover, Define, Develop and Deliver. Each diamond shows a widening then a narrowing, which stands for exploring broadly, then focusing.

Good for: giving a whole team a shared picture of the process, and reminding everyone to explore before deciding.

Where it falls short: Dan Ramsden lists eight limitations. It is too abstract to answer specific design questions. It fails to represent the complexity, unpredictability and emergent nature of real design work. It says nothing about creativity or how to handle messy problems, and it leaves out empathy, human-centred design and ethics. It also misses reflection, prototyping and iterative testing, and it does not tell you when to visualise an idea or make a decision. It is a map, not a set of instructions.

Lean UX

Lean UX, set out by Jeff Gothelf, comes from Lean Startup and Agile thinking. It trades heavy documentation for teamwork and fast learning, and runs on a loop of Think, Make, Check. You make your best guess, build the smallest thing that tests it, then learn from real feedback.

Good for: moving quickly, cutting wasted effort, and keeping the whole team focused on outcomes rather than deliverables.

Where it falls short: Aarlien and Colomo-Palacios group the problems into two kinds. The first is communication: keeping alignment across a project, losing context when work is handed over, misunderstandings about requirements, and the myth that Lean UX means no documentation at all. The second is adoption: staffing every role when the team is small, training developers to deal with customers, spreading decision-making across a large client organisation, and adapting structures and mindsets in organisations already built around agile.

Product discovery in Agile

Agile keeps teams shipping small, valuable increments quickly. Discovery inside Agile means feeding those sprints with evidence about what is worth building. There is real appetite for this: when Agile professionals were asked whether integrating agile methods with usability and user-centred design added value, 43.84% agreed and a further 29.35% strongly agreed.

Good for: fast delivery and tight feedback loops.

Where it falls short: six problems come up repeatedly. Time constraints make thorough research hard in a fast sprint cycle. Agile does not support much upfront design, so there is no clear best practice for building the backlog. It is developer-centric, which can push UX designers to the margins. Competing stakeholder demands cause misalignment. Scaling across multiple teams and complex projects is difficult without standard procedures. And UX is often not seen as a core business strategy at all, which affects how much it is prioritised.

Continuous discovery

Continuous discovery, made popular by Teresa Torres, is the habit of talking to customers regularly so their feedback shapes the product week to week. It leans on tools like the opportunity solution tree to connect research to outcomes.

Good for: keeping teams close to customers all the time, and tying every research activity to a clear outcome.

Where it falls short: Megan Scheminske, a Senior UX Researcher at Teachable, names three limits. It is time-consuming and brings logistical challenges that get overwhelming without proper support or tools. It is prone to bias, because people reinforce beliefs they already hold or over-weight whatever they heard most recently. And the reliability of the results can suffer because the groups involved are small.

Standardised or customised?

There is a second question underneath all of this: do you take a framework as it comes, or adapt it?

Standardised processes are general and flexible. They suit a wide range of projects and give more predictable results, and the Design Council’s Double Diamond is the obvious example. Customised processes are adaptations, modified to fit the needs of a specific project or organisation.

Plenty of teams customise. Dan Nessler reworked the Double Diamond into his own framework. Sohaj Singh Brar applied it to redesigning circular ticket booking on the Indian Railway. Zendesk went further and built a Triple Diamond, adding a third diamond to their process.

That is the honest answer to which framework to use. In my interviews, teams treated frameworks as guidelines rather than strict rules, and tailored the process to the goals of each study.

So which should you use?

They are not really rivals. Most teams borrow from several:

Use the Double Diamond as a shared map of the overall process.
Use Lean UX to keep the loop tight and outcome-driven.
Use continuous discovery to stay connected to customers between the big moments.

The most useful lesson from the research is to treat frameworks as guidelines, not strict rules, and to adapt them to your goals and constraints rather than following any one of them to the letter.

Want the practical version? Read the continuous product discovery process or start with what is continuous product discovery.