When execution gets cheaper, product judgement carries more weight.
TL;DR
AI-native companies are compressing the old software delivery model.
Engineers are speaking to customers and making product calls. Designers are generating multiple product directions before a review meeting begins. Account managers can ask an agent in Slack to remove an operational bottleneck that sat in a roadmap queue for months. Coding agents now sit inside the product systems teams already use to capture feedback, shape work, write code, and review changes.
The common reaction is to ask whether product managers are being replaced.
A better read is that the coordination-heavy PM role is losing its economic protection.
Product work still matters, but the durable parts are shifting towards context quality, decision rights, strategic constraints, taste, evidence loops, measurement, sequencing, and governance. Those responsibilities become more important when teams can build more things, faster, with less friction.
The central risk is no longer a lack of execution capacity. The risk is uncontrolled execution: every customer request becomes a candidate build, every edge case becomes a configuration, and every sales objection gets converted into product surface area.
AI does not remove the need for product judgement. It raises the cost of weak judgement.
The next product operator works closer to code, customers, agents, and commercial reality. They build first-pass artefacts, structure the context agents depend on, define what good output looks like, and protect the product from becoming a high-speed feature factory.
The handoff model has lost part of its economic logic
Traditional issue tracking came from a world where engineering time was the scarce resource.
A product manager gathered context, wrote a spec, translated the work into tickets, negotiated scope, waited for engineering capacity, clarified edge cases, checked the shipped result, then carried the learning into the next planning cycle.
The rituals around that model were not accidental. Prioritisation meetings, backlog grooming, delivery ceremonies, roadmap reviews, status updates, and escalation paths all helped companies route scarce implementation capacity through a set of human checkpoints.
Some of that process protected quality. A large share compensated for distance between the person holding the context and the person doing the work.
Agents reduce that distance.
A feature request that once needed product shaping, ticket writing, engineering allocation, QA, and follow-up can now become a working prototype inside the same afternoon. The prototype will not always be production-ready, but it is real enough to test, reject, sharpen, or hand to an engineer with evidence attached.
Role boundaries blur when the first version no longer requires a formal handoff.
Engineers talk to customers because they can try the fix quickly. Designers use AI to explore product directions before committing to a single branch. Commercial teams automate internal pain when product and engineering queues move too slowly. PMs with technical fluency can prototype workflows, inspect outputs, run small tests, and arrive at engineering conversations with something more useful than a document.
Accountability still needs a home. Production standards, security, architecture, data handling, and maintainability remain serious work. The shift is in the path from intent to artefact.
The first artefact no longer has to be a ticket.
Linear’s recent product launch is a signal
Linear’s “issue tracking is dead” argument lands because it describes how most software organisations still operate.
A PM scopes the work. Engineers pick it up later. The system fills with negotiation, prioritisation, workflow states, and process designed to bridge the gap between context and implementation.
Linear is now moving towards a shared product system that holds feedback, intent, decisions, plans, code context, automations, skills, and agents in one place.
That direction matters more than the launch copy.
The next product system is becoming an execution environment for humans and agents working from the same operating context.
An agent does not need a beautifully formatted ticket. It needs enough structured context to act without inventing the business.
Useful context includes customer evidence, product principles, technical constraints, commercial priorities, UX patterns, open decisions, known non-goals, and permission boundaries. Weak context produces plausible work that still misses the point.
A badly written ticket slows a human down. Bad context piped into an agent creates low-quality work at scale.
Product leadership moves into the design of that context and the review of what it produces.
Claude Code, Codex, OpenClaw, Hermes Agent, and the new work surface
The tools are changing too quickly for any serious operator to build an identity around one of them.
Claude Code reads a codebase, edits files, runs commands, and fits into development tools. Codex runs coding tasks in cloud sandboxes and can work across multiple tasks in parallel. Linear is putting agents, skills, automations, and soon code intelligence inside the product workspace. Wispr Flow turns spoken intent into usable written output across apps. Granola captures customer conversations and turns notes into product context. Personal-agent projects such as OpenClaw and Hermes Agent point at another surface: agents that sit closer to an individual operator’s recurring work, feeds, messages, research, and routines.
The names will change. The pattern matters.
Work is moving away from a single queue owned by a single function. Intent is being captured wherever it appears: Slack, Linear, terminal, meeting notes, customer calls, GitHub, personal agents, voice input, and internal tools.
Jensen Huang recently described agents as the “iPhone of tokens” on Lex Fridman’s podcast. The phrase is loose, but the implication is useful: agents turn model capability into an interface people actually use to get work done.
For product teams, that creates a new kind of sprawl.
Customer evidence sits in Granola notes. A PM dictates a rough brief through Wispr Flow. An engineer asks Claude Code to inspect the codebase. A founder asks Codex to explore a fix. Linear Agent clusters feedback and drafts work. A personal agent monitors feeds, pulls research, and proposes next actions.
The company gains speed only when those surfaces feed a coherent product system.
Without that system, every tool becomes another place where context leaks.
Execution abundance creates a sharper feature factory problem
AI-native teams do not struggle because they cannot build.
They struggle when the cost of building falls faster than the quality of product decision-making improves.
A customer asks for a workflow. Sales needs a blocker removed. Support wants a configuration. Finance wants a dashboard. Operations needs a shortcut. Each request sounds reasonable in isolation, and now each request can reach prototype form before the organisation has decided whether it deserves to exist.
That is how a product loses shape.
The backlog stops acting like a scarce queue and becomes a temptation engine. Loud customers acquire roadmap gravity. Edge cases turn into settings. Sales objections become near-term exceptions. Enough exceptions move the company away from product leverage and towards custom services disguised as software.
The old PM defended engineering capacity.
The modern product operator defends product coherence.
Those constraints need to appear inside the operating system, not as vague reminders during planning.
A few constraints belong in the product surface. Agents can configure approved primitives, generate variants within known patterns, or combine existing workflow blocks before they gain permission to create new application logic.
Decision rights need similar precision. Early-stage companies may route final product calls through one accountable founder or product lead. Larger teams need north-star metrics, strategy ladders, decision records, and escalation rules that stop each squad from optimising its own local patch of the product.
Evidence constraints keep speed honest. Teams should define what counts as signal before the prototype ships: activation, retained usage, support load, expansion revenue, margin impact, quality scores, latency, customer effort, or operational time removed.
Permission boundaries separate harmless agent work from risky change. A research synthesis can move quickly. A billing-flow change needs heavier review. A support macro deserves testing against real tickets. A migration script should never share the approval path of a copy variant.
Speed creates surface area. Product work decides which surface area deserves to become part of the company.
Product people now manage context, taste, and evidence
Jira ownership no longer protects a PM.
The valuable work is the quality of product decisions made before and after execution: which signal gets believed, which request gets rejected, which prototype earns engineering time, which trade-off protects the business, and which agent output is safe to use.
Three responsibilities sit at the centre of that shift.
1. Context architecture
Agents depend on explicit context because most organisational knowledge was never written for machines.
Customer calls sit in Granola notes, Slack threads, support tickets, product analytics, sales decks, research summaries, old issues, internal docs, and the heads of senior people. A strong PM can navigate that mess with memory, judgement, and follow-up conversations.
Agents need cleaner inputs.
Context architecture means deciding what gets captured, how it is structured, where it lives, who maintains it, and how agents are allowed to use it.
The raw materials are practical:
- Product principles that define the boundaries of the product.
- Customer evidence tagged by segment, revenue potential, workflow, frequency, and severity.
- Decision records that preserve the trade-off, not just the final answer.
- Non-goals that stop agents and teams from reopening settled questions.
- Technical constraints written plainly enough for commercial and product teams to use.
- UX patterns and copy rules that protect consistency across generated work.
- Metric definitions that stop every workflow from inventing its own success measure.
This work only looks like documentation from a distance.
Up close, it becomes the material agents use to act without dragging every decision back through a senior human.
2. Taste under abundance
Delivery cost used to hide weak taste.
Teams had to choose because they lacked capacity. AI removes enough friction that teams can generate ten flows, five positioning routes, and three prototype variants before lunch. The hard part becomes deciding which version deserves to survive contact with customers.
Product taste is applied judgement under constraint.
It combines customer truth, timing, commercial relevance, interaction quality, technical consequence, and the product’s existing shape. The metrics matter, but the dashboard arrives after the decision has already changed the user’s experience.
A workflow can show usage while making the product harder to explain. A configuration can close a deal while weakening the core model. A generated flow can satisfy the prompt and still push the company towards operational complexity.
Agent-generated work needs review from someone with a strong internal model of the product.
The review should test whether the work strengthens the core loop, reduces customer effort, protects future optionality, and increases strategic surface area in a way the business can support.
Prompt satisfaction is a low bar.
Product fit is the bar that matters.
3. Evidence loops
Faster execution has no value when learning stays slow.
A company that ships five times more experiments with weak measurement has multiplied noise. The evidence loop needs to be designed before the build begins.
A good loop defines the expected behaviour change, the tested segment, the minimum signal required, the failure mode to watch, the cost of serving the workflow, the quality threshold, and the decision that follows the test.
AI-powered workflows add another evaluation layer.
Product teams need golden sets, scored outputs, retry rules, regression checks, cost telemetry, latency budgets, human review points, and thresholds for when generated work is good enough to reach a customer.
The PM does not need to become the platform engineer.
They need enough technical fluency to define acceptable performance in operational terms.
A vague acceptance criterion becomes expensive when an agent can produce endless plausible output.
The next PM behaves more like an automation engineer
I argued last year that product managers are well placed to prototype, ship, and measure AI-supported automations.
That argument has aged well, but the toolchain has moved on.
The point is no longer that a PM can stitch together Zapier, n8n, Lovable, or v0 to prove an internal workflow. Those tools still matter, but the centre of gravity has moved towards agents that can read a codebase, modify files, generate pull requests, inspect logs, draft research, cluster feedback, and operate across a personal or company workspace.
Product managers already sit near the problem. They run discovery, shadow workflows, negotiate priorities, define success, manage stakeholders, and translate customer pain into product decisions.
The upgrade is build fluency.
A modern product operator should be able to create a first working version of an internal automation, agent workflow, lightweight interface, or evaluation harness without waiting for a full engineering cycle.
That does not turn the PM into a production engineer.
It changes the evidence brought into the room.
A credible operator can structure a JSON output, test prompts against a small golden set, inspect an API response, build a workflow in n8n, ask Claude Code to explore the relevant part of a repo, use Codex for a contained task, read logs, define retry logic, and explain why the system failed.
The first-pass artefact changes the engineering conversation.
Instead of asking senior engineers to interpret an abstract requirement from zero, the PM brings a prototype, early usage, known failure cases, cost estimates, risk notes, and a production brief.
Engineers then harden work that has earned investment.
That is a better use of technical talent than treating engineers as the first stop for every unproven idea.
The team model needs cleaner responsibility boundaries
AI-native teams need fewer rituals around handoffs and more discipline around ownership.
The product operator owns intent, evidence, economics, sequencing, and coherence.
That includes the customer problem, commercial rationale, success metric, constraints, non-goals, rollout path, and review criteria. They decide which work deserves agent acceleration, which work needs senior human judgement, and which requests should be killed early.
The engineer owns production quality, architecture, security, maintainability, and technical leverage.
Their work includes reviewing generated code, shaping interfaces, protecting the system from brittle automation, setting architectural boundaries, and deciding when a prototype becomes real software.
The designer owns interaction quality, product language, usability, and the integrity of the customer experience.
AI gives them more directions to inspect. Taste collapses that expanded option set into a product experience a customer can understand.
The agent handles procedural expansion: drafting, searching, clustering, generating variants, proposing plans, writing first-pass code, updating issues, analysing feedback, creating QA scenarios, and running repetitive checks.
The operating model works when each actor has the right context, permissions, and definition of good.
The product leader’s job is to make that system legible.
Discovery becomes wider, then more selective
AI-native companies can simulate customers, generate research summaries, run more interview analysis, and explore more solution variants in less time.
That creates a real advantage when the team treats AI as a force multiplier for discovery rather than a substitute for customer truth.
Synthetic customers can pressure-test assumptions, generate edge cases, expose weak language, and prepare a team for real conversations. They cannot reproduce the emotional weight of a buyer with a budget, an internal politics problem, and an operational consequence for choosing badly.
The product team should use AI to widen the discovery aperture.
Human judgement decides which signals deserve belief.
That requires discipline around customer quality. Fifty interviews from the wrong segment produce false confidence. Three painful conversations with the buyer who owns the budget can change the strategy.
Research volume is a vanity metric when it does not improve the next product decision.
Skills become organisational memory
Linear’s “Skills” framing points at a pattern every AI-native company will need.
When a workflow works, codify it.
A good skill is more than a saved prompt. It is a reusable operating procedure with inputs, context sources, rules, examples, output format, quality checks, escalation points, and ownership.
Product teams should create skills for repeated judgement work:
- Cluster customer feedback into opportunities with segment, revenue, and workflow context attached.
- Draft a product brief from calls, tickets, analytics, and current strategy.
- Generate an experiment plan with success metrics, guardrails, and stop conditions.
- Review a feature idea against product principles, technical constraints, and commercial priorities.
- Turn shipped changes into release notes, support guidance, and sales enablement.
- Analyse failed workflows and propose fixes with evidence.
- Produce QA scenarios from acceptance criteria, known failure modes, and historic bugs.
The compounding advantage comes from turning good judgement into repeatable infrastructure.
A backlog stores pending work.
A skill stores a way of working.
Hiring product people now requires a harsher filter
Companies still hiring PMs to manage process are hiring for yesterday’s bottleneck.
The better hiring question is simple: can this person improve the rate and quality of learning when execution is increasingly cheap?
A stronger interview loop should give the candidate messy customer feedback, a thin product strategy, a rough dataset, a technical constraint, and access to AI tools.
Ask for four artefacts:
- A product judgement: what to build, what to ignore, and why.
- A first-pass prototype, automation, analysis, or evaluation harness.
- An evidence plan with success metrics, failure thresholds, and rollout logic.
- A production brief that an engineer would respect.
That exercise reveals the useful signals quickly.
Can they think commercially? Can they use AI tools without losing judgement? Can they reason through ambiguity? Can they protect product coherence? Can they convert signal into action?
The strongest candidates will not hide behind a narrow reading of the PM title.
They will understand where their technical boundary sits, then operate right up to it.
“Builder” only works when accountability stays sharp
Some companies are replacing titles like SWE, PM, and designer with “Builder”. The instinct makes sense because the tools have made the work more fluid.
PMs build prototypes. Engineers write strategy documents. Designers generate production-ready UI directions. Operators automate their own workflows. Commercial teams use agents to remove bottlenecks without waiting for roadmap approval.
A broad title becomes dangerous when it blurs accountability.
A company still needs clear ownership for product coherence: the customer segment that matters, the requests that damage the product, the workflows that deserve automation, the agent outputs that require review, the metrics that define success, and the ideas that should die after early evidence arrives.
Call that person a PM, product operator, product lead, founder, GM, or builder.
The title matters less than the responsibility.
When more people can build, the company needs stronger judgement about what reaches the product.
The CPO mandate is now operating-system design
For product leaders, the practical mandate has moved beyond tool adoption.
The question is whether the organisation has been redesigned around the speed those tools create.
That requires fewer ceremonies built around handoffs, stronger context systems, clearer decision rights, sharper product principles, better evaluation infrastructure, and tighter feedback loops between customer reality and implementation.
The CPO should inspect the operating system with direct questions:
- Where does customer context live, and can agents use it safely?
- Which product decisions still sit inside recurring meetings?
- Which workflows deserve reusable skills?
- Where is the team shipping faster without learning faster?
- Which agent outputs reach customers without sufficient review?
- Which PMs can build first-pass artefacts rather than only describe them?
- Which metrics protect commercial quality rather than feature throughput?
- What permission boundaries separate low-risk agent work from production-impacting change?
The answers determine whether AI creates leverage or operational mess.
Product management is becoming less forgiving
The weak version of product management was always exposed.
Status reporting, ticket translation, backlog grooming, stakeholder buffering, and meeting-heavy coordination were never strong foundations for a durable role.
AI removes the protective friction around that work.
The stronger version of product management becomes more valuable because the surrounding system now moves faster than most organisations can absorb.
Customer pain still needs to become strategy. Coherence still needs defending. Agents still need constraints. Fast builds still need judgement. Commercial impact still needs measurement. Teams still need someone capable of connecting the customer, the system, and the business model.
The future product leader is a builder-strategist with enough technical fluency to prototype, enough commercial judgement to prioritise, enough taste to protect the product, and enough systems thinking to make humans and agents work from shared context.
That role is now harder to fake.
The poolside TikTok era of big-company product management was always going to meet a harder market. AI has simply accelerated the correction.
The next cycle should reward the operators who can turn customer signal into working systems at speed, and protect the product from becoming a pile of fast-moving requests.