Last week, Ben Erez shared a tweet on his experience creating products at Facebook.
An uproar ensued. Many felt like this was further proof that product managers don't do anything. Others (mostly PMs at other companies) applauded this model. PMs from across the internet weighed in on this method.
John Cutler from Amplitude pointed out one truth to the situation: people were quick to judge with no context.
Today, I want to add some context and share how we define the PM role at Facebook, how our relationship with engineers works in practice and why this model works for us (and perhaps your team too).
The Role of a PM = Execution + Strategy
Since joining Facebook, I've been a PM on four teams across different parts of the company. They were in wildly different areas and the day-to-day responsibilities varied. But the constant was what I was expected to deliver and my working model with engineers.
Product managers at Facebook are responsible for two key outcomes: great strategy and great execution. A former manager explained this principle in a catchier way:
The role of a product manager is to figure out what game we're playing and how we're going to play it.
Strategy is choosing the game we're playing. It’s finding worthwhile areas to invest in and creating a compelling vision for how we can succeed in this game. A great strategy connects to the evolving need of users, aligns with the business’s direction and has a reasonable set of pillars to make progress.
Execution is how we play the game. It’s the day-to-day processes, decisions and actions we take to make progress towards our mission. Execution is what Ben’s tweet was referring to, so I’d like to spend more time here.
In my mind, great execution boils down to nailing two large categories of sub-tasks:
Prioritization involves, roadmapping, estimating impact and deciding on the right features to build. This is an important part of my role and this is the category of execution where I spend the majority of my time.
The other side is process management. The process is everything that is necessary to go from a product brief to a launched and successful outcome.
Doing these sub-tasks well can help create a great execution rhythm. But If a PM were to do all of these for every feature that they were involved in, this would be a full-time role.
And for more junior PMs, this is the full-time role. When I first became a PM, the majority of my day was supporting the execution rhythm of the team. This was project management, Gantt charts, discussing experiment results and writing weekly summaries. When I first started, I was more of a feature manager than a product manager.
But after my first evaluation cycle, I learned a key point: PMs are responsible for the outcomes of the team; the inputs are subjective. For example:
No one cares that you built a Gantt chart; they care that you delivered the project on time.
No one cares that you created meeting agendas, wrote weekly emails or created tasks; they care that the project had an impact when shipped.
No one cares that you wrote SQL queries because your data scientist was on PTO; they care that your goals were reasonable and achieved.
This understanding made me stop defining my role by the tasks I needed to do and instead focus on the output I was responsible for creating.
Let me be clear: PMs are 100% accountable for the results of your team. If your team fails to hit your goals, it’s your neck on the line. Cemre explains this well:
But results are an outcome; the inputs to create that outcome are your team’s decisions. Your goal as a PM should be to find the best combination of inputs to maximize the outcomes of your team. Ray Dalio calls this systematic thinking.
This means you don't need to do every task related to execution. In fact, the only way to scale your role/impact in the org is to begin meta-execution.
Meta-Execution
Meta-execution is executing through others. This is how product directors can steer a team of 200 people without writing tickets, doing experiment reviews or writing weekly updates.
The ability to empower leaders within your team to have more ownership is what separates execution for a PM on a 5 person eng team and a PM who drives a 40 person eng team.
Meta-execution is about empowering leaders within your team to have more ownership. This allows the PM to focus on the problems they are uniquely able to solve.
Let's revisit the list of execution items above. You could stack rank these into a list of items that the PM is uniquely positioned to solve. My view would be:
The ones towards the top of the list are the ones that will always need your attention while the ones on the bottom can be delegated to other leaders on your team.
Meta-execution requires finding capable leaders to drive more execution independently. Once you’ve identified these leaders, empower them with ownership and continue to offer support along the way.
This helps you get to a world where meaningful parts of execution are driven by other team members.
A model like this makes sure you're helping the team execute on the areas where they need your support the most. It also frees up your capacity, which you can then use to define the longer-term strategy for your product area.
Key points:
PMs are responsible for the outcomes of the team; the inputs are subjective. Your goal should be to find the best combination of inputs to maximize the outcomes of your team.
The more senior a PM you become, the more impact you can have with strategy. Freeing your own capacity while not allowing outcomes to suffer requires meta-execution.
But regardless of your delegation abilities, you will stay accountable for execution.
If you’ve made it this far, you may enjoy Product Life. Join thousands of product managers who are growing their careers by subscribing below:
Empowered Product Teams
You don't need to look far to find criticisms of this method. From Ben's post:
Criticisms like these create an adversarial view between product and engineering. It's saying that PMs have certain tasks they need to do and engineers have others.
This criticism is only valid when teams do not decide what to build. If you don’t decide what to build, then all that matters is how you deliver the project that was assigned to you.
If your team does decide what to build, then the outcome you create is how you’ll be judged — not “who does what”.
This is what Marty Cagan refers to as the difference between empowered and non-empowered teams.
In most companies, technology teams exist “to serve the business.” That is very often the literal phrase you will hear. But even if they aren’t explicit about it, the different parts of the business end up driving what is actually built by the technology teams.
However, in contrast, in strong product organizations, teams exist for a very different purpose. They exist “to serve the customers, in ways that meet the needs of the business.”
This perfectly highlights the contrast. At Facebook, product teams decide what is the best thing to build and are responsible for the outcomes.
In this world, there is a significant amount of work on understanding the customer, user, business and market needs for what you're building. This is why a PM focussed solely on execution is a sign of a non-empowered team. Dare captures this well:
If your team is responsible for outcomes, engineers are happy to drive parts of the execution if it enables the PM to find the most impactful outcome to create.
When engineers are evaluated on the impact they create (ex. grew DAU by +5%), they want the projects that can deliver massive impact. If I were in their shoes, I’d much rather my PM spend time finding these projects rather than managing the tasks of the project I’m working on.
Key points:
Empowered product teams are responsible for outcomes, not inputs. This is why people take on tasks outside of their traditional roles (to support the outcome).
On an empowered product team, everyone thinks about the best way to improve the outcome. This may involve changing the inputs (ex. engineers drive parts of execution so PMs can identify the right areas to focus on).
The best way for a PM to help an engineer is to ensure they are working on the most impactful work.
From the Engineers POV
Let’s go deeper into the perspective of an engineer.
In an empowered product team, all engineers think about the outcomes of the team. They are involved in prioritization, work with cross-functional partners (ex. design, data science) and are evaluated on the impact they create — not the lines of code they write.
Dominik Krejcik wrote an excellent description of what it’s like being a tech lead on an empowered product team:
Being a tech lead in an empowered product team is not a purely technical role. In addition to your typical engineering duties, you are a part of the product manager/tech lead/product designer trifecta and you collaborate on product decisions.
Collaborating on product decisions is possible when engineers have ownership over an area. A way for engineers to grow their ownership is by driving meaningful parts of execution.
Communicating progress, leading experimentation and driving project management will make the engineer the face of the product and necessitate their inclusion in important decisions.
Here are some ways I’ve seen engineers and PMs work together to drive execution:
Creating roadmaps: PM drives the process (with input from everyone) to find the most impactful projects. Once they have been prioritized and the project has been kicked off, engineers own the solution and track progress towards milestones.
Communication: Engineers will drive meetings, documentation and general communication for the feature they are supporting. More senior eng will drive progress for larger areas. PMs will drive meetings, documentation and project management for the entire team.
Project management: PMs create the execution structure (ex. recurring meetings, project tracker, milestones check-ins) and engineers drive it. Engineers who lead these meetings are responsible for raising blockers and support each other for hitting the goals. The PM plugs into the parts of execution that they can best support
These engineers drive execution to develop skills, be involved in product decisions and earn the ability to take on more ambiguous problems.
Key points:
Empowered engineers want to collaborate on product decisions. Driving execution is a great way to develop ownership and become included in important decisions.
PMs and engineers should work together to make sure that execution is well-handled. If there are gaps in the process, the PM should aim to fix them.
Putting this All-Together
When a team is evaluated on outcomes, they adjust their inputs to have the most impact. While we’ve spoken about engineers taking on execution tasks, there are many other permutations of this concept:
If a PM can free up a tech lead’s time to architect a large-scale problem, the PM should jump in.
If a designer can drive the project management to allow a PM to formalize a new partnership, the designer should jump in.
If data science needs leadership buy-in to finalize goals, PMs can jump in to drive that alignment.
This is because the product team is, in fact, a team. It’s not a series of individual roles who sit next to each other.
Imagine a football/soccer team where strikers refused to play defence because that wasn’t their role. This is what some of the gripes on Ben’s original post sound like.
Product managers are leaders on a team. Not because we have any authority, but because we are responsible for the long-term outcomes of our teams.
Sometimes, it’s in the best interest of our teams for the PM to take a step back from execution to develop leaders on the team, define long-term plans and make sure we’re working on the absolute highest priority items.
Thanks for reading. It took me a while to frame my ideas on this topic so I’d be keen to hear your thoughts on Twitter. If you enjoyed this read, share it with a friend:
And if you’re new here, join thousands of product managers who are growing their career by subscribing below:
See you next week,
Love your posts Will! I was wondering if you can talk about your experience working with PMM at Facebook. I don’t see PMM mentioned above.
So, curious to hear how you view their roles.
I find it interesting that companies are constantly inventing the wheel anew, and "discover" things that are readily available to everyone. I think it's just a matter of leadership enabling this to happen, while at other organizations, leadership supports something more strict, e.g. more technical, or more project-mgmt oriented, or more subservient, etc. Best of luck to FB and everyone else who is empowering people to do their best work.