Product Engineering Overtaking Product Management?
Introduction
Many professions have become extinct with time and technology, from telephone switchboard operators to watch and camera repair professionals.
New roles appear in the technology world, while others disappear or are sidelined.
A role's emergence or obsolescence can be due to new technology (e.g., AI = artificial intelligence) or a shift in work methods and how organizations operate.
This review explores the validity of whether an evolving skills gap will lead to "product engineering overtaking product management".
Background
People predicting the emergence of new professions and the demise of others is in itself predictable.
Product management was not spared these predictions.
Ryan Singer, the author of Shape-Up, wrote a post on Linkedin:
I’m starting to think Product Management will be overtaken by Product Engineering.
Engineers are learning product. But PMs aren’t learning how to build.
Reminds me of the old days when “information architects” got together and complained about how nobody understood how important they were. Then they disappeared.
The post was reposted 24 times, and 292 people reacted positively.
The post's popularity merits examining its core message.
Message
The post consists of a thought (veiled prediction), two observations, and a past occurrence of a supposed equivalent situation to reinforce the prophecy.
The post is phrased in a way that demands much clarification, for example:
- "Product Management will be overtaken by Product Engineering". What does overtake mean (surpass or replace)? Is product engineering the same as product development?
- "Engineers are learning product". What is "Product"? Does this mean that engineers learning to perform product management tasks? If so, which tasks?
- "PMs aren't learning how to build". Does this mean product managers should learn and perform product development tasks?
One possible interpretation of the post's message is that product engineers know how to build a product and understand the product's internals, technology, and architecture.
Product managers are considered less technical or non-technical and supposedly not versed in nor trying to learn product development methods.
The post suggests engineers are acquiring product management knowledge and could potentially be able to perform both product management and product development activities.
This situation, as the post suggests, where the engineers have product management and product development knowledge and skills, could marginalize, invalidate and replace product management in all product decisions.
This is what is likely meant by "product engineering overtaking product management", which implies a company would only need product engineers and no product managers.
Product managers would then disappear from the corporate landscape, similar to the "Information Architects" fate described in the post.
Origin
What is the root cause of the message in the post that a company could suffice only with capable engineers and without product managers? Where did this idea come from?
The Technology approach to product management considers product management as an extension of product development and, at times, even subservient to product developers and the product development process.
The Technology approach, implemented predominantly at software development companies, promotes the notion that a deep understanding of technology and acute product knowledge is highly valued and primary.
At these technology-driven companies, strategic aptitude, market knowledge, and strategy formulation skills associated with product management are considered secondary to hard-earned technical skills.
These considerations could promote a belief that engineers can more easily learn product management skills than product managers can learn engineering skills.
But learning and doing are different things.
Reality
Engineers gain a deep understanding of product internals through their education, experience, and professional focus, which takes time and lots of learning.
But engineering and technical know-how are not transferable to markedly dissimilar domains, such as user experience (UX), product marketing, and product management.
Furthermore, intelligence can be overshadowed by disposition and mindset.
Engineers flourish in the organized, deterministic, structured, orderly, and predictable technical world. It's natural to them.
Conversely, many engineers find the conceptual, ambiguous, and probabilistic world of product management less favorable to their personalities. They soon gravitate to their comfort zone — technology.
The Technology approach to product management is unsupported and lacks a methodological foundation. It is unsurprising it can lead to misguided ideas and false predictions.
PMTK
The Blackblot PMTK Methodology™ views the Product Manager as a strategic role in the problem space that is responsible for managing the market problem that the product solves.
More specifically, the product manager is a strategic role in the problem space, owned by an analytical and articulate problem-teller, a market expert with a formalized mindset.
According to PMTK foundation rules, PMTK asserts the identity of product managers and engineers:
Product Managers are market experts, and Engineers are technology experts.
Product Managers are problem-tellers, and Engineers are problem-solvers.
Aggregation
The post suggests that engineers could potentially be able to perform both product management and product development activities.
This is Role Aggregation, and it occurs in companies due to budgetary concerns, politics, entrenched culture, and viewpoints.
But role aggregation is counterproductive because it gradually neutralizes or degrades performance when people cannot focus on their core job.
According to PMTK, Product Management belongs to the problem space, and Product Development belongs to the solution space.
PMTK's primary guideline for combining roles is to have all the combined roles belong to one space only.
That means do not mix and assign roles from both the problem and solution spaces to one person.
The secondary guideline to follow when combining roles is only to join roles of the same character.
For example, assigned roles are all strategic. Do not assign strategic and operational roles to one person.
Following these two guidelines should mitigate the negative impact of role aggregation.
Summary
Product management will not be overtaken by product engineering.
Aggregating product management with product development responsibilities across both the problem and solution spaces will prove inefficient.
The reports and predictions of the demise of product management are greatly exaggerated.