Der Context Lake ist das neue Kernelement des Produktmanagements

Artikel 7 von 9 in dieser Reihe.

Stellen Sie sich einen Product Owner und einen Entwickler vor, die gemeinsam an einem Nachmittag an einer Teams-Konferenz teilnehmen und eine Story besprechen, die am Vormittag von ihrem Refinement-Agenten recherchiert, entworfen und gestaltet wurde. Der Beitrag ist gut verfasst. Die Akzeptanzkriterien sind präzise formuliert. Abhängigkeiten sind gekennzeichnet. Bei einer normalen Refinement-Sitzung würde dies problemlos durchgehen.

Das Problem ist eines, das niemand im Raum erkennen kann. Das Element passt nicht zur Produktstrategie. Es ist nicht offensichtlich falsch, sondern nur auf subtile Weise. Eine Funktion, die auf ein Segment abzielt, dessen Priorität das Team vor sechs Monaten herabgestuft hat. Ein Akzeptanzkriterium, das stillschweigend im Widerspruch zu einer Compliance-Vorgabe steht, die in einem Slack-Thread dokumentiert ist, den niemand durchsucht hat. Eine Wertannahme, die bereits während eines Pilotprojekts des vorherigen Product Owners getestet wurde – und dabei gescheitert ist.

Der Agent wusste davon nichts. Das konnte er auch gar nicht. Er kennt lediglich die Daten, mit denen er trainiert wurde, sowie die zusätzlichen Informationen (den Kontext), die ihm vom Team zur Verfügung gestellt wurden. Der fehlende Kontext wurde nirgendwo festgehalten, sodass ein Agent (oder ein neues Teammitglied) ihn nicht hätte finden können.

Dies ist die unauffälligste Form des Scheiterns bei KI-gestützten Produktteams – und zugleich eine der kostspieligsten. Der Code ist korrekt. Die Umsetzung ist sauber. Die „Definition of Done“ ist erfüllt. Die Arbeit steht jedoch in keinem Zusammenhang mit dem Produkt, da der Produktkontext nie an die Stelle gelangt ist, aus der der Agent seine Informationen bezieht.

In den ersten sechs Artikeln dieser Reihe habe ich eine Definition von Wert vorgeschlagen, dargelegt, dass sich die Verantwortlichkeit konzentriert, sobald neue Akteure dem Team beitreten, die Verfeinerung als „Option Framing“ neu definiert, die Messlatte für Inkremente höher gelegt, um deren Übernahme zu gewährleisten, die Sprint-Review im Demo-Stil durch eine „Evidence Review“ ersetzt und die „Tacit Knowledge Tax“ benannt, die KI-gestützte Teams zahlen müssen. Alle sechs Punkte beruhen auf einer Annahme, die ich bisher noch nicht ausdrücklich genannt habe: Was das Team weiß, können die Akteure nutzen. Diese Annahme ist heute in den meisten Teams falsch. In diesem Artikel geht es darum, was sich ändert, wenn man dies korrigiert.

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht genau sagen, wie das Produktmanagement in fünf Jahren aussehen wird. Ich kann Ihnen jedoch darlegen, wie eine Gruppe erfahrener Professional Scrum Trainer die Verlagerung des Schwerpunkts einschätzt und warum das nächste zentrale Artefakt, das Ihr Team entwickeln muss, weder ein weiteres Backlog noch eine Roadmap oder ein Dashboard ist. Die vollständige Liste der Mitwirkenden der Face-to-Face-Veranstaltung in Amsterdam finden Sie am Ende des Artikels. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns allen.

Der Wandel, den das Produktmanagement still und leise vollzogen hat

Seit dreißig Jahren wird die Aufgabe des Product Owners in den meisten Teams als die Pflege eines Product Backlogs beschrieben. Elemente verfeinern. Sie ordnen diese an. Sie entscheiden, was wann ausgeliefert wird. Der Scrum Guide forderte jedoch mehr: den Wert zu maximieren, Produktziele zu klären sowie die Beteiligten über die Produktrichtung zu informieren und auf diese abzustimmen. Doch die tägliche Realität der meisten Product Owner besteht darin, das Backlog zu verwalten, an Besprechungen teilzunehmen und sich die Bedürfnisse der Stakeholder anzuhören.

KI verringert die Bedeutung des Backlog-Managements. Bots erstellen Einträge schneller, als Menschen sie lesen können. Heuristiken zur Priorisierung lassen sich in großem Maßstab anwenden. Bei ausreichendem (strategischem) Kontext, Daten und Erkenntnissen wird die Priorisierung zu einer einfachen Aufgabe. Die „mechanischen Aspekte“ der Rolle des Product Owners werden kostengünstiger, einfacher und verlieren an Bedeutung.

Was nicht billiger wird, ist die Vorarbeit. Was sollte das Team überhaupt in Betracht ziehen? Welche Kundensegmente sind derzeit von Bedeutung? Was haben wir bereits ausprobiert und daraus gelernt? Welche Untersuchungen, Daten und Erkenntnisse sind für das Problem, das wir für die Zielgruppe lösen wollen, wertvoll – und welche nicht? Was sind die unverzichtbaren Rahmenbedingungen – rechtlicher, technischer, markenbezogener und ethischer Art –, die unsere Entscheidungen bestimmen? Warum ist eine Funktion vorhanden? Warum fehlt eine Funktion? Welche Erkenntnisse aus welchen Untersuchungen fließen in welche Entscheidungen ein?

Machen Sie keinen Fehler: Produktverantwortliche waren bereits zuvor diejenigen, die für die Klärung und Kommunikation dieses Kontexts verantwortlich waren. Dreißig Jahre lang existierte dieser Kontext jedoch größtenteils im Kopf des Produktverantwortlichen, ergänzt durch ein Flickwerk aus Wikis, Roadmaps und Slack-Threads. Das war tolerierbar, solange der Produktverantwortliche die Hauptzielgruppe für seinen eigenen Kontext war. Es ist jedoch nicht mehr hinnehmbar, wenn Mitarbeiter (fast) alles lesen, schreiben und beeinflussen, was das Team produziert.

Der Context-See

Ich möchte einen neuen Begriff, ein neues Artefakt und eine neue Kernaufgabe für den Product Owner vorschlagen. Wir können das Artefakt als „Context Lake“ und die Aufgabe als „Context Management“ bezeichnen.

Ein „Context Lake“ ist die kuratierte, versionierte und priorisierte Sammlung von Produktkontexten, auf deren Grundlage das Scrum-Team, der Product Owner, die Stakeholder und die Mitarbeiter arbeiten. Er umfasst die Produktvision und -strategie. Er umfasst die Wertdefinition. Er umfasst Kundensegmente, Personas und die Untersuchungen, auf deren Grundlage diese definiert wurden. Er umfasst die Rahmenbedingungen – rechtliche, technische, ethische und markenbezogene Aspekte. Er umfasst das Entscheidungsprotokoll: warum bestimmte Funktionen vorhanden sind, warum andere fehlen, warum Wetten gewonnen und warum Wetten verloren wurden. Er umfasst den Kontext des Kontexts: welche Erkenntnisse woher stammen, wie aktuell sie sind und welches Gewicht ihnen beigemessen werden sollte.

Es handelt sich um einen See und nicht um ein Lagerhaus, da die darin enthaltenen Informationen nicht einheitlich sind; ein Teil davon besteht aus ausgefeilten Strategien, ein anderer Teil aus unverarbeiteten Kundenaussagen, wieder ein anderer Teil aus noch nicht ausgereiften Hypothesen – und all dies ist innerhalb eines gemeinsamen Raums zugänglich, nachvollziehbar und nach Prioritäten geordnet.

Der Product Owner ist (oder wird) für den Context Lake verantwortlich. Die Entwickler tragen dazu bei. Der Scrum Master sorgt dafür, dass die Regeln für dessen Pflege eingehalten werden. Die Stakeholder tragen dazu bei und nutzen ihn als Wissensdatenbank, indem sie Fragen stellen und neue Ideen einbringen. Die Mitarbeiter lesen darin und schreiben, sofern dies gestattet ist, Entwürfe zur Überprüfung durch Menschen wieder hinein. Es handelt sich weder um ein statisches Dokument noch um ein Wiki; es ist ein lebendiges, sich weiterentwickelndes Artefakt – der Ort, an den sich das Team und seine Mitarbeiter wenden, um zu erfahren, warum.

Von der Produktwand zum Kontextsee

Das Konzept eines „Context Lake“ mag Ihnen bekannt vorkommen, da es einige Parallelen zu einem „Data Lake“ aufweist. Darüber hinaus gibt es auch einige Parallelen zum Konzept einer „Product Wall“ oder eines „(Product) Obeya“. Beides sind physische oder digitale Räume, in denen das Team alles, was für das Produkt von Bedeutung ist, an einem einzigen, gut sichtbaren Ort zusammenführt: die Vision, die Strategie, die OKRs, die Roadmap, Kundeninterviews, Wettbewerbsanalysen, in der Entwicklung befindliche Funktionen, offene Probleme, die es zu untersuchen gilt, Erfolgskennzahlen, neue Ideen, beteiligte Personen und Teams sowie die Abhängigkeiten zwischen all diesen Elementen. Alles Relevante an einer Wand, für jeden lesbar, der den Raum betritt.

Machen Sie keinen Fehler: Produktwände und (Produkt-)Obeyas sind hervorragende Vorgehensweisen und wertvolle Ideen. Der Context Lake stellt keine Ablehnung dieser Konzepte dar. Er ist vielmehr eine Erweiterung (oder Weiterentwicklung) derselben für ein Team, in dem nun neben Menschen auch Agenten zum Einsatz kommen. Eine Wand, die dafür konzipiert ist, dass Menschen sie in einem Raum lesen können, ist nicht automatisch eine Wand, die ein Agent über eine API auslesen kann. Der „Context Lake“ ist das, was aus einer Produktwand wird, wenn man sie für jedes Teammitglied – ob Mensch oder nicht – lesbar, nachvollziehbar und abfragbar macht.

Für erfahrene Produktteams, die bereits eine „Product Wall“ oder ein „Obeya“ nutzen, ist der Aufwand gering(er). Ein Großteil der Inhalte liegt Ihnen bereits vor. Sie benötigen drei Schritte: Machen Sie die Inhalte sowohl maschinenlesbar als auch für Menschen lesbar, fügen Sie neben den Artefakten explizite Entscheidungsprotokolle hinzu und kennzeichnen Sie jede Aussage mit dem Konfidenzgrad und der Herkunft. Für Teams, die noch keine „Wall“ aufgebaut haben, ist der „Context Lake“ die moderne Form, auf die Sie vom ersten Tag an hinarbeiten sollten.

Was gehört hinein und was nicht?

Zumindest die folgenden Themen gehören in den Context Lake. Alles andere ist Störsignal oder gehört an eine andere Stelle.

Ausrichtung. Vision, Strategie, OKRs, Produktziel, Wertdefinition, Roadmap und die aktuellen „Option Frame“-Einsätze aus Artikel 3. Die Ebene, auf der es um die Fragen geht: „Warum existieren wir?“, „Wohin gehen wir?“ und „Worauf setzen wir?“.

Einschränkungen. Leitplanken – rechtlicher, regulatorischer, technischer, markenbezogener und ethischer Art. Vernetzte Personen, Teams, Produkte und die Abhängigkeiten zwischen ihnen. Die unverhandelbaren Vorgaben und der Systemkontext, die ein kompetentes Teammitglied – sei es ein Mensch oder ein Agent – ohne ausdrückliche Eskalation einhalten muss.

Erkenntnisse und Einsichten. Kundenbefragungen, Nutzerforschung, Forschungsarbeiten, Wettbewerbsanalysen, Erfolgskennzahlen, Entscheidungsprotokolle (was wurde entschieden, von wem, wann und auf welcher Grundlage), Ergebnisse von Pilotprojekten, Daten zur Akzeptanz, fehlgeschlagene Vorhaben sowie offene Probleme und Ideen, die als Nächstes untersucht werden sollten. Die Ebene der „Das habe ich im letzten Quartal ausprobiert“ und „Das sollten wir als Nächstes untersuchen“-Ideen, die normalerweise in einem Slack-Thread im Sande verlaufen.

Alles andere – Details auf Aufgabenebene, sprintspezifische Umsetzungshinweise, Betriebsdokumentation – gehört nicht unbedingt in den Context Lake. Diese Informationen befinden sich weiterhin in den Tools, in denen sie schon immer zu finden waren. Der Context Lake ist für die Produktebene gedacht, nicht für die Projektebene.

Die Protokollierung von Entscheidungen ist die unscheinbare Disziplin, die dafür sorgt, dass alles andere funktioniert

Eine Gewohnheit hält einen Context Lake mehr als alle anderen am Leben: Notieren Sie sich das „Warum“, wenn Sie eine Entscheidung treffen.

Nicht das „Was“. Nicht das „Wer“. Das „Warum“. Warum haben wir diese Funktion gestrichen? Warum haben wir diese Kohorte für das Pilotprojekt ausgewählt? Warum haben wir den Anbieter abgelehnt? Warum haben wir die höhere Latenz im Austausch für eine einfachere Bereitstellung in Kauf genommen? Ein Entscheidungsprotokoll, das in dem Tool geführt wird, das das Team ohnehin bereits nutzt, und wöchentlich in den Context Lake eingespeist wird, ist die gewinnbringendste Gewohnheit, die sich ein Product Owner in einem KI-gestützten Team aneignen kann.

Der Grund dafür ist einfach: Agenten und neue Mitarbeiter können Ihre Schlussfolgerungen nachvollziehen, wenn sie Ihre Argumentation einsehen können. Sie können Ihre Intuition jedoch nicht nachvollziehen, wenn sie lediglich das Ergebnis sehen. Ein Entscheidungsprotokoll sorgt dafür, dass das Urteilsvermögen des Teams übertragbar wird.

Rückverfolgbarkeit und die Priorisierung von Erkenntnissen

Nicht jede Forschungsarbeit ist gleichermaßen wertvoll. Nicht jede Meinung eines Interessengruppenvertreters hat das gleiche Gewicht. Nicht jedes Kundenzitat ist gleichermaßen aufschlussreich. Ein „Context Lake“ ohne Rückverfolgbarkeit und Priorisierung ist ein Sumpf.

Rückverfolgbarkeit bedeutet, dass jede Aussage im System auf ihre Quelle, ihr Datum und ihren Konfidenzgrad zurückgeführt werden kann. Ein Zitat aus einem Kundeninterview im März wird nicht gleichgesetzt mit einer beiläufigen Bemerkung eines Beteiligten. Das Ergebnis einer Pilotstudie mit n = 50 wird nicht mit einem Bauchgefühl gleichgesetzt.

Erhalten Sie die Artikel von Robbin Schuurman direkt in Ihren Posteingang:
. Melden Sie sich kostenlos bei Medium an, um Updates von diesem Autor zu erhalten.

Geben Sie Ihre E-Mail-Adresse ein:
Abonnieren

„Angemeldet bleiben“ für eine schnellere Anmeldung

Priorisierung bedeutet, dass das Team über eine klare Rangfolge verfügt, welche Erkenntnisse bei welchen Fragen Gewicht haben. Der Product Owner stellt die Auswahl zusammen, das Team diskutiert darüber, und die Mitarbeiter halten sich bei ihren Überlegungen an diese Rangfolge. Eine Erkenntnis mit veralteten Daten und geringer Zuverlässigkeit wird mit Bedacht verwendet – sie wird nicht verworfen, sondern entsprechend gekennzeichnet.

Wo dies innerhalb von Scrum angesiedelt ist

Der Context Lake ersetzt nichts im Scrum Guide. Er erweitert die bestehenden Artefakte.

Das Produktziel, das Sprintziel und das Produkt-Backlog werden umso klarer, je klarer der ihnen zugrunde liegende „Context Lake“ ist. Der Optionsrahmen aus Artikel 3 bezieht seine Informationen direkt aus dem „Context Lake“: Die Zeile „Ergebnis“ verweist auf die Wertdefinition, die Optionen stützen sich auf Einschränkungen, die Wette wird gegen bisherige Erkenntnisse abgewogen, und der Evidenzplan basiert auf dem, was das Team bereits als funktionierend kennt. Die Evidenzüberprüfung aus Artikel 5 fließt zurück in den „Context Lake“: Jedes Ergebnis der Umsetzung, jede Wette, die aufgegangen ist oder nicht, jeder Stresstest durch Stakeholder wird dort festgehalten. Der „Context Lake“ ist das beständige Gedächtnis zwischen den Sprints. Der Sprint ist der Ort, an dem der „Context Lake“ konsultiert und aktualisiert wird.

Kleine Teams, große Teams und der See

Der „Context Lake“ hat je nach Team ein unterschiedliches Gewicht. Ein kleines Team von ein bis drei Personen, das ein einfaches Produkt entwickelt, kann einen Großteil davon mitunter in einem gemeinsamen Gedächtnis behalten. Der „Context Lake“ bleibt schlank. Das Entscheidungsprotokoll ist zwar nach wie vor wichtig, aber der Umfang ist gering. Ein größeres Team in einem komplexen Umfeld – mit mehreren Produkten, teamübergreifenden Abhängigkeiten und einer regulierten Branche – muss proportional in den „Lake“ investieren. Die Kosten einer unterlassenen Investition steigen umso schneller an, je größer und komplexer das Produkt wird.

Ein Praxistest: Wenn ein neuer Product Owner, der am kommenden Montag in Ihr Team eintritt, nach der Lektüre Ihres „Context Lake“ nicht in der Lage wäre, in einer einzigen Besprechung zu erläutern, warum die letzten drei wichtigen Produktentscheidungen getroffen wurden, erfüllt der „Context Lake“ seine Aufgabe noch nicht.

Wie dies in der Praxis aussieht

Kehren wir zu dem SaaS-Onboarding-Team zurück, das bereits in den vorherigen Artikeln behandelt wurde. In einer Welt vor Context Lake trifft das Team im Rahmen der Verfeinerung die Entscheidung, eine vorgeschlagene Social-Login-Funktion zu streichen. Die Entscheidung ist richtig. Sechs Monate später entwirft ein Mitarbeiter einen Eintrag im Product Backlog, in dem er dieselbe Funktion erneut vorschlägt, da er keinen Einblick in die zugrunde liegende Argumentation hat. Ein Entwickler entdeckt dies. Zwanzig Minuten der Verfeinerungssitzung werden darauf verwendet, die Argumentation erneut zu erörtern.

In einer Context-Lake-Umgebung wird die Entscheidung am Tag ihrer Fassung protokolliert. „Social Login zurückgestuft, März 2026. Grund: Ein Pilotprojekt mit einer vergleichbaren KMU-Kohorte im 3. Quartal 2025 zeigte keinen Anstieg der Aktivierungsrate und einen messbaren Rückgang der Vertrauenswerte. Nur dann erneut prüfen, wenn sich das Signal der Unternehmenskohorte ändert.“ Wenn der Bearbeiter einen Eintrag entwirft, liest er zunächst den Lake, markiert die vorherige Entscheidung und schlägt einen anderen Ansatz vor. Die Verfeinerung schreitet schneller voran. Das menschliche Urteilsvermögen wird nicht jedes Quartal neu entdeckt. Es wird erweitert.

Multiplizieren Sie dieses Muster mit der Anzahl der Entscheidungen, die ein Produktteam im Laufe eines Jahres trifft. Das ist der Wert des Context Lake.

Wozu das Produktmanagement wird

Ich gehe davon aus, dass sich die entscheidende Kompetenz eines erfahrenen Product Owners oder Produktmanagers innerhalb der nächsten drei bis fünf Jahre deutlich verändern wird. Weniger Zeitaufwand für die Abwicklung des Backlogs. Mehr Zeitaufwand für die Pflege des „Context Lake“. Weniger Zeitaufwand für die Optimierung des Refinement-Durchsatzes. Mehr Zeitaufwand für die Pflege der Fakten, Rahmenbedingungen und der Historie, auf die sich alle nachgelagerten Prozesse stützen. Das Produktmanagement wird in bedeutendem Maße zu einer Art „Context Engineering“ für das Produkt.

Das ist eine anspruchsvollere, risikoreichere und folgenreichere Aufgabe als die, die die meisten Product Owner heute ausüben. Es ist aber auch eine Aufgabe, die es wert ist, übernommen zu werden.

Vier Maßnahmen, die Sie in Ihrem nächsten Sprint umsetzen können

Die Wende

Seit dreißig Jahren ist das Produkt-Backlog das sichtbarste Artefakt des Product Owners. In einer von KI geprägten Welt ist dies nicht mehr das Artefakt, das das Team auszeichnet. Jeder verfügt über ein Backlog. Agenten können über Nacht eines entwerfen. Was das Team in fünf Jahren auszeichnen wird, sind die Qualität, die Nachvollziehbarkeit und die lebendige Disziplin des Kontexts, von dem aus das Team und seine Agenten argumentieren.

Der Context Lake ist kein neues Tool, das Sie erwerben müssen. Es handelt sich um ein neues Artefakt, das Sie sich zu eigen machen müssen. Je eher das Produktmanagement dies als seine Kernkompetenz betrachtet, desto eher hören die Teammitglieder auf, gut formulierte Ergebnisse zu erstellen, die keinen Bezug zum Produkt haben, und beginnen stattdessen, gut formulierte Ergebnisse zu erstellen, die das Produkt tatsächlich voranbringen.

Nun sind Sie an der Reihe

Führen Sie diese Woche einmal ein Gedankenexperiment durch. Wenn morgen ein erfahrener Agent zu Ihrem Team stoßen würde und nur das lesen könnte, was Ihr Team bereits niedergeschrieben hat – wie gut könnte er dann Ihr Produkt einschätzen? Wenn die Antwort „nicht besonders gut“ lautet, liegt die Lücke nicht beim Agenten. Sie liegt vielmehr darin, was Ihr Team bewusst explizit gemacht hat.

Der nächste Artikel befasst sich mit einem noch heikleren Thema. Wenn der „Context Lake“ die Quelle ist, aus der das Team und seine Akteure Informationen beziehen, wie lässt sich dann die Scrum-Säule der Transparenz aufrechterhalten, wenn die Daten, die Argumentation und immer mehr der Entscheidungen selbst in der KI verankert werden? Und wie wirkt sich das auf die fünf Scrum-Werte aus, wenn das aktivste Mitglied des Teams nachweislich auch ein voreingenommenes ist? Wir sehen uns dort.

Mitwirkende

Dieser Artikel entstand auf der Grundlage der PST-Präsenzveranstaltung Nr. 137 von Scrum.org in Amsterdam. Er wäre ohne die Gespräche mit folgenden Personen nicht möglich gewesen: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton und Karel Smutný. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns.

< Lesen Sie den vorherigen Artikel

Quellen

Der Scrum Guide, Schwaber und Sutherland

„Das wissensschaffende Unternehmen“, Ikujiro Nonaka und Hirotaka Takeuchi

Evidenzbasiertes Management, Scrum.org

Von der Geschwindigkeit zur „Agenteneffizienz“: Evidenzbasiertes Management für das KI-Zeitalter, Scrum.org

Die Definition von Wert steht im Mittelpunkt – Artikel 1 dieser Reihe

Sie können die Verantwortung nicht an einen Beauftragten delegieren – Artikel 2 dieser Reihe

Verfeinerung ist kein Lösungsentwurf – Artikel 3 dieser Reihe

Die Sprint-Review funktioniert nicht – Artikel 5 dieser Reihe

Das Wissen, das Ihrem Team verloren geht – Artikel 6 dieser Reihe

Transparenz und der voreingenommene Teamkollege, Artikel 8 dieser Reihe

Scrum wurde für das durchschnittliche Team entwickelt. Es ist an der Zeit, höhere Ziele anzustreben – Artikel 9 dieser Reihe