What do product roles become in future?

A large portion of my professional network is from my product tenure, so this question comes up almost daily. What is product in the age of AI?

Preamble

This debate is not theoretical. It affects real people in real jobs, and those jobs support families, mortgages, and whatever version of long-term security people are trying to build in an already pressurized economy.

That reality is exactly why I hesitated to write this. For months.

And it is personal for me. I still identify as a product person. I have led product teams I still feel deeply responsible for. So when I say I think these roles will materially change, I know that impacts people I care about, and quite possibly me, too.

Still, I would rather provoke and participate in a debate on this topic, versus watch it decided while I sit quietly on the sidelines.

Here is what I see, what I think, an important factor behind the change, an emergent way of working to pay attention to, and a sketch of a facilitation prompt I recommend for cross-functional leadership to help begin a productive conversation that shapes these tectonic shifts across organizational fabric as we currently know it.

What I see

At a dinner for product leaders a few months ago, Oji Udezue from Product Mind, the speaker for the dinner, was asked this question by the product leaders in attendance, "What will become of product roles in the age of AI?"

The responses were both spicy and immediate from the speaker and many members of the audience. My observation, given my background in large organizations, was something to the effect of, "Well, leadership in many companies are going to get territorial, close-minded, and reactive about this topic. And it will play out in most big tech (in a quiet, polite version) of departmental political warfare."

I am not implying, nor do I think that these leaders I am thinking of are bad (or stupid, or avoiding hard truths, or whatever other negative behavioral diagnosis someone would want to assign given how I said I think this plays out), rather I would recommend spending a moment and reading a rather brilliant book called Scarcity, by Sendhil Mullainathan, and Eldar Shafir. A read that has helped me reframe and sense-make many behavioral tics I see play out when this topic comes up in any organizations of scale. These behaviors are part of the observable cognitive impacts of scarcity. And I believe scarcity, and fear, are what is felt across the board when this topic comes up for leaders of any discipline, not just product.

What I think

I think product roles, as currently defined, will reduce, dissolve, and then reform. The timeline depends heavily on company type.

• AI-first startups (now to 12 months): This is already underway. In small AI-native teams with un-throttled access to strong coding tools, and low organizational barriers to the right context, product work is being redistributed in real time. Some product responsibilities are absorbed by technical builders. Some are picked up by non-traditional builders who now have execution access they didn’t have before.
• Mid-size software companies (1 to 3 years): Expect quieter signals first: reduced product hiring, frozen backfills, and strong product people self-selecting into AI-forward roles elsewhere. Titles may not change much at first. Headcount composition will.
• Big tech and slower enterprises (2 to 5+ years): Change will look incremental, then structural. Early phase: “AI-ify” existing operations (even the really shitty ones). Later phase: role boundary blur, likely design-product overlap first, followed by deeper org redesign. This is where scarcity politics will be most visible, as leaders fight to hold onto FTEs, even though everyone stays very polite offsite sessions leading up to it.

Most product professionals are in buckets two and three. So many people won’t feel this all at once. But “years” is no longer the cushion it used to be in technology adoption.

One of the factors behind the change

In software organizations, the core currency is engineering capacity.

Historically, product’s central business case was straightforward: protect that capacity from waste by improving the odds that the right things get built.

From that core, product work expanded: prioritization, stakeholder alignment, customer needs synthesis, sequencing, dependency negotiation, roadmap communication, and the endless artifact layer of decks, docs, tickets, and plans that keep a multi-team system coherent.

That model made sense when there was a hard tradeoff between two activities:

1. context - gathered in meetings
2. software building - outside the meetings

Product people served as human bridges between departments, between disconnected SaaS tools and siloed data, typically with that work being accomplished "in the room."

Organizations used that knob to dial up or down involvement from engineering to protect their time (since engineering time=capacity=customer value=revenue).

That binary is breaking.

And the economics of the product engineering system itself changing drastically.

As an engineer (or builder, you pick the word), in a mature AI agent harness you are building while you are talking in the meeting. As a builder your agents are building when you are reviewing roadmap insights gathered from sales calls, support tickets, customer satisfaction surveys, and research calls. It is no longer a binary for builders' time. Builders with agents can do both things, and when they do...the results are better. Builders that have the right context produce better outcomes.

Couple that with the measurable capacity within engineering systems leveraging mature AI harnesses and agent architecture is by an order of magnitudes greater then it has ever been before in industry history. And this is the slowest, and worst it will ever be.

Product, an entire discipline that exists because of a primary goal increasing the likelihood that the right things get built, is no longer relevant in the same way. And all the other jobs, in addition to protector of capacity, that the typical product person does to make the system work, are quietly altering. Organizational ways of working are changing.

Some reading this might not have seen this playing out, so here is an example:

Our team has seen versions of this at several companies over the last few months where AI engineering maturity is at least moderate and access to the best tools and good enough models is not throttled. We are talking about engineering organizations that have hit at least a 3+ across most of the engineering population (using Steve Yegge's AI engineering maturity scale for reference).

As engineering throughput rose, a predictable bottleneck appeared: the volume of “ready-to-build” work did not keep pace. Product teams could not scale backlog curation at the same rate that builders could now execute.

So builders stopped waiting.

They began pulling directly from customer request streams and emerging opportunities before traditional vetting cycles completed by product. Product teams then reacted with valid concerns: feature bloat, coherence drift, support burden, diluted focus, out of date docs, user confusion.

Both sides are seeing something real.

So the question is no longer “How do we force the old handoff model?” The question is: what operating model lets high-velocity building happen without sacrificing product quality?

So, what now?

I have strong views on what comes next for product, design, engineering, QA, support, technical writing, etc. But I don’t think this is usefully framed as a single-discipline problem.

This is a whole system redesign problem.

When execution economics change this fast, role boundaries blur, coordination costs move, and the organization needs a different operating rhythm, process, and tools. Teams that treat this as a headcount argument first miss the deeper shifts.

One pattern we would strongly emphasize (from having learned the hard way as a new company): asynchronous, low or as close as possible to zero latency information flow, that pushes relevant context and decisions to the people that need to know. Do not force people to constantly poll for updates across the everything soup of data and context, guessing at what might have happened, that they might need to care about.

Not better enterprise search juiced up with an LM on top. It's about better context, and better context delivery. If only retrieval improves, humans still need to know what to ask.

If your operating system can detect meaningful change and route it to the right person at the right time, you reclaim cognitive bandwidth, deeper thinking, fewer performative meetings. Better decisions are made.

And yes, you get a little JOMO (the joy of missing out), which we increasingly think of as a strategic advantage.

Something to try with your leadership team

At your next leadership offsite, run this as a multi-disciplinary exercise.

Ask people to work solo or in pairs.

Prompt: draw your company’s software-building system three years from now. Include roles/jobs-to-be-done, team structures, core tools, core processes, and how value, and how information moves through the system.

Then have the leader who convened the session present first.

To that leader: Go first. Be brave. Be willing to be wrong in public. Invite the group to reshape your own thinking. Invite the room to improve your draft before anyone presents their own.

That one move does more for psychological safety and quality of debate than most “innovation” workshops.

If you run it well, you won’t leave with perfect answers. You’ll leave with shared language, visible assumptions, and better strategic questions, and insight into which of the leaders around the table may be capable of re-authoring entire sections of your operations successfully.

Right now, that is the work.

Join the debate. Speak up in meetings where these decisions are being drafted in your organizations. We all deserve a say in imagining the next versions we will work in.

Our team is here to help facilitate your next leadership offsite, or if the fully scripted version of the activity above would be helpful, let us know. Happy to share.

‍