The dentist appointment
Refinement day. Planning day. That is when your team schedules their dental appointments, their physicals, their kid's orthodontist consultations. Every errand they have been putting off for six months.
Slide 01
AI agents gave product managers the ability to build working proofs of concept. The twelve-page PRD, the estimation session, the refinement meeting everyone schedules their dentist appointment over — that translation layer between judgment and code is now overhead, not value.
Slide 02
Refinement day. Planning day. That is when your team schedules their dental appointments, their physicals, their kid's orthodontist consultations. Every errand they have been putting off for six months.
The two-hour session where someone argues a story is a five, not an eight. The scrum master says "let us split the difference." Nobody feels good about it. Industry data says the estimate was wrong anyway.
Open since 2023. Seventeen child stories. Four done, six blocked, seven nobody can explain anymore. The retro where someone writes "too many meetings" on a sticky note for the fourteenth consecutive sprint.
In twenty years of software, I have never once heard a developer say "I cannot wait for Thursday's refinement session." I have never heard a product manager say "writing acceptance criteria is the highlight of my week."
Nobody looks forward to this. Nobody ever did.
Slide 03
Decomposition. Estimation. Prioritization frameworks. Dependency tracking. Capacity planning. The backlog, the sprint, the acceptance criteria, the definition of ready, the definition of done. All of these artifacts exist because the cost of building software was high enough that you could not afford to build the wrong thing.
The feedback loop that used to take two sprints now takes two hours. The cost of building software dropped so far that the overhead of describing what to build now exceeds the cost of just building it and seeing if it is right.
Slide 04
Three to five days translating customer understanding into a twelve-page document with user flows, edge cases, acceptance criteria, and integration notes. $2,600 to $4,300 per feature at fully loaded PM cost.
Day one: trying to understand what the document actually means. Next two weeks: building what they think it describes. Comments, clarifications, "quick question" meetings in Slack and Jira.
Somewhere around sprint two, someone realizes the spec missed an edge case. More tickets, re-prioritize the backlog, wait for the next sprint. The customer feedback loop takes weeks.
Slide 05
Describe the feature the same way you would describe it to a new engineer. The agent writes code while the PM directs: "the user flow should go here first," "what happens when payment fails," "add a loading state." Forty-five minutes in, a working POC.
Build it in a morning, show it to a customer that afternoon. If it misses, tweak it with the agent and show the updated version the next day. No engineering time consumed. No sprint capacity allocated. No tickets filed.
By the time the engineering team sees it, the POC has been through three or four rounds of product thinking and customer validation. Engineers do not get a document to interpret. They get working software to harden.
The new conversation is "here, try it. Click this button. See what happens? That is what I want. Now make it real."
From documents that describe a bridge to an actual bridge
Slide 06
The customer feedback loop ran through the entire engineering organization. Weeks per iteration. Engineering capacity consumed on every pivot, every missed assumption, every "actually what I really need is this other thing."
Engineering only sees the version that customers have already confirmed they want. Every iteration happens between the PM and the agent. Zero engineering hours consumed on discovery. Zero sprint capacity allocated to validation.
Slide 07
Product manager fully loaded at $180K runs about $865 a day.
Three to five days writing a PRD. Before estimation meetings, refinement, Slack threads, and story writing workshops.
Multiply across 30 features a quarter. That is the cost of describing what you want to build before anyone writes a line of code.
All of that was a translation layer. The product manager had an idea of what the customer needed, and the spec was the mechanism for translating that idea into something an engineering team could execute on.
The spec existed because you could not hand a developer your vision. Now you can hand it to an agent.
Slide 08
Unit, integration, contract, end-to-end. The POC proves the idea works. The engineer proves it works under every condition.
Edge cases, failure modes, input validation, auth boundaries. A PM-built POC is never going to have these. That is not the point of the POC.
Logging, monitoring, schema migrations, performance under load. The production concerns that separate a prototype from a product.
Slide 09
Estimation was never accurate. Decades of data prove it. When a feature takes four hours to POC and two weeks to harden, the question changes from "how many sprints will this take" to "is this worth two weeks of engineering time." That is a better question. It is also a faster question.
When your backlog is a list of POCs waiting to be hardened, planning shifts from "how many story points fit in a sprint" to "which of these six POCs should we invest in this month." That is a product conversation, not a process conversation.
Dependencies still exist but they surface earlier. Working code reveals in day one that you need an API from the billing team instead of finding out in sprint two when a developer reads the acceptance criteria. The dependency was always there. The spec just hid it.
Instead of "Q3: payment processing overhaul, estimated 47 story points across 3 epics, subject to re-estimation after refinement" you get "Q3: we have three POCs that work. Here is the effort to harden each one. Which two do we fund?"
Slide 10
Backlog managers, scrum masters, agile coaches whose roles depend on the existence of the backlog. Process discipline that became its own constituency. Tooling vendors who convinced you the overhead was necessary.
When the unit of work changes from a story card to a POC, you do not need seven columns and four approval gates. You need visibility into three states: validated, hardening, shipped.
Slide 11
They need AI agent access and enough technical context. Some will take to it immediately. Some will resist because the PRD is their craft. Some will build bad POCs the same way they wrote bad PRDs — because the artifact was never the problem, the product thinking was.
Actually easier than it sounds. Most engineers would rather look at working code than read a twelve-page document. The hard part is the cultural shift from "tell me exactly what to build" to "show me roughly what you want and I will figure out the rest."
Scrum masters, agile coaches, backlog managers need to hear what their role looks like when the backlog is no longer the center of the workflow. Some will evolve. Some will need to find new work. You owe them that conversation early.
Slide 12
The PRD. The spec. The epic. The story card. The acceptance criteria document. The Jira workflow with seven columns and four approvers. The confluence page with the requirements matrix. The story writing workshop where eight people decompose a feature into cards so developers can spend the first hour of each card trying to understand what it means.