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 referred to as desirability, value is the benefit a customer gets from using a product or service. For most products and features, value is the most critical 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 when 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.

Burger King's Satisfries
Burger King's Satisfries

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 of utilizing 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 five 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 minimal 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 possible errors?

  • Easy to learn: Can the product be used with users' prior knowledge? Does it apply patterns of interaction that are well-known to the target audience? Is it predictable? Can users extend their knowledge and skills easily?

As an example, imagine you want to provide your phone number on a website and are offered these two 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. These personas are supposed to actually be using the product because their skills and experience may differ from those of 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 a ready-to-drink, pre-brewed cold coffee sold in a carton. The packaging promised superior convenience to consumers, and it featured a picture of a hot mug. However, the coffee was, in fact, the opposite: hard to handle and, due to its packaging, couldn’t be microwaved. The coffee was discontinued shortly after its release due to poor usability.

Maxwell House Brewed Coffee
Maxwell House Brewed Coffee

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 make 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 it is 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 hardly worked 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 wasn’t feasible based on existing technology.

Microsoft Bob
Microsoft Bob

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.

Marty Cagan

viability refers to the second part of that quote: any new product or service must also work for the business, be economically justifiable, and be 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 proper 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, the plan was scrapped very soon as it would have hurt the overall Netflix business.

Netflix Qwikster
Netflix Qwikster

To summarize, even when we can build a new product, when usability is 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.