Why product managers are asleep at the wheel
Risky business - Part 1
Whatever we do, there are risks associated with it. The question is, how aware are we that risks exist, and how much risk are we willing to take? I want to dive deeper into something I have observed: Product managers often (have to) take a lot of risks, and in many cases, aren't even aware of those risks. In this article, I dive into how humans generally treat risk and how product teams and the PMs within them are different.
This is part 1 of a two part blog post, thanks for being an early reader, the second part will be published on Tuesday next week. Subscribe to the newsletter to get it in your inbox and be one of the first to read it!
Excursion into Human Psychology
There are various famous psychological experiments that show that humans are generally risk-averse. In most cases, they become entirely irrational once there is some kind of perceived risk. To get a feeling for how people act in various situations, let’s first explore two theories in psychology on risk-taking in humans.
Prospect Theory (PT)
One of the most accepted theories about risk taking is the Prospect Theory.
The Prospect Theory (PDF version of the Scientific study) was developed by Daniel Kahneman and Amos Tversky in 1979. It was one of the reasons Daniel received a Nobel Prize in economics in 2002.
The theory demonstrates (and proves in controlled studies) how individuals assess their loss and gain perspectives in an asymmetric manner.
Let's explain this by considering 2 scenarios:
100% chance to gain $450 or a game of chances: (50% → $1000, 50% → $0)
For this scenario the mathematically better option is going for the 50% chance to gain $1000 (Expected value of $500 vs. the guaranteed 450$).
Yet the study shows that people opt for the risk averse scenario of a 100% chance to gain $450.
100% chance to lose $500 or a game of chances: (50% → -$1100, 50% → -$0)
For Scenario 2, the mathematically better option is going for the 100% chance to lose $500 (vs. the expected value of -$550 with the 50% chance to lose $1100).
The study shows that in this scenario, people opt for the risk seeking (yet irrational) route and head towards the 50% chance to lose $1100.
What this study has shown in simple terms is that humans are not willing to gamble a sure win for the potential of a mathematically better gain. Conversely, humans are not willing to accept a sure loss if they can gamble on the chance of not losing anything.
The theory continues to explain how this becomes even more extreme when facing more complex percentages and how humans are overvaluing low probability outcomes (e.g., 60% chance to win $1000, 39% chance to win $500, 1% chance to win $0, humans are treating the 1% as if it were 5%+).
The Uncertainty Effect
Now comes what I believe is one of the most interesting examples. A study done on what they called “the uncertainty effect”.
The Uncertainty Effect (PDF version of the Scientific study)
When asked how much people are willing to pay for a restricted $50 gift card, the average is $26.
When asked how much people are willing to pay for a lottery ticket that wins either $50 or $100 of the same restricted gift card, the average goes down to $16.
That's crazy, right? People are willing to pay almost twice for $50 if the $50 is fixed and there is no chance to also win $100. (With the risk to state the obvious: They asked different people not the same people, and then computed the averages from that)
Yet the outcome is completely irrational. But the pure fact of uncertainty being present decreases the perceived value on average (where the lottery ticket's actual value is that of a gift card worth $75).
But what we can see again is that risk makes humans go down the irrational route.
Product managers are taking too much risks
“The purpose of product discovery is to address these critical risks: Will the customer buy this, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Does this solution work for our business? (Business viability risk)”
―
Marty Cagan,
Most product managers would agree that they are responsible for managing the risk for any given product delivery. Yet, when taking a closer look at product teams, they are often so busy building that they completely forget to de-risk what is being built. (This is what some call feature teams vs. empowered product teams) Sooner than later, this becomes a vicious cycle, and I would go as far as to say that most product managers are basically asleep at the wheel right now. When asked to write down the risks for their current project, many would have to start digging. (Which, in return, means they have no awareness of the risks, but are already investing probably a quarter-long implementation cycle to get something shipped)
Here is where this becomes contradictory to how this article started. Humans are generally risk-averse, shouldn't this apply to product managers and the projects they work on as well? Why are they diving into all this risk head-first without being worried? Are they worried but simply can’t change the situation ? Is there nothing that can be done to make this a better situation for everyone?
3 manifestations of why product managers are not acting as they should
Before going into the steps one can take to get out of the mess, I want to shine a light on what I believe are 3 of the major reasons why someone finds themselves in a feature team vs. an empowered product team.
The Roadmap
The roadmap is a common tool in product management. It can provide customers and colleagues with expectations, but it can also drive teams to prioritize output over outcome, especially when deadlines are set for specific features. This approach can lead to sacrifices, which can be disastrous. Here is what I mean (in probably quite drastic examples):
Build something less usable, who cares we need to meet the deadline.
Build a version with everything that makes it valuable to the customers stripped away, who cares we need to meet the deadline.
Take away the only opportunity to monetize the product, who cares we need to meet the deadline.
I think you get it by now, and I strongly believe that this is the most common gateways to becoming a well oiled feature factory.
The Fear of Failing
More often than not, product managers have to convince a whole lot of stakeholders before an idea is elevated to the status of a potential product or feature to be worked on. After running around for weeks parading all the great benefits for a product, taking the step back once the team gets going on it and looking at all the risks can be scary. When done well, the risks uncovered can very much be the reasons the product will fail in the future, and they might be exactly the arguments the stakeholders that pushed back need to stop the project. Now the product manager is in a dilemma, make the risks transparent and risk the project being killed top-down, or keep it low and pray for them to never materialize. Spoiler alert: Option 2 is chosen quite often. The worst part is that if a company's culture allows the killing of projects because someone with an opposing view does not like a risk, the incentive will always be to not surface all the risks or opt for whatever has almost no risk. (And usually almost no upside)
The (informal) Product Committee
The third major reason I see is something that often creeps into organizations. It's the committees, either formal or informal, within organizations that need to be brought on board to make any product decision. This usually becomes a problem because suddenly the product manager's job is not to discover what is most valuable, feasible, usable, and viable, but also to find out what can be successfully agreed upon with the committee. Often, this happens when a risk was not successfully mitigated in a prior project, and from then on, it needs the "approval/ok/involvement/..." of person A. Next time, something else may not be perfect, and from then on, it needs "..." from person B. Sooner than later, a product committee is formed, and the product manager can't simply uncover and mitigate a risk. Instead, once they uncover something, every step needs to be agreed upon with a large group of people. This is not only a terrible way to make decisions, but also a sure way to incentivize a “I’d rather just put my head down and deliver” mentality.
How to stop gambling
“The first step towards solving a problem, is admitting that you have a problem.”
―
Unknown
Realizing that you have been unaware of risks is the first step towards solving them. What is difficult to change is the black and white idea of being in a company that works with empowered product teams or a feature factory. But regardless of whether you are the CPO or an Associate Product Manager, I am convinced you can take steps towards a less risky future.
What about my roadmap ?
Roadmaps don’t have to be the perfect way to become a feature factory. They can be a fabulous tool to transparently show what the questions are that a product team tries to answer. What problems they want to solve. What outcomes they want to achieve. In simple words; Roadmaps can focus on problems to solve or outcomes to reach not just features to deliver. If your organization insists on feature outlooks, you can speak broadly about the problem space you aim to address. This avoids committing to a specific feature by a particular date, reducing the likelihood of prioritizing the deadline, overlooking significant risks and becoming a well running feature factory.
If I had to advocate to move away from a feature focused roadmap, I would recommend the following approach:
Identify and write down all possible risks of the current roadmap item you work on (e.g., Customers might not use a feature on the roadmap, it can not be monetized down the line, etc.)
Document potential mitigation strategies for these risks
Acknowledge the risks that cannot be mitigated, but ensure their transparency
Share the document with all the stakeholders that need to be convinced
By doing this, those pushing for delivery might start to understand what they are potentially risking. Then, make a case for conducting some experimentation towards risk mitigation strategies. See if people are willing to forego the deadline in exchange for a product that truly meets the business needs (revenue, retention, etc.). More quickly than you can imagine, you might become empowered to reach goals instead of delivering whatever has been written on the roadmap.
What about my fear of failing ?
I am not the product I manage! I am not the product I manage! I am not the product I manage! Say it once more with me: I AM NOT THE PRODUCT I MANAGE!
I get it, it can feel scary to admit that something you have been pushing so hard for actually has some risks of failure, but believe me, sweeping those risks under the rug won’t help you. You will have to face them at one point, and showing transparently what could go wrong will maybe even impress the people you have been persuading to fund the project. (A big plus is that you can now actually work on mitigating those risks, which will drastically improve the chance of success)
Secondly, as mentioned: You are not the product you manage. A feature implementation fails, users are not using it, revenue is not increasing, metrics are not moving? You are fine. Get up and understand which risk you underestimated, or if you ignored those risks in the first place. Next time, experiment more and build less, and you will see more successful deployments!
What about my product committee ?
To be frank, this will be the hardest to change from within. Once an organization starts to believe that a committee is needed to safeguard the organization from risk and that this is a good replacement for risk-aware product management, it will be tough to fix without ruffling some feathers. With that being said, lets ruffle some feathers:
I would go about this similarly to the roadmap, mainly writing down the risks and what to do about them. Next up, start tackling those risks and see how the "committee" reacts to it. Now it heavily depends on how your company operates, but in many cases, people will see that you are on top of things, and you might be able to change the process through leading by example. If that does not work and the committee interferes once they even hear the word risk it might be best to escalate this and involve someone like your CPO/VP Product to step in, I would recommend having a conversation with them and explaining why the current situation is more harmful than good. (Focus on the risks the organization faces and what that would mean to the most important metrics you are looking at, not about how much it sucks that the committee is watching every one of your step - because yes it does suck!).
Where to get stated ?
Thanks for reading early, I truly appreciate you being here. Yet this is a 2 part blog post - drop your email and subscribe for free so you will get the second part into your email inbox!