We're all risk managers... (Part 1)

When I started getting into backcountry skiing, I did what a lot of beginners do: enroll in an avalanche safety course. It's a great course and I highly recommend it. But if you're not familiar with the topic, you might be surprised to find out that the Level 1 course is ~20% how to perform a rescue and ~80% how to assess and manage risk.

Now that I've had some time to reflect on that course, I've realized that many of the central lessons are applicable outside of winter travel. In particular, to my own profession of product management.

Exposure and Consequences

Risk Management is an entire field of study, with many concepts that I am glossing over. But you can get pretty far with a basic understanding of Exposure and Consequences. You may know it as Probability and Impact. Or Likelihood and Severity. It's the same idea applied to different industries. When evaluating risk, you should consider (1) the chances of a negative event occurring and (2) the results of that event occurring.

When traveling over snow and ice, we collect a ton of data to give us a sense of how likely an avalanche could be. But we also avoid situations where an avalanche would have a particularly bad outcome. I hope I'm never in an avalanche. But if I ever am, I'd rather it be a small one that buries me up to my chest than a big one that buries me 15 ft under. And I'd rather it run out into a meadow than into a forest or over a cliff. Wise decision-makers always consider both sides of risk.

In the early stages of a new company or a new product, the probability of failure is very high. Our early hypotheses are almost always wrong, at least in some way. As Steve Blank says, "a hypothesis is just a fancy word for a guess." So how do we manage this risk? We reduce the consequences. And there are a ton of resources on how to do this well. From Steve's Lean Launchpad course, to Eric Ries' book Lean Startup, to Jake Knapp's Design Sprint - we put a small amount of time and money to work with great intensity, to make our way from guesses to evidence. For each hypothesis proven false, we lose a few person-days or person-weeks. And we save months of design, engineering, sales, and marketing effort.

Team

Ok, so this a well-tread cliche. But forming your team is probably the single most important choice you will make.

In the classroom, we reviewed the 2012 Tunnel Creek avalanche, later made famous by John Branch's feature in the NY Times. It's a particularly confounding case on the surface, as the skiers and snowboarders involved were very experienced and knew the terrain well. In reality, that may have ended up working against them. A number of different factors led to the disaster, but the one I want to highlight here: even the riders that didn't feel good about the situation didn't stop the group or raise their concerns, at least not outside their close friends. They either assumed everyone else knew what they were doing or feared the social awkwardness of being the wet blanket.

There's a clear parallel with technology teams. Unlike mountaineering, it's rarely a life or death scenario. But thanks to the research of Google's People Ops, we know that some of the best indicators of team success are psychological safety, dependability, and goal alignment. In other words, can you speak your mind without fear of embarrassment? Can you rely on your teammates to put the team first? And are you working towards the same goal(s)?

So next time you have a lingering doubt or a stupid question, raise your hand or speak up. Some of the time it will be a stupid question. No getting around that. But sometimes you'll give the team new perspective. Or it'll turn out that the whole room was wondering the same thing.

Similarly, I've tried to rephrase my questions when I'm presenting. Instead of "Any questions?" I ask "What information are we missing?" And instead of "Any feedback?" I ask "Which of my assumptions are wrong?"

Planning

One of the hardest lessons to abide by is agreeing to a general goal with multiple options before heading out for the day. It's all too easy to text your friends the night before and decide that we're going to ski this face of that peak. Of course, options are always nice if the weather changes or the parking lot is overflowing. But more importantly, having an alternate or three gives your brain an easier way to decide that the path you're on is too risky. When you woke up early, and you've been hiking all morning, and you're light on oxygen, and you're looking downslope at your only option, then it can really feel like you have no choice but to send it.

Similarly, too often I go into a design review or a customer feedback session with one solution. After all, this is later in the customer development process. We have much clearer understanding of the customer and their needs. And it's much easier to test one design or one solution. Is this a good solution or not? What should be changed? Of course, there are many benefits to devising at least three solutions to each problem.

• It forces you to work through the details of an idea you may have unfairly dismissed out of hand.

• It lets you make comparisons and highlight pros/cons.

• You might end up with a solution that combines the best of each alternative.

These are fairly obvious, and why most teams have a brainstorming phase of their process. It's a quick way to generate lots of ideas.

Less obvious is the risk if you don't take the time to do this. Like the mountaineer who won't turn back, you become increasingly attached to the solution. Maybe you're willing to make small adjustments here and there based on feedback, but you won't be swayed from the main thrust of the solution. One thing I am certain of: the farther you go, the harder it is to turn back.