Double Diamond: A framework to help product managers with design thinking

As a product manager, you might already know how important Discovery is in feature development. The process that examines the usefulness and feasibility of features before starting to develop them.

You may be familiar with Dual-Track Scrum  – a convenient and effective way of doing this. But what if there was a way to elevate this process further?

A good product manager organizes the workflow efficiently and helps to deliver a quality product, sure. But a great product manager also aims to build a connection with the development team and inspire the members to deliver amazing products.

Think about it this way: you’re working with designers. What’s the best way to connect with them? There’s a saying “To catch a criminal, you have to think like a criminal.'' That's right – you start thinking like one. No, not like a criminal, but like a designer.

Does the term “Double Diamond” sound familiar? Chances are, it does. The Double Diamond model describes a framework that designers use. Originally intended for developing physical products, this model has recently started gaining popularity in software development, and for good reason.

Understanding how the Double Diamond fits into Dual-Track Scrum can help you work better with discovery sprints and understand the design process on a deeper level.

Double Diamond From A to Z

Dual-Track Scrum is about doing a “discovery sprint” before the “delivery sprint”, to make sure that a feature is agreed upon and detailed out before feature development starts. In the discovery sprint, the team looks at different ways to solve the problem.

Double Diamond takes things one step further. Before even starting to look at the solution, there is one cycle only looking at the problem. The Double Diamond process consists of two cycles of divergence and convergence, translated into the four phases: Discover, Define, Develop and Deliver.

Discover falls into the start of the project when the designer gathers insights on the general problem at hand and analyse it. The key here is to examine and analyse the environment of the problem. It’s important to understand not only the problem, but also how it came to be in the first place, it’s the source and the driver behind it.

Looking back at the big picture, you may even come up with a shortlist of interconnected problems. This will help to create better in-depth solutions in the later phases.

Define is the second phase, where the designer begins to prioritize the problems, to find those that are the most important and urgent. Here, you should determine how to measure success and what impact you’re trying to achieve.

In this stage you want to synthesise your research, find insights and build opportunity areas (potential areas of action). This is the stage where you select the exact problem to work on from the set of the previously shortlisted ones.

Develop is the phase where, after having a defined problem to solve, you should start ideating around solutions. It is a diverging phase, where a “yes, and…”  mentality works best, keeping the mind open to creative ideas and out-of-the-box thinking.

This is the trial and error period to improve and refine ideas. Then all these ideas go through evaluation, and filtered out, leaving you with the best solutions.

Delivery is the final phase, where a detailed solution is created. A solution is selected from the short-listed ones, as designers start to think about the best way to turn the initial research, wireframes, prototyping and tests into a full-fledged design. Technical feasibility is also taken into account in this phase. 

The result generated through the four phases of the Double Diamond then goes into a delivery sprint. All four phases of the Double Diamond technically happens in the discovery sprint within the Dual-Track Scrum framework. In the delivery sprint of the Dual-Track Scrum is about actually coding the feature. 

How Double Diamond Fits in Product Development

Working with Double Diamond means using discovery not only to think about how to solve the problem but also going deeper into understanding what problem to solve. Quite often development teams focus on what to deliver, instead of the impact it will have.

By pursuing only short term solutions you risk losing sight of the bigger picture. There’s a reason designers love thinking about problems holistically. And sometimes you as a product manager should too.

Take a step back to think about what problem to solve, and when to go for solving a particular problem. In the long run, it’s better to not only consider whether you’re “building the thing right” but also whether you’re “building the right thing”. This is what thinking like a designer can offer if used wisely.

Because even the most agile software development is costly, you don’t want to work on the wrong solutions. At the same time, going through this extra cycle of problem discovery will require more resources, and will steal more of your focus.

The tricky balancing act for a product manager thus becomes when to go for what approach. For some simple features, it is best to just go for the first obvious solution, and so not even a discovery sprint is needed.

For most features, it might make sense to look at a few different solutions, but what problem to solve probably seems quite clear. But for a few crucial features, thinking like a designer, and doing the full Double Diamond can have a huge impact.

Good designers have been trained in thinking “problem first”, and you will likely spend much time together with the designer in that first cycle of the Double Diamond. Therefore it is often good to have an ongoing dialogue with your designer to determine what approach to go for and when.

Borrowing a specific way of thinking is sometimes the key to seeing everything differently. This might help you find issues and come up with answers you never thought were there in the first place.

Regardless of what approach you are going for with a feature (directly to sprint, design sprint first, or full Double Diamond), writing down what problem you are solving is always good practice. A good way to ensure that happens is to use a template that explicitly brings up what problem to solve.

At Delibr, we have interviewed hundreds of product managers and dozens of designers, and have put together a feature refinement template based on the best practices we observed.