More Product Management Mental Models for Everyone

Tom Redman
6 min readFeb 5, 2020
Manipulated illustration originally by Ben Coy

Whether you know it or not, you already have a number of mental models about how the world works in your mind. And they’re different from mine, and everybody else’s, because they’re derived from your unique experience and worldview.

Mental models are simple expressions of complex processes or relationships. These models are accumulated over time by an individual and used to make faster and better decisions.

These models are tools our brains use to organize patterns of behavior, production and outcomes. They are learned, experienced, internalized and ultimately applied back into the world through our creative and professional outputs.

These are some of the mental models I’ve collected over the years as they relate to product management.

Seeing the Front

Minimize faulty decision-making by ensuring you “personally see the front”.

How it’s useful

This one is pretty simple: As a product manager, you should always stay in touch with your customers. Never let others’ research fully supplant your own.

Avoid fully relying on secondhand information which is prone to miscommunication, external biases, and faulty assumptions. Your firsthand information will also serve to improve the quality of your secondhand information.

Tendency to minimize energy output

Behavior is often governed by a tendency to minimize energy usage.

How it’s useful

Deviating from the status quo takes mental energy, if not physical.

Put another way, behavior modification is hard because of a natural resistance to change.

The product you build needs to overcome a person’s natural resistance to change, which ultimately stems from a conservation of energy.

Build things with the simplest interactions and flows possible. Make choices on behalf of the user and double-down on smart defaults. Remove all barriers to engagement that are within your control. If you’re between two options, pick one and don’t offer a toggle.

Start there, and only include things as they become truly painful to not have.

If your users have spent the initial energy to try your product, capitalize on that by making the rest easy for them.

Don’t rely on users to reading copy

A large percentage of users will automatically bypass written copy, so you need guardrails in place to make sure they’re still successful.

How it’s useful

Some people will read what you write, many won’t.

Don’t allow critical information to be passively consumed. You can force acknowledgement or, better, improve the guardrails in your product such that critical paths are navigated organically.

Note that this doesn’t mean you should remove or neglect copy. Great copy is essential to a great experience, it just shouldn’t be used as the only line of defence.

Opportunity costs

Literally every choice you make comes with one or more trade-offs as a part of the decision.

Frazz by Jef Mallett for June 15, 2010

How it’s useful

This is a classic.

It’s compromises all the way down. Be honest about the compromises that come with any given decision. Acknowledge and understand them. Compare these trade-offs to the other possibilities to get a better picture of the impact of your decision.

You’ll run into this one almost every day.

Team psychology matters

Humans are imperfect and irrational beings. This affects your team’s ability to equally deliver otherwise equal products.

How it’s useful

Imagine you’re deciding which feature to build next. You’ve whittled your options to two choices, each with equal scope and complexity:

Feature A: has slightly higher customer value than Feature B, but is related to something the team has done many times in the past.

Feature B: has slightly less potential value for the customer, but it’s exciting and new from a product development perspective.

Because Feature B is more exciting for the team, it actually shifts the value-to-effort ratio in its favor. The net result is that feature B might be shipped sooner because your team is enthusiastic about it. It’s not a slog to build.

Conversely, it’s possible that boredom will translate into shipping Feature A more slowly. It happens. We’re human.

And according to the law of the time value of shipping, a product shipped earlier is worth more to customers than product shipped at a later time, the realized customer value might end up being equal or even greater with Feature B!

Increasing, marginal, and diminishing utility

The value of additional production tends to vary with scale. A unit of additional work has the potential to add either significant value, marginal value, or negative value.

How it’s useful

Not all units of work are made equal. For simplicity’s sake, think of a unit of work as a “day of engineering”.

Some units of work can result in a step function in value by breaking through a “critical point” of utility, unlocking the full potential of all preceding work.

For example, imagine you’re building a reporting product for marketers. Your team spent the last 4 months perfecting the charts, graphs, typography, and export functionality. It’s perfect!

Except nobody’s using it. Why?

It turns out marketers absolutely need the ability to upload their logo to the reports that they send to clients. Without that, everything else is moot.

Therefore, for any of the team’s prior work to matter, one additional unit of work is required. With one more day of engineering, you are able to unlock the utility of the preceding work and marketers around the world rejoice!

On the other hand, some units of work will only add marginal utility or worse, no utility at all.

In the case of marginal utility, you’re just keeping up with inflation. This is not a great place to be. Taking that a step further, units of work that no longer deliver utility are actually diminishing the value of your product due to the time value of shipping. This is the worst place to be!

For example, if you keep working on the logo upload feature beyond its functional utility, your product is actively getting worse because you’re not actively making it better.

That’s it for now!

To reiterate a salient point from Brandon’s original post, mental models are useful in some contexts and less so in others. Don’t be too prescriptive with the models I’ve outlined here. Rather, incorporate them into your personal latticework of models. Combine, mold, and shape them as a part of your unique contribution to the world.

And if you do end up writing some of them down, I want to hear about them!

If you enjoyed this, please spread the word by clapping 👏 💚 and share freely 🙏

I’d also love to hear from you on Twitter!

— Tom

Special thanks to Tyler Wanlass for giving this an early read over and for our insightful discussions on mental models.

This article was inspired by Brandon Chu’s Product Management Mental Models for Everyone. I highly recommend reading this!

--

--