Managing and Developing Product Managers
If the craft of Product Management is often mired in ambiguity, managing product managers is ambiguity².
When you start managing PMs for the first time, you are forced up a steeper managerial learning curve than in other functions. This is because the average PM you may manage is already quite experienced, due to the fact that PMs typically start the role after success in other disciplines or entrepreneurship. That’s in contrast to disciplines like engineering or design, where initial management responsibilities start much earlier in a career due to the more established entry pipeline from schools.
I’ve directly managed over twenty PMs in my career now, and for the last year have managed manager-PMs as well. My takeaways from those experiences are that while you must still excel at basic management hygiene like consistent 1:1s, direct feedback, and clear goals — you need additional frameworks if you want manage PMs effectively.
That’s what this post is about. It’s structured into three sections:
- The mental model for managing PMs — A useful mental model built off the foundations of what drives most PMs
- Developing PMs — How to construct scopes for PMs, and give a particular PM an appropriate scope
- Assessing PMs for performance — How to create a balanced and repeatable way of assessing PMs
Note: This is an opinionated view of what most successful product managers are like based on my experiences. It has generalizations, and as such, is imperfect. Let’s acknowledge there are many exceptions.
The mental model for managing PMs
What is a good mental model for managing PMs? Let’s start with describing what makes them tick.
Who are PMs?
Being a product manager is a high pressure job. If there’s ever uncertainty about who is responsible, it always defaults to the PM, and only certain types of people want or can cope with that type of pressure.
Because of this, I’ve found that most successful PMs crave responsibility and ownership, and have strong traits of being achievers and mission-driven. It’s this mix of traits that explain why so many PMs go on to start companies, or are ex-founders.
Being a PM is the best job in the world to “practice startup”.
This is not to say that any random founder off the street is automatically a good PM. The hard skills still matter. It just means that from a personality perspective, founders have useful traits for the job.
It’s also not to say that all great PMs should want to become founders. Being a founder and being entrepreneurial are different. The former is about risk appetite, and the latter is about your attitude towards finding opportunity and solving problems.
It’s this idea that strong PMs are entrepreneurs at heart that is at the foundation of how I think about managing and developing PMs.
The Mental Model: they’re entrepreneurs, you’re the investor
This is my favourite mental model for thinking about managing PMs. It guides you on the working relationship, and sends a powerful signal to your PMs as to their responsibilities.
It’s their vision, you just buy into it.
To paraphrase a Steve Jobs quote, “it makes no sense to hire smart people and then tell them what to do”.
It’s your job as the investor to identify great PMs that want to build something in an area you think is a great opportunity. After you’ve hired them though, you should aspire to truly let them run with it.
The takeaway from this is to be very transparent during hiring about what product area you’re looking for someone to lead. You should be looking for candidates who are genuinely excited to lead the area, just like an founder would be of their own startup. This reinforces the investor <> entrepreneur model.
Investors don’t mettle in a portfolio company’s operations
You must must must let your PMs struggle and solve their own problems. An investor would rarely meddle in the operations of a company they’ve funded, and likewise, you should own up to your promise of autonomy and ownership for the PMs you bring onto your team.
Don’t solve their people problems. Don’t make decisions for them. Overall, don’t disempower them by doing their job. Doing so sets them up to fail, because people around them will no longer perceive them as having the agency to make decisions, and their job-ending frustration is self fulfilling from there.
This doesn’t mean you shouldn’t support them, coach them and give them constant feedback, but just like an investor would you’re holding them to the end result, not how hard they work or the way they do it.
Focus on helping to support their blind spots
A good by-product of the diversity of PM backgrounds is that you will often know much less than they do about certain domains or disciplines. You will also have a very different way of doing things than they do, even though both approaches can lead to success.
Your job isn’t to make them like you. It’s to work with them to identify where they are weak and you are strong, and help them by supporting their blind spots. This is analogous to the way that VCs can help portfolio companies that don’t have experience in hiring, operations, etc.
Never miss the opportunity to learn from them as well. One of my favourite aspects of managing PMs is the diverse thinking that I get exposure to. As of the time of this writing, my team has people who have founded several startups, and have worked at Amazon, Microsoft, Hulu, and IBM Watson to name a few.
Learning from this group is something I cherish and helps me become better everyday.
They should have more to gain in success than you do
Product management is a function where it’s pretty common that a PM can outshine their boss and ultimately be more capable.
When you have a superstar PM, your responsibility is to accelerate their career, even if that means it surpasses yours, and do it quickly. PMs are super ambitious and they will not wait for you to provide them opportunities they’ve earned. If you’re too slow, they will leave — I promise you that.
Don’t worry, you can always be “the person that hired X”.
They should have more to lose in failure
If you feel like you’ve supported your PM, coached them through a few “pivots” to get them winning, and yet they still aren’t performing — you need to let them go.
Remember, it’s not just about them, it’s actually more about everyone else. We have a saying at Shopify that “it’s better to have no PM than a bad, or even a mediocre one.”
When you leave a low performing PM to wallow around:
- Other PMs on your team that work so hard will find it really frustrating to see low performing PMs stick around. It devalues their work
- Engineers and designers that have the bad PM on their team will be even more frustrated. A bad PM is absolutely toxic to a team and creates turnover risk
- You are losing tons of trust within the company because the poor performing PM is obvious to everyone
As an investor, you should’t feel too bad as long as you feel you’ve given them good support along the way. A PM’s job is super hard and success is very contextual to the company’s culture and personality of the PM. A PM that is unsuccessful on your team could be very successful somewhere else, you are just moving that reality along.
Where does that leave career development?
One of the difficult aspects of the investor<>entrepreneur mental model is that it’s non-obvious how to develop the career of a PM if you’re supposed to be so hands off as a manager.
If you’re constantly letting them “run with it”, how does that enable/disable you from giving them opportunities that make them better? How can you increase scope in a way that fits this mental model, and also ensures that they’re maximizing impact to the company as they progress? That brings us to the next section.
Developing PMs
This section explores the right way to construct product opportunities for PMs, and then tailor the scope for their abilities.
PMs develop best when shipping Whole Customer Experiences
Most careers typically develop through skills building. For example, junior engineers will start with writing tests, then move deeper into the stack. Junior designers will start by doing lots of production work based on the direction from others, and move on to problem definition and running design sprints. As these people build skills, their careers advance.
PM careers don’t grow with specific skill mastery because that doesn’t tie with how they create value. If a PM is incredible at backlog management but doesn’t know how to frame the benefits of a product, or if they’re fantastic at business modelling but cannot understand support and operations — they can’t create value. This is because PMs only create value through end-to-end customer experiences they ship.
Let’s call this solving for the whole customer experience . That means building the right product, marketing and selling it, building a sustainable business model around it, ensuring it’s on strategy, and creating operational excellence around it, like customer support.
In short — it’s not just the product, it’s everything around it, too. Take a look at two different projects a PM could take on, represented by the diversity of functional skill that is required from the project, below.
This illustrates one of the most common issues I see with how PMs are developed. They are given scope that simply doubles down on what they’re already good at. For example, if they’re of an engineering background, they continuously get projects that are of increasing engineering difficultly. Why is this bad? Because this pigeon-holes the PM into only being able to succeed at certain types of projects.
When your PM team is full of specialists, it makes your team incapable of capturing opportunity reliably. Everything in tech moves too quickly, and you never want to be stuck with a situation where you can’t move a PM to a project project because “it’s too design heavy”, or “it’s consumer facing”, or “it has too much operational complexity”.
Instead, as is demonstrated by the project on the right, you should aspire to be developing PMs that are discipline and domain agnostic. As an investor, this gives your investments optionality.
When PM career development is centred on solving whole customer experiences:
i. the PM can always take a product all the way to market
ii. the PM can operate autonomously (because of the above), and thus it reinforces the investor<>entrepreneur model
iii. It’s easy to explain to a PM how their careers will grow — as they progress they will solve the whole problem for product areas of ever-increasing scope (the definition of which we’ll cover next)
Finding the right scope for a PM
Your job is to maximize the impact to the company by giving a PM the biggest product area they can manage at their current abilities. This can be tricky, both to assess how difficult a product area is, and how prepared the PM is to manage it.
Assessing difficulty of a product area
There’s no exact science to this, but here are some dimensions I like to use to gauge difficultly:
- Customers Impacted — self explanatory
- Revenue/Cost Impact — self explanatory
- Strategic Importance — how mission critical is the success of this project/product to the future of the company?
- Operational Complexity — does this product fit into the existing operational systems of the company? Can the existing support team manage issues or do we need to create new operations?
- New Company Domain — is this a new area for the company? For example, is it a consumer product now dabbling in enterprise?
- Resourced Required — what percentage of the company’s people are allocated to this project or product area?
You can visualize the scope that you’re giving a PM for a particular project by plotting the dimensions of the project as per the chart below, with 0 being no complexity and 1 being maximum complexity for each . The total difficulty is the area plotted.
Choosing how much scope to give a particular PM
If you have direct evidence of a PM’s ability to handle scope (i.e. shipping product at your company), then always give them a larger scope than the last. When you don’t have evidence, either because they’re new to PM or they are from another company, start them small but be ready to adjust quickly and aggressively.
Another great management exercise is to compare the scope-areas of all the PMs on your team and see how they rank. Your strongest PMs should have the biggest scopes, and the relative scopes of all the PMs should be reflective of their stage of development.
It’s worth reinforcing here that when I say “give them scope”, it does not mean telling them what to build. It simply means aligning on what the goals are, and then falling back to the investor <> entrepreneur model.
Managing PMs that manage other PMs
It’s human nature for PMs to want to hire when they’re too busy. I’m strongly opinionated, however, that you should never let your PMs hire glorified backlog or project managers. If you do, then the entire team will lose its universal ability to solve whole customer experiences, and worse, you will dilute the reputation and expectations of what it means to have a PM on your team for the rest of the company.
Instead, if your senior PMs need to scale, help them figure out how to divide up their current product areas into the whole customer experiences that an incoming PM could own autonomously.
And of course, coach them on the other side of the investor <> entrepreneur model.
Assessing PMs for Performance
PMs are notoriously difficult to evaluate for a few reasons. In general, they write no code, produce no designs, achieve no sales quotas, and manage no support tickets. And even if they did, you wouldn’t want to measure their efficacy as a PM on those outputs, because PMs exist to create those outputs through others and help a team build the right product. Here are the four dimensions I use to assess PMs:
A. Product Performance
The theoretically perfect way to assess a PMs is through the performance of the products they manage. In practice, however, that can only be one of the inputs, because of how difficult it is to measure reliably:
- Products often require a long time horizon to know if they’re successful — The time it takes to build and launch a product is one thing, but even after you launch it, it can take a long time to know the impact of the product. You can measure things in the short run like adoption and engagement, but the metrics with lasting impact like retention, revenue, and customer satisfaction necessitate significant time and sample size to assess.
- Not all product performance is directly attributable — If a PM’s feature adoption grew 80%, is that good? What if user growth during the same time was 70%? Or a complimentary feature from another team grew 150%? The point is it can be very difficult to isolate a specific feature’s impact, because customers pay for the whole product and support experience, which is a system of interconnected features/operations with feedback loops to each other.
- PMs that inherit products and are tasked with improving them are limited by what they were given — If a PM took a poorly performing product area, and through some incredible work made it O.K., how does that compare with one that took a fast growing area, and continued it’s growth trajectory?
- PMs are just part of a team. They can’t be assigned all the credit — If a PM has the best designers and engineers in the company on their team, it’s a bit unfair to assess their products with the same lens as a PM who has a group of interns on their team.
All the above being said, I think it’s always worth trying to assess a PM on the performance of their product, but do so while normalizing as many of the conditions as possible.
B. How well they work with other people
This sounds wishy washy but it’s probably my number one indicator of an effective PM. Do people enjoy working with them, respect them, and think that they add value to the team?
You need to get feedback from all the key stakeholders a PM has: their direct team, their PM peers, the sales team, the support team, the marketing team, the engineering and design leadership, etc.
Product management is a leadership function, and the potential impact of a PMs is a function of the amount of trust they have developed with people internally. The more trust they have, the more capable they are of moving mountains inside a company, and galvanizing large groups of people to get shit done. That is their firepower, and it’s worth a lot.
This is also how I get signal as a manager on how well a PM does PM-y things like backlog management, writing project briefs, presenting, etc. Since those outputs are used by people around the PM to operate, the sum of their impact results in higher trust scores with the people around them. It’s that final result that should matter to you more than the PM-y things they do. For example, if 100% of the people think a PM is organized and knows what’s most important at a given time, you shouldn’t give two shits about the state of their backlog.
C. Decision making ability
Every project has to make big trade offs. You should deep dive with the PM on the key decisions they’ve made, and get them to defend those decisions and explain how they came to them.
Use these sessions as coaching moments, but also to level set your assessment of their decision making ability (and as we’ve covered before in Making Good Decisions as a Product Manager, ability is measured by the speed and correctness of decision making).
D. Strategic thinking
What you’re checking for here is how well a PM thinks of the big picture. Strategic thinking means building a product strategy based off of:
- What the company’s strategy at large is
- What is happening in the external market today, and having an opinion of what will happen in the future
- What the other important initiatives are within the company
A good product strategy will use those inputs and be able to articulate how the resulting plan should better accelerate the company’s impact, versus a plan designed with tunnel vision. We covered product strategy in more detail in the First Principles of Product Management.
Ambiguity²
As clean and confident as this article may read, product management really is a dark art and managing PMs will never be straightforward.
The approach isn’t for everyone, specifically the investor <> entrepreneur model. That model can represent a level of responsibility, accountability, and ambiguity that PMs are just not comfortable with, and for managers it can represent a loss of control that they’re equally troubled by.
Investing comes with risks and rewards, and this is no different. When I reflect back on how this approach has helped/hurt me, the major benefits have been that:
- It’s been highly scalable for me from an organizational design perspective. People know to talk to my PMs, and not me (because I have no answers!).
- It has enabled me to manage a high ratio of PMs sustainably and effectively
- It enabled superstars on my team to maximize their impact to the company, and have quickly accelerating careers (leading to retention)
The major downsides have been:
- Heightened career risk (for me), because regardless of my management philosophy, I am accountable for my PMs’ results and this approach creates higher volatility in those results.
- Significantly smaller pool of people to hire from (those with a deep entrepreneurial mindset), meaning that I’m always playing catchup to engineering and design.
Hopefully, what we’ve covered in this post has given you a few ideas on how to manage PMs. Whatever approach you decide to take, just remember that basic management hygiene is required, but it likely will not cut it alone.
