Can you describe the difference between a product manager and a product leader? Can you think of three aspects of product creation that a product leader must balance to deliver a successful product? Do you know what’s even more fundamental to great product management and leadership than developing a great process?

You’ll find expert-level answers to those questions, and dozens of other important product leadership questions, in the book Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams, by Richard Banfield, Martin Eriksson & Nate Walkingshaw.

The book covers a great deal of territory for product professionals. But if we had to distill it to a single thesis, it’s this:

Product leadership is distinct from product management, although if you’re a product manager you’re also acting as a product leader (or you should be). And that product leadership role is probably the most challenging and important role you have. Challenging, because you have a massive amount of responsibility but little or no organizational authority to carry it out. Important, because as a product leader you are responsible for the success or failure of your company’s products—and, by extension, the success or failure of your company itself.

Watch CEOs discuss how to practice resilient leadership during challenging times:

We love recommending books for product managers. And because product management is such a complex role, touching so many areas of the organization, sometimes our book recommendations aren’t exactly PM-specific. But Product Leadership is a wonderful book speaking directly to PMs, offering wisdom gained through the many decades of its authors’ combined product management and leadership experience working with industry-dominating companies like YouTube, Google, Airbnb and Intuit.

Here’s a brief overview of the types of product wisdom you’ll find in this great book.

1. A product leader must find the right balance between the three key aspects of a product: viability, feasibility, and usability.

In a real-world organization, with finite resources and competition for those resources, there is an element of zero-sum when it comes to striking the right strategic balance.

Tweet This:
“In a real-world organization, with finite resources and competition for those resources, there is an element of zero-sum when it comes to striking the right strategic balance.”

To be viable, the product needs to solve the big problem (and the right problem) for its users. But this won’t be cheap or easy, so next you’ll need to determine if doing this will be feasible. Do you have the resources, the time, and the in-house skillset to pull it off in a timeframe everyone (including your executive stakeholders) can live with?

And finally, can we build this thing to address our users’ needs and wants without making it a complex maze of features and processes they won’t abandon out of frustration? In other words, can we make a robust product that also delivers a great user experience?

2. Smart product leadership (and product management) logically leads to an agile development process, even if the product isn’t software.

Here is the authors’ logically unassailable argument for favoring an agile-oriented “ship often” approach to developing and improving your products:

“When the product is finally out in the market, the product manager should be spending their time poring over data and talking to customers face to face about the product to discover how they use it. Did it solve the right problem? Do the customers understand the product’s value? Will they pay for the product? Then the product manager goes back and does it all over again. When done optimally, this is not a waterfall process. There is too much to be gained from iterating in short cycles.”

3. Although every company and situation is unique, there are definite best practices for a product leader to establish a successful product organization.

The book offers a deep dive into all of the major steps a product manager or leader should take in setting up their product teams for success. Here’s a brief overview of those steps.

Start by establishing your high-level product principles.

These principles will help guide you and your team on the work you do. They’ll give you clarity.

The book quotes Intercom’s Product VP Paul Adams, for example, saying one of his product team’s principles is “ship to learn.” What a great mantra for any agile team!

Referring to principles like these when team members get into the weeds can obviously be a great help when they need to decide whether a product or new feature is “ready” to meet its users in the market. Because they’ve established this principle, the team will in most cases probably answer yes—and they’ll get more learnings, more quickly and more frequently, as a result.

Set a product vision.

As the authors explain, your product vision should be timeless and not tied directly to the products you’re building. They use Disney’s vision as an example: “Make People Happy.”

Once you have your vision set and your product principles in place, you now have pillars to guide your team on both the large, strategic questions (“Is that going to make people happy?”), and your more tactical questions (“If we hold the product back any longer, can we really say we’re shipping to learn?”)

Move from vision to strategy.

Here, the authors explain, the product leader needs to begin translating that lofty vision into concrete strategic goals—such as growing revenue, or breaking into a new market, or improving customer delight.

Also key at this stage will be earning buy-in from your executive stakeholders. Which is why, as the book emphasizes throughout, one of the most important skills a product leader must possess (or develop) is outstanding communication.

Translate your strategy to your product roadmap.

We couldn’t resist including this step in our summary, because our mission for years has been to advocate for the importance of product roadmaps.

We were also impressed with the book’s list of no-no’s for any roadmap, with which we agree wholeheartedly. Here are a few of the things they argue a roadmap is not:

• A roadmap is not a release plan.
• A roadmap is not a list of product features.
• A roadmap is not a commitment. (It’s a living guide.)

There are plenty of other great sections in the book, such as:

• How to identify great product leaders
• How to hire great product leaders
• What makes a successful product team?
• What are the big challenges for startup product leaders?
• What are the big challenges for enterprise product leaders? (Hint: They’re very different from the challenges a startup leader faces.)

And there’s a lot more. Our recommendation: Read the book. Then, if you’re so inclined, we hope you’ll return to the ProductPlan blog and share what you learned from it in the comments section below.