5 Mental Models that Help Product Managers Acquire and Retain Users

I’m a big believer in lifelong learning. I read everything I can get my hands on, listen to audiobooks at 2x speed, and rely on products like Blink and Audible to learn even faster. Everyone has the ability to learn faster than they think they can, and increase their daily consumption of information.

To become a learning machine though, you can’t just overload yourself with information. You have to apply critical thinking to what you’ve learned.

One of the most helpful tools I’ve found for this is cultivating an understanding of different mental models.

Professor of digital computing at MIT Jay Forrester defined a mental model as:

The image of the world around us, which we carry in our head, is just a model. Nobody in his head imagines all the world, government or country. He has only selected concepts, and relationships between them, and uses those to represent the real system.

A mental model is a framework that we use to make decisions, explain concepts, or make sense of the world. Understanding mental models helps you increase self-awareness in the cognitive principles behind what you think and why you think them.

For product managers, this practice is especially important. Product managers aren’t developers, marketers, or salespeople. They’re a little bit of each. PMs don’t just have to understand and eliminate their own biases — they have to dig in and understand what makes their users tick.

Below, I’ve included some of the mental models I’ve found most valuable for each stage of growing a product, and how to apply them.

1. The 5 Whys

When you set out to build a product, the most obvious problem isn’t always the real problem you should be solving. Developing a deep understanding of the root problem helps you save time and money before writing code.

The “Five Whys” is a mental model developed by Sakichi Toyoda, the founder of Toyota, for solving this problem. It simply involves asking “Why” five times.

• The problem: The vehicle won’t start
• 1st Why? — The battery is dead.
• 2nd Why? — The alternator is not functioning.
• 3rd Why? — The alternator belt has broken.
• 4th Why? — The alternator belt was well beyond its useful service life and not replaced.
• 5th Why? — The vehicle was not maintained according to the recommended service schedule.

Following the model above, getting to the first “Why” might lead an engineer to conclude that a battery is broken, and to try to fix the battery. Asking “Why” multiple times leads to the conclusion that vehicle maintenance is the root problem — not the battery. This mental model is a powerful way of stripping back your internal biases around what you think the problem is, and what the deeper underlying problem is.

Downtime at FogBugz

Back in 2008, Joel Spolsky and the team at Fog Creek Software, were running a developer task-management tool called FogBugz when suddenly, the site went down.

It turned out that one of the sysadmin’s hadn’t correctly installed a network switch — it worked, until one day, it didn’t. For a company like FogBugz, downtime is deadly. Customers use FogBugz every day to help them do their work. If FogBugz was unreliable, people would stop using it.

To solve this problem, one of the sysadmin’s suggested putting together an internal service licensing agreement (SLA) that defined the percentage of “uptime” to aim towards and hold themselves accountable to. The idea was that once the sysadmin team knew what percentage uptime to aim for, this would be translated into day-to-day practice.

This is a common, instinctual reaction to a problem. When an existing process fails, it’s normal to assume that the solution is more process.

As Joel Spolsky points out in his writeup of the episode, though, the issue with an SLA is the lack of statistical meaningfulness:

Measuring the number of minutes of downtime per year does not predict the number of minutes of downtime you’ll have the next year.

Using the “5 Whys technique,” the team was able to get down to the root challenge:

• Problem: Our link to Peer1 NY went down.
• Why? — Our switch appears to have put the port in a failed state.
• Why? — After some discussion with the Peer1 NOC, we speculate that it was quite possibly caused by an Ethernet speed / duplex mismatch.
• Why? — The switch interface was set to auto-negotiate instead of being manually configured.
• Why? — We were fully aware of problems like this, and have been for many years. But — we do not have a written standard and verification process for production switch configurations.
• Why? — Documentation is often thought of as an aid for when the sysadmin isn’t around, or for other members of the operations team, whereas, it should really be thought of as a checklist.

Ultimately, it wasn’t about guaranteeing 99.999999% reliability — which would have been incredibly costly to configure. The root problem wasn’t a lack of guaranteeing uptime — it was the lack of documentation around how to install a switch in the first place.

2. Inversion Or Working Backwards

“Think forwards and backwards — invert, always invert” — Charlie Munger

Inversion, or working backwards, is a helpful mental model for taking large complicated problems and breaking them down into smaller, easier problems. When you’ve attacked the problem the same way 100 different times, a better approach is often to turn the problem around.

As the vice chairman of Berkshire Hathaway, Charlie Munger, says:

The way complex adaptive systems work and the way mental constructs work is that problems frequently get easier, I’d even say usually are easier to solve, if you turn them around in reverse. In other words, if you want to help India, the question you should ask is not ‘How can I help India?,’ it’s ‘What is doing the worst damage in India? What will automatically do the worst damage, and how do I avoid it?’

Inversion is a mental model that helps you revisit your core assumptions, and find new solutions to hard problems.

Onboarding at SideKick

Brian Balfour and the team at Sidekick, HubSpot’s freemium sales product for email, were facing a churn problem. People would sign-up for Sidekick, and promptly leave after the first week.

To improve retention, the team focused on improving the onboarding experience of the product. They hypothesized that the onboarding experience didn’t teach people how to use Sidekick well enough. Because they didn’t understand how to use Sidekick, they left the app. With the right onboarding experience, the team believed they could solve Sidekick’s churn problem.

They tried…

Decluttering the welcome screen:

Adding sample data to the welcome screen:

…and five additional experiments. Nothing worked. Finally, the team went back to the drawing board. They had to invert the problem, and rethink their assumptions about how to solve it.

As Brian Balfour says:

It wasn’t about improving the landing experience of the product, it was about improving the experience of the product itself. Meaning we were advertising a product about your email on the landing page, we had you install the product within your email, and then your first experience was basically this web page within a web application.

The problem wasn’t that people didn’t understand Sidekick’s product or how it worked. The problem was that people wanted to start using Sidekick faster. To fix retention, the team had to invert the problem and rethink their assumptions about solving it.

Ultimately, what finally worked was removing a welcome screen to Sidekick’s web app. Instead, after installing Sidekick, they were taken straight to their inbox:

3. The Problem Hypothesis

When you’re building or growing a product, you’ll have a lot of great ideas. Taking a rigorous, scientific approach to validating these ideas is how you build something that people actually care about.

The “problem hypothesis” is a mental model for taking your great idea, and reframing it around a problem that can be tested and validated.

For example, if you have an idea for building a product that schedules tweets on social media, your problem hypothesis might be:

People want to share on social media, but they have a problem scheduling tweets individually.

When you come up with a problem hypothesis, you have to be careful to test and analyze data objectively. It’s easy to manipulate the data to tell the story you want to hear — that’s why you need to be rigorous about your hypothesis and how you test it.

The problem of user feedback

When we were doing customer development for KISSmetrics, my web analytics company, we noticed that a common problem that our customers were facing was getting feedback from their customers.

While this wasn’t a problem that was directly related to what we were doing at KISSmetrics, we heard it repeated so often that we thought it might be worth building something around.

But before writing code, we wanted to test our idea and validate it by creating a hypothesis. It was:

Product managers have a problem doing fast/effective/frequent customer research.

To test our hypothesis, we started out by learning more. We wanted to know:

• What are customers doing now?
• What other tools are available?
• Who is involved?
• How frequent / severe is the pain?
• What else are customers complaining about?

We ran around 20 interviews with customers by phone, and three in-person user tests with paper prototypes. We learned that because people had a hard time getting customer research, they weren’t doing customer research. They were using existing survey tools like SurveyMonkey, which made it hard to get rapid, instant feedback. Customer research was a constant pain that needed to be solved.

It wasn’t enough to 100% prove our problem-hypothesis, but this early data was convincing enough that we built an initial product. Within a few months, we had over 1,121 websites using KISSinsights — and it all began with a problem hypothesis.

4. Anchoring Bias

So far, we’ve discussed mental models that help clarify your thinking to build better products. But mental models are also a powerful tool for better understanding your users. “Anchoring” is a good example of a user-focused mental model. Anchoring explains the human tendency to rely heavily on the first piece of information it receives to make subsequent assumptions.

A common example of anchoring effect occurs during negotiations. Say that you’re at an antique market, and see a chair that you like. You ask how much it costs, and the vendor replies “$50.” You counter-offer at $25, the seller counters again at $30, and you buy the chair. The chair may have been worth $25 — but you negotiate around the anchor, or the initial $50 offer. Once an anchor is set, people tend to make decisions around that initial piece of information.

In the context of building a product, understanding how anchoring works is really important. The language and way your users initially encounter your product determines how they’re likely to think about it and use it (or not).

How to acquire 46M users by changing one call-to-action

Over ten years ago, James Currier was developing an online photo product that helped people store their photos on the internet. The problem was that people weren’t biting. Currier was having a hard time acquiring new users as competition in the online photo-sharing site was heating up.

In an interview with Reforge, Currier points out:

We said, ‘You can store your photos here now that you have digital photos,’ and this was triggering people’s protectiveness, says Currier, because the word “store” sparked users’ motivation to defend and collect.

The issue was that the word “store” had an anchor effect on what people thought was possible with the product. Storing led users to think that the product had a limited use-case — backing up and collecting their photos online. In reality, there was a lot you could do with the photo product.

By talking to their users, and testing and iterating on the sign-up call-to-action, Currier ran into a more powerful anchor term that would tap into a different motivation for users to try the product. Instead of telling users they could “store photos,” they changed the call-to-action to “share your photos.”

“Sharing” anchored the product within a completely different context: instead of just passively storing their photos, new users anchored their understanding of the product with the ability to show their photos off to others. Rather than trying to motivate users to store their photos online, “share your photos” tapped into the more powerful motivation of passing photos around to friends and loved ones.

5. Loss Aversion

Loss aversion is a psychological principle that states that people prefer avoiding losses to making an equivalent gain. We’d rather not lose $5 than gain $5.

To measure your own aversion to loss, ask yourself, “How much would I need to gain to balance an equal chance to lose $100?”

According to behavioral psychologist Daniel Kahneman, for most people the answer is $200–2x the amount lost. Psychologically, we respond emotionally to decisions around winning and losing. The fear of losing typically outweighs the prospect of winning.

In building products, loss aversion is a double-edged sword. Loss aversion can help you retain users by helping create a sense of progress in your app. But it can also create friction toward adopting your product in the first place.

How understanding loss helped Amazon reduce friction

When you’re launching a new product, loss aversion can be one of the biggest sources of friction for acquiring users. New products typically replace old ones, which means that switching products incur some type of loss.

This was exactly the case at Amazon Music. Amazon Music is Amazon’s music streaming product, similar to Spotify or Apple Music. When Amazon Music first launched in 2013, some of Amazon’s customers had already purchased the equivalent of hundreds of dollars of CDs through Amazon. Seeing the option to purchase digital music triggered their aversion to loss. Switching to digital music would have meant either losing all the money they’d invested in CDs, or expending a lot of time and effort to rip CDs one by one.

So the product team at Amazon launched “AutoRip” a product that gave people digital versions of CDs that they had already purchased. That helped reduce friction to adopting the Amazon Music’s product. As Kintan Brahbhatt, one of the product leaders behind Amazon Music, explains, “Customers were thrilled, and we eliminated two causes of anxiety — decisions and loss — with one product launch.”

To arrive at insights like these, Brahbhatt recommends that product managers “Make a list of all decisions a customer needs to make in order to complete a task in your product. Then question each one.”

In the case of Amazon Music, you might think that the decision to switch to digital music was obvious — customers don’t have to deal with importing CDs, can play music across their devices, and more. But by digging deeper and trying to understand the mental model of loss aversion behind their customers’ decision-making, the team at Amazon was able to reduce friction toward adopting the new product.

More Mental Models

When you’re dealing with product or user problems, you’re likely going to be overloaded with information. Not all of it is going to be helpful. Mental models help you sort through and cut to the heart of the problem. Then you can develop solutions that get at the deeper issues and prevent these problems from happening again.

Here are some more mental models that help you increase your awareness of your own thinking and solve smarter:

• Mental Models I Find Repeatedly Useful — A list of 181+ mental models
• A Dozen Things I’ve Learned About Mental Models from Charlie Munger — A curated list from Tren Griffin of Microsoft
• Influence: The Psychology of Persuasion — A canonical book by Dr. Robert Cialdini

Recognizing and shaping the way you think is one of the most immediate ways to improve as a learning machine. As your company develops, utilizing mental models helps you to continue to hone your problem solving skills.

You should sign up for my free email newsletter, Product Habits — I share the best Product development and business content each week.