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 PM is the individual directly responsible 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:
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 PM will work with many other functions (design, marketing, sales, engineering, data science, etc.) to answer the questions above, but they 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 PM should be on top of incorporating user input and feedback into the product lifecycle.
Product prioritization and problem solving.
PMs own the product roadmap, and they are responsible for ensuring that it has the right set of trade-offs. Tactical aspects of this include: writing and receiving feedback on product requirement documents (PRD), organizing and directing product roadmapping sessions, working with all the functions mentioned above, and making trade-offs on features versus impact and work needed. Crisp PRD can make a world of difference in driving concise agreement on the product and its execution. PRD 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 those metrics, and then tracking them will enable more alignment on product priorities. The more technical the PM is, the more likely they are to analyze the data needed to make crucial trade-offs. In parallel, the PM should strive to understand customer needs and then make trade-offs relative to engineering costs or business impact.
PMs will also spend time solving problems on 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. The PM will coordinate with engineering (on technical constraints and feature ideas), design, data science, marketing, sales, support, legal (on 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 that 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.)
Execution: timelines, resources, and removal of obstacles.
As part of driving a product’s success, PMs should work closely with engineering to set and hit goals on time. Often the biggest ways a PM can help the team hit its goals include: lobbying for resources or attention from engineering, design, and other functions; removing or prioritizing features and providing a clear roadmap for execution; asking “stupid” questions to see if it is possible for each function to reduce timelines or to remove unneeded features or work; and pushing back on extraneous requests, whether those are internal (design, sales, etc.) or external (customers, partners).
Many people think of 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 away from it and deal with pricing changes or other issues that may cause customer backlash.
It is important to note that PMs are not project managers—their primary job is not just running a schedule.
Communication and coordination (overlays all of the above).
PMs 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 and product reviews with the leadership team as well as communicating launch or other timelines across the organization.
Often the hardest part of the communication is conveying the “why” behind the product roadmap, prioritization, and sequencing. Part of this will be creating a framework that establishes why some things are prioritized over 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 because these are very different functions, and sales will wonder why product management can’t ship faster and why the PM is always trying to keep salespeople away from the engineers. (It is so engineers can focus on building the product without spending all their time on one-off requests from sales.)
PMs 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 them in front of a customer. Hearing customer feedback firsthand can often change minds or shape a great brainstorming 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, then they have a weak engineering management counterpart they are covering for, they are not empowered by company management to do their job, they do not understand their job, or they are not respected by their peers and cannot do more important work. Optimally, most product management time should be spent 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 determine whether the right person is in the right role or if your company is properly empowering that person.
Characteristics of great product managers
When hiring product managers, you should select for the following skills:
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 toolkit to quickly learn about your customers and their needs.
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?
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.
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 cost of goods in order to scale market share faster. In response, their customers bought in volumes they had not projected until two 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.
Exceptional communication skills: Much of the job of a PM boils down to understanding and then communicating trade-offs to a diverse group of coworkers and external parties.
Ability to identify metrics and a 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 hardwired to only do one of the below well.
1. Business product manager
These product managers are strongest at synthesizing requests from external customers 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 the product roadmap versus the engineering effort needed. They will have keener insights into product pricing, customer segmentation, and customer needs.
2. Technical product manager
Technical product managers 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 trade-offs in the product.
3. Design product manager
Most commonly found working on consumer applications, design-centric product managers are more focused on user experience. Some companies will convert a designer to a 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 trade-offs 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 trade-offs 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 product managers tend to be quantitative, analytical, numbers-driven, and, in the best cases, wildly creative and aggressive. The focus of the growth PM is to determine the critical levers needed to drive product adoption and use and then 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 backend 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 few to zero 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 (APM) and rotational product managers (RPM)
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 or RPM works with a different product organization (e.g., ads, a consumer product, timeline, or search). APM and 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 product managers
When interviewing product managers, it is important to keep in mind the role you are hiring them 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:
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 or 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?
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?
Prioritization: Focus your questions around prioritization on the frameworks the candidate uses for making trade-offs rather than the trade-offs 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?
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 afterward? 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.
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 whether 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 they are 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 backchanneling, pursued appropriately, can be especially enlightening.
The best product managers have a history of launching products or features that otherwise would have gotten stuck. They successfully negotiate with engineering and design to make trade-offs that contribute to the success of the product, and they create a big strategic viewpoint that drives business success.