“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” - Abraham Maslow
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.
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.
Product managers are jugglers within SaaS companies. You have to handle a ton of moving parts:
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.
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.
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.
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.
Thinking about the positive and negative correlations between events helps prevent you from being blindsided 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.
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.
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.
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.
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 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.
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.
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.
Now, you can carry out tests by asking users questions:
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.
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.
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.
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.
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.
Looking for new tools your product managers can leverage for product innovation? Discover how Scuba can help.