Engineering Beyond Agile: Do we still need a PM in the Agentile Team?
Will the PM Job be "eaten for breakfast" by AI?
When we talk about AI Assisted Software Development or Agentile teams, we often start with engineering. With how code gets written, reviewed, and shipped when AI agents enter the flow. With fewer ceremonies, tighter loops, and a different relationship to speed. But there’s another shift happening in parallel — quieter, and often harder to name.
The role of the product manager is stretching.
Not because PMs are trying to claim more territory, but because Agentile teams remove the layer that used to absorb uncertainty. Someone has to carry the weight of decisions earlier than before.
The role was already changing. AI just removed the buffer.
Long before agentic workflows became a topic of conversation, product managers were already drifting away from the neat shape the role once had. Research from the last few years tells a consistent story: PMs spend most of their time navigating internal complexity rather than shaping products or talking to their customers.
More coordination. More interpretation, more translation. Less time with customers, less time thinking.
At the same time, AI has quietly become part of everyday product work. Most PMs now use AI in some form, most days. Yet if you look closely, it’s rarely where the leverage is highest. Drafting emails. Summarising meetings. Cleaning up documents. Helpful, but shallow.
The contradiction is subtle but important: the scope of the PM role is expanding, while the space to actually think is shrinking. Agentic Maturity isn’t the cause of this, but noticeably amplifying it.
When speed collapses cycles, decisions move upstream
In traditional product setups, many of the hardest decisions were delayed by process. Architecture could wait. Trade‑offs would surface later. Ambiguity could hide behind delivery milestones.
Agentile teams now remove that safety net. In spec-driven development – where currently a lot of organisations get a taste of the agentile future – this becomes apparent
When experimentation accelerates and feedback loops tighten, questions that used to appear at the end of a cycle now show up at the beginning. What are we optimising for? What constraints actually matter? Which risks are acceptable? What does “good” look like when outcomes are probabilistic rather than deterministic?
In practice, this shows up in small but telling ways.
A customer email turns into a potential feature discussion within hours, not weeks. A PM sketches a flow, tests assumptions, and produces a proposal — not as a slide deck, but as a concrete artefact engineers can reason about. An RFC appears before a backlog item ever does.
No code is written. But real decisions are already being made.
Increasingly, that someone is the product manager – not as a backlog owner, but as a kind of orchestrator. The person who connects intent, constraints, and consequence across a system that no longer moves in neat stages or a classic roadmap.
Product and engineering stop taking turns
One of the most noticeable effects of Agentile ways of working is how thin the line between “product” and “engineering” becomes. We are moving form a hand-off based way of working (like a relay race) to becoming outcome based. Not because the roles completely merge, but because the hand‑offs disappear.
Specifications begin to replace user stories as the primary interface. Constraints and non‑functional requirements stop being appendices and start becoming inputs. Architectural decisions are captured early – while they are still cheap to revisit.
In practice, this often looks like a PM working alongside engineers to refine a specification that includes not just what should happen, but under which conditions it should not. Capacity assumptions. Security boundaries. Cost implications. Failure modes.
Separating problem space from solution space no longer works when the system moves this quickly.
Engineers don’t wait for “final requirements”. PMs don’t wait for “technical feasibility”. They meet in the middle, earlier.
AI accelerates this convergence. When a PM can prototype flows, simulate scenarios, or explore trade‑offs without waiting for a full delivery cycle, the boundary between problem space and solution space becomes thinner – by necessity. The work becomes shared earlier – and that changes expectations on both sides.
This doesn’t turn PMs into full-time engineers necessarily (again, there’s no single truth). But it does raise the bar of technical literacy required to operate in fast‑moving systems.
AI doesn’t just help – it rearranges responsibility
There’s a tendency to talk about AI as a productivity layer. Something that helps you do the same job faster. This framing is a stubborn reminiscent of early marketing of GenAI products, and doesn’t do it justice. In reality, AI changes who does what – often without anyone explicitly deciding it should.
Today, it’s common to see product managers synthesising research at scale, generating mock‑ups, exploring data, drafting specifications, shaping narratives, and smoothing workflows. Not because the role description changed, but because waiting is no longer required.
AI makes this possible, but possibility without intent is where friction starts.
A PM records a customer conversation, feeds it into an agent, and within minutes has a structured summary, a set of hypotheses, and a draft problem statement. Another agent turns that into a spec. A preview environment makes it tangible enough to validate assumptions before anyone commits to implementation. Powerful or dangerous? AI makes this possible, but possibility without intent is where friction starts.
The risk isn’t that PMs become generalists who do everything. The real risk is that judgement – the part of the role that actually matters – gets crowded out by amplified noise. Agentile teams force a choice: either we design deliberately for where human judgement is essential, or we let speed decide for us.
One thing comes through clearly in both research and practice: while work can be delegated, accountability cannot. Product managers may ask AI to explore, draft, simulate, or synthesise – but they consistently pull decisions, trade‑offs, and ownership back to themselves. Not out of mistrust, but out of necessity.
A risk is that people stop knowing what the system has already done, which assumptions were applied, and where human judgment is still required. The outputs look reasonable, so the loss goes unnoticed – until it doesn’t.
In fast‑moving systems, accountability is the stabilising force. And delegating it, even subtly, is where things start to break.
The opportunity inside the chaos
When AI is embedded into product work thoughtfully, something interesting happens. Not more output – less waste. Less time spent reconstructing context. Less effort re‑explaining decisions. Less duplication of work across tools and meetings.
What emerges instead is space. Space to notice weak signals. Space to challenge assumptions earlier. Space to make trade‑offs explicit while they’re still cheap to reverse. This is where the Agentile product manager adds real value by deciding what can be delegated, and what must never be.
What really changes
Agentile Product Management isn’t about heroics. It’s about discipline and outcome-based engineering. Making decisions visible instead of rediscovering them. Codifying intent instead of relying on memory. Using AI to reduce noise, not amplify it. Treating speed as something to be shaped, not worshipped.
The PM of the future isn’t a feature shepherd, and they’re not an AI operator either. They are a sense‑maker: Someone who helps a system that’s moving faster than intuition alone can handle remain oriented, deliberate, and humane.”
This is the second article in my Agentile series. Read part one: