A 3-to-4-Week Feature Shipped in One. Can Product Keep Up?

A feature that would easily have taken 3 to 4 weeks was done in one week. It needed a third of the manpower, and it was a performance improvement to an existing process.

At the demo we had everyone you would expect: the team and product, and senior leadership too. They liked what they saw. What amazed them most was the time. I’m not sure what I expected them to say. It surprised me too. I thought it would take a bit more time, and the pace is simply crazy.

So can product keep up? What I see across many places is that most of the product groups I know are not keeping up with the pace.

That is why one week matters: look at who used to get blamed.

Deadlines used to be the developers’ problem

For years, development was the heaviest and most loaded part of the SDLC process. When deadlines were missed, most of the claims went from product toward development. That was the normal direction of blame.

I see that direction starting to flip.

Now development finishes first

Today the code and most of the delivery process are automated. Once you bring in teams of agents and more advanced logic, development in many cases works through requirements fast. A feature can now be done in less than half the time.

Think about the agile demo. It used to happen every two or three weeks, at the end of the sprint. If development can finish features that fast, product has to iterate faster and be more agile too.

You could say that doesn’t matter, because it just lets product hand over more requirements in a shorter period. Maybe. But product people now need to be more technical and change how they work, and many of them are falling behind.

So requirements have to be written faster. And you can go further: rethink the whole requirements process from the top, and write requirements from the start in a form that suits the AI processes development is adopting. If requirements must be faster and shaped for AI, what did I change?

So I rewrote how requirements are written

Requirements are still written the old way, and I said as much earlier in What an AI agent actually is. This time I did something about it.

I can’t share the exact format. What I can say is that it is an organized process, and it defines what every requirement must include: the product area and the specific feature, whether there is integration with other teams or other features, the problem today and the solution we propose, and, for example, who is affected.

Every item also carries acceptance criteria. They define exactly what should exist at the end of the process. And there is a Definition of Done, which states explicitly what, from the product side, confirms that the feature meets the standards.

An agent that knows the code reviews every requirement

The engineering agent comes in at a later stage. Think of it as a critic that knows the code. It works against both the repository and the existing product. It estimates how likely we are to deliver each requirement.

The most common problem it finds is missing information, or a requirement that is not clear enough. Then the requirement goes back to product, with what is missing and what the risk is.

The first requirement it sent back was a request to support one specific type of upload. That would have needed serious refactoring of the system. Product had not taken that into account in the delivery estimate. The project would have taken much longer than the requirement assumed. It was an excellent catch. Product could see what was required, how it affects the timelines, and communicate that before deciding whether to go for it or not.

This is also where the speedup comes from. As soon as requirements arrive from product, agents do the whole analysis quickly. They build the document and define the acceptance criteria. It used to happen in meetings that included people from development. Now the development agents have already done it, so the big problems are communicated early. The grooming discussion is much more efficient and productive now, and the problems development used to raise there dropped drastically, because part of them were already caught in the automated iterations.

It was not smooth from day one. The agents had to be tuned. Sometimes they were too accommodating, and sometimes they were strict about requirements that were perfectly valid. Mostly at the beginning, the agent also did not always do the full analysis it was supposed to do, so some of what it flagged or rejected came with no “why”.

The other problem was that the agent knew nothing about the people available. It said a requirement would take a month, with no context about the team’s capacity or what the people could actually do. So we added a layer that takes the available capacity into account as a factor in the estimate.

After a number of iterations its context improved, and from there the process works without problems. It keeps getting better day by day, because work in the field raises new challenges and new requirements each time.

Getting people to work this way was the hard part

The first step turned out to be a cultural change and not a technical one. The resistance was fairly broad, from managers down to employees. It’s a change of mindset, and that is hard to do. Product people, some more technical and some less, were asked to work with a format and with agents. None of that existed before.

My way in was to take two team managers. Over 3 sprints we showed them how the method works.

Their worry was real. They were the first to join the process, so in their eyes it could be a waste of their time. They were also skeptical about the idea of using agents, and about where it was heading.

Then came the central question: would the requirements actually be better or more efficient than what we get today, and how would we see it? What would prove that this process is better? So we built a set of metrics. Two of them: the time from creating a requirement to the start of actual work, and the number of bugs found because a requirement was defined wrongly or was missing something.

Once there was a plan, and a way to show success, the process started to flow. Everything was easier after that, and the technical side became the easy part. What I liked was watching the managers get on board. They wanted to define more things for the agents, and to do it even better than before.

Where a product manager should start

If I were in that seat, I would first check whether product holding up development is even my situation. If it is, I would look at how to bring AI into my own work and become an expert in effectiveness and process improvement, mostly in how I work with development.

I would also try the tools available today, to understand where they help and where they help less. And I would look at how to set up asynchronous communication with engineering, so the process runs efficiently. I plan to automate a lot of that asynchronous part, which is the kind of delivery change I write about in my book REDEFINE.