.png)
Here we go. The world is once again imposing an identity crisis on Product Management.
This time it has been triggered by (a) remarkable leaps in the accessibility and usability of LLMs and AI-based “building” tools, and (b) a proliferation of amazing AI-first features and products that have created a haze that makes it look like everything and anything is or eventually will be an AI product.
For now I'll focus on (a), as it will speak to many fundamentals and first principles upon which (b) will need to sort itself out.
If a Product Manager was just gonna say it and write it to an Engineer and/or a Designer anyway, why wouldn’t they just say it and write it to AI agents that can do a lot of that Engineering and Design stuff, and get more ‘final product’ output earlier and faster?”
Yes, it’s more complicated than that - and that’s a reality that is just as much an oversight of the zeitgeist as it is a flaw in my oversimplification. Once this philosophy/strategy/experiment gets unleashed into operational reality, it quickly snowballs in predictable directions.
Structurally, it demands consideration of what roles combine, collapse, contract, expand, and even perhaps - hey, if we’re going to be diligent about optimizing performance and growth potential (oh, and OpEx too, I guess), we gotta consider everything, right? - what new roles we need, and what “old” roles we don’t.
Tactically, it gushes beyond the lines of tool adoption almost instantly, requiring new technical expertise, additional overhead and artifact ownership, and then ultimately the sustained allocations and enhancements required for any practice that becomes adequately institutionalized for scale.
But realistically, we’ve been here before. A few times.
Not with AI in the mix - and AI certainly is a game-changing variable - but with very similar challenges to The What and The Why of Product Managers.
A Quick Dip in the DeLorean
Come the mid-late 2000s, PMs had successfully dusted off the expectation of “being technical” - writing javascript, querying DBs, troubleshooting bugs, etc. It was a battle to justify the healthy distance and the alternate value props; building stuff was clunky and time-consuming, reporting/data visibility wasn’t “out of the box”, the role in a software context was still fairly fresh, and even more so than today most OG PMs were ex-engineers. But heels dug in, educated arguments were made, compelling literature was published, success was achieved and replicated, and the non-Eng PM baseline was established.
Then with little delay, the industry took another swing: we introduce to you, “The Technical PM”.
(Oh, I see what you did there)
Ultimately, after some reminding and rehashing, we landed in a sensible place. Most PMs need some degree of technical literacy (they can’t plug their ears and hum Greenday songs the second something sounds code-ish), but ultimately Engineers own ‘under the hood’; and sometimes, due to the nature of the product, you do in fact need your Product Manager to be quite technical.
Fast-forward about ten years; building and deploying has gotten easier/cheaper for many types of features and products, Agile methodology is ubiquitous, everyone is being encouraged to better “understand the customer” and be more “data-driven”, and out-of-the-box insights and automation tools are making that possible.
Lean is back, baby!
Then comes the push, this time from the other end: Engineers guided to spend more time at the strategic planning and definition level and engaging directly with customers, and PMs steering to spend even more time at 30,000 feet, and back away from execution, minutia, and story-to-story support.
While some of it worked for some (and continues to work), the hard shifts didn’t hit for most, so again, there was some reminding, rehashing, and reality-checking, and ultimately we again landed in a sensible place.
Engineering as a partner needs to be involved earlier, but everyone who works in the weeds can’t be constantly pulled out because in practice the disruption is too expensive; Product Owners can be an effective “layer” to enable a more strategic PM perch, stronger process and documentation can improve knowledge transfer across cycle phases, and everyone needs to take more ownership - but ultimately it’s often best that PMs maintain a tight tether to process, definition, and execution because at the end of the day they need to know the nuance and carry all the strategic and customer context since they’ll be making many final calls at many different levels.
Time is a Flat Circle
Now, just as in the cycles before, we have a critical opportunity and obligation to revisit, reexamine, and reaffirm the role of Product Management; and with full context in mind, realign on what it touches, what it supports, and what we need it - or something like it - to do in order to achieve some definition of “success”.
True to the game of Product, this is where we (re)confront our first snag: defining what we’re actually trying to accomplish.
It seems like we continue a fixation on the never-quite-right recipe for the “velocity” + “shipping enough stuff” painpoint, with the usual sprinkles of vision / knowledge / context-leak concerns throughout.
And we continue to want to make a healthy portion of that recipe a Product Management problem.
(In fairness, from birdseye views of cost and churn reduction, ROI/ROIC/MOIC, etc. it’s an understandable attraction)
So to back it out, we land on something like this:
It’s interesting; Product / Brand Managers in Consumer Packaged Goods industries haven’t been shaved down this far.
And that makes sense, because that’s the beauty and the unique appeal of SaaS, right?
“Supply chain” and “materials” is all bits, bytes and magic; Marketing and Sales are still real, but demand gen and ad spend is its own well-oiled science/automation, and Sales shouldn’t need that much support; Pricing is always a moving target, but it’s pretty straight-forward/flexible anyway since it’s all margin; mistakes shipped are super-cheap, because if something someone bought gets dumb, ugly or broken we’ll just replace it while they’re sleeping - or while they’re in the middle of using it, whatever (pretty sure we have/had something called, “Tech Support”/FAQs); “Training” and “Enablement”? Of course, all the details of what we built are documented somewhere/in a bunch of places (wait, what was that second thing?); and “Distribution” isn’t really a thing, because all that stands between “Ready” and “Launched” is a click (or voice command for accessibility compliance).
Kind of, but not quite. Many have swung too far, and landed too narrow.
Product Management is ultimately about product success; product success is achieved at many different stages of many different processes across many different stakeholders and departments; and product success is ultimately in service of overall business and company success.
Here’s what I would consider a healthier cut at defining our evolved objectives:
With that, we’re ready to (re)remember what the life of an End-to-End Product Manager looks like.
Effectively evolved, A-list, “got to get me more of these” Product Managers are, to some degree or another, tackling most if not all of this (above).
And with many PMs at many companies covering portfolio scopes that stretch beyond a single product or feature, many of these things can be happening all the time, at the same time.
Product Management, at its highest level, is about orchestrating harmony across all of these dimensions, stakeholders, and stages - by baking and breaking down vision, injecting and inspiring innovation, quarterbacking healthy and resilient processes, commanding impeccable audience-aware communications, securing intuitive and always-accurate documentation, actively enabling all things Customer Success and GTM, exercising and enforcing excellence, asking mostly smart questions, avoiding any stupid decisions, and providing just about everyone and anyone along the way with some kind of (scalable) support - in order for a product or a feature to truly hit the mark.
Aside from the AI Tooling stuff - which is now table stakes for every role, and must supercharge any and all PMs - nothing here is particularly “new”. It’s just another way of exhibiting and ingesting the many layers of what we’ve craved through pre-growth spikes in start-ups and scale-ups, what we’ve discovered through years of operational experimentation and achievement, and what we’ve experienced through great results delivered by top performers in impressive orgs.
But it’s also a baseline, a cohesion, and a self-awareness that we’ve allowed to slip into exaggerated teleological crises at a pretty reliable clip of every 7-9ish years.
Though it goes without saying, I’ll still say it: not all of this makes total sense for all companies and all products. As seen through the historical context, things usually land in a few different places with multiple shades of the middle.
Some companies are so large that they require more cross-cycle distribution and autonomy for scale, approvals, compliance, etc.
Some products and PM portfolios are so “streamlined” in scope that some of these things don’t consume that much time and intellectual horsepower, if any at all.
Some products are just so darn “technical” or “back-end-heavy” in nature that the highest ROI model is to maximize the pieces of flair on a “builder” role and then when that gets too heavy, offload the rest to a different group (or layer) of professionals to handle more of “the business” stuff.
(ahhhh yes, a slow, comfy return to every Product professional’s favorite force-painted fuzzy line between “The Business” and “The Technology”; and I don’t recommend holding your breath on the FDE concept/role challenging that line as much as it helps redefine the context and scope of a consultancy-priced “IT” implant)
Many companies can confidently justify their own flavor of Product Management - it’s a necessary entitlement, albeit the very entitlement that gasses the role’s orbit around ambiguity. But the starting point of that definition is critical.
I'd recommend starting with the holistic ownership set and then closing in.
It’s pretty well-established what needs to get done to get things done right, so perhaps an org-aware intelligent allocation exercise will be more effective than an odd hybrid of a wholesale re-imagining and a vacuum-enclosed everyone-shift-left-and-right-at-the-same-time fire drill.
The Big Question
This is part of a post on LinkedIn by Moe Ali, CEO of Product Faculty.
“Everyone is becoming a builder.
Product managers will prototype and write more code.
Designers will take products closer to completion and validate them.
Engineers will become architects and work more directly with customers.”
Let’s run with the above as a concise summary of the musical chairs model that’s motivating material change to PMing right now.
So now that PMs are spending more of their time "building", who’s doing the rest of the end-to-end stuff?
And why is it better that they do it instead of a Product Manager?
And I don’t mean just “do it” - we’re not abandoning standards. I mean do it well, properly, effectively, successfully.
Who do we have in mind? For exactly which things? Are they equipped to do them well? Do they have time? Do they know what we're signing them up for?
(If the honest answer is, “The PM still”, then we really need to ask, “When do they have time to do it?” I will be quite disappointed if I find out this is ultimately a “75hr work weeks are the new 60hr work weeks” gameplan.)
Radiohead, "The Bends", Track 7
Here is where it is critical to not sell the PM role short. If we don’t actually represent everything that PMs do in harmony - and do at a professional grade - then coverage for each thing and its ripples will be implicitly transferred by buckshot at best, or dropped from the menu entirely at worst.
And we need to stop doing this to ourselves.
Product Leaders and PMs need to grasp and accept the holistic scope of the apex archetype, and need to stop reducing the reach and impact of the role to the same few things just because they feel like its the cleanest pole-vault over the “Business” vs. “Tech” barrier.
Understanding the Customer - that’s only part of it, and ultimately, everyone has to do that better.
Setting Priorities - that’s only part of it, and ultimately, everyone has to participate and do that better.
Defining Success - that’s only part of it, and ultimately, everyone has to participate and do that better.
Deciding What Not to Build - that’s only part of it, and ultimately, if all the existing players get better at the above (via PM guidance), and PMs get better at aligning the players on those things, then this looks more like fluidity through collaboration than it does milestones through dictation.
Delivering Customer Value - too vague, table-stakes, throwaway.
It’s not just those things; it’s all of the other things too. All of it has to go somewhere, and get done well.
The entire Product lifecycle end-to-end, the entire Org wall-to-wall.
Orchestrating harmony across every single stage to consistently, scalably deliver and make positive impacts.
It’s. All. Of. It.
Thanks to AI, major evolutions in how we organize ourselves and how we work is happening, it’s necessary, it’s exciting, and it’s taking us to some remarkable places at some cheek-stretching speeds.
The smarter we are at addressing the more holistic “How” and “By Whom”, the more exceptional the results will be, the more aligned the people will be, and the more prepared we’ll be when everything changes again in another 9 months.
And it starts by remembering who we are, what we do, and why we do it.
Mentorship program and in-person event experiences are at an extra cost.
Join for free!Join the TPMA Slack Community with 1000+ members
Free Virtual TPMA events for the entire TPMA Season
Become the first to know about in-person events and networking opportunities
Here we go. The world is once again imposing an identity crisis on Product Management.
This time it has been triggered by (a) remarkable leaps in the accessibility and usability of LLMs and AI-based “building” tools, and (b) a proliferation of amazing AI-first features and products that have created a haze that makes it look like everything and anything is or eventually will be an AI product.
For now I'll focus on (a), as it will speak to many fundamentals and first principles upon which (b) will need to sort itself out.
If a Product Manager was just gonna say it and write it to an Engineer and/or a Designer anyway, why wouldn’t they just say it and write it to AI agents that can do a lot of that Engineering and Design stuff, and get more ‘final product’ output earlier and faster?”
Yes, it’s more complicated than that - and that’s a reality that is just as much an oversight of the zeitgeist as it is a flaw in my oversimplification. Once this philosophy/strategy/experiment gets unleashed into operational reality, it quickly snowballs in predictable directions.
Structurally, it demands consideration of what roles combine, collapse, contract, expand, and even perhaps - hey, if we’re going to be diligent about optimizing performance and growth potential (oh, and OpEx too, I guess), we gotta consider everything, right? - what new roles we need, and what “old” roles we don’t.
Tactically, it gushes beyond the lines of tool adoption almost instantly, requiring new technical expertise, additional overhead and artifact ownership, and then ultimately the sustained allocations and enhancements required for any practice that becomes adequately institutionalized for scale.
But realistically, we’ve been here before. A few times.
Not with AI in the mix - and AI certainly is a game-changing variable - but with very similar challenges to The What and The Why of Product Managers.
A Quick Dip in the DeLorean
Come the mid-late 2000s, PMs had successfully dusted off the expectation of “being technical” - writing javascript, querying DBs, troubleshooting bugs, etc. It was a battle to justify the healthy distance and the alternate value props; building stuff was clunky and time-consuming, reporting/data visibility wasn’t “out of the box”, the role in a software context was still fairly fresh, and even more so than today most OG PMs were ex-engineers. But heels dug in, educated arguments were made, compelling literature was published, success was achieved and replicated, and the non-Eng PM baseline was established.
Then with little delay, the industry took another swing: we introduce to you, “The Technical PM”.
(Oh, I see what you did there)
Ultimately, after some reminding and rehashing, we landed in a sensible place. Most PMs need some degree of technical literacy (they can’t plug their ears and hum Greenday songs the second something sounds code-ish), but ultimately Engineers own ‘under the hood’; and sometimes, due to the nature of the product, you do in fact need your Product Manager to be quite technical.
Fast-forward about ten years; building and deploying has gotten easier/cheaper for many types of features and products, Agile methodology is ubiquitous, everyone is being encouraged to better “understand the customer” and be more “data-driven”, and out-of-the-box insights and automation tools are making that possible.
Lean is back, baby!
Then comes the push, this time from the other end: Engineers guided to spend more time at the strategic planning and definition level and engaging directly with customers, and PMs steering to spend even more time at 30,000 feet, and back away from execution, minutia, and story-to-story support.
While some of it worked for some (and continues to work), the hard shifts didn’t hit for most, so again, there was some reminding, rehashing, and reality-checking, and ultimately we again landed in a sensible place.
Engineering as a partner needs to be involved earlier, but everyone who works in the weeds can’t be constantly pulled out because in practice the disruption is too expensive; Product Owners can be an effective “layer” to enable a more strategic PM perch, stronger process and documentation can improve knowledge transfer across cycle phases, and everyone needs to take more ownership - but ultimately it’s often best that PMs maintain a tight tether to process, definition, and execution because at the end of the day they need to know the nuance and carry all the strategic and customer context since they’ll be making many final calls at many different levels.
Time is a Flat Circle
Now, just as in the cycles before, we have a critical opportunity and obligation to revisit, reexamine, and reaffirm the role of Product Management; and with full context in mind, realign on what it touches, what it supports, and what we need it - or something like it - to do in order to achieve some definition of “success”.
True to the game of Product, this is where we (re)confront our first snag: defining what we’re actually trying to accomplish.
It seems like we continue a fixation on the never-quite-right recipe for the “velocity” + “shipping enough stuff” painpoint, with the usual sprinkles of vision / knowledge / context-leak concerns throughout.
And we continue to want to make a healthy portion of that recipe a Product Management problem.
(In fairness, from birdseye views of cost and churn reduction, ROI/ROIC/MOIC, etc. it’s an understandable attraction)
So to back it out, we land on something like this:
It’s interesting; Product / Brand Managers in Consumer Packaged Goods industries haven’t been shaved down this far.
And that makes sense, because that’s the beauty and the unique appeal of SaaS, right?
“Supply chain” and “materials” is all bits, bytes and magic; Marketing and Sales are still real, but demand gen and ad spend is its own well-oiled science/automation, and Sales shouldn’t need that much support; Pricing is always a moving target, but it’s pretty straight-forward/flexible anyway since it’s all margin; mistakes shipped are super-cheap, because if something someone bought gets dumb, ugly or broken we’ll just replace it while they’re sleeping - or while they’re in the middle of using it, whatever (pretty sure we have/had something called, “Tech Support”/FAQs); “Training” and “Enablement”? Of course, all the details of what we built are documented somewhere/in a bunch of places (wait, what was that second thing?); and “Distribution” isn’t really a thing, because all that stands between “Ready” and “Launched” is a click (or voice command for accessibility compliance).
Kind of, but not quite. Many have swung too far, and landed too narrow.
Product Management is ultimately about product success; product success is achieved at many different stages of many different processes across many different stakeholders and departments; and product success is ultimately in service of overall business and company success.
Here’s what I would consider a healthier cut at defining our evolved objectives:
With that, we’re ready to (re)remember what the life of an End-to-End Product Manager looks like.
Effectively evolved, A-list, “got to get me more of these” Product Managers are, to some degree or another, tackling most if not all of this (above).
And with many PMs at many companies covering portfolio scopes that stretch beyond a single product or feature, many of these things can be happening all the time, at the same time.
Product Management, at its highest level, is about orchestrating harmony across all of these dimensions, stakeholders, and stages - by baking and breaking down vision, injecting and inspiring innovation, quarterbacking healthy and resilient processes, commanding impeccable audience-aware communications, securing intuitive and always-accurate documentation, actively enabling all things Customer Success and GTM, exercising and enforcing excellence, asking mostly smart questions, avoiding any stupid decisions, and providing just about everyone and anyone along the way with some kind of (scalable) support - in order for a product or a feature to truly hit the mark.
Aside from the AI Tooling stuff - which is now table stakes for every role, and must supercharge any and all PMs - nothing here is particularly “new”. It’s just another way of exhibiting and ingesting the many layers of what we’ve craved through pre-growth spikes in start-ups and scale-ups, what we’ve discovered through years of operational experimentation and achievement, and what we’ve experienced through great results delivered by top performers in impressive orgs.
But it’s also a baseline, a cohesion, and a self-awareness that we’ve allowed to slip into exaggerated teleological crises at a pretty reliable clip of every 7-9ish years.
Though it goes without saying, I’ll still say it: not all of this makes total sense for all companies and all products. As seen through the historical context, things usually land in a few different places with multiple shades of the middle.
Some companies are so large that they require more cross-cycle distribution and autonomy for scale, approvals, compliance, etc.
Some products and PM portfolios are so “streamlined” in scope that some of these things don’t consume that much time and intellectual horsepower, if any at all.
Some products are just so darn “technical” or “back-end-heavy” in nature that the highest ROI model is to maximize the pieces of flair on a “builder” role and then when that gets too heavy, offload the rest to a different group (or layer) of professionals to handle more of “the business” stuff.
(ahhhh yes, a slow, comfy return to every Product professional’s favorite force-painted fuzzy line between “The Business” and “The Technology”; and I don’t recommend holding your breath on the FDE concept/role challenging that line as much as it helps redefine the context and scope of a consultancy-priced “IT” implant)
Many companies can confidently justify their own flavor of Product Management - it’s a necessary entitlement, albeit the very entitlement that gasses the role’s orbit around ambiguity. But the starting point of that definition is critical.
I'd recommend starting with the holistic ownership set and then closing in.
It’s pretty well-established what needs to get done to get things done right, so perhaps an org-aware intelligent allocation exercise will be more effective than an odd hybrid of a wholesale re-imagining and a vacuum-enclosed everyone-shift-left-and-right-at-the-same-time fire drill.
The Big Question
This is part of a post on LinkedIn by Moe Ali, CEO of Product Faculty.
“Everyone is becoming a builder.
Product managers will prototype and write more code.
Designers will take products closer to completion and validate them.
Engineers will become architects and work more directly with customers.”
Let’s run with the above as a concise summary of the musical chairs model that’s motivating material change to PMing right now.
So now that PMs are spending more of their time "building", who’s doing the rest of the end-to-end stuff?
And why is it better that they do it instead of a Product Manager?
And I don’t mean just “do it” - we’re not abandoning standards. I mean do it well, properly, effectively, successfully.
Who do we have in mind? For exactly which things? Are they equipped to do them well? Do they have time? Do they know what we're signing them up for?
(If the honest answer is, “The PM still”, then we really need to ask, “When do they have time to do it?” I will be quite disappointed if I find out this is ultimately a “75hr work weeks are the new 60hr work weeks” gameplan.)
Radiohead, "The Bends", Track 7
Here is where it is critical to not sell the PM role short. If we don’t actually represent everything that PMs do in harmony - and do at a professional grade - then coverage for each thing and its ripples will be implicitly transferred by buckshot at best, or dropped from the menu entirely at worst.
And we need to stop doing this to ourselves.
Product Leaders and PMs need to grasp and accept the holistic scope of the apex archetype, and need to stop reducing the reach and impact of the role to the same few things just because they feel like its the cleanest pole-vault over the “Business” vs. “Tech” barrier.
Understanding the Customer - that’s only part of it, and ultimately, everyone has to do that better.
Setting Priorities - that’s only part of it, and ultimately, everyone has to participate and do that better.
Defining Success - that’s only part of it, and ultimately, everyone has to participate and do that better.
Deciding What Not to Build - that’s only part of it, and ultimately, if all the existing players get better at the above (via PM guidance), and PMs get better at aligning the players on those things, then this looks more like fluidity through collaboration than it does milestones through dictation.
Delivering Customer Value - too vague, table-stakes, throwaway.
It’s not just those things; it’s all of the other things too. All of it has to go somewhere, and get done well.
The entire Product lifecycle end-to-end, the entire Org wall-to-wall.
Orchestrating harmony across every single stage to consistently, scalably deliver and make positive impacts.
It’s. All. Of. It.
Thanks to AI, major evolutions in how we organize ourselves and how we work is happening, it’s necessary, it’s exciting, and it’s taking us to some remarkable places at some cheek-stretching speeds.
The smarter we are at addressing the more holistic “How” and “By Whom”, the more exceptional the results will be, the more aligned the people will be, and the more prepared we’ll be when everything changes again in another 9 months.
And it starts by remembering who we are, what we do, and why we do it.
Toronto Product Management Association (TPMA) is a community focused on development, growth and networking of Product professionals in the Greater Toronto Area.
