The Evolving Role of Product Managers
Why teams hire a PM in the first place and how the PM role evolves as the company grows and makes intentional decisions about its culture
A couple months ago I shared a tweet & LinkedIn post that caused a bit of a stir in the product management community:
Turns out this was a controversial thing to say!
Many responses followed. Some of these were summarized by a fellow PM at Facebook named Will Lawrence, along with his excellent overview about the execution muscle at FB, in his post Execution at FB (I recommend subscribing to Will’s newsletter if you’re into this topic). I won’t do a better job than Will in describing how we execute at FB.
That said, I do want share some more thoughts on this topic.
Before the First Product Manager
While there’s some debate about exactly when software product management became a dedicated role, it’s generally agreed today that product management existed as a shared responsibility within product teams for many years before the first full time “product manager” showed up on the scene.
A team can certainly operate without a dedicated Product Manager; I’ve seen it first-hand because I joined two different startups as the first PM. They were shipping and generating revenue before I showed up.
From my direct experience and that of friends who were in similar boats, before the first PM joins, teams generally build features that they see as “obvious” and “necessary”.
These features get identified by the team through one of five mechanisms:
The founders are basing the next funding milestone on it
Customers refuse to use the product without it
Competitors have it so it’s needed for feature parity
A team member has a personal desire to see it exist
Business can’t operationally scale without it
In my experience, it’s rare to see a particular new feature check all of these boxes at once. Given scarce resources in a startup, not all the features can get built in parallel. So the team needs to prioritize!
Without dedicated product managers, a feature gets prioritized in one of four ways:
Founders tell engineers what to build
Engineers decide what to build
Sales or ops bug engineers to build
One-time prioritization session
This process is not disciplined and happens organically, with little predictability. It’s exciting, fun and chaotic. Every week is completely different.
To summarize:
Teams without a PM lack a clear and repeatable framework for prioritization
Before I talk about how the incoming PM crashes the party and ruins all the fun, I want to acknowledge that I’ve had a tremendous amount of fun myself in these chaotic situations. And it’s important to remember that the reason the company can even afford to bring in a PM is because the chaos was mostly working. Customers were paying, investors were funding it, and talented people joined before me. So clearly, a lot of things need to be working really well before a PM can even enter the picture.
At this point you might be wondering: why hire a PM at all if the team is already able to consistently ship products that customers want to pay for?
This question will bring us to the crux of the issue.
The reason companies hire PMs is because they recognize that the process that got them to the current stage will NOT get them to the next stage
Let’s break this down.
Imagine the chaotic 30-person startup I described above. This team has maybe 15 engineers, an engineering manager, 2 designers, 2 marketing people, 2 sales people, a finance person, a recruiter, and the founders. There might also be a QA engineer, a product marketing person, an HR person, a data analyst, etc.
This team has been able to delight customers and establish itself as a hot new company in its space. It raises a $15mm Series A at a $75mm valuation. The money will be used to scale the team and fuel growth. High fives go around and congratulatory messages flood the inboxes. The founders are now millionaires on paper.
With the money in the bank, the leadership team starts planning how to execute on the milestones for the Series B: grow revenue, get more customers, etc.
They realize that they’re at full capacity with the current development team. The company needs more engineers to hit the goals. Thus, hiring becomes a top priority. More engineers will create more capacity and then they’ll be able to build more features, which should:
Accelerate next funding milestone
Enable new customers to adopt the product
Reach feature parity w/ competitors
Keep current team members engaged & excited
Allow business to scale operationally
So the company pours gas on hiring engineers.
The eng team doubles from 15 to 30 over the next six months. Onboarding engineers is challenging and time-consuming but the earlier team members did a stellar job preparing to plug new engineers in.
With the growing engineering team, the founders start making more ambitious plans and promising bigger and better features to customers and start hyping up investors for the next round.
A specific big feature starts emerging as a game changer. This one feature is going to sell new customers, bring the product into feature parity with the competition, and everyone’s excited about it.
Weeks go by and the feature is behind schedule. At first, it’s only a month late.
Then, it’s two months late.
Six months go by and it’s not ready. And it’s not just this one feature. A lot of the other projects in the pipeline hit roadblocks and begin falling behind.
The tension is building up as customers who signed with the promise of a critical new feature being around the corner realize the new feature might never come.
Customers who championed the product internally are getting grilled by their teammates on their poor decision.
The leadership team comes to a crushing realization:
The engineering team doubled in size but somehow the team is now shipping half the features they used to ship.
They’ve slowed down when they were supposed to be accelerating.
The founders convene an emergency company all-hands to diagnose the issues.
At first, nobody speaks up. Finally, someone admits that things have become too chaotic. Engineers are getting stretched too thin and constantly switching context. Newly hired engineers need more hand-holding than expected.
As a result, 30 engineers are now producing about 7.5 engineers of productivity.
Engineering leadership is called to do whatever it takes to produce 30 engineers of productivity. They embark on a listening tour with the engineers on the team, asking what would help them be more productive.
A theme emerges with resounding consistency:
Engineers are spending too much time reacting to internal requests and don’t have enough time to write and review code.
A new rule is implemented: nobody is allowed to talk directly with engineers. Any engineering requests need to go through eng leadership.
Weeks go by, and engineers start reporting increased levels of focus and productivity. They have time to mentor the new engineers while getting their own work done. PRs are getting reviewed on time and merged in. Features start shipping again. The train is accelerating.
This rise in engineering productivity at the individual contributor level is accompanied by a barrage of feature requests to engineering leadership, who have now become the triage layer between stakeholders and engineers.
Engineering leaders are now in back-to-back meetings all day with their colleagues to talk about why new feature X and new feature Y are essential. Engineering leaders can’t find time to spend with engineers and the engineering culture starts to suffer.
The situation isn’t sustainable.
Desperate for ideas, engineering leaders start talking to their friends at other companies who have also reached this stage and ask for advice.
A theme emerges:
Engineering leaders have discovered they can offload the bulk of the internal discussions around which feature to build next to product managers.
Hiring product managers allows engineering leaders to focus on scaling the engineering organization and building a healthy culture while spending less time discussing features that might never even get built.
The next step becomes clear: the team must hire a product manager.
The First Product Manager
When deciding to build a product management org, the first decision is who to hire first: an individual contributor (IC) or a manager.
I’ve seen some companies hire their first PM as an IC who reports directly to a cofounder or CTO. I’ve also seen companies hire their first PM as a player/coach who steps into the role of manager as soon as they’ve onboarded and are ready to hire the first IC on their team.
I’ve joined a team as a first PM in each of these scenarios:
Once reporting to a Director of Product, Design and Eng (who was not the first dedicated PM hire)
Another time reporting to a Director of Product Management (who was the first dedicated PM hire)
Either way can work, but the decisions come with tradeoffs.
I recently caught up with a friend who is a cofounder of a Series A startup and sees his company hiring their first PM in the next 6-12 months. I told him it’s a huge decision and that the person they bring in can either really accelerate things in a positive direction or can genuinely bring the execution muscle of the team to a halt.
Who should you hire as your first PM?
In my experience, the answer comes from asking a couple key questions:
Which problems are you looking to offload to this person?
Are you looking for someone to solve execution problems or someone to drive strategic product direction?
Tasking a new PM with strategic direction-setting is very different than asking them to build a predictable execution cadence on the team within a well-defined direction. I think early-stage founders are mostly looking for the latter. The reason is that they’re not looking for someone to come in and question the strategy and direction for the product. They’re looking for someone to ship, ship, ship.
As a founder, it’s important to be honest with what you want. My sense is most founders should hire a first PM with 2-3 years of product management experience and a proven track record of setting up a team for execution.
Which brings us to the core of my controversial posts:
PMs at small startups need to be process-oriented execution machines
This is simply the “industry standard” play & play execution playbook. If you walk into a chaotic product org that consistently misses ship dates, a bit of process goes a very long way.
One misunderstood element of my posts is that I’m not condemning task creation and sprints as a responsibility of PMs. I’m simply saying that these are valuable parts of a PM’s job when the team is shifting from a chaotic environment into a predictable cadence.
That said, I think early stage startup PMs should still get out of task management and sprint planning as soon as possible. I’ve come to believe that the natural owner of day-to-day engineering execution should be the engineering manager for the team. The EM understands the capabilities of the individuals on their team and ultimately needs to be accountable for matching people with bugs/features that fit their strengths, interests and career goals.
With the EM handling sprint planning and ticket creation with engineers, the PM can shift 50% of their focus to forward-looking strategy and ensuring the bigger picture isn’t being overlooked.
Let’s now fast-forward 15 years to contrast the role of the PM in these early days with the role of the PM in a big tech company like Facebook.
The 2000th Product Manager
The company now has sixty thousand employees and two thousand product managers, the role of the PM changes quite a bit. The PM culture of a company is shaped quite heavily by whether it’s a top-down strategy company or a bottom-up strategy company.
FB is a top-down company when it comes to priorities and org structure. However, when it comes to product strategy, it’s driven by the product managers at the ground level.
PMs at Facebook are expected to take full ownership of the most important problems in front of them rather than waiting for top-down guidance. There’s a saying at FB that “nothing is someone else’s problem”. The role of managers in this culture is to support the individual PMs and it’s the responsibility of the PM to ask for specific kinds of support.
While the PMs are carrying the strategic responsibility for the team’s 2-year investment plans and partnerships with the necessary teams to make it happen, the PM at FB still certainly contributes to execution. I encourage you to reference Will’s excellent post for more info on how we execute @ FB:
On my team, here’s how I’ve influenced execution:
Lead our 10-week roadmapping process, which includes everyone on the team
Prioritize the problems we’ll tackle the following half
Prioritize the projects we’ll tackle the following half to solve those problems
Ensure XFN staffing is secured where needed
Set the team target for the half based on these projects
Create the project briefs at the beginning of the half for each project and invite XFNs to chime in on respective sections (background, problem, opportunity, solution, audience, success criteria, metrics to monitor, experiment plan, etc)
Secure commitment from partner teams to support where needed
Block & tackle as challenges arise to keep the project moving forward
This operating model has allowed me to set the direction of the team’s investments while empowering the individuals on the team to drive their projects with very little involvement needed from me.
I’ve received a ton of feedback from the team that this is the healthiest team dynamic they’ve experienced and have enjoyed the results of this setup personally and professionally.
In Summary
I have nothing against tasks, sprints, backlogs, or Jira
These are essential for a team to shift from a chaotic team that consistently misses release dates to one that executes with a predictable and disciplined cadence.
Once a company establishes a predictable shipping DNA, it needs to make a very intentional decision choice from two paths about the role of PMs in their company:
Keep PMs operating at the Jira level (tickets, backlogs, sprints) and put the strategic responsibility on leadership and management.
Entrust these responsibilities to engineering managers, empowering the PM to drive team strategy while still supporting the execution muscle of the team.
The path that the company pursues will shape the product culture of the company for many years. Both paths can work, as long as the decision is made intentionally.
Thanks for reading!
If you’d enjoy having these delivered directly to your inbox, subscribe below 👇
If you enjoyed this post and want to share it with others, I’d appreciate it 👇
Great post, Ben! Thoughtful, comprehensive and well-written! I fully agree the biggest impact the PM can make is stepping away from being a task-master!