The Collision of Product Management and Product Ownership

A story of love, hate, oppression and triumph

I’ll admit, I’ve started to fall out of love with agile over the past year or so — don’t get me wrong it’s great, we’re still friends — I wholeheartedly believe that you need to be adaptable to survive today but the further I travel on my own journey the more I wonder if we as an industry are moving past agile. As a result, like many others I too have started to think of myself as more of a “product person” these days — Why?

Much like the seismic activity before a volcano erupting, we often see a number of signals, things that just don’t seem to look right, just before some major shift happens. One signal I’ve been giving much thought too of late is the collision of two roles, Product Management and Product Ownership. A topic of hot debate in the agile and product circles but with very few answers. Many have attempted to define the difference between these two roles (if any) — are they one role, two roles? Are they different, the same but different?? The answer is often unclear.

The agile manifesto turned eighteen this year, the Scrum framework is even older — have they stood the test of time? (now before I get a whole lot of backlash for that statement and what I’m about to say next, I ask those agilists out there to practice what you preach, have an open mind and hear me out.)

Scrum and the agile manifesto were created in a time where we used to still package and ship software physically. The principles which sit behind the manifesto were largely created by engineers and vastly aimed at fixing organisational dysfunction and making their lives better. Scrum came about even earlier than the agile manifesto almost a whole decade to be exact (although you can trace it’s origins earlier back to 1986 with the article The New New Product Development Game). The idea of continuous deployment wasn’t even a thing back then, internet was in its infancy and smart phones weren’t even a concept yet.

Credit: DataKitchen

Since its inception, Scrum and the Product Owner role has become widely adopted. As time progressed many Product Managers wondered if they should be a Product Owner and similarly many Product Owners started to wonder where they fit in relation to their Product Manager counterparts. Confused and loss of a sense of identity, many — including myself — went looking for answers. Numerous conferences later, talking with peers and reading many blogs like this only left me with more questions than answers.

However after some soul searching, I believe the answer lies somewhere between the past, present and future of the two roles — how they came about and have for many reasons, evolved, diverged and collided over the years.

The origins of the Product Manager

Product Management theoretically started back in 1931 after Neil H. McElroy wrote a short memo where he described “Brand Men” who had overall responsibility for the brand and managing a product. Ahead of his time he also described that the best “Brand Men” would do this through experimentation and customer interactions — obviously most people skipped that part!

Later whilst being an adviser at Stanford university Neil H. McElroy influenced two entrepreneurs named, Bill Hewlett and David Packard— names look familiar, anyone? Took the “Brand Men” ideology and put decision making as close to the customer as possible, by doing so they built the empire that we know today as Hewlett-Packard — (did you know Hewlett-Packard at their prime they sustain a 50 year unbroken record of 20% year-on-year growth which is just insane!)

As the name “Brand Men” suggests the origins of Product Management was truely in marketing. Largely contained to that area, Product Managers were focused on product sales through pulling promotions, price, and marketing levers, largely leaving the development of the actual product to others. This divide continued and with the rise of technology and software delivery methodologies such as PRINCE2, many Product Managers became well versed in handing over requirements over the fence to technology teams who would then build to such specifications. Such a divide can still be seen today in many organisations where Product Managers are seen as the ones who “know” the market and customers, and the IT department as the machine which is there to build to their requests.

This worked (arguably) well when products were packaged, physically shipped and changed infrequently but as digitalisation came onto the scene, complexity grew and the need for rapid feedback cycles and experimentation became paramount — this required a new thinking and new way to build products.

Subscribe

Join 'The PBL Newsletter' for regular tips, tools and frameworks on Product, Business and Leadership.

    We won't send you spam. Unsubscribe at any time.

    Enter agile. The rise (fall) of the Product Owner

    Trying to solve the organisational dysfunction of the dived between those building the product and those speaking with customers, Jeff Sutherland and Ken Schwaber proposed a new way to build products — a framework which promotes rapid feedback cycles and adaptation, they created what we know today as Scrum.

    Seeing an ever-growing gap in the traditional Product Manager role Jeff and Ken decided to redefine it. In fact, they decided to broaden the scope of the role by bringing it closer to the team and customers — this was the creation of the Product Owner role.

    “When I created the Product Owner role, I gave it more responsibility for product strategy and revenue generation than a Product Manager. I specifically pulled the best Product Manager Easel Corporation had out of Product Marketing and retrained him. It also has more responsibility for directly working with engineering 50% of the time to assure that the product fits customer needs. So it is a broader role in that sense but usually does not include Product Marketing (sales collateral, shows) or long term Competitive Analysis although it needs to support those efforts.

    The goal was to eliminate the common Product Manager failing of throwing requirements over the wall only to have the customer receive something that they didn’t want.” — Jeff Sutherland

    The Scrum movement was accelerated after 2001 when a group of seventeen software though-leaders met up at a ski lodge in Utah and created the agile manifesto. Since then, the Scrum and more broadly, the agile bandwagon grew exponentially. The rise of the internet, smartphones and all kinds of technical advancements, saw many monolithic empires crumble through disruption — leaving those still standing desperately searching for a way to stay alive.

    As a result thousands of companies all over the world have recognised this need of adaptability and much like a Phoenix rising from the ashes these companies jumped on the agile bandwagon, hired agile coaches, created new c-suite roles such as Chief Digital Officers, Chief Innovation Officers, etc and announced to the world that there are undergoing a “transformation”. However, rarely has these transformations it looked as elegant as a Phoenix rising from the ashes.

    The proliferation of agile transformations resulted in the vast majority of Product Owners today being found in larger more traditional organisations who had undergone this so-called transformation. Unfortunately for the Product Owner role, many of these transformations have either failed or continued with a bastardised version of the roles and Scrum framework. Adopted in name and structure only, the original intent, principles and mindsets were largely left behind. This saw a rise of feature factories — where Product Owners were simply left doing endless product increments for unknown reasons, and far from what was intended. Many simply had their hands tied from the vast number of dependencies, weighed down by organisational complexity and decades of technical debt. When trying to address these issues or — heaven forbid — actually try to be a Product Owner many were met with resistance and their rallies for change were often lost in the ‘fog’ of middle management.

    Not as Jeff and Ken had intended with many companies opting to have both roles

    Something strange also happened as companies adopted Scrum over the years, unlike what I imagine Jeff and Ken expected, the Product Owner role in most cases didn’t replace the Product Manager role, but rather was seen as a different role in itself — a new role which I guess it was — but was never designed to co-exist with a Product Manager counterpart.

    Perhaps its origins in software development didn’t do the Product Owner role any favours in this department — it definitely didn’t do any for agile and Scrum, but that’s a different story. Given that many of these organisations already had traditional Product Management, the misconception that Scrum and agile is for IT only allowed organisations to justify leaving the traditional Product Manager function intact. Ironically, this saw the responsibilities of the Product Owner role in many large organisations to be but a fragment of what Ken and Jeff had originally intended — in many cases, a pawn to the Product Manager whose role remains largely unchanged. The Product Owner in these cases was left to be nothing more than a glorified order taker, another link in a very long chain which divides the customer from those actually building the product.

    Not what was originally intended, unfortunately this has become a common view of the roles today

    The connotations of the Product Owner being an IT-only role narrowed the perception of where the role was could play in the product lifecycle. Take for example, in the early stages of a product you may be defining product-market fit, possibly product strategy or doing market research — all things that are crucial for building successful products but far from IT and definitely something you’d want to nail before even touching a line of code.

    “As a Product Manager your roles and responsibilities will change depending on your context and the stage of your product. Without a Scrum team or with a smaller team, you might be doing more strategy and validation work with problem discovery in a product that has not been defined yet. With a Scrum team, you may be more focused on the execution of solutions. As a manager of Product Managers, you might be leading strategy for a larger part of the product and coaching your teams to discover and execute well.” — Melissa Perri

    One could argue that there is no reason why a Scrum team couldn’t be building a product strategy or doing research work (and I 100% agree and have in fact done exactly that on many occasions) but often this notion is quickly discarded because of the connotation that agile and Scrum are for software only — “no way a Scrum team could be doing that!”. The agile-gurus of you out there would argue that they just misinterpreted what agile is — and as much as I agree with you I also wonder how true that really is? One only needs to take a glance at the agile manifesto’s twelve principles to see the words “software” and “developers” all over the place! It’s even harder to argue whether building a product strategy or doing research aligns to the principle of “Working software is the primary measure of progress”…

    Unfortunately agile’s own family didn’t do it any favours either. The Scaled Agile Framework (SAFe) encourages this misconception of dividing the role into a strategic Product Manager role and a tactical Product Owner role. SAFe describe the Product Manager as the outwards customer facing role of the two — the one who speaks to customers, sets the product vision and direction. Leaving the Product Owner to be the inwards facing role — the one who works with developers day-to-day, stuck in the solution space, far away from the customer — nothing more than the “floor manager” of Feature Factory inc.

    Product Manager and Product Owner roles as defined in SAFe. In my opinion creating a divided like this between the customer and those building the product is never a good idea.

    SAFe’s definition has an uncanny resemblance to the traditional Product Manager role and is perhaps a reason why many organisations look at SAFe favourable — because they don’t need to actually change or address existing dysfunctions. Ironically 20 years later this leaves Jeff’s and Ken’s attempt to solve an organisational problem by broadening the Product Manager role to have done the exact opposite.

    The evolution of Product Management

    Don’t get me wrong many traditional companies, even still today, benefit from adopting the agile mindset and Scrum framework however something I’ve found extremely profound is that if you look at startups and product leading companies today — particularly ones which didn’t exist too long ago, not many of them felt the need to adopt frameworks like Scrum — take a look at Amazon, Spotify, Atlassian, etc none of them have Scrum Masters today — perhaps unburdened by layers of middle management, traditional management methodologies and old delivery practices, these companies had the opportunity to define their culture, structure and people from scratch.

    “Today (at Atlassian), many agile teams combine practices from a few different frameworks, spiced up with practices unique to the team. Some call this heresy. We call it practical. It’s not about “Agile” — it’s about agility.” — Atlassian on agile

    In fact much like AtlassianSpotify started with Scrum and over time evolved out of it as Thaisa Fernandes⚡explains:

    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. According to the video, these things were getting in the way, so they decided to make the Scrum roles, artifacts, and events optional. — Thaisa Fernandes

    No Scrum Masters, no strict agile frameworks where does that leave Product? Interestingly, all of them have Product Managers, yes they use the title Product Managers, not Product Owners, but unlike many of the large organisations I described earlier they only have the one product role — not both.

    Like businesses all over the world, Product Management was not clear from digital disruption either. In the absent of frameworks and buzz words it evolved on its own. Even more fascinating is how much it evolved to be what the Product Owner role was intended to be — if anything it’s become broader.

    The Product Manager was moved from being a marketing-centric role to being product-centric one — this meant getting involved in the day-to-day delivery of the product. Now spread across the whole product lifecycle these product-centric companies supported these newly formed superheroes but creating a vertically aligned structure that surrounded products. This meant that marketing, sales, developers, legal, etc all worked closely day-to-day. The Product Manager in these cases became less of a manager and more of a leader — someone who helped bring it all together and aligned under one vision. As companies adopted techniques such as lean, design thinking and (yes even) agile, so too did Product Management — design thinking, lean and agile have all become the default way to discover, build and ship products and are all now considered to be a Product Manager’s bread-and-butter.

    GA Product Management course curriculum — although I wouldn’t use the words “Project Management” knowing agile is a core part of being a Product Manager today

    One only has to look at the General Assembly’s Product Management course to see how far the role has come. Given that the course alone is either 10 weeks part time or 5 days full time you can see how broad the role has become — that’s a long course!

    Although the general consensus is that Product Manager and Product Owner roles are in fact the same, the market has gravitated towards the title of Product Manager more. Perhaps simply because it didn’t carry with it the baggage of the Scrum framework. Maybe the true irony is that the Product Owner role didn’t exactly nail its own product-market fit — brought down by the connotation that the Product Owner role and Scrum were are a package deal. (before anyone rebuttals me on this one, I know that Scrum, as we know it today, is an agnostic framework however it was originally described as a “way to develop software” and even today there is the perception that Scrum is a prerequisite to adopting the role). 

    Melissa Perri put such a sentiment well:

    “if you take Scrum away as a process for your organization, you are still a Product Manager. Product Management and Scrum work together well, but Product Management is not dependent on Scrum. It can and should exist with any framework or process.” — Melissa Perri

    Perhaps at the end of it all, the Product Manger title has managed to disrupt its disruptor — it has evolved more rapidly and in many cases is perceived to have overtaken the Product Owner role. Perhaps today the Product Manager title stands the victor.

    “Product Owner is a role you play on a Scrum team. Product Manager is the job.” — Melissa Perri

    The collision of Product Management and Product Ownership, colliding into the Scrum Master 🤔

    The Product Owner role originally had so much responsibility that Jeff thought it would be too much for one person and as such decided to split the role in two — this was the birth of the Scrum Master role.

    “It was also to replicate the Chief Engineer role at Toyota which requires much more responsibility than a Product Manager. So much, that I split the role by giving the Scrum Master responsibility for the team.” — Jeff Sutherland

    The Scrum Master, although originally created as the enforcer and manager of the Scrum framework, the role has made leaps and bounds since then. As we know it today it has very much become a leadership role — servant leadership one to be exact — a role which is focused on people and process leadership. Great Scrum Masters coach and help bring the best out of people by creating environments where teams do amazing work — great Scrum Masters ultimately look to build more leaders and create a self-sufficient team — in turn they actively work towards making themselves redundant.

    Agile expertise aside this leadership style of coaching and cultivating culture does not need to be defined to a particular role, nor do I think it should be. If anything it is the role of everyone in the organisation — particularly those in a “leadership” position, or better put a position of influence. Perhaps Jeff and Ken saw another dysfunction in organisations, a lack of strong leadership — I know from my own experience at traditional organisations out there, they have plenty of managers — the floors are littered with them — but very few have leaders, true leaders.

    It would seem that something that was once divided into two roles is now converging back into one role. This is important to note because as the Product Manager role today evolves into one which is about coaching and leadership, where does that leave roles like the Scrum Master? In fact Brandon Chu used a very befitting analogy to describe the Product Management role today as being comparable to a sports team coach — one where the Product Manager is a leader, a coach to the team and definitely not their manager. Consequently I often wonder if the term Product Manager is still a befitting title — manage what exactly? From my observation, and many others like Brandon, the role has evolved into a leadership role — I therefore wonder if the term “Product Leadership” could be a more accurate term for the role today (in fact at a previous company we had toyed with the title “Product Lead”). No longer are we managing a product but rather we are leaders, we provide leadership to the product and to the product team.

    If you look at Silicon Valley Product Group’s coaching assessment for developing Product Managers they break the role down into three pillars, Product, People and Process. These three pillars have a stark resemblance to the two Scrum roles — Product Owner and Scrum Master. Where the Product Owner focused on the Product pillar, the Scrum Master is focused on People and Process ones. Ironically Jeff and Ken had removed the People and Process pillars from the Product Owner role because they thought it was too much for one person, but with many Product Managers today doing all three it begs the question of whether or not they were right with that assumption. Many companies as stated before like Atlassian, Spotify, etc have indeed shown this to be possible and are examples of companies that have outgrown the Scrum framework. Perhaps roles like the Scrum Master had simply served its purpose and made itself redundant or perhaps after 20 years we may be simply outgrowing Scrum.

    Product Management and Product Ownership are indeed one-in-the-same but as the market gravitates towards using Product Manager title as standard practice it might well one day soon cast a shadow over other any other titles for the role. The rise of roles such as the Chief Product Officer, shows a continual evolution and importance of the role — such importance that it made me wonder why we had not seen that kind of evolution for agile roles like Scrum Master and Agile Coach — no one has decided to hire a Chief Agility Officer (perhaps they should?) or maybe the issue of leadership and building an environment with the right conditions for high performing teams is now being resolved elsewhere but product leadership still remains paramount.

    Product Owner and Product Manager although considered to be the same thing, the market has shown a preference to the title Product Manager

    Footnotes — just to clarify some potential assumptions :)

    • Product Owner = Product Manager, they are the same thing but as market perception grows they are in many ways drifting apart. Much like the dictionary definition of words, their meaning and connotation have shifted over time.

    • By no means am I suggesting that we change the title of Product Manager to Product Lead or any other variation — I hope that the Product Owner story that I have illustrated paints a picture on how that could be a potentially bad idea.

    • Please don’t take any of this as a suggestion that your company no longer needs Scrum Masters or the Scrum framework, rather the contrary — if you still are vastly a traditional organisation, not structured with vertical alignment to your products and/or are lacking strong leadership, you will indeed benefit from using Scrum. In these environments you cannot put a price on the value of hiring great Scrum Masters who can be catalysts for change and help you work towards being a product centric company as it was intended to do.

    • The future of Product Management as a leadership role is one that I think can only succeed in a company that has strong leadership and a taxonomy which is product centric. Without these I believe Jeff and Ken were right in saying that the role is too large for one person — I see this daily in many traditional organisations, struggling Product Owners/Managers in an environment which has simply not set them up for success.

    References

    Subscribe

    Join 'The PBL Newsletter' for regular tips, tools and frameworks on Product, Business and Leadership.

      We won't send you spam. Unsubscribe at any time.

      Previous
      Previous

      How to Master Yourself and Win at Receiving Feedback

      Next
      Next

      Feedback vs Advice — Tips on giving effective feedback