Visualizing Product Management Roles and AI-related Operations Gaps

There has always been lively debate about how to define the role of Product Manager. In one early meeting of the Silicon Valley Product Management association, this was the topic of a presentation. How do we describe our job? Is it a development or business function, or both? The slide deck showed a universal translator from Star Trek, and everyone was looking around to see who got the reference and who didn't.

Ever since I heard the terms "inbound" and "outbound" to describe technology-facing versus market-facing Product Management, I have thought of it as a left-right split. The focus areas listed here are just examples, not meant to be fully representative.

I also think of Product Management in a vertical sense, because the core Product Management output is a top-down backlog from Portfolio Themes to User Stories. There are differing tales about whether the term "Product Owner" was accidentally or deliberately created to be separate from the role of Product Manager. The general understanding now is that Product Managers are more senior and focused on long-term strategy, while Product Owners are the main point-of-contact between delivery teams and business stakeholders on a daily basis. If you have to draw a line, from a planning and backlog management perspective, it is usually drawn somewhere around Feature-level concerns.

Where PMs and POs Operate — and Where They Don't

A Product Owner can have a totally appropriate sense of where they operate, then transition to a different area with equal effectiveness. Inbound versus Outbound orientation is partially due to background, whether they come from the technical side or more of a business stakeholder role. It is not discussed enough that the product lifecycle draws focus one way or the other depending on the maturity of the technology. If the goal is potential niche revenue from new technology, the focus is mainly inbound. Enhancing solutions and scaling is mainly outbound. Maintaining service while cutting costs swings back to mainly inbound.

I like using the quadrant diagram below with anyone in the Product Management job family, to help visualize where they are, how much scope they cover, where they think they should be covering, and where they might look to strengthen their partnerships.

This is for illustration purposes. I left the Product Manager out of this example because it would have been too distracting. I think it is a fair example of how things could be working in an average Product Org these days. I use these quadrants, with a blank slate and sticky notes, as a conversation starter with people in the PM job family. This leads into more detail about what is in the bubbles, and the borders of responsibilities.

• Does the Product Owner do daily release sign-off?
• Does the Sr. Product Manager own or co-own milestones on a technical roadmap, and is it clearly aligned with the business roadmap?
• Do the PO and PM have the context and feedback loops that they need, horizontally, to fulfill their technical and non-technical areas of responsibility?
• Do the PO and PM have the context and feedback loops that they need, vertically, for alignment and transparency of short and long-term goals?
• Where does AI call for accelerated coordination, from idea to production, to keep up with AI-accelerated prototyping and development?

The Two Gaps AI Makes Urgent

Whether or not these example bubbles represent the situation at your company, there is a common pattern. The Product Management job family tends to run in a line from the upper right to a bit left of center at the bottom. There are two obvious gaps in coverage, in the corners of the quadrant.

Regarding the bottom right, toward weekly or daily customer recognition of incremental value: how frequently do your Scrum and Kanban teams demo new customer-facing functionality and get direct feedback? A typical two-week sprint is starting to seem like slow turnaround.

For the upper left, toward technical strategy: are Architecture, Sales, Marketing, Security and Product all aligned on the benefits of a continuous deployment pipeline, with frequent release-on-demand? DevOps may be a big topic on the architecture and engineering side at your company, but does everyone understand that a DevOps transformation culminates in non-technical people performing low-effort, low-risk product releases? Sales and Marketing should be clamoring for business-driven push-button releases and expedited customer feedback loops. Most Sales and Marketing people do not know about the business relationship to DevOps. The urgency is rising, and organizations should be getting on board with DevOps and Kanban if they are getting on board with AI.

What Product Operations Needs to Do Now

In order to fully leverage AI-native Product Management and software delivery operations, the technical and customer-facing gaps need to be addressed. As AI accelerates development, organizations must evolve to accelerate prototype feedback, continuous deployment, frequent release on demand, and rapid value recognition.

Geoffrey Moore, known for Crossing the Chasm, recently wrote about making way for a new model of Customer Success and proposed the idea of Use Case Teams (UTCs). I highly recommend the read for anyone thinking through how the customer-facing gap gets closed.

Scrum and Agile were designed to leverage the rapid delivery and feedback that was made possible by extreme programming. Product Management had to become Agile, and business agility lagged behind technical agility for years. This lag could happen again with AI. Product Operations should evolve quickly. Kanban boards can scale out to include more upstream architecture enablement, and more downstream release activities. Engineering-Product sync meetings will need to be streamlined, with recurring cadences and supporting assets like metrics and virtual collaboration tools. Key stakeholders will need to be more available for responding to rapid prototyping.