Skip to main content

Product Management Bookshelf

Great product management requires a combination of learning, leadership, facilitation, and strategy skills.  To gain and maintain proficiency, new and experienced product managers alike can benefit from reading books on these topics.  My product management bookshelf includes a number of texts that never cease to benefit me.  I find myself referring back to the books to refresh my skills, rekindle my product management passions, and cite interesting passages to friends and colleagues.

Here are some of the top books I recommend product managers read.  The books I'm listing aren't books on product management per se, but they cover skills essential for effective product management.  If you're an executive overseeing a product management or product team, consider buying these books for the team's product management bookshelf.

22 Immutable Laws of Marketing: Violate Them at Your Own Risk
Al Ries and Jack Trout


This classic book enumerates and explains the principles that an organization should apply when making strategic marketing decisions.

A product manager leads the process of making such product decisions as which market problems to solve, the unique value proposition the product should embody, and which buyers and users to target.  Market knowledge is necessary to make informed decisions but is not sufficient.  Timeless principles of marketing are also essential for synthesizing this knowledge and applying it to actual strategic decisions about the product.

Your product manager has identified unsolved problems in the marketplace and how the market perceives competitors.  But how should the product team decide which of the unsolved problems to take on and what brand promise(s) the product should make that will resonate in the market?  Ries and Trout tell us that the Law of Focus, the Law of the Opposite, the Law of Sacrifice, the Law of the Mind, the Law of Candor, and other "immutable laws" should determine these types of decisions.


Running Lean: Iterate from Plan A to a Plan That Works
Ash Maurya


This new book is by a thought leader in the lean startup community who has refined and synthesized the best ideas of Eric Ries, Brant Cooper, Alex Osterwalder, and Steve Blank, and has melded them with a thorough understanding of both marketing and development.

You've heard about agile development. Is it really just for development, or does it encompass product strategy, marketing, and sales? Lean startup clearly encompasses all of them. In particular, you won't optimally define all aspects of your product strategy up front. Your product strategy is a set of hypotheses that you can methodically validate or invalidate using qualitative and quantitative measurements over time, enabling you to iterate and "pivot" as needed to optimize them.

The book tells us what goes into the business model for a product, describes each of its components in detail, how to make explicit the testable assumptions that underlie the hypotheses, and how to go about testing them quickly in your prospect interviews and by developing and releasing a minimum viable product (MVP).

At first glance, you might think this book is about entrepreneurship and product development.  It is, but it also squarely addresses questions central to product management at any organization.

Marketing Warfare
Al Ries and Jack Trout


My friend Prabakhar Gopalan makes a great case that strategy is not war, but this book nonetheless applies the warfare principles of Sun Tzu to marketing.  In particular, when your product team is making fundamental decisions about the unique value proposition and positioning of the product, it's essential for the team to understand these principles.

Ries and Trout describe how, depending on the competitive landscape, you should adopt an offensive, flanking, or guerrilla strategy. When conceiving and adjusting your unique value proposition, your product manager needs to identify the biggest competitor, understand its biggest strength in the market, identify the weakness within that strength, and turn the biggest weakness of your own product into a strength.

Not a lot of product managers are familiar with these concepts; your product managers can differentiate themselves and give you a business advantage if they understand and apply them.


Dirty Little Secrets: Why buyers can't buy and sellers can't sell and what you can do about it
Sharon Drew Morgen


If your product manager buys into the conventional wisdom, she understands that prospect problems lie at the root of many of the strategic decisions required for product success. This wisdom, in my opinion, is absolutely valid. However, it doesn't address an entirely separate set of factors that determine product success.

Before any buyer or user will adopt your solution, she must navigate all of the behind-the-scenes issues, emotions, and personalities that in many cases have nothing to do with the problem. The book teaches product managers this lesson and also to appreciate that they will never know - and don't need to know - what all these issues are. Product managers will learn from the book, however, some important skills they can apply to assembling the right people for prospect interviews and to facilitating those interviews.

In addition, a key challenge product managers face is getting buy-in for product decisions and driving the organizational change needed to execute on those decisions. To address this challenge, a product manager benefits greatly from understanding systems thinking, decision facilitation, and change management. The book explains how a "seller" (for our purposes, the product manager convincing the organization to adopt a new product strategy) applies this other set of skills that precede but enable the "sale".
 

Becoming a Technical Leader: An Organic Problem-Solving Approach
Gerald M. Weinberg


Especially when it comes to technology products, a product manager is a technical leader. He can't just inform the process of making product decisions; he also needs to unlock the synergistic talents of the entire product team to make and execute on the decisions. If the product manager has a technical background, it can be helpful, but it doesn't qualify him to be a technical leader.

This book teaches the soft skills and self-awareness necessary to transform a domain or technical expert into a problem-solving leader who brings out the best in others. "MOI" stands for:
  • Motivation. Provide the motivation for individuals and teams to work together towards common goals.
  • Organization. Create and integrate with processes that enable teams to work effectively.
  • Ideas. Manage the flow of ideas to foster innovation and problem-solving.
Got other product management books you'd recommend?  Add them to the comments, or tweet them with the #prodmgmtbookshelf hashtag.

Comments

brian piercy said…
I'll add three:

1) "Hooked: How to Build Habit-Forming Products" (Nir Eyal)
2) "Contagious" (Jonah Berger)
3) "The Hard Thing About Hard Things" (Ben Horowitz)

Enjoy!
Roger L. Cauvin said…
Thanks, Brian! Those books are new to me. I'll check them out.
brian piercy said…
No problem! While I'm at it...

http://platformed.info/

Great stuff for platform-centric business models. Highly recommended.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio