The AI-era role debate is asking the wrong question.
Most of the conversation sounds something like this: can product managers code now? Can designers build features? Can operators write SQL? Can marketers make their own tools? Can "non-engineers" do engineering work?
Those are interesting questions. They are also too narrow.
The bigger shift is not that one function can suddenly borrow work from another function. The bigger shift is that AI is making many of the activities inside product development more visible, more learnable, more modular, and more transferable.
Product managers can prototype faster. Engineers can explore product and customer tradeoffs more directly. Designers can get closer to implementation. Data, research, marketing, security, support, and operations teams can create tools and workflows that once required longer chains of handoffs. Technical program managers can pull more threads together because more of the underlying work is legible.
The shift is not one-way. It is multi-directional.
Roles are bundles of capabilities. AI is starting to unbundle them.
Roles are useful, but they are still shortcuts
Roles exist for good reasons. Companies need them for hiring, compensation, performance management, career development, planning, and communication. 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.
But roles are still shortcuts.
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.
A product manager may be excellent at strategy, prioritization, stakeholder alignment, and executive narrative while also being able to build a rough prototype or make a constrained product change. Another product manager may be just as valuable while having no interest in implementation. An engineer may be deeply technical and also strong in product judgment, design systems, or customer empathy. Another engineer may create enormous value by staying focused on architecture, reliability, and execution. A designer may be strong in interaction design and research synthesis while also being able to write crisp requirements or build a working concept.
People are spiky. Roles flatten them.
This was already true before AI. AI just makes it much harder to ignore.
We keep confusing roles with capabilities
When people ask whether product managers can code, whether engineers can do product work, or whether designers can do research, they are usually mixing together several different questions:
Capability. Context. Evidence. Review. Outcome ownership. Standards.
Those should not all collapse into "what is this person's title?"
Take technical implementation as an example. Someone might be able to understand technical tradeoffs, edit a small piece of existing code, build a prototype, ship production code in a low-risk area, review someone else's code, design architecture, or approve a security-sensitive change. Those are not the same capability level.
The same is true for product strategy, design, analytics, research, security, accessibility, launch planning, stakeholder communication, and most other areas of product development.
The better model is simple: individuals have capability profiles, and workstreams have capability needs.
An individual capability profile describes what a person can do, at what level, based on what evidence, with what capacity, and with what growth interest. A workstream capability map describes what the work requires, at what depth, based on scope, risk, complexity, and the expected outcome.
That changes the planning conversation.
Instead of asking only, "Which functions need to be assigned?" teams can ask, "What capabilities does this workstream require, at what level, and who can responsibly provide them?"
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." It can become a permission slip to push people into work they are not good at, do not want to do, or cannot responsibly own. It can become a way for leaders to ignore craft expertise because the AI-generated output looks polished enough in a meeting.
That is not the point.
If anything, AI should make review, standards, and accountability more important. Not less.
Straker wrote in AI is great, but the slop problem is real that the useful question is not whether AI made an individual faster, but whether it improved organizational efficiency. The same test applies here. If capability unbundling just creates more low-quality work for other people to inspect, clarify, redo, or reject, then congratulations, you did not improve the system. 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 most important word in the previous sentence is "evidenced."
Capability should not be based only on self-description, vibes, title, or enthusiasm. Evidence can come from demonstrated work, manager assessment, peer attestation, senior expert review, artifact review, structured exercises, or formal certification for high-risk capabilities.
Not every capability needs a certification path. In fact, most probably should not. If every level of every capability requires a formal process, the model becomes bureaucracy with better vocabulary.
But some work absolutely should require stronger validation before someone acts independently. Customer data handling. Security-sensitive implementation. Accessibility signoff. High-risk release approval. Production-critical code review. These are not places where "the AI seemed confident" should get anyone across the finish line.
The point of validation should not be badges. The point should be trust.
If someone is validated at the right level for a capability, that should affect what they can do independently, what requires review, who can review others, and eventually what permissions make sense in systems like code repositories, release tools, design systems, analytics platforms, or production workflows.
This is where the conversation gets more interesting than "can PMs code?"
A product manager might be perfectly capable of building a prototype and still need engineering review before production. A designer might be capable of implementing a design-system-compliant component and still need accessibility review. An engineer might be capable of making product tradeoff recommendations and still need product review on customer impact. A support leader might be able to identify and automate a workflow pattern and still need security or privacy review before connecting it to customer data.
That is not failure. That is healthy capability-based work.
Outcome ownership is not the same as doing all the work
Every meaningful workstream still needs someone accountable for the outcome.
That person may do much of the work directly. They may do almost none of it directly. Both can be valid.
The important distinction is that outcome ownership and activity execution are not the same thing. One person can own the outcome while another performs implementation, another reviews the work, another defines the standard, and another validates whether the work meets the bar.
This is already how many high-functioning teams operate. We just do not always describe it clearly.
Capability-based work only works if accountability gets sharper. Flexible contribution cannot mean fuzzy ownership.
This connects to Straker's writing on the consolidation of PM roles and the TPM triangle. The valuable people in product development are rarely valuable because they fit a title cleanly. They are valuable because they can pull together product judgment, execution, technical depth, process, communication, and organizational context in service of an outcome.
AI does not remove the need for that interdisciplinary leadership. It raises the ceiling on how many activities a capable person can contribute to, while raising the importance of knowing where their contribution needs review.
Functions may become stewards of craft
So what happens to functions?
They still matter.
Engineering still needs technical standards, architecture judgment, operational discipline, and review patterns. Design still needs critique, interaction quality, visual systems, and accessibility expertise. Product still needs strategy, prioritization, discovery, and outcome discipline. Data, research, security, privacy, marketing, support, and operations all have real craft that should not be flattened into "anyone with a prompt can do this now."
The shift is that functions may become less important as exclusive containers for who is allowed to do work, and more important as stewards of craft.
The community of people developing or exercising a capability may become broader than the formal function that historically owned it. A design capability may be practiced by designers, product managers, engineers, or researchers at different depths. A technical implementation capability may be practiced by engineers and by some non-engineers, again at different depths. A product strategy capability may be practiced by PMs, TPMs, designers, engineers, data scientists, or operators.
The function or guild still helps define what good looks like. It supports learning paths. It creates examples. It reviews work. It validates higher-risk capability levels. It protects the craft from becoming slop.
That sounds less like territorial ownership and more like stewardship.
This also rhymes with Straker's discussion of matrix vs. integrated teams. The important question is not only where someone reports. It is where standards live, where accountability lives, and how work actually gets done across disciplines.
What leaders should do differently
This does not require a giant transformation program to be useful. The starting point is much smaller.
In planning, ask:
- What outcome is this workstream accountable for?
- What capabilities does the work require?
- What level of each capability is needed, given the scope and risk?
- Who has evidence of those capabilities?
- Who has capacity?
- Who wants to grow into part of the work?
- What requires review?
- Who is accountable for that outcome?
That is a better planning conversation than "Do we have a PM, designer, and engineer assigned?"
Sometimes the answer will still be yes, you need a product manager, designer, engineer, researcher, data scientist, security reviewer, and launch owner. Great. This model does not say otherwise.
It simply makes the work more explicit.
It also makes growth more intentional. Someone can contribute to a capability at a lower level, with review, without pretending they are already an expert. Someone can deepen a capability that sits outside their title without requiring a role change. Managers can see where the team has too much overlap, where it has real gaps, and where a stretch assignment is reasonable if paired with the right reviewer.
That is much healthier than pretending every person with the same title has the same strengths, gaps, interests, and autonomy.
The shift will not happen overnight
AI is changing product development, but not only because it lets more people generate code, documents, designs, or analysis.
It is changing the cost of learning, contributing, reviewing, and combining capabilities.
This does not mean org charts collapse tomorrow. Roles are durable. Functions are useful. Levels, ladders, and reporting lines still matter because organizations need structure to operate.
But the work underneath those structures is already changing. 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.
The old role debate is too small. The question is not whether product managers can code, whether engineers can design, or whether designers can do product work. Those questions turn a system-level shift into a title fight.
AI will not make roles irrelevant. It will make the gaps between roles and actual capabilities harder to ignore.
Organizations that keep planning by title alone will misread both the work and the people available to do it. Organizations that learn to see capabilities clearly will have more ways to use expertise, grow people, protect standards, and move faster without pretending that review and accountability no longer matter.
The future of product development may not be fewer roles.
It may be fewer excuses for organizations to hide behind them.