Mental Models in Product Management – great article by Brandon Chu on his experience in using them in Product Management for improved investment, scoping, and iteration of shippable products.
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.
Here’s an example: the Pareto Principle states that roughly 80% of all outputs come from 20% of the effort.
In the context of product management, the model suggests that instead of trying to create 100% of the customer opportunity, you may want to look for how to do 20% of the effort and solve 80% of the opportunity. Product teams make this trade-off all the time, and the results often look like feature launches where 20% of customers with more complicated use cases aren’t supported.
Mental models are powerful, but their utility is limited to the contexts they were extrapolated from. To combat this, you shouldn’t rely on one or even a few mental models, you should instead be continuously building a latticework of mental models that you can draw from to make better decisions.
This concept was popularized by Charlie Munger, the famed Berkshire Hathaway vice chairman, in a speech where he reflected on how to gain wisdom:
What is elementary, worldly wisdom? Well, the first rule is that you can’t really know anything if you just remember isolated facts and try and bang ’em back. If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form.
You’ve got to have models in your head. And you’ve got to array your experience — both vicarious and direct — on this latticework of models. You may have noticed students who just try to remember and pound back what is remembered. Well, they fail in school and in life. You’ve got to hang experience on a latticework of models in your head.
What are the models? Well, the first rule is that you’ve got to have multiple models — because if you just have one or two that you’re using, the nature of human psychology is such that you’ll torture reality so that it fits your models, or at least you’ll think it does. You become the equivalent of a chiropractor who, of course, is the great boob in medicine.
It’s like the old saying, “To the man with only a hammer, every problem looks like a nail.” And of course, that’s the way the chiropractor goes about practicing medicine. But that’s a perfectly disastrous way to think and a perfectly disastrous way to operate in the world. So you’ve got to have multiple models.
This post outlines some of the most useful mental models that I’ve accumulated in my career in Product Management. As I learn new models, I’ll continually update the post.
This is also not a post for just product managers, it’s for everyone that works on products. Product thinking is not sacred to the role of a PM, in fact, it’s even more useful in the hands of the builders than PMs.
The mental models we’ll cover are structured into the following categories:
- Figuring out Where to Invest
- Designing and Scoping
- Shipping and Iterating
Figuring out Where to Invest — the next set of mental models are useful for deciding what your team should build, or “invest in”, next.
1. Return on Investment
A finance concept: for every dollar, you invest, how much are you getting back? In product, think of the resources you have (time, money, people) as what you’re “investing”, and then consider return as impact to customers.
How it’s useful
The resources available to a product team are time, money, and [the number and skill of] people. When you’re comparing possible projects you could take on, you should always choose the one that maximizes impact to customers for every unit of resources you have.
2. Time value of shipping
The product shipped earlier is worth more to customers than a product shipped at a later time.
How it’s useful
When deciding between problems/opportunities to invest in, you can’t just compare the benefits of different features you could build (if you did, you would always choose the biggest feature).
Instead, to make good investment decisions, you also have to consider how quickly those features will ship, and place more value on features that will ship faster.
3. Time Horizon
Related to the Time Value of Shipping, the right investment decision changes based on the time period you are optimizing for. Given a long enough time horizon, the cost of a 3 month vs. 9-month build is insignificant.
How it’s useful
Choosing to ask “How can we create the most impact in the next 3 months?” or “How can we create the most impact in the next 3 years?” will result in dramatically different decisions for your team.
It follows then that aligning with your team and stakeholders about what time horizon to optimize for is often the first discussion to have.
4. Expected Value
Predicting the future is imperfect. Instead, all decisions create probabilities of multiple future outcomes. The probability-weighted sum of these outcomes is the expected value of a decision.
How it’s useful
When considering the impact of a project, map out all possible outcomes and assign probabilities. Outcome variability typically includes the probability it takes longer than expected and the probability that it fails to solve the customer problem.
Once you lay out all the outcomes, do a probability-weighted sum of the value of the outcomes and you’ll have a better picture on the return you will get on the investment.
Designing and Scoping — the next set of mental models are useful for scoping and designing a product after you’ve chosen where to invest.
5. Working Backwards (Inversion)
Instead of starting at a problem and then exploring towards a solution, start at a perfect solution and work backward to today in order to figure out where to start. Note that working backward isn’t universally better, it just creates a different perspective.
How it’s useful
Most teams tend to work forwards, which optimizes what is practical at the cost of what’s ultimately impactful.
Working backward helps you ensure that you focus on the most impactful, long term work for the customer because you’re always reverse-engineering from a perfect solution for them.
Note that working backward isn’t universally better, it just creates a different perspective. It’s healthy to plan using both perspectives.
6. Confidence determines Speed vs. Quality
The confidence you have in i) the importance of the problem your solving, and ii) the correctness of the solution you’re building, should determine how much you’re willing to trade off speed and quality in a product build.
How it’s useful
This mental model helps you to build a barometer to smartly trade-off speed and quality. It’s easiest to explain this by looking at the extreme ends of the spectrum above.
On the right side: you have confidence (validated through customers) that the problem you’re focused on is really important to customers, and you know exactly what to build to solve it. In that case, you shouldn’t take any shortcuts because you know customers will need this important feature forever, so it better be really high quality (e.g. scalable, delightful).
Now let’s look at the left side: you haven’t even validated that the problem is important to customers. In this scenario, the longer you invest in building, the more you risk creating something for a problem that doesn’t even exist. Therefore, you should err on launching something fast and getting customer validation that it’s worth actually building out well. For example, these are the types of situations where you may put up a landing page for a feature that doesn’t even exist to gauge customer interest.