Backlog war gestern

These

Der erste Teil dieser Serie beschreibt, wie Design Systeme zur ausführbaren Infrastruktur werden. Der zweite Teil übersetzt das in den Alltag von Product-Design-Teams. Dieser dritte Teil nimmt die Perspektive ein, die dabei bisher unterbelichtet blieb: Product Management. Denn dort landet – leise und ohne Manifest – die meiste Integrationsarbeit, wenn Design ausführbar wird.

Product Management wird in dieser Konfiguration zum Single Point of Integration zwischen Strategie, Design, Engineering und Go-to-Market. Die Rolle gewinnt operative Hebel, und sie verliert zugleich die komfortable Pufferzone zwischen Anforderung und Umsetzung, die jahrelang im Handoff steckte. Solange Design-Artefakte über Wochen durch Übergaben wanderten, hatte ein PM Zeit, Entscheidungen reifen zu lassen oder sie unbemerkt dem Prozess zu überlassen. Wenn aus einem Kontext-Dokument in Stunden ein lauffähiger Kandidat wird, ist diese Zeit weg – und mit ihr das Versteck.

PMs, die weiter Backlog verwalten, werden austauschbar. PMs, die Entscheidungsräume strukturieren, werden knapp und teuer.

Drei Szenen aus dem PM-Alltag

Szene eins. Ein Product Manager bringt drei generierte Varianten eines Flows in die Sprint-Planung. Engineering fragt: „Und das ist jetzt das Design?” Die gleiche Szene taucht im zweiten Teil dieser Serie aus Designer-Sicht auf – von der PM-Seite betrachtet ist sie unangenehmer: Die Frage landet bei der Person, die die Varianten mitgebracht hat. Wer generiert, hat entschieden, ob er will oder nicht. Formal verantwortet die Entscheidung niemand.

Szene zwei. Eine Discovery-Session. Die Designerin liefert eine kriterienbasierte Evaluation der Generator-Ausgaben – dokumentiert, nachvollziehbar, mit klarer Empfehlung. Jetzt liegt der Ball beim PM: Geht das in die Roadmap oder nicht? Diese Entscheidung fiel früher irgendwo im Review-Zyklus, verteilt über mehrere Meetings und Wochen. Jetzt fällt sie vor dem Sprint, an einem Punkt, komprimiert auf eine Person.

Szene drei. Eine mittelgroße Organisation reorganisiert ihr Produkt-Team. Die Frage im Steuerungskreis lautet nicht mehr „Brauchen wir einen PM pro Team?”, sondern „Welche Urteilsarbeit machen wir wo – in Discovery, in Delivery, in Ops?” Die Stellenpläne kennen diese Frage noch nicht. Die Organigramme auch nicht.

Keine der drei Szenen ist Zukunftsmalerei. Sie sind in Teams mit entsprechendem Toolstack beobachtbar, und sie haben eine gemeinsame Struktur: Entscheidungen, die früher im Prozess verteilt lagen, konzentrieren sich auf die Rolle, die zwischen den Funktionen sitzt.

Was sich für Product Manager verschiebt

Von Backlog-Pflege zu Entscheidungsarchitektur. Das Backlog war das Steuerungsinstrument einer Welt, in der Produktionskapazität knapp war: eine geordnete Warteschlange vor einem teuren Engpass. Wenn Varianten billig werden, kehrt sich das Problem um – nicht die Abarbeitung der Liste ist der Hebel, sondern die Verknappung dessen, was überhaupt in Betracht kommt. Ein PM, der zwanzig generierte Varianten in ein Backlog sortiert, verwaltet Überfluss mit einem Werkzeug für Mangel. Entscheidungsarchitektur heißt: den Raum der Möglichkeiten so strukturieren, dass wenige, gut begründete Optionen übrig bleiben, bevor produziert wird.

Von der User Story zum Kontext-Bundle. PMs formulieren zunehmend nicht mehr Anforderungen für Menschen, sondern Kontexte für Generatoren: Akzeptanzkriterien, Gegenbeispiele, Grenzfälle, Brand-Constraints – als strukturierte Artefakte, die ein System produktiv konsumieren kann. Das ist die Spec-Literacy aus dem zweiten Teil dieser Serie, von der anderen Seite betrachtet. Eine klassische User Story delegiert die Lücken an das Gespräch („wird im Refinement geklärt”). Ein Kontext-Bundle muss die Lücken selbst schließen, weil am anderen Ende kein Gespräch mehr stattfindet.

Von Priorisierung zu Urteils-Moderation. Die klassische PM-Moderation vermittelte zwischen Stakeholdern, die sich nicht einig sind. Die neue Moderation vermittelt zwischen System-Evaluationen, Brand-Governance und Business-Hypothesen – zwischen Urteilen unterschiedlicher Herkunft, die alle dokumentiert und begründet vorliegen. Das klingt einfacher, ist aber anspruchsvoller: Wer zwischen Meinungen moderiert, kann auf Konsens spielen. Wer zwischen dokumentierten Urteilen moderiert, muss selbst eines fällen und begründen.

Discovery im Laufzeit-Kontext

Discovery wird durch diese Verschiebung nicht entwertet – im Gegenteil. Was Generatoren nicht liefern können, ist Wissen darüber, welches Problem für welche Menschen in welchem Kontext zählt. Marty Cagan hat Discovery als eigenständige Disziplin etabliert, Teresa Torres hat sie mit Continuous Discovery Habits in eine wöchentliche Praxis übersetzt. Diese Grundlagen bleiben.

Was sich ändert, ist das Artefakt, in das Discovery mündet. Klassische Discovery lieferte Insights, die in Specs und Stories übersetzt wurden – für Menschen, die daraus Software bauen. Generative Discovery liefert Insights, die in Generator-Kontexte, Evaluations-Kriterien und Constraints münden – für Systeme, die daraus Kandidaten bauen. Der Unterschied ist nicht kosmetisch. Wer Discovery-Ergebnisse 2027 noch ausschließlich in klassische User Stories übersetzt, verliert Hebel gegenüber Teams, die denselben Erkenntnisstand direkt generatorfähig strukturieren: Ihre Erkenntnisse wirken schneller, in mehr Varianten, mit dokumentierter Begründung.

Team-Organisation: was verschwindet, was entsteht

Auf der organisationalen Ebene sortiert sich die Meeting- und Rollenlandschaft neu. Es verschwinden die Rituale, deren Zweck im Handoff lag: Design-Reviews als Übergabe-Zeremonie, Spec-Abnahmen, Status-Runden entlang der Werkzeuggrenzen. Die Meetings verschwinden dabei langsamer als ihr Zweck – viele Organisationen halten Rituale noch Monate am Leben, nachdem der Grund entfallen ist.

Es bleiben Discovery, Research, Stakeholder-Alignment und Go-to-Market-Entscheidungen – die Arbeit, die auf Wissen über Menschen und Märkte beruht.

Und es entsteht Neues: Evaluations-Rituale, in denen Design, PM und Engineering gemeinsam Generator-Output gegen Kriterien prüfen. Runtime-Governance, also die laufende Kuratierung des Systems, das die Generatoren konsumieren. Und Entscheidungs-Logbücher, in denen dokumentierte Urteile nachvollziehbar werden – als Audit-Artefakt und als Lehrstoff für den Nachwuchs. Offen ist, wo diese neuen Aufgaben wohnen: bei PM, bei Design, oder in einer Rolle, die es noch nicht flächendeckend gibt.

Die Integrations-Kapazität wird zum Engpass, nicht die Produktions-Kapazität.

Der PM-Nachwuchs

Der klassische PM-Lernweg lief über Menge: Backlog gepflegt, Hunderte User Stories geschrieben, Dutzende Stakeholder-Interviews geführt – und daraus ein Gespür entwickelt, welche Anforderung hält und welche im Refinement zerfällt. Die Menge war die Lehrstufe, genau wie im Design.

Wenn Kontext-Bundles statt Stories gefragt sind und Entscheidungsarchitektur statt Backlog-Pflege, braucht der Junior-PM eine andere Lernumgebung: dokumentierte Entscheidungsräume, an denen sich nachvollziehen lässt, warum eine Option gewann. Review von Generator-Kontexten, so wie früher Code-Review. Explizite Kriterienbildung als Handwerk. Die Ansätze ähneln denen aus dem Design-Teil dieser Serie – Pairing mit Senior-PMs, öffentliche Dokumentation eigener Produktentscheidungen, Curricula mit Urteilsfokus – und wie dort ist keiner davon fertig gedacht.

Einordnung für Organisationen

Für mittelgroße Organisationen, KMUs und Digital Units verschiebt sich die Personalfrage. Bislang lautete sie: Wie viele PMs brauchen wir? Künftig lautet sie: Wie viel Integrationsarbeit fällt bei uns an, und wo wohnt sie? Das kann auf weniger, dafür seniorere PM-Rollen hinauslaufen, auf ein Product-Ops-Team, das Governance und Evaluation trägt, oder auf Fractional-Konfigurationen, in denen strategische Produktführung auf Teilzeit sitzt und eine Runtime-Infrastruktur den operativen Anteil absorbiert.

Die ehrliche Gegenrechnung gehört dazu: Ein Single Point of Integration ist auch ein Single Point of Failure. Wer die Integrationsarbeit auf eine Rolle konzentriert, ohne Governance, Evaluations-Rituale und Dokumentation aufzubauen, erzeugt keine schnellere Organisation, sondern eine überlastete Person mit maximaler Fehlerhebelwirkung. Die Konzentration der Entscheidungen ist nur dann ein Gewinn, wenn die Organisation die Infrastruktur nachzieht, die diese Entscheidungen prüfbar macht.

Einordnung

Dieser Text ist aus der Perspektive eines Design Leads geschrieben, der seit Jahren an der Schnittstelle zu Product Management arbeitet – in KMUs, Digital Units und Produktorganisationen im DACH-Raum, zuletzt intensiv mit generativen Toolstacks. Es ist eine Außensicht auf die PM-Rolle, keine Innensicht: Ich habe PM-Arbeit begleitet, mitgestaltet und von ihr abhängig gearbeitet, aber nie über Jahre einen PM-Seat besetzt. Was diese Perspektive gut sieht, ist die Verschiebung an der Naht zwischen Design und Produkt. Was sie schlechter sieht: die Binnendifferenzierung der PM-Rolle (IC Principal, Team Lead, Product Ops) in großen Organisationen, US-Kontexte mit anderer Rollenökonomie, regulierte Industrien mit mehrjährigen Zyklen.

Kritische Einordnung

Was hält stand

• Die operativen Verschiebungen sind in Teams mit generativem Toolstack beobachtbar, nicht spekulativ
• Der Trend zur Spec als Artefakt hat methodische Vorläufer (Requirements Driven Development, User Story Mapping, Impact Mapping) – die Bewegung ist älter als die Generatoren, sie wird durch sie nur verbindlich
• Dass Integrationsarbeit bei der Rolle zwischen den Funktionen landet, wenn Übergaben kollabieren, folgt der gleichen Logik, die in den ersten beiden Teilen der Serie für Brand und Design dokumentiert ist

Was man einordnen muss

• Die Verschiebung trifft nicht alle PMs gleich. Ein Principal IC in einem Plattform-Team erlebt etwas anderes als ein Team-PM in einer Digital Unit – Pauschalaussagen über „die PM-Rolle” sind mit Vorsicht zu lesen, auch die in diesem Text
• Die Überlastungs-Gefahr ist real: Die Diagnose „PM wird Single Point of Integration” beschreibt eine Tendenz, keine Empfehlung. Organisationen können sich auch dagegen entscheiden und Integration bewusst verteilen
• Die Tool-Adoption verläuft in DACH-Organisationen langsamer als in US-Kontexten – Jahreszahlen in diesem Text sind Richtwerte aus einem Umfeld mit hoher Adoptionsbereitschaft
• Der Text ist von der Design-Seite der Naht geschrieben. Die PM-Community selbst würde manche Gewichtung anders setzen – die Diskussion darüber ist erwünscht

Diskussionsfragen

01 Spec-Artefakt: Welcher Spec-Typ – Prompt, Kontext-Bundle, Decision Log – wird zum dominanten PM-Artefakt, und wer definiert seinen Qualitätsstandard?

02 Governance-Ort: Wohnt Runtime-Governance in Product Management, in Design, oder in einer neuen Rolle zwischen den Disziplinen?

03 Discovery-Ökonomie: Wie rechtfertigt man Discovery-Zeit in einer Organisation, die gerade lernt, dass Produktion billig wird?

04 Junior-PM-Pfade: Welche Lernumgebung ersetzt die klassische Backlog-Pflege als PM-Lehrstufe?

Quellen

• Marty Cagan, Inspired: How to Create Tech Products Customers Love, Wiley 2018, und Empowered: Ordinary People, Extraordinary Products, Wiley 2020 (SVPG)
• Teresa Torres, Continuous Discovery Habits, Product Talk 2021
• Anthropic: Introducing Claude Design by Anthropic Labs (analysiert im ersten Teil dieser Serie)
• Harvard Business Review, The Rise of the Fractional Executive, 2025

Glossar

Single Point of Integration Die Rolle, die Strategie-, Design-, Engineering- und Go-to-Market-Entscheidungen zusammenführt. In der klassischen Konfiguration über Übergaben verteilt, in der Laufzeit-Konfiguration zunehmend konzentriert auf Product Management.

Kontext-Bundle Ein generatorfähig strukturierter Satz aus Akzeptanzkriterien, Gegenbeispielen, Grenzfällen und Brand-Constraints – funktionaler Nachfolger der klassischen User Story.

Decision Log Dokumentierte Kette von Produkt- und Design-Entscheidungen mit Begründung und Kontext – dient als Audit-Artefakt und als Lehrstoff für den Nachwuchs.

---

Dritter Teil einer Serie zur Verschiebung des Designberufs, wenn Design ausführbar wird. Teil 1: Marke wird Software · Teil 2: Zehn Entwürfe. Und jetzt?.