The Product Manager
Diplomacy, product development, and domain expertise.
This essay is part of the series Essential Roles within Development Teams.
You’ll hear me say this many different ways throughout the chapters to follow, but so much of what we do in a strong product organization is to optimize for the effectiveness of product teams… [and] if your company is not yet set up around dedicated product teams, this is probably the most important thing for you to fix. Everything else depends on this.
What distinguishes good teams from the best teams is typically excellent product leadership. While the engineering manager is accountable for how things get done, the product manager (PM) is responsible for what gets done.1 Since direction of travel is far more important than velocity—all things being equal—a skilled PM will benefit a team far more than additional engineering horsepower (or its attending management).
Diplomat
The PM role is the most difficult role on any team when it’s being done well2. Not only does the PM have responsibilities which span across several disparate domains, they also have to be a highly effective communicator within all of these domains. PMs need to speak fluently in the the distinct languages of business, product, and engineering. They’re often called on to be charismatic presenters and occasionally sellers3.
Business Consultant
It is the responsibility of the PM to align a team’s objectives with business objectives and to be able to defend a team’s work—at any time—in terms of the value it is delivering to the business. This means the PM has to not only understand the larger business objectives, she also has to understand the internal narratives about those objectives such that a story can be readily told about a team’s work and its alignment with the broader company. Since the PM is often put in the position of defending a team’s priorities and fielding criticism she needs to have thick skin and a personality which inspires confidence.
Domain Expert
The PM is also the direct representative of the team’s customer. They are expected to deeply understand a customer’s pain-points and unmet needs, all user personas, and the overall customer story. While a PM might not conduct user research directly, they are responsible for it and for deriving actionable insights from it. The PM is then responsible for articulating a coherent product vision—especially for more mature products. Depending on the complexity of the product, this vision might take the form of a presentation or it might necessitate the creation of an entire wiki carefully detailing key product primitives like user personas, user actions, and core data concepts (e.g. a game might require this).
Project Lead
The PM is the stakeholder between commercial and engineering functions that aligns them. As the expert on both of the customer experience (user value) and the realities of the commercial market (business value), the PM ultimately sets the team’s product direction. This direction is based on their best understanding of relative tradeoffs of opportunities available to the team. These tradeoffs can be related to market timing, development costs, competitive landscape, sales difficulty, synergies within the company, and internal politics to name a few. Since this is fundamentally a matter of educated guesswork, good PMs are generally humble and willing to quickly course-correct if their initial thesis fails to pan out. On the other hand, they are quick to triple down and make big ambitious bets on a good opportunity when they find one (since they understand how rare these opportunities are).
After having synthesized and compared opportunities along the axes of effort, impact, and risk, a PM is responsible for resolving a team’s priorities into a product roadmap and—in collaboration with engineering—detailing a teams’s epics, milestones, and deadlines. As a product undergoes development, the PM tends to be responsible for managing the scope of releases and continually re-assessing the relative priority of items on the backlog. It is the shared responsibility of the PM and EM to encourage whole-team collaboration4, an experimentally-driven process, and force difficult conversations to happen when necessary (while limiting attempts to re-litigate past decisions). As progress is made, PMs tend to own communications with leadership, customers, and other stakeholders like sales. Ensuring a team is data-driven and responsive to key user adoption metrics like conversion rates, feature adoption, and user retention is increasingly the responsibility of the PM.
Finally a PM that is actually part of a product team (not a temporary owner of a feature or deadline), is incentivized to achieve a sustainable pace of software development and collaborates with the technical stakeholders to keep engineers motivated and empowered to make investments in infrastructure and pay off technical debt.
Conclusion
Sounds like a really hard job right? It’s even harder than you think. Smart people tend to dramatically overestimate their ability to make informed product decisions. Nowhere is the Dunning-Kruger effect more prevalent in Silicon Valley than in product development. This is precisely why venture capitalist prefer to fund founders that are solving their own problems. It is extremely hard to find someone with all of the aforementioned skills who can bring them to bear on an arbitrary business and product. Such people are unicorns. In my experience, it’s more reliable to find a smart person with domain expertise and teach them PM skills than to find someone with PM skills and try to level them up on a very complex domain.
At least to the first approximation. If you work in a more sophisticated organization “what” gets done will be a roadmap that explicitly interweaves product and engineering objectives.
Because the PM role is so difficult it’s often done poorly, so most people have only had the experience of working with a poor or mediocre PM, which can be a worse situation than no PM. Bad PMs are often guilty of micromanaging which can be fatal to creative teams. This is one of the many reasons that leadership can be hesitant to resource the PM role and why it is often taken on by the EM or the “de facto” product lead (like a general manager).
While some organizations resource product marketing independently this is yet another responsibility that can fall on the PM. Note that this also applies for internal product. If you’re building internal tools one of the hardest problems is just getting the word out and figuring out why people are or are not using your product.