The product manager's job in the ADLC
When code stops being the constraint, the specification becomes it. That is a promotion for product management and a much less comfortable one than it sounds.
A product manager wrote a ticket that said “users should be able to filter the report by date range.” It was a perfectly normal ticket. It would have been a perfectly normal ticket in 2014. An agent picked it up and shipped it in about forty minutes.
What came back was a date range filter. It defaulted to the last seven days, which was wrong, because this particular report is used at month end. It did not persist across page loads, so anyone who clicked into a row and came back lost their selection. It allowed an end date before the start date and rendered an empty table with no explanation. And it filtered on the record creation date rather than the transaction date, which for this report are different by up to eleven days and are the entire reason the report exists.
Every one of those was in scope. None of them were in the ticket.
Here is the part that matters. If a human developer on that team had picked up the same ticket, none of those four things would have happened, and the developer would not have asked a single question. They would have known that the report is a month-end report because they sat next to the person who built it. They would have persisted the filter because that is what the other four filters in the product do. They would have caught the date inversion because they have been burned by it. They would have used the transaction date because of a conversation in a hallway two years ago that nobody wrote down.
The developer was not just implementing the ticket. They were silently completing it. Product management has been running on that subsidy for its entire existence, and the subsidy is being withdrawn.
The gap that was filled for free
Every ticket ever written has a gap between what it says and what it means. The gap is enormous. A two-sentence ticket routinely expands into forty decisions during implementation: what happens with no data, what happens with too much data, what the loading state looks like, whether the action is undoable, what gets logged, what happens on a slow network, what the thing is called in the interface.
Those decisions were made by whoever wrote the code, in their head, in real time, mostly correctly, and almost entirely invisibly. Nobody called it product work. It was product work. A senior engineer on a mature product is making dozens of product decisions a day and would be surprised to hear it described that way.
An agent makes those same forty decisions. It makes them from the literal text plus whatever context it has been given, with no institutional memory, no hallway conversations, and no scar tissue. It will not stop and ask, because from its point of view the ticket is unambiguous. Ambiguity is a property of the reader, and this reader resolves it instantly and confidently, every time, in whatever direction the words happen to point.
So the failure mode changes character. It used to be that a vague ticket produced a delay: the developer would come and ask. Now a vague ticket produces working software that is wrong, at speed, with tests passing. That is a substantially worse failure, because delay is visible and confident wrongness is not.
What a vague ticket used to cost
- A developer walks over and asks
- Half a day of delay
- The gap is closed in conversation
- Nothing is written down
- The cost is visible and small
What it costs now
- Nobody asks anything
- Working software in under an hour
- The gap is closed by guessing
- Tests pass against the wrong intent
- The cost is invisible until a user finds it
Specification is now the constraint
For thirty years the implicit model of product management was that specification is cheap and implementation is expensive. Everything about how the role is practised follows from that. Write the thin ticket, let engineering push back, iterate in review, discover the details during the build. It was rational. Why invest four hours precisely defining something when the people building it will spend four weeks and can figure it out along the way.
Invert the cost and the strategy inverts with it. If implementation takes an hour and specification takes four, the specification is the project. This is the single most important thing to internalise about the role, and most of the discomfort people feel is downstream of it.
It means the PM’s output changes shape. The artefact is no longer a persuasive document that gets a team moving. It is a precise description of a desired outcome that can be checked. Persuasion still matters upward and outward. But the thing you hand to the build process has to survive contact with a literal reader.
It also means the fun ratio changes, and I want to be honest about that. Writing the strategy narrative is enjoyable. Writing the fourteenth acceptance criterion about what happens when the date range spans a daylight saving transition is not enjoyable. The job now contains more of the second thing. People who came into product management to do vision work and delegate the details are going to find this a worse job, and they should know that in advance rather than discovering it over eighteen months.
The old skill was writing a ticket clear enough that a smart human would ask the right question. The new skill is writing one clear enough that a literal reader cannot go wrong. Those are not the same document, and the second one is longer.
What actually goes in the criteria
The obvious objection is that this is just waterfall with extra steps, and the objection is fair enough that it deserves a real answer.
The difference is scope, not depth. Waterfall specified everything up front, before any feedback existed, and then defended the specification against reality for eight months. What is required here is precise specification of one small increment, immediately before it is built, with the expectation that the next increment will be specified differently because of what you learn. The unit is still small. It is just no longer allowed to be vague.
In practice a criteria set that holds up has a few properties.
It states the observable outcome, not the implementation. “Selecting a date range filters the table to transactions whose transaction date falls inside it, inclusive of both endpoints” is checkable. “Add a date picker component” is a work instruction, and a work instruction cannot be verified, only performed.
It names the boundaries explicitly. Empty result, single result, maximum result, invalid input, unauthorised user. Roughly eighty percent of the wrongness I have seen from fast pipelines lives in exactly these five cases, and roughly none of them appear in a typical ticket.
It says which existing behaviour must not change. This is the one people skip. An agent optimises for the criteria in front of it and has no loyalty to anything else. If the report must remain exportable, and the export must keep the filter applied, say so, because otherwise you have no claim on it.
It encodes the domain fact that everyone knows. Transaction date, not creation date. Month end, not last seven days. These are not requirements in the classical sense, they are institutional knowledge, and they used to live in people’s heads because there was no cost to leaving them there. Now there is.
The throughput problem nobody warns you about
Here is the operational consequence that catches teams by surprise about a month in.
Discovery does not speed up. Talking to eight customers takes as long as it took. Getting a decision out of legal takes as long as it took. Watching how people actually use a workflow takes a fortnight of watching. Meanwhile the build side of the pipeline just got five to ten times faster.
The result is a starved pipeline with a very visible queue at the front of it. The engineering team is idle-ish and asking for work. The PM is now the bottleneck for the entire team, publicly, every day. That is an unpleasant position to be in and it produces two predictable bad responses.
The first is to lower the bar: push through thin tickets to keep the pipeline fed, which reintroduces confident wrongness at exactly the moment the volume is highest. The second is to expand scope to fill capacity: build things nobody asked for because there is capacity to build them. The second is more common and more expensive, and it is how products get bloated in a single quarter.
The honest response is neither. It is to accept that a team can now build considerably more than it can responsibly decide to build, and to treat deciding as the activity worth investing in. That means more people involved in specification, not fewer. It means engineers writing criteria alongside the PM rather than waiting for them. It means being comfortable with a team that is not saturated, which is culturally very difficult in organisations that measure utilisation.
What product managers should stop doing
Three things are worth actively dropping, because they were tributes to a cost structure that no longer exists.
Stop estimating in story points as a planning input. When build time was the dominant variable, estimating build time predicted delivery. It no longer does. The variance now sits in specification quality and review capacity. Estimating the cheap part with great ceremony while ignoring the expensive part is not planning, it is theatre.
Stop treating the backlog as an asset. A backlog of four hundred thin tickets was a store of value when writing tickets was a bottleneck. It is now a liability, because each thin ticket is a loaded gun: cheap enough to build on a whim and vague enough to build wrong. A shorter, sharper backlog is worth more than a long one.
Stop reporting progress in tickets closed. The number of tickets closed is now a measure of how fast the pipeline runs, which is roughly constant and roughly uninteresting. What changed is whether the closed thing was the right thing, and no ticket count contains that information.
Where this breaks down
Several honest limits, some of which undercut the argument above.
Not all products have crisp criteria available. If you are three people looking for a market, precision is premature and probably harmful. The right move at that stage is to build the wrong thing quickly and look at it, and heavy specification will slow you down for no benefit. Everything in this piece is aimed at products with real users, real consequences and real institutional knowledge to encode. Applying it to a prototype is cargo cult.
Design-led work resists this framing. “The onboarding should feel calm” is not a failure of rigour. It is a real requirement that decomposes into checkable statements only by losing most of its meaning. Teams that insist everything be machine-verifiable will systematically underinvest in exactly the qualities that differentiate a product, because those qualities are the hardest to phrase as criteria. I do not have a clean answer to this. The best I have seen is to keep the aesthetic judgement in a human review gate and be explicit that it is a judgement, rather than pretending it is a check.
Precision can be false confidence. A long criteria set feels rigorous. It can still specify the wrong outcome with beautiful clarity. Making the specification checkable improves the odds that you build what you described. It does nothing whatsoever to improve the odds that what you described is worth building, and the increased effort of writing it creates a sunk-cost attachment that makes people less willing to throw it away. That is a real risk and I have watched it happen.
Some of this work should not be the PM’s. I have written as though the PM authors all of it. In practice the domain facts often live with engineers, the boundary conditions often come from QA, and the “must not change” list is usually best written by whoever supports the thing. A PM who tries to author all of it alone becomes a worse bottleneck than the one described above. The role is closer to editor than author, and organisations that staff it as pure authorship will fail.
The takeaway
Product management has always been the practice of deciding what should exist. What changed is that the profession could previously get away with deciding at low resolution, because a talented human on the other end would finish the decision for free and nobody would ever notice.
That subsidy has been withdrawn. The specification is now the slowest and most valuable part of the pipeline, which is a promotion, and it comes with more detail work, more visible responsibility for being the constraint, and less of the pleasant delegation that made the job comfortable.
The one habit worth building first: for every ticket, write down the empty case, the invalid case and the thing that must not change. Three extra lines. It will catch more confident wrongness than any process change you could make this quarter.
The next piece looks one seat over, at engineering managers, and at why the job is drifting away from managing people’s output and toward designing the system that produces it.