PRODUCT IN THE AI AGE · PART 2

Does Every Feature Still Need a Backlog of Stories?

By Lindsay Bell · Product & Engineering Leader

A working prototype can communicate things that are difficult to express in a ticket.

It shows how a user moves through a task, how information appears, and what happens after a decision. People can interact with it, challenge it, and discover questions that a written description did not bring to mind.

AI makes these prototypes more accessible to product managers, designers, and engineers. That creates an opportunity to reconsider how much manual translation is necessary between understanding a problem and implementing a solution.

Does every feature still need a product manager to decompose it into a detailed backlog before engineering can begin?

Start with what the artifacts are for

Requirements, mockups, stories, and acceptance criteria serve useful purposes. They help people establish intent, identify constraints, and agree on what a satisfactory result looks like.

Their value comes from the understanding they support. Producing them is not, by itself, evidence that the team understands the problem.

Teresa Torres makes a related distinction in her discussion of generative AI and discovery: artifacts are outputs of the learning process, and generating them cannot substitute for engaging with real people. Don’t Use Generative AI to Replace Discovery with Real Humans

The question is whether we can communicate what we have learned with less repetitive work.

A prototype and a specification can develop together

For some features, creating an interactive prototype can take a comparable amount of effort to producing a static mockup. The prototype then becomes a place to explore behavior rather than merely describe it.

It still needs an accompanying explanation.

An interface may not reveal permission rules, data assumptions, failure behavior, or constraints imposed by existing systems. It may demonstrate one successful path while leaving important exceptions unresolved.

A useful specification captures those details, along with the questions the team has not yet answered. As the prototype changes, the specification should change with it.

Warren Smith explores a related requirement for useful handoffs: a working implementation needs sufficient documentation for another team to interpret and maintain it. My emphasis here is on maintaining that context during discovery, while the team is still changing its mind. Vibe Coding Is Not the Problem. Failed Handoffs Are.

In my own work, using OpenSpec during prototyping reduced the effort of maintaining that alignment. Agents could reference the specification as we iterated, and updates to it helped preserve decisions in writing. OpenSpec is one implementation of an existing specification-driven approach, rather than a prerequisite for this way of working. OpenSpec project

The important practice is keeping behavior, intent, and unresolved questions connected.

Make the prototype a shared working artifact

There is a risk in having product build a prototype and then ask engineering to make it production-ready: the team may preserve a sequential handoff with a more persuasive deliverable.

By the time engineering sees it, substantial decisions may appear settled. Some may have been made deliberately. Others may simply reflect what the AI generated.

Itamar Gilad cautions that a detailed prototype can settle questions before the team has discussed them. That concern matters here: I see the prototype as something the team develops and challenges together, with unresolved decisions made explicit. 3 Trendy AI PM Archetypes, and 1 We Actually Need

Engineering involvement during discovery helps expose that difference. Engineers can question assumptions, identify dependencies, and suggest alternatives before the prototype becomes a commitment. Design expertise remains important in understanding whether the experience is coherent and usable.

Marty Cagan and Bob Baxley similarly place technical assessment within discovery rather than only after a solution has been defined. Product, Design and AI

The prototype should make the conversation more concrete while remaining open to change.

Decomposition can become an implementation choice

I am questioning the default expectation that a PM must manually decompose every feature into implementation-ready stories.

A feature still needs a clear purpose, boundaries, relevant constraints, and criteria for evaluating its behavior. Once that intent is sufficiently clear, engineers and AI can determine the breakdown needed to implement it.

I would stop requiring PM-authored implementation stories when the intended outcome and behavior are explicit, important business rules and exceptions are documented, engineers have participated in shaping the solution, and unresolved assumptions remain visible. Engineering must retain ownership of the implementation plan. A polished prototype alone does not satisfy those conditions.

I would retain more explicit coordination where work crosses team boundaries, depends on external integrations, or carries contractual delivery commitments. Those constraints can justify detailed breakdowns even when generating code is fast. The point is to choose the level of coordination the work needs, rather than enforce the same artifact everywhere.

Some work will benefit from small tasks and explicit dependencies. Other work may be straightforward enough to execute directly at the feature level. The team should choose the structure that helps it reason about the work.

This also preserves the PM’s involvement in tradeoffs. A technical choice can change the customer experience, delivery timing, or future options. Understanding those consequences is part of product judgment.

A functioning prototype is the beginning of a better question

A prototype makes a proposed solution easier to examine. It does not establish that the solution is valuable.

Subject matter experts may uncover technical inaccuracies or missing workflows. Customers may interpret the experience differently than expected. A convincing demonstration can still solve the wrong problem.

The goal is to reduce the effort between learning something and expressing it clearly enough to test and implement.

If prototypes and living specifications help achieve that, product managers can spend less time maintaining parallel descriptions of the same idea—and more time determining whether the idea deserves to become a product.