The Four Key Risks

Product Discovery, as will be explained in depth in Part 3 of this book, is needed to address four types of critical risks associated with product development. While there is no absolute guarantee of success, the objective is to collect enough confidence that a solution to be developed later during Product Delivery will actually solve the customer’s problem. These 4 key risks are:

The Four Key Risks
The Four Key Risks
To eliminate these risks, we need to collect evidence instead of having opinions. In many cases, most of these risks can easily be eliminated, e.g. feasibility mostly being an issue when it comes to something never done before, a completely new technology stack or performance requirements way beyond anything done before – but even then it is helpful, as a team, to jointly agree on this view.

Value Risk

Sometimes also referred to as desirability, value is the benefit a customer gets by using a product or service. For most products and features, value is the most important risk because if there is no value, then all other aspects won’t matter. Also, value is in the eyes of the customers: When at a later stage problems are encountered with usability, performance, reliability, and all that — these can be fixed. But if there is no demand, then nothing else matters. In most situations, customers will already solve a task in one way or another. Note that this might be a completely different approach to get the job done, it might use a completely different set of tools, even non-digital pen & paper solutions. Consequently, not only has a new solution to provide value but it has to be substantially better than a previous solution to also justify switching costs.

Example

Fast food company Burger King in 2013 introduced Satisfries and advertised it as a healthier alternative to traditional french fries. The new fries were also more expensive than regular ones. In the end, the product was a failure and quickly discontinued, because consumers did not see any value in it.

Specifically in Enterprise B2B, note that there might even be conflicting perceptions of value: while the buyer and decision maker could aim primarily for compliance, transparency, and efficiency gains, daily users might prefer flexibility and convenience. See Focus on B2B for more details.

Usability Risk

The key aspect of usability is: even when there is a potential value, even when users want to use a product — will they actually be able to? Will they be capable to utilize it in the exact context when they need it, with the skills they have, will they even enjoy it?
In a bit more detail, there are 5 factors to usability, also referred to as 5-E’s:
  • Effectiveness: Does the product allow users to achieve their goals?
  • Efficiency: Can users accomplish their goals with a minimum amount of resources, so quickly?
  • Engaging: Is the product pleasant and satisfying to use?
  • Error Tolerance: Does the product prevent errors caused by the user’s interaction and does it help recover from any errors that might occur?
  • Easy to learn: Can the product be used with prior knowledge of users, does it apply patterns of interaction well-known to the target audience, is it predictable, can users extend their knowledge and skills easily?
As an example, imagine you simply want to provide your phone number on a website and are offered these 2 solutions:

Obviously, the first one is a very clunky way of entering a phone number; but even the second form is falling short as it only complains about an invalid format — without any guidance as to which format is accepted.

To assess usability, it is crucial to have the specific target group in mind, the personas who are supposed to actually be using the product. Because their skills, their experience may differ from other groups of people just as the context of product utilization might be specific. As an example consider office environments, with stationary PCs on desks, and compare these to the factory floor and harsh environments, potentially even with sparse Internet connectivity. Skills and expectations of users will be very different in both environments, as is the context of using a tool.

Example

Maxwell House Brewed Coffee was ready-to-drink, pre-brewed cold coffee, sold in a carton. Promising superior convenience to consumers, also with the picture of a hot mug on the packaging, it was in fact the opposite: hard to handle, and due to the packaging couldn’t be microwaved. The coffee was discontinued shortly after the release for poor usability.

Feasibility Risk

The question of feasibility is: How confident are we that we can actually build and operate the product we envision?
  • Does the team know how to build, do they have the right skills and tools, did they even build something similar before?
  • Will the team have the resources to build, most notably enough time?
  • Are there any impacts on architecture, new components needed, or specific dependencies that need to be managed?
  • Can the product be built to comply with SLAs, so be scalable and performant enough?
  • Apart from building, can the team also roll out, configure and operate the product?

Example

In 1995 Microsoft released Microsoft Bob as a simple and easy-to-use interface. However, Bob did hardly work on standard hardware at that time and, instead, required way more processing power than standard home computers had at that time. Apart from other aspects, such as pricing and conflict with later Windows 95, the tool simply wasn’t feasible based on existing technology.

In most cases, feasibility will not be a major problem, specifically when it comes to more incremental feature development rather than inventing a brand-new product. The engineering team may have seen similar requirements many times before and, thus, quickly be able to eliminate concerns. In some situations, however, they might need a few days to investigate or even prototype in order to gain confidence or find a working solution.

Viability Risk

Looking at

As Product Managers, our job is to build products that our customers love, yet work for our business.

viability refers to the second part of that quote: any new product or service must also work for the business, must be economically justifiable and in line with the business strategy. Essentially, ensuring viability boils down to aligning with selected stakeholders and clarifying potential risks with them, such as what are the impacts on marketing channels, whether sales have the right channels and skills, how the new product idea impacts existing customers, or how it supports (or violates?) the long-term business strategy.

Example

Netflix, today known as the media streaming giant and producer of content, initially started as a deliver-by-mail DVD rental service competing with Blockbuster. To focus on online streaming, the company in 2011 announced Qwikster as a separate company handling the DVD business. The change also would have been much more expensive to customers wanting to consume both, DVD and streaming content. Being widely criticized, then plan was scrapped very soon as it would have hurt the overall Netflix business.

To summarize, even when we can build a new product, when usability would be great and there is no technical risk of building it — viability is about the question: Should we build this?

Note that this chapter did not address risks related to poor execution and failures in Product Delivery.

Tools to Mitigate the Risks

Depending on the risk, specific activities, tools, frameworks, and techniques can be applied to increase confidence and reduce uncertainty. The table below provides an overview of selected methods:
PM Activities by Risk
PM Activities by Risk

Some tools are specific for a particular risk while others can be applied more holistically. The entries marked in bold are explained in more detail in the Resources section of this playbook, and others are explained in the respective chapters describing our process.