Product Management Is a Game of Risk

Photo by Loic Leray on Unsplash

When I first started working in product management, I focused on opportunities. There were so many great ideas to pursue, and this was thrilling. However, I quickly came to realize that ideas are cheap, and time is scarce. I was constantly faced with the question of prioritization, in all its forms:

• Which one of these hundred ideas should we invest in?
• Should we invest the bare minimum in two features, or just do one of them well?
• Should we optimize this existing feature, or spend time on this moonshot?
• Will we ever find time for feature X?
• How can we find time to pay down this technical debt/invest in this enabling technology?
• Should we build feature Y that Strategically Important Customer wants, or is that a distraction we need to avoid?
• And so on.

If your day job is building products, I expect you can relate to this challenge. The issue is not coming up with ideas or problems to solve, it’s finding the right ones. In fact, prioritization is such a fundamental fact of life in product, most articles on the subject focus on how to prioritize. Some frameworks propose a formula, some a process. For me, what has been most helpful is the lens through which I view prioritization, and for me, that’s risk.

What is product risk?

Marty Cagan’s description of the four product risks is my go-to. In short, there are four main risks that can cause a given product or feature to fail:

• Value risk — the risk of building something people don’t want or won’t buy
• Usability risk — the risk that users can’t figure out how to use what we’ve built
• Feasibility risk — the risk that we can’t build it with the time, capabilities, and/or technology we have
• Business viability risk — the risk that what we’re building doesn’t work for our business (e.g. has legal complications, the financials don’t work, etc.)

That’s a lot of negatives, right? Far less exciting than a list of ideas! But putting ideas through this gauntlet separates the bad, mediocre, or even good ideas from the great ones. Here are some ways a risk mindset can help level up your product thinking.

Four advantages to taking a risk mindset

A risk mindset illuminates your objective

Thinking through the lens of the four risks expedites your product development process. Product discovery can be thought of as the process of de-risking - reducing the likelihood of building the wrong thing. Rather than thinking about how to “refine” an idea, which typically leads to a bunch of specifications and technical discussions, thinking in terms of risk identifies what is most important to focus on for a given idea. This will be different for different types of work, depending on its size, complexity, whether we’ve done something similar before, what discovery work has already been done in this area, and so on.

For example, the risk profile of a feature redesign (primarily usability) will look very different from the risk profile of launching a new product in a new market (primarily value, viability). The risk profile will also change over time as you progress through discovery for a particular idea, because you should be mitigating your risk as you go. For example, conducting problem interviews with prospective customers can reduce value risk, while prototype interviews can reduce usability risk.

When prioritizing different items, think of the risk of that product or feature failing. What would be the most likely reason for the failure? How many unknowns are there? Focus on that uncertainty, rather than the desire to get to ‘complete’ as quickly as possible.

A risk mindset clarifies the ‘how much’ question

In risk management, risks are mitigated and managed; rarely can they be totally removed. So it is in product management: you can never be certain how the market will respond to your product before you release it, nor how users will interact with a feature before you put it in their hands. What you can do is think in terms of probabilities — how likely is it that the market will respond positively or negatively to your product? — and dramatically reduce the probability of the negative outcome.

Consider the following table. Each row is a choice for how much time you could spend on discovery work on an idea, and the resulting likelihood of that idea being a success. It’s totally made up and arbitrary, but humor me. Which bet would you take?

You probably have an opinion, even if you’re also screaming out for more information. How about now? How much discovery time would you invest?

How much you need to de-risk something is a function of a number of factors. In addition to the time to implement an idea, there are things like reputational risk, ongoing maintenance, product bloat, and so on. Thinking in terms of risk allows you to consider all those things, beyond a simple “value vs. effort” type formula, and also develop a sense for when you’ll have enough data to make a go/no-go decision.

A risk mindset encourages balance

Many prioritization frameworks describe a way of calculating a “score” by which work can be prioritized, such as ICE (Impact x Confidence / Effort), RICE (add Reach to ICE), or WSJF (Weighted Shortest Job First). These frameworks are nice in the context of perfect information, where these scores can be reliably calculated. But rarely is information perfect, and often we have different data points for different items of work, meaning there is an imbalance in the inputs for these scores for different items. And while models like ICE and RICE incorporate confidence for this reason, you still need to decide which ideas merit discovery work to increase the confidence score.

Early in my career, I worked as a financial auditor (I know — a far cry from product management!) In an audit, the goal is not to comprehensively verify every part of a company’s books, because there aren’t enough hours to make that practical. Instead, auditors use a series of tools and techniques to cover the landscape of possible errors, fraud, and so on:

• Through double-entry accounting, confirming that both sides of the ledger “balance”
• Verifying adherence to a recognized accounting framework and standards
• Spot-checking random items
• Following the paper trail of particular transactions
• Focusing more resources on “material” (i.e. higher value) items
• Interviews with different stakeholders to develop context
• And so on.

An auditor uses different techniques to assess the financial statements and ensure they are ‘true and fair’. Using these different techniques covers a lot more of the range of possibilities and makes it harder to hide fraud than one technique alone, because each technique balances the shortcomings of other techniques. For example, random spot checks mitigate the limitation of simply relying on the balance sheet being in balance (because balancing the books is a rule that is predictable and therefore can be gamed by someone with the necessary skills and access).

Similarly, in product, using a balanced set of techniques provides greater risk mitigation than one technique alone. For example, combining quantitative techniques such as analyzing product usage data (what is happening) with qualitative techniques such as user interviews (why the behavior is happening) gives you insight into where to invest in your product, and also what points of friction your users are experiencing.

When prioritizing, don’t rely on a single tool or score to make your prioritization decisions. Instead, ask yourself whether the idea passes muster from a number of different angles and whether it is supported by different types of evidence. If it does, the idea is likely less risky than alternatives that are dependent on a single insight or data point.

A risk mindset emphasizes judgment

While some of the auditing techniques I described above follow rules, standards, or strict process, others require judgment on the part of the auditor to determine which items to delve further into. In the same way, product decisions require judgment and while process can help, it can never be the sole method of decision-making. When thinking about risk, context is key.

Depending on the stage of your company, its appetite for risk and what kinds of risk it will accept will likely be very different. In early stages, reputational risk may not be much of a concern, but accepting a large amount of financial risk (putting all your eggs in one basket) could be a deathblow. For a large, established company, the reverse may be true.

Similarly, the strategic and market environment plays a part in assessing risk: you may, by necessity, need to accept larger risks or bigger bets if an opportunity arises that is strategically important or that you will miss out on if you don’t act fast. This has certainly been true of companies who have had ‘their moment’ in the context of the trends that have accelerated during the pandemic.

Assessing risk involves judging where the risks are. There’s no ‘template’ in this sense. Ignoring broader shifts in the context you are working in can result in you making decisions that seem right on paper, but fail to make the impact you had hoped for.

Conclusion: product is a risky business

We’re all familiar with the idea that most products and features fail to deliver the value they promised. That means that product development is an inherently risky proposition. Viewing product development through the lens of risk doesn’t mean taking a glass half-empty mindset. Instead, it highlights the areas you need to focus on. It also forces you to consider development not simply in terms of the destination — the finished product — but steps on a journey, with each step being an attempt to reduce the risk of waste or failure. And while thinking in terms of risk doesn’t give you a simple formula to follow, it does provide a useful thinking tool: for any given product decision, you can ask, “what is the biggest risk here? And what can I do to mitigate that risk?”

What do you think? Do you consider risk when assessing your product initiatives? Or do you use some other thinking tool to organize how you lead your team to create great products? I would love to hear from you.