I smiled as I read the title and thought, “Alright Lopp, I’ll bite”. How could I resist?
I paired up with the one-and-only Michael Lopp to facilitate the session and it was truly one of the most interesting a-ha conversations that I’ve had the opportunity to take part in for a while.
Honestly, this also couldn’t have been better timed. Having just started a new role (as a Head of Product and Design) with a team of Product Managers and Product Designers in my care, I was facing some challenges with how my team was working with our engineering team. Recognising that while they were doing a great job, there’s of course always room for improvement.
I was extremely grateful for this chance to hear the varying perspectives within this room full of developers, all with different experiences to share.
There was one thing that really stood out to me during these chats.
There are probably two types of devs. Those who’ve worked with excellent Product Managers, and everyone else.
The devs who had positive experiences with Product Managers seemed to understand and appreciate the role of the PM within the team.
But.. there were a lot of devs in the room who had worked with bad* Product Managers. Unpacking the definition of what made a bad* Product Manager was rather fascinating.
As I listened to multiple recounts of experiences laced with frustration, there seemed to be two common threads.
- The expectations of the Product Management role were wildly different from person to person
- The bad Product Managers were mostly criticised for the ‘managing’ part of their title
You could almost feel the collective shudders when there’d be mentions of the PM dictating directions to the team on what they needed to do and when, without much consultation or collaboration.
The examples kept rolling in where the PMs had treated the team as resources, not being inspiring or motivating, absence of mutual respect, and seemingly being ill-experienced as servant leaders.
I wondered if these concerns were ever raised with the Product Managers and frustrations properly addressed and resolved. If not, surely these were toxic workplace environments to be in? I also wondered where this management style came from; did they pick it up from their managers? Or previous mentors? Perhaps these PMs were great subject matter experts, but were they experienced with management as a skill?
Could it possibly be that having “manager” in the title is a word that causes the role to trip up?
I’ll admit, coming into this current role that I’m in, the lack of shared understanding for the definition of Product Management across the org was the biggest point of concern. Management had one idea, the tech leads had a different idea, the PMs had another idea, and it was an all round cluster bomb. I had a team of hard working, highly skilled folks in my team, but the misalignment of expectations, upwards, inwards and sideways, meant that the role was unfortunately never set up to succeed. This environment was incredibly unfair for those concerned and it was the first thing I wanted to set out to change.
Reaching out to my industry peers for their perspectives, it seemed that the confusion surrounding the role and what it entails was equally murky out in our creative tech world. Why is that? Could it be because the artefacts aren’t really as obvious as most other roles in a product and engineering team? A common response that I received was, “It’s just like a project management role, right?”. Hmm…! It was time to unfuzz this mysterious role.
I found this thread by Noah Weiss (see image above) talking about the harmful myths surrounding the PM role. He subsequently wrote a great blog post around the topic.
He describes the 5 myths below:
Myth 1: PMs are mini CEOs
“Teammates want product leaders, not dictators.”
Myth 2: PMs are the decision makers
“PMs are responsible for the pace and quality of decision making. Full stop.”
Admittedly, I’m guilty of having initially thought differently on this point in the past. I now actively endorse “shared responsibility” of the decision making with the PM facilitating to ensure the quality of these decisions with the team.
Myth 3: PMs are the idea generators
“In an ideal world, creative brainstorming is a constant team exercise that the PM just happens to drive.”
Myth 4: PMs have to be great at company politics
“(great PMs) keep disparate groups bought into a shared vision of where the company and its product need to head.”
Myth 5: PMs need technical degrees
“PMs do need to have a deep curiosity about the underlying technology behind their projects.”
I believe that a lot of these kinds of misconceptions of the role have stemmed from Product Managers generally coming from such unique and dynamic pathways, typically having worn multiple hats in the lead up. There’s no direct career trajectory to the role, meaning that the experience and specialisations between one PM to the next can be worlds apart. This can understandably add to the confusion…
We’ve seen this kind of confusion in other roles though, right?
What is thy purpose?
In a time where we see these questions such as, “Should designers code”, “Should developers design”… what if we considered:
“Should Product Managers….”
- Be technical? (Design, Engineering, UX)
- Have business degrees? Be business analysts?
- Spend time with customers? Conduct user interviews?
- Manage people? Resolve conflicts? Shield the team?
- Understand digital marketing? Build digital marketing campaigns? Be growth hackers?
- Write stories? Groom backlogs?
- Set strategy and direction?
- Create user journey maps?
- Conduct UAT testing?
- Facilitate workshops? Mediate?
- Be data analysts?
- Seek opportunities?
- Ideate and innovate?
- Build roadmaps?
- Create dashboards?
- Be decision makers?
- Approve PRs?
- Conduct market research?
- Project manage?
I honestly wonder… have we created some kind of full stack product role?
Titles. It’s not too dissimilar to what we’re seeing with this wave of titles that are appearing in our industry for designers and developers (Product Designers, UI, UX Designers, Principal Designers, Service Designers…. Dev Ops, Back End Devs, Front End Devs, Interaction Designers/Developers… etc).
Then we have our full stack unicorns which we often wonder if they truly exist, right? Currently, product is just… product, but should the Product Management role be split up into specialist areas as well?
I enjoyed this read by Kit Ulrich outlining 6 types of Product Managers and the strengths and possible weaknesses of each of the verticals.
- Type 1: The Growth Hacker Product Manager
- Type 2: The Workflow Warrior Product Manager
- Type 3: The Community Connector Product Manager
- Type 4: The Platform Product Manager
- Type 5: The Data (AI) Product Manager
- Type 6: The Mobile Product Manager
She describes these different specialist types in the contexts of what type of PM your team and company might need at various stages and sizes. Her follow up post about identifying the different types of PMs during the interview process was also equally as fascinating.
There have been plenty of posts about good PMs versus bad PMs published, and I’ve read a lot of them. A side note that I particularly enjoyed this modern day take by Hemal Shah, which seemed to cover most bases. Definitely worth a read!
Final thoughts…
I’ve come to the conclusion that the role is unavoidably going to be defined differently depending on the product, the company, the goals, the needs of team and the specialisations and experience of the PM in the role. That’s a certainty. My concern is when there are expectations of the role that aren’t clearly communicated and agreed upon, leading to unresolved tension and resentment bubbling into the team’s culture.
To avoid these unsavoury scenarios, I believe it’s most important that there is an abundance of support for the PM role, because it’s in turn, a key support role for the team. So…
If you’re a leader reading this; identify and amplify the strengths and specialist verticals of your PM. Recognise their weaknesses and provide pathways for them to level up and grow in those areas. If you want them to successfully be of service to the team, lead by example for them to see what they can be.
If you’re a peer of a PM; actively get to know your PM’s day-to-day better. Please be open and honest with them. If you have expectations of their role, open up the conversation so that you can help each other work better together as a team. The team’s success is also their success. Help by showing, not just telling.
If you’re a PM; please always remember that your role is a service role (to the team, to the customer and to the business) and that your success is closely coupled with the team’s success. Therefore, it’s in yours and the team’s best interest to identify and amplify the strengths of the individuals in the team — lean on them and encourage them to do the awesome things they do. Learn, and share your learnings. Be flexible, be curious, be humble.
To all; we’ve surely all heard the saying, “Good Design Is Invisible; Bad Design Is Everywhere”. Let’s imagine replacing the word design with product management and together, let’s appreciate that when product management is done well, we probably won’t notice it. And that’s totally okay.