The Backlog Was Yesterday

Thesis

The first part of this series describes how design systems become executable infrastructure. The second part translates that into the everyday life of product design teams. This third part takes the perspective that has stayed underexposed so far: product management. Because that is where most of the integration work lands – quietly, without a manifesto – when design becomes executable.

In this configuration, product management becomes the single point of integration between strategy, design, engineering and go-to-market. The role gains operational leverage, and at the same time it loses the comfortable buffer zone between requirement and implementation that used to live inside the handoff. As long as design artifacts wandered through handovers for weeks, a PM had time to let decisions mature, or to quietly leave them to the process. When a context document turns into a runnable candidate within hours, that time is gone – and so is the hiding place.

PMs who keep managing backlogs become interchangeable. PMs who structure decision spaces become scarce and expensive.

Three Scenes from Everyday PM Work

Scene one. A product manager brings three generated variants of a flow into sprint planning. Engineering asks: “So is this the design now?” The same scene appears in the second part of this series from the designer’s point of view – seen from the PM side it is more uncomfortable: the question lands on the person who brought the variants. Whoever generates has decided, whether they wanted to or not. Formally, nobody owns the decision.

Scene two. A discovery session. The designer delivers a criteria-based evaluation of the generator output – documented, retraceable, with a clear recommendation. Now the ball is with the PM: does this go on the roadmap or not? That decision used to fall somewhere inside the review cycle, spread across several meetings and weeks. Now it falls before the sprint, at a single point, compressed onto one person.

Scene three. A mid-size organization reorganizes its product team. The question in the steering group is no longer “Do we need one PM per team?” but “Which judgment work do we do where – in discovery, in delivery, in ops?” The staffing plans don’t know that question yet. Neither do the org charts.

None of the three scenes is futurism. They are observable in teams with the corresponding tool stack, and they share one structure: decisions that used to be distributed across the process concentrate on the role that sits between the functions.

What Shifts for Product Managers

From backlog care to decision architecture. The backlog was the steering instrument of a world in which production capacity was scarce: an ordered queue in front of an expensive bottleneck. When variants become cheap, the problem inverts – the lever is no longer working through the list but narrowing down what enters consideration at all. A PM who sorts twenty generated variants into a backlog is managing abundance with a tool built for scarcity. Decision architecture means structuring the space of possibilities so that few, well-reasoned options remain before anything gets produced.

From the user story to the context bundle. PMs increasingly formulate not requirements for people but contexts for generators: acceptance criteria, counter-examples, edge cases, brand constraints – as structured artifacts a system can consume productively. This is the spec literacy from the second part of this series, seen from the other side. A classic user story delegates its gaps to the conversation (“to be clarified in refinement”). A context bundle has to close the gaps itself, because there is no conversation at the other end anymore.

From prioritization to judgment moderation. Classic PM moderation mediated between stakeholders who disagree. The new moderation mediates between system evaluations, brand governance and business hypotheses – between judgments of different origins, all of them documented and reasoned. That sounds easier and is harder: whoever moderates between opinions can play for consensus. Whoever moderates between documented judgments has to make one, and justify it.

Discovery in the Runtime Context

Discovery is not devalued by this shift – on the contrary. What generators cannot deliver is knowledge about which problem counts, for which people, in which context. Marty Cagan established discovery as a discipline of its own; Teresa Torres translated it into a weekly practice with Continuous Discovery Habits. Those foundations stay.

What changes is the artifact discovery feeds into. Classic discovery delivered insights that were translated into specs and stories – for people who build software from them. Generative discovery delivers insights that feed into generator contexts, evaluation criteria and constraints – for systems that build candidates from them. The difference is not cosmetic. Whoever still translates discovery results exclusively into classic user stories in 2027 loses leverage against teams that structure the same knowledge in generator-ready form: their insights take effect faster, in more variants, with documented reasoning.

Team Organization: What Disappears, What Emerges

On the organizational level, the meeting and role landscape re-sorts itself. What disappears are the rituals whose purpose lived in the handoff: design reviews as handover ceremonies, spec sign-offs, status rounds along tool boundaries. The meetings disappear more slowly than their purpose – many organizations keep rituals alive for months after the reason is gone.

What stays are discovery, research, stakeholder alignment and go-to-market decisions – the work that rests on knowledge about people and markets.

And new things emerge: evaluation rituals in which design, PM and engineering jointly check generator output against criteria. Runtime governance, meaning the ongoing curation of the system the generators consume. And decision logs in which documented judgments become retraceable – as an audit artifact and as teaching material for juniors. What remains open is where these new tasks live: with PM, with design, or in a role that doesn’t exist at scale yet.

Integration capacity becomes the bottleneck, not production capacity.

The Next Generation of PMs

The classic PM learning path ran through volume: backlogs groomed, hundreds of user stories written, dozens of stakeholder interviews conducted – and out of that, a feel for which requirement holds and which falls apart in refinement. Volume was the teaching stage, exactly as in design.

When context bundles are needed instead of stories, and decision architecture instead of backlog care, junior PMs need a different learning environment: documented decision spaces that let them retrace why an option won. Review of generator contexts, the way code review used to work. Explicit criteria building as a craft. The approaches resemble those in the design part of this series – pairing with senior PMs, public documentation of one’s own product decisions, curricula focused on judgment – and as there, none of them is fully worked out.

What This Means for Organizations

For mid-size organizations, SMEs and digital units, the staffing question shifts. Until now it was: How many PMs do we need? Going forward it is: How much integration work occurs here, and where does it live? That can lead to fewer but more senior PM roles, to a product ops team that owns governance and evaluation, or to fractional configurations in which strategic product leadership sits part-time and a runtime infrastructure absorbs the operational share.

The honest counter-calculation belongs here: a single point of integration is also a single point of failure. Whoever concentrates the integration work on one role without building governance, evaluation rituals and documentation does not create a faster organization but an overloaded person with maximum error leverage. Concentrating the decisions only pays off if the organization builds the infrastructure that makes those decisions checkable.

Perspective

This piece is written from the perspective of a design lead who has worked at the interface to product management for years – in SMEs, digital units and product organizations in the DACH region, most recently with generative tool stacks. It is an outside view of the PM role, not an inside view: I have accompanied, co-shaped and depended on PM work, but never held a PM seat for years. What this perspective sees well is the shift at the seam between design and product. What it sees less well: the internal differentiation of the PM role (IC principal, team lead, product ops) in large organizations, US contexts with a different role economy, regulated industries with multi-year cycles.

Critical Assessment

What holds up

• The operational shifts are observable in teams with a generative tool stack, not speculative
• The trend toward the spec as artifact has methodological precursors (requirements driven development, user story mapping, impact mapping) – the movement is older than the generators; they merely make it binding
• That integration work lands with the role between the functions when handovers collapse follows the same logic documented for brand and design in the first two parts of this series

What needs qualification

• The shift does not hit all PMs equally. A principal IC in a platform team experiences something different from a team PM in a digital unit – blanket statements about “the PM role” should be read with caution, including those in this piece
• The overload risk is real: the diagnosis “PM becomes the single point of integration” describes a tendency, not a recommendation. Organizations can decide against it and deliberately distribute integration
• Tool adoption in DACH organizations runs slower than in US contexts – the year references in this piece are reference points from an environment with high adoption readiness
• This piece is written from the design side of the seam. The PM community itself would weight some points differently – that discussion is welcome

Discussion Questions

01 Spec artifact: Which spec type – prompt, context bundle, decision log – becomes the dominant PM artifact, and who defines its quality standard?

02 Where governance lives: Does runtime governance live in product management, in design, or in a new role between the disciplines?

03 Discovery economics: How do you justify discovery time in an organization that is just learning that production is getting cheap?

04 Junior PM paths: Which learning environment replaces classic backlog care as the PM teaching stage?

Sources

• Marty Cagan, Inspired: How to Create Tech Products Customers Love, Wiley 2018, and Empowered: Ordinary People, Extraordinary Products, Wiley 2020 (SVPG)
• Teresa Torres, Continuous Discovery Habits, Product Talk 2021
• Anthropic: Introducing Claude Design by Anthropic Labs (analyzed in the first part of this series)
• Harvard Business Review, The Rise of the Fractional Executive, 2025

Glossary

Single point of integration The role that brings strategy, design, engineering and go-to-market decisions together. Distributed across handovers in the classic configuration, increasingly concentrated on product management in the runtime configuration.

Context bundle A generator-ready structured set of acceptance criteria, counter-examples, edge cases and brand constraints – the functional successor of the classic user story.

Decision log A documented chain of product and design decisions with reasoning and context – serves as an audit artifact and as teaching material for juniors.

---

Third part of a series on how the design profession shifts when design becomes executable. Part 1: Brand Becomes Software · Part 2: Ten Drafts. Now What?.