Product Backlogs in the Age of AI

If AI can generate backlog items and working software in a fraction of the time they once required, do product backlogs still matter?

Yes. But what makes a backlog valuable is changing.

A backlog was never valuable because it was a large inventory of detailed future work. That idea was always a bit of a myth. What made a backlog valuable was that it captured the team's best current thinking about what to build next and why.

AI just makes the myth harder to sustain. When detail can be generated in seconds, there is even less reason to specify hundreds or thousands of stories far in advance. At the same time, AI increases the backlog's value as a record of thoughtful product decisions and the next things worth learning.

AI can help teams build faster. It does not decide what is worth building.

A Product Backlog Is Not a Queue for Keeping AI Busy

Organizations have long made the mistake of treating a product backlog as a queue whose purpose is to keep developers busy.

AI creates the potential for an even more extreme version of that mistake.

A coding agent finishes something, so we feed it the next item. Then the next. If the backlog begins to run low, AI can generate dozens of additional stories to keep the development process moving.

This may produce a great deal of software. It does not necessarily produce a successful product.

The goal of product development is not maximum feature production. It is to solve valuable problems, learn from users, and make good decisions about what to do next.

A backlog should support those decisions. It should not become an inexhaustible queue of plausible features.

We Need to See Ahead, but Not Forever

The novelist E.L. Doctorow once compared writing a novel to driving a car at night. You can only see as far as the headlights, but you can make the whole journey that way.

I've long applied that analogy to product development.

A product backlog needs to let us see far enough ahead. It does not need to illuminate the entire journey to the product's release—or eventual end of life.

The items closest to implementation need enough clarity that the team can discuss, estimate, and build them. Items farther into the future can remain larger and less detailed.

As priorities shift and the team learns more, those items can be refined, replaced, or removed.

AI makes this progressive approach even more practical. If a team can generate examples, acceptance criteria, and possible story splits quickly, it has less reason to invest heavily in detail that may become obsolete before anyone uses it.

The ability to generate detail inexpensively is not an argument for adding detail everywhere. It is an argument for adding it when it becomes useful.

Some Teams Need Brighter Headlights

Not every team needs to see the same distance ahead.

A very slow-moving team may need only five or 10 clear backlog items because those items will keep it occupied for months. A faster team needs more ready work to avoid outrunning its backlog.

Dependencies also affect the required planning horizon. A team may need additional visibility when its work involves:

Manufacturing or physical components
Regulatory approval
User training
Marketing and sales preparation
Vendors or external partners
Data migration
Security or legal review
Scarce specialists
Other development teams
Expensive decisions that will be difficult to reverse

I once worked with teams building a programmable scientific calculator used in university courses. The hardware, along with companion web, iOS, and Android apps, had to ship together under a strict feature-parity mandate—nothing could appear in one version without appearing in all of them.

Each team kept its own backlog but stayed aligned through frequent coordination, watching progress on mandatory and desired features closely. Those teams needed brighter headlights because several products had to converge on the same release. They still did not need every possible future story described in detail.

The right planning horizon depends on delivery speed, uncertainty, risk, dependencies, and how early others need to act. It should not be determined by a desire to make the backlog appear complete.

AI May Allow Larger Stories

For years, agile teams have been encouraged to make stories smaller so they can complete them quickly and get feedback sooner.

That advice remains useful, but AI adds an important nuance.

If AI allows a team to complete what was once a large story in the same amount of time a small story used to require, the story may not need to be split merely to satisfy an old expectation of how much functionality belongs in a story.

Elapsed time and risk matter more than an abstract definition of small.

Suppose a team once needed two weeks to implement a capability. With AI-assisted development, perhaps the team can now complete that capability in two days. The team may be able to keep the capability together and still receive feedback quickly.

But faster implementation does not remove the risk of building too much before validating an idea. The appropriate size of a story depends partly on how much the team is willing to build before learning whether users value it.

A larger story may be reasonable when:

The intended outcome is well understood.
The team has strong evidence that users need it.
Implementation can still be completed quickly.
Users can validate it soon after it is built.
The cost of being wrong is acceptable.

A smaller story or earlier experiment is wiser when the need, solution, or expected outcome remains uncertain.

AI may change how much work fits within a short feedback window. It does not eliminate the need for that window—and a bigger story only makes sense if the team is still willing to stop and look before building the next one.

The Biggest Risk Is Building the Wrong Features Faster

AI-assisted development creates many potential benefits. Teams can explore alternatives, create prototypes, generate tests, and implement working software more quickly.

But it can also help a team turn an inadequately considered idea into working software before anyone has seriously questioned it.

That is the greatest risk: building the wrong features faster.

Building the wrong thing wastes time and money. It can damage morale when team members invest effort in functionality nobody needs. It can also harm the reputation of the product or company when users encounter features that are confusing, unnecessary, or poorly suited to their needs.

The fact that AI made a feature inexpensive to implement does not make the feature valuable.

Nor does "the AI built exactly what we asked for" demonstrate that we asked for the right thing.

Use Faster Development to Reach Evidence Sooner

The best use of AI is not merely getting from idea to code faster. It is getting from idea to evidence faster.

Teams can do that in several ways:

Validate the problem through interviews, observations, analytics, support data, or operational evidence.
Test a possible solution with a sketch, prototype, example, or workflow walkthrough.
Identify the assumptions most likely to make the idea succeed or fail, and decide up front what evidence would confirm or kill it.
Build an amount of functionality appropriate to the uncertainty and risk.
Put working software in front of real users early.
Stop, change, or simplify the feature when the evidence is weak.

Putting working software in front of users is especially important.

AI may let a team create something meaningful sooner. Take advantage of that by showing it to users sooner—not by adding five more features before anyone sees it.

Feedback should accelerate along with development.

Keep the Backlog Dynamic

As AI reduces the cost of producing detailed backlog items, good teams may choose to maintain less detail, not more.

Their backlog can be shaped by a clear product direction while containing:

A manageable set of high-level future possibilities
Prioritized near-term items
Enough detail to support the next useful decisions
Evidence and assumptions that still need to be tested
Items refined shortly before the detail becomes valuable

AI can help supply detail when the team needs it. It can suggest acceptance criteria, examples, alternatives, risks, and possible decompositions.

Humans still need to decide which items deserve that attention.

This changes the backlog from a warehouse of predicted requirements into a tool for guiding learning and delivery. That is what a good product backlog should have been all along. AI simply makes the distinction harder to ignore.

AI makes it easier to build more.

A good product backlog helps the team decide when more is actually better.

Last updated September 29th, 2026