What Changes for Product Managers

If engineering capacity stops being the primary constraint, the role that existed largely to allocate it changes shape. Not in the direction most predictions suggest.

What the role was partly about

Deciding what engineers work on, because engineering time was expensive and scarce. Prioritization, sequencing, scope negotiation, and saying no — all downstream of a capacity constraint.

Relax that constraint and the allocation problem shrinks. What's left is a different job that was always in there and often crowded out.

What gets more important

Deciding what's worth building at all. Cheaper building means more gets attempted, including things that shouldn't. ⚠️ The discipline of saying no becomes more necessary when the cost argument no longer does the saying for you. A lot of prioritization was effectively free because everything couldn't be built; now the reason has to be an actual judgment.

Specification precision. As the constraint moves to well-specified work, producing precise, unambiguous requirements becomes the direct bottleneck. This is a craft skill and it's now closer to the centre of the role than the prioritization spreadsheet.

Knowing what users actually do. The scarce input agents lack most completely. A PM's genuine advantage is proximity to users, and it becomes the differentiating one.

Maintenance cost judgment. Every shipped thing is carried forever. Build cost fell; maintenance didn't. Someone has to weigh lifetime cost against value, and it's a product judgment rather than an engineering one.

Defining what correct means. For agent-based features, someone has to specify acceptable behavior — which failures are tolerable, when the system should decline, what the quality bar is. That's a product decision that arrives looking like a technical one.

What gets less important

Rationing engineering capacity. The core of a lot of the job, and it shrinks.

Detailed sequencing. When implementation is fast, elaborate ordering matters less than it did.

Being the translation layer. Some of the PM role was converting business intent into engineering-legible requirements. That conversion is exactly what tooling assists well, and being purely a translator is the exposed portion.

💡 The uncomfortable part

If a PM's value was primarily allocation and translation, that's the exposed part. If it was knowing users, judging what matters, and specifying precisely, it's appreciating.

Same split as everywhere: production versus judgment. It just lands on a role that assumed it was already on the judgment side.

✅ The concrete shifts

• Write specifications precise enough to implement without follow-up questions. Notice how much you had to decide. That deciding is the job.
• Spend more time with users, less in prioritization meetings. The ratio should move.
• Include lifetime cost in every build decision, explicitly.
• Define acceptable failure for anything agent-based, before it's built.
• Raise the bar on what gets built, since the cost argument no longer holds it.
• Follow up on outcomes. Whether shipped things did what was intended — the habit that calibrates judgment, and the one most consistently skipped.

The takeaway

Cheaper engineering shrinks the allocation and translation halves of product management and expands specification, user knowledge, lifetime-cost judgment, and defining what correct means. The uncomfortable version: a role that assumed it was already on the judgment side has its own production half, and it's the part getting assisted. Write the precise specifications, spend the time with users, and raise the bar on what's worth building — because nothing else is holding it now.