Successful product managers can manage a roadmap, define requirements, and dance their way through any kind of customer conversation. The best product managers use a few ethereal — almost intangible — skills to make these tasks look effortless. The sort of skills that fall into a nebulous undefined bucket of “things we wish people had but don’t really think they have … or maybe they sort of do?” These specific skills are a combination of emotional intelligence, critical thinking, and a good dose of pragmatism.
The best product managers are able to synthesize multiple perspectives and turn a cacophony of opinions into a single voice of clarity.
The best product managers can influence without authority by being a partner that understands their teams needs and expresses well-articulated steps. They also recognize that their team has agency to follow (or not follow) those steps.
The best product managers express accountability for the team’s direction and where they’re going — especially when the product manager didn’t decide the destination.
Synthesizing Multiple Perspectives
As product managers for software organizations, we get to work with many different groups in the organization:
- With engineering, we try to figure out what can be built and what might be borderline impossible.
- With sales, we make sure the value of the solution is being properly communicated and do what we can into customer hands.
- With support & customer success, we help resolve any customer issues and look for ways to help drive customer engagement so that we have happier users.
- This even extends to more internally-focused groups such as legal and finance, where we partner to understand our contractual obligations or where we may have budget to pursue future opportunities.
Product managers are part of the nexus of the organization and get to hear the opinions, thoughts, and insights from every group within the company. Each of these groups are valuable and have their own goals and aspirations. Sometimes these aspirations are in direct conflict with each other — for example, support may have an initiative to focus on customer satisfaction by minimizing the exposure to bugs and defects, but engineering may be focusing on a large code refactor that will cause initial instability for the sake of long-term quality.
As product managers, we have the unique opportunity to understand each of these goals, but we also have the responsibility of creating a cohesive plan of action that addresses all these goals (even if it addresses them imperfectly). Sometimes that means we are able to see a solution that no one else sees due to the multiple perspectives running through our brains. Sometimes it just means we act as a translator across groups and help make sure each group is taking the goals of others into account.
In the previous example, the solution could be as elaborate as shifting the nature of the refactor, or as straightforward as communicating the downstream effects of the refactor to support and help them adjust their near-term goals to reflect the refactor.
Influencing without Authority
“The Product Manager is the CEO of their product.”
— Not a Product Manager
The product manager and the CEO are separated by a single word: Authority. The CEO has a giant neon flashing “BOSS” sign over her head and has the ultimate authority to dictate the direction and personnel for any given project within the organization. However, like the CEO, the product manager is still accountable for the the direction and success of the product and must find ways to compensate for the lack of authority.
Being able to influence without authority is a critical skill for successful product managers. One of the best ways to do this is by showing that you understand an individual’s needs and can clearly communicate how you can directly address those needs. Product managers are advantaged in this regard, since we are already the nexus of the organization — which means we also have insight on everyone’s needs and aspirations!
Going back to the support & engineering example from earlier, we can identify their needs and aspirations based on what we know:
- Support is focused on measuring (and improving) the quality of the customer experience, and their chosen metric is the number of reported known bugs.
- Engineering is focused on improving future code velocity, and their chosen solution is to re-architect more complex areas of the code.
In a vacuum, each group may decide to proceed down their respective paths and engineering’s work may come into direct conflict with support’s goals as the initial re-architecture might create some confusion amongst customers.
Both the CEO and the product manager may foresee this based on their expanded context. The CEO has the authority to either mandate that support adjust their goals or require that engineering change their architecture plans so that there is more alignment between both groups. The product manager does not have the luxury of authority, but may recognize that the re-architecture plans could improve the quality of the overall customer experience in the long run. Based on this insight and an understanding of each groups’ needs, the product manager might take the following actions:
- Working with engineering, they can document the near-term risks with the re-architecture as well as assist in creating success metrics that focus on quality and the customer experience (I.e. no regressions and improved uptime when compared to the previous architecture)
- Working with support, they can help the team understand the risks with the initial phase of the architecture and give insight on how to re-adjust their chosen metric so that they are still achievable. The product manager can also incorporate support’s feedback and domain expertise into engineering’s re-architecture plans, since that might contribute to a better customer experience
It’s easy to make the assumption that influencing without authority as a product manager is about creating a grand, sweeping vision that puts a smile on everyone’s faces and makes it so that they can’t help but follow you. For a select few extremely talented leaders, this may even be the case.
For the rest of us, influencing without authority is more like getting a box of imperfect puzzle pieces and trying to understand how we can nonetheless create a compelling picture where the pieces mostly fit. It’s less about a charismatic vision and more about understanding the various (and sometimes diametrically opposed) needs of the organization and how to address them without compromising your goals.
Being Accountable for the Team’s Direction
A team’s direction is comprised of the decisions they make and how they choose to spend their time. The product manager has direct control over some decisions, such as the team’s product roadmap. The product manager may not have control over other decisions, such as corporate initiatives or dependencies within other teams. And then there are decisions that the product manager can influence but is not the ultimate decision maker, such as architecture implementation decisions or how an engineering team works. All of these decisions come together to create the team’s direction and charter. The product manager is ultimately accountable for the team’s direction — and that means the product manager is accountable for the team’s decisions, regardless of who made them.
Bearing the burden of accountability (especially if you didn’t have a direct hand in the decisions) can feel unfair, but it opens up opportunities as a product manager. It gives you a holistic view of all the inputs and the outputs, making it easier to understand everyone’s needs and opens up the ability to influence even when you don’t have authority. Being accountable for the direction forces you to understand why each piece of work is being done even if you weren’t there for the decision making or planning. This can expose you to different perspectives and let you synthesize those perspectives into a cohesive narrative.
A project can stall and its direction and charter may go astray when there are multiple owners that are only focused on their specific domains. The best product managers know this and make themselves accountable for anything related to the project and their team. This accountability is everything, and can be the difference in having a product stuck in a perpetual beta versus launching a generally available release to the public.
It’s All Connected
By now, you might have realized that each of these skills are interrelated and build off of each other. In fact, a product manager that focuses on learning one of these skills will naturally pick up the others if they continue to apply first skill over and over.
As a product manager, you’re exposed to multiple (sometimes disparate) perspectives due to where you sit within the organization. The best product managers understand that this is part of the role and embraces it fully. It ends up creating a self-feeding loop:
- Synthesizing multiple perspectives forces you to understand and address their needs
- Addressing those needs allows you to partner with stakeholders and influence even without authority
- The act of influencing without authority makes it easier to be accountable for the direction
- Accountability for decisions that you had no involvement in exposes you to new perspective
And the loop starts over again.
These are easy skills to talk about, but really tough skills to master. Luckily, there are lots of opportunities to practice these skills once a product manager (or an aspiring product manager) knows where to look.
If you’re not sure where to begin, talking to different groups and trying to understand their perspective is probably the best place to start!