|
Product management is an intensely cross-functional role.
While engineers might spend the bulk of their time interacting with fellow engineers at work (with some data science and design mixed in), a product manager's time allocation between different functions is more fragmented.
PMs will likely interact heavily with counterparts on engineering and design but they'll also likely spend significant time interfacing with other groups too: marketers, sales teams, support, operations, legal and execs.
If you're a prospective or current PM, it's helpful to understand how the core groups that interact with PMs, like designers and engineers, perceive their product management peers.
Why? Well, if a PM is aware of what his/her counterparts appreciate in a good PM, he/she can adjust their actions appropriately to help build a winning team and product.
This document, which compiles a list of anonymous comments from designers and engineers, does a nice job of highlighting anecdotal insights from designers and engineers about what qualities stood out about top performing product managers.
We recommend taking a spin through the full document, but to help get things started, we've pulled out a few of the key comments, put context around them and explained their importance.
We've highlighted four key themes that emerge when you look at what engineers and designers respect in their PM counterparts.
For each one, we've pulled out a few representative quotes and added color commentary on why each of these is so important.
The best PMs for me have been great listeners. Taking all of what their teams are talking about and turning that into action.
Many PMs get caught up in the perceived glamour of being a PM and mistakenly translate "be the CEO of the product" as a mandate to dictate all tasks and actions that the team should pursue.
Often, the reality is the inverse. Great PMs need to listen actively to their customers and team members so they know what to build and how to build it effectively and efficiently.
Once they're listening, they're well primed for utilizing that expertise.
Gave me enough time to be a product designer. Did not ask to change my designs based on their "taste". Cared about the user more than their own ideas.
Understanding the difference between product decisions and technical decisions [and staying in their respective lane].
As a PM, it will be impossible to be the resident expert on every aspect of the product(s) you work on.
For example, it's rare that a PM is an expert in both advanced machine learning techniques and user experience design.
Given this reality, it's important for PMs to respect, embrace and leverage the expertise their functional team members bring to the team. It's not the product manager's role to make every decision but rather to ensure that the overall product is successful - doing that will require leaning on the expertise of team members.
As a developer, working with PMs who are consistently clear on "what are we working on now and next" and not changing their mind daily/weekly/mid-sprint is a godsend.
Nothing irritates team members more than a constantly moving target.
Given that PMs don't produce code or designs, they can misunderstand the depth of work that goes into producing either. Something that seems like only "a small change" can create significant re-work for their counterparts.
PMs who prioritize with conviction and stick to decisions - unless it's critical to change course - often earn the respect of their teams and have an easier time executing on projects.
Shorten feedback loops, get developers involved in product decisions early and often.
Communicate, communicate, communicate. Champion the "why", get people excited about the impact of building the "what."
In the chaos of building, iterating on and launching a product, it can be easy to fall prey to the "curse of knowledge," an unfortunate condition where one assumes other people know all the same relevant information and context.
For product managers, two structural conditions of the job exacerbate this: 1) they often make decisions which will have downstream impacts on the rest of the functions (e.g., prioritize feature X over Y) and 2) they interact heavily with the rest of the organization, from customer support to execs, and gain valuable context from those interactions (which the broader team might not have).
Given this, it's critical for PMs to communicate constantly about what the product goals are, what new insights have been learned and why certain product decisions were made.
Since successful product management requires significant cross-functional collaboration, it's critical to understand how other functions like to engage with product managers.
While we reviewed external perspectives from engineers and designers above, product managers should do a similar exercise to understand what counterparts in all roles (e.g., sales, marketing, operations) like to see from their PM peers.
Real interview questions. Sample answers from PM leaders at Google, Amazon and Facebook. Plus study sheets on key concepts.