Double Diamond design framework for physical products

The Double Diamond design framework is a powerful tool for structuring innovation, but the standard version often falls short for physical products. Its emphasis is on digital services and user desires. Anyone launching a tangible product quickly discovers that desirability alone is no guarantee of success: without early validation of the technology, cost price and manufacturability, a good idea remains only a promise.

This article explains how to adapt the model for hardware and plastic products so you do not only discover during the development phase that your foundation is unstable.

What does the Double Diamond model look like in practice?

The Double Diamond design framework organises innovation into four phases that alternately diverge and converge: Discover, Define, Develop and Deliver. In the first diamond you broadly explore the problem space. You then define clearly what you will solve, after which the second diamond repeats the same pattern to design and realise the solution.

This method forces teams not to jump straight to solutions, but first to build certainty about the problem definition.

This works excellently for digital applications because iterations are cheap and feedback cycles short. For physical product development, each phase requires extra discipline around technical and financial constraints. The standard explanation of the Double Diamond design framework usually focuses on services or software, where assumptions can be tested quickly with prototypes that cost little.

Makers of physical goods do not have that luxury.

You therefore must account from day one for constraints that in a digital process only become relevant much later: materials science, assembly sequence, certification paths. Without this adjustment you may get stuck in engineering after a perfect Discover phase.

Why validate the problem first and only then the solution?

Strictly separating the problem and solution spaces prevents organisations from investing in products for which there is no real market need, and that can be disastrous in physical innovation because of high development costs and long lead times. A validated customer insight is fundamentally different from an assumption: it rests on evidence from practice, not on internal beliefs or presumed stakeholder wishes.

Many product teams unknowingly still start from a solution.

They have a technical concept or an aesthetic example and then look for a problem to match. That yields products that may be ingenious but that nobody truly needs. Within the Define phase of the Double Diamond design framework, validation means removing uncertainties with data and conversations, not with brainstorming sessions or management gut feelings.

Only when the problem is clearly defined and confirmed by the target group may you enter the solution space.

This discipline sometimes feels like a delay, but it is the only way to avoid much more costly failures later. For physical products you cannot fix an error in the problem definition with an update or patch; you must return to the drawing board and remake tooling.

Why the standard model falls short for physical products

Desirability is necessary but never sufficient for hardware: a desired product that cannot be manufactured or afforded does not exist commercially. The standard Double Diamond design framework often treats technical feasibility, cost estimation, certification requirements and production capacity as later concerns, whereas in physical innovation they weigh just as heavily as user desires.

A brilliant design fails if the mould cannot be made.

If you only include these hard constraints in the Develop phase, you discover problems at a point where changes have become extremely expensive. You cannot simply choose a different material or adjust a tolerance without consequences for the entire chain, from supplier to final assembly.

That is why technical and financial requirements must be equal partners in the definition phase.

PEZY adds technical, financial and production expertise in the Define phase of the innovation process to bridge the gap between idea and manufacturability. This way you know not only what the customer wants, but also what it may cost, which certifications are required and whether the critical function is technically achievable within the given constraints.

Without this integration your first diamond remains an exercise in wishful thinking.

Integrating technical and financial constraints into Define

Before you start development it must be crystal clear whether the critical function can work technically, what the product may cost at most and what investment in tooling and certification is realistic within the business case. These questions may seem premature during problem exploration, but they form the filter that separates a nice idea from a viable product.

A good idea is not yet a product decision.

For physical products it must first be clear whether the critical function can work technically and what the product may cost before you invest further in detailing. In the Define phase you must therefore already validate technical feasibility through targeted tests, not through theoretical studies or supplier promises.

Manufacturability is not an abstract concept but an arithmetical reality.

By applying Design for Manufacturing principles early on, you avoid defining a design that meets the user desire but cannot be produced at the required cost. Certification requirements also belong here: a CE mark or medical approval often dictates the product architecture and choice of materials.

If you do not include this in your definition, you will inevitably build a product that later fails certification.

Critical functions and cost price as hard requirements

Cost price is not an outcome of the design process but a precondition that you include in the problem definition, just like the technical performance the product must minimally deliver. If you only calculate costs after detailing, you often find yourself disappointed and must compromise on functionality or quality promised in the Discover phase.

Set the cost target therefore as part of your Product Decision Pack.

Secure certification and production capacity early

Certification processes take months and require specific test setups. Therefore you must know the requirements before shaping the product, not only when the prototype is ready for validation. The same applies to production capacity: if you do not know series volumes or cycle times, you cannot make a reliable business case.

This knowledge belongs in the first diamond.

From the first diamond to a complete product decision

The transition from abstract insights to concrete engineering requires a document that acts as a bridge between design thinking and technical realisation so that later phases do not stall on unexpected blockages. The Product Decision Pack is the concrete outcome of PEZY Define and contains the validations needed to responsibly start development, including answers to questions about technology, costs and regulation.

This package is more than a specification list.

It is the evidence that your problem definition is robust enough to justify the investment in the Develop phase. When drafting the product specification, you translate user requirements into technical parameters that have been tested against manufacturability and cost, so engineers do not have to guess the intent behind the requirements.

Without this foundation every start of development is a gamble.

Many organisations skip this step because they believe their Discover results are sufficient, but then they miss the crucial layer of technical and financial validation. A PEZY Define programme delivers precisely this missing link so you can enter the second diamond with confidence.

The Product Decision Pack as foundation

This document consolidates all validations, risk analyses and constraints needed to start the Develop phase without the team having to return to the drawing board later due to missed requirements. It forces the team to eliminate vagueness and make explicit choices about what is and is not in scope.

Checklist: readiness for the Develop phase

You are only ready for development if the critical function has been demonstrated, the cost price is substantiated, the certification route is known and the production partner is involved in the specifications. If any of these elements is missing, your product decision is premature and you take unnecessary financial risk.

Use these criteria as a gatekeeper.

The role of prototyping and TRL in the Double Diamond process

Theory and practice come together in targeted validation moments specifically aimed at removing technical uncertainties before you commit full development capacity. Where digital teams use clickable prototypes, for physical products you must provide tangible proof that the chosen technology works under real conditions, not only in a lab setup.

This demands a different approach to prototyping.

A Proof of Concept in this context is not a rough model to visualise an idea, but a focused experiment that answers the most risky technical question from your definition. By linking this to the Technology Readiness Level scale, you make technological maturity measurable and comparable, which is essential for investment decisions.

This prevents developing based on hope.

Proof of Concept as a validation moment

A PoC tests only the critical function or the greatest technical risk and has no aesthetic or ergonomic value, because the goal is purely risk reduction, not presentation. If the PoC fails, you have failed in the Define phase, not in development, and that is precisely the intention of the Double Diamond design framework for physical products.

Failure here is a win.

Technology Readiness Level as a metric

The TRL scale provides an objective framework to judge whether a technology is mature enough for integration into a product, turning ‘feasibility’ discussions into standardised scores. This helps R&D leads and product managers report progress and link decision moments to actual maturity rather than planning optimism.

When is your product really ready for the Develop phase?

Your product is only ready for the Develop phase when, in addition to a validated customer problem, you also have technical feasibility evidence, a substantiated cost price calculation and a clear route to certification and serial production. The Double Diamond design framework does not deliver this certainty automatically; you must actively supplement the model with engineering and business validations to avoid disappointments in later phases.

If this certainty is missing, continuing is irresponsible.

Use the checklist mentioned earlier as a hard gate, and be prepared to return to the Define phase if there are gaps in your substantiation. For organisations that seek this certainty but do not have the broad expertise in-house, a specialised programme is often the fastest route to a valid product decision.

Manufacturable innovation starts with an honest definition.

Frequently asked questions about Double Diamond for physical products

How does the Double Diamond model for physical products differ from the standard design thinking approach?

For physical products you weigh technical feasibility, cost and manufacturability in the first diamond as equal factors alongside user desires. Standard design thinking often focuses primarily on desirability and leaves technical validation until the development phase, which for hardware leads to costly late changes.

Which criteria must be validated before a physical product enters the Develop phase?

The critical function must be technically demonstrated via a Proof of Concept, the maximum cost price must be substantiated and the certification route must be known. It must also be clear whether the intended production capacity and investment are realistic within the business case.

What is the difference between a validated customer insight and an assumption in the Define phase?

A validated insight is based on evidence from practice, such as user tests or market research, whereas an assumption rests on internal beliefs or unchecked hypotheses. For physical products this distinction is crucial because errors in the problem definition lead to expensive rebuilding of tooling and moulds.

How do you integrate manufacturability and certification requirements into the first diamond?

You apply Design for Manufacturing principles during the problem definition and involve production experts when setting the requirements. Certification requirements are included as hard constraints in your Product Decision Pack so they steer architectural choices instead of being an afterthought.

What does a Product Decision Pack contain and why is it essential?

It contains all the technical, financial and regulatory validations needed to responsibly begin development, including cost calculations and feasibility evidence. This document bridges design thinking and engineering and prevents teams from getting stuck in the Develop phase on unforeseen blockages.