Based on the sheer volume of failed products in the world (read: most of them), it’s probably a safe assumption that product management is really, really hard. Craig McLuckie, who knows a thing or two about building great products (Kubernetes, anyone?), recently detailed the key characteristics of a product manager, including an unswerving connection “to the business, and…an equal level of urgency and commitment to the customer’s needs.”
But even when a product manager and her team nail McLuckie’s tips, products can still fail and regularly do. Why? Well, according to Shreyas Doshi, the first lead product manager at Stripe, those failures often come down to biases. As teams plan, they build all sorts of plans. That’s great, Doshi said, but “For a sufficiently smart & motivated group of individuals, decision-making is less about making brilliant choices, and much more about avoiding bad ones.” How do product teams avoid making bad decisions?
Customer feedback and the problem of myopia
The first step, Doshi noted, is to actively remove bias from the process of getting customer feedback. Customer-centric product teams may have the tendency to do focus groups, customer advisory boards, or other mechanisms that enable them to pitch product ideas to customers, with the intention to build products in which customers show interest (“I definitely need that!”).
The problem, he stressed, is that by focusing a customer’s attention on a product feature/solution, we only learn of their interest in that particular feature, and not how it compares against all of their other, competing priorities. To minimize the chance of running afoul of such “focus bias,” Doshi stressed, “ask[ customers] to stack rank that problem vs. all the other problems they were trying to solve for their business & for their organization. THAT is where the real truth [will] emerge.”
What are signs that a product team has a focus bias? According to Doshi, if product teams find themselves making the following statements, they may be blinded by focus bias:
“They’d love to trial the product, but not this quarter because [reasons].”
“We just need to make it easier to deploy so customers can prioritize its rollout.”
“We need to give customers an incentive to use the product and then they’ll see its value.”
The IKEA effect
Another bias that Doshi highlighted he calls the “IKEA effect,” and it’s essentially the inverse of sunk costs in economics. Economists assume that people shouldn’t consider sunk costs (i.e., what we’ve already spent) when making future decisions, but this is easier said than done. In terms of product management, this plays out when teams try to make an existing product work (“we spent so much time/money building it”), rather than start over based on customer feedback.
As Doshi pointed out, “You’ll encounter the IKEA effect…quite often with products that are stuck in that unfortunate zone of not being a complete failure and not being very successful either.” This makes sense, because while it might be easier to scrap a product that customers clearly hate, it’s tempting to assume that with “just a little more effort” it can be turned into what the customer wants.
Overly aggressive impulses to build
This brings us to what Doshi pointed out is the most common bias of all: The Bias-for-Building bias. In this bias, “We don’t take the time to thoroughly understand the problem, domain, competitors, and other determinants of product success because we feel compelled to be in constant motion. We tell ourselves we must begin building and just iterate based on feedback.” In other words, we rush to market a half-baked “minimum viable product” that turns out to be not viable, and start throwing “IKEA effect” bias at it (the natural successor to bias-for-building) to remedy the problem.
Which, of course, only compounds it.
There are four other biases that Doshi detailed that inhibit great product teams from building great products, but I’ll leave you to dig into his Twitter thread to understand them.
The ultimate key to building better products
We may already fall prey to some (or all) of these biases, but that doesn’t mean we need be hobbled by them. As we strive to be aware of our propensity to blind ourselves with one or more of these biases, then name the problems so our teams will be able to speak of them with common terms, we’ll be in a great position to start changing company culture. This is the ultimate key, and it’s where we can systematically build mechanisms that help our product teams, and our companies, avoid bias and build better products.
Disclosure: I work for AWS, but the views expressed herein are mine and not those of my employer.