20 Mental Models for Product Managers

Karen A
Agile Insider
Published in
14 min readAug 2, 2018

Memory fails me on the exact sequence of events that led me to discovering mental models and how I became obsessed with them. This is unsurprising because I read a lot of stuff — articles, books, and more; partly because I love the experience of reading (and writing), and partly because it’s more or less a requirement when you work as a Product Manager, but mostly because I have an insatiable, unquenchable thirst for knowledge.

Mental models seem to be gaining more popularity these days, with most content I have seen revolving around Charlie Munger’s ideas — I guess he saw it before we all did. However, my go-to resource has been the Farnam Street blog, which was very instrumental to the writing of this article. In my simple terms, a mental model presents a way to think about a problem. Each one is a framework, method or approach, that can be used to make decisions. The reason why I like them so much is that they implicitly mimic the way the human brain works when making decisions.

If you have read as much Daniel Kahneman as I have, you would know that the human brain tends to be very lazy by default. At any point when it needs to make a decision, it’s more likely to rely on what it already knows or past experience, than attempt to learn new information. So, it should follow that if you learn enough of these frameworks for decision making then you are effectively training your brain to have more information to call upon in varied situations, making you all the wiser. Well, this is partially true but not as simple because in reality, these models tend to be in conflict with each other, so even in deciding which one to use, you need to know a great chunk of them in order to make an informed decision.

Now, what field requires quick decision making on a daily basis more than Product Management? You could probably name a few, but this one is most familiar. It has struck me on more than one occasion, that I do have models which I rely on to make my job easier and help me work smarter, so I have taken a chunk of the most useful ones, and distilled them down through the stages of the typical Product Lifecycle, which every PM typically would have faced (or will face) at some point in their career.

Stage 1: Conceive

At this stage, the product concept or idea is still being formed, so the team is still trying decide what to build. Two things are the focal points for the PM and company team — idea generation and identification of user needs. So you would probably be doing a lot of brainstorming to determine what features to build. Ideas can come from a number of sources but the most common are your immediate team, sample users or clients (if B2B), and some early stage metrics extracted from the initial product idea, if you have one. In identifying user needs, you will also be trying to ensure that the ideas solve the user’s real problems, while avoiding any unintended side effects.

Mental Models

  1. Representativeness Heuristic — Tendency to Stereotype — The representativeness heuristic is what our brain often uses as a mental shortcut, to make decisions about the probability of an event under uncertainty. Specifically, the tendency to stereotype is when we broadly generalize and categorize events, rather than looking for specific nuances. In determining user needs, we do this implicitly when we build features based solely on user feedback, without trying to understand the real problem to be solved. Being aware of this, PMs can guard against this bias by consciously working to uncover areas where more digging needs to be done to find the root cause(s) of user needs.
  2. Second Order Thinking — Typically, when taking an action, we consider only one layer of consequence and mitigate the risk of that single layer. However, there are often multiple layers of effects that occur after an action, and second order thinking means uncovering multiple layers of effects on actions we take, in order to help us avoid unintended side effects. In idea generation for instance, there might be a feature which delights the user, but could also cost the company a data loss, and so due to the negative impact on the business, should not be implemented.
  3. Tendency to Overgeneralize from Small Samples — When using small samples, we tend to take the results from this subset of data as absolute truth, especially when they show positive output. While it is necessary to use samples as an abstract to test, we need to be able to guard against a potential bias. When conducting research into user needs, remember to keep the sample size in mind so that you don’t jump to conclusions without statistical proof that may not necessarily apply to a larger sample.

Stage 2: Plan

This stage comprises a significant amount of market research to understand the competition and the market. This is also typically the phase of customer development, where a lot of time is spent talking to users — through research and interviews.

Mental Models

  1. Comparative advantage — Economically, this is the ability of a nation to produce a good or service at a lower opportunity cost than another, which establishes the basis for international trade. This can be applied to a competitor analysis when establishing the strengths and weaknesses of competitors using a matrix or some other model. If a company operating in the same industry as yours is able to produce some things cheaper than you can, this could be an opportunity for partnership, or a factor for determining whether to launch the product, or how best to launch.
  2. Bottlenecks Simply put, a bottleneck is a point at which flow stops. Depending on how close this is to the critical path of the production of a good or service, it can negatively impact or ultimately halt production. This could potentially be a goldmine of untapped opportunities when analyzing an existing market. Identifying bottlenecks in the supply chain is usually a good way to determine the point of entry into the market, that is both unexpected and solves a key problem.
  3. Narrative Instinct — By default, human beings are drawn to storytelling and narratives — as a result, we seek to construct, and find meaning in them. The ability to construct a story around your product that appeals to users could be the key differentiator between your offering and a competitor’s. If your target audience connects with your story, it reduces their barriers to purchase. Being able to exploit the narrative fallacy is key to harnessing this bias — people believe they can explain cause-and-effect relationships if a story supports their prior beliefs, so capitalize on this when developing a customer base.
  4. Trust — This is a very simple one, that I think is often forgotten, or taken for granted. Fundamentally, human relationships are built on trust. If established early, there are manifold rewards that can be reaped from users who trust a product. So, you will want to find avenues to establish trust very quickly when speaking to users, and you can use the narrative instinct here to help bridge gaps and establish familiarity. As the product grows into maturity, you will find that these initial seeds of trust will help to keep repeat customers.
  5. Commitment & Consistency bias — Human beings like to be consistent and committed to their words, actions, and more. The idea that once we start doing something, we have to keep at it for various reasons — positive self-image, to gain trust, rationality, honesty — is very rampant. When speaking to potential users, a good way to secure commitments and overcome barriers to adoption is by breaking down large promises to smaller chunks of commitment, which they can consistently adopt in a stepwise process.

Stage 3: Develop

In my opinion, this is the busiest part of any product lifecycle because it has the most number of simultaneous moving parts. First, you are gathering and synthesizing a lot of user feedback, turning them into ideas. Second, you are building prototypes based on the ideas to feed into the MVP. On the other hand, you are forming or clarifying assumptions and hypotheses, while preparing metrics to define success. And last but not least, you are dealing with development — creating and managing the backlog through user stories, prioritization and testing. So, it’s a lot to handle at once and choosing what to focus on, is usually the pain point for PMs.

Mental Models

  1. Opportunity cost — What are you and your product team foregoing by choosing to focus on one thing over another? It is obvious that a single product cannot be built to solve all problems or meet all user needs, so decisions around what not to do, are as important as choosing what to do. This model can be applied to the product in different perspectives — how much are we losing by doing x as opposed to y? How many users are we gaining by adding feature 1 as opposed to feature 2?
  2. Utility (marginal, increasing, diminishing) — The idea that as additional units of a product/service are consumed, utility increases up to a critical point, where any more additional units have the inverse effect of diminishing utility. This is a useful way to determine how to manage limited resources for product development, because it can help to illustrate what sequence of events should come first, with regards to implementing the backlog. If a product feature is producing diminishing utility, this can be de-prioritized over one that is increasing.

Stage 4: Iterate/Launch/Steady State

This is an extension of the Develop process, as opposed to a completely new phase. In this phase, the product is evolving or may have already evolved from MVP to a more mature product. As a PM, you would be focusing on growing through a combination of several approaches — user retention, optimization, testing, and scaling. Similar to the previous phase, focus remains a key concern but scale also takes priority; in order to have a stable enough product that more and more users can adopt.

Mental Models

  1. Fragility — Robustness — Antifragility — This model represents a spectrum which a system can move through — it is a check on how a system responds as negative variables are introduced. Fragility at the lower end is where the system can handle little to no negative variability, robustness is the center where it can handle additional negative variation, while antifragility is at the higher end where the system is not impacted by additional negative variables. I believe this speaks a lot to the product development process — in MVP stage, the product is fragile hence the limited scope and user base, but as usage grows, more features are added which make it more robust. PMs can use this model to determine what needs to be built to take their product further down the spectrum towards achieving antifragility, such as safety, performance features and ability to cover a maximum number of edge cases.
  2. Feedback Loops — Borrowing the definition of feedback loops from Universal Principles of Design it says that “every action creates an equal and opposite reaction. When reactions loop back to affect themselves, a feedback loop is created”. All systems have both positive and negative feedback loops — the former for creating change and the latter for resisting change. The reason why both exist is because things tend to be restored to a state of balance eventually, i.e. homeostasis. In developing software, there’s an innate power that lies in feedback loops which can be used for growth. As a PM, you should be trying to find the series of events that cause customer happiness or success for your product, e.g. when we use this button text, more people click on it, and that leads to conversions, they use the feature and it delights them, they come back to use it, and invite other users, and so on. Negative feedback loops can also be used to minimize bad behavior or use in product development. When a product is losing users who are not taking advantage of a new feature that could enhance their experience, a PM can prioritize removal of older features obstructing the customer’s success to restore engagement and growth.

Stage 5: Maintain or Kill

This stage applies to products that have gone through maturity and into decline. Due to the steady decline, the business is questioning its existence and wondering whether to maintain or kill it. If it is to be maintained, then the PM would be thinking about how best to pivot or salvage the idea and push for growth.

Mental Models

  1. Pareto principle — This states that a small amount of some variable or phenomenon causes a disproportionately large effect; usually represented numerically as 20% of x produces 80% of y. There are two ways this can be extrapolated in product development. A PM managing a product in decline should be digging into data to ask questions. In order to apply the principle, you can try to identify if 80% of the revenue generated is coming from only 20% of users, and if so, is it worth trying to pivot the product with this user segment as a niche? The second focal point could be exploring if 20% of features are used by 80% of users, because this would then give you ideas on possible ways to pivot.
  2. Law of diminishing returns — In any system, additional units or resources increase value and returns, until the point of diminishing returns where any addition could lead to a negative result. This applies to products as well — if adding more features to mature product is not converting in terms of increased users or revenue, then it is a signal of diminishing value. As a PM, this could be a useful way to test if the effect of adding a new feature is valuable enough to maintain or kill the product.
  3. Scale — All systems are sensitive to scale, and products are no exception, as they exhibit different behaviors when scaled up or down. This model applies to all complex systems but may often be missed, due to the fact that it is implicit. This can be used in tandem with the Pareto principle above, when deciding the future of a mature product — having observed the product to see where the most revenue or users come from, you can then analyze the system performance in the context of scaling down or up. If the decision is to pivot with a new idea, then scaling down could help to minimize costs while testing with a higher level of certainty, based on the application of the Pareto principle.

Working with People

One certain thing about the product development process is that it does not happen in isolation. There are always people involved, and a PM has to have strong teamwork and interpersonal skills that are on par with their other technical skills, in order to be successful. As a result, the remaining models apply to working with others.

Mental Models

  1. Circle of competence — Each individual has varying levels of knowledge about different areas, disciplines or subjects. For instance, your team might have a designer and an engineer who are skilled in two separate areas — user interface design and software architecture. And even though as a PM, you may have some knowledge of each, it is important to let each specialist tackle their area of expertise. Defining a circle of competence is simply acknowledging what you know as a professional, by especially focusing on areas in which you have deep subject matter expertise, i.e. specialist knowledge. In product development, this needs to be defined for all the individuals on a team. On the flip side, it is also very important to agree on what each person does not know. The benefits of delineating these are firstly, you will save a lot of time leveraging each person’s strength rather than when team members try to learn things in which they have no deep expertise; and secondly, there is a higher probability of success when each person is focused on specialist areas.
  2. Seeing the front — Originally a military tactic, this is the habit of observing what’s in front of oneself before making decisions, rather than relying solely on advice, research, and reports. The main reason is to minimize and potentially avoid biases which could come from individuals. As the Product Manager, you own the product and are ultimately responsible for its success or failure, so being able to observe things firsthand is invaluable. This does not mean that you should discard suggestions from colleagues or team members, rather it means that you should be able to check information out for yourself, and make an informed judgement based on everything you find out.
  3. Social Proof (Safety in numbers) — In times of uncertainty, human beings look to others to know what to do or how to behave — this stems from an innate desire to fit into a group rather than stand out, and is the basis for the psychological concept known as social proof, or safety in numbers. This could be dangerous for two reasons — first, a group of people might reach the wrong conclusions without concrete proof, and people could be driven to make choices they would not ordinarily make. Product teams are not immune to such pitfalls — especially when users are exhibiting certain behaviours, or a competitive product employs a new tactic. As a PM, being able to identify when these biases occur, can help to prevent the team from moving in a direction that could be detrimental to the product in the long run.
  4. Inertia — In Physics, this refers to the concept of resistance to changes in motion. As individuals, this idea manifests in our minds through what is known as cognitive inertia, and results in us being lazy, idle, unable to move, or resistant to change. Teams also exhibit this by choosing to operate based on what they currently know or believe, and being closed to new ideas or ways of doing things. The good thing about inertia is that it keeps things stable and prevents us from constantly questioning our beliefs, but when overdone, the result is that teams and companies remain stuck in their ways and find it difficult or impossible to adapt. A PM who is aware of this inertia can guard against it by helping the team to push through the initial resistance. This is usually the hardest phase to overcome, but if done correctly, it becomes easier to reach the next level of product success.
  5. Hanlon’s razor — A simple but often underrated model which is useful when working with others, it can be simply summarized as; “Never attribute to malice that which can be adequately explained by neglect”. It means that more often than not when a team member does something wrong, it isn’t for personal reasons to spite you so it shouldn’t be misconstrued as such. When working with a team of individuals who have varying personality types and work styles, it is not uncommon to clash based on a number of things, such as missed deadlines or miscommunication. At first instinct, we tend to blame others for not wanting the team to succeed, when in fact, they might have failed for alternate reasons. Obviously, the possibility always remains that an individual could be sabotaging the team for some personal reason, so you can use this model in conjunction with logic, experience, and evidence to rule out all other possibilities.

Well done if you made it to the end of this, and bonus points if you made it to the end and you are not a PM. Mental models can be a lot to take in, especially if it’s your first time hearing of them, or trying to actively use them in decision making. So, that’s why I wrote this — ultimately to show you that there is a systematic way to help you make decisions. Although this is written with a professional theme, and for a very niche audience of Product Managers, everyone has to make countless decisions in their life — at work, at home, in transit, and so on — so I challenge you to extend the application of these models to different parts of your life.

Do you have an experience with mental models that you would like to share? I’d love to chat endlessly about it (karen@intelia.io). Want more product/tech/general musings from me? I write every so often, and you can join my mailing list here. Speak soon.

References: Farnam Street, Udemy.

--

--

Karen A
Agile Insider

Product Manager. Design Thinker. Believer in the extraordinarily (Im)possible.