Tailoring the Framework for Innovation

Eadaoin Doherty

Eadaoin Doherty

Product. Pilates. Soy chai lattes.

Recently, I’ve been working with clients across different phases of their product development. One client had a product idea they wanted to explore and test, and the other client had an existing product which they wanted to adapt for a new market. Both of these situations required my team and I to understand the market in detail before we could determine what the product would be. We knew that if we understood the market, and the problems potential users were facing, we could start to identify opportunities and prototype a product that met those needs.  

Understanding the market and identifying user needs are vital first steps in a lean approach to product development. Skipping these steps to create an untested product, based on just an idea, is a risky business. Google Glass is a good example of a product that sounded like a great idea, but one that the market wasn’t interested in! Do not trust the saying ‘build it and they will come’ – they very rarely do! Set yourself up for the best chance of success by making sure customer research is your first step.

To kick off the projects mentioned above, I needed a process that would guide me from research to prototype. I was aware that the Design Council had recently updated their Double Diamond model to be a Framework for Innovation, and I was keen to take it for a test run. 

Design Council’s Framework for Innovation 

As with any process model, it needed to be adjusted to meet our specific needs. Below is a description of how we used the model and how it helped guide us through the innovation process.

The Framework for Innovation (with a few adjustments)

Fundamentally, the Framework for Innovation is split into two sections:

    1. The discover and define phase
    2. The develop and deliver phase

We made the call that the outcome of our process would be to create a validated prototype, rather than production software. For this reason we named the first diamond our ‘Discovery’ diamond, and the second diamond our ‘Prototype and Validate’ diamond. For each diamond we noted the activities we wanted to do as part of our research.


Our updated Framework for Innovation

The visualisation of the diamonds helped people understand whether we were in a phase that required divergent or convergent thinking. To really drive this home we even wrote it on the model.  

Divergent Vs Convergent thinking

This short video is a great explanation of the differences between convergent and divergent thinking and how they compliment each other.

Giving people the time and space to think divergently helps us to be creative. There is often a tendency to hone in on an idea or an opportunity as soon as one appears, but this can stifle exploration of other ideas and opportunities. Asking people to consciously look for more ideas and opportunities, without the risk of judgement, gives people a feeling of freedom. They are able to explore ideas in more depth and investigate other potential paths. 

Conversely, having time assigned to convergent thinking lets people know that now is the time for reviewing insights, discussing options and making decisions. It’s important to avoid ‘analysis paralysis’, so set a defined time period for decision making and then move on. The Framework for Innovation is an iterative process, so as you learn you can adjust your thinking, but you need to make decisions to get things done. 

The Discovery Diamond

Divergent thinking

The first half of the discovery diamond was all about knowledge gathering, immersing ourselves in the market and learning about the (potential) users. We wanted to find as many market opportunities as we could – without jumping to solutions. Our goal was to simply discover opportunities.

We also incorporated some desktop research to help better our understanding of the market.  We split research tasks amongst the team and some examples of the activities we undertook were;

User research was a key part of the research process.  We needed to understand what solutions potential customers were already using, what problems they were facing and what decisions they were making on a daily and weekly basis. Based on the market research and company goals, we created a hypothesis about who we thought would use the product, and the problem it would solve for them. Then, we undertook user research based around this hypothesis. We spoke to eight potential customers to gather feedback and gain insights into user problems.

Convergent thinking

We shared the data we gathered amongst the team asynchronously, so folks could start to mull it over individually.

We then came together to review the insights and identify areas of opportunity within the market. The aim of our Discovery convergent thinking was to answer 2 questions;

  • Who were our potential users?
  • What problem could the product solve for them?

At this point we were still steering clear of thinking about solutions. We regularly checked each other if a sentence started with ‘We could build…’. This is hard to do when you have lots of great ideas in your head, but it’s important to wait until the second diamond for those discussions, otherwise you can get pulled in too many directions before you’ve decided what problem you are solving and for whom.


The Prototype and Validate Diamond


Divergent thinking

We entered the second diamond with our user, and the problem we were solving, clearly defined. We had identified several opportunities in the discovery diamond, and had prioritised them, narrowing down to one option to take forward into the prototype and validate diamond. We were excited and optimistic about the idea we were bringing forward, but we didn’t throw away all the other ideas. We parked some of them, knowing they could be worth investigating later. 

Now it was time for ideation, and lots of divergent thinking again. We needed to identify a product idea we could prototype and test with users. We held sketching workshops, debated solutions and built on each other’s ideas.  

At this stage it was also important for us to identify our riskiest assumptions, so they could be quickly tested with users. For one project, an assumption we needed to test was whether we had enough data (gathered over the last 3 years) to create market insights that would be valuable to customers. So as well as testing whether customers would pay for the data, we also needed to ensure that technically we could access it and draw useful insights from it.

Convergent thinking

After lots of divergent thinking and discussions, it was time for us to select what we believed to be the best solution and to determine how we would test it with users. We also needed to assess the technical feasibility of the idea so debated the pros and cons of each idea, and as a team, selected one to test. 

Our prototyping approach was different in each of the two projects. For one, we created simple, hand drawn wireframes which allowed us to discuss the idea with potential users, and test our riskiest assumption about their behaviour. For the other project we had to create a fairly technical prototype that allowed us to pull data into a visualization tool.  It’s important to choose a prototyping approach that will best allow you to test your riskiest assumptions as quickly as possible.

Iterate, iterate, iterate

As the blue arrows in the Framework for Innovation indicate, the processes described above are iterative. Finding the right product for the right market doesn’t happen the first time you work through the model, but with persistence and iteration of a process like this, you’ll get there and come out with something much better than only once around. The process is fun, exciting, dynamic and ultimately rewarding when you do nail your product-market fit. 

If you are interested in learning more about how we use the Framework for Innovation then why not get in touch? Say hello here, we’d love to hear from you!

Liked this post? Share it on…

Share on facebook
Share on twitter
Share on linkedin

Related posts

Scott Rogers

Mapping Team Effectiveness

Having worked with hundreds of product teams in organisations of many shapes and sizes, we’re in a unique position to understand many of the challenges teams face, as well as the ways they might improve. One of the tools we use to identify how teams are working and what might be holding them back is the Competing Values Framework.

Read More
Eadaoin Doherty

Product managers and user research

As a Product Manager, I delight in how the collaboration of a product brain and a design brain will always give a better outcome than just one of those brains going solo. However, the reality is, sometimes product peeps have to go it alone when doing user research. I want to reassure you that as a product person, you can do this and get some really valuable insights by following these basic rules.

Read More