Two in a Box PM
In my earlier article on the six different models of Product Ops I have found in practice, I mentioned that there were two overarching issues behind the most damaging models, and I promised to discuss each further.
In my last article I talked about the tendency to think you can scale with process rather than with people, and in this article I’d like to talk about the tendency to want to split the product management job in two, referred to as the “two in a box” PM model.
One of the things that makes this problem difficult to discuss is that so many people in the product world can’t even agree on what the real role of the product manager is.
This is endlessly frustrating to me, but I’ve come to understand that the root of this confusion is that as an industry we use the same title – product manager – for two very different situations: feature teams vs product teams.
One of the few things both groups generally agree on is that however you define the job, it’s often too much work for one person.
Hence the very understandable desire to cut the role up, and split it among two or more different people.
I will tell you up front that in a great many situations I see, the way the job is defined indeed really is too much for one person. And when I say “too much,” I don’t just mean stress level and work hours, I also mean not having the time to focus on the activities truly critical for success.
But the way the job is scoped down is the key, and unfortunately, the most common ways of trimming down the role have consequences far worse than most companies realize.
Let’s begin this discussion by first saying that what I’m talking about here in this article is the PM role on an empowered product team. In fact, much of what I say below doesn’t even apply to the PM role in a feature team, although many of the remedies do apply.
The job of a product manager of an empowered product team is to be responsible and accountable for addressing value and viability risk. The designer covers usability risk, and the tech lead covers feasibility risk. Together, they create a product.
In order for the product manager to be effective in addressing value and viability, there are a few things that are absolutely critical, and these are what you need to be very careful about preserving as you go about scoping down the role:
Direct Access To Users and Customers
This should be obvious but without direct, unencumbered access to users and customers, the product manager has little hope of any kind of success in solving for value. The users and customers provide not only inspiration for unaddressed problems but also the means to rapidly test our proposed solutions. A little less obvious is the need for direct access to the data about these users and customers, such as how our users interact with our product. I don’t mean direct access to raw data – but definitely direct access to the data tools, and to data analysts that can help interpret confusing or ambiguous data.
Direct Access to Business Stakeholders
Solving for viability is about solving for business constraints, and it’s essential that the product manager has direct access to the experts across your business that are responsible for these constraints – in marketing, sales, services, finance, legal, compliance, manufacturing, subject matter experts, and more. The product manager must establish relationships with these people where the stakeholder believes that the product manager understands the relevant constraints and will ensure they are addressed in any proposed solution.
Direct Access to Engineers and Designer
Finally, value and viability depend on usability and feasibility, and the engineers work daily with the enabling technology, and the designer is directly responsible for the user experience, so discovering a solution that is valuable, usable, feasible and viable is predicated on deep, ongoing collaboration with engineering and design. When you understand why engineers are so consistently the source of true innovation, you understand that if you lose this direct access, you quickly lose your chance at innovation.
What this means is that you need to protect the product manager’s direct access to these three constituencies, and fight any temptation to place a person (or process) between the PM and these people.
It is in fact the direct, ongoing access to these three constituencies that enables the product manager to make good decisions regarding value and viability.
This is leading to another discussion on the very nature of technology-powered products and innovation, but that’s a more philosophical topic, so I’ll be going deeper on that point in an upcoming article, but for now, the point I wanted to make is to please do not slice up the PM role such that direct access to any of these three is lost.
Because this is such an important point, I want to be explicit:
Cutting up the PM job to have a product manager that interacts with customers and stakeholders, but a different person (e.g. product owner) that interacts with the engineers, causes the PM to lose the direct access to engineers.
Similarly, cutting up the PM role to have a different person (e.g. one of the definitions of a product ops manager) interacting with one class of stakeholders – sales, services, support, operations – loses the ability for the PM to have direct access to these critical sources of input.
When I refer to the two-in-a-box PM anti-pattern, it is referring to splitting up responsibility for these three constituencies among two different people. There are many ways this happens, but in my experience, this is a very serious mistake leading to long-term negative consequences.
Hopefully at this point, even on an intuitive level, you can see how if you want your product managers to be responsible for value and viability, you understand why this direct ongoing access to customers, stakeholders, and engineers would be key.
So, you might be thinking, what’s left to cut?
A remarkable amount, it turns out.
Now don’t misunderstand me – all the responsibilities I’m about to describe below are ones I have seen PM’s be responsible for numerous times, but that doesn’t mean that it’s common that a PM has all of these additional responsibilities. Fortunately, I don’t recall ever seeing a situation that bad. But it’s not unusual to find more than one, and realize that each of these can represent a very significant load.
The most common additional burden on a product manager is project/program/delivery management. I’ve written many times about this issue. The good news is that this can be remedied relatively easily and quickly, although ironically sometimes the PM is reluctant to let go of these responsibilities, so coaching may be required.
In some companies, while they may have designers, if they are graphic/visual designers rather than product designers, there’s a pretty big gap left uncovered – service design, interaction design, and often user research as well. This may be tougher to fix because finding product designers is generally harder than finding delivery managers (that’s just an observation on market supply, not a judgment).
User Research Administration
It’s increasingly common for product teams and especially product managers to take an active role in user research. That’s a good thing because of the principle of shared learning in product discovery. However, in many cases, while the product designer plays the key role in user research (they’ve usually been trained on doing that well), the product manager often picks up the research administrative load. This includes recruiting, screening, and scheduling users and customers. It’s not that this is cognitively hard, but it is time consuming. When I find this situation, I strongly encourage the organization to get some part-time administrative help to support this work. It’s a low-cost and high-leverage fix.
This one never ceases to amaze me when I find it, but in a surprising number of companies, the engineers pride themselves on not having QA or test automation engineers. They think test-driven development and a nice suite of unit level regression tests is all they need to do. But in practice, the PM’s end up having to play the QA role, which is normally a very time consuming job, and a big responsibility if the company cares at all about their customers. Now it’s important to note that it’s normal for the PM to be responsible for acceptance testing, but that is a very minor responsibility compared to the much larger quality assurance role. When I find this I tell the CTO they need to either have their engineers step up and ensure they are delivering working software, or they need to hire QA engineers.
Every product manager has some level of customer service responsibilities, if nothing else helping the customer service people diagnose issues and problematic use cases. But in some cases, especially in smaller companies that have yet to staff up customer service or a customer success function, this load can easily grow to consume the PM.
I discussed this in the Product Ops Overview article, but for certain products, the run-time operations load is significant, and while it’s good for the PM to understand the issues so that automation can be addressed where it makes sense, this can also be a very significant and stressful use of time.
The product marketing role (PMM) is often under-appreciated and understaffed. Especially for B2B companies with a direct sales organization, this can be a very large responsibility and very much a full time job on its own. Not every product team, even in the same company, is impacted by product marketing responsibilities to the same degree, but if you have a PM that has significant PMM responsibilities as well, that is a recipe for long hours and a lot of stress.
I’ll admit that this one really irks me. But I meet too many PM’s that tell me that they want to hire an “associate PM” (or some such title) reporting directly to them (in a people management sense) to handle mundane tasks like attending standups, writing user stories, dealing with tickets in Jira, scheduling meetings, or whatever. Yet I point out to them that they can easily end up spending as much time managing this direct report, as they might get in any time savings. But more generally I really don’t like the message a PM assistant role sends to the rest of the product team. The engineers don’t like spending time in Jira either. Should they each hire “associate engineers” to cover the administrative tasks they don’t like doing? Product teams should be a flat structure and the product manager should not have to worry about people management as well as their product’s value and viability, so please don’t do this.
Product Team Size and Scope
The most obvious way to reduce the scope of a PM job is to consider the size and scope of the product team.
There is a natural balance between the product manager and designer, and a given number of engineers. If you have a single product manager responsible for providing valuable and viable solutions for more than about 10 engineers, then this may simply be too much for a single product manager to keep up with, and it may be time to split teams.
Or, occasionally I’ll see a company where each product manager is responsible for multiple product teams, sometimes with more than 20 engineers in total. In every case like this I’ve seen, the results have been weak, almost always devolving into delivery teams.
The tougher case is when the balance is within the normal range, but depending on the nature of the work, and the experience level of the team members, you may still be out of balance. It’s normally a lot less work for a PM to cover a team of 4 engineers versus a team of 8 engineers. In this case, you can consider reducing the size and/or scope of the product team.
But this quickly becomes a team topology topic, with much more significant implications. Further, there are other benefits to having larger scope product teams, especially in terms of empowerment and autonomy. So I prefer to focus first on reducing the personal responsibilities of the product manager.
But as you can see, if you want to prune down the responsibilities of your product managers to ensure they have the time and energy to sustainably cover their critical responsibilities, there are usually several very effective ways to do that, without gutting the role and destroying your chances of innovation.
One last important caveat: There is a real difference between a product manager at an early stage startup, versus at a growth stage or established company. In many early stage startups, there literally are not enough funds to have people dedicated for many of the roles, and in practice the product manager often picks up much of this work (everyone usually has to wear multiple hats). Partly this works out ok because the load is usually still small (e.g. we don’t yet have many customers or stakeholders). But I’ll also admit that I’ve never felt more pressure than during my early stage startup experiences, so it’s important to know what you’re getting into if you want to join an early stage company.