Facing Risks: A Practical Guide for Product Managers
Risky business - Part 2
This is the second part of the risky business blog series. I will show you a clear path on how to uncovers and mitigate risks in software projects. (Also check out the first part where I have gone deep into why product managers are taking too much risk in the first place: https://blog.pp.partners/p/risky-business-part-1 )
If you follow this practical guide, the outcome will be a document that transparently shows which risks are to be faced and how these risks can be mitigated. Get started right away with this Notion template: Link to Notion template
How to get started ?
The first step in understanding the potential risks of future development is to identify the types of risks. I firmly believe in not reinventing the wheel, and much work has already been done on how to categorize risks for software products effectively. In this guide, I will provide practical advice on testing for and mitigating the four big risks that I first encountered when reading Inspired by Marty Cagan.
value risk (whether customers will buy it or users will choose to use it)
usability risk (whether users can figure out how to use it)
feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
business viability risk (whether this solution also works for the various aspects of our business)
Marty Cagan - The 4 big risks
How to identify risks
The 4 big risks we want to identify for each product are: Value, Usability, Feasibility, and Business Viability. Let's now dive into each of them and explore how we can best identify if risks within these categories exist.
Value Risk
Value risk is the threat of your product not being valuable to the customer. This risk category is usually the one that product managers show the most attention to.
To identify risks of value, you need to ask yourself:
Will the customer buy this ?
Will the customer choose to use this?
Will the customer come back after using it?
Usability Risk
Usability risk tackle to the possibility of your product not being user-friendly.
To identify risks of usability, you need to ask yourself:
Will the user achieve their goal?
Can the user figure out how to use it?
Will it need explaining so the user understands it?
Feasibility Risk
Feasibility risk is the risk of not being able to build the product.
To identify feasibility risks, you need to ask yourself:
Do we have the knowledge to build it?
Will building this have an impact on other systems?
Can we build it within a certain budget or timeframe?
Business Viability Risk
Business viability risk refers to the risk of your product not being sustainable for your business.
To identify business viability risks, you need to ask yourself:
Does this fit with my business model?
Does it need to comply with any laws or regulations?
Will this affect other teams or departments?
What to do in practice ?
What you should do now in practice is sit down and understand for each of these 4 categories if any risks exist or not. Try to ask yourself these questions for each of the categories and list all risks that you can identify. The next step is to understand which risks need mitigation and which risks can be left alone.
Which risks you should mitigate
The next step is to understand which risks should be mitigated and which can be ignored. To do this, I first assess the priority of these risks. I like to evaluate them on two axes:
Probability
How likely is it that a risks comes true. There could always be the risk that a meteor strikes every customer that opens your product, the chance of that happening is simply almost zero (except you build software for astronauts, but even then I would say the risk can be ignored). In the end mitigating risks that are very improbable will take away a lot of the most valuable resource you have: your time.
Severity
Next up, we've got to tackle the question of severity. We need to figure out how damaging it would be if a risk were to actually occur. This is a similar to the probability of a risk, but here we're focusing on the potential damages. Just like it's a waste of your time to worry about risks that are hardly likely to happen, it's equally pointless to lose sleep over risks that wouldn't cause significant damage even if they did occur.
Priority
Lastly, I like to compute a priority based on how I scored probability and severity. I believe not overcomplicating this is more important than making sure it is 100% correct. This is what I do:
Score Probability in 3 steps: Low, Medium, High
Score Severity in 3 steps: Low, Medium, High
Compute a priority from the other 2 scores.
Low + Anything → Not Critical
Medium + Medium → Medium
High + Medium → High
High + High → Critical
Lastly, you need to decide for which priorities you want to create mitigation strategies and for which you do not. I usually only mitigate risks that are either high or critical. For some very important new developments, it might be worth mitigating medium risks as well.
Mitigating Risks
After identifying the risks associated with your undertaking, the next step is to determine how to address these risks. Numerous techniques can be used for risk mitigation. Let's get into more detail to explore what can be done for each type of risk.
Value Risk
Value risks primarily revolve around whether customers will use your product. Mitigating these risks involves understanding the core problem of the customer and ensuring the proposed solution addresses it. This can be achieved through:
Conducting qualitative interviews with potential customers to identify their problems
Developing a minimum viable product (MVP) to validate your product idea before spending months to make it perfect
Usability Risk
Usability risks pertain to situations where customers cannot achieve their goals or find the process overly complex. To mitigate these risks, ensure that customers can understand the solution without extensive training. Examples include:
Developing one or multiple design prototypes for testing with customers
Measuring time-to-success in initial versions to gauge how quickly customers reach their goals
Feasibility Risk
Feasibility risks typically involve either the inability to deliver a product with the current team at all, or at a much higher cost (in terms of time) than anticipated. To test for feasibility, the engineering team should be involved in designing the solution from day one. Here are some examples of how to mitigate feasibility risk:
Have engineering propose the solution, instead of just delivering tickets
Build a prototype that addresses the core problem to understand technical feasibility
Business Viability Risk
Business viability is most often associated with problems surfaced by departments outside of product development (Legal, Marketing, Sales, etc.) or risks regarding the business model (e.g., the new product is sold differently than other products). Here are some examples to mitigate business viability risks:
Engage with departments outside of product development (Legal, Marketing, Sales, etc.) early in the process to identify potential business viability risks.
Assess the business model to ensure the new product aligns with it.
Risks that can’t be mitigated
While it's essential to mitigate risks, it's equally important to mention that not all risks can be mitigated. Sometimes it is not possible to find a clear strategy on how to mitigate risks. However, it will still be very helpful to understand which risks you need to monitor while prototyping, designing, or shipping. These risks should be transparently communicated to both the team working on the product and other stakeholders.
Conclusion
In conclusion, it's important to remember that risk is an inherent part of product management. By identifying, mitigating, and communicating risks, you can make informed decisions and create products that add value to your customers and your business.
Tackle your risks now and get started with my free notion template: Link to Notion template