Being a product manager is a challenging position. You have to deal with market unknowns, technology challenges, dozens of stakeholders, and limitations, all on a daily basis. But before all that, you have to deal with one additional hurdle: overall confusion over who a product manager and product owner is and the most optimal set of responsibilities for each role.
It’s not uncommon to apply to a product manager or a product owner position and end up doing a little more than project management work under a different title. I’ve covered this confusion and the dangers it poses multiple times throughout my career.
Recently, however, a similar topic got even more spotlight when Marty Cagan, product leader and author of the best-selling book Inspired, published his newest article on product management trends for 2024. When discussing the future of product owners in 2024, he said:
“This topic is just so frustrating at this point. The rise of product owners has done more damage to the craft of product than anything else I can think of in the past 40 years.”
So, should the role of a produce owner be sunsetted? What do PMs think about this? Keep reading to find out more.
To get you up to speed, let me quote the author word for word:
“This topic is just so frustrating at this point. The rise of product owners has done more damage to the craft of product than anything else I can think of in the past 40 years.
The root of the issue is that we have literally thousands of well-intentioned but process-focused “agile coaches” that have never done product at a product company, thinking they can train product owners. They adopt some buzzwords, teach people a specific delivery process like scrum, give people a certificate, and send them out to serve as “the product owner of a product team.” Funny how they don’t pretend they can train engineers how to code, or designers how to design, yet they are fine pretending they can train product owners how to ensure they are delivering value and viability.
So I am very much hoping that we can just acknowledge this was a very big mistake, and move past this sad chapter.
Unfortunately, what’s driven this situation in the first place is process people taking over agile, and that shows no sign of slowing down, so my worry is that this will get worse before it gets better.”
This is an interesting take on the topic and one I don’t think I fully agree with. Let me, however, build a common understanding before I share what I think.
To understand the two roles, let’s turn our attention to the Scrum Guide.
A product owner is a role on an agile development team that is responsible for maximizing the value of the products that the team builds. The product owner manages the product backlog, prioritizes the features, communicates with the stakeholders, and ensures that the team delivers solutions that meet the customer and business needs. The product owner role was created as part of the scrum framework, but it can also be applied to other agile methodologies.
Quick side note — with this definition, there should be no difference between a product manager and a product owner, but how those two differ in real life is material for a completely different article.
There is no such role as an “agile coach” in official scrum resources. However, in my experience, this role is simply a relabeled, senior version of a scrum master or a scrum master of scrum masters. If we follow this logic, then we can define an agile coach in the following way:
An agile coach is a person who helps an agile development team or an organization adopt and improve agile practices and principles. The agile coach mentors, guides, facilitates, and teaches the team or the organization how to work effectively in an agile environment, how to overcome challenges and impediments, and how to continuously learn and improve. The agile coach role is not defined by the scrum framework, but it is often used to support the implementation and scaling of scrum and other agile methodologies.
So far, so good and clear. So, where is the problem?
Ok, so in theory, agile coaches should actually help product owners rather than jeopardize their work. Marty has, obviously, way more experience than I do and has worked with many more partners and organizations. I do trust his words. That being said, it doesn’t align with my experience.
When I started my product owner position, I came from a startup background where everyone did everything possible to achieve success. Job titles were made up and we just helped each other as much as we could. I could have been called a product manager, but I was actually also a project manager, quality assurance engineer, and client support rep who occasionally did some coding. The bottom line here is that I was working day in and day out to create software end to end with the help of the developers.
Naturally, when I joined a bigger company, I started doing what I knew best — being next to the development process, breathing into my team’s necks, fixing their roadblocks, and doing much more than was expected of me. Thus, my long-term strategic work was non-existent and I was almost literally running sprint to sprint, becoming more and more burned out with every release.
This all changed when an agile coach started observing me and flagging my anti-patterns. I was a product owner who wasn’t being a good product owner. At first, I resisted and didn’t take well to the critique of my work. However, being challenged a few times to follow his advice and see what happens, I slowly saw his way.
My developers were bright chaps who started growing and positively surprised me when there was no Bart around to hold their hands, but the sprint goals still had to be made. There were a few more tweaks I’ve done to how I operated based on the agile coach’s point of view and frankly, I wouldn’t be here writing those words if it wasn’t for him.
However, my personal story highlights one difference between what happened to me and what he sees as the problem: my agile coach taught me how a product owner should fit into an agile team and not in product management.
He didn’t instruct me on how to prioritize the backlog, find the right initiatives to pursue, or interpret the results of my product tests. None of that. He did what an agile coach/scrum master was meant for in the Scrum Guide and that worked like a charm.
As a product management instructor myself, I can’t see myself teaching the topic without having many years in the field and clear achievements to showcase. I often say that it would be hard for me to carry on as a teacher and content creator if I didn’t have my day job as a PM to inspire me.
Marty is talking about the rough truth — that people with little experience become those senior agile coaches and provide advice that has no grounds in their experience, nor do they have any success in supporting their authority. However, agile scrum certificates, or any product management certificates for that matter, are useless when it comes to being seen as a great candidate. Therefore, we are witnessing a plague of unqualified people teaching others how to be a product owner, then this should be a problem of wasted money for meaningless training.
Perhaps, in some regions of the world that I am not aware of or in pre-pandemic times I don’t remember, the certificate was enough to put your foot in the door, but I know for a fact this is not the case in European companies. Even for entry-level, junior product positions, one needs to present some product experience, as the certificate area of the resume will often be ignored by recruiters.
To summarize, if unqualified people are put in a position they have no business to be in, this is a clear anti-pattern that can lead to poor product work. That being said, I do not understand how this could be the case. In all the companies I know, no one would bat an eye on a resume for a product manager/product owner/agile coach if that document didn’t scream, “I have experience and I have evidence I am great at what I do.”
Where does this leave product owners, then? What will this poor training regime do to the role overall?
Unfortunately, I don’t have any good news here. In my humble opinion, nothing will change and product managers and product owners will remain as they are for a simple reason: it’s not scrum.org or some product community that defines how we work, but the companies we work for. If some company tolerates the poor performance of a product person or chooses to make them a project manager under a different job title, there is no external condition that could affect that, just like the Bar Association for lawyers.
All that can be done is to sort of self-regulate. Have experienced senior product people recruit only those who are truly well-equipped to carry out the product duties optimally. Those younger product people also need to invest in their training, not for any certificate, but to actually improve their craft and create great products for the future. At least this is what I try to add to the product community as a product educator and this is what I hope to pass on to the people who will follow my lead.
Reading into Marty’s words, it looks like in his experience the world of agile coaches is filled with Gilderoy Lockharts, and, if that is the case, that needs to stop. The product owner role is suffering because these individuals are being trained by inexperienced coaches. On the other hand, I believe that weaving a scrum master/agile coach role into a core agile scrum framework happened for a reason and, when done right, can help any team and individual excel at their jobs! I know it did that for me. The product owner role isn’t going away anytime soon, but there is a lot of work to do on how product owners learn their craft.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Should PMs iterate or reinvent? Learn when small updates work, when bold change is needed, and how Slack and Adobe chose the right path.
AI accuracy problems are often chunking problems. Learn how chunk size and structure impact cost, retrieval quality, and UX.
April Dunford, bestselling author of Obviously Awesome and one of the most trusted voices in product positioning, explains how to expose weak AI claims and anchor differentiation that wins deals.
See how PMs replace dashboards with AI powered Slack workflows to surface real time insights, automate execution, and reduce cognitive load.
Learn more →
One Reply to "Is the product owner role doomed?"
From what i have learnt in my work experience and obviously I am a Certified Scrum Product Owner (not an uncertified person writing), I have couple of observations
1. Scrum master or product owner both don’t train the team for agile.
2. Neither Scrum master or agile coach will every tell you or train you how to be a better product owner (PO)..You (PO) are the quality gate for sprint outcomes. And PO is responsible to check how can he be a better PO !! ..
3. Agile or Scrum are just for guidance in how to ensure larger teams stay in sync with customers, management and with each other for a product delivery.
Product teams can adopt to hybrid agile processes aiming to better the velocity and quality of their team increment !!
4. If you have a better process with which you managed teams earlier , this article would have been more effective had you shared it with us.
Absence of insights about how your process was better than the one proposed by agile coach only makes this article occur like a cry baby over few developers not wanting to grow beyond their daily tasks. Next time hope you cover all aspect of why do you think product owner role is either redundant or compromised and come up with a solution that you think is better.
Cheers.