The new product leadership: less backlog, more judgement
When creating a first version becomes cheaper, the bottleneck is no longer turning requirements into code. Product leadership comes to mean selecting problems, designing evidence and deciding which options should not survive.

For years, an important part of product work has been managing scarcity. There were more requests than development capacity, so we needed to prioritise, refine and prepare a sufficiently clear queue of work for the team to execute.
Agents do not remove that need, but they change its centre of gravity. When we can explore several solutions, build prototypes or turn a hypothesis into software much faster, execution capacity is no longer the only scarce resource.
The scarce resource becomes judgement.
A backlog is not a strategy
A long, prioritised list creates a sense of control. It can also hide the fact that many entries are not connected to a relevant decision. If the cost of producing options falls, feeding that list with more ideas only increases the noise.
Product direction needs to turn requests into questions:
- Which behaviour do we want to change?
- What evidence would make us invest more?
- What is the risk of not acting?
- Which assumption could invalidate the entire proposal?
- Which solution would preserve product coherence?
A backlog remains useful for making work visible. It stops being useful when it replaces the conversation about why that work should exist.
Produce options and eliminate options
AI can generate alternatives at great speed: journeys, copy, architectures, analyses and prototypes. That makes a function that once looked secondary more valuable: elimination.
Every option adds evaluation cost. Those that reach the product also add support, communication, data, operations and future decisions. Leadership is not measured by how many ideas it starts, but by the quality of the system it uses to decide which deserve to continue.
Evidence is designed
Asking users whether they like an idea produces politeness. Showing them a concrete situation and observing what they do produces evidence. Product must decide what form of reality it needs to create to reduce uncertainty.
Sometimes it will be a prototype. At other times, a manual operation, an offer, a technical test or a limited product change. The central skill is connecting each artefact to an explicit decision.
When execution is cheap, building no longer has to be the final commitment. It can become a way of thinking with our hands.
Lead the complete system
Agents also change the relationship between product and engineering. If a product leader can materialise an option independently and an engineer can explore business implications, the boundaries become more porous.
That does not remove specialisms. It requires a shared language around objectives, constraints, quality and evidence. Product must help people and agents work within the same direction, without becoming an intermediary that merely moves tickets.
Less administration, more accountability
Automating some operational product work does not reduce accountability. It concentrates it. We need to protect privacy, coherence, accessibility, organisational impact and the consequences of multiplying changes.
The new product leadership is not about writing less. It is about using fewer documents as substitutes for judgement and more artefacts as instruments for learning.
Sources and references
- DORA’s 2025 report on AI-assisted development.
- Primary source: Victor’s experience in product, venture building and transformation.