How to de-risk new product development ideas

Welcome to the Product Digest – our regular wrap up of the issues, trends and themes driving the world of digital product strategy and management. In this issue, we’re focusing on how to reduce the risks around new product development for any product or service ideas.

Big ideas are what great organisations are founded upon, but going into the unknown carries a huge amount of risk for product teams. Here’s an overview of some product management techniques that allow product teams to stress-test their next big idea and find out whether it’s a rocket ship waiting to launch or a dud in the making.

Risk? What risk?

It’s easy to get excited by an idea and want to get stuck into new product development as soon as possible. While time to market can be a factor in the potential success of an idea, diving headfirst into spending time and money developing a new product or service when the likelihood of success is not understood is a recipe for failure.

Some ideas suffer from fatal flaws that mean they’ll never achieve the outcome the team is banking on – and that’s okay. However, the phrase ‘fail fast, fail quickly’ is at best misleading, and at worst dangerous.

If we can use cheap, throwaway experiments to figure out which aspects of an idea work and which don’t, that’s considered learning. But if an organisation only figures out why an idea doesn’t work after they’ve spent significant amounts of time and money developing it, that’s considered failure.

‍

‍

The four types of risk

While the term ‘risk’ can be defined in many different ways, Marty Cagan’s definition of the four types of risk is clear and effective for new product development.

Value risk – whether customers will buy it or users choose to use it
Usability risk – whether users can figure out how to use it
Feasibility risk – whether engineers can build what is needed with the time, skills and technology available
Business viability risk – whether this solution also works for the various aspects of the business

Having these simple concepts in mind helps product teams to focus on the feasibility of ideas as a whole, from both a customer and business perspective.

Four steps to reducing risk in new product development

Much has been written about different techniques that can be used to reduce risk in new product development, from Eric Ries’s lean startup methodologies to Strategyzer’s Testing Business Ideas. There’s a lot to take in.

We’ve boiled things down to four simple steps, with the main objective of getting everyone thinking about how an idea can be defined and tested quickly and cheaply, and in a way that allows the team to communicate their approach to the wider organisation.

To get started, we must first define exactly what problem this shiny new idea intends to solve.

‍

‍

Step one: Problem definition Statement

Many new product or service ideas fail because they simply were not solving a problem that needed to be solved, often after months or years of work. Before embarking on new product development, you should know:

What problem you are aiming to solve – and what you’re not solving. Set your scope too wide and you’ll fail to solve any problem all that well. It’s much better to solve one problem brilliantly.
Whether or not the problem exists for your chosen audience, with evidence to back that up.

To do this, we use a product definition sheet, commonly used in Six Sigma methodologies. It encourages product teams to answer the who, what, where, why, when and how of the problem they’re working on – or ruling out. The real value of this technique lies in the evidence, both quantitative and qualitative, that the team gathers to figure out just how big the problem really is.

The findings can then be summarised into a problem definition statement – one to three sentences that can be shared with the wider team. Hopefully at this stage the team has either found that the problem does indeed exist, or that their initial assumptions were wrong and they should focus on something else.

Step two: Leap of faith assumptions

When it comes finding a solution for the chosen problem, the product team should focus on all the things that need to be true in order for the solution to be deemed successful.

This is a technique from lean startup methodologies that helps uncover which aspects of a potential business idea need to be stress-tested. If an assumption is found to be false, the team may be able to look at alternative solutions or move on to a different problem.

Here, focusing on the four types of risk can help uncover assumptions about both customer and organisational viability for new product development.

Some examples of leap of faith assumptions include:

Value

People will actively engage with our potential solution when we present it to them
People will be willing to pay for it

Usability

People will be able to figure out how to use it without special training

Feasibility

We will be able to build the solution with the knowledge and resources we have available

Business viability

The solution will be compatible with our organisation’s strategic direction

Step three: Risk prioritisation

Once all leap of faith assumptions have been listed, the team can begin to figure out which are the most important to tackle.

A useful way to do this is to map out where each assumption sits on a graph, where X is the level of certainty the team has around whether or not the assumption is true and Y is how critical (or not) the assumption is to the success of the idea as a whole.

Anything that appears in the critical-uncertain quadrant should be tackled first as these issues have the greatest likelihood of causing the idea to fail.

‍

‍

Step four: Hypothesis testing

The final step is to start thinking about how quickly and inexpensively the team can figure out whether or not their riskiest assumptions are true.

There are myriad different ways to test an assumption – this guide from Strategyzer is a great place to start if you want to learn more about hypothesis testing methods.

When trying to pick the most appropriate method for testing assumptiona, the team need to answer two big questions:

What level of certainty is required in order to proceed to the next step with this idea?
How much time and/or expense are we willing to invest to get to that level of learning?

Assumptions can also be tested with more than one method. For example, if a team has an assumption that, “Customers will be able to use the feature without any training,” they could begin testing with a basic cardboard prototype that takes just a few minutes to build. Once they are more confident, they can move on to building a clickable prototype, knowing that the investment of a few days design time was less likely to be wasted.

Ultimately, de-risking new product development is a mindset that teams need to develop, continually asking themselves how they can understand the assumptions that are critical to success and test them as quickly and inexpensively as possible.

The methods of testing may vary, but the four steps above should help keep everyone aligned on answering the most important questions for your idea.