Thread by @shreyas

Product failure is expensive.

And look around, it’s common.

Why do products fail?

Is it becos we can't build the product?
No

Is it becos we launched it N weeks late?
Almost never

So what is it?

The 7 Biases of Product teams, a very visual thread:

It all started when I asked myself this question in the year 2016:

This thread is my answer to that question.

And it has to do with the biases of product teams when building products.

3 parts to this thread:

To answer that, let’s start with the Inputs—Outputs—Outcomes framework. Within the scope of this framework, our challenge is simple, though not easy.

Our challenge is:
How do we collect the right Inputs, convert them to the right Outputs, so we can get to the right Outcomes?

And THAT is where Decisions come in.

Mind you, we make countless decisions while building, enhancing and marketing our products.

The quality of those Decisions is ultimately what determines the impact that our product makes.

That’s why I like to say—you do not rise to the level of your plan. It’s easy to make a great-looking plan—you fall to the level of your decision-making.

Similarly:

Annual planning is useful, but the decisions you make while creating your product strategy will determine your long-term success more than your annual plan.

Lastly:

So, if you show me 10 teams with similar ability and ask me which one will produce more wins over the long term?

I’ll tell you that it’s the team that makes the most effective decisions.

We can all appreciate what the person on the left is saying about making effective decisions.

That's all well and good, but what the person to the right is saying is equally important. And that is: to avoid making bad choices.

Let's let Charlie Munger drive this point home.

For a sufficiently smart & motivated group of individuals, decision-making is less about making brilliant choices, and much more about avoiding bad ones.

And THAT is why we need to study the biases that stymie us as product people

Let's start with a product story.

Once upon a time, a team has a new product idea.

The team is very customer-driven & they talk to customers about their product hypothesis.

Customers sound very excited, so Andy & team get the mandate to build out version 1 of the product.

The team works hard, executes almost flawlessly on v1 and launches it in just 6 months.

Andy now goes back to the customers who had expressed interest in the product early on: "the product is ready for deployment".
And then he waits.
And he waits some more.
And then some more.

Unfortunately, even 6 months after its initial launch, barely any customer adoption.

It’s now time for a product review with the exec team.

At the review, Andy directs attention towards the positives.

Here’s what we’ve learned:
Our MVP isn’t sufficient.
We need to make it easier to adopt.
We need features X, Y, and Z

Kris, the CPO, gives the go-ahead.

The team takes 6 more months to build features X, Y, and Z.

Adoption is still not nearly where it needs to be. Flat.

Time for another product review.

Andy, still very customer-centric, says:
“We know from talking to customers that we have the right product. We just need to improve our Go-To-Market strategy & execution”

Kris & Jo discuss ideas to improve GTM approach: bundling, re-org the Sales team, pricing, etc.

They go ahead and make the changes on the GTM front. Another year goes by.

Adoption is STILL flat.

So finally, at the next product review, almost 3 years after work began, a decision is made:

It’s time to sunset this product.

Now, at this point:

Learnings are captured and shared widely in the org

"We haven't failed, we have learned”

Of course, Edison’s lightbulb quote is repeated several times

“I haven’t failed, I’ve just found 10,000 ways that won’t work”

So… what really happened here?

Now clearly, there can be many possible causes for product failure.

But in this case, the main observation is a simple one:

This product should not have been built in the first place.

When Andy talked to customers about the specific problem of customer support costs, they naturally “focused” on that problem.

And with that Focus on a specific problem, they excluded other, more important problems they were facing.

That is why these customers could never find the time or resources to actually adopt & deploy the product when it was ready.

Here’s what Andy should have done instead:

After talking to each customer about the problem of support costs, he should have asked them 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 could have emerged.

This Customer Problems Stack Rank (CPSR) acts as a great test of the TRUE priority of the customer problem & the product solution you’re discussing.

Anyway, back to our story, there are at least 3 biases that got in the way of Andy, Kris, Jo and team here.

The first one being: The Focusing Illusion, first described by Daniel Kahneman.

While Kahneman was prolly talking about everyday life,
the Focusing Illusion applies to products too. It's one of the biases I see quite often. It’s common because it’s largely invisible.

Companies that think of themselves as customer-driven are especially susceptible to it.

Here are some ways this bias can manifest in team discussions.

I want you to note that, no single one of these is by itself a definitive sign of this bias, but I suggest keeping your eyes and ears open when these things are said repeatedly by you or your team.

The second bias that Andy, and especially Kris, fell prey to is the IKEA Effect for products.

It comes from the observation that something we’ve built together with our own hands is more valuable to us than if we had to purchase exactly the same item pre-assembled.

You’ll encounter the IKEA effect for products quite often with products that are stuck in that unfortunate zone of not being a complete failure and not being very successful either.

What’s interesting about the IKEA effect is that it makes us less attentive to our customers’ actual needs.

Instead of being rational, we try to rationalize.

For our next bias, it's time for another story, a short one

Over here, the Engineering Manager is keen to get the eng team started with s/w development for a new project

The problem is that the PM isn’t yet ready with the requirements. But is also feeling super-guilty about it.

So what does our hardworking PM do? She spends the weekend completing the PRD.

Has to defer more customer & competitive research to v2. Promises herself she'll "fix this" in v2.

Sadly, we all know how such stories of “doing better for v2” end—they rarely have a happy ending.

This is the most common bias I see, especially on high-energy teams & ambitious startups. We can’t stand the idea of taking a couple more weeks to get the product spec or experience right upfront & we end up building something sub-optimal. And the IKEA Effect kicks in after that.

The Bias-for-Building Fallacy is most common in orgs that worship speed. That's fine, but if you go speedily in the wrong direction, you will end up in the wrong place. That’s why teams should value velocity much more than speed: velocity being a combo of speed & direction.

I thought this is a perfect illustration of our next bias – it’s inspired by a scene from the TV show “I Love Lucy”.

With the Execution Orientation Fallacy we are so focused on execution that we craft flawed product strategies and make suboptimal product decisions because we base these decisions on what we know we can easily execute today.

This one is common in product cultures where shipping something—anything—is lauded & rewarded.

When I talk to PM leaders & startup CEOs, it comes up all the time. They want their teams to think bigger, not be fazed by current limitations. They want their ppl to have High Agency.

Now, on to our next bias. This one’s named after Abraham Maslow, who needs no introduction.

One relatively little known aspect of his legacy is called Maslow’s Hammer: if the only tool you have is a hammer, you will treat everything as if it is a nail.

Consistency, process, data are often used as hammers at companies.

Now, data isn't bad, process isn't bad.

The main point is that our decisions must first be informed by the context, not by a tool, a process, or a best practice that may have worked for us in another context.

We often encounter situations where ANOTHER company’s product is a fiasco.

And when look at such a situations, we might ask ourselves:
What was the product team thinking?

How did they miss something so big, so harmful & obvious?

And the answer is that such teams are likely affected by the next bias, Russian Roulette for products.

In it, we don’t account enough for scenarios that could, under certain conditions, lead to a catastrophic outcome for our product or a PR nightmare for our company.

Russian Roulette for products is especially common in companies where moving fast & breaking things is viewed as a virtue. It's also common in companies where "following orders" is expected & rewarded.

Pre-mortems are a good antidote for Russian Roulette for products.

And lastly, the Authority Approval Bias, where we devise products and plans based on what’s going to be easier to get us approval or confirm the pre-existing beliefs of an executive.

We aim for a “successful product review meeting” at the expense of a “successful product”.

This is the easiest to understand & explain becos most of us have vividly seen this at some point in our career

Whether it’s aligning with the CEO’s pet project to get funding, or team members not bringing up important facts, concerns & ideas with the fear of triggering an exec.

So there you have it.

You now know what I’ve observed across many companies of all sizes over the past 15 years and what took me the last 4 years of introspection, inquiry, and research to fully understand.

In this last part, we’ll take a look at the 3 main ways that we can combat these biases as product people and as leaders within a product organization.

As with most things in life, we need to start with Self Awareness. Recognize that these biases are real & each of us susceptible to them. If we sense ourselves falling prey to one of them, that doesn't mean we are stupid—that recognition is the key that unlocks greater wisdom.

Second, name it to tame it.

Make your teams more aware of these biases, by name.

Add these names to your team's shared vocabulary so you can create mutual awareness and accountability while ensuring psychological safety for everyone.

It’s much easier and safer for people to be able say that “let's be careful of the IKEA effect here” than to say that “we aren't thinking straight about our priorities”.

THAT is the power of a shared vocabulary—it helps us see reality and talk about it objectively.

And as they say “The team that sees reality best, wins”.

Last but not the least, we must remember that lasting org-wide change cannot come through surface level treatment.

That’s why I love this quote from Taylor Swift:

That’s why the best long-term solution is culture change. And the ultimate onus for avoiding these traps is on PM/Engineering/Design leaders at the company.

If our product decisions will make or break our company, doesn’t it make sense to have core values and operating principles that counteract these product biases
so we can make better product decisions?

So friends, I’ll leave you with the most important part of this thread: a view of how each of these biases can be counteracted with an operating principle you can establish.

You can do this at the level of a single team, a single org, or the entire company, based on your scope.

To counteract the Focusing Illusion for products, we need Deep Customer Empathy.

We need to really understand their biggest problems and work towards solving those big problems.

To counteract the IKEA Effect for products, we need a culture of rigorous thinking, or reasoning from first principles.

To fight the Bias-for-Building fallacy, we need to recognize that sheer Speed doesn’t mean much unless it’s in the right direction. That is why Velocity is what really matters.

The antidote for the Execution Orientation Fallacy is to cultivate high ambition and high agency—to seek what's impactful not just what's convenient, to find a way to get what you want, without waiting for conditions to be perfect or otherwise blaming the circumstances.

To counteract Maslow’s Hammer, we need to recognize that Context comes first.

The same tool can either help us or harm us, and the way we decide is with an appreciation of our current context.

To avoid getting killed in a game of Russian Roulette for products is to understand that Preventing Catastrophe is better than having to do Heroics to save the day afterwards.

And lastly, leaders should counteract the Authority Approval bias by fostering a culture of Constructive Dissonance—which is about going after the right answer, and not to just try to prove ourselves right.

Note that this need not be one-size-fits all. You likely don’t need each of these operating principles.

That’s where context is important. Identify which biases your teams are most susceptible to, and adopt the corresponding operating principles accordingly.

And with that, I hope that this thread is helpful when you're scoping a project next week, when you are making major prioritization decisions for annual planning, and when you’re devising a new product strategy next year.

But perhaps even more importantly, I hope that our shared journey today will help you build happier & more capable product teams and more satisfied customers.

And for that, I wish you all the best.

Thank you very much for your time.

❤️

Back to the top of this thread:

Additional references👇🏾

This thread is an updated version (with more stories & solutions) of my original product biases thread in July 2020. Check out the bottom of that thread for tons of additional links & other related threads that might interest you:

I recently gave 2 talks on this topic of product biases. Audience feedback was encouraging. Combined NPS from these talks was 90. Main suggestion from the audience was to make the talk longer (it was ~21 min long). If there's interest, I'll post the video when it's available.

"The team that sees reality best, wins" comes from the A+ book "15 Commitments of Conscious Leadership" by @ConsciousLG

I first heard about "Constructive Dissonance" from Hamilton Helmer on the @twentyminutevc podcast by @HarryStebbings (7:18 mark)

More:

A good book to understand biases & anti-patterns of software teams.

amazon.com/Adrenaline-Jun…

"Are Your Lights On?" and "Peopleware" are two other books that can help us combat biases within teams and better see reality.

On High Agency (which is referenced a few times above)

Much of my advice around combating product biases can be boiled down to this: "don't be too smart"

I recently heard that on @InvestLikeBest, in an interview with @mwseibel.

The whole interview is superb and I recommend checking it out.
podcasts.apple.com/us/podcast/inv…

My opinion on advice that's often blindly accepted as "truth" by product teams and even some executives & founders e.g., "the best teams always hit their launch dates", "must make product mistakes to learn", "product-market fit always takes time"....

Some people think that we shouldn't talk about the negative stuff (i.e. biases) and just focus on the positive (i.e. advice on what to do, not on what not to do). Here's why I think that's wrong (check out/bookmark the linked article from @farnamstreet)

We should use the power of asking the right questions to make better product decisions

Use Eigenquestions by @shishirmehrotra as a tool for better product decision-making, especially for the highly strategic make-or-break decisions:

Don't underestimate the power of WAYRTTD in helping create more rigor

When building B2B products, remember this:

If your product can consistently
A) Prevent the buyer from getting fired, or
B) Help the buyer get promoted, or
C) Very directly & clearly earn revenue
you might be on to something big.

Related:

Many middle-managers and some large company execs fall prey to Maslow's Hammer and forget what their real job is.

The difference between good PMs and great PMs when it comes to understanding customers:

As a founder/CEO, you need really good managers to be your agents for helping avoid these biases as your company scales

Metrics can be used both as a tool for rigorous decisions and as a harmful hammer. Here's a thread on how I tend to think about product metrics:

Check out this video based on the content in this thread: