Let’s start from the beginning: Why was the Product Manager (PM) role created? Before I get started, I kindly ask for agility out there: Open your heart and mind and hear me out first.
Scrum came about around 1986, the internet was in its infancy, and smartphones were a Jetson’s futurist comic idea. Later came the Agile Manifesto at a time when we still used to package and ship software physically. Aiming at fixing dysfunctional organizations and making developers’ lives better, a group of great engineers came up with the Agile manifesto.
As we don’t ship software physically anymore, we have smartphones, ten more languages, 200 new frameworks, and more… Why do we keep believing the PM role doesn’t need to change, adapt, or die completely?
Origin(s)
In 1931 McElroy, ahead of his time, wrote a short memo where he described the “Brand Men”:
“Who had the responsibility for the brand and managing a product through experimentation and customer interactions.” — McElroy
Then Scrum comes along, pumping up the Product Owner.
The goal was to eliminate the typical Product Manager’s failure to throw requirements over the wall to have the customer receive something they didn’t want.
When I created the Product Owner role, I gave it more responsibility for product strategy and revenue generation than a Product Manager.” — Jeff Sutherland.
The Scrum movement was accelerated after 2001 when seventeen software leaders met up at a ski lodge in Utah and created the Agile Manifesto.
As a result, a new misconception of the two roles came to exist. Former PMs complaint about the POs and vice-versa. As I grew through this movement and learned with my peers, what I saw happening that the PO role became nothing more than a glorified order taker. The whole ownership concept, mini-CEO, is nothing more than colossal bullshit.
The PM role becomes a false idea of a strategic thinker of the product, but at the end of the day, none of the two roles takes on the most important responsibility of representing the user’s voice in the business.
Several companies started to understand that something needed to change to adapt. One relative well-documented change I read came from Thaisa at Spotify:
Spotify is a 100%-Agile company that started with the Scrum framework, but as their teams were growing, they noticed some things on the Scrum framework that weren’t working well for them. So, they decided to break some Scrum roles, artifacts, and events. These things were getting in the way, so they made the Scrum roles, artifacts, and events optional. — Thaisa Fernandes
What PMs think about PM’ing
So, let’s get to the essential exercise of research and ask other PMs what it really means to be a PM.
I reached out to my peers with more than 8 years of experience and just asked. First of all, thanks for your help, secondly I was a bit shocked by a few of the answers:
“It is a fucking lonely job. The team is always cross-functional. It is exaggeratedly glorified as a mini-CEO of the product, etc. The reality, it involves a lot of negotiation and convincing people across the company. If you don’t have the patience to navigate people with different points of view, this is not a path for you.” PM at a Big-tech company.
“Everyone knows the title, but nobody really understands what it is supposed to bring to the table. There is a lot of ambiguity that changes with each organization and at different stages within the same organization. It’s exhausting saying no every day. I become a noxious beast where I pass more time saying no to ideas all week long.” PO at a Big-tech company.
“You will find plenty of PMs complain that they are expected to be mini-CEOs but feel helpless and lacking autonomy on the decision-making process of their product. Companies and Founders should only expect their PMs to take ownership to the extent that they are willing to empower their product teams to make decisions. Otherwise, PMs are just glorified document makers,” PM at Growing Startup.
“I love it because PMing is an evolving role. Certainly not along the path of a ‘mini-CEO.’” VP of Product, Big-tech.
So, what does the future look like?
I will probably get a lot of backlash for that statement and what I’m about to say next, but:
Let’s first kill the two titles; they are not helping. A PM doesn’t want to be called a PO, and a PO desires more power than the title. So, what is the point of keeping them? Just laziness of HR and ego from PMs and POs.
Why does a company need this role? Shit, wrong. Let me rephrase it, what do all the stakeholders of a product need help with? Assuming that the technical part is covered by engineers, what they are missing:
Someone to identify the problem (pain) by interacting with users and other stakeholders.
Translating users’ pains into business, marketing, and product issue.
Provide context with adequate communication of the problem(s) to engineers, marketers, finance, and support so they can build the appropriate solution.
Keep problems, findings, decisions, and solutions documented.
Stakeholder management and async communication.
Focus on input and output metrics.
Designs experiments.
Will the brief description of the role solve the problem? As a result? Hope so. But is the position responsible for the solution? No way. The team is responsible for the solution.
So, we can call the role whatever you want, PM, PO, PS, etc… But be sure to understand, accept and communicate that the role’s nature is fluid — what you do doesn’t change, but how you do it definitely changes. And why? Different problems, different approaches, sometimes different teams, and for sure other stakeholders.
I do believe we will see the PM/PO role die pretty soon; the items I described above can be run by any team member at any given time. That means the PO role in Scrum can be taken by an engineer, or a designer, or… at any time, or by the problem to be solved, for example. The critical point of this, and several companies have already started to understand, is that the missing link is not the role but the passion for the problem and not the solution.
PMs will become engineers, designers, marketers, and any other role will have in your company; what you need is to empower people to fall in love for a problem to be solved.
If you are a PM, you should start to consider expanding your knowledge to:
Data analysis.
Data science.
UX/UI.
Product Marketing.
Engineering.
Project Management.
I am not trying to be pessimistic with this article, mainly because I’m a PM. I believe our role is in transition, and we need to be the first to see and raise our voices with solutions. I don’t want to wait to be rolled over by in just a couple of years.
Remember, what used to be footnotes are now vital.