12 min read
I have a question for you. What do people enjoy more, sitting in traffic on their morning commute or backlog refinement?
The real answer is neither. The real answer is going to the dentist. Because if you have ever looked at your team’s calendar, that is when everyone schedules their dental appointments, their physicals, their kid’s orthodontist consultations, and every other errand they have been putting off for six months. Refinement day. Planning day. The two-hour estimation session where someone is going to argue that a story is a five, not an eight, and the scrum master is going to say “let us just split the difference” and nobody is going to feel good about it. That is when your team remembers they are overdue for a cleaning.
I have been in software for over twenty years. 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.” I have never seen an engineering director sit down at quarterly planning and think “this is the best use of the next three days of my life.” And I have definitely never seen a full team show up to grooming without at least one person sending a last-minute “sorry, dentist appointment, will catch up on the notes” message.
Nobody looks forward to story pointing either. Or the retro where someone writes “too many meetings” on a sticky note for the fourteenth consecutive sprint. Or the epic that has been open since 2023 and has seventeen child stories, four of which are done, six of which are blocked, and seven of which nobody can explain anymore.
These ceremonies exist because we needed them. I want to be clear about that before I go further, because the people who built these processes were not stupid. They were solving a real problem. When it takes a team of humans six to twelve weeks to turn a product idea into shipped software, you need a system to manage the work in progress. You need decomposition. You need estimation. You need prioritization frameworks and dependency tracking and capacity planning and all the rest of it. The backlog, the sprint, the story card, the acceptance criteria, the definition of ready, the definition of done (I wrote about those, they matter) — all of these artifacts exist because the cost of building software was high enough that you could not afford to build the wrong thing.
That cost just changed.
What happens when PMs build instead of write
Think about what a product manager actually does when they write a PRD (Product Requirements Document). They talk to customers. They synthesize the need. They understand the problem. And then they spend three to five days translating that understanding into a twelve-page document with user flows, edge cases, acceptance criteria, and integration notes. That document gets handed to engineering, who spends the first day trying to understand what the document actually means, and the next two weeks building what they think it describes. Somewhere around sprint two, someone realizes the spec missed an edge case, and the cycle of comments and clarifications and “quick question” meetings begins.
Now think about what happens when that same product manager sits down with an AI agent instead. They describe the feature the same way they would describe it to a new engineer on the team, and they start building. Not writing about building. Building. The agent writes the code while the PM directs: “no, the user flow should go here first,” “what happens when the payment fails,” “add a loading state, that transition is jarring.” Forty-five minutes in, they have a working POC (Proof of Concept). By lunch, it handles edge cases they had not even gotten to in their PRD yet because the agent asked about them.
That is not a hypothetical. That is what is happening right now in organizations I work with. Product managers who used to spend four days writing a document that describes what they want are now spending four hours building a thing that does what they want. I wrote about this velocity in One Hundred POCs a Day and it is not an exaggeration. And then they test it with a customer before engineering ever sees it.
The workflow is logical if you think about it for ten seconds. Talk to customers, understand the problem, build a POC with an AI agent, iterate on it, show it to another customer and ask “is this what you meant,” adjust based on what you hear, and when it is right, hand it to engineering. By the time the engineering team sees it, the POC has already been through three or four rounds of product thinking. It is not a sketch, it is a prototype that has been tested against real user expectations.
The engineers do not get a document to interpret. They get working software to harden. And I want to be clear about what “harden” means because it is not a polish pass. It is test coverage, error handling, security review, observability, schema migrations, performance under load, and all the production concerns that a PM-built POC is never going to have. The POC is a starting point, not a shortcut. But it is a starting point where the engineer can run the thing, click through it, read the code, and say “okay, I understand what we are building. Let me make this real.”
The old conversation was “let me explain what I want, let me answer your questions about what I mean, let me clarify the edge cases, let me update the story card when we realize I missed something.” That conversation took days, sometimes weeks, and generated dozens of comments in Jira and follow-up Slack threads. The new conversation is “here, try it. Click this button. See what happens? That is what I want. Now make it real.”
Now consider what this means for customer validation. In the old model, a product manager writes a spec, engineering builds it over several sprints, and then you put it in front of a customer and find out if you got it right. If you did not, you file more tickets, re-prioritize the backlog, and wait for the next sprint. The customer feedback loop runs through the entire engineering organization and takes weeks.
In the POC model, the product manager builds the thing in a morning, shows it to a customer that afternoon, and finds out immediately whether it solves the problem. If it does not, they tweak it with the agent and show the updated version the next day. No engineering time consumed, no sprint capacity allocated, no tickets filed. The product manager iterates directly with the customer until the thing is right, and only then does it reach an engineer’s screen.
That is the part nobody talks about when they discuss this shift. It is not just that specs are gone. It is that product managers can now validate ideas with real customers without consuming a single hour of engineering time. Every iteration, every pivot, every “actually what I really need is this other thing” conversation happens between the PM and the agent. Engineering only sees the version that customers have already confirmed they want.
The product managers I work with who have made this switch are shipping more features in less time, and the time they used to spend writing PRDs they now spend doing the thing product managers were always supposed to be doing, which is talking to actual customers. The story writing workshops, the estimation sessions, the refinement meetings that everyone scheduled their dentist appointments over, those are gone. And nobody misses them.
The artifact layer is the overhead
The answer is not that product managers are obsolete. I want to say that clearly because there is a version of this argument floating around Twitter that is reductive and wrong. Product managers who understand the customer, who know which problems are worth solving, who can prioritize ruthlessly, and who can say no to the VP’s pet feature, those people are more valuable than ever. The judgment is not going anywhere.
What is going away is the artifact layer between the judgment and the code. 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 spend a Tuesday afternoon decomposing a feature into cards so that developers can pick them up on Wednesday and spend the first hour of each card trying to understand what the card actually means.
Do the math on what that translation layer costs. A product manager fully loaded at $180K runs about $865 a day. Three to five days writing a PRD is $2,600 to $4,300 per feature, and that is before the estimation meetings, the refinement sessions, the follow-up Slack threads, and the two days of story writing workshops. Multiply across a portfolio of thirty features a quarter and you are spending $80,000 to $130,000 just on the ceremony 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 just hand a developer your vision and say “build this.” The developer needed structure, scope, and enough detail to estimate how long it would take. But you can hand an AI agent your vision and say “build this.” And if it builds the wrong thing, you look at it, say “no, not like that, like this,” and it rebuilds it. The feedback loop that used to take two sprints now takes two hours.
What about estimation and capacity
I know what the process people are thinking right now because I have been one of those people for most of my career. “What about estimation? How do you plan capacity? How does the business know when things will ship? What about dependencies? What about the roadmap?”
Estimation was never accurate. You know this. I know this. The industry has decades of data showing that software estimation is consistently wrong, and the ceremonies we built around it (pointing, planning poker, t-shirt sizing, the fibonacci debates) were coping mechanisms for the uncertainty, not solutions to it. When a feature takes four hours to POC and two weeks to harden for production, the estimation conversation 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.
Capacity planning changes too. When your backlog is not a list of story cards waiting to be estimated, but a list of POCs waiting to be hardened, the planning conversation shifts from “how many story points can we 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. That is where your product managers should have been spending their time all along.
Dependencies still exist but they surface earlier because the POC reveals them. When you have working code, you find out in the first day that you need an API from the billing team instead of finding out in sprint two when a developer reads the acceptance criteria and says “wait, we need what from billing?” The dependency was always there. The spec just hid it.
And the roadmap becomes more honest. Instead of “Q3: payment processing overhaul (estimated 47 story points across 3 epics and 12 stories, 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?”
The tooling question
The tooling question comes up a lot. “What about Jira? What about Linear? What about our entire workflow management system?”
I do not think those tools disappear entirely but I think their role shrinks considerably. 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 a list of POCs, who owns hardening each one, and whether it shipped. That is a spreadsheet. That is a Kanban board with three columns (POC, hardening, shipped). That is not a sixty-thousand-dollar-a-year enterprise workflow management system.
Could it be that we kept the tooling because the tooling vendors convinced us we needed it? Or because the process discipline around the tooling became its own constituency, with backlog managers and scrum masters and agile coaches whose roles depend on the existence of the backlog? Or is it simpler than that, and we just never stopped to ask whether the overhead was still justified?
Regardless of intent, where are the metrics that tie the economic investment in your workflow management process to the value delivered back to your organization?
(If that question sounds familiar, it should. I asked the same thing about code review last week.)
How to make the transition
I am not saying burn it all down on Monday. If you have a mature product organization that runs well, there is transition work here. Your product managers need to learn to build POCs, which means they need AI agent access and enough technical context to have productive conversations with the agent. Some of them will take to it immediately. Some will resist because the PRD is their craft and you are asking them to let go of it. And some, honestly, will build bad POCs the same way they wrote bad PRDs, because the artifact was never the problem, the product thinking was. AI does not fix bad judgment, it just makes it faster. You still need product managers who understand your customers. Be kind about that. Be patient with people genuinely trying to adapt. But kindness is not pretending the change is not happening.
Your engineering teams need to learn to work from POCs instead of specs. That is actually easier than it sounds because 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.” That requires more judgment from the engineer, not less. The engineers who thrive in this model are the ones who understand the product, not just the technology.
And your process people, your scrum masters, your agile coaches, your backlog managers, need to have an honest conversation about what their role looks like when the backlog is no longer the center of the engineering workflow. Some of them will evolve into something valuable (facilitation, delivery coordination, organizational improvement). Some of them will need to find new work. That is a hard conversation and you owe it to them to have it early rather than late.
The spec was the bridge. The POC replaced it.
I wrote about epics, stories, and features dying a while back. This is the other side of that argument. It is not just that the decomposition artifacts are obsolete. It is that the entire layer between “I know what the customer needs” and “here is working software” is compressing to the point where the artifacts in the middle are overhead, not value.
The product manager’s job is to know what to build. The engineer’s job is to make it production-ready. The spec was the bridge between those two jobs because neither could do the other’s work fast enough to skip it.
AI gave product managers the ability to build POCs. That is the bridge now. Not a document that describes a bridge. An actual bridge, rough and temporary, that the engineers then replace with something that will hold weight.
Nobody is going to miss backlog grooming, or the estimation debate, or the epic with seventeen child stories and no clear owner.
The product managers I work with stood in front of their teams and said “we do not write specs anymore.” Nobody in that room asked them to run a pilot first. Nobody asked for a working group. The engineers had already seen the POCs. They already knew this was better.
In closing I ask: if your product managers can hand your engineers working software instead of a twelve-page document, why are you still writing the document?
