Book Review: The 42 Rules of Product Management

The 42 Rules of Product Management is a collection of “over five centuries” of product management wisdom from a variety of product management experts. Each chapter – from a different contributor – is consequently a fresh perspective provided in a short, concise chapter.

As a new product manager, I enjoyed gleaning insights from a variety of perspectives (the contributors include executives, consultants, authors/bloggers, and trainers as well as product managers). I appreciated reading what each contributor felt was important about product management, and why. It gave me a broad perspective in a short amount of time, and I found myself plowing through the book very quickly.

In this post, I'll share some nuggets that I came away with.

Products and Profits
Companies sell products that product managers are responsible for, and therefore the viability of your company rests on the success of your products. But 42 Rules advises against your primary focus being corporate profits and shareholder value. “…only by creating customer value do we ensure the long-term viability of our respective companies.”

This is because generating profits and shareholder value are outcomes of delivering a product to the market that customers find valuable. This means thinking like an entrepreneur and focusing on your customer’s needs, emotions, and purchase drivers, not just product features and benefits. Concentrate on how your product features and benefits align with customer goals better than competing offerings.

Working with Development/Engineering
Problems can manifest themselves when high-level requirements are articulated and estimates provided that yield a date that everyone gets married to. As development progresses, learning takes place and one way or another, new requirements are added. But development is told that the date cannot move and no one ends up happy with the resulting overtime and finger-pointing.

42 Rules says that after this experience (release), the next one typically gravitates towards the “Requirements Death Spiral." This is where the product manager starts asking for more detailed time estimates and the development manager starts asking for more detailed requirements to provide those estimates.

The problem with this? The partnership that should exist between product management and development/engineering vanishes. “Without even realizing it, the product manager begins to specify the solution (rather than needs) and the development team, not wanting to be blamed for any mishaps, starts to build exactly what is written without ever questioning it.”

42 Rules advises that, “It is product management's responsibility to identify customer problems worth solving. It is engineering's role to identify technical solutions to those problems. Together both sides must collaborate to create the optimal design that will solve the problem for the customer and delight them in its use. Product managers, therefore, must be vigilant to avoid entering the death spiral. The easiest way to do this is to focus on the problem space and encourage engineering to apply their creative energies to the solution space.”

Saying “No” Because the Customer Isn’t Always Right
“We are conditioned by pithy phrases like, 'The customer is always right,' and mantras like, 'customer focused,' to assume that everything a customer requests is reasonable, and that not reacting to it is a capital offense. Unfortunately, this mentality just compounds the problem. Product managers succeed when they stop responding to specific demands from individual customers and start listening to the market as a whole.”

Sometimes the issue a question of timing – when a feature is going to be delivered – which is a little easier to contend with since the customer will eventually get what they want. But sometimes customers ask for a feature that is important to their business, but something that you know shouldn’t be in your product – ever. This is where saying “no” is important, and as 42 Rules points out, the result can be mutually beneficial:

“I drew a line in the sand and told the customer that even though the feature was important to their business, I did not see that it would ever be in the product. Despite the customer team initially being quite upset and frustrated with my response, and getting a call from their CEO about her disappointment about the state of the product and its ability to meet their needs, telling them ‘no’ was the right decision for them and the product. I spoke with the customer team again several months later with a decidedly friendlier outcome. They told me that because I had told them that they wouldn't get the feature (rather than the feature being delayed), they had decided to invest in building the capabilities they needed in-house and were very happy with the results. And they were happier with my product too.”

Improving Your Product
42 Rules provided interesting advice on how to improve your product. And it doesn’t involve talking to current customers. “When you ask a current customer what they don't like about your product, they'll likely point to things they don't like which they think should be added or fixed—things they discovered after purchasing it and which they feel should be improved ‘for free.’”

What should you do instead? Talk to a competitor’s customer. “…they'll tell you why they didn't buy your product, and what you would have to do to your product to make it worth purchasing. As a product manager, I've always learned a lot more about what can be done to improve my product by talking to people who are not buying it, and people who are buying it and then not using it.”

Being the CEO for your Product
“As product managers, we're encouraged to act as CEOs for our products. What does that really mean? Many of us believe that it means we should be making all the decisions about our products. After all, how can you be responsible for its success if you don't have this authority? But watch your CEO carefully. If the CEO in your company is making all the decisions, then you're not making product decisions anyway, the CEO is; and this is not a very scalable company.”

Sound advice! If everything hinges around you, sooner or later, you’ll get run over. You won’t be able to go through a day without hearing how someone is “blocked” because they need something from you. A heaven help you if you want to take a vacation to relax. You won’t be able to.

As the CEO of your product, 42 Rules advocates communicating – a lot. As a product manager this is done through PRDs (Product Requirements Documents) and MRDs (Market Requirements Documents). “You need to educate, persuade, coach, and manage internal and external perceptions, assumptions, and people. To do this, have every pertinent piece of information documented. To be the product leader—which a good product manager is—you need a record. Without it, others will try to mold the product into their view, which may not align well with what the market needs and the opportunity you're chasing.”

Being the CEO of a product is different than being a CEO of a company. You don’t have the formal lines of authority leading directly to you. But 42 Rules points out a key test of you as a product CEO: “When a question arises about product direction, all eyes turn to you. If that's not happening, ask yourself if you're being a true product leader.”

Good versus Great
In closing, 42 Rules differentiated between a good and a great product manager: “To be a good Product Manager, a solid blend of technological and business acumen is required. To be a great PM, outstanding oral and written communications are essential, in conjunction with confidence, a general ‘whatever it takes’ attitude and pride in one’s product.”