As models improve, it’s becoming common for complex features that once took weeks or months to be built in days, and sometimes in hours. That doesn’t make product leadership easier. It moves the hard part from “can we build it” to “should we, does it fit, and can our customers absorb it,” and it asks a team built for the old pace to work a new way without anyone feeling left behind.
For twenty years, the slow part of software was building it. Product teams wrote detailed requirements because engineering time was scarce, and every sprint had to count. Most of our rituals, from grooming and pointing to three-week sprints, exist to ration that scarcity.
That scarcity is easing. When a working feature takes days instead of a quarter, the rituals built to ration engineering time start rationing the wrong thing. The new scarce resources are judgment about what to build, the coherence of the product, and the customer’s capacity to absorb change.
I lead product in regulated software, where every release carries validation, training and trust costs. I build with coding agents like Claude Code every day, and I see the gap between what’s now possible and how most teams still work. This is my attempt to describe the job on the other side of that gap, including the parts that are uncomfortable.
The ideaKeep the purpose; change the method. Use agents to see far more. Tie every feature to a stated outcome. When requirements leave a gap, trust the team to decide in line with the product’s goals and share the reasoning. Make quality a shared, automated bar. Write every decision into skills so no one has to learn it twice. And govern how much change customers get, not just how fast we can make it.
Before anything about speed, the part that stays fixed. These were true before AI and they’re the only things that keep a fast team from becoming a fast feature factory.
Switch between how each tenet was practiced and how it’s practiced now.
Competitive analysis used to be a person reading a handful of competitors’ sites and release notes when they had a free afternoon. User feedback was a sample. Stakeholder requests lived in inboxes. Now agents can read competitors’ products, help centers, demo videos, reviews and press every day, across dozens of companies, and hand a leader a deep report each morning.
That changes what a product leader is responsible for. It’s no longer “did we look.” It’s “did we notice what mattered, and did it change what we build.”
Illustrative numbers for a mid-size software product, to show the order of magnitude. Your own will differ.
When so much more can be built so quickly, the biggest risk is building everything. Each feature looks reasonable on its own. Together they turn a product into a drawer of gadgets. The defense isn’t a slower team; it’s a visible line from every feature to an outcome the company has chosen.
A company goal, the outcomes that serve it, and the bets behind each outcome. Propose a feature below and see where it lands.
The question isn’t “can we ship it this week.” It’s “which branch does it grow on, and would a customer feel it as part of one product?”
The roadmap changes shape too. Quarterly lists of features go stale in days. What holds is a short set of outcomes and bets that the whole company can see, with the features underneath treated as experiments that can be added, changed or removed quickly. Feedback on the roadmap can come in the same way: a living page, reviewed weekly, with the evidence for each bet attached.
The old path is a relay. A product manager writes a spec, a designer draws each screen, engineering rebuilds the prototype from scratch, QA tests it, and the whole thing waits for the next sprint. The new path is one piece of work. A product manager builds with a coding agent such as Claude Code, using the design team’s skills and the engineering team’s standards, on a branch that engineers review. The prototype is the code.
The same small feature, a new filter on a busy list screen, with typical elapsed time on one shared scale. Press play.
Illustrative. The new path assumes design and engineering standards are already encoded as skills, and automated tests are part of every change.
Notice what the new path still has: a review by an engineer, automated tests, a feature flag, and customers. Speed comes from removing handoffs and rebuilds, not from removing care.
“Product managers write the code” sounds reckless until you see the steps. The product manager builds; engineering and QA still review what matters; customers see it earlier. Here is one feature, end to end, with the handoffs marked.
Who does each step, how long it usually takes, which shared skills the agent applies, and where the work passes to someone else.
When building costs so much less, “good enough” stops being a trade-off and becomes a choice. There’s very little excuse left for shipping anything less than the best version we can imagine.
The most important tactical change is the least visible. Every decision the team makes, about the customer, the design, the code, the domain or the quality bar, gets written into skills that the team’s coding agents apply to every future feature. Correct something once, and it stays corrected.
That turns a familiar frustration into a process failure. If someone has to ask “didn’t we already agree on this?”, the fix isn’t another review comment. It’s updating the skill so the question never comes up again.
The team’s skill library, and the loop that keeps it current. Press “Next signal” to follow one through.
Skills are now an open standard that works across coding agents, not a single vendor’s feature. These are the practices I’d hold a team to, from Anthropic’s engineering guidance and the people building on it.
The energy that used to go into correcting the same thing in every review goes here instead. It’s the difference between a team that repeats itself and an engine that gets smarter with every feature.
A lot of delay hides in small gaps. The spec didn’t say what happens when someone closes a dialog with unsaved changes, so work stops, a question is logged, and it waits for a meeting. With the product goal and context available to the coding agent, the person building can make a well-reasoned call in minutes, in line with the product’s goals, and share it.
An engineer hits a gap in the spec on Tuesday morning.
This only works if engineers know the customer and the goal, not just the ticket. That’s the real shift: from “implement exactly what was specified” to “understand why we’re building it, make good small decisions, and flag them.” Most gaps in a spec were never truly blocking. The process just required someone else to sign off before work could continue.
None of this works if one department feels it’s being written out. Every role changes. None disappears. The work moves up: from producing each artifact by hand to encoding judgment once, so everyone’s work carries it.
What each role did, what it does now, and why the team is worse off without it.
Here’s the honest version. When product managers start shipping code with coding agents, many engineers feel two things at once, often without saying either. They worry their job is going away. And they worry they’ll be the ones blamed when fast, AI-written code breaks in production. So they pump the brakes: more requirements, more grooming, more questions before starting. That isn’t bad faith. It’s a reasonable response to carrying the quality risk alone.
The answer is to take that weight off their shoulders, not to push harder.
So engineering and QA aren’t the only ones holding the line.
Quality stops being engineering’s burden and becomes the team’s standard. That’s what lets engineers be excited about speed instead of afraid of it.
If we can release twenty features a week, should we? Usually not. Every visible change asks something of customers: attention, relearning, trust. In enterprise and regulated software it also costs retraining, documentation and sometimes validation. Just as always-on agents need a governor on spending, a product needs a governor on change.
Pick where the product is and who uses it. The recommendation is a starting point for a conversation, not a formula.
Two things make the budget go further. Most improvements can be invisible to users: speed, reliability, fewer errors. And visible change can be bundled into fewer, well-explained releases instead of a constant drip. An early product should sprint to its first plateau. A mature enterprise product should mostly refine, and make each visible change count.
My own estimate of how the time shifts. Hover or tap a segment for the detail.
Status meetings, spec writing and grooming shrink. Time with customers, strategy, reviewing what shipped and coaching the team grows. The leader also takes on a new job: curating the context the whole team and its agents work from, including goals, customers, principles and the design and quality skills. That context is now the most leveraged thing a product leader produces.
Teams don’t switch methods overnight, and they shouldn’t. This is the path I’d take with a team used to detailed requirements and three-week sprints.
For some features, building in hours is realistic now; for many, days is. Either way, knowing it was the right feature still takes time with customers, and discovery doesn’t compress the way coding does. Product managers writing real code need real guardrails, and some teams won’t have the test coverage to start safely. In regulated software, validation is part of the product, not overhead. And the ratio debate is unsettled: several practitioners argue more PMs won’t fix a discovery problem. I think they’re right that the fix is better judgment, not more headcount.