A guide to using the “Double Diamond” framework to score product home runs

The double diamond is a popular framework for conducting product discovery, and the one we use here at Productboard. Some roll their eyes at it, and some swear by it. But one thing is true: if you’ve been in the product world long enough, you’ve launched a feature at some point that — let’s face it — fell a bit flat. And usually not choosing the right problem and solution is to blame.

The double diamond framework encourages product teams to approach problems and solutions by diverging (starting broad to enable creative collaboration) and then converging (narrowing down to one or two key areas of focus).  It also provides a structure for understanding and defining user problems before jumping straight into a solution.

But does running all of your product development processes through the double diamond always lead to product home runs? Not necessarily, says Productboard’s Group Product Manager Sophie Lalonde. 

One of the major reasons that the double diamond framework ends up backfiring is that product teams get the pacing wrong, Lalonde says. Essentially, your product team must move slow enough to effectively accomplish the goals of each step and quickly enough that they can out-innovate their competition. Don’t go through the process just for the sake of it.

Here’s how to think about each of the steps and how to know when it’s time to speed up or slow down, according to Lalonde. 

Step 1. Diverging on the problem

When you’re in the “diverging” stage in the first diamond, you don’t know exactly what problem you’ll be asking your team to solve — and you’re not supposed to! Instead, this is where you should be talking to your core persona and having open-ended conversations without any preconceived notions, without offering specific suggestions, and definitely without a script.

Use this discovery phase to solicit and document their unfiltered input about the broad rumblings you may have been hearing from customer-facing teams. Be comfortable with ambiguity. Listen to your customers’ voices to get your finger on the pulse of the market. As you brainstorm, you’ll be able to see which problems or sub-problems start to bubble up for the personas you want to help.

“If somebody asks me what the problem is at this stage, I’ll tell them that I’m confident that I am not sure yet,” Lalonde says.  

The only way to expedite this knowledge is by running continuous discovery rather than waiting to look into specific problems in the double diamond. Either way, whether continuous discovery has been run or not, there will be a point where you have enough information on the problem to move on to the next step. As PMs, we are curious by nature, and our natural inclination is to keep learning to perfect our craft, but the extra time can not only put your business at a disadvantage but leave customers waiting longer for a solution that could really help them.

Signs that you’re ready to move on

• You’re boiling the ocean. This usually means that you have been researching for so long that you might be going in circles. The problems are likely there within the discovery notes. Take a personal day off of work or the weekend, and look back at your discovery with a fresh set of eyes.  Or even bring another PM or your team to look at your work to see which themes they grasped.
  
• The problem has been known for years. Perhaps the easiest to diagnose, this just means that whoever has been at the company longer than you has not adequately transferred the context to you.  Set up a casual 1-on-1 and ask them to tell you everything that they know about the problem at hand — it will not be time wasted for either party. 
  
  See if there are any recordings of customer calls that mention the problem.  Note that while talking to execs or customer-facing teams can be better at scale than talking to 10 customers, for the most important bets for the company, you really should talk directly to customers. 

Step 2. Converging on the problem

At some point, you’re starting to get a good sense of how to define the problem. You’ll be able to understand major pain points, which sub-problems you need to address first, and be able to explain the problems and advocate for them to executives.

“Once I converge on the problem, I should be able to pause and prioritize it compared to problems defined in other double diamond discoveries,” Lalonde said. She considers the discoveries from not only across her team, but also all of the product teams at her company.

If you find yourself not able to articulate the "why "behind the problem you may have moved through Step 1 too fast.

Comments that may tell you that you moved too fast

• "Well, what did you de-scope?" This tells you that you haven't provided enough options and the rationale for why the particular problem or sub-problem is one that your team should go after. If you’re not choosing between multiple options when it’s time to converge, you probably moved too fast. 
• "We need an answer for quarterly planning." You’ve let your business rituals set your discovery schedule. If you are close to understanding the problem or running continuous discovery, strategy planning schedules are a good forcing function. However, strategy planning schedules can make product managers feel forced into defining the problem before they fully understand it. This is the time to “manage up.” You’re the person closest to the customer, not the executive — let them know if the business and customer outcomes will be better if you have time for problem discovery. 

Comments that tell you you’re ready to move on

• "We heard the same thing from the last two interviews." If you keep hearing common themes and repetitive issues in discussions with customers from your core persona, it’s time to converge on the problem and move forward.
• "All the problems sound equally important." This can happen quite a bit when you are tackling a large problem.  Perhaps you didn't scope your discovery down enough. In that case, you should start prioritizing based on your company’s priorities. Converge on the problem that best supports your business strategy while also considering feasibility, effort, payoffs, learnings, and sequencing. 

Step 3: Diverging on a Solution 

After you know what specific problem you’re trying to solve and you’ve prioritized that problem over others, it's time to explore the solution. Back to the blue ocean and time to get started on your second diamond! This is a particularly fun time to get creative with your team — it’s where you can jot down all of your back-of-the-envelope ideas and explore as many possibilities as you can think of without limitations.

“The world is your oyster,” Lalonde says. 

While your team would often be happy to spend endless amounts of time brainstorming, here’s how you know it’s time to move forward.   

Comments that may tell you that you moved too fast

• “Where are the other options?” You may have gone with the most obvious solution without spending time thinking if there were other interesting ways to solve the problem.  This usually happens when just one person is trying to think of a solution, so open up the ideating process to more stakeholders and listen to what they think rather than pushing your solution.
• “But what could this look like in the future?”  In this instance, you were likely thinking in a constrained way about how your product works currently.  You may have limited yourself to specific design patterns or workflows that could be re-imagined.  Go back to the drawing board and think bigger.

Comments that may tell you that you’re ready to move on

• “Seems like most of us agree this is the best way forward.” Those closest to the project start to agree on the right option. Sometimes we wait for everyone to agree, but that really isn’t necessary to go forward. Assign a decision-making framework that considers customer value, business impact, and feasibility, then let whoever is in charge make the call.   
• “I see how this solves the customer problem.” Your design ideas tackle the problem in ways that clearly address the specific customer feedback you’ve gotten. You’ll start to have an idea of what a potential prototype could look like and can express at a high level how it meets your customer objectives

Step 4. Converge on a solution and iterate as necessary

After you’re done diverging, it’s time for the part that will bring your idea to reality — narrowing the possibilities you came up with down to just one and outlining it in quite a bit of detail. This is where you’ll make a prototype and product specs to work collaboratively with design and engineering. But just because you launch a new feature doesn’t mean you’re necessarily done. 

That’s because you’re not always going to get it exactly right the first time. Sometimes you’ll need to move backwards before you can move forwards. 

But just how far back should you go when your solution isn’t the right one?

Signs that you need to move back to step 1

If your solution worked well during trials but isn’t actually being used, there are likely one of three root causes:

• The feature could just not be discoverable
• The market needs to be educated on the feature
• You solved the wrong problem — the most tragic of the causes

If you haven’t heard much feedback about the feature and your power users aren’t evangelizing the feature, this may be a sign you aren’t tackling the right problems. Reach out to your customers to gather feedback and validate this hypothesis, assess your own learnings, and start diverging on a different problem.

Signs that you need to move back to step 3

If your customers are angry, frustrated, or annoyed with your solution and let you know about it, it may actually be a good sign — it means they want you to solve their problem, and that they are eager for an improved or different solution! So while there’s no need to go back all the way to the beginning, it may mean you haven't gone through enough iterations and need to start diverging on other solutions again.  

Choose your own adventure 

If all that jumping back and forth makes you and your team feel like you’re in the middle of a “choose your own adventure” story, don’t fear. It’s normal to go through some of these stages multiple times. The double diamond is an iterative process, and as you gain more domain knowledge, the better you'll get at choosing the right solutions for the right problems.  

It's also common to be working on multiple double diamonds at a time. Lalonde notes that she’s currently working on at least four double diamonds that are all in different stages. Group PMs should expect to work on multiple processes at the same time, even if it requires context switching.

“The product leader should be in charge of making sure that people are doing the right double diamond processes, and the group PM should be in charge of the portfolio double diamond processes, including who on their team will run each one and how to know when to move to the next stage,” Lalonde explained. 

While a double diamond is a great way to make sure that you’re thinking critically at every stage, keep in mind that there are times when using a double diamond doesn’t make sense. In teams with a more hierarchical structure, for example, someone at the director level may instead favor settling on a specific problem — in other words, completing the first diamond — at their level, and then hand it down to the PM or product lead. As long as the context is shared, this can be a valid — though not the most empowered — approach. 

Double diamond works best for empowered teams where product leaders provide objectives and northstar metrics. Director-level or group PMs then work with IC PMs to lead a creative, collaborative, and iterative process, starting with an extensive discovery phase in order to better define the problem. The best results come when PMs have the freedom to explore and experiment.

And if it first you don’t succeed? Try, try again.