Every Technical Role Is Now Product-Accountable

Writing Essay

Every Technical Role Is Now Product-Accountable

AI is lowering the cost of building software. That does not remove the need for architects, managers, or technical leads. It removes the excuse for any of them to stay distant from user value.

The most important thing AI is changing in software is not that code gets written faster. It is that the distance between technical work and product value is getting harder to justify.

For a long time, organizations could tolerate a separation between the people who decided what mattered and the people who built it. Product managers gathered context. Architects designed systems. Engineers implemented. Managers coordinated. In reality, those roles always overlapped, but the industry could afford the fiction because software creation was still expensive enough that specialization felt efficient.

That bargain is weakening.

When a single person can use AI to scaffold a feature, generate tests, draft docs, review patterns, and produce a reasonable first pass in minutes, execution gets cheaper. Once execution gets cheaper, the bottleneck moves. The scarce resource is no longer only implementation capacity. It becomes judgment: what should be built, for whom, in what sequence, with which trade-offs, and with what evidence that it is working.

That is why I think the strongest framing for technical work in the AI era is not that everyone becomes a product manager, and not even that everyone becomes a product engineer. The better framing is this: every technical role becomes product-accountable.

Building is getting cheaper

There is now enough research to say this without relying on hype.

In June 2025, Microsoft Research published results from three randomized field experiments across Microsoft, Accenture, and a Fortune 100 company. Across 4,867 developers, access to an AI coding assistant was associated with a 26.08% increase in completed tasks, with stronger gains among less experienced developers. That matters because it moves the discussion out of anecdotes and into measured productivity change.

Google’s September 23, 2025 DORA report points in the same direction at a broader industry level. Surveying nearly 5,000 technology professionals, DORA reported that 90% of software development professionals were using AI, more than 80% said it improved productivity, and 59% said it improved code quality. The significance is not only that AI use is widespread; it is that AI is becoming part of the default workflow across roles, not a niche edge case for early adopters.

Anthropic’s April 28, 2025 Economic Index on software development adds another useful signal. After analyzing 500,000 coding-related interactions across Claude.ai and Claude Code, Anthropic found that 79% of Claude Code conversations were automation rather than augmentation. It also found that many of the most common use cases involved UI, UX, and web application development. In plain language: AI is not just helping people think about software. It is increasingly doing significant portions of the work directly, especially in user-facing application layers.

If you step back, the pattern is clear. The cost of producing a first draft is falling. The cost of experimenting is falling. The cost of generating options is falling. This is a real shift, and organizations that pretend otherwise are mostly choosing to be slow.

But faster building is only one half of the story.

Cheaper execution does not automatically create value

The mistake I see most often in AI conversations is assuming that lower implementation cost automatically translates into better outcomes. The evidence does not support that.

McKinsey’s March 12, 2025 global survey found that 78% of organizations now use AI in at least one business function and 71% regularly use generative AI in at least one function. But the same study found that more than 80% of respondents reported no material enterprise-level EBIT impact from generative AI yet. The strongest link to financial value was not merely tool access. It was workflow redesign. And only 21% of organizations using gen AI said they had fundamentally redesigned at least some workflows.

That gap is the whole story.

AI can remove friction inside a task. It does not, by itself, redesign the system of work around the task. It can draft a feature spec, write the endpoint, and generate the test. It does not tell the organization whether the feature matters, whether the metrics are misleading, whether another team is building the same thing, or whether the problem should have been solved with a workflow change instead of software in the first place.

A 2025 NBER field experiment across 66 firms and 7,137 knowledge workers reinforces this point. Workers given access to a generative AI assistant spent less time on email and reduced after-hours work, but researchers did not find meaningful changes in the quantity or composition of work overall. That is a useful correction to both AI optimism and AI fear. AI is already valuable at reducing friction. It is not automatically transforming organizational behavior.

This is why I think product thinking becomes more important, not less, as AI improves. When shipping gets cheaper, shipping the wrong thing gets more dangerous. You arrive at the wrong destination faster.

DORA’s research on user-centricity captures this well. Teams that focus on the user have 40% higher organizational performance. That finding predates the latest wave of AI tooling, which is exactly why it matters. Faster tools do not change the need for a steering wheel. They increase it.

What “product-accountable” actually means

I do not mean that every role does the same job.

The architect still has to think in systems. The engineering manager still has to create clarity, prioritization, and accountability. The senior engineer still has to exercise technical judgment. The product manager still has a critical role in discovery, sequencing, and decision hygiene.

What changes is the acceptable distance from the user and from the outcome.

An architect can no longer justify a decision mainly on technical elegance if it slows learning, hardens the wrong assumptions, or makes iteration expensive. Architecture has to be evaluated partly by how well it supports product learning: reversibility, observability, safe rollout, and the ability to adapt once reality pushes back.

An engineering manager can no longer define success mainly as hitting delivery dates. In an AI-shaped environment, management quality increasingly shows up in whether the team is pointed at the right problem, whether feedback loops are tight, whether priorities are coherent, and whether higher execution speed is creating value or just more output.

A senior engineer can no longer hide behind implementation excellence alone. AI is compressing some of the traditional advantage of experience in writing first-pass code. What remains highly differentiated is problem framing, system judgment, context integration, and the ability to notice when a locally correct solution is globally wrong.

Even the product manager role becomes healthier under this framing. If product thinking is treated as the exclusive property of product managers, the rest of the organization disengages from customer value. Then product becomes a handoff function instead of a shared operating principle. A strong product manager should not monopolize product thinking. They should improve the quality of product thinking across the system.

Product-accountable does not mean same responsibilities. It means shared responsibility for value.

Why this shift is broader than software alone

This is not only a software workflow story. It is also a labor-market and capability story.

The World Economic Forum’s January 2025 Future of Jobs report found that 39% of workers’ core skills are expected to change by 2030. At the same time, employers still rank analytical thinking, along with resilience, flexibility, leadership, and social influence, among the most important capabilities. In other words, the skills becoming more valuable are not just tool-operation skills. They are interpretation, judgment, adaptation, and coordination skills.

Stanford’s 2025 “Future of Work with AI Agents” project makes the same point from another angle. Based on responses from 1,500 workers across 104 occupations, the researchers found that equal human-AI partnership was the dominant preferred model in 47 of 104 occupations. They also found that workers preferred higher levels of human agency on 47.5% of tasks than experts believed were technically necessary. That tells us something important: even when automation is technically possible, people still want human judgment, control, and accountability in the loop.

Microsoft’s April 23, 2025 Work Trend Index adds the organizational signal. Based on survey data from 31,000 workers across 31 countries, Microsoft reported that 82% of leaders saw 2025 as a pivotal year to rethink strategy and operations, and 81% expected agents to be moderately or extensively integrated into their AI strategy within 12 to 18 months.

Put these together and a pattern emerges. AI increases leverage, but it also increases the premium on the human parts of work that machines do not resolve cleanly: deciding what matters, coordinating across ambiguity, building trust, and making trade-offs legible.

The titles are not the point

I understand why many people reach for titles like Product Engineer right now. The title communicates something real: an engineer who is close to users, outcomes, experimentation, and business value is more useful than an engineer who treats implementation as an isolated craft.

But I do not think the industry needs to force every role into a single new label.

The more important change is conceptual, not cosmetic. The architect should be product-aware. The manager should be product-aware. The staff engineer should be product-aware. The platform team should understand its internal users the way a product team understands external customers. The security team should understand where controls create trust and where they create avoidable drag. The SRE function should understand user experience, not only incident mechanics.

The issue is not whether everyone has the word “product” in their title. The issue is whether anyone still believes their role exempts them from understanding the user, the business constraint, and the outcome.

That exemption is becoming harder to defend.

What organizations should do with this

If this argument is right, there are some practical implications.

  • Connect technical teams directly to user feedback. Product accountability is impossible when engineers only see tickets and never see user behavior, support pain, adoption patterns, or churn signals.
  • Evaluate architecture partly by learning speed. The best system is not only the one that scales. It is the one that helps the team discover quickly whether it is solving the right problem.
  • Reward outcome ownership, not just output volume. AI can increase output dramatically. That makes weak metrics even more dangerous.
  • Treat workflow redesign as leadership work. If AI only speeds up existing steps, the organization gets local efficiency. If leaders redesign how decisions are made and how work flows, the organization gets compounding value.
  • Keep human judgment at the right boundaries. The most expensive failures are often not syntax failures. They are priority failures, framing failures, and systems failures.

None of this is abstract. It is operating discipline.

The real shift

The tempting story is that AI flattens expertise and turns everyone into a generic builder. I think that story is too shallow.

What AI is really doing is compressing the value of routine implementation while increasing the value of judgment, context, prioritization, and product sense. It does not eliminate roles. It changes what good looks like inside them.

That is why I keep coming back to the same sentence:

Every technical role is now product-accountable.

Not because every role is the same. Not because architecture, management, leadership, and engineering collapse into one job. But because faster execution removes the excuse to stay distant from value. When the cost of building drops, the cost of poor direction rises.

In that environment, the question is no longer whether someone is “technical” or “product.” The question is whether they can use their function, whatever it is, to move the product and the business in the right direction.

That is the bar now.

Sources

Filed under ai systems , engineering leadership and product strategy .

If this connects with something you are building or untangling, reply by email — the subject line is already written.