Chapter 1: What is Product Management?

“Nobody asked you to show up.” These simple words of truth are from Ken Norton, partner at Google Ventures, in a blog post titled “How to hire a product manager.” Think about a company for a second: 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 wallet up to buy the product. What more do you need?

That simple question is what causes a lot of the confusion and opportunity about product management. Truthfully without a product manager, a company will continue to operate pretty well. Yet with a strong product manager, a company can become great. Before we dive into what product management is, let’s talk about what it is not.

Project managers are often confused with product managers, perhaps because they have the same abbreviation, “PM.” While there are many subtle differences, we can sum up and say that a project manager owns the schedule and helps ensure the team is on track to meet any deadlines. The project manager will often work with the product manager, and a product manager will provide input to the schedule. Sometimes, a product manager has to act as a project manager, too. But project management skills are often not a product manager’s key strengths.

Program managers are usually a bit more similar to product managers, but program managers generally focus more on the “getting it built” side, working with engineering and operations closely. If you’re manufacturing hardware in Asia, for example, the program manager will likely be in touch with the manufacturing facility frequently whereas a product manager will have limited direct interaction with the facility. Program managers tend to be masters of execution, sort of like a super-project-manager.

To further confuse things, the title that describes what a product manager varies slightly company to company. Microsoft, for example, calls their product managers “program managers.” Apple generally splits the product manager role into the engineering program manager (EPM) role and the Product Marketing Manager role, with PMM being closer to what we’ll define as a product manager and EPM being closer to a project manager.

Ugh! So product managers don’t generally code, design, create pixels, own the schedule, ask the buyer to open their wallet, or even have a consistent job title. What the heck do they do?

Put simply, a product manager represents the customer, and they help make the customer awesome. No one buys a product because they want to give the company money. Customers buy and use products because it enables them to do something cool, and a PM ensures the customer can be great. There’s a lot behind this simple definition, though. Adam Nash summed up product management by saying PMs figure out what game a company’s playing and how they keep score (hint: it’s not always how much money did they make).

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 using both data and intuition. They must know how to define what success for a product will mean. They must understand how to work with engineering and design to get the right product build. They must know how to work with marketing to explain to the customer how the product fills the customer’s need better than a competitor. They must do whatever’s needed to help ship the product. Oh and by the way, PMs manage products, not people, so they must achieve everything using soft influence and leadership, not orders.

Even though no one asked you to show up, now that you’re here, you’re going to do a lot!

Ironically, the thing you do the most is saying no. Some people believe that product managers just dictate what features to build, and given everyone has lots of feature ideas, why bother with a PM? It’s true that everyone has lots of ideas, some of them good, but most ideas people have are things they want, not necessarily things a customer wants. For example, think of an engineer you know who spends her days writing code in emacs or vi and who wrote her resume in LaTeX using vi. (I’m sure you know someone like this!) This engineer likely prefers keyboard shortcuts, dislikes GUIs, and likes using code to explicitly specify meaning. Now imagine that engineer is part of a team working on an iPad word processor for senior citizens. Do you think the features the engineer would prioritize match what the customers want? A large part of a PM’s job is figuring out the small number of key features to build for the customer and gracefully saying no to the numerous requests that don’t fit.

Becoming a PM

Most careers have a very clear-cut path: you go to school and study computer science, and then you’re set to become an engineer. Product isn’t one of those careers.

Because product is a newer discipline, there is much less formalized training or processes. Given the role often comes down to “do whatever it takes to ship a product that customers will love and achieves business goals,” you want smart, flexible people in the role! This means product managers are fundamentally smart, talented people who can figure things out on their own.

Beyond being smart, product managers commonly have an intersection of a technical background (not just engineering), industry expertise, and communication skills. The most common type of product managers are people with an engineering/computer science background who become interested in business. They often start out as individually-contributing engineers and then find themselves taking on more responsibility, conducting customer interviews, working with design to validate ideas, and possibly even working with marketing to make sure what they’re working on aligns with customer needs. They’re not necessarily the best coders or absolute best domain experts, but it’s their mix of skills that make them unique. But sometimes PMs come up from design, marketing, or even business school!

A common question is how technical do PMs have to be? You need to know enough that you can work effectively with engineers, participating in bug prioritization and scoping meetings, but you don’t have to have a computer science degree. Knowing how to code even a little will be beneficial, and we’d highly recommend using a resource to learn the basics. Fortunately there are plenty of resources to help you learn, whether you enroll in a bootcamp like CodeSchool or HackReactor or take an online course from lynda.com or Udemy.

Another common question is how business-oriented to PMs have to be? You don’t need an MBA (in fact some tech companies prefer not to hire MBAs) nor do you need a sales background. But you should understand the industry the company you’re interested in works: who are the customers? Who are the major players? What differentiates them? How do the businesses make money? You should also have an understanding of basic financial concepts like revenue vs. profit.

In general, when we’re working with people who want to make the transition to being a product manager, we always recommend they start with an industry/company they’re already very familiar with. That makes for an easier transition because they likely know the answers to many of those questions even if they don’t explicitly realize it! After you have a few years of product experience, it’s fairly easy to switch to a new domain as you know the right questions to ask to be successful.

At Product School, we often talk about the product triangle (Figure XXX). This is a simple way to visualize and understand where product (ideally) sits in relation to different core departments, engineering, design, and marketing. This diagram is helpful for two reasons: one, it visually emphasizes that product is really a generalist role, and you need to be able to work with significantly different domains. Second, as you go through the process of building the product, you will shift your balance to different parts of the triangle (more on this shortly). Thinking about which leg of the triangle you’re focusing on will let you think about the right way to communicate and the right goals to set during each phase.

Figure XXX: The product triangle, showing product management at the intersection of three core domains.

Introducing the Product Life Cycle

While sometimes it might seem like someone imagines a product in the shower and then tells the engineering team to build it, product only works like that on TV. (Of course rather than telling the engineering team to build it, on TV you’re more likely to see the guy get out of the shower and start hacking on a laptop with bright green text, occasionally solving a hard problem by drawing on glass. The real world doesn’t work like that either.) Products have “life cycles,” and a product manager will shepherd the product through each phase, owning some phases and contributing to others. A life cycle involves discrete steps, and each step shifts the emphasis of the product triangle. Future chapters will cover each of these steps in depth, but let’s look at a high-level overview.

Finding the Right Opportunity

The very first step of the product life cycle is to find and clearly define the right opportunity. The world’s a sea of possibilities! What should you build? Sometimes there’s a clear mandate from someone about the product you’re going to build: the CEO has mandated we’re building an Apple Watch app next. Other times it’s completely vague and up to the product manager to find the right opportunity.

The first thing a product manager should do is look at the company’s context. What are its current strengths? What is the company building now? What does it excel at compared to the competitors? What’s the company’s vision and more fundamentally, why does the company exist? Who are the key customers you aim to solve a problem for? A simple example is that if you have a web services company, it’s likely that your strength is building web apps quickly. It would be very hard for that company to suddenly decide to build a smartwatch or other hardware product.

A big question to ask initially is what are the company’s goals? Generally company goals fall into two categories, growth and revenue. Specifically, do they want to get more users for the product or do they want to increase their revenue from the current customers? If the company has a clear goal for the short term, that will likely influence what you pick to work on next.

Next, if you have current users for the product, what do they think of it right now? If your goal is growth, what’s stopping new customers from using your product? If it’s revenue, how do you currently monetize your product, are how do you increase the value to your customers to get more of them to be willing to pay for the product?

You will likely also have some data about how customers use your product. This data is called metrics, and it can provide some great insight! For example, cnn.com likely keeps track of what headlines you click on, how many people start watching each video, how many finish watching each video, how many scroll down and read each article, and more. They might then use this data to pull out conclusions, such as “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.”

After looking at the company’s context and goals, talking with users, and looking at usage data, you’ll likely have an idea about what to do next. This topic is so important and there are so many subtleties, we’ll cover it in more detail in the next few chapters.

Once you’ve found an opportunity, you’ll begin to scope it. Scoping it means clearly defining the opportunity and the customers you want to target along with the requirements for the solution. For example, if you’re building a pen, do you need it to work in space? Underwater? Upside down? You’ll want to clearly define these situations to help everyone else understand what the product will need to do when it’s finished.

We sometimes talk about a “minimum viable product” (MVP). This simply means what’s the most minimally-featured thing you can build that will address the opportunity well for most of your target customers. For example, while many of us would like to drive a Ferrari, a Tata Nano that’s 1/200th the price of a Ferrari will safely get us from point A to point B in a similar amount of time, even if it’s not as comfortable, featured, or enjoyable. The Tata Nano is an MVP for a car. It’s good to identify the MVP for your product since it will help with decision making later, helping you identify the features you have to build. If we’re building a car, and you only have time to build one feature, you should prioritize the brakes over satellite radio since brakes are part of the MVP but satellite radio isn’t.

Just as important as scoping the problem is defining your success metrics. What are your goals with the product, and how do you keep score as to if you’re achieving them? Going back to our pen, our goal might be to make the best writing instrument out there, and perhaps we define success initially by how many people buy our pen over a competitor’s. We might have a secondary success metric of how many people buy replacement cartridges for our pen, indicating that they like it and are continuing to use it. The reason we don’t just use “how many people buy cartridges” is that it will take time from when people buy it and start using it until they need cartridges, and it’s always good to have success indicators as soon as possible. Plus it’s useful to measure what percentage of people who buy our pen like it enough to buy cartridges rather than just the raw number of cartridges sold.

Product managers create a document called a Product Requirements Document (PRD) that contains the explanation for why we’re pursuing this opportunity, the scoped problem definition, and the success metrics. Over the product life cycle, the PRD will expand to contain more information, but it starts by clearly stating the problem and why we’re working on it.

What a PRD does not contain, however, is the problem’s solution. It will be up to design and engineering to figure out the right way to solve this problem, not the product manager. After all, the design and engineering teams are the experts in their domains. The product manager is not, even if she started her career in one of those domains!

Furthermore, even though the PM will do the bulk of the work to identify the opportunity, you don’t do the work in isolation. You will work with many other people from your boss to your teammates to the engineering, design, and marketing leads to make sure that you’ve identified the right opportunity.

The first phase of the product life cycle is finished when we have this partially-completed PRD, clearly identifying the opportunity/problem and success metrics, and all stakeholders have agreed it’s the right problem to focus on next.

Design a Solution

The next phase of the product lifecycle shifts the emphasis of the product triangle from the middle (product management) to the top (product design). In this phase, we’ll figure out a solution to the problem we’ve identified that is feasible to build.

During this phase, PMs will primarily work with the design team, but the engineering team will offer input as well to help gauge feasibility. For example, we could say that nuclear fusion is the answer to our energy problems, but as of the time of writing, it’s not feasible to implement, so it’s not the right solution.

Even though the PM won’t be coming up with the solution, she’ll stay actively involved in this phase. She’ll likely work closely with design to conduct user research, looking at people’s current behavior. She’ll also help communicate with engineering to make sure design isn’t working in isolation.

Contrary to popular belief, design doesn’t just mean what does the solution look like. Design involves aspects like information architecture (what order are things presented to the user), wireframes (where should the information live on the screen), and pixels (how does it look). It’s uncommon to find a designer who’s an expert on every one of these aspects, and a PM will likely be working with a design team to figure out how the product should function and look.

If possible, you’ll want to produce prototypes of your solutions that you can test with customers to validate the design. These prototypes could be printouts that you swap in when the customer “clicks” on something, clickable mockups working with fake data, or more. The key is to have something that accurately represents the solution but that you can mockup without having to actually build the design.

Design is done when you have validated a prototype as a suitable solution, engineering has agreed to the viability of the solution, and you have mockups that define the look/feel of the solution that all stakeholders have agreed to.

Building the Solution

Once you’ve defined the problem, come up with a solution, and tested the solution as much as possible with customers, it’s time to build it. This is where we shift to the development leg of the product triangle.

Companies have different approaches to implement the solution depending on their history, the product, and their desires. For example, if you’re working on a mobile app, it’s very easy to release a new version to customers every week, and development is likely focused around smaller but more frequent releases. If you’re building hardware, it takes a long time between design and when the hardware’s ready for mass production. Hardware engineering companies generally have fewer but very high-quality releases. After all, it’s hard to release a hardware update to fix a bug!

In Chapter XXX, we’ll cover some of the most common software development methodologies. Suffice it to say, the PM will stay involved throughout development, helping to prioritize bugs, test software, and do whatever’s needed to help the product ship.

A note of caution if you’re currently an engineer who wants to transition to product: development might turn out to be the most frustrating phase to you because you are not an engineer anymore. You will not be writing code for the product or telling people what code to write. Your job is to stand aside and let the people who are still engineers write the code. You help them however else you can, even if it’s getting them coffee, but don’t tell them what to do unless they ask for your help.

Also, while we’re presenting the product life cycle in a very linear fashion, it’s a lot more iterative in real life. For example, while design will have figured out the most common use cases in the prototyping stage, there are likely many edge cases that will come up while engineering’s building the product. Product, design, and engineering will work together to address these needs and questions that come up while working on the product.

New information might come up during development that affects the product’s scope, too. Going back to our pen, perhaps we find out that it’s significantly more expensive to build a pen with replaceable cartridges, and after doing some analysis, the team decides to make a non-refillable pen instead.

It’s always best to do more investigation up front so that you don’t waste resources designing a solution and then have to change large parts of it. But the best product managers are ones who know they can’t define everything perfectly up front and that it’s generally impractical spending months trying to do so. Instead, they do their best and react to new information and changes with open arms.

A PM should try and find opportunities to share prototypes of the product during this phase with customers or others inside the company so that you can get early feedback about the product. Does it address the customer’s need effectively or is there a big tradeoff you didn’t anticipate? If you prioritize building the minimum viable product you previously identified, then you can start testing the core product once the MVP’s ready.

This phase of the product life cycle is done when a working product that has been thoroughly tested is ready for release.

Share the Solution

As much as we’d like to believe that if we build it, they will come, the world doesn’t work that way. Product marketing is an incredibly important part of the product life cycle. This is where we share our product with the world and let our customers know how our product will make them awesome. Here we shift to the final leg of our product triangle, marketing.

Effectively telling the world about our product is so important some companies even split it into a separate position, Product Marketing Manager. A PMM is very similar to a PM, but a PM tends to be more internally focused (getting the product build) while a PMM is externally focused (working with customers, understanding their needs and communicating it internally, and communicating what the product will do for a customer to the customer).

Early on in the definition stage of the product life cycle, it should be clear what this product will do for the customer. This isn’t a list of what features it has or what the product does but rather what problem it will solve. In this phase of the product life cycle, you will figure out how to succinctly and effectively communicate how the product will make the product awesome to the customer. It’s essentially storytelling, and we call it “messaging.”

For example, going back to our pen, perhaps what’s special is that our pen is completely compostable/bio-degradable, and our target customer is someone who’s environmentally conscious. You wouldn’t start by telling the customer it has black ink (a feature), nor would you simply say “it’s a writing instrument” (what it does). Instead you would focus on why it matters to the customer, such as “it’s the first guilt-free disposable pen.” Then you could expand on the core message and say “it writes as smoothly as the nicest pen you’ve ever used, but once you’re done with it, it won’t sit around in a landfill for thousands of years. It will biodegrade within 10 years.”

This phase of the life cycle is more than just figuring out the product’s message, though. Here, we will plan for the product’s release. This might involve planning a beta test, creating marketing assets for a website or ad, working with key partners before release, briefing the press, or planning a launch event. The exact needs will vary from launch to launch.

Broadly, this phase of the life cycle is done when the product’s launched, but there will likely be many marketing campaigns and tasks to help achieve the product’s success metrics beyond the launch. These will often continue even while the team internally has moved on to the next version of the product or a completely different product. This phase is really finished when the team choses to stop actively marketing this version of the product.

Assess the Solution

The last phase of the life cycle is to look at how the last pass through the product life cycle went, see if you’re on track to achieve your success metrics, and to come up with a recommendation for the next iteration.

Specifically, the first thing to do is to meet with the team that you build the product with and assess how it went. Did everyone get so burned out that half the team quit? Was the team very happy with the process and excited to work on the next project? What went well, and what should you do differently the next time around?

Next, now that the product’s released, you should start seeing real data about how people are using it. Is it in line with your expectations, or is something far off? This will be a mix of data you automatically collect and reaching out to customers with surveys and interviews. And most importantly, does it look like you’re on track to achieve your success metrics? For example, if your success metric is how many people sign up, are people signing up for your product, and if so, how many? If they’re not signing up, try to get data about why by doing customer interviews and surveys.

The final part of this phase is to put together a recommendation for what’s next: is there more to do on this feature/product to achieve your success metrics, is this product good enough for now, and it’d be best to move on to the next product, or is this product just not achieving what you want no matter how much you do and it’s best to discontinue it? This recommendation will help inform the next iteration through the product lifecycle.

As you can see, there’s a lot to product management and the product life cycle! But don’t worry, the following chapters will break things down into more detail and help you understand how to be a great product manager who makes awesome products that customers love.