ZerotoHero
Published in

ZerotoHero

Your PM role will be dead by 2030

Please don’t freak out…not yet!

Let’s start from the beginning; why the Product Manager (PM) role was created? Before I get a start, I kindly ask for agilizas out there: Open your heart, 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 in a time where we still used to package and ship software physically. Aiming at fixing dysfunctional organizational and making developers’ lives better, a group of great engineers comes 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 though-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 have seen happing is the PO role became nothing more than a glorified order taker. The whole ownership concept, mini-CEO, is nothing more than colossal bullshit.

And the PM role becomes a false idea of a strategic thinker of the product, but by the end of the day, none of the two roles are taking the most important responsibility to represent the user’s voice in the business.

Several companies started to understand that something needs 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 just ask around to other PMs; what really is being 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 with 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 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 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 it’s the future looks 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 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:

  1. Someone to identify the problem (pain) by interacting with users and other stakeholders.
  2. Translating users’ pains into business, marketing, and product issue.
  3. Provide context with adequate communication of the problem(s) to engineers, marketers, finance, and support so they can build the appropriate solution.
  4. Keep problem, findings, decisions, and solutions documented.
  5. Stakeholder management and async communication.
  6. Focus on input and output metrics.
  7. 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 a pessimist with this article, mainly because I’m a PM, and 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.

--

--

--

Recommended from Medium

Analytics Engineering at Spotify

PROJECT MANAGERS IN SCRUM

Creating Strategic Impact for Leadership Through Multidisciplinary Research

Types of Product

The lessons I learned in my first two months as a product manager

The Full Loop Analytics Framework

5 signs you should go Scrumban, rather than Scrum or Kanban

Scrumban or bad agile practice of Scrum and Kanban?

Product Management is about Purpose, People and Progress

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Taric Andrade

Taric Andrade

Entrepreneurial minded, passionate for tech, driven by intellectual curiosity — curating knowledge to solve problems and create change.

More from Medium

Identifying Empowered Product Teams

SS*: Going live with digital product FAST

How the Leadership Team can be a Driving Force Behind Product Culture Failure

Defining teams for a product development organization