If you have strategy, product, program, project, design, research, analyst, or analytics in your title in any form and you work on software products, then your job is likely to change, or even be eliminated by AI in the near future.
Welcome to the first of three articles on the topic of whether AI can replace Product Managers. In these three articles, I will be exploring how much of the product management role can be replaced or augmented by AI. I am not exploring how products can themselves be enhanced by AI. While I could do that and share all my wonderful ideas on that topic, I would need you to sign an NDA before that would happen.
In this article, we will first explore the redundancies that often exist in organizations which leads people to make the argument that a lot of product management “could” be eliminated. Then, we will look at which roles could be eliminated with AI regardless of redundancy. We can’t start talking about this if we don’t understand what roles exist within the Product Management space, and where the overlap with other departments might be. So, let’s spend a little time on the business of building, launching, and growing products (specifically products with a healthy amount of software). Seasoned Product Managers may be tempted to skip this section, but I urge you to keep reading. I may define some of these things slightly different than you do.
*A side note on Agile: If you know me or read any of my other articles, you know that I am a strong believer in agile-organizations. This means I think all aspects of a company can migrate to an agile and an iterative approach to most things, achieving much greater success than traditional methods of operating. That said, every company is on its own path to adopting agile practices. Most have limited agile to their software development lifecycle. Some have expanded it to their go-to-market activities. A small few have extended it to their entire product lifecycle. This series of articles is mostly agnostic on the agile vs. traditional argument. Regardless of how agile your company is, AI will impact the same roles and responsibilities. I might even argue that AI will take over more roles at a traditional company than they would at an agile one, especially if you work on a feature team (more on that later).
Foundation Part One – The product lifecycle and common redundancies
All products follow the same product lifecycle: Concept, Discovery, Launch, Growth, Maintenance, and Death:
- Concept & Ideation (Market Research) – Once the concept is proven via market research then companies are founded or money allocated to a team to define or discover what the product should do. All products start with a concept. Some start with a technical concept, some start with an identified problem to solve (I will save arguing over which is better for a different article). This is typically owned by people who are more on the “business” side of building products.
- Discovery (Product Research) – The team has their mission: “Build a product that solves this problem”, or “Figure out which problem this product best solves”. The team does research with users/customers on the product idea and tests the market to figure out what to build or how to finalize, package, and launch what was already built.
- Build & Launch (Product Development) – This is where the execution occurs with all of your R&D and initial launch activities. The initial launch includes delivering the functional product (shipping it), and all the activities and collateral to bring the product to market. This includes internal collateral creation, training, external communication and related marketing activities.
- Go to Market and Growth (Growth) – Some people might bundle these with the “Launch” component of Product Development. However, the focus shifts externally, which also typically changes who does the work. This includes lead gen, building and executing on the sales pipeline and implementing new customers. This also includes product changes and enhancements to react to feedback from users, the market, and product data and metrics.
- Maintenance and Death – In general, the active amount of Product Management work on products in these phases drops off rather quickly. Product Managers tend to be working on next generation versions of these products and are only engaged to ensure they do not repeat problems of the past. Therefore, these two phases are not relevant to this series of articles, and we won’t be exploring them any further.
Within these phases you have different roles, skills, and titles of people that can own them or contribute to them. Below is a shortened list of the above phases by who tends to work on them:
- Market and Product Research – You typically have people with variations of strategy, analyst, analytics, or research in their title working on these phases. They can exist at all layers of the company (from the CEO down to an entry level position). For example: You may have somebody as a VP of Corporate Development who initiates research in the market with some analysts on their team. If their market research shows promise then they engage with their peers in either Design or Product (depending on who owns user research) to start the product research activities.
- Product Development and Growth – People with titles containing these terms are all here: Product Manager, Product Owner, Program Manager, Project Manager, Scrum Master, Analyst, Designer, Researcher, Product Marketer, Business & Product Intelligence and Analytics.
I purposely made the above list of roles regarding product phases vague. As mentioned in my intro to this series, most companies don’t really plan their organization structure. It tends to happen organically based upon strengths and weakness within the team. This organic approach is how you up with responsibilities in “odd” places (like strategy being owned by Customer Success) and how you end up with redundancy when the company matures. At some point you start hiring leaders of departments that are used to owning certain responsibilities, and they end up duplicating the work. I call this true redundancy. This is where you have two departments responsible for the same thing (whether the company recognizes it or not). This results in a good game of “who calls the ball?”, or for comic book nerds this problem:
The second type of redundancy is where it appears by title that two departments do the same thing, but in reality they are different. I call this a false redundancy. For example, analysts exist in almost every department. A market analyst may reside in a corporate strategy team. They produce market data that is used by the company at large for overall business decision making. A product analyst may reside within the product team. They are also looking at market data, but with a focus less on overall business and more on products and competitors. There is overlap between these roles for sure. However, the audience for the output of their work is where the difference lies, and the details that matter to the different audiences drives the need for both roles.
In a theoretical world you can identify the overlap in both cases. In a false redundancy, you share all data researched between both teams of people and reduce the size of each team accordingly. In a true redundancy, you just reorganize the company. This is the utopia that many authors and pundits often allude to when they say that product managers are redundant with other departments and can be eliminated. For most companies achieving this utopia has been close to impossible. The cost and disruption to hire enough management consultants (or Bobs) to clearly identify all the true vs. false redundancies and reorganize the company almost always exceeds the actual savings.
There is, however, a very common type of true redundancy that has emerged more recently that is fairly easy to eliminate manually and even easier to automate away with AI. This is when your Product Team operates like a Feature Team. While covering the entire concept of Product Teams vs. Feature Teams is outside the scope of this series, you need at least a passing knowledge of what it is to understand why I say that Feature Teams have the biggest risk of being eliminated by AI.
As far as I know, the concept of feature teams was coined by Marty Cagan at Silicon Valley Product Group a few years back. He has written about them and his concept of empowered teams extensively. Here is a good starting point: https://www.svpg.com/product-vs-feature-teams/. Here are a few things that are common in companies with Feature Teams:
- Product strategy and feature decisions are made outside of product management. This typically means there is a team that operates as Corporate and/or Product Strategy. This may be an actual Strategy team with a Chief Strategy Officer, a Corporate Development team, a General Manager structure, or just a mix of the leaders from Sales, Marketing, and the Senior Leadership team (AKA “The Business”).
- The Engineering teams own most internal Product Development activities. This is where you tend to see a full team that includes Program Managers, Product Owners, Project Managers, and Scrum Masters who are all part of the engineering team and the Product team is outside of it.
- Access to customers/users is managed by a separate team. This is often more than just “managed” and more like owned and closely protected/guarded. This may be Sales, Customer Success, or a dedicated Design team. Either way, they talk to the customers and the Product teams (and others) do not.
Here is a short breakdown of what a feature team looks like vs. a product team:
Here’s the hard truth. If you find yourself working as a product manager in a company with feature teams, your role is likely redundant with other departments and ripe for being replaced with AI. If you have been trained according to modern product management philosophy, you may be in the process of transforming your company to be “product oriented” and move away from feature teams. However, in lieu of that transition fully completing, you are likely only handling execution and coordination activities, which are better defined as pure program or project management. Your role is the most common target when people say that “Product Management” can be eliminated by removing redundancy and adding AI. I will elaborate on this a bit in the second half of this article, and in the next article (I, Robot) where I explain what AI can do.
This establishes our foundation for the first part of the problem highlighted by others. It is true, there can be both true and false redundancies with necessary and unnecessary overlap in responsibilities. This can exist most dramatically in companies that grew without an organizational plan. There can also be significant overlap between teams in the normal process of bringing products to market regardless of how agile, product focused, or how technically advanced your product and organization may be.
*Side note: I keep putting “The Business” in quotes because I often hear people within feature team companies refer to those that make product decisions as “The Business”. You may be meeting with the engineers to discuss features and somebody might ask “has The Business finalized these requirements?”. In this sense “The Business” is referred to within the company and as a proper noun as if you were referring to a person’s role or title or name, even though it represents an amorphous amalgamation of senior leaders that happen have their hands on the levers of power. If you are a Product Manager working on a Product Team, you are “The Business” or at least part of it. If you find yourself at a company where “The Business” is invoked then you are likely part of a Feature Team. I will add this concept to the list of interesting things to write about in the future.
Foundation Part Two – Who’s at risk (what can AI take over)?
As stated in the beginning of this article, anybody with strategy, product, program, project, design, research, analyst, or analytics in their title are at risk. In part one, we explored the product lifecycle and identified the roles that contribute to each phase. In this part of the article we will look at what AI can actually take over, and why those roles are at risk.
The first group of people at risk are what I will call “information managers”. Regardless of your title or department, if your job in any aspect of Product Management is about moving data around, then you are at risk. In thinking about this, I am reminded of the scene from Office Space where the “Bobs” ask Tom “what exactly would you say you do here?” and he replies that he (paraphrased) “takes the requirements from the customers to the engineers” (if you don’t get the reference, then have a look: I have people Skills Office Space). In defending what he does, Tom references a fax or his secretary, which certainly dates the clip. However, look at this recent example from earlier this month on LinkedIn – as you read it, imagine this person being question by a management consultant about how they add value to the company and what they “actually do here”:
Change the names of the apps and say you are moving a raw customer request from your CRM to your development backlog/bug tracking system, updating your project management task system, and refreshing your published product roadmap and this example probably rings true for far too many of you.
This problem exists due to both a lack of organizational design and the complexity involved in operating a business with a lot of people that need to be “kept in the loop”. Each team/department has their own “preferred” tool for tracking all the things. The responsibility for maintaining all those systems falls to a person with Product, Program, Project, or Analyst in their title.
We established above that attempting to actually solve this redundancy manually has been too expensive, ripe for errors, and often does not actually solve the problem. However, with AI, this can be done fairly easily with out significant organizational change.
Let’s look at a few examples in our product lifecycle that are ripe for AI to take over:
- Business Strategy and Market Research is all about finding, distilling, and sharing relevant data. That data is often available freely online, or from industry analyst reports. You pay somebody on a product or strategy team to compile the data into a market assessment.
- Product research is similar, but now you are retrieving data (from product use, surveys, user interviews, prototypes), identifying trends and themes, and compiling it all into a product assessment.
- Managing Product development involves moving and combining data between various systems (as in the above example) and publishing things based upon that data internally and externally.
- GTM activities involve compiling information and producing collateral materials for CS, Marketing, and Sales (release notes, customer notifications and CTA’s, internal pitch materials, etc.). Post launch you are gathering data from multiple sources (marketing systems, product user experience tools, your actual product database monitoring product analytics (user behavior, KPI’s and other metrics) to measure success and to fuel iteration.
Let’s take one of the more extreme examples I have seen of a product request flow for a “simple” feature in an organization with lots of duplication and probably far too many layers of responsibility:
This may seem like overkill. If you count there are ten separate people doing activities in the realm of “product management” without even considering the actual developers, QA, and testing activities. Some of you from smaller startups might be aghast and wonder what all these people do. Some of you at larger companies could be looking at this and saying “you missed a few steps and people”.
Now lets look at that same process with AI:
In the above there are only six people in the flow and, other than the designers, they are not producing anything – they are just reviewing data and making decisions. I am betting that many of you have your BS meter going off right now. As I write this I can hear you saying “there is no way an AI can do all those things!” and “my company would have to change so much for that to happen”. Frankly I am also hearing “I have people skills!”.
Trust me when I tell you that AI can do this today. Does this mean that even the most disorganized companies with lots of redundancies and dysfunction can and will adopt AI to do all of this tomorrow? No, of course not. It does mean that if AI can do it today than the operationalization and commercialization of AI will improve over the next few years making easier and easier for your company to consider it.
If any of the below are true, then it is possible for AI to impact your role in the near future:
- You have strategy, product, program, project, design, research, analyst, or analytics in your title.
- Your company has all of the following departments and they all “touch” product: Business and Product Strategy; Product Management; Design and User Research; Program Management; Project Management.
- If you work in any of the following roles and your company has most of them: Product Manager; Product Owner; SCRUM Master; Program Manager; Project Manager. Side note: Whether some of these roles should exist at all, and more importantly whether they should exist at the same company is a whole series of articles on its own. I may explore this in a different series if you all are interested.
- You are in a different department (like CS, Sales, Marketing, etc) and a bulk of your duties involve moving data about product between systems to keep other people up to date and to enable them to make decisions.
In short, yes there are often redundancies within organizations. Some can be true redundancy that are wasteful, others are either a result of just inefficiency or just the costs associated with keeping each team/department in the loop as things change. While solving true redundancy is seemingly easy, removing the second type has always been difficult, at least until AI makes it possible to change everything.
In the next article (I, Robot) I will show you how AI can do all these things and prove to you that it is real (your BS meter will wind down a little and your Oh S! meter may redline). In the final article (The Last Question) I will walk you through both what I think the role of Product should be, and how I think all of the people who are at risk can best prepare themselves to excel in the role.
Want to learn more? Want to engage directly with me? I offer direct consulting, group and private training and mentoring sessions that deep dive on all these topics. Ping me or go to jaypross.com to find out more.