# Product management in an agentic SDLC

Status: gap. Owner: Andrew Flett. Last reviewed: 2026-09-10.
Canonical: https://agentic.madebymany.com/positions/product-management-in-an-agentic-sdlc

Agile's ceremonies existed to coordinate and price scarce build capacity. Build capacity is no longer the scarce thing, so most of them no longer pay for themselves, and what is left of product management is the part that was always the hard part: deciding what to build, and finding out quickly that you were wrong.

This is not an argument against agile's principles. Working software over documentation, responding to change over following a plan, a build that answers the question rather than a document that describes it: an agentic lifecycle meets those tests more often than the fortnightly ritual that claimed them. What went is the ceremony, and each one went for the same reason, which is that the constraint it managed collapsed.

## What went, and why

Each of these managed a constraint. They did not stop being useful because they were disliked. They stopped being useful because the thing they were built to handle is no longer true.

### Stand-ups

They existed to sync people whose work was serialised through each other. When a change takes an hour rather than a week, the sync is stale before the meeting ends.

### Estimation

Estimates priced scarce build capacity. Build capacity is no longer the scarce thing; judgement about what to build is, and estimating that was never what the ritual did.

### Planning as ceremony

A spec written to be proved wrong by the build, and revised, does the same job continuously and more honestly than a planning session does fortnightly.

### Retrospectives

A retrospective is periodic, so it happens weeks after the event when the detail has gone. It is expensive, because it costs a room of people an hour. And its output is disconnected from the thing it should change: a list of actions with no owner and no destination, which is why so few of them ever landed. Everyone involved knew this. The meeting continued anyway, because there was nothing else. There is now, and it runs continuously rather than fortnightly.

## What replaces them

The spec does most of it. An intent becomes a spec covering the problem, the scope, the riskiest assumptions and what success would look like, and it is written to be proved wrong by the build and revised. That is a planning session that runs continuously, and it is more honest than one that runs fortnightly, because the build is what corrects it.

The gates do the rest. Formatting, types, tests, accessibility, visual regression and performance budgets fire on every commit and every pull request, so quality is not a thing anyone has to remember to ask about in a meeting. Who reviews, who signs off and what is recorded is [a principle of its own](/principles/governance-is-how-the-work-is-made).

## What we track, and where

Tracking is a decision about audience, not about tooling. On a prototype, GitHub Issues: the work and the tracker are in one place and nobody outside the team needs to see it. On client production work it biases hard to Linear, because the client is in the tracker too, and an in-repo checklist stops being shareable the moment it has an audience.

That is deliberately conditional rather than a default, because a default that ignores the kind of engagement is wrong about half the time.

## Still to write

This position is a stub with the material that already existed moved into it. What is outstanding is the substance: what a product manager's week actually looks like now, what happens to roadmaps and to release planning, how a client is kept close when there is no fortnightly ceremony to hold them, and what breaks when a team tries this without changing how it is measured.