The Product Book: How to Become a Great Product Manager

by Product School

One of the most important parts of being a product manager is knowing who your customers are and what they need.

Much like chess, poker, and Minecraft, product management is easy to learn, but can take a lifetime to master.

“Nobody asked you to show up.” Every experienced product manager has heard some version of those words at some point in their career. In this case, those painfully frustrating words are from Ken Norton, partner at Google Ventures, in a blog post titled “How to Hire a Product Manager.”

Engineers build the product. Designers make sure it has a great user experience and looks good. Marketing makes sure customers know about the product. Sales gets potential customers to open their wallets to buy the product. What more does a company need? Where does a product manager fit into that mix?

Truthfully, without a product manager a company will continue to operate pretty well—to a point. Yet with a strong product manager a company can become great.

What Do Product Managers Do? Put simply, a product manager (PM) represents the customer. No one buys a product because they want to give the company money. Customers buy and use products because the products address their needs. Done properly, the products let the customers be awesome. The end result of representing the customer is that a PM helps the customer be awesome.

Day to day, PMs must understand both business strategy and execution. They must first figure out who the customers are and what problems the customers have. They must know how to set a vision, finding the right opportunities in a sea of possibilities, by using both data and intuition. They must know how to define success, for the customer and the product, by prioritizing doing what is right over doing what is easy.

They must do whatever’s needed to help ship the product, finding solutions rather than excuses.

PMs manage products, not people, so they must achieve everything using soft influence, effective communication, leadership, and trust—not orders.

PMs do so much that they’re sometimes even called “Mini CEOs.”

A large part of a PM’s job is to figure out the small number of key features to prioritize for the customer, and to lay the groundwork for long-term business viability by gracefully saying “no” to the numerous requests that don’t fit the customer’s needs.

The project manager will often work with the product manager, and a product manager will provide input on the schedule.

Project managers are masters of schedules and Gantt charts, not of representing customers.

Program managers tend to be masters of execution, sort of like a “super” project manager.

Microsoft, for example, calls its product managers “Program Managers.” Apple generally splits the product manager role into the “Engineering Program Manager” (EPM), and the “Product Marketing Manager” (PMM), with the PMM being closer to our definition a product manager, and the EPM being closer to a project manager.

Product managers are like the conductor in an orchestra. The conductor never makes a sound but is responsible for making the orchestra as a whole sound awesome to deliver a great performance to the audience.

diplomatically moving everyone together toward the shared goal of a great performance.

Project managers help keep all the rehearsals organized so that the orchestra will be prepared for the concerts. Program managers are involved in planning the entire season’s schedule for the concert hall, setting things up so that the project managers can make each performance successful.

Given that the role often comes down to “doing whatever it takes to ship a product that customers will love and that achieves business goals,” product managers should be smart, talented people who can figure things out on their own.

conducting customer interviews, working with Design to validate ideas, and possibly even collaborating with marketing to make sure what they’re working on aligns with customer needs.

At Product School, we often talk about the Product Triangle (Figure 1-1). This is a simple way to visualize and understand where product management (ideally) sits in relation to other core departments: Engineering (product development), Design, and Marketing.

Thinking about which leg of the triangle you’re focusing on will let you think about the right way to communicate—you’ll talk with Design differently than you do Engineering—and the right goals to set during each phase.

They need to know enough that they can work effectively with engineers, participating in things like bug prioritization and scoping meetings, but they don’t need a computer science or electrical engineering degree. Especially for software PMs, knowing how to code even a little will be beneficial, and if you want to become a PM but don’t know how to code, we’d highly recommend learning the basics.

Who are the customers? Who are the major players? What differentiates one company from another? How do the businesses make money?

revenue is how much money a company takes in, and profit is how much is left after expenses.

After you have a few years of product management experience, it’s fairly easy to switch to a new domain, as you know the right questions to ask to be successful. If you’re a founder looking to build your start-up’s product team, we’d recommend focusing on finding the best product person possible, even if that person isn’t familiar with your domain.

person might work on a software API where the end customer is a software developer. Technical PMs won’t be writing the code or performing technical tasks, but they need to understand the details of what goes into those tasks.

strategic product management. This role is the complement to a technical PM, and it’s someone who has a strong business-oriented background.

growth product manager or mobile product manager.

products continuously undergo a product-development life cycle, and a product manager shepherds the product through each phase, owning some phases and contributing to others. The product-development life cycle involves discrete steps, and each step emphasizes a different leg of the Product Triangle.

lean approach, based on Toyota’s manufacturing methods and adapted to software/product development by Steve Blank and Eric Ries.

very fast, iterative cycles where your goal is to make something small, release it, learn from it, and use that knowledge to figure out what to do next.

you risk a little bit to build something small, learn from it, and iterate. For that reason, even larger and older companies are shifting towards a lean approach, moving away from waterfall.

The most common approach you’ll encounter is a hybrid of waterfall and lean where the PM will plan a bit upfront to find the right opportunity, but then the teams will implement the product in an iterative way.

Hardware product development takes a more waterfall approach because it’s harder to change things you’re physically building.

Every product goes through five key conceptual stages: 1. Finding and planning the right opportunity 2. Designing the solution 3. Building the solution 4. Sharing the solution 5. Assessing the solution

Usually, it’s up to the product manager to create and sort through all the possibilities, picking the right one to focus on next.

Unlike the other phases, where other disciplines take the lead, this phase is where product leads, taking input from other disciplines. It’s probably the most different from anything expected in another position.

breaking it down into three parts: strategically understanding a company (Chapter 2), creating an opportunity hypothesis (Chapter 3), and validating that hypothesis (Chapter 4).

At a high level, company goals fall into three categories: growth, revenue, and customer satisfaction.

If the goal is revenue, how does the company currently monetize their product, and how can you increase the value for customers to make them more willing to pay for the product?

If the goal is growth, what’s stopping new customers from using the product?

If the goal is to delight their customers, what can you deliver that they would l...

What is the company building now? What does it excel at compared to its competitors? Who are the key customers you aim to solve a problem for? What’s the company’s vision, and—more fundamentally—why does the company exist?

What do you believe is the right thing to work on next? It could be something as small as fixing a bug that’s been in your backlog for a while, or something as large as building an entirely new product.

Collectively, your metrics can provide some great insight! From metrics, you might find an opportunity, such as wanting to get higher engagement with a component of your product.

“We should prioritize video content instead of text because people tend to watch videos to completion and see each ad, whereas very few people read articles to completion.”

But before you start to build a feature, you should do some type of validation work to ensure this is the right opportunity to pursue, and that it actually will help you achieve your goals.

Scoping means clearly defining the opportunity and the customers you want to target, along with the requirements for the solution.

“What’s the most minimally featured thing you can build that will address the opportunity well for most of your target customers and validate your opportunity?”