Product management overview

Great product management organizations help a company set product vision and road maps, establish goals and strategy, and drive execution on each product throughout its lifecycle. ¹

Bad product management organizations, in contrast, largely function as project management groups, running schedules and tidying up documents for engineers.

To build a great product organization you need to first understand the role of the product manager. Secondly, you need to hire individuals with the right skill sets, including a strong VP of product. Finally, establish a simple set of processes to enable the product organization and help the company scale its product development.

What do product managers do?

At a high level, a product manager (PM) is the single cross-functional owner directly responsible for the success of a product. Some pundits call PMs the “general manager of the product” or “CEO of the product.” In reality, a product manager is the directly responsible individual for a product—they have all the responsibility for the product’s success but often lack the direct line reporting of the other functions.

Product managers are responsible for:

1. Product strategy and vision. What is the goal of the product? Who is the customer? What are the primary features and use cases? How do we define success and what metrics can we use to track the product? What are the competitive dynamics and how should we position the product against competitors? How will the product differentiate? What are some key distribution channels? What is the business model for the product? How should we price the product? The product manager will work with many other functions (design, marketing, sales, engineering, data science, etc.) to answer the questions above, but should ultimately be in charge of asking and answering these questions.

The product strategy and vision should also reflect the voice of the customer. The product manager should be on top of incorporating user input and feedback into the product lifecycle.

2. Product prioritization & problem solving. Product managers “own” the product road map and are responsible for ensuring it has the right set of trade-offs. Tactical aspects of this include: writing and receiving feedback on PRDs (product requirement documents), organizing/directing product road mapping sessions, working with all the functions mentioned above, and making trade-offs on features versus impact and work needed. Crisp product requirement documents can make a world of difference in driving concise agreement on, and execution of, the product. PRDs should clearly articulate primary features and product needs.

“Crisp product requirement documents can make a world of difference in driving concise agreement on, and execution of, the product. PRDs should clearly articulate primary features and product needs.”

– Elad Gil

These responsibilities require a PM to be data- and customer-driven. Defining the right metrics, getting agreement on them, and then tracking them enables more alignment on product priorities. The more technical the product manager, the more likely they are able to analyze the data needed to make crucial trade-offs. In parallel, the product manager should strive to understand customer needs and then make trade-offs versus relative to engineering cost or business impact.

Product managers will also spend time problem-solving aspects of the product or its development. For example, how could the product be tweaked or changed to avoid a legal or regulatory issue? How could features be modified to address a competitive or pricing concern from sales?

Note: product managers will not work on this alone. Building a product, and solving related problems is a team effort. PMs will coordinate with engineering (technical constraints and feature ideas), design, data science, marketing, sales, support, legal (regulatory issues), and other functions. However, the ultimate role of product management is making or suggesting trade-offs between the pristine, platonic ideal of beauty that the design team wants, the technical pizzazz engineering desires, the “just give me some shit I can sell” of sales, and the “this may be risky” of legal (these examples are all purposefully exaggerated).

3. Execution: timelines, resources, and removal of obstacles. As part of driving the success of a product, product managers should work closely with engineering to set and hit goals on time. Often the biggest ways a product manager can help the team hit goals includes (a) lobbying for resources or attention from engineering, design, and other functions, (b) removing or prioritizing features and providing a clear road map for execution, (c) asking “stupid” questions to see if it is possible for each function to reduce timelines or remove unneeded features or work, and (d) pushing back on extraneous requests, whether those are internal (design, sales, etc.) or external (customers, partners).

Many people associate product execution as something that ends when you launch a product. In reality there is ongoing product maintenance, feature iteration, and eventually the sunsetting or killing of a product. Deprecating a product can be an art in its own right as you transition customers off, deal with pricing changes, or other issues that may cause customer backlash.

It is important to note that product managers are not project managers—i.e. a PM’s primary job is not just running a schedule.

4. Communication and coordination (overlays all of the above). Product managers should organize and communicate team status, progress, obstacles, and functional sequencing to the rest of the organization. This may include driving (or co-driving with engineering) weekly team status meetings, product reviews with the leadership team, and communicating launch or other timelines across the organization.

Often the hardest part of the communication is communicating the “why” behind the product road map, prioritization, and sequencing. Part of this will be creating a framework that establishes why some things are prioritized higher than others—and it’s important that all other functions buy into this framework.

Ultimately, product management will collaborate closely with, and at times have a natural (collaborative) tension with, engineering, design, and sales. Engineering will feel that since they are building everything, they should have the power to make product decisions. Design will think product management is redundant with design (these are very different functions,) and sales will wonder why product can’t ship faster and why the PM is always trying to keep sales people away from engineers (it is so engineers can focus on building the product without spending all their time on one-off sales requests).

Product managers should also function as the “buffer” or shield that protects engineers and designers from other internal and external parties. Sales and marketing people will always want to meet engineers directly to lobby for their favorite features, while customers will want to have a conversation directly with engineering. Product management should be a smart buffer for these interactions and consolidate all input and questions into a weekly internal team meeting, or the PM can act as the primary point of contact for sales. This will prevent sales, marketing, and other organizations from draining too much engineering and design time. That said, sometimes the best way to convince an engineer of a customer need is to put her in front of a customer. Hearing customer feedback first-hand can often change minds or shape a great brainstorm or problem-solving session.

Do you have the right people?

You can tell a good PM from a bad PM based on how much time they spend on each of the above. If a PM’s time is spent solely on checklists and project management, they either (i) have a weak engineering management counterpart they are covering for, (ii) are not empowered to do their job by company management, (iii) do not understand their job, or (iv) are not respected by their peers and cannot do more important work. Optimally, most product management time should be going towards defining the product, prioritizing trade-offs, spending time with customers, and working with various functions on launch, feature iteration, and communication. ² The hardest part may be to separate whether the right person is in the right role versus whether your company is empowering that person properly.

1. Ben Horowitz has a classic post on this topic. See eladgil.com. [https://a16z.com/2012/06/15/good-product-managerbad-product-manager/]
2. Ben Horowitz has a good post on this, although it is focused on 1990s enterprise-PMs. See link on eladgil.com. [https://a16z. com/2012/06/15/good-product-managerbad-product-manager/]