42 Rules of Product Management

42 Rules of Product Management

42 rules to live by for product managers. Great insights and product principles for being a great product manager and making better products.

42 Rules of Product Management  edited by Brian Lawley

This book is packed with great advice, product patterns, and anti-patterns. The rules are brief and written by different authors. Each encapsulates a key principle of effective product management. There are rules related to working effectively as a product manager, understanding your customers, creating product strategy, and working with your peers and stakeholder. This isn’t a detailed “how-to” book, rather it is a “here’s the principle, now go think about how it applies to you” book that has a lot of deep insights into product management from a variety of perspectives.


One of the rules, written by Lawley, advises to work on problems you are passionate about. There’s a popular product management saying: “Love the problem, not the solution”. Passion unlocks creativity, which is a key attribute of successful product manager. The more interested you are in the customer and their challenges, the better questions you’ll ask and the more observant you’ll be. This will increase your chances of finding a solution which meets their needs. Lawley notes that passion is infectious and spreads across the whole team. If everyone sees your interest and engagement, they will get swept along. And there’s no better way to make your days enjoyable than working on something that fires you up.

Being a great product manager

Although all the advice in the book is intended to make you a great product manager, there are several which are specific to performing the job effectively. There’s advice about learning to say “no”, thinking like an entrepreneur, writing everything down, and managing the political side of the job.

One of the best rules is simply “Let the customer end the debate.” When everyone in the room is putting forth opinions and assertions, customer data wins.

Dan Olsen has a great essay on priorities and says “the best product teams are crystal clear about their priorities at every point in time and are adept at quickly changing their priorities when they need to.” He says that a lack of priorities indicates deeper issues and means the team doesn’t have a clear point of view about their customers and the problems they are trying to solve or the team lacks decision making processes. He also notes it can be a symptom of there being no one who can make difficult product decisions.

Kevin Epstein‘s rule “be data-driven by the consumers of your product” notes that “you are not the customer, but you are the distilled collective voice of all your customers.”  He suggests gathering both quantitative and qualitative data on customers. Epstein also recommends that product managers not be steamrolled by your largest customer who is “often not the most representative of the wider base.”

There’s a rule about a “90-360-3” plan: take 90 days to get a 360 view of your product and pick 3 high impact changes to make. This is great advice for an incoming product manager, especially if no product plan or strategy exists.

Product Strategy

The positioning statement is what you say if someone with a minimal understanding of your industry asks what your product is

There’s some great advice on product positioning from Fritz Mueller from i365. It’s critical for product managers to explicitly spell out their positioning and review it with the entire team. This is something many product managers neglect to do and assume everyone knows. It’s a great seed for conversations to clarify product strategy and get everyone on the same page about the state of the product. You can write a current-state and aspirational positioning statement.

Creating a positioning statement forces you to figure out what you are best at, where you are in the hierarchy, and exactly what you are selling.

A related rule “Differentiation isn’t enough, you have to be better” by Paul Alex Gray advises product managers to understand: 1) what customers want; 2) what you’re good at; and 3) where competitors are weak.  He says “the intersection of these three areas is the best opportunity for going beyond differentiation to define, develop and deploy a product that is more likely to succeed.”

There are a couple of rules related to segmentation. One of these is “decide what you are going to do and not do” by Mike Freier from the 280 Group. He discusses market segmentation and notes that “when companies understand the nuances of markets, they are able to build winning products” because they are allocating their resources and targeting the needs of segments effectively. Since everyone has limited resources, making a choice of which group of customers to serve is essential.

We can get so close to our products that we no longer have the wide view to see the market problems that are bigger than problems that are currently being addressed.

The quote above is from Rule #28 “Find Market Problems Worth Solving”. Nick Coster from brainmates writes “it is not the value of the technology that will add value to the business, it is the value of solving the market problem.”

The requirements death spiral

This rule will be familiar to nearly every product manager. Although Agile methods have been around for over a decade, we still fall into this trap. Written by Greg Cohen, this rule describes the anti-pattern that occurs when the product development conversation begins to focus on dates. The problem begins when something the engineering team is building “takes too long”. When the engineering effort does not conform to an arbitrary date, everyone rushes in to help meet the date. This causes both sides to point fingers at each other. The engineering team says the requirements were not complete and kept changing. The product management team responds with even more detailed requirements and demands requirement sign-offs and date commitments.

There’s no winning the “date” conversation because it is based on the mistaken belief that anyone can estimate the completion date of software that has never been before. This leads to conversations about “maturity” (i.e., the team is not mature enough to produce reliable estimates) and “commitment” (i.e., the team is afraid of commitment so they are intentionally being vague about what they can deliver). This line of thinking distracts everyone from the things that really matter: building something that solves a problem or need that your customer is having and measuring the outcome of what you just built.

Only when viewed from the perspective of delivering value to the customer and creating value for the company are product management’s and engineering’s actions so clearly counterproductive.

To avoid the death spiral, Cohen says product managers must “focus on the problem space and encourage engineering to apply their creative energies to the solution space.” Being mindful of the problem space and solution space helps product manager avoid falling into the trap of debating solutions and technical designs with engineering teams. This takes product managers away from their core responsibility: understanding their customers and market.


42 Rules of Product Management is a collection of 42 short essays from a variety of product leaders. If you’re looking for a thought-provoking set of “rules to live by” for product managers, this is it.

Reading each rule will resonate with your product experience and make you think about how you can improve as a product manager and how you can make your product better. It’s a great check-list of product principles that is useful for even the most experienced product managers. The rules are stepping-off points for thinking about your approach and the current state of your product.

You won’t find “here’s how to build a roadmap” or “here’s how to work with UX and engineering”. Rather, you’ll find lots of “make sure you are doing this thing or your product will fail” and “don’t do this or your product will fail and so will you.” Read it slowly. You’ll be quoting the book in your tweets!


Leave a reply