Introduction

This guide is an excerpt from Elad’s book, High Growth Handbook, which presents a playbook for navigating the most complex challenges that startups face.

Great product management organizations help a company set product vision and roadmaps, 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 roadmap and are responsible for ensuring it has the right set of tradeoffs. Tactical aspects of this include: writing and receiving feedback on PRDs (product requirement documents), organizing/directing product roadmapping sessions, working with all the functions mentioned above, and making tradeoffs on features versus impact and work needed. Crisp product requirements 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.

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 be able to analyze the data needed to make crucial tradeoffs. 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 tradeoffs between the pristine, platonic ideal of beauty that the design team wants, the technical pizazz 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 roadmap for execution, (c) asking “stupid” questions to see if it is possible for each function 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 roadmap, 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 tradeoffs, 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.

Characteristics of great product managers

When hiring product managers, you should select for the following skills:

1. Product taste. Product taste means having the insights and intuition to understand customer needs for a product in a given area. What product features will wow a customer or meet their core needs? If the PM is joining you from another industry they may not know the specific needs of your customers. However, they should have the skill set and tool kit to quickly learn about your customers and their needs.

2. Ability to prioritize. What is the value of a proposed product feature versus the engineering work needed to accomplish it? What is more important – a new product for the sales team or a feature for customers? Should pricing be optimized for consumers or small business owners? What is the 80% product that should be launched immediately and what singular customer problem does it solve?

3. Ability to execute. A big part of product management is convincing and cajoling teams and different resources to get the product to launch, and then to maintain the product and support the customer base. Product managers will partner with engineering, design, legal, customer support, and other functions to execute on the product roadmap.

4. Strategic sensibilities. How is the industry landscape evolving? How can the product be positioned to make an end run around the competition? Intel’s famous pricing strategy in the 1970s is a good example of a bold strategic move. At the time Intel understood there was a strong reduction in their own costs as they scaled unit sales. Dropping unit sales would lead to increased demand and volume, causing a virtuous cycle. Intel smartly decided to launch a new silicon product at cost below their COGs in order to scale market share faster. In response, their customers bought in volumes they had not projected until 2 years out, causing a massively lower cost structure for them and therefore profitability. In other words, their low pricing became self-fulfilling and sustainable through massive volumes years ahead of projections.

5. Top 10% communication skills. Much of the job of a product manager boils down to understanding and then communicating tradeoffs to a diverse group of co-workers and external parties.

6. Metrics and data-driven approach. You build what you measure. Part of the role of a product manager is to work with engineering and the data science team to define the set of metrics the product team should track. Setting the right metrics can be hard, and even the right metrics can sometimes drive the wrong behavior.

The four types of product managers

The product manager you hire depends on the type of product your company is working on. Often companies need a mix of the below. Some people can function as more than one type of PM, while other individuals are hard wired to only do one of the below well.

1. Business product manager

These product managers are strongest at synthesizing external customer requests into an internal product roadmap. Business PMs tend to thrive at enterprise software companies, or working on the partner-facing portions of consumer applications. They can work well with sales and present well to customers, yet are still technical enough to work with engineering and design to trade off roadmap versus engineering effort needed. They will have keener insights into product pricing, customer segmentation, and customer needs.

2. Technical product manager

Technical PMs are often (but not always) deeply technical people who can work with engineering on areas like infrastructure, search quality, machine learning, or other inward-facing work. Technical PMs can often work on a wide variety of products across enterprise and consumer as long as they can pick up the necessary business skills and have good user intuition to make the right tradeoffs in the product.

3. Design product manager

Most commonly found working on consumer applications, design-centric product managers are more user experience centric. Some companies will convert a designer to be the product manager for a consumer product. While designers are often incredibly talented at user experience and visual design, they may not be trained in making the tradeoffs needed to run a business (e.g. advertising models, pricing, etc.) or may want a product to be pixel perfect (which means it will take longer to ship the product). In general, it is good to retrain design people who become product managers to focus more on pragmatic tradeoffs between beauty and marketing. Design PMs spend the most time with internal engineering and design teams and tend to spend less time on outward facing or business-centric tasks.

4. Growth product manager

Growth PMs tend to be quantitative, analytical, numbers-driven, and in the best cases wildly creative and aggressive. The focus of the growth PM is to (i) determine the critical levers needed to drive product adoption and use, and then (ii) to manipulate those levers. For example, the growth team at Facebook added tens of millions of incremental users via email loops, funnel optimization, and large scale multivariate testing of sign up, conversion, and other flows. Growth PMs tend to work closely with engineering, marketing, UX, and in some cases partnership or deal teams. Sometimes growth marketing will play the role of growth product management and this role will report into marketing.

In general, the more technical and back-end heavy your product, the fewer product managers you will have. A database company is likely to have a much lower product manager to engineer ratio than a consumer Internet company. When I was at Google, the search infrastructure team had a few to none product managers while the mobile team, which was more UI-centric and business-centric, had many (despite a much smaller engineering organization).

Not a product manager: Project managers.

Do not hire project managers as product managers. While project managers may be great at organizing and driving a schedule, they often lack the ability to prioritize features or ask the larger strategic questions. In general, project managers are not needed in high functioning software organizations, where a mix of the engineering manager and product manager will take on project management. Project managers may become useful for hardware products, external partner implementations or vendor-specific hardware integrations.

Associate product managers (APMs) / rotational product managers (RPMs)

Google and Facebook have developed extensive programs for more junior product managers joining these companies straight out of undergraduate programs. The Google program consists of two 12-month rotations, while the Facebook program is three six-month rotations. For each rotation, an APM/RPM works with a different product organization (e.g. ads, a consumer product, timeline, or search). APM/RPM programs are meant to grow an internal crop of future product leaders for each company. As your company scales to 1,000 or more people, it might be worth considering an APM-like program. Don’t do this until you have a solid internal senior product management organization in place.

Interviewing PMs

When interviewing product managers, it is important to keep in mind the role you are hiring her for (see the previous section “The Four Types of Product Managers”), as well as the generic capabilities sought out in all product managers (see “Characteristics of Great Product Managers”) and all hires (culture fit etc.).

Key areas to push product managers during interviews are:

1. Product insights. What products do you use daily? How would you change X product? How would you design X product for a specific set of users? What features would you add? What would you drop/discontinue? If you were starting a company from scratch, what product would you start with, and why? For example, how would you design a mobile phone for children?

2. Contributions to past successful products. When I worked at Google, I overlapped with some of the strongest product people I ever met. I also overlapped with a number of terrible product managers who happened to be at the right place at the right time. When interviewing a product manager from a successful product, it is important to dig into their specific contributions. For example: What role did you play in the product definition and launch? Who came up with which product features? Who drove the idea to price the product X way? Etc.

3. Prioritization. Focus your questions around prioritization on the frameworks the candidate uses for making tradeoffs, rather than the tradeoffs themselves. You can initiate these questions by providing a scenario or case study to work from. For example: What is a real world example where your company had multiple potential product paths to invest in but could not do all of them? How would the PM approach this decision-making choice? What factors would fold into it? What data could be used? What is an example of a product feature that the executive team requested that you pushed back on or had removed?

4. Communication and team conflicts. Have you been able to sell a vision or product to your last company’s leadership team? What disagreements or conflicts did the PM have with engineering or design? How were these disagreements resolved? How does the PM actively build relationships with other parts of the organization? What communication approaches does the PM use? What is important to communicate, and when? What is an example where a miscommunication caused an issue for a product? How was this resolved and what changed from a process perspective after? In general there is a natural tension between product, design, and engineering. Conflicts may arise naturally in a fast-paced environment. The key is how to build relationships to surmount disagreements and how to resolve conflicts if they do occur.

5. Metrics and data. What metrics did the PM track for their last product? How did they choose these metrics? What bad behavior could these metrics have driven and how would you avoid this behavior? What metrics would the PM track for your company’s product? Why are those the right metrics? How often and in what context should metrics be reviewed? How do you evaluate if a product launch has been successful?

Reference check all your product hires

For all hires, reference checking is incredibly important. For product managers, it’s even more important. With an engineering candidate, an interview can reveal if she is technically competent. For a product manager there is no easily testable metric of competence. Instead, past work is the strongest single indicator of whether someone may be successful again in the future. Informal backchannel, pursued appropriately, can be especially enlightening.

The best product managers have a history of launching products or features that would otherwise have gotten stuck, successfully negotiating with engineering and design to make tradeoffs that contributed to the success of the product, and creating a big strategic viewpoint that drives business success.