Heuristics For Addressing Product Management Bias — Learning from Human Factors in Avalanche…
Heuristics For Addressing Product Management Bias — Learning from Human Factors in Avalanche Incidents
Heuristics are rules of thumb, and here’s why they are so effective at managing bias — and some practical examples for Product Managers lifted from the world of alpinism.
Skiing Telluride Backcountry
Understanding Bias
Unconscious bias is a processing shortcut the brain uses to save mental processing when evaluating it’s environment. As your brain creates consciousness it goes through a series of assumptions that makes your world much easier to understand. It is fundamental to us interacting with our physical world — but it creeps into our intellectual one as well. Especially when working in groups.
In some situations certain outcomes are clearly undesirable, but they still result despite knowledgable participants. In fact bias can increase dramatically when an “expert” is involved. That’s why many high stakes activities like alpinism have already established a useful set of best practices for evaluating bias. We’ll be looking at how alpinist have tried to deal with this while still pursuing perilous achievements.
Two Types of Catastrophic Failure
Statistically there are two types of user groups when it comes to avalanche deaths. The first is inexperienced groups that are unaware of the avalanche conditions and make uniformed decisions. They don’t have the appropriate equipment, and are not prepared or aware of the implications of venturing into “the backcountry”. Despite youthful enthusiasm they end up over their heads and not able to survive.
The other group is the habitual user. They are a regular in the terrain they travel, aware of the conditions and capitalizing on what they believe to be optimal ski, sledding or climbing conditions. They are taking a miscalculated risk, usually due to outside pressures.
While this may be a morbid example it has been instrumental in the design of a global avalanche awareness and safety system — a phenomena that takes place on all 7 continents. The contents of this post are based on the academic paper titled Human Factors in Avalanche Incidents but are equally relevant to software teams.
Familiarity
While I am proponent of teams practicing their craft, releasing to production often and avoiding “big launches” the downside to this is complacency. Prior experience can lead teams to take chances they wouldn’t take with a lower comfort level. While this can be advantageous from an experimentation standpoint it can also lead to blindspots for common failures like memory leaks, slowness, and other reliability aspects of your product. The solution — black box monitors that are truly objective and charted over long periods are indispensable to Product Managers working with engineering teams. See the SRE book.
Acceptance
“The desire to be noticed and accepted has a powerful influence on human behavior. There are many possible variations on this theme, including peer group acceptance and gender acceptance.” This is a direct quote from the paper cited above, but could easily applied to 10x Engineers and Rockstars. It’s even worse if there are romantic dynamics on your team (hey, it happens). If your culture rewards these behaviors or encourages interoffice hookups watch out! This is really a leadership problem, but if you are a PM in a culture like this the bus is coming for you.
Consistency
In a software context this is probably better described as the sunk cost fallacy. This is a sneaky one in Products because it can lead to death by a thousand cuts and there is no clear answer or safeguard. That said, for prolonged initiatives I find that a classic 2x2 of complexity and value is worth checking in on — that is are you getting the value you want for a given complexity? Is the complexity inline with your original assumptions? Reducing the question can simplify the answer.
The Expert Halo
Following a leader is a very human trait which helps simplify the decision making process for groups. When teams are inexperienced this is especially pronounced — even decisions that can seem democratic in nature are susceptible to influence by contributors with a long history on the Product or with the organization. Much of the time the expert may be correct, but Product Managers need to avoid placing themselves in this role or forcing decisions onto “experts” especially when external factors could skew the decision. Take stock of who the “expert” is on your team and make it a routine to question their judgement.
Social Facilitation
As teams grow, the pressure to “perform” is innate — this predates even the agricultural revolution back to our hunter gatherer ancestors and even applies among social primates. Some of this is healthy as some people perform under pressure but if you find yourself trying to impress (or more importantly not let down) a key executive or stakeholder the Product Manager should step in and ensure that the decisions are rational for you users. Remember you are producing the Product for them, not the executive in the end.
Scarcity
“Desperate times lead to desperate measures”, “any port in any storm” — these are not healthy phrases for Product Teams but they are pragmatic ones for Product Managers. In fact most good PMs are often focused on the achieving the metric you’re product doesn’t yet have and that’s valid. That said organizations can act irrationally when a lack of funding, talent, or time is involved. This is a complicated set of constraints, but that’s all they are. I find it to be a helpful thought experiment to imagine a scenario without constraints — what would you do differently?
Practice Rescue Scenarios (Divesting)
It’s naive for experienced practitioners to assume that mistakes won’t happen. You will fall into these traps — your conditioned to. That’s why alpine teams practice rescue scenarios, because in the backcountry you have to self rescue. The same is true in Product, but the approach is different. While many teams are becoming practiced at releasing new features most do not have divestment strategies — how long do you support products that are being replaced? When can you remove a valuable integration? These are not easy questions to answer but they are rescues for teams facing scarcity.
Get Educated!
If you are a Product Manager I am really enjoying the materials put out by John Cutler and Modern Agile. If you are in Denver and a backcountry skier checkout some of the classes from the non profit Friends of Berthoud Pass.