Little Guide to Risk Thinking for Product People

Considering “risk” can be a curious yet effective way to plan. Being aware of the risks involved with any endeavor helps us acknowledge and address the uncertainties involved with our efforts. Product management can even be thought of as a risk-mitigating discipline, aiming to reduce the potential downsides associated with developing and delivering products.

Photo by Dave Photoz on Unsplash.

Often though, product managers and other makers in tech companies aren’t introduced to a structured way of thinking about “risk.” In absence of such structure, we instinctually think of our fears of something bad happening rather than strategizing about dynamics of the actual something. (We may also get steamrolled by legal, security, and privacy teams with whom we should collaborate.)

It’s difficult to make good product and business decisions based solely on expressions of fear. Worse, we may ignore risk entirely or implicitly accept a different kind of risk, that of loud personalities and highest-paid persons’ opinions (HiPPOs) governing our decisions, rather than data, reason, and understanding what bets are really worth taking.

So let’s investigate a little framework to help us deploy “risk” productively, as a way to think, decide, and act amidst uncertainty.

What Is Risk?

For this post, a “risk” is a specific, undesirable, potential outcome of doing pretty much anything.

In effect, such outcomes could:

  1. directly hinder our success (e.g. not reaching sales goals, not entering a new market, preventing launching new features, rendering business lines moot),
  2. pose undue costs (e.g. slowing down product development, forcing higher expenditures), or
  3. in extreme cases, present legal consequences (e.g. rendering our business illegal or leading to individual jail time).

Whatever they may be, we won’t like them, and they have minor to significant impact.

Outside Our Control

Characteristically, risks lie outside of our sphere of control but often within our sphere of influence. That is, if we could control and anticipate such events, we’d probably just do something about them in the first place.

But the problems that risk thinking addresses are those happenstances we may face but inherently cannot control ourselves, a key reason why risks can carry so much emotional weight. And it’s also why they often surface in collaborative settings in peculiar ways, which we’ll talk about.

Even in this light, all’s not lost! Even though we can’t directly prevent an undesirable outcome, we can still take action, particularly given a healthy assessment of risk, something that will moves us past a sense of impending doom and towards something more objective and quantifiable.

Part 0 – Reviewing The Context (aka The Situation)

A risk needs a context, a la “risk associated with doing X.” That X can be any number of things:

Such contexts usually have goals, aspirations, desired outcomes, or projects. But the key point is we’re going to model the risks associated with these contexts so we can increase our chances of success, whatever that may mean.

…stay calm, cool, and collected!

In that sense, it’s worth documenting our aspirations and what success looks like, i.e. what outcomes we’re aiming to accomplish. Then we enter into a precarious mindset that imagines all the things that could go wrong outside of our control. This is where risk takes the stage.

But as my favorite math professor would say, “Then you stay calm, cool, and collected!”

Part 1 – How to State a Risk

The common ways to discuss risk either talking about a single risk, which represents a single undesirable outcome, or overall “riskiness,” which describes an overall sense of the uncertainty we face in a given situation or context.

It turns out that overall riskiness is difficult to quantify and action on. We usually consider how we feel about dangerous activities like going to war or riding a rocket to the moon, but inevitably, describing overall riskiness naturally breaks down into describing individual risks anyway. So let’s investigate the former, how to state a single risk.

We’ve already noted a risk represents a single specific, potential, negative outcome. But to be an effective planning tool, a risk statement should include more than even a matter-of-fact description of such an outcome. The best risk descriptions facilitate our understanding the event, assessing how it compares to other risks, and cluing us in to the actions we can take to mitigate it.

In this framework, a complete risk statement has four components, all of which are required. Without the set, you don’t have a description of a risk, you have something else.

  1. First, state the event. What might happen that poses a concern? Be specific.
  2. Next, state the impact the event may have should it occur. Ideally, this is quantified and evidence-based, but it can have qualitative aspects as well.
  3. Then, articulate how likely this event is to occur. Counterintuitively, this piece is the most critical. If you don’t have this, you don’t have a proper risk statement.
  4. Finally, state how we know this may occur, its impact, and its likelihood.

And that’s it. Let’s break this down further.

A – State the Event: What specifically might happen?

It might be obvious and intuitive, but the first step is to state the event. This could mean anything from getting into an accident on a roadtrip to incurring assembly line mistakes while manufacturing medical devices.

Because humans are so good at conjuring potential futures, some bad habits can seep into our thinking.

One such habit is not being specific to the extent we need. Our intuitions may lead us to say something like the following:

But in structured risk conversations, we need more, much more. Risk isn’t just about exploring the possibilities or imagining our implicit fears, we need a dry, almost scientific specificity to reach the explicit, actionable, and objective territory we want. Better statements might be:

Another bad habit (again probably due to most of us not being introduced to a consistent risk framework) is stopping with the event and thinking we’ve stated a full risk. This happens a lot, but we’ll address that below.

B – What’s the potential impact?

The thought of the potential impact of an undesirable event tends to spark fear, and it’s also what well intentioned risk-conscious people may tend to focus on.

The prominent bad habit here again is specificity. To the extent we are able, we should estimate or calculate the downside impact like this:

Making these estimates can be tedious and tenuous, but they’re necessary to help weigh the different impacts of different events. Another bad habit is assuming every event is equally impactful as all others.

Another bad habit is assuming every event is equally impactful as all others.

These impacts can be delays, lost revenues, fines, loss of reputation, customer churn, loss of trust in a vendor or partner, or pretty much anything that matters to the team. And if we can’t determine a specific quantified range, an order-of-magnitude still helps.

Remember, while this section values a single occurrence, the larger framework encourages a holistic approach. We’ll soon compile all such occurrences so we can weigh them in comparison to each other consistently; so knowing a particular occurrence might cost a firm one day of development time versus six months indicates a material difference.

C – How likely is it to happen?

Now this is where we get into real “risk” territory. In addition to estimated impact, we need to consider that not all events are equally likely to occur. And said somewhat flippantly, just because we can imagine a negative event doesn’t mean it’s as important as all other imaginings. Nor does imagining an event mean it will happen at all. These kinds of assumptions are yet another bad habit.

So for a given event, assess (ideally calculate) how likely it is to happen.

Casual assessments can be as simple as “unlikely,” “likely,” or “highly likely.” Formal assessments could be probabilities, like “on average, once every 50 years” or “on average, one out of every thousand patient procedures.”

One bad habit is thinking every risk is just as likely as every other.

I recommend avoiding absolutes like “always” and “never,” unless they truly describe impossibilities worth mentioning.

It’s also best to pick one scale of measurement (casual or quantitative) and maintain consistency across multiple risks, since ideally we want to compare likelihoods of various events. If a factory assembly error occurs 1 out of 1000 widgets versus a different error that occurs 10 out of 1000 widgets, we may want to give more attention to the latter (particularly if the impact also justifies doing so).

Out-of-Band Events

However, there are also events so unlikely, even though still possible, that they’re truly not worth including in our assessments, particularly a category I call “out-of-band” events.

Out-of-band events may sound like oddly specific versions of “the sky is falling.” They aren’t impossible, but they aren’t directly related to the situation or decision we’re facing. A blunt example would be while we’re planning a road trip, for which we may reasonably note the risk of getting a flat tire, but an out-of-band event would be the risk of being hit by a meteorite on the way.

Similar out-of-band events:

D – How do we know?

A risk can nominally be described as impact and likelihood, and doing so puts you ahead of the game. But documenting how we’ve come to these assessment is more important than it may first seem.

This counterbalances our intuitions, potential bias, and assumptions. It forces us to confront why we’ve brought forth a particular assertion and helps us assess collaborative dynamics (highest paid person’s opinion effect) versus more scientific ones.

Again, the parts are simple, but all required: What specifically might happen? What’s the potential impact? How likely is it to happen? And how do we know? Together, they can be quite impactful.

But that’s not even the whole framework; that’s just how to state a single risk! Here’s the meat of it.

Part 2 – Inherent Risk

A complete risk statement, relevant to its context, articulated with the framework above, but without any mitigations or controls yet considered, are by definition inherent to the situation we’re facing. That is, it’s intrinsically tied to the path ahead, and we couldn’t avoid thinking about such a downside if we want to be responsible.

The compilation of all such risks we call “inherent risk.”

If we’ve been comprehensive in our risk statements, excluding out-of-band risks and formulating likelihood and impact from real evidence, then to the best of our knowledge, this represents the starting point of our risk model.

Inherent risk lays out the underlying problem to solve. By surveying inherent risk, we can get a sense of the potential downsides of our venture.

If a significant number of impacts are high, If likelihoods are high,

Part 3 – Risk Controls

Risk controls (or just “controls”) are actions we can take and investments we can make, by definition within our sphere of control, that (1) reduce the likelihood of risks occurring, (2) reduce the impacts of risk should they occur, or (3) both.

For example:

We don’t get controls for free, however. Each risk control incurs a cost (and associated opportunity cost!) to put in place. And notice how each control mentions a mitigation specifically for impact or likelihood (or both).

Opportunity costs often get overlooked. Assuming we have a finite budget, opportunity costs are those things we could otherwise invest our budgets. Opportunity costs are particularly important for risk controls, since what we’re really doing is adding additional scope to our organization we wouldn’t have normally considered without such modeling.

If we’re developing a physical product, our instinct leads us to consider the costs of building, not mitigating the likelihood and impact of manufacturing mistakes. We tend to think optimistically, imagining the ideal path forward, fearing the negative, rather than considering investing in processes and actions that may not be needed, but if they are, would be super valuable, depending on the nature of the risk.

Part 4 – Residual Risk

After sets of appropriate controls have been applied in our modeling, the resulting riskiness is called “residual risk.”

This is the collective likelihood and impact after we’ve considered how mitigations for these costly events (or at least, all the controls we can afford). Remember, mitigations have both a cost and opportunity cost, and costs can be resources like human attention, capital, operational expenditures, and implementation time.

It’s useful to model the possible residual risk regardless of cost, however, so you know the upper bound of your model. When compared with the inherent risk, you have the total range of risk you should be concerned with.

At this step, you haven’t really decided which controls to implement though, even if it seems obvious. This decision comes in the next step, and it’s key to wait because the risk question can often turn into a cost question, and it very well may be worth spending more to reduce risk.

Part 5 – Risk Tolerance

So finally, after all this setup, we ask the critical question. Given a set of controls, is the residual risk is within our “risk tolerance?"

The risk tolerance is essentially how much downside we’re willing to face for the context, and this varies based on the decider and the organization the risk profile impacts.

Some organizations are more tolerant because they’re in an inherently risky field and thus need a higher risk tolerance to play the game.

Other organizations have resources that could cover the downside even without additional controls, which may be reasonable when, say, such controls take too long to implement and thus impact other temporal concerns like time-to-market. (Even though this pattern doesn’t necessarily have a good track record. See the Challenger Disaster as a tragic example.)

The critical question is whether the residual risk (determined by a set of controls) is within our organization’s risk tolerance.

So while there is tolerance on one side for downside impact and potential cost, the other side of the equation are constraints around how much the controls themselves will cost us.

Part 6 – BONUS: Operationalize!

Having the framework is great, but it has to be operationalized to be useful. And while a one-off assessment is great, if it’s done on a Tuesday afternoon then forgotten after Taco Tuesday Happy Hour, and it doesn’t affect the decision-making or scope of our teams, then it’s useless.

Risk frameworks like this one have to become organizational habits that hold parties accountable, track the efficacy of the risk decisions made, and adjust to changing conditions.

So someone needs to first assess by collaboratively and comprehensively documenting the inherent risk, potential controls, residual risk, and organizational risk tolerance. And each of these may involve some politics and stakeholder management; the CEO may have a different idea of risk tolerance than the legal team or the CFO.

Once we have the initial assessment, decisions need to be made about which controls to implement. Budgets need to be balanced with risk tolerance, and teams should be informed of those decisions and project or program managers assigned to implement the controls.

Then someone needs to run the risk program, reviewing on a regular bases the risk framework, updating the assessment of likelihood and impact, the status of each control, measure their effectiveness, and update the list of risks should new ones arise or others become obsolete.

If the strategic situation changes, like a new law is passed that affects our product, we need to review the inherent risk again, and any changes will naturally flow to ideating on controls and assessing the residual risk.

Pitfalls

Someone states a negative event but without a likelihood, impact, or how they know, and the group believes a decision was just made to stop a course of action. Without interrogating a potential downside, we can at worst end up making implicit decisions to not do something potentially valuable. If we assume everything is uncertain, then every project becomes a bet.

Risk controls without associated costs and opportunity costs.

Politics.

Risk Thinking

In a way, risk-based planning, or risk thinking, is interesting because it depends less on accuracy whether you’re right or not, such as whether you have an accurate prophecy about future customer behavior or business health. It’s about likelihood of something happening and the impact that may have.

When we say something is “risky,” we might be thinking of our overall sense of trepidation about situation, however fuzzy it may be. But when we say, “Whoa, this is too risky,” what we really mean is something like, “There’s a collection of risks that present a profile that’s worth our concerted attention.” Or even better, “There are risks that collectively represent significant loss and a high likelihood of occurring.”

Quick Reference

  1. A complete risk statement consists of four parts:
    1. What is the negative event?
    2. What would be the impact to us should it occur? This can be delays, monetary costs, damage to reputation, customer churn, legal repercussions, etc.
    3. What is the likelihood of it actually occurring? Pick a scale (casual or quantitative) and be consistent.
    4. How do we know the above? Experience? Educated guesses? Actual data?
  2. Inherent Risk
    1. Compile all the relevant risk statements, each using the four-part framework above, without considering any mitigations or controls.
    2. Avoid out-of-band risks that aren’t relevant to the context.
  3. Risk Controls
    1. List all the actions (i.e. controls) we could take to reduce the impact and/or likelihood of each event occurring.
    2. List the costs of implementing each control.
  4. Residual Risk
    1. Model applying the controls; reassess the impact and likelihood of all the risks.
    2. I recommend modeling a range of controls, starting with all the best controls (highest quality with no budget constraints) to one or more scenarios constrained by an actual budget.
  5. Risk Tolerance
    1. Critical question: Is the residual risk is within the tolerance of the organization?
    2. Determining the right sense of “risk tolerance” may involve politics and stakeholder management.
    3. Can we absorb the modeled impacts and still remain in a healthy state?
    4. Can we accept the modeled likelihoods?
    5. Decide the controls to implement within our budget.
  6. Operationalize!
    1. Rinse and repeat the above on a regular basis as a risk program.
    2. Ensure the controls are implemented by the appropriate teams.
    3. Measure the results.