We Will Not Need Product Managers and Engineers in the Same Way
AI is collapsing the boundary between deciding what to build and building it. The organizations that benefit will be the ones whose engineering systems make ownership possible.
Product management as a separate profession is a relatively modern idea in software.
The work is not new. Someone always had to understand the customer, make tradeoffs, and turn an idea into a product. But as technology companies grew, we split that work into specialized roles.
Product managers decided what should be built. Engineers decided how to build it. We treated this separation as organizational maturity: better results would come from having people specialize in narrower parts of the process.
For a while, that made sense. Scale was the main problem. Now the direction is reversing.
Across more than two decades in engineering, pre-sales, partner management, and product management, I found that the most valuable work happened when customer understanding, commercial judgment, technical design, and execution came together.
AI is turning that into a practical operating model.
Product managers can now build. Engineers can now do much more of the work traditionally assigned to product managers. The long-term question is not which profession wins. It is why we continue to organize teams around a boundary that the tools are rapidly removing.
Product Management Existed to Bridge a Costly Gap
Building software was expensive and engineering capacity was scarce. Companies created functions to research customer needs, prioritize investments, align stakeholders, and reduce the risk that engineers built the wrong thing.
When every experiment consumed weeks of engineering time, separating deciding from building was rational.
But AI changes the cost structure.
A product manager can now describe a problem, generate a prototype, test it, and put it in front of users. What required a handoff can happen inside one loop:
Understand the problem. Build something. Test it with users. Learn. Change it.
That is product management and engineering at the same time.
I experience this in my work on Microsoft Fabric extensibility. A partner conversation can reveal a gap; I can move into the TypeScript code, change the toolkit or validator, test it, and return with something concrete. Discovery and implementation become one learning loop.
Yes, Product Managers Should Be Able to Build
A common objection is that product managers are not sufficiently skilled to write production code.
I disagree with the premise.
Not every product manager can build production software today. That is often evidence that the company’s engineering system makes development unnecessarily difficult. (A problem for engineers as well)
In a healthy system, the repository is understandable, interfaces are clear, tests express expected behavior, and automation catches regressions and security problems.
With those foundations, AI can help a product manager make a bounded change and ship it through the same controls used for everyone else.
If only long-tenured engineers can safely change a system, the organization has accumulated knowledge in people instead of encoding it in architecture, tests, tooling, and documentation.
AI did not create that weakness. It exposed it.
Engineers Are Already Becoming Product Managers
The convergence works in the other direction as well.
Engineers in AI-first teams can explore approaches and test hypotheses without specialist handoffs. When implementation becomes cheaper, choosing the right problem becomes more important. Customer empathy, prioritization, and product judgment become part of engineering itself.
The best engineers have always asked why, challenged assumptions, understood the user, and found simpler solutions. AI gives them more reach.
An engineer who understands the problem and can execute across the stack does not need a product manager to translate every decision into a backlog item. They need access to customers, context, goals, and constraints.
The Codebase Determines How Much Convergence Is Possible
This is where many discussions become too optimistic.
Role convergence depends on the codebase and the system around it. With clear patterns, modular boundaries, fast feedback, representative tests, and reliable tooling, engineers and product managers can operate at a higher level without losing control.
AI struggles when the codebase is tightly coupled, poorly documented, inconsistent, slow to test, or full of hidden assumptions. The model can still produce code quickly, but the organization cannot determine quickly whether that code is safe.
AI-first organizations will encode knowledge into architecture, tests, documentation, and automated controls. Others will add AI to a brittle delivery process and conclude that generated software is unreliable.
Their problem will not be model capability. It will be that their engineering environment cannot convert faster generation into trustworthy delivery.
Roles Will Remain, but the Boundary Will Matter Less
Companies will not remove product management or engineering titles tomorrow. Deep technical and product expertise remain essential.
But expertise is not the same as exclusivity.
People will still have different strengths, but high-capability teams will cross the old boundary. Product people will build. Engineers will shape the product. Both will work with customers and own outcomes.
The useful distinction will not be between people who think and people who implement.
It will be between people who can take ownership of an outcome and those who can only complete one step in a predefined process.
The Real Transformation Is Organizational
The debate about whether product managers should code misses the point. AI is reducing the coordination cost that caused companies to divide product creation into narrow functions.
Can a product manager turn a customer insight into a tested prototype? Can an engineer speak with users and decide what not to build? Can a new contributor or AI agent understand the repository and make a safe change?
If not, adding an AI coding assistant will only generate code faster inside an operating model designed for scarcity.
The companies that benefit most from AI will not be those that preserve the cleanest boundary between product and engineering. They will be those that build the technical and organizational systems that make the boundary unnecessary.
We will still need excellent product judgment. We will still need excellent engineering judgment.
We just will not need to keep pretending they belong to different people.
Discussion Prompt
Is your company preparing people to work across product and engineering, or using AI to make the existing handoffs slightly faster?