Don't Split the PM Role Into Multiple People
Hiring PMs *and* Product Owners / Project Managers / Technical PMs will slow down your SaaS startup
TL;DR - Product Management is a broad role. It’s tempting to split the job into a person who specializes in strategy and market/customer needs (“Product Manager”), and a person who specializes in execution and working with engineers (“Product Owner”, “Technical PM”, etc). But splitting usually leads to slower decisions and unhappy orgs. A better approach is to hire and train “full-stack” PMs.
A big challenge for Product Managers is balancing strategy (“what should we do?”) with execution (“let’s get it done!”). Finding the right balance between the two is never easy. One seemingly-promising solution is to split the PM job into a strategy-only role of “Product Manager” and an execution-only role, often called Product Owner, Technical Product Manager, Program Manager, or Project Manager.
In B2B Product teams, this split is usually a bad idea. It costs money and morale. But worst of all, spreading the work around usually makes teams go slower, not faster as intended!
This post coalesces what I’ve seen—across more than a decade of managing B2B product teams in both startups and BigCos—of various challenges that come with splitting the PM role, and how to avoid those challenges.
Splitting PM: why it happens
In a SaaS startup, the typical reason why these roles are split goes like this:
“Jimmy” on the Marketing (or Sales, Marketing, Support, etc.) team has lots of domain expertise and understands customer needs really well, but he’s disorganized and doesn’t like to sweat the details. He travels a lot so is often unavailable to answer questions. He also has limited tech experience and has no idea how tech products get built. And he’s always randomizing the developers so they dislike him.
“Victor” is a junior PM with great organizational skills, good rapport with engineers, but isn’t very familiar with the market, isn’t plugged in with the Sales team, and isn’t comfortable presenting to or defending his decisions to management.
Naïve leaders might think that the right solution is to put Jimmy in charge of roadmap and product decisions, while Victor can focus on executing those decisions by working with engineers (and everyone else) to get the product shipped. Jimmy likes this because he can direct the product without getting sucked into the weeds. Victor likes it because he can stay in his comfort zone: working with engineers and focusing on “process”. Everyone wins, right?
Wrong. Building a tech product is not like plugging an address into Google Maps and blindly following directions for 500 miles. Building tech products is like a NASCAR race where the driver and the pit crew continually make hundreds of decisions—large and small—to make optimal use of scarce resources and to beat the competition. If you slow down your decisionmaking process or reduce your decisionmaking quality, then you’ll lose the race.
To make decisions well and quickly, you need one person who’s empowered to make decisions and who has context (business, technical, interpersonal) about why those decisions are and should be made. That person doesn’t need to have the job title “Product Manager”, but they do need to understand the business, understand how tech products are made, and to be consistently available to work with engineers and others to make decisions and tradeoffs. “Jimmy” never has the bandwidth nor inclination to do this. He’ll get bored!
Your best answer is to hire “full-stack” PMs who have both great business/product sense (“what should we build?”) and great execution chops (“how do we get it built quickly with the right level of quality?”).
But life isn’t perfect. Imagine you have a flaky Jimmy and a shy Victor on the team. How can you make it work? Here’s what I’ve done in the past in similar cases:
First, I’d send Victor and Jimmy on a road trip for a few weeks to visit customers. Jimmy’s job is to educate Victor about what the market needs. Victor’s job is to absorb knowledge from Jimmy and the customers they visit. The goal: Victor should be able to answer most questions without having to bug Jimmy, but also should learn which questions are complex enough to need Jimmy’s advice. If possible, engineers and designers should go with them—the more the merrier to learn about customers.
Then, when the team is back in the office, Jimmy, Victor, the lead Engineer, and other senior team members should lock themselves in a room for a day or two and hash out a draft roadmap. Given that they’ve all seen the same customers, firsthand, getting consensus is easier than you’d think.
After that, Victor should keep Jimmy closely in the loop, ideally with regular 1:1s so that they can discuss progress, solve problems, and ensure that Jimmy feels involved *without* having to directly bother the engineers. When it’s time to present progress to the management team, Victor should present but should pre-review with Jimmy so that Jimmy supports him publicly when the heat is on.
But on a day-to-day basis, the team should know that Victor is the go-to person for product decisions.
And if Victor can’t do this, then you probably need to recruit a “Caroline” who is capable of thinking about both business and execution at the same time.
Even great split PMs are inefficient
The story above is a typical case of roles being split because of skills gaps. But even if you put perfect people on both sides of a split PM role, there’s still an inherent inefficiency. It’s easy to see this graphically:
Going from a team of 3 to a team of 4 will *double* the number of interpersonal connections that must be managed! It also makes it harder to schedule meetings, makes team-wide ad-hoc chats less practical, makes it harder to get consensus quickly, increases the number of different opinions that must be addressed, increases the chance of misunderstandings, and so on.
The point is that human groups work faster and more efficiently if they’re composed of fewer individuals with a wider set of skills. It’s one reason why startups can move faster than BigCos.
This is why replacing one PM with two PM-like people will seldom speed things up.
In theory, you could arrange things like this:
This organization might solve the “number of relationships” problem, but it also means that neither of the Partial PMs have a full picture of what’s going on. One of them knows implementation status and has great synergy with engineers. The other understands the strategy but can’t make the day-to-day adjustments in that strategy based on what’s happening during implementation. This is also inefficient.
How to hire and support Full Stack PMs
It’s hard to find PMs who are both good at strategy and good at execution. Luckily, in a SaaS startup you only need a few PMs. For example, when I left Splunk a year before IPO, it was valued at several billion dollars and had fewer than 10 PMs. So be picky!
One thing I do when interviewing PMs is that I always ask to see multiple writing samples: one that’s more technical and focused on execution (like a spec or PRD that engineers read) and one that’s more business-focused: a product plan, roadmap, strategy doc, etc.
Then during interviews, I like to ask questions about both docs, and test the candidate’s understanding with follow-up questions about both high-level and low level concepts. If I don’t see comfort and competence in both areas, then I’ll usually pass.
Every candidate will be stronger in either strategy or execution. Nobody’s perfect! So I like to help newly-hired PMs gradually stretch themselves in their less-strong area. For example, I might assign a part of a strategic plan (like a mini-roadmap for one part of the product) to a new better-at-execution PM, or ask a strategy-comfortable PM to partner with a senior engineer on a complex feature.
Over time, people tend to gravitate to where they’re most comfortable. This can exacerbate an imbalance between strategy and execution. Therefore, I periodically check in to make sure that each PM hasn’t veered too far into either a strategy or execution focus, and I’ll help them find projects to get in balance.
Avoid the “strategy-only PM” fantasy
Many MBA grads or consulting-company alums see the Product Manager job as “strategy”.
This is related to a romantic conception of PM as the “CEO of the Product”. And CEOs delegate low-level work to underlings, right? This assumptions leads to the idea of a “strategy-only PM”.
PMs should be responsible for defining product strategy: what to build, for whom, when, and why. But in almost all companies, product strategy can’t be a full-time job because while building a good strategy takes a lot of skill and experience, it doesn’t take a lot of time. If you know your customers and market well, it simply doesn’t take that long to build a solid product strategy and roadmap.
In great companies with great engineers, it might take 10x more calendar time to execute a product strategy than to define it. That’s the best case. For most companies, it’s more like 100x. But it’s always vastly harder to deliver than to dream.
So for strategy-only PMs, what will they do with the rest of their time? There are many possibilities. All of them bad!
They could continue writing and presenting ever-more-detailed strategy docs. But fine-grained long-term planning in a tech business has diminishing returns. Plans usually don’t play out as you’d expect, due to changes in the market, learnings from shipping the first release, or any number of other reasons. Reality forces you to adjust.
Another way strategy-only PMs can keep busy while waiting for teams to execute is to become the Strategy Police, micro-managing the team’s output without actually doing the execution work required to speed up the team’s delivery. This sometimes can help, but mostly it just makes the rest of the team resentful.
Another thing strategy-only PMs may do is to start intruding into the strategy of other teams, like Marketing or Sales, in an attempt to carve out a wider role for themselves driving cross-team strategy. This also annoys colleagues and often pushes PMs out of their comfort zone of product and business strategy into areas where their experience and instincts add even less value.
I could keep going with more examples, but you get the idea: PMs need to spend their non-strategy time helping the team to deliver on the strategy, not finding some other make-work in the meantime.
And if a PM says that they need 40+ hours per week simply to define the strategy, it’s a sign that they don’t know their customer or market well enough, or a sign that they can’t build a strategy. Or both!
Don’t PMs in Big Companies have Strategy-Only Jobs?
BigCo PMs sometimes brag that they exclusively focus on strategy.
I have good friends who are PMs at Meta. Ben is correct that Meta’s engineering teams tend to handle much of their own project management. So what do PMs at Meta spend most of their time on? From what I hear from my Meta friends, it’s *not* defining the strategy and roadmap, which (like in startups) doesn’t take that long.
The rest of their workdays are filled with BigCo-specific coordination tasks:
Hours every week in cross-team meetings simply to keep work on track. Meta even has a special acronym for this work—“XFN” meaning “cross-functional”—and PMs’ annual performance reviews rate them on these skills!
Hours preparing slides and documents for executive reviews, and following up with executives afterwards to make sure their feedback is incorporated in the plan.
Socializing plans with different teams and executives so that the high-pressure meetings above actually go well.
Learning about what other teams are doing, and adjusting strategies so that they align (or at least don’t conflict) with their own team’s strategy.
Responding to changes in direction or re-organizations that are internally driven, rather than responding to customer feedback. If you have a new manager or a new team every 6-12 months due to org churn, it takes a lot of time to adjust!
Lobbying senior management for budget and approval to actually execute the strategy that they’ve defined, and defending their budgets and approvals against other teams’ priorities.
This is not unique to Meta. I was a BigCo PM for many years before switching to startups, and the list above was a big part of my job there too. Personally I prefer startup-style execution, which is mostly working directly with engineers, designers, and customers.
PM roles without strategy are also bad!
Many PMs get pigeonholed into non-strategic roles where their entire job is focused on executing decisions made by someone else. For good PMs, this creates a backlash which can look like this:
If you’re a PM in a job where you don’t define the strategy that you execute, then you should have a frank discussion with your manager about why.
It could be that they don’t trust your instincts or knowledge about the market. And don’t assume that your manager is off-base about this! Business strategy can take a long time to learn how to do well. Don’t expect to drive everything overnight.
It could be that your manager is inexperienced or uncomfortable with delegation. It could be that they’re trying to shield you from something they don’t think you want. There are lots of other possibilities. You’ll never know until you ask!
It’s a great opportunity for you to ask for help in how your job can be more strategic. Not strategic-only, but strategic *and* implementing that strategy.
