Skip to main content

On Mental Models for Great Product Managers

A problem comes up and you—a PM—think that you know how to deal with it. You throw on your usual sauce and step back. You do the same for the next problem, and the next. But the thing is—you're not getting the results you want. Your shortcuts are actually cutting important corners.

What you're doing here is relying on a mental model. Mental models are frameworks for making decisions. Humans have lots of mental models for navigating the world—they determine how we make sense of things and how we make decisions. But when you're building and scaling a product, you need to carefully select your mental models to make sure you're incorporating the most important factors into your decisions.

Product managers have to navigate an unpredictable variety of problems all the time. You work at the intersection of many different aspects of a company: product design, user experience, technical feasibility, and business concerns.

Product Manager Intersection Source: Intercom

Instead of falling back on the easier or most familiar way to approach a problem, PMs need a toolbox of mental models so that you can apply critical thinking to all of the information you are thrown.

Here's how you can start building your toolbox and developing the skills to tackle each unique problem as it comes.

Tweet: 6 Essential Mental Models for #Product Managers

Why mental models are a PM's most important tool

Product managers are jugglers within SaaS companies. You have to handle a ton of moving parts:

  • You need to make decisions about what changes to make to a product, often based on incomplete information
  • You need to prioritize tasks and to-dos, even when everything seems like it's on fire
  • You need to communicate decisions and outcomes to different people with different priorities on different teams

To handle these moving parts, you can't go on autopilot and apply that one thing that worked really well once to every problem that comes up.

Instead, mental models provide ways to approach problems with new perspectives and break solutions down into actionable steps. And they're not static—as they become part of your workflow, the models are shaped by your experiences and become even more useful and relevant.

If you are aware of the models and images that are guiding your decisions, you can work on improving them and understand why you make certain decisions. Then, you can start to make decisions that are formed by the most important and the most relevant factors.

Below, we've researched mental models that the top SaaS companies and product people swear by. We've picked the top six for you to put into practice and cultivate on your team—and start making more effective decisions.

1. Inversion

It feels like the hundredth time this quarter that you've asked your team: How can we acquire more users? You're asking the same question and getting the same answers, over and over again.

Instead, flip the problem on its head. Ask the opposite question and figure out what you should not be doing.

This breaks your repetitive thought loops. By considering what would cause things to go wrong—instead of what would cause them to go right—you may start to identify areas of your process that are leading to these kinds of negative outcomes.

Inversion can be incredibly useful because it plays upon the psychological principle of loss aversion. In general, people prefer avoiding losses to making an equivalent gain. When you ask yourself “How can we acquire fewer users and turn users away?” you create a more painful scenario. To avoid this outcome at all costs, you find new ways of looking at the problem.

Putting this into practice is a rhetorical exercise. First, identify the problems that you and your team keep bumping up against. Then, flip them and ask the opposite questions. For example, imagine that you work on an app for a product that helps companies monitor their social media presence.

Inverted Question

Finally, brainstorm the decisions or events that would lead to these worst-case scenarios, and plan how to avoid them. Avoiding these losses can spark entirely new, and sometimes, more productive, ways to approach the original problem.

2. Causal loops

Your team is torn. Your product designers want to remove elements from your product's dashboard for a cleaner UI, but your sales team wants to keep them in because the robust dashboard is a huge selling point.

To understand the multi-spoked impact of your decisions, build causal loops. These are visual maps that identify positive and negative correlations.

Tweet: To understand the multi-spoked impact of your #product decisions, build #causal loops

Thinking about the positive and negative correlations between events helps prevent you from being blind-sided by unintended consequences. This mental model can also help you explain and justify your decisions to different teams, who might not directly see the benefits of certain decisions.

For example, imagine that you're prioritizing tasks for your team: adding features, improving UX design, improving product speed, and fixing bugs. You evaluate each on whether the time you spend on it will directly add or detract from user acquisition and current user happiness.

Causal Loops

While new features would be a great selling point for new customers, they might at first frustrate current customers who have to relearn parts of the product. Meanwhile improving speed and fixing bugs will make current customers happy, but it's not a really sexy selling point for acquiring new users. However, improving product design can attract new users and improve the experience of current users. Depending on what you want to prioritize from a business standpoint, you might bump up improving design on your to-do list.

Most decisions that you'll make as a product manager are going to affect nearly all teams within your company. But they won't affect each team the same way—so it's your job to navigate which changes are worth making.

3. The five whys

Sometimes the problem that you see is not the problem that you should address. If you really want to dig to the heart of a problem, ask “why” five times.

This mental model was developed by Sakichi Toyoda, founder of Toyota. He saw every problem as an opportunity for learning and improvement and encouraged his team to explore the root causes of problems by asking why something was happening without any preconceptions about the reasons behind it.

These deeper problems—that emerge after you ask five whys—often involve systematic issues, UX confusion, and misalignment within the team.

In practice, asking five whys just requires patience and follow-through. For example, say you've just seen a user churn from your grocery delivery app because the food they got wasn't fresh.

Five Whys

By asking this series of questions, it's clear that the real problem is with hiring and team growth, not with product freshness. By finding ways to scale the team at the same rate as the business, you'd be able to address the root of this issue and prevent it from happening again.

Asking why five times helps you avoid wasting time on “band-aid” solutions that don't address the real cause of the problem. If you skimp on this, you'll continue running around putting out fires—creating more work for yourself—without ever really improving the quality of your product or the user experience.

4. Jobs to be done

Whenever your user thinks about improving herself or her work process, she has a job that needs to be completed. She needs to hire some tool to do that job—and if you're lucky, that tool will be your product.

The Jobs To Be Done mental model, developed by a Harvard Business Professor Clayton Christensen, says that one of the most effective ways to improve a product is to understand the job the user is trying to accomplish.

In his famous example, Christensen helps McDonald's increase the sales of their milkshakes by understanding the job that the milkshake does for the drinker. For early morning commuters, drinking a milkshake is the perfect snack for a long, boring drive. To improve the milkshake and increase sales, Christensen recommended that McDonald's make the milkshake thicker, so it took even longer to drink.

Jobs To Be Done Source: Airtable

Other companies have their own takes on this mental model to help them make better decisions. One especially useful interpretation for product managers is the way that Airtable uses Jobs To Be Done to shape roadmaps and production pipelines. To understand what your users want and figure out what will be most helpful to them, Airtable recommends defining the persona (the type of user), their action (what they'll do with your product), and the outcome (what they hope to achieve with this action).

Airtable's framework is incredibly useful to SaaS companies. When you're at a dead-end for product improvement, you need to take a step back and find out what users really want to accomplish with your product. Start by asking:

  • Who will the new feature or product improvement serve?
  • What action will they take with the new feature?
  • What do they hope that this will ultimately accomplish?

You can also supplement this with direct user feedback. Survey your users and ask them:

  • What would they miss out on if they stopped using your product?
  • Which other tools or services would they be using if there weren't using your product?

This mental model helps you avoid thinking about your product in a vacuum. It puts it in the most relevant context possible—how it's helping your user.

5. The problem hypothesis

Great ideas may never see the light of day if you don't turn the thought into concrete actions. The problem hypothesis helps you reframe something cerebral or theoretical as something that can be proven true or false.

This helps you test the viability of your idea. You determine whether the idea is valuable by seeing whether you can prove your hypothesis true or false. Then, you can be confident that the project is worth pursuing, and have a clear goal for what you're trying to accomplish.

For example, imagine that you want to build a feature into your messenger app that lets people send voice messages. It sounds kind of cool, but your dev team is swamped with fixing bugs. It's hard to know whether your nice idea is actually an item that your team should prioritize. You need to turn your arbitrary idea into a hypothesis that you can validate.

Problem Hypothesis

Now, you can carry out tests by asking users questions:

  • Do you currently send voice messages using another product?
  • How often would you use voice messages—as compared to the other features—if that feature were incorporated into this product?
  • About how many times a day would you want to use the product if it included voice messaging?

If the new feature will increase usage, you've proven your hypothesis and given your idea a good reason why it should take up time and energy from your team. This mental model helps you determine whether to pursue ideas, modify them, or shelve them.

6. Pioneers, settlers, and town planners

It takes all kinds of people and ideas to build a great product. But the trick of a good PM is knowing which to call on, and when.

That's where the pioneers, settlers, and town planners mental model comes in. Pioneers, settlers, and town planners all help to build a city, but they contribute different types of thinking at different times.

Pioneers Settlers Town Planners

Understanding the right time to build, sustain, or scale helps you become more efficient with your time and capital. Building is exciting, but sometimes you can accomplish your goal by sustaining or scaling what you've already built. And it's much easier and cheaper evaluate the need to build upfront than to write new code and later realize you didn't need it.

Tweet: The trick of a good #product manager is knowing which people & ideas to call on, and when

To put this into practice, try categorizing decisions into actions that innovate, sustain, or scale. Then make sure that the category these decisions fall under matches up with your company's objectives.

For example, if you're a fledgling startup and your product is still under development, you'll need to be iterating and innovating.

On the other hand, if you're a more mature company and you identify a feature that 80% of users find helpful, figure out how you can scale that to the other 20% instead of building an entirely new feature.

Thinking about your product decisions this way helps you recognize when innovation is necessary, and when you can improve efficiency and save resources by relying on systems that already work.

Mental models are long-term tools

These mental models aren't growth hacks or tips of the week. They're strategies for solving problems that you can use over and over again, in a variety of different situations. They apply to many different products and help you solve unique problems while accounting for all of the nuances.

As you use these mental models over time, they'll evolve with your experiences. Not every model will be pertinent to every situation, but by considering many perspectives, you'll learn which are most helpful. This means that your toolkit will grow in value over time, and with it, your problem solving skills will sharpen.



Popular posts from this blog


मुद्दत हो गयी उन तन्हायियो को गुजरे , फिर भी इन आँखों में नमी क्यों है  ? तोड़ दिया मोहब्बत पर से यकीन मेरा, फिर भी मेरी दुनिया में तेरी कमी क्यों है ? हसरत है क्यों आज भी तेरी चाहत की मुझे, क्यों याद तेरी जेहेन से मिटती नहीं ? जलजला क्यों उमड़ता है ख्वाबो में मेरे, उस आशिकी की आगज़नी क्यों है  ? सन्नाटो में भी क्यों सुनता हू तुझे मेरी परछाई से क्यों तू जाती नहीं ? इन डबडबाती आँखों को तलाश तेरी, आज भी कहीं क्यों है   ?

How the Python import system works

How the Python import system works From: If you ask me to name the most misunderstood aspect of Python, I will answer without a second thought: the Python import system. Just remember how many times you used relative imports and got something like  ImportError: attempted relative import with no known parent package ; or tried to figure out how to structure a project so that all the imports work correctly; or hacked  sys.path  when you couldn't find a better solution. Every Python programmer experienced something like this, and popular StackOverflow questions, such us  Importing files from different folder  (1822 votes),  Relative imports in Python 3  (1064 votes) and  Relative imports for the billionth time  (993 votes), are a good indicator of that. The Python import system doesn't just seem complicated – it is complicated. So even though the  documentation  is really good, it d

On working remote

The last company I worked for, did have an office space, but the code was all on Github, infra on AWS, we tracked issues over Asana and more or less each person had at least one project they could call "their own" (I had a bunch of them ;-)). This worked pretty well. And it gave me a feeling that working remote would not be very different from this. So when we started working on our own startup, we started with working from our homes. It looked great at first. I could now spend more time with Mom and could work at leisure. However, it is not as good as it looks like. At times it just feels you are busy without business, that you had been working, yet didn't achieve much. If you are evaluating working from home and are not sure of how to start, or you already do (then please review and add your views in comments) and feel like you were better off in the office, do read on. Remote work is great. But a physical office is better. So if you can, find yourself a co-working s