Product Management is Risk Management

It sounds strange, but only at first glance

Product management is a broad and varied discipline. Among the less obvious aspects of that discipline is the fact that product management is, at its heart, risk management.

At first, this assertion might seem crazy. Risk management sounds like legacy industries, big infrastructure projects executed in a stage-gate process, and lots of box-ticking exercises. That is pretty much the antipode of software product development, where you progress iteratively, accepting even to proverbially “move fast and break things”.

At a closer look, though, the end goal of developing software iteratively and shipping quickly is precisely to reduce risks. Product development is inherently and fundamentally a risky endeavor. The risks are just very different than in these legacy industries. If you build a bridge over a river, you know that the bridge will be able to fulfill its purpose of allowing people to cross over the river. The risks are often more about safety, quality, timely completion of the project, cost, and so on.

In the development of new software products, the risks are more fundamental: you can’t even be certain whether the end product will fulfill its purpose, whether it will solve the customer problems it set out to solve. Fortunately, software is more malleable than physical infrastructure: you can deliver new versions of a software product to customers with hardly any disruption. This means that the way in which risks are managed in the development of software products looks very different to the risk management processes used in legacy industries, but in the end, it is still about effectively and efficiently reducing risks.

This management and reduction of risk is at the heart of the job of a product manager. Very early startups often don’t have any product managers — not because there isn’t any risk, but precisely because the product risk is so fundamental that it needs to be borne and owned by the founders. At such an early stage, the risk is: “will anyone even want this product?”

Over time, as it becomes clearer that there is a market for the product, the risks get less fundamental but more manifold. Thus, the role of the product manager is often introduced. The product manager has several important hats to wear, and one of them is that of taking a strategic mission, iteratively identifying the biggest risks and managing them. Of course, product managers never achieve this alone, they work together with their teams, but in an environment that didn’t have the same level of risks, the product manager job wouldn’t be required (a project manager or even a delivery team without a “manager” type role would suffice).

The primary job of a product manager isn’t to get the product out to customers as quickly as possible (or “on time, on budget, on scope”). The primary job is to manage and reduce the risks inherent to the development of software products.

The risks inherent to software product development come in many forms. The most important ones are Marty Cagan’s four big risks:

• Value risk: Is it valuable enough to users and customers that they are willing to buy / use the product?
• Usability risk: Do our users understand how to use the product?
• Feasibility risk: Can we build the product (from a technical perspective)?
• Viability risk: Is this product viable from a business perspective (i.e., can we make money from it)?

There are also additional risks that might need separate management. For example, there might be legal, repetitional, or ethical risks (even though they could be subsumed under viability risks). There are also risks involved in the development and delivery process of the product itself — some related to technical feasibility, but also to organizational setup and processes. This is especially pertinent the more of a physical component a software-enabled product has. Lastly, there is the risk of increased complexity: Any time something is added to a product, it increases the complexity of the overall system, which makes all future changes more costly. This is a particularly tricky risk to manage, since the costs of that risk only become evident further down the road.

It is worth repeating that none of these risks are the responsibility of the product manager alone. To the contrary: usability risks will most often be owned by product designers, and feasibility risks by engineers. It is, however, the product manager’s responsibility to maintain a holistic view of the risks and address the biggest ones first. As an example, it’s not worth running many iterations of usability tests of an interface for a product that’s not technically feasible, for example — the biggest risk, in this case, is the feasibility risk, which should therefore be addressed first.

This fundamental insight is the driving force behind the Lean Startup’s Build — Measure — Learn cycle and the associated concept of the Minimum Viable Product. Often misunderstood, neither of these concepts mean that you need to bring a product to market that you are ashamed of and that’s held together by duct tape. These concepts mean identifying the biggest risks in the form of the assumptions with the biggest uncertainty, then validating those assumptions, and moving on to the next biggest risk.

If you are a product manager and want to improve your craft, start by assessing what risks your current projects are facing, and how you might most effectively reduce those risks. If the biggest risks are about value, ask yourself if there is a test or study that you could run to validate that whatever you are building is value. If the biggest risks are about feasibility, you might want to work with your engineers to build a proof of concept. If it is about usability, it’s time to prototype at various levels of fidelity and run usability tests. For viability risks, it often means collaborating with stakeholders across the business to ensure the risks can be mitigated.

In any case, focusing on the biggest risks first means you can make sure to focus your energy and the energy of your team on the most critical questions, and not wasting precious time on answering questions that will later turn out to be irrelevant.

I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.