Among the many roles within technology and product companies, most are well-defined with a clear and definitive understanding of the roles and responsibilities expected, with strong similarities found across the field. Developers write code; quality assurance tests use scenarios; SDETs combine development and testing; ops teams deploy the finished product; etc. Product management, on the other hand, tends to be much more flexibly defined, with no guarantee from one place to another precisely what the role will be, what the responsibilities will be, or even what deliverables are expected from the person filling the position.
To some extent, this is expected — the role of product management is one that is to some degree a jack-of-all-trades position, one that fills in the gaps wherever needed in the organization in order to succeed. But at the same time, there are some very specific responsibilities that all product managers should be expected to deliver against, and that anyone taking a product manager role should push to be charged with.
Product Management Myths
But, before we talk about those things, we should discuss some of the most common and troublesome myths about product management. Many of these have grown over time, spread by people who don’t really understand the roles and responsibilities of product managers, or by people sticking to old-style definitions of the role from the days when waterfall development and command-and-control management styles were the norm.
Myth: “The Product Manager is the CEO of the Product”
This is one of the most pernicious and misleading myths that is constantly spread around by a variety of players within the product management community. It certainly sounds attractive, and plays directly to the entrepreneurial spirit that most product managers have, and that drives those who are not already product managers into the role. But, the simple fact is, it’s such a vast overstatement of the role as to be virtually useless — it’s a throwaway sound bite that has long since outlived its usefulness.
Certainly, there are some similarities between the CEO and the product manager:
- Both roles have to make decisions that are often based on incomplete information;
- Both roles need to clearly communicate the vision, strategy, and tactics of the organization;
- Both roles need to coordinate and facilitate between vastly different parts of the company; and
- Both roles are highly accountable for the outcomes of their efforts to bring a product to market.
But the differences are stark and dramatic:
- The CEO is beholden only to the board of directors, if anyone; the product manager is beholden to the entire leadership chain up from their role in the organization.
- The CEO can and does make flat decisions that everyone must follow; the product manager rarely has authority to tell others what to do.
- The CEO is directly responsible for the financial performance of the organization as a whole; only in rare circumstances is the product manager directly responsible for the P&L line of their product.
- The CEO can make hiring and firing decisions when they are unhappy with the performance or attitude of an individual; the product manager must learn to work with the resources they have available, regardless of their performance or attitude.
Given these differences, it’s really not true that the product manager is the “CEO of the Product” in any really meaningful way; rather, we should view the product manager as the “leader” of the product, who moves the product and the company forward through influence and example.
Myth: “Product Managers Must be Technical”
Another pervasive myth about product management is that you must be “technical” in order to succeed in the role. This myth abounds because certain companies have established technical skills as a necessary component of their product management job descriptions — often those that are the most engineering-driven, such as Facebook and Google. What began as a filtering requirement for these organizations has morphed into a belief that Product Managers cannot succeed unless they are technical, which is simply not the case.
The primary role of the product manager in any organization is to be the expert on the customer, the user, and the market, and to identify valuable problems that the company or product should solve — not to make technical, architectural decisions about the chosen implementation of that solution. Requiring that your product managers be as technical as your developers or architects completely forgets that their role isn’t to be in the “how” but to guide the “what” and “why.”
This isn’t to say that being technically proficient to some degree isn’t a benefit — it certainly is. But as a fundamental requirement for even interviewing for the role, it’s an unreasonable disqualifier that pushes out people who can certainly bring value to the role for a lack of skill that’s at best tangential to their role in the organization.
What Product Management Is
Having put those common myths aside, we can focus on the specific duties and responsibilities that all product managers should expect to be held accountable for, and for which anyone taking a product management role should push to secure the role as a valuable addition to the organization.
The Customer Advocate
First and foremost, the product manager’s job is to be the resident expert on the market, customers, and users that the product and company targets or is or considering targeting. We must be ruthlessly focused on ensuring that every decision that passes through the product management organization is being made to serve the customer, user, or market — and not merely the whims or beliefs of someone within the organization. We must arm ourselves with actual customer contact, with information derived from interviews and other interactions, and with as much data as we can to point decision-makers in the direction that’s best for the customer, user, and market. We need to constantly assess the work underway, to challenge others to frame their requests and efforts in terms of how the customer, user, and market benefit, and to keep the needs of those outside the organization at the top of mind throughout the company.
Data-Driven Decision Maker
There’s a classic quote from former Netscape CEO Jim Barksdale: “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” This quote should be a fundamental truth for all product managers — in the absence of data, someone will make the decision based on opinion; and that opinion is likely to be one of the CEO, COO, or other similar leader in the organization. We, as product managers, need to focus our organization on making decisions that are based on actual data — research, interviews, objective market analysis — and not on opinions. Opinions about what our customers need are always highly biased toward the person making the decision — and who often are not the actual users of the solution. The problem is that many such opinions are usually close enough to help the customer in the end — but rarely will opinion-based decisions actually delight the end user, customer, or market. We must actively seek out data ourselves and raise the bar of discussion and decision-making in our organizations to focus on actual data and not on someone’s opinion of the moment.
Leading Through Influence
Last, and most importantly, is the fact that product managers lead through indirect influence and not direct authority. Product managers can’t go into the role expecting that people will blindly follow what we say, regardless of how much data we collect and disseminate through the organization. Instead, we must build and leverage relationships throughout the organization, from the top to the bottom. We must build up social capital, banking it for future needs and asks. We must demonstrate leadership by example in everything that we do. We don’t get to tell people to do something “because I said so” — we have to convince people to do things because it’s the right thing to do for the customer, user, market, or company. A good product manager is on who can build coalitions within the organizations aligned toward the same goal and vision of the future of the product.
What Product Management Isn’t
Now that we’ve established some of the things that product managers should be responsible for, it’s time to flip the coin and discuss some of the very common responsibilities associated with product management that shouldn’t be part of the role.
Project Management
The most common mismatch of responsibilities for product managers is the expectation that they are also project managers. The reality is that the skills and personality traits that make someone an exceptional product manager directly conflict with the skills and personality traits that make someone a great project manager. Project managers are typically responsible for deep-level management of execution — time, scope, and resources. They must be in the weeds every day, checking and double-checking their Gantt charts, resource allocations, and focusing on the “how” component of the product equation. On the flip side, product managers should be focused on ensuring that the vision and strategy of the company is clear and understood, that the product roadmap is targeting innovative solutions to valuable problems and that the development and quality assurance teams understand the “what” and the “why” for the things they’re tasked with doing, leaving them to determine the “how.” This isn’t to say that product managers should not understand the progress that teams are making, nor that they should ignore time and resource limitations — but that it’s not their day-to-day job to manage these things. We need to be focused on ensuring that we are solving valuable problems, not on digging into the deep technical details about how the teams are solving those problems. Project management is a complementary skillset and role to that of a product manager; but the two are very different in scope and in focus, and should not be thought of as a single, combined role.
Spec Writer
Another very common dysfunctional role that is assigned to product managers, often under the guise of a title of “technical product manager” is that of a “spec writer” — someone who simply takes the ideas of another person in the organization and translates those ideas into a backlog of specifications or user stories. Now, there’s nothing wrong with this role in an organization — many startups need someone to sit in between the visionary thoughts and desires of the leadership and the day-to-day execution of the development teams. But this role is absolutely not a product management role; there is no leadership involved here, there is no responsibility for anything other than the translation and management of the requirements that are being generated, and most importantly there is no ownership of any of the original thought involved in the ideas behind the features and capabilities. Putting the “product manager” label on this role is a disservice to the domain itself, waters it down until it bears little to no resemblance to the ideal form of the role, and inherently limits not just those in the role, but the organization as a whole, from achieving their potential.
Bringing it all together
As you can see, there are a wide variety of roles and responsibilities that companies use to define the role of product management in their organization. Some of these are reasonable and align with the general domain’s definition of itself, while others are limiting in their definition or completely tangential to the more broadly-accepted definitions of the role. As product managers, we need to constantly work to better define our own roles, and to call out those duties and responsibilities that do not fit into the market-driven, customer-centric, problem-solving focus that a true product management role should have.
