Product Management is not one role.
It is a response to complexity.
When organisations get more complex, coordination becomes expensive. When coordination becomes expensive, someone needs to own outcomes across boundaries. That “someone” keeps changing shape, because the systems keep changing shape.
The title stayed.
The job evolved.
1931: the origin story was commercial
Modern Product Management has a clear ancestor: Procter & Gamble.
In 1931, Neil H. McElroy wrote the memo that introduced the idea of “Brand Men”. One person. One brand. End-to-end responsibility. Sales, positioning, advertising, customer understanding. A mini business inside a business.
The emphasis was outward.
Market.
Distribution.
Messaging.
Commercial success.
This is the root of “own the outcome”.
Background here.
Software changed the centre of gravity
As software grew into the product, the bottleneck shifted.
In consumer goods, the product is stable and the market changes around it.
In software, the market shifts and the product itself changes constantly.
Engineering-led teams could build.
Project managers could schedule.
Marketing could sell.
But nobody was structurally accountable for: “Are we building the right thing, for the right users, with the right trade-offs?”
So Product Management re-emerged inside tech.
Not as branding.
As translation and prioritisation.
The “mini-CEO” era happened for a reason
Tech Product Managers became popular because they sat in the gap.
Between:
business goals
user needs
engineering constraints
The “mini-CEO” label stuck because PMs were expected to own outcomes without owning resources. The influence model became part of the job.
Then agile accelerated it.
Agile pulled Product closer to delivery. Closer to decisions. Closer to iteration cycles. PM became embedded in the build loop, not sitting outside it.
Today’s Product Manager is a connector, not a commander
“Mini-CEO” implies authority.
Most Product Managers operate without it.
The modern PM role is more like a systems connector. It is the point where inputs become decisions.
Inputs like:
user feedback
metrics and performance
commercial targets
technical constraints
regulatory requirements
delivery capacity
The output is direction.
Not just a roadmap.
A set of trade-offs that create a coherent product direction across teams.
The job expanded into a multi-skill operating role
The PM skillset broadened because product systems broadened.
A modern Product Manager is expected to be:
customer-anchored
data-literate
technically fluent
commercially aware
strong at alignment
strong at narrative
comfortable with ambiguity
This is not about being good at everything.
It is about being able to coordinate specialists into coherent outcomes.
The role absorbs complexity.
It does not eliminate it.
Specialisation is not a trend. It is an inevitability.
As product orgs scale, generalist PM work fragments into domains.
Growth PM.
Platform PM.
Pricing PM.
AI PM.
Data PM.
Security and privacy-focused PM work.
That is not “titles for the sake of it”.
It is product architecture catching up with organisational architecture.
Good sources that track the practice and the shift:
The next shift is AI, but not in the way most posts frame it
AI is not just “a new feature type”.
It changes the production model of work.
PM workflows already include:
synthesising feedback
drafting requirements
analysing competitor moves
creating comms
creating plans and stories
AI tools will automate pieces of that.
The leverage is not “doing the same work faster”.
The leverage is redesigning the loop.
When parts of execution become cheap, the scarce input becomes:
problem selection
judgment
evaluation
ethics
system design
AI adds a new responsibility: steering systems, not features
AI introduces failure modes that do not look like normal product bugs.
Bias.
Hallucination.
Silent degradation.
Prompt sensitivity.
Data leakage.
Misaligned optimisation.
This makes the PM role more governance-heavy in some contexts, especially regulated environments.
The PM becomes responsible for:
defining what “good” means
defining guardrails
designing feedback loops
choosing when humans intervene
ensuring auditability
This is product thinking moving up a layer.
From “ship the feature” to “ship a safe, monitored system”.
The constant thread
The role changed shape across decades, but the invariant remains.
A Product Manager exists to own the success of a product by:
understanding users and market
making prioritisation decisions under constraint
aligning teams around a coherent direction
ensuring what ships creates value
The tactics evolve.
The responsibility does not.
One implication for builders
If you want to stay relevant as a Product Manager, do not chase trend knowledge.
Build systems literacy.
Learn to:
design loops
define metrics
allocate attention
create governance layers
run experiments with discipline
interpret outputs without outsourcing judgment
Execution will keep getting cheaper.
Good judgment will not.