tProduct development is inherently risky, and the most heavily-prized new product development — the product that will open up a new market or create a new category — is the most risky of all. In fact, only in the most mature markets can product developers operate with near-certainty that their products will succeed on the market. The chance of failure is a part of life as a product developer, and new product development requires people who have high tolerance for the unknown.

Rapid Learning Cycles eliminate risk by closing Knowledge Gaps. Knowledge Gaps are the things that we need to learn in order to make good decisions that stick, and don’t cause problems later. A Knowledge Gap provides the focal point for a Rapid Learning Cycle.

When we close a Knowledge Gap, we eliminate the risk that we will make a wrong decision based on incomplete information. But it will never be enough to eliminate every risk. This makes risk management a critical skill for product development leaders, whether they use Rapid Learning Cycles or not.

Sources of Risk in Product Development

While it seems like everything in product development is risky, some areas are more likely to generate high-impact risk:

The Knowledge Gaps You Choose Not to Close: Not every Knowledge Gap can be closed within a reasonable period of time to bring a product to market. All the Knowledge Gaps that cannot be closed — the ones where the team must make a best guess — represent an area of risk.

New Markets, New Customers: Some of the most important risks to manage are not technical — they arise from the need to move into a new market or serve a new set of customers who have different expectations. Market research, surveys, focus groups and test markets can reduce, but not eliminate the risk that the market will reject the product.

New Technology: New areas of technology, new approaches to supplier management and new manufacturing processes all generate risk that will be difficult to eliminate completely until the product has made it out into the field.

Stakeholders Who Make Decisions Outside Your Control: Regulatory bodies, the financial markets, competitors, channel partners and major customers are only a few of the external stakeholders whose actions can derail a product development program.

The Product’s Environment: Products operate within the external environment and product development programs live within the company’s environment. Economic conditions or the political situation in a target market can impact the success of a product. Similarly, internal reorganizations, the success or failure of related products, leadership changes and resource availability also affect the health of a product development program.

The Company’s Environment: Sometimes, simply the fact that a program is innovative generates a lot of risk from the internal environment: the leaders may not understand the product’s strategic fit, all of the skills needed to develop the product may not exist inside the company, and it may stress the organization’s standard processes for procurement, regulatory approval, IP protection or transfer to manufacturing.

Risk Management

The word “management” is heavily overused, but it is the best word to use for risk, because actively managing risk is exactly what we have to do. We need to monitor risks, make and execute mitigation plans, and continuously scan the environment for new risks. It doesn’t need to take a lot of time, but it does take some attention from the project leader and the team.

The existence of a Risk Management plan does not mean that a team is managing its risk. Teams under time pressure will make a plan because they have to make it in order to pass a gate review. But the plan will get stuck on a system someplace and never looked at again.

Simple tools work best. Excel spreadsheets and/or sections of visual planning walls can store the key information about a team’s risks, and a regular cadence of reviews — often tied to integration events — help teams to recognize when a risk has turned into a reality, and new risks have appeared.

I like to see teams use a simple classification method to identify the impact and likelihood of a risk, as a way to prioritize work among many potential problems. High impact items require full back-up plans, even if the likelihood is low. Low impact risks may not justify the effort even if likelihood is high. Many things will fall in the middle, where the team should have some mitigation plans available, but should not spend a lot of time on them.

I don’t like checklist-driven Risk Assessments, except as a final check at the end of a session to identify risks. These risk assessments only tell the team what has failed in the past — they say nothing about the risks inherent in this new program.

The primary risk management tool that my teams use is a simple prioritized list, with a place to either write down the mitigation plans or to link to A3s that contain full back-up plans. This risk list gets ongoing review from the team to remove those risks that did not materialize, and add new ones that have developed.

When a Risk is Not A Risk

High impact items with high likelihood are not risks. If every one of your last five products has had installation issues and nothing else has changed, then “installation” is not a risk — it is a practical certainty. Similarly, if you have never sold a product through a new sales channel to a new market, then “market risk” fails to express the major obstacles that you may face. These kinds of things don’t belong on your risk list. A “known unknown” is not a risk — it is a Knowledge Gap — and calling it a risk is mere wishful thinking.

Teams that include near-certainties as “risks” dilute the focus of risk management. At the same time, including these items on the risk list may lead a team to believe they have done all they can do about these challenges, depriving them of the focus they need to overcome the obstacles permanently.

A Simple Risk Management Checklist

• The team has identified its Key Decisions and Knowledge Gaps, including the Knowledge Gaps that they will not close (these are the first items in the Risk Assessment).
• The team has looked for other risks using several different techniques to address the different sources of risk.
• The team has completed a simple Risk Assessment for every identified risk with appropriate mitigation plans.
• The team regularly updates this list (usually at Integration Events) to see if anything can be removed, or should be added to the list.
• The Risk Assessment is a key input into the investment decisions that business teams make at stage gate meetings to move projects into new development phases.
• The technical Risk Assessment is used to develop product test plans, and the commercial Risk Assessment is used to develop test marketing and launch plans.
• The Risk Assessment is updated after the project is finished, at the team’s final Knowledge Capture meeting, so that future teams can learn from this team’s experience.