The AI-era role debate is asking the wrong question.
Most of the conversation sounds like this: can product managers code now? Can designers build features? Can marketers make their own tools? Those are interesting questions, and they're too narrow to explain what's actually happening.
What's changing is that AI is making the activities inside product development more legible and more learnable. Product managers can prototype. Engineers can explore product tradeoffs without a translation layer. Teams in research, support, and operations can build workflows that used to need long chains of handoffs. The movement runs in every direction at once, which is why framing it as one function borrowing from another misses it.
I've spent a good part of the last two years running prototyping workshops for people whose titles have nothing to do with building software, and the thing that surprised me wasn't how much they could produce. It was how quickly the interesting question stopped being "can you build this" and became "should you be the one who ships it."
Roles are bundles of capabilities. AI is starting to unbundle them.
Roles are useful, but they're still shortcuts
Roles exist for good reasons. Companies need them for hiring, compensation, and career development, and nobody wants to run a large organization by treating every person as a completely bespoke snowflake. That way lies chaos, and probably a very sad HR business partner. They're still shortcuts, though.
A title tells you where someone sits in the organization. It does not tell you, with much precision, what that person can actually do, at what depth, based on what evidence, in what context, and with what level of autonomy.
Think about two product managers on the same team. One is excellent at strategy and executive narrative and can also build a rough prototype when it saves a week of back-and-forth. The other has no interest in implementation and is every bit as valuable. Same title, same level, genuinely different shapes.
People are spiky and roles flatten them. That was true long before AI. AI just makes it harder to ignore.
We keep confusing roles with capabilities
When people ask whether product managers can code, they're usually mixing together several different questions at once. Capability is one. So are context, evidence, review, and who owns the outcome. All of them tend to collapse into a single proxy: what's this person's title?
Take technical implementation. Reading a tradeoff, shipping to a low-risk surface, and approving a security-sensitive change are wildly different capability levels wearing the same word. The same is true of product strategy, design, research, and most other areas of the work.
The better model is simple: individuals have capability profiles, and workstreams have capability needs.
A capability profile describes what someone can do, at what level, and on what evidence. A workstream map describes what the work requires, given its scope and risk. Put the two next to each other and the planning conversation changes: instead of asking which functions to assign, you ask what the work needs and who can responsibly provide it.
This is not everyone doing everything
Let me say the dangerous part out loud: this idea can be misused. It can become "AI means everyone can do more, so we need fewer people," or a permission slip to push people into work they aren't good at and don't want to own. The most seductive version is the polished-output one, where a leader waves off craft expertise because what the model produced looked good enough in a meeting. If anything, AI raises the stakes on review and accountability.
I'm not pointing at somebody else here. I've written the org-design argument myself: flatter structures, fewer overlapping roles, wider spans. I still think most of it holds up. What I've also learned is that an argument like that gets picked up as a headcount exercise almost immediately, because that's the fastest thing anyone can do with it. If you're going to make the case, you own where it lands.
There's one test I'd apply, and it has to be organizational rather than personal: did the whole system get better, or did one person just get faster? If unbundling capability creates more low-quality work for everyone else to inspect and redo, then congratulations, you didn't improve anything. You moved the bottleneck and made it more annoying.
The goal is not to have everyone do everything. The goal is to match work to evidenced capability, with the right review and ownership model.
Autonomy should follow evidence, risk, and review
The word doing the work there is "evidenced." Capability shouldn't rest on self-description, vibes, or enthusiasm.
I got a much sharper view of that when a few of us rebuilt part of our PM interview loop earlier this year. The version we replaced asked candidates to talk through work they'd done, which mostly measures how well someone narrates. We swapped it for an hour of live building: here's a problem, here are the tools, make something. The first thing we learned is that people kept explaining what they would do instead of doing it, so we gave them most of the hour to build and saved the conversation for the end. What came out was a far better read on prompting, on iteration, and on knowing when the thing in front of you is solid enough to show someone. None of that had shown up reliably in the old format, and I'd assumed for years that it did.
Evidence can come from demonstrated work, manager assessment, peer attestation, senior expert review, artifact review, structured exercises, or formal certification for high-risk capabilities.
Most capabilities don't need a certification path, and I'd resist building one. If every level of every capability requires a formal process, you've just built bureaucracy with a better vocabulary. Some work does need stronger validation before anyone acts alone: customer data handling, accessibility signoff, production-critical review. "The AI seemed confident" shouldn't get anyone across those lines.
The way out of that trap sits in the same shift that created it. Roles won in the first place because fine-grained capability data was expensive: nobody could track what every person could actually do, so we compressed it into a title and took the loss. AI changes that side of the ledger too. When the work happens in prototypes, review threads, and shipped artifacts, the evidence is exhaust from the work itself rather than a form somebody fills out. A capability profile shouldn't be a database anyone maintains. It should be something you could reconstruct from what a person has built and how it held up once someone else looked at it. If your version needs a quarterly self-assessment cycle, you've rebuilt the performance review and given it a badge.
Validation is about trust, and the badge is just bookkeeping. When someone's validated at the right level, it should shape what they can do alone, what still needs review, who's allowed to review others, and eventually what permissions they hold in the systems where the work happens.
This is where it gets more interesting than "can PMs code?" A product manager can be perfectly capable of building a prototype and still need engineering review before it goes to production. A support leader can spot a workflow worth automating and still need a privacy review before it touches customer data. Neither of those is a demotion. That's what the work looks like when capability and review are tracked separately.
Someone still has to be accountable for the result, and the model only holds together if that accountability gets sharper as contribution gets more flexible. Flexible contribution can't become an excuse for fuzzy ownership. AI raises the ceiling on how much one capable person can touch, and it raises the importance of knowing exactly where their work needs another set of eyes.
Functions may become stewards of craft
So what happens to functions? They still matter, quite a lot. Engineering still needs architecture judgment and operational discipline. Design still needs critique and accessibility expertise. Every one of these functions carries real craft that shouldn't be flattened into "anyone with a prompt can do this now." What changes is what the function is mainly for. It stops being the gate that decides who's allowed to do the work and becomes something closer to a guild, the steward of how the work gets done well.
The community of people developing or exercising a capability may become broader than the formal function that historically owned it.
Through all of it, the guild is what defines good. It sets the examples, reviews the work, validates the higher-risk levels, and keeps the craft from sliding into slop. That's stewardship rather than gatekeeping, and it means reporting lines are only part of the story. What matters just as much is where standards live and how work actually crosses disciplines.
What leaders should do differently
None of this needs a transformation program. The starting point is much smaller. In planning, ask:
- What outcome is this workstream accountable for, and who owns it?
- What capabilities does the work require, at what level, given the scope and risk?
- Who has evidence of those capabilities, or the capacity and appetite to grow into them with review?
- What still needs a second set of eyes, and whose?
That's a sharper conversation than "do we have a PM, designer, and engineer assigned?" Sometimes the answer is still yes, you need all of them. Great. Nothing here argues otherwise. It just makes the reasoning explicit.
I've run a version of this. A while back I stood up governance for cross-cutting engineering work, and the mechanics landed close to the list above. Every initiative needed a named senior sponsor, a written business case, and an explicit call on whether it was required, recommended, or fine to skip this year. The tracking turned out to be the least valuable part. What mattered was that the priority argument had to happen out loud and in writing, rather than getting settled by whoever carried the most standing in the room.
I'd temper that with what I can't claim. The framework outlasted my ownership of it, and I'd count that as the real signal. But I've never been able to draw a clean line from it to any team shipping measurably faster, and I'm skeptical of people who say they can.
It also makes growth more deliberate. Someone can work at a lower level of a capability, with review, without pretending to be an expert, or go deep on something outside their title without needing a role change to justify it. A manager can see where the team overlaps and where it's genuinely thin. That beats pretending everyone with the same title has the same strengths and the same appetite for autonomy.
One more thing, because it decides whether any of this survives contact with a real organization: the reward system. Ladders, promo packets, and comp bands are all indexed to roles, and people are very good at doing what the packet rewards. If the capability someone stretched into never shows up where their promotion gets decided, they'll stop stretching, and the model quietly reverts to planning by title with extra steps. You don't have to rebuild compensation to start. You do have to make sure promo criteria can see evidenced capability outside a role's home turf, and that managers actually write it down.
The shift will take a while
The obvious story about AI is that more people can now generate code, documents, and analysis. The more interesting effect is on the cost of learning a capability, contributing to one, and reviewing someone else's work in it.
Org charts aren't going to collapse tomorrow. Roles are durable, functions are useful, and ladders still matter, because organizations need structure to operate. The work underneath those structures is already changing, though.
The more AI makes activities easier to learn, assist, combine, and inspect, the less credible it becomes to treat a role as a complete description of what someone can do.
There's a version of this argument I should take head-on. Unbundling rarely stays unbundled. Music came apart into tracks and recombined into playlists, and capabilities that come apart will recombine too, around new seams. You can already see it in the product engineer title showing up at AI-native startups, where one person carries product judgment and implementation together. That's a new bundle rather than the absence of one. I don't expect large organizations to follow that curve quickly, and most of them shouldn't try. What I'd predict is narrower: today's bundles stop being the only defaults, and the organizations that read capability well will be the first to notice which new ones actually hold.
The old debate is too small. Asking whether PMs can code turns a system-level shift into a title fight. My guess is that in established organizations roles stay roughly where they are, and the gap between those roles and real capabilities just gets harder to ignore every year. Keep planning by title alone and you'll misread both the work and the people you have to do it.
The future of product development may not be fewer roles. It may just be fewer excuses to hide behind them.