Risk-driven analysis (2/3): how I determine the levels of risk
May 26, 2023
This is part 2 of the 3-part series on the risk-driven analysis approach I cultivate at Elements.cloud. In this article, I explore the drivers behind different levels of risk.
Risk-driven analysis : recap
As I articulated in my 1st article, risk-driven analysis is a method of qualifying the risk of an idea based on how well evidenced and understood is the end user problem, job to be done and user journey, and then leveraging that risk to determine how much further validation is needed before you feel confident in building a solution.
There is no ‘no risk’ scenario
I want to start by stating that there is no scenario where an idea does not have some risk. For example, I know I will only truly validate a product/feature once the target users have actually adopted it (widely and repeatedly).
That is why the essential tool in the product manager’s toolkit is the Minimal Viable Product (smallest product/feature you can ship to validate your concept quickly). However, as David J Bland and Alex Osterwalder explained in their book Testing Business Ideas, an actual software MVP is still one of the most expensive experiments you can run (you can read up on other types of experiments in their book or in David J Bland’s article). Therefore, our team strives to proceed with software MVPs once the idea’s risk has been driven down to ‘low’.
Now, you might think that if the MVP proves to be successful (ends up being adopted by many users and repeatedly so), we have validated our value hypotheses, and we can proceed with iterative improvements. However, while this might mean that ideas about future iterations of that product/feature will not be highly risky anymore, the reality is that we still might get it catastrophically wrong (e.g. Google apps’ new logos).
How do we define risk?
In short, defining a risk level of an idea is always a judgment call. It’s not a precise mathematical formula (at least not to us). However, we do have a set of guidelines to help guide our judgments:
As you can see, three dimensions keep reappearing throughout those guidelines, so let me explain what I mean by each one.
Understanding the problem
Most ideas raised by customers or internal stakeholders (and a fair share of our ideas) come in the form of a feature request. We know we are dealing with a high-risk idea if we cannot fathom what value it is supposed to achieve or the problem it is supposed to address. In some situations, after deliberation, we may discover that we could apply the headline of the idea to multiple different issues. The fact that we don’t know which problem we are supposed to solve exactly makes the idea a high-risk in our book.
Example:
Let’s imagine that the sales team lets you know that based on their interactions with the prospects and customers, we should build a car (feature/product request). Without a clear point of reference, we might ask, “what do the customers/prospects mean when they say ‘a car’ exactly?” The answer: a transportation vehicle.
Now, we might have questions, like:
- What is wrong with the horse?
- What is wrong with the train?
- What is wrong with the carriage?
And assuming we did answer all of those questions and indeed concluded that a car is fundamentally better in many situations, we still have an issue: which problem is the car supposed to address:
- Not having a reliable means of personal transportation (family car)
- Not being able to meet the demand for our products/services (car for transporting cargo)
- Not being able to manage the crops effectively (farm vehicles)
Therefore, if the sales team would ask us just for a car, we would have to classify it as a high-risk idea.
Understanding the job to be done
The next big challenge is understanding the job to be done (for a good resource on this concept, I recommend Jobs to Be Done: A Roadmap for Customer-Centered Innovation). To build a proper solution, we need to understand the task, who is doing it, when it is performed, and what its function (is the purpose functional, social or emotional). On top of that, we need to understand the driver/context within which the job is performed. This would include dimensions such as attitudes, background, and circumstances.
Example:
Continuing with the story, let’s imagine that we have validated that the problem worth solving with the car is not having a reliable means of personal transportation. But that is not enough.
We can see it on the streets today that everybody has a different car. And even if we were to slice up the car market into price ranges (based on the price of the car), we would still find much divergence. That is because different cars serve different functions. For example, some cars symbolise luxury (a social job of communicating status), while some are marketed as environment-friendly (a personal need and potentially a social job).
Then, depending on the geographical context, customers would require a different car for personal transportation. For example, someone living in the French Alps may need a 4-wheel drive with a more robust engine, while someone living in the busy city centre would need something smaller to make it easier to find a parking space.
Understanding the user journey
Finally, once we understand both the underlying problem and the job to be done, we have one final obstacle to overcome — understanding how implementing an idea will affect the current user journey. The user journey is simply a sequence of experiences that a customer goes through while interacting with our product.
A new feature or product never exists in isolation. It coexists with all other existing features. Therefore how it fits the current interface, whether it replaces or displaces an existing functionality, how it affects performance, intuitiveness, and the choices the users face is extremely important to get right. A great idea executed poorly is no better than doing nothing at all.
Example:
Continuing with the car analogy, there is no better example of a product where customer journey was at the forefront of the team’s mind than Tesla’s electric vehicles. An electric car with a good range, fantastic acceleration, unique design and aura of eco-friendliness checks many boxes for target customers. But long charging times and lack of a proper/wide-spread charging infrastructure (essentially the user journey of day-to-day use) could have killed the product or considerably delayed the advent of electric vehicles.
Investing in a charging network and adding seemingly silly (but extremely delightful) features such as racing games or Netflix to the car addressed the most painful aspects of the user journey. One could even argue that these improvements to the user journey have further strengthened the brand and the job to be done (at least its social aspect) and thus making Tesla cars genuinely unique in the market.
What's next?
A methodology I use to de-risk ideas is called Total Story Visualization. It is a powerful and syncretic technique that combines several other methods into single, logical approach. First, you need to become familiar with UPN diagramming notation. Within TSV there is also a very specific approach to understanding and capturing jobs to be done.
You can learn the entire framework with practical examples to hone your skill and understanding in my masterclass in Total Story Visualization:
