PRODUCT IN THE AI AGE · PART 1

Rethinking Agile When the Cost of Building Changes

By Lindsay Bell · Product & Engineering Leader

Software delivery processes reflect the problems we expect them to solve. When those problems change, we should reconsider the process.

AI is prompting that reassessment. In teams that use it effectively, implementation and test creation can move substantially faster. Yet much of the work surrounding engineering still follows familiar patterns: prepare a backlog, decompose features, clarify requirements, and keep enough work ready for the next sprint.

Those practices deserve another look. To understand which ones should change, it helps to remember why we adopted them.

Why we planned before we built

When developing software requires a substantial investment, defining the work upfront has an understandable appeal. Agree on the scope, document the requirements, establish a design, and then commit engineering resources.

The difficulty is that some of the most important questions only become apparent once people can interact with the software. Requirements can change during development. Assumptions that looked reasonable in a document can fail when they encounter an actual workflow.

This tension was recognized long before Agile. Winston Royce’s influential 1970 paper described the risks of a straightforward sequential process and proposed measures including feedback and preliminary development. The history is more complicated than a progression from universally accepted waterfall to universally enlightened Agile. Managing the Development of Large Software Systems

Teams often committed substantial effort before working software exposed weaknesses in their assumptions.

What Agile changed

Agile shortened that distance. Frequent delivery, collaboration, and an expectation of changing requirements allowed teams to learn before committing to an entire solution.

The original principles emphasize working software and adaptation. They do not prescribe a particular ticket size or require product managers to write every implementation task. Principles Behind the Agile Manifesto

In practice, many organizations built substantial processes around those principles. Features became stories, stories became tasks, and backlog preparation became an ongoing responsibility. That structure can be useful: it exposes dependencies, clarifies expectations, and helps coordinate work.

But the usefulness of a practice depends on the problem it addresses. A process that once helped engineering move efficiently can become a constraint when the pace of engineering changes.

When execution gets faster

For this discussion, execution includes implementation, testing, and preparing work for release.

AI can help create code and associated tests within the same workflow. It can reduce the separate effort involved in writing unit, API, and end-to-end tests. Reviewing those tests, investigating failures, and deciding whether the evidence is sufficient still require attention.

The gains vary by team and problem. My observation is narrower than a claim that software development has become universally cheap: where execution accelerates substantially, the relative cost of the surrounding work changes.

I saw this while working on a product redesign with experienced, AI-enabled engineers. An initially substantial backlog eventually gave way to daily preparation of the next work. Prototyping, clarifying scope, reviewing deliveries, and validating assumptions began competing for the same hours. The engineering acceleration made those demands much more visible.

That observation fits a broader discussion. Marty Cagan has described AI as changing the allocation of effort in product development while preserving the importance of experimentation and product decisions. Experimentation, AI and the Product Model

Product definition contains different kinds of work

Understanding a problem and documenting a proposed solution are related, but they are not the same activity.

A customer may request a feature that does not address the underlying difficulty. Understanding their circumstances, forming a hypothesis, and testing it require investigation. Interviews, prototypes, experiments, and conversations with subject matter experts can all contribute.

Translating the resulting decisions into several sets of documents and tickets is another kind of work. AI can help maintain those artifacts and reduce the effort of keeping them aligned.

Teresa Torres makes a related distinction: discovery artifacts support the learning process, but producing them is not a substitute for understanding real customers. That distinction applies here. Automating documentation can create capacity for discovery; documentation volume does not demonstrate that discovery occurred. Don’t Use Generative AI to Replace Discovery with Real Humans

Keep the feedback loop and reconsider the surrounding practices

If a team can implement a coherent feature in the time it previously took to complete a smaller slice, that feature may become a reasonable unit of product intent. Engineering can still break it down internally, test incrementally, and release cautiously.

A larger functional increment does not have to mean a longer interval before feedback.

Parallel work also becomes more feasible, but it introduces demands on review, integration, and decision-making. Keeping more work in progress is useful only when the team can learn from and complete it.

My recommendation is to examine decision and validation capacity before adding engineering capacity. Look at work waiting for clarification, completed features waiting for acceptance, and rework caused by assumptions discovered late. These reveal different constraints; a larger backlog is not a remedy for all of them.

If clarification dominates, bring product and engineering together around the unresolved behavior. If acceptance is delayed, arrange reviewers and decision ownership before implementation finishes. If validation repeatedly changes the solution, invest earlier in testing the assumptions. These are diagnostic choices, not a prescription to keep every engineer busy.

Product leaders should examine where work now waits. Is the delay in understanding the problem, maintaining specifications, resolving a decision, or validating the result? Each calls for a different response.

AI gives us a reason to reassess our implementation of Agile. Its emphasis on learning and adaptation remains relevant—including when the process itself is what needs to adapt.