The Product Manager Is Dead. Long Live the Product Developer.

10 min read

Specialization Was a Workaround, Not a Strategy

Here is how the old world worked. A “business person” had an idea. They wrote a document. Maybe they drew mockups. They handed that document to “the technical team” and said: build this. Then they waited. Weeks later, something came back. Wrong, usually. So they wrote a longer document with more detail. The technical team built that, too. Also wrong. Repeat until budget runs out or everyone gives up.

This workflow created entire job families. Product Managers who “own the backlog.” Business Analysts who “gather requirements.” Subject Matter Experts who “know the domain.” UX Designers who “understand users.” All feeding instructions to developers who were apparently too stupid to understand anything beyond syntax.

That assembly line made sense when turning intent into working software required months of typing. Translation was expensive. You needed specialists at every handoff point because each handoff lost information and someone had to catch the loss.

AI killed translation costs. And with them, the rationale for most of those handoffs.

The Mockup Handover Is Over

Picture the classic Product Manager. They spend three weeks talking to stakeholders, distilling requirements, building a Jira backlog, creating Figma mockups, writing acceptance criteria. They schedule a “grooming” meeting. They present the mockups to the team. The team asks questions. The PM goes back to stakeholders for answers. Comes back next sprint. The cycle repeats.

That person’s entire value proposition was being the translator between “business” and “technology.” They existed because developers couldn’t afford the time to understand the domain. Every hour a developer spent talking to users was an hour they weren’t typing code. And typing was the bottleneck.

Typing is no longer the bottleneck.

When a developer can describe a system to an AI and have working code in hours instead of weeks, the economics flip. The bottleneck is now understanding the problem. And the Product Manager was never the one who understood the problem deepest. The users understood it. The developers, once they talked to the users, understood it fast enough.

The translation layer becomes overhead.

Subject Matter Experts Without Skin in the Game

Subject Matter Experts had a similar deal. They knew the business rules, the regulatory constraints, the edge cases. They sat in meetings and explained things. Developers took notes. Most of the nuance got lost because it was passed through two or three people before reaching the code.

The SME who never ships code has a fundamental problem: no feedback loop. They describe what should happen, someone else builds it, and by the time the gap between intent and implementation surfaces, six weeks have passed and nobody remembers the original conversation.

A developer who understands the domain doesn’t have that problem. They hear the business rule, they encode it, they test it, they ship it. Same day. The feedback loop is hours, not months.

“But developers can’t understand complex business domains!” I hear this from people who’ve never actually tried. A competent software developer who spends two weeks immersed in a domain will understand it well enough to build the software. Not well enough to run the business. But well enough to build the software. That’s the bar. And AI makes the immersion faster because the developer can ask questions, model scenarios, and prototype solutions in real time instead of scheduling meetings.

Vertical Integration Wins

The old model was horizontal specialization. One person knows the users. Another person knows the domain. Another person designs the interface. Another person writes the backend. Another person handles infrastructure. Five people, five handoffs, five opportunities for information loss.

The new model is vertical integration. One person (or a tight pair) who understands the user problem, designs the solution, builds the system, tests it, deploys it, and monitors it in production. Not because they’re superhuman. Because AI handles the parts that used to require separate specialists for mechanical reasons. Because software development is design, not assembly.

SpaceX figured this out with rockets. When you vertically integrate, you eliminate handoff delays and information loss. The person making the design decision is the person who sees the consequences.

This is the T-shaped Software Product Developer. Deep expertise in system design and engineering discipline. Broad enough knowledge to talk to users, understand regulatory constraints, design interfaces, manage infrastructure. AI fills the gaps. You don’t need to memorize Kubernetes YAML. You need to understand why your deployment strategy matters and let AI write the manifests.

What Dies

Let me be specific about what disappears.

The Product Manager who writes tickets. If your contribution is translating stakeholder wishes into Jira stories, AI does that faster and with less information loss. The developer talks to the stakeholder directly, sketches the solution with AI assistance, and ships it. Your intermediary role is gone.

The Business Analyst who documents requirements. Requirements documents were always a poor substitute for conversation. Now the conversation happens in real time between the person who has the problem and the person who ships the solution. The document never needs to exist.

The UX Designer who hands over mockups. A developer with AI can prototype an interface in minutes, show it to users, iterate in real time. The “design handoff” was a ceremony for a world where building a prototype was expensive. It’s not expensive anymore.

The Subject Matter Expert who only advises. Domain knowledge without implementation authority is just consulting. The Product Developer absorbs enough domain knowledge to build the right thing and validates with the actual domain users.

The Scrum Master who facilitates. When a team of two or three Product Developers ships daily, there’s nothing to facilitate. No sprint planning because there are no sprints. No retrospectives because feedback is continuous. No standups because the team is small enough to just talk. As the framework lifecycle showed us, these roles were products of the framework industry. Small teams that ship without ceremony have always outperformed framework-laden departments.

What Survives

Not the Product Manager. The activities.

Talking to users, understanding market dynamics, evaluating whether software solves real problems. Those things don’t disappear. They become what every developer on the team does. There’s nobody left to “manage” the product because there’s nothing to manage. There are decisions to make, and the people making them are the same people writing the code.

Eric Ries got this right fifteen years ago with Lean Startup. Build-measure-learn. Ship something small. Watch what users actually do. Adjust. Ship again. The problem was never the idea. The problem was that “build” took six months and required a 40-person relay race from PM to BA to designer to developer to QA to ops. So “measure” arrived too late and “learn” got buried under the next sprint’s backlog.

AI collapsed “build” to hours. Now build-measure-learn runs daily. A Product Developer ships a feature in the morning, watches usage data in the afternoon, and decides by evening whether to iterate, expand, or kill it. No roadmap committee. No quarterly prioritization theater. Just a tight loop between code and reality.

The domain expert who can sit with a developer and answer questions in real time while the developer builds? Essential. But they’re embedded, not siloed. They don’t write documents. They demonstrate workflows, explain edge cases, validate behavior. The developer encodes what they learn immediately.

What about designers? In theory, one who can prototype, test with users, and iterate the same day is valuable. In practice, most designers won’t make the leap. They refuse to learn CSS. They cling to Figma and hand over pixel-perfect mockups of things that don’t work in a browser. They treat the web as a canvas instead of a medium with its own constraints. That stubbornness is a career-ending choice. A Product Developer with decent taste, a feel for usability, and AI generating layout variations in seconds will produce better results than a designer who draws pictures and throws them over the wall. Good UX sense isn’t a rare gift. It’s a skill that developers with curiosity pick up fast, especially when AI handles the visual experimentation.

The common thread: everyone who survives works inside the product development cycle, not adjacent to it. And “product management” dissolves from a role into a shared discipline. Every developer on the team talks to users. Every developer reads production metrics. Every developer makes product decisions. That’s not chaos. That’s build-measure-learn without the middleman.

The T-Shaped Product Developer

This is the profile that replaces five separate roles.

Deep skills: System architecture. Testing strategy. Deployment and observability. Security fundamentals. The ability to read code, reason about failure modes, and verify that AI output actually works. These are non-negotiable. The end of coding didn’t mean the end of development. It meant the end of clerical typing. And let’s call it what it is: development, not engineering. Engineers apply established rules. A civil engineer follows building codes. A software developer creates something that didn’t exist before, makes judgment calls in uncertainty, and takes responsibility for outcomes nobody can predict from a specification. That’s development. The word matters.

Broad skills: Domain understanding. User empathy. Basic design sense. Communication with stakeholders. Regulatory awareness where relevant. Business model comprehension. You don’t need an MBA. You need enough business literacy to know whether what you’re building matters.

AI-augmented skills: Infrastructure configuration. UI prototyping. Data analysis. Documentation. Boilerplate generation. Test scaffolding. Anything that used to require a specialist because of mechanical complexity, not conceptual complexity.

Humans decide what to build, how to structure it, whether it works. AI produces the code, the tests, the documentation, the configuration. Judgment stays human. Volume goes to the machine.

Why Organizations Resist This

Because it threatens headcount, budgets, and empires.

A VP of Product with 15 Product Managers isn’t going to volunteer that 12 of those roles could be absorbed into development teams. A Head of Business Analysis with 8 analysts isn’t going to suggest dissolving the department. A Director of UX with a team of 20 designers isn’t going to admit that 15 of them are doing work that AI plus a product developer handles better.

Organizations optimize for efficiency through specialization. That’s the factory model. It works when the constraint is production throughput. It fails when the constraint is comprehension and decision-making.

Building products in the age of AI requires small teams that move fast and decide well. Every person in the room should be capable of shipping. If someone’s job is only to describe what should be built without any ability to build it, they’re a bottleneck, not an enabler.

The Uncomfortable Truth

This isn’t a prediction. This is already happening at every company where developers use GitHub Copilot, Claude Code, or similar tools seriously.

A developer who uses AI well can absorb work that previously required three or four supporting roles. Not because those roles were unnecessary in the old model. They were necessary. Translation was genuinely hard. Handoffs were genuinely expensive. Specialization was genuinely efficient when typing was the bottleneck. And no, AI doesn’t replace the developer. We’ve tried that every decade since 1969. It fails every time.

But the bottleneck moved. AI became a thinking partner, not just a typing assistant. The developer who uses it well doesn’t just code faster. They understand faster. They prototype faster. They validate faster. They ship faster.

The question isn’t whether this transition happens. It’s whether your organization adapts or gets outcompeted by a three-person team that ships more value in a week than your 40-person department ships in a quarter.

Getting There

Stop hiring for handoff roles. Start hiring for integration roles.

Stop asking “who writes the requirements?” Start asking “who understands the problem well enough to ship the solution?”

Stop separating “business” from “technical.” The Product Developer is both.

Invest in developers who are curious about domains, not just about technology. Invest in domain experts who are willing to pair with developers, not just write documents. Invest in designers who prototype with code, not just with Figma.

Kill the assembly line. Build integrated teams. Ship daily. Measure outcomes. Everything else is overhead.

The Product Manager is dead. Long live the Product Developer.