The double diamond. If you ship product, chances are this model is ingrained in your mind.
First, you find the right problem. Then, you solve the problem right. That’s all well and good — if you have the time to go through it all.
We’ve been experimenting with an approach that allows us to define a validated product with deep strategy and high-impact moments in as little as five weeks.
That’s significantly less time from start to MVP definition than would be possible with a double diamond approach.
As Head of End to End Product Design and Product Director, here at MetaLab, we've been collaborating to refine this process for our teams.
Here are our learnings so far.
Breaking down double diamond
When teams start new projects, they typically look for good frameworks to help guide them. For years, the double diamond has felt like a natural jumping-off point.
Typically, the process looks something like this:
- Discover: the research and product management teams lead the discovery phase, going deep to understand the user needs and business opportunities.
- Define: then, they move into product definition — asking out of all these things — what are the true problems we need to solve.
- Inflection: Once the problem space is defined and the vision and strategy are set, they define briefs to onboard designers.
- Develop: Designers absorb the brief to get into the headspace of the problem, and focus on exploring solutions.
- Deliver: The full team then hones in on the MVP and ships it.
In the “truest” model, research and product own the first diamond, while design and engineering wait until the strategy is set to jump in.
While people have been using this framework for years, we know that something happens when you wait to start solutioning so late in the game — you lose the potential for the magic.
We’re excited to be sharing an approach that we’ve been experimenting with that leaves room for magic, while still shipping a product efficiently and effectively.
What’s wrong with the double diamond?
At face value: nothing.
It’s a light risk approach that leads to useful and successful products.
Each team plays to its strengths and no time is wasted outside their discipline.
The core belief is that solutioners (eg: designers and engineers) must have a core list of problems to solve to make the most use of their time. These series of handoffs create a waterfall effect that is intended to mitigate risk and increase certainty.
The result: the product machine — product development that creates solutions.
It’s a process that works for many but falls short in three scenarios.
- If you’re looking for a competitive edge
- If you want to get to market quickly
- If your team works best with tight collaboration and minimal silos
So we’ve broken the double diamond, and we think that’s a good thing.
Tinkering with the double diamond
To understand why we started doing this, we have to look back in MetaLab history.
In the beginning, we were a small scrappy team trying things to see what would stick.
Designers weren’t waiting until the Discover phase of the diamond was complete, they were running the whole diamond.
Some would tell you this was a bad strategy but we struck gold — more than once. And each time we tried to add layers of process, and department isolation, we found we lost a bit of that.
What we discovered is that there’s real value in having designers involved from day 1 to capture those first bursts of creativity — unbiased, unconstrained.
When the problem isn’t fully defined yet, exploration naturally becomes extremely blue sky and sometimes super out there.
It’s what’s led to some of our most impactful work.
Our experimental approach
So our goal was to find a balance between creativity that comes from the truest of blue-sky thinking, while also delivering an impactful product with a solid strategy in an efficient and rapid manner.
Here’s what we’ve been experimenting with on select projects:
To ensure we start on the same footing, we show up as a core cross-discipline team to client kickoff sessions, then regroup post-kickoff to define our ridiculously early hypotheses based on our collective learnings.
Why do we think we are here? Where do we think we should go?
We have some hunches, but everything is far from certain.
#2 Teams split up into focus areas
We recognize that we can unlock the true superpowers of our team by letting them go deep into what they are great at.
Our research and product team teams use the hypotheses to begin research activities* to understand what should the product be based on user needs, business drivers, and the macro-landscape. They start defining a vision and strategy by identifying the true areas of opportunities and problems we must solve.
Note: it’s not a clean separation as we like our design teams to be present for live research sessions to grow empathy for the user.
At the same time, our design* team goes heads down into a broad concepting exercise known as Tarantinos. They immerse themselves in what they’ve learned and design an end-end product experience of what they think the product could be.
Note: when possible, our engineers love to get into this as well — creating proof of concepts and being part of the “art of the possible” conversations.
As the weeks progress, each team’s lips are sealed except for a few core individuals who are across the work. We do this to ensure the integrity of the thinking isn’t broken.
You might wonder — isn’t all the time apart potential waste? And yes, there is some waste but the way we think of it 90% is pure untapped opportunity. Consider the other 10% as an investment in creativity.
#3 Meet in the middle
After some time apart, our teams converge and present to each other. Our product managers and researchers show our initial product strategy and product objectives, and our designers present a product experience based on their understanding from kickoff.
This is where the magic happens.
Product managers can look at fully unconstrained design thinking and identify potential features and capabilities for the product that ladder up to each objective.
Designers can look at the strategy and have “ah-ha moments” on additional areas to explore or refine.
Through this approach, we’ve been able to come up with ideas for the product that we may never have if we started concepting with defined constraints and problem spaces. Features that we may never have deemed as aligning to the product suddenly were able to fit nicely into an objective and have a significant measurable impact on the product.
Those moments that come from the blue-sky thinking often can become differentiators for the product.
On the strategy side, the product vision or objectives may be refined and crystallized because of the way a designer interpreted the problem space.
#4 Shared definition of the foundational product
Then, our teams spend time together fleshing out a few details of the foundational product experience. This ensures that we have full alignment with our team and client on what the product might be. From there, we can rapidly pivot into identifying our MVP and delivering on it.
Compared to a traditional double-diamond approach, getting to this point after kickoff to the foundational product experience and MVP is extremely rapid. In one of our projects, we’ve been able to do this as quickly as 3 weeks.
The reason is that we aren’t spending time first getting alignment on the strategy, then briefing the team, then reviewing concepts, then defining the core product experience. We stack activities in a way that unlocks creativity and realization of what the product is.
With our strategy and potential solutions developed simultaneously, we’re able to rapidly prioritize an MVP with true differentiation and opportunity for our client.
Results that Matter
So far, our clients love this approach. They get to see results and differentiated ideas quickly.
As nice as a strategy presentation might be, there’s power in combining words with compelling design. It allows clients to visually see what they’re agreeing to when asked to make decisions about their strategy.
They’re able to get a sense of the end-end product experience that could come from the intersection of strategy and concepting work so far. This makes them more confident in what they are agreeing to when prioritizing an MVP
It motivates our teams as well.
Our designers feel like they are truly part of the “shaping and definition” process.
Researchers, engineers, and product managers can rapidly ground their work and realize the bold ideas of our design team.
It’s a win-win on all fronts.
Where we’ll continue to explore
Like any good cross-discipline product team, we’re always learning and never done. As this model is still a work in progress, you’ll need to consider the following as you put it into practice:
Experiment to find the right balance of technical exploration versus technical build in the process
Typically, technical discovery would be concurrent to the activities above, but some engineering teams (like ours) might like to be part of the unconstrained explorations on what the product could be. Building the product and getting to market is critical. Experiment to find the best time for engineers to get involved in both areas.
Work to remove bias from ridiculously early hypotheses
While ridiculously early hypotheses are intended to be initial stakes in the ground that should be challenged and tested, it’s important to recognize they might unintentionally introduce bias in research synthesis and exploration.
To mitigate this, you’ll need to actively train your team members on how to keep using the hypotheses as foundational inspiration, but to also continue to challenge and evolve them along the way.
Hedge against the tantalizing nature of Tarantinos
There is a danger to Tarantino work as clients can become enamored by this work. We’ve had some reference early design ideation further into our design sprints. For this reason, try to be super intentional with how you communicate and share this work.
Know the model may shift when the project warrants more certainty vs. more blue-sky thinking
There may be situations where you put more weight on strategy-oriented activities vs. generative thinking depending on you initial hypotheses or where your teams think you should focus. Use this model as a guide but know it can flex and shift based on the needs of your product.