If you’re involved in design (and even if you’re not) you probably know about the Double Diamond process. But, is that the end of the story? This article expands the perspective and completes the model by taking you from ambition to market in a repeatable entrepreneurial cycle.

Divergence and convergence

Back in 1996, Hungarian-American linguist Béla H. Bánáthy made obvious something that was hiding in plain sight, and as a linguist he expressed it in beautifully simple terms. He described the thinking process in terms of two key phases, the first being divergence and the second convergence. During divergence we consider a situation and create a range of choices arising from that situation. Convergence then follows and we narrow those choices down to a single decision point.

For example, you’ve bought a new painting for your home, and now it needs to be displayed. Maybe you already have a space for it, but more likely, you now examine your rooms and build up in your mind a list of places where it would look great. This is divergence.

Next, you imagine the painting in each of these places. Perhaps you get a friend or partner to hold it up so that you can get a feel for how it’ll look. Slowly you narrow down the field of options until you’re left with just one – the perfect spot. This is convergence.

Divergence involves expanding your understanding and increasing your options without judgement. To judge and reject too early is to do so without adequate knowledge. Far too many great ideas end up on the cutting room floor (or voted down in “brainstorming” sessions) because they’re unfamiliar or poorly understood. This is why divergence has to be allowed to happen before any attempt is made at convergence.

Convergence is reduction of options through elimination, and most importantly elimination through experimentation rather than through opinion or “gut feel”. You’d be amazed at just how many “obvious” things turn out to be wrong when put to the test in the real world. For example, we all know that warm water freezes faster than cold water, don’t we. That’s so obvious we really don’t need to waste time testing it? It’s a safe assumption, right? If you agree, I recommend you read up on the Mpemba Effect – a timely reminder that there is no such thing as a safe assumption.

A tale of two diamonds

Divergence followed by convergence can be pictured as a diamond, starting from a single decision point, and expanding out like a tree, growing freely. Once the tree is fully grown its branches are then pruned back until only the strongest remains. This is your new decision point from which you grow your next tree.

You can apply this pattern to most situations that require thought and an outcome. Choosing a holiday; picking a route to work; designing a new mode of transport; even painting that picture. In just two words, Béla brought to life the idea that problem solving was not a linear process that created certainty out of chaos, but instead a journey that created chaos in order to get to the next point of certainty.

This is a concept that appeals to the creative mindset, and so it comes as no surprise that the British Design Council took this concept and popularised it in the form of the Double Diamond design process model.

As the name suggests, the model sees the design process as two consecutive divergence-convergence activities, the first consisting of discover and define, and the second of develop and deliver. The first phase allows you to discover a problem domain to gain insight, and then narrow down that insight to define the problem to be solved. The second uses that problem definition to develop a range of potential solutions, tested for viability, and then deliver these solutions to an audience and use their feedback to converge on a single preferred solution.

The double diamond model has become almost ubiquitous in the world of design, and there may well be as many renderings of the illustration above as there are designers. However, as I mentioned earlier, the divergence-convergence model can be applied to most situations requiring thought and therefore to most meaningful undertakings. It was only a matter of time before the Double Diamond concept was extended.

Two’s company, three’s a crowd

It’s at this point in our story that the Triple Diamond Model enters the fray. There are many versions of this model and they all vary in the terminology used, but the one thing the majority have in common is the direction in which they extend the model. The new diamond is placed in front of the Double Diamond model and its two stages are often referred to as “opportunity” and “strategy”. 

The intention of this extra diamond is to reflect the process that gets us to the awareness that there is a particular problem worth solving. First explore the market to find a range of opportunities (divergence), then formulate a strategy that targets the first of these opportunities in the form of a proposition (convergence). In the world of software development, this is where the product strategy emerges.

Some would say this is just taking a good model and ruining it with unnecessary embellishment. It’s a common pattern with models that people spend too little time understanding them before adding complexity to cover aspects already encompassed by the original concept. A minimalist’s nightmare.

Others would suggest that the Double Diamond is specific to one particular viewpoint, and requires extension to cover a broader range of perspectives. I’m an advocate for the second view – the double diamond is an excellent start, but it’s not the full story. The real question is how far does that story stretch? Is three diamonds enough? Four? Is there even a limit?

For those of you who hate spoilers, look away now. For the rest of you, (the impatient ones), the answer is five.

A matter of perspective

To understand the Double Diamond we have to see it in context, and to do this we need to expand our perspective to encompass the full process from start to finish. Designers often (rightly) complain that they are not engaged early enough in the process, and this in itself is a recognition that there is a broader activity to which they could contribute. The same is true for most participants in the creative process. Each sees the process from the perspective of when they are first approached to the point where their role ends. Beyond those points things become more vague and tend to get condensed into “the step before” and “the step after”. What might, from a local perspective, seem like brief steps, are actually a chain of events spanning weeks or even months of investigation and insight.

Also, when considering processes, it is popular to think in terms of straight lines and trends (a beginning, a middle and an end; a start point and a destination). However, many things in life are cyclic, and only look like linear trends if we observe them for a limited duration. Proper understanding requires context. The context for the Double Diamond process is product development, and this is part of a loop I like to refer to as the “Entrepreneurial Cycle”.

As can be seen, this cycle involves five points of focus, and it is from this that the limit of five diamonds is derived. To get from one point to another requires divergence to understand and create options followed by convergence to get to the decision point. But first a quick summary of how the cycle operates.

An entrepreneur operating in a given market observes that market and perceives threats and opportunities emerging as that market evolves. This observation gives rise to an ambition and ambition leads to the development of a range of strategies from which one is chosen. This strategy gives rise to a proposition which in turn is developed into a product that can be deployed into the market. If this product is successful, it will inevitably change the market, leading to new threats and opportunities, and so the cycle repeats itself.

The biggest lesson to draw from this is not just that product development is a cycle, but that the act of developing products feeds the cycle and keeps it going. The very act of introducing a new product into the market changes that market, and so a wise entrepreneur recognises the need to keep moving. In essence, the market for which your product was developed no longer exists once your product is successful.

Turning the wheel

Let’s take a simple example to bring the Entrepreneurial Cycle to life. A company providing an online service has seen a plethora of challengers enter their market. Customer churn is high and brand loyalty is low. Although they’re seeing as much customer gain as loss (and thus maintaining market share), the cost of maintaining this share is becoming uneconomical.

They believe their service is superior and embark on a venture to radically improve customer retention and brand loyalty. They have established their ambition.

They also observe other apparently similar industries adopting subscription models and believe this might be a way to achieve this retention. This approach now forms the basis of their strategy.

The information available to them shows that a monthly subscription model providing customers great value for money through unlimited access to services has improved retention in other industry sectors. They also believe that by adding benefits and exclusive rewards to this model they will achieve the levels of customer retention they desire. Their proposition is starting to take shape.

They now look into their customer base and decide a single subscription won’t work for everyone, so they define a tiered model and develop this into a set of subscriptions options from which the customer can choose (silver, gold and platinum). Each has a different level of service and associated offers, and comes with different levels of customer support ranging from online chat through to personal concierge service. They set out to develop these products and launch them onto the market in place of their current offerings.

If, as they hope, this is a successful venture, they will retain their current customer base and continue to acquire additional market share through the high churn the industry is experiencing. However, the model is easy to duplicate and their competitors will no doubt adapt by introducing similar, or potentially better, products. They will need to prepare in advance to react to this change in the market if they are to stay ahead of the game.

And what if they’re wrong? That’s a significant amount of effort and investment to waste on an unsuccessful venture, not to mention the potential reputational damage. This is the danger of linear thinking.

Diamonds are forever

To address this, each stage in the Entrepreneurial Cycle needs to exploit the elegant wisdom of Béla H. Bánáthy. The earlier diagram, however, fails to convey this. It’s drawn in a way that implies movement from one state to the next is a linear, predictable activity, and the example above includes elements of this linear thinking style. It should be clear from the example that the decision making involves a lot of assumptions and gut feel decisions. There is little room for uncertainty or verification.

So now we need to overlay this cycle with the diamond model to make it more complete and add some rigour to the process of investigation and decision making. For ease of drawing, I’ve stretched it out horizontally, but please remember it’s cyclic:

And for those who prefer text to visuals, here is a further breakdown of each of the five stages of the Entrepreneurial Cycle described in terms of convergence followed by divergence::

• Market to Ambition
  Before doing anything you need situational awareness. To achieve this you must observe the market in which you’re operating to understand how it’s evolving and to identify the threats and opportunities. You might even want to draw a map of your territory to better understand it. From a diversification perspective, we’ve developed the Business Evolution Map. For a more personalised picture, you might want to try creating a Wardley Map. Once you understand the space in which you’re operating you can identify the most attractive opportunity (or the most immediate threat) and target an outcome that addresses it. The way this outcome will be achieved is not yet known, but there is now an ambition to achieve it. You have an intended destination.
• Ambition to Strategy
  Now you know the outcome you want but not how to make it happen. What you need to do is find a course of action that will get you there. The best way to do this is to explore the routes (the strategies) available to you to get to your intended destination. Exploration doesn’t just involve conceiving of the routes – it includes testing out your assumptions in some small way to see how feasible they are. This testing of assumptions is essential if you are to successfully orientate on the strategy most likely to succeed. Never underestimate your ability to choose the wrong thing based on familiarity when you lack the evidence to make a value based decision.
• Strategy to Proposition
  To turn the intent of your strategy into something with real business potential you need to do some targeted research. What is the true value of the idea (the size of the prize) and what will need to change in your business and in the relationship with your customer to make it real? Once you understand this, you can shape your intent into a proposition that includes a viable business and service model. And always remember, research is not just a numbers game; it’s a hands-on activity where assumptions need to be tested and hypotheses proved.

• Proposition to Product
  The first diamond from the Double Diamond Process, in which you discover the needs of the users involved in your proposition, and define the product required to fulfil those needs.

• Product to Market
  The second diamond from the Double Diamond Process, in which you design the product and deliver it to the market, iterating on your design as you go based on user feedback and early indicators of success from the market.

In summary

• Product development is a cycle, not a straight line journey to done
  The very act of introducing a new product to the market causes a ripple effect of change. Competitors will respond, either through emulation of your change or innovation to defend against it. Customer expectations will also change. What was once fresh and exciting will become commonplace as familiarity potentially breeds contempt. The cycle is self-sustaining.
• It starts before an idea has formed or a problem has been identified
  Limited perspective often leads people involved in the process to believe they are closer to the beginning than that really are. A new idea rarely emerges from nothing overnight. It is the product of an extended process stretching back weeks or even months.
• Divergence expands understanding without judgement
  It is tempting, when researching a situation, to filter the information you’re receiving and reject concepts that don’t fit your current understanding of the domain. All too often, the real solution (and definitely the innovative solution) lies in the unknown. This is why suspending judgement is essential to successful divergence.
• Convergence chooses an answer by eliminating that which doesn’t work
  Good convergence requires you to try things out; to test every assumption before deciding. It’s a hands-on activity, not an academic exercise. Nor is it a democratic process. Voting as a way to choose might be quick, but it relies on gut feel and prior assumptions. To do convergence you need practitioners to try things out and you need decision makers who act on the evidence of those experiments, not the security of familiar ideas.

And finally, if you take only one thing away from this article, make it this: 

Limited or untested knowledge leads to bad decisions. To discover what you don’t know, diverge without judgement. To find the answer that works, converge through experimentation.

At Equal Experts, we’re frequently asked about success measures for product delivery. It can be hard to figure out what to measure – and what not to measure!

We often find ourselves working within multiple teams that share responsibility for one product. For example, an ecommerce organisation might have Equal Experts consultants embedded in a product team, a development team, and an operations team, all working on the same payments service.

When we’re asked to improve collaboration between interdependent teams, we look at long-term and short-term options. In the long-term, we advocate moving to cross-functional product delivery teams. In the short-term, we recommend establishing shared success measures for interdependent teams.

By default, we favour measuring these shared outcomes: 

• High profitability. A low cost of customer acquisition and a high customer lifetime value.
• High throughput. A high deployment frequency and a low deployment lead time.
• High quality. A low rework time percentage.
• High availability. A high availability rate and a low time to restore availability. 

If your organisation is a not-for-profit or in the public sector, we’d look at customer impact aside from profitability. Likewise, if you’re building a desktop application, we’d change the availability measures to be user installer errors and user session errors. 

These measures have caveats. Quantitative data is inherently shallow, and it’s best used to pinpoint where the right conversations need to happen between and within teams. What “high” and “low” mean is specific to the context of your organisation. And it’s harder to implement these measures than something like story points or incident count – and it’s still the right thing to do.

Beware per-team incentives

‘Tell me how you measure me and I will tell you how I will behave’ – Eli Goldratt

People behave according to how they’re measured. When interdependent teams have their own measures of success, people are incentivised to work at cross-purposes. Collaboration becomes a painful and time-consuming process, and there’s a negative impact on the flow of product features to customers. 

At our ecommerce organisation, the product team wants an increase in customer page views. The delivery team wants more story points to be collected. The operations team wants a lower incident count. 

This encourages the delivery team to maximise deployments thereby increasing its story points, and the operations team to minimise deployments to decrease its incident count. These conflicting behaviours don’t happen because of bad intentions. They happen because there’s no shared definition of success, so the teams have their own definitions.

Measure shared outcomes, not team outputs

All too often, teams are measured on their own outputs. Examples include story points, test coverage, defect count, incident count, and person-hours. Team outputs are poor measurement choices. They’re unrelated to customer value-add, and offer limited information. They’re vulnerable to inaccurate reporting, because they’re localised to one team. Their advantage is their ease of implementation, which contributes to their popularity.

We want to measure shared outcomes of product delivery success. Shared outcomes are tied to customers receiving value-add. They encode rich information about different activities in different teams. They have some protection against bias and inaccuracies, as they’re spread across multiple teams.   

When working within multiple teams responsible for the same product, we recommend removing any per-team measures, and measuring shared outcomes instead. This aligns incentives across teams, and removes collaboration pain points. It starts with a shared definition of product delivery success.

Define what success means

When we’re looking at inter-team collaboration, we start by jointly designing with our client what delivery success looks like for the product. We consider if we’re building the right product as well as building the product right, as both are vital. We immerse ourselves in the organisational context. A for-profit ecommerce business will have a very different measure of success than a not-for-profit charity in the education sector. 

We measure an intangible like “product delivery success” with a clarification chain. In How To Measure Anything, Douglas Hubbard defines a clarification chain as a short series of connected measures representing a single concept. The default we recommend to clients is:

product delivery success includes high profitability, high throughput, high quality, and high availability

In our ecommerce organisation, this means the product team, delivery team, and operations would all share the same measures tied to one definition of product delivery success.

These are intangibles as well, so we break them down into their constituent measures.

Pick the right success measures

It’s important to track the right success measures for your product. Don’t pick too many, don’t pick too few, and don’t set impossible targets. Incrementally build towards product delivery success, and periodically reflect on your progress.

Profitability can be measured with cost of customer acquisition and customer lifetime value. Cost of customer acquisition is your sales and marketing expenses divided by your number of new customers. Customer lifetime value is the total worth of a customer while they use your products. 

Throughput can be measured with deployment frequency and deployment lead time. Deployment frequency is the rate of production deployments. Deployment lead time is the days between a code commit and its consequent production deployment. These measures are based on the work of Dr. Nicole Forsgren et al in Accelerate, and a multi-year study of Continuous Delivery adoption in thousands of organisations. They can be automated.

Quality can be measured with rework time percentage. It’s the percentage of developer time spent fixing code review feedback, broken builds, test failures, live issues, etc. Quality is hard to define, yet we can link higher quality to lower levels of unplanned fix work. In Accelerate, Dr. Forsgren et al found a statistically significant relationship between Continuous Delivery and lower levels of unplanned fix work. Rework time percentage is not easily automated, and a monthly survey of developer effort estimates is a pragmatic approach.

Availability can be measured using availability rate and time to restore availability. The availability rate is the percentage of requests successfully completed by the service, and linked to an availability target such as 99.0% or 99.9%. The time to restore availability is the minutes between a lost availability target and its subsequent restoration. 

In our experience, these measures give you an accurate picture of product delivery success. They align incentives for interdependent teams, and encourage people to all work in the same direction. 

If your organisation is a not-for-profit or in the public sector, we’d look at customer impact aside from profitability. Likewise, if you’re building a desktop application, we’d change the availability measures to be user installer errors and user session errors. 

Measuring shared outcomes rather than team outputs makes collaboration much easier for interdependent teams, and increases the chances of product delivery success. It’s also an effective way of managing delivery assurance. If you’d like some advice on how to accomplish this in your own organisation, get in touch using the form below and we’ll be delighted to help you.