Stop me fellow Product Manager if you’ve never heard some version of this line –
Well, I’d never do {BEHAVIOR}, and so our customers would never do {BEHAVIOR}, and therefore this is the wrong decision
Expectancy Bias is one of the key biases that Product Managers must fight in themselves, and break down in any organization. If it’s allowed to rot, then your products will be built based on opinions, anecdotes, and biased intuition. If you can treat it early and often, then your products will be built based on data, direct customer feedback, and developed intuition.
To show why, let’s start with an example…
Let’s say you’re building a PaaS, and all of your engineers graduated top 10% in their class, spend their weekends in open source projects, and love to debate lint formats.
If you fall into our expectancy bias trap, then your developers expect the world to look like them (which many of your early adopters will confirm), and won’t see value in building tools for other developer types (who are disregarded for a variety of reasons).
Why?
Your Rock Star Developer has the opinion that all developers should write their own SDKs on the raw REST API as opposed to the data that many developers are getting stuck in your Getting Started flow and not getting any further.
He has anecdotes from his friends that the REST API is easy to use, and therefore doesn’t review the direct customer feedback asking for SDKs in specific frameworks.
And he therefore builds a biased intuition to the group who fits his expectation of the outcome as opposed to developing intuition with and relationships across a wider swath of developers who better represent the market of the business you’re trying to build.
What can you do about it?
Here’s the pattern I’ve found works best to fight expectancy bias – first make the business decision to do, and then center every product conversation that you have around customer empathy that you develop.
The question of SDKs for some developers versus raw APIs for other developers actually needs to start somewhere else – “Do we want Fred – a lovely developer from Wilmington, NC who needs a .NET SDK as a customer?”
The business decision is whether Fred, who “needs our platform to scale his system from size N to N^2, is like D thousand other developers in this market, in a market whose total value to our business would be $X million”, is worth investing in?
At this point, don’t mix what it takes to be successful with Fred as a customer with should we even consider Fred as a customer. The question at this point is only – should we even consider this?
The answers should come from business goals, company priorities, and product strategy.
If the answer is yes (and this is always a business decision before it’s a product decision), then roll up your sleeves, and start building empathy for Fred internally.
- Bring Fred and 3 other Freds into the office to meet with your engineers
- Do a hack-a-thon with them, and watch how they use your tools as they are, and where they need help
- Do unscaleable things like help them build things so you can see how they talk about problems they’re solving, why they need to solve them, and how they expect a solution to work for them.
- Make sure your Engineer, Designer, PMM is in every single one of these interactions
Leave little room for opinions, anecdotes, and biased intuition to determine the product solution. Instead, even if in small quantities, create – with your building, designing, and marketing partners – data, direct customer feedback, and intuition. Then use those tools to understand How you’re going to make Fred a successful customer (not only the Fred who came in, but the D thousand Freds who made the business decision worth investing in).
Just like flossing, you’ll find pushing biases out is one of those things where even getting into some kind of rhythm works out much better for the hygiene of your product than hoping you can do it all the day before a critical appointment or product kickoff.
And your gums will thank you for it too.
Leave a Reply