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 twenty twenty-three and has seventeen child stories, four of which are done, six of which are blocked, and seven of which nobody can explain anymore.
Look. 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, and 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.
Consider what happens when product managers build instead of write. Think about what a product manager actually does when they write a Product Requirements Document, or P R D. 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 product manager 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 Proof of Concept, or P O C. By lunch, it handles edge cases they had not even gotten to in their P R D 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 P O Cs 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 P O C 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 P O C 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 product manager built P O C is never going to have. The P O C 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, and 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 P O C 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 conversation about needing something else happens between the product manager and the agent. Engineering only sees the version that customers have already confirmed they want.
Right. The product managers I work with who have made this switch are shipping more features in less time. The time they used to spend writing P R Ds 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, and the refinement meetings that everyone scheduled their dentist appointments over, those are gone. And nobody misses them.
Here is the thing. 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 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 vice president'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 P R D, the spec, the epic, the story card, the acceptance criteria document, the Jira workflow with seven columns and four approvers, and the confluence page with the requirements matrix. We are losing 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 one hundred eighty thousand dollars runs about eight hundred sixty-five dollars a day. Three to five days writing a P R D is twenty-six hundred to forty-three hundred dollars 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 eighty thousand to one hundred thirty thousand dollars 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.
So 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 were coping mechanisms for the uncertainty, not solutions to it. When a feature takes four hours to P O C 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 P O Cs waiting to be hardened, the planning conversation shifts from how many story points can we fit in a sprint to which of these six P O Cs 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 P O C 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 quarter three being defined by a payment processing overhaul estimated at forty-seven story points across three epics, subject to re-estimation, you get a simple choice. Quarter three, we have three P O Cs that work. Here is the effort to harden each one. Which two do we fund?
Then there is the tooling question. It 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 P O C, you do not need seven columns and four approval gates. You need a list of P O Cs, who owns hardening each one, and whether it shipped. That is a spreadsheet. That is a Kanban board with three columns: P O C, hardening, and 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.
Let us talk about 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 P O Cs, 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 P R D is their craft and you are asking them to let go of it. And some, honestly, will build bad P O Cs the same way they wrote bad P R Ds, 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 P O Cs 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, and 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 like facilitation, delivery coordination, or 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 P O C 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 knowing what the customer needs and having 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 P O Cs. 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 P O Cs. 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?