12 Product Management Frameworks

12 frameworks that are part of my Product Manager toolkit.

Whether I’m shaping a new feature, creating a roadmap, or thinking about a problem, these are the frameworks I use.

Addition by subtraction (less is more, 80-20)

A simplification framework.

A method to make a product less complex by focusing on what you’ll say no to.

What is not a priority? What problems will this product not solve? What features will we not include?

A method to enhance clarity (addition) by saying no (subtraction).

Nassim Taleb in his book “Antifragile” described this framework as via negativa.

If we cannot express what something is exactly, we can say something about what it is not.

Antifragile

Proclus was known to repeat the metaphor that statues are carved by subtraction. I have often read a more recent version of the idea, with the following apocryphal pun. Michelangelo was asked by the pope about the secret of his genius, particularly how he carved the statue of David, largely considered the masterpiece of all masterpieces. His answer was: “It’s simple. I just remove everything that is not David.”

Antifragile

Steve Jobs had two famous quotes on this topic.

Focus is about saying no.

Steve Jobs

I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

Steve Jobs

agile vs Agile

A framework for thinking about the nimbleness of your product team.

Do you rigidly follow Scrum ceremonies because that’s how it’s always been, or because your team needs a rigid structure?

Do you spend unnecessary time debating whether a story is a “Small” or “Medium” t-shirt size?

To be agile is to be able to move quickly and easily. It’s to adapt to a constantly changing environment.

Think about if your development processes are lower case agile or upper case Agile.

Principles behind the Agile Manifesto

Big Things & Papercuts

A broad framework that can be used for prioritization, roadmap planning, or strategy.

The framework is used by the Amazon leadership team to manage projects.

The big things are the initiatives rooted in foundational customers needs that are not going away. At Amazon, a big thing is customers wanting fast delivery. That likely will be true forever. The majority of your time is spent addressing the big things.

Think about the things that are not going to change over 10 years. Those are probably the big things. I know that in our retail business at Amazon, customers are still going to want low prices, fast delivery, and big selection. When you identify the big things, you can tell they are worth putting energy into because they are stable in time.

Jeff Bezos on Lex Fridman Podcast

Papercuts are all those smaller issues that take away from the core experience. You may have a long list. You’ll need to deliberately make time to work on fixing papercuts.

Tiny customer experience deficiencies. We call those papercuts. We make long lists of them. We have dedicated teams that go fix papercuts. Because the teams that work on the big things, never get to the papercuts. They never work their way down the list to get to the papercuts. You need special teams who are charged with fixing papercuts.

Jeff Bezos on Lex Fridman Podcast

Context, User Groups, Problems, Solutions (CUPS)

A framework for thinking about new product or feature ideas.

It can also be used to structure an answer for a Product Sense interview question such as “how would you improve Spotify” or “design an app for a traveler who wants to taste Italian cuisines”.

Start by establishing context. Business objectives, budget constraints or time restrictions. Identify the user groups (cohorts) to focus on. Define what problems people in these user groups have. Define possible solutions to these problems.

Courtland Allen from IndieHackers covers a similar framework in his post How to brainstorm great business ideas.

Enough

A sibling of the Addition by subtraction framework.

This framework is about defining what is sufficient for your product to have in order to deliver value or solve a customer’s problem.

Jason Fried from 37signals use the enough framework to determine the scope of a new feature or product.

It doesn’t do everything, but it does what you need.

Five whys

A method to assist with diagnosing root causes of problems.

Start by asking why, and continue to ask why until you reach the root of the problem.

Typically 5 levels of why will be sufficient, but you can go to additional levels if needed.

The method was developed at Toyota.

Jobs to be Done (JTBD)

A framework for thinking about customer needs.

The framework asks you to consider what job is the customer hiring my product to do?

Created by author and former Harvard Business School professor Clayton Christensen.

In the paper, Clayton Christensen told the story of morning commuters “hiring” a milkshake for a job to be done during their morning commute.

It became clear that they all had the same job to be done in the morning. That is that they had a long and boring drive to work and they just needed something to do while they drove to keep the commute interesting. One hand had to be on the wheel but someone had given them another hand and there wasn’t anything in it. And they just needed something to do when they drove. They weren’t hungry yet but they knew they would be hungry by 10 o’clock so they also wanted something that would just plunk down there and stay for their morning.

Clayton Christensen

MoSCoW

The MoSCoW method is a framework for prioritization.

It can be used to organize a list of features into four groups:

  1. Must have
  2. Should have
  3. Could have
  4. Will not have right now

Minimum Remarkable Product (MRP)

A variation of the foundational Lean Startup MVP principle.

One of the main objectives for creating a Minimum Viable Product is to test your hypothesis. To validate (or invalidate) if you’ve found a useful solution to a real customer problem.

For an MRP, think about what would be the minimum needed in order to create a remarkable MVP?

It adds an additional layer of complexity, so it may not be useful for a team trying to find product-market-fit.

However if you already have a customer base, and are building a new product or feature for them, consider what is the MRP.

One way & Two way door decisions

A framework for classifying the significance of a decision, and as a result how much time you should spend thinking about it.

It’s a framework that the leadership team at Amazon used for classifying decisions.

A two way door decision is one of low consequence. If you get it wrong, you can go back and try again. Don’t over analyze it. Make a decision and reassess if needed.

If it’s a two way door decision, you pick a door, you walk out. You spend a little time there, it turns out to be the wrong decision, you can come back and pick another door.

Jeff Bezos on Lex Fridman Podcast

A one way door decision is of high consequence. Getting it wrong can be catastrophic. Significant time should be invested in analyzing the decision.

Some decisions are so consequential, so important, and so hard to reverse, that they really are one way door decisions. You go in that door, you aren’t coming back. Those decisions have to be made very deliberately. Very carefully. If you can think of another way to analyze the decision, you should slow down and do that.

Jeff Bezos on Lex Fridman Podcast

Reach, Impact, Confidence, Effort (RICE)

A prioritization framework created by the team at Intercom.

It can be used to assist with backlog or sprint prioritization, roadmap planning, or evaluating ideas from different stakeholders.

  1. Reach: how many customers will this reach
  2. Impact: what is potential impact of this initiative on customers or a business goal/KPI/OKR
  3. Confidence: how confident are you in your estimates
  4. Effort: how much time or resources will this initiative require

The simplest thing that could possibly work

A framework for coming up with a solution to a problem.

It requires a deliberate focus on a goal, and identifying the shortest (simplest) path to reaching it.

If you’re building a new feature for a customer, consider what is the simplest solution that could deliver value to the customer?

What you come up with does not need to be the thing you ship, but it’s a starting point. It’s an option. And it may be enough.

When Kent Beck and I were playing with Smalltalk, we found it amazing what Smalltalk would do compared to anything either of us had used before. And it really seemed that Smalltalk wanted us to try things. A lot of times, we would just try to see if we knew how to program something. We’d be talking about something, and say, “Gosh. Do you think we could program that?” And we’d just jump in and start programming. And sometimes the programming was almost effortless, as if Smalltalk had been made to write that program. It was amazing. But other times we’d be programming away, and we’d say, “Now, wait a second, what are we working on here?” We’d just get stuck. And if we were stuck more than a minute, I’d stop and say, “Kent, what’s the simplest thing that could possibly work?”

Bill Venners

It was a question: “Given what we’re trying to do now, what is the simplest thing that could possibly work?” In other words, let’s focus on the goal. The goal right now is to make this routine do this thing. Let’s not worry about what somebody reading the code tomorrow is going to think. Let’s not worry about whether it’s efficient. Let’s not even worry about whether it will work. Let’s just write the simplest thing that could possibly work.

Bill Venners