Three Common PM Role Antipatterns

Product Management has been around for a good 40 years, but many companies are still figuring out the basics, including the role of PMs, their reporting line, and relationship with other disciplines. 

Getting these things wrong  can waste a lot of your product management resources and frustrate both the PMs and the people working with them. In fact you may get negative benefits. 

Here are three major PM role issues I see come up (plus one bonus). 

1. Product Managers reporting to a non-PM Manager

This antipattern has multiple variants:

• PMs reporting to the CTO/VP engineering
• PMs reporting to COO/CIO
• PMs reporting to Head of Marketing or head of Sales

While there’s some allure in putting PMs in the same org with the people they need to collaborate closely with, all of these options are problematic. I’ve written about this issue in the past: 

Product managers are a special breed of animal — neither engineering nor business nor design. They thrive when they report to senior PMs who understand their unique set of challenges, can coach them, and give them the freedom they need to do their jobs. Reporting to non-PMs, while possible and not uncommon, can hamper career growth and performance.

My general recommendation to CEOs is to create a product org reporting to a chief product officer (CPO). If there’s no room for a CPO it’s best to have the PM org report to a head of product (ideally a senior and experienced person), who reports to the CEO or to the general manager of a business unit.

It’s not a good idea to have product managers report to a pure-engineering manager or a pure-marketing/sales manager. As well-meaning as those individuals may be, in both cases goals will not be well aligned. Instead of focusing on finding the right product the PMs may be asked to help close deals (aka business PMs) or help make engineers fully productive and happy (technical PM, or now, Product Owners). I’ve been there and I can tell you it’s not fun for the PM and not helpful for the org.

---

Join thousands of of product people who receive my newsletter to get articles like this (plus eBooks, templates and other resources) in your inbox. 

---

2. Splitting the PM Role

The role of product managers is very rich and involves many interfaces: with customers, engineering, design, marketing, sales, and marketing. Over the years there were multiple attempts to split the role in various ways:

• External facing PM vs internal PMs
• Business PMs vs. Technical PMs
• Strategic senior PMs vs. Tactical junior PMs

With the adoption of Agile Dev we saw the emergence of Product Managers vs. Product Owners.  I wrote about this one too in the past:

In my early days in product management there were no product owners, just product managers. The term was introduced a few years later with Scrum, the most popular Agile development methodology. Product owner (PO) is an important role within scrum, working closely with the development team as the representative of the customers/users and of other stakeholders, and, among other things, managing a prioritized product backlog that feeds the team with work items.

This sounds like a good fit for a PM, but of course it’s only a subset of what modern PMs do. Today’s PMs don’t dictate requirements based on “market research”. They work closely with with the team to discover the product that best addresses the goals. This version of product management sits at odds with the more classically defined product owner.

I’m not sure that the authors of scrum intended to create a real-world role called product owner, but that’s just what happened. Today companies are hiring full-time product owners by the boatload, mainly for two reasons:

Recent interpretations of scrum are putting far higher demands on POs, requiring them to write detailed epics and user stories, to attend planning sessions, retrospectives and daily standups, and more. This can easily become a full-time job.

Managers like the concept of dividing the work — strategic, outbound-facing product work handled by senior, full-fledged, product managers or by the managers themselves while the grueling tactical work is handed off to the POs. It’s not the first time this was attempted, but to my knowledge it has never really worked.

If it’s not already clear, I’m not a fan of the current product-owner-as-a-full-time-job model. I don’t believe there’s a neat way to split product management work along strategic and tactical responsibilities and I don’t feel that’s a great work experience for the product owner. The solution lies in reducing the tactical load on POs, through delegation to team members and reduction in process overhead, enabling them to perform the other important functions of the PM.

3. Siloing PM, Engineering, and UX

This is not a very common one, but I run into it with some regularity. In some companies the heads of engineering or UX attempt to optimize their team’s time by employing an agency model. There are no fixed cross-functional teams. Instead each quarter new ad-hoc teams are formed according to goals and roadmaps. The engineers and designers are treated as generalists that hop from area to area and from project to project as needed. Engineering managers argue that this keeps developers more engaged as they constantly learn new things. Some UX leaders prefer this model because they believe that to be effective a designer must be embedded with other designers rather than with a cross-functional team.

In my experience this approach always creates major issues:

• Misalignment — PMs, UX and engineering are more likely to be committed to their own disciplinary goals (for example: deliver maximum number of features, use proper design principles, maintain high code quality). Finding a compromise becomes much harder. The success of the product becomes the problem of the PM, who is treated as a customer of sorts. 
• Lack of area expertise – Engineers and designers that continuously work in a particular area of the product (say Search, or Payment) develop expertise in the technologies, the codebase and the user experience. In the agency model a lot of knowledge is dispersed or lost and the team is far less effective.
• Lack of team spirit — Product teams take time to gel and learn to work as a unit through multiple cycles of product development and launches. This doesn’t happen with ad-hoc teams. 
• Handoffs — This mode of work encourages mini-waterfall, where the PM hands-off requirements, designers hand-off mockups, and the engineering team push out working code. We get all the downsides of waterfall, including planning overhead and lack of agility. 
• Decisions don’t stay in the team — In the agency model engineers, and especially designers, are encouraged to review and make decisions with their disciplinary colleagues. So a PM may be told that she can’t have a particular feature, because the design committee (to which she wasn’t invited) deemed it a wrong approach. This is very different from PM, UX and engineering working closely to define the product, and then taking it to reviews as needed. 

How to fix:

• Create cross-functional product teams with clear sense of identity and mission 
• Create leadership trios – Starting with team leads and up the management hierarchy PM, UX and eng leaders should form trios (we called them triads at Google), and collaborate closely. Directors and VP trio work close to break the walls between the disciplines and encourage cross-disciplinary collaboration. They strive to empower teams and give them all the context they need to make decisions on their own.

Bonus: Introducing Product Management without Changing the Mindset

“Product Management Requires a System Change” is a keynote I’m regularly invited to give. I believe there’s a reason. Many companies realize that their product organizations are not as effective as they ought to be because the company hasn’t adapted. Product management, which is about discovering and delivering the product that maximizes value delivery and value capture, is something  the entire organization needs to take part in. To do it right we need to let go of old habits and embrace new principles:

• Customer focus (instead of solely sales-focus or tech-focus) 
• Evidence-guided-decisions (as opposed to opinion/rank-based decisions)
• True agility/adaptability (as opposed to plan-and-execute) 
• Empowered product teams (as opposed to command-and-control management) 

Not changing is the underlying cause of a lot of the issues we saw above. The good news is that when there’s a true desire to modernize, PMs can be very effective agents of change. They can bring people together, make the business case, employ new principles and frameworks, and communicate results. With help form the top, training, and patience, positive progress is very possible.

Image: Jacques Carelman, Impossible Objects

---

We discuss in-depth the role of PMs and the frameworks they use to create high-impact products in my Lean Product Management courses. 

Secure your ticket for the next public workshop or contact me to organize an in-house workshop for your team. 

---