Episodi

  • Hackathons bei OBI: Was Product Owner daraus mitnehmen
    Oct 12 2026
    Hackathons bieten Product Ownerinnen und Product Ownern einen geschützten Rahmen, um Ideen jenseits des Sprintalltags zu erproben. Oliver spricht mit Andrea aus dem IT-Portfoliomanagement und Tech Lead Lukas über die internen Hackathons bei OBI: Wie entstehen aus Ideen Prototypen, welche Rolle übernehmen Product Owner und was lässt sich in die tägliche Produktentwicklung mitnehmen? Außerdem geht es um die Weiterverfolgung der Ergebnisse und praktische Learnings zu Organisation, Kommunikation und Verpflegung.
    Mostra di più Mostra meno
    42 min
  • Wenn KI unsere Juniors ersetzt, wo kommen dann zukünftige Seniors her?
    Oct 5 2026
    Tim und Dominique werfen in dieser Folge die Frage auf was passiert, wenn KI unsere Juniors ersetzt und wo dann die Seniors von morgen herkommen. Recherche, Protokolle, Backlog-Pflege und erste Analysen übernimmt eine KI heute schnell und schon recht brauchbar. Genau diese Aufgaben waren lange der Einstieg für Berufsanfänger:innen auf dem Weg hin zum Product Owner oder Product Manager (genauso in der Projektarbeit). Solche zuarbeitenden Aufgaben und Rollen boten Gelegenheit, eine Fähigkeit nach und nach zu durchdringen, Fehler zu machen und zu beobachten, wie andere auf Basis der eigenen Arbeit entscheiden. Fällt dieser Einstieg weg, bleibt offen, wie Erfahrungen im Berufseinstieg überhaupt erworben werden kann. Irgendwann gehen dann die heutigen Seniors in Product Leadership und C-Level (oder auch in Rente). Und was passiert dann? Senior wird niemand durch die nächste Weiterbildung. Erfahrung wächst durch viele kleine Entscheidungen, durch Feedback und durch Fehler. Man kann sie weder herunterladen, noch per Knopfdruck abrufen. Das Wissen dahinter ist implizit, ähnlich wie beim Fahrradfahren, denn wer das Gleichgewicht hält, kann kaum erklären, wie er das macht. Mit explizitem Wissen geht eine KI natürlich souverän um. Sobald Menschen zusammenarbeiten, braucht es aber ein Gespür für Kontext, für Konflikte mit und zwischen Stakeholdern und dafür, Unsicherheit auszuhalten. Dazu kommt ein leicht zu übersehendes Risiko: Wer neu im Beruf ist, erzeugt mit KI in kurzer Zeit User Stories, Konzepte, Interview-Leitfäden und Protokolle, die erstaunlich gut aussehen mögen. Ob sie taugen, beurteilt nur, wer solche Arbeit schon einmal selbst gemacht hat. Der Automation Bias verschärft das Problem nochmal, denn Menschen vertrauen automatisierten Ergebnissen schnell und prüfen sie zu selten. Brüche und offene Schnittstellen fallen dann spät auf und kosten richtig Geld. Wenn KI unsere Juniors ersetzt, braucht es einen neuen Weg, um Erfahrung aufbauen zu können. Der Ausweg liegt im Wechsel von der Produktionskompetenz zur Entscheidungskompetenz auf Basis von Urteilsvermögen. Ein Ansatz könnte der folgende sein: Berufseinsteiger bekommen besser echte, klar abgesteckte Probleme statt billiger Zuarbeitsaufgaben. Sie nutzen die KI als Werkzeug, begründen ihre Entscheidungen und vergleichen Alternativen. Die Verantwortung wächst Schritt für Schritt, ähnlich wie bei Delegation Poker: erst beobachten, dann mitreden, schließlich selbst entscheiden. Dafür eignen sich kleinere Produkte mit wenigen Stakeholdern. Zwei Jahre als Junior abzusitzen und nur AI-Tools zu bedienen, garantiert dagegen keine Reife. Damit verändert sich die Rolle von Seniors und Führungskräften. Unser Rat: Sie delegieren nicht alle lästige Aufgaben und machen stattdessen ihr Denken sichtbar. Sie fragen die Juniors, warum eine Lösung gut ist, welche Alternativen existieren und was dagegen spricht und sie erklären ihre eigenen Entscheidungen ganz explizit. Das kostet natürlich Zeit, denn über ein Ergebnis nachzudenken dauert länger, als es zu erzeugen. Die Juniorphase wird kürzer, das Mentoring dafür intensiver. Organisationen müssen Nachwuchsentwicklung deshalb als bewusste Investition begreifen, auch wenn der wirtschaftliche Druck zu kurzfristiger Produktivität drängt. Juniors werden nicht verschwinden, es wird sich lediglich ihr Einstieg verändern. Statt kleiner Aufgaben bekommen sie Entscheidungsräume und dazu Reflexionsräume, in denen sie mit erfahrenen Kolleginnen und Kollegen auswerten sollten, was funktioniert hat. Die Leitfrage für jedes Unternehmen lautet daher: Wer ist in drei bis fünf Jahren unser Senior? Folgende ältere Episoden unseres Podcasts passen zu diesem Thema: - Karrierepfad als Product Owner - Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern Wird KI via Automatisierung den Einsteigern wichtige Erfahrungen rauben und dadurch das Wachstum bzw. die Lernreise von Juniors behindern? Was glaubt Ihr?
    Mostra di più Mostra meno
    43 min
  • Hilfe, mein Team arbeitet dauernd an Stories, die gar nicht wichtig sind!
    Sep 28 2026
    Oliver und Tim sprechen in dieser Folge über ein Problem, das vermutlich viele Product Owner kennen: Das Team arbeitet dauernd an Stories, die gar nicht wichtig sind. Der Anlass ist ein Coachingfall. Ein Produktmensch klagt darüber, kaum voranzukommen. Sein Team hat immer zu viel zu tun. Gleichzeitig schreiben die Teammitglieder eigene Tickets ins Backlog. Oder sie ziehen sich Themen selbst von irgendeiner Stelle des Backlog. Manche Stories laufen auch gerne über mehrere Sprints weiter, ohne dass die Developer ein Störgefühl zeigen. Nur passt das selten zur eigentlich notwendigen Produktstrategie des Product Owners bzw. der Produktorganisation. Wenn Teammitglieder selbst Einträge für das Product Backlog schreiben, ist das natürlich erstmal ein absolut gutes Zeichen. Es zeigt echte Selbstorganisation. Schwierig wird es dort, wo diese Einträge ohne Absprache direkt ins Backlog wandern und die Reihenfolge verändern. Genau diese Reihenfolge liegt eigentlich in der Verantwortung der Produktverantwortlichen. Fehlen klare Working Agreements, wer Tickets erstellt und wer sie freigibt, entsteht schnell Unordnung im Backlog. Stories, die gar nicht wichtig sind, bleiben oft über mehrere Sprints liegen. Man möchte begonnene Arbeit ja zu Ende bringen… Das klingt vordergründig vernünftig, kostet aber Steuerungsmöglichkeit. Ein hilfreicher Reflex: Unfertige Einträge wandern konsequent zurück ins Product Backlog. So bleibt die Priorisierung nach Wert erhalten. Die Produktverantwortliche soll dann jederzeit neu entscheiden können, welche Themen gerade wichtiger sind. Hinter dem Punkt "Stories die gar nicht wichtig sind" stecken oft andere Gründe. Häufig fehlt eine klare Produktvision. Technisch geprägte Teams setzen dann eigene (ggf. technische) Prioritäten, weil niemand ihnen die Richtung von oben deutlich genug vermittelt hat. Aber auch andersrum mag technische Komplexität eine Rolle spielen: manche Produktverantwortliche durchdringen die technischen Zusammenhänge nicht gut genug bzw. schaffen es nicht, die fachlichen Zusammenhänge und Notwendigkeiten dem Team gut genug zu vermitteln. Entwicklerinnen und Entwickler treffen dann lieber eigene, technisch motivierte Entscheidungen - schlichtweg weil ihnen der Kontext fehlt. Fehlt zusätzlich eine Scrum Masterin bzw. Agile Coach moderiert oft niemand die nötigen Retrospektiven. Genau dort sollten solche Muster eigentlich auffallen. Auch geringe Präsenz der Produktverantwortlichen im Teamalltag begünstigt die Entwicklung. In dieser Lücke entstehen eigene Gewohnheiten und stille Freiheiten. Fehlendes Refinement und fehlende Sprintziele verstärken den Effekt zusätzlich. Ohne Sprintziel wird im Sprint Planning nie klar, warum ausgerechnet diese eine Story gerade wichtiger sein sollte als jene andere. Am Ende hilft nur Konsequenz: solche Beobachtungen dürfen nicht folgenlos bleiben. Sie brauchen Raum in Retrospektiven, im Refinement und im Sprint Planning. Dazu gehört auch eine Produktvision, die man immer wieder neu erzählt, bis sie beim ganzen Team ankommt (oder allen gefühlt schon zu den Ohren rauskommt). Wer also merkt, dass im eigenen Team dauernd an Stories gearbeitet wird, die gar nicht wichtig sind, sollte das als Alarmsignal für den gesamten Produktentwicklungsprozess verstehen. Oliver und Tim ermutigen dazu, dieses Storytelling auch mit Werkzeugen künstlicher Intelligenz auszubauen. So lässt sich die eigene Produktstrategie in einer Sprache aufbereiten, die im Entwicklungsteam wirklich verfängt. Folgende frühere Episoden werden im Gespräch genannt: - Wenn dein Team dir als Product Owner nicht folgt - Mit Storytelling andere von deinen Produktideen überzeugen - Product Backlog Refinement - Tipps für Product Owner - Product Principles (Produktprinzipien) - Verantwortung als Product Owner übernehmen
    Mostra di più Mostra meno
    39 min
  • Was ist eigentlich das Produkt? - Ein Erfahrungsbericht mit Philipp Weiß
    Sep 21 2026
    Was ist eigentlich das Produkt? Die Frage klingt trivial, ist für viele Product Owner aber alles andere als leicht zu beantworten. In dieser Folge spricht Oliver mit Philipp Weiß, Product Owner der Website bei Transfermarkt.de, über genau diese Frage an einem konkreten Praxisfall. Transfermarkt ist seit 26 Jahren die größte öffentlich zugängliche Fußballdatenbank der Welt, mit Profilen, Marktwerten, News, Forum, Spielen und Tools, in 16 Sprachen, dazu App und B2B-Angebot. Ist bei dieser Bandbreite einfach die ganze Website das Produkt? Und wie lassen sich Produktvision, North Star Metric und Strategie auf dieser Ebene sinnvoll nutzen? Oliver und Philipp gehen mögliche Produktschnitte durch: nach Kanal, nach Inhalt, nach Teamstruktur oder nach Nutzerbedürfnissen. Sie sprechen darüber, was jede Variante für Priorisierung und Zusammenarbeit bedeutet, warum sich Organisationen so schwer von gewachsenen Features trennen und warum der Fokus auf wenige Spielfelder oft wichtiger ist als der perfekte Produktschnitt. Eine Folge für alle Product Owner mit gewachsenen, komplexen Produkten, auch für Hörer:innen ohne Fußballbezug.
    Mostra di più Mostra meno
    43 min
  • Tracken des Nutzungsverhalten
    Sep 14 2026
    In dieser Folge sprechen Dominique und Oliver über das Tracken von Nutzungsverhalten. Dabei geht es darum, warum Produktdaten oft ehrlicher sind als das, was Menschen in Interviews erzählen. Wer Nutzende befragt, bekommt wertvolle Eindrücke, aber auch gefärbte Antworten, denn kaum jemand zeigt sich gerne von einer schwachen Seite. Das Tracken von Nutzungsverhalten liefert die quantitative Ergänzung und zeigt, was im Produkt tatsächlich passiert. Diese Lücke begegnet Produktteams ständig, gerade beim Prüfen von Hypothesen aus der Product Discovery. Nicht jede Funktion braucht die gleiche Tiefe an Beobachtung. Bevor Teams Events, Klicks oder Feldänderungen erfassen, sollten sie klären, welche Entscheidung die Daten unterstützen sollen. Eine Terminverwaltung kann etwa festhalten, wie oft Termine angelegt, verschoben oder abgesagt werden, ohne jede einzelne Eingabe zu protokollieren. Tracking funktioniert am besten, wenn zuerst der gewünschte Outcome feststeht und daraus passende Kennzahlen abgeleitet werden. Verbindet man einzelne Ereignisse über eine Sitzung hinweg, werden Nutzungswege sichtbar. So lässt sich erkennen, wo Menschen aussteigen oder welche Muster sich wiederholen. Im Onlinehandel zeigt ein Funnel beispielsweise, an welchem Schritt des Bestellprozesses Kundschaft abspringt. Auch Kohorten helfen als Unterteilung, um so beispielsweise Unterschiede zwischen neuen und langjährigen Nutzenden zu verstehen. Natürlich gibt es einige Herausforderung beim Tracken: Problematisch wird es, wenn Teams zunächst möglichst viele Daten sammeln und erst danach nach passenden Fragen suchen. Ebenso riskant ist es, Daten nur zur Bestätigung bereits getroffener Entscheidungen auszuwählen. Beides erzeugt Kennzahlen, aber kaum belastbare Erkenntnisse. Auch intensive Nutzung bedeutet nicht automatisch Mehrwert. Sie kann ebenso auf umständliche Bedienung hinweisen. Korrelationen erklären zudem keine Ursachen, und aggregierte Kennzahlen können Unterschiede zwischen Nutzergruppen verdecken. Daten müssen deshalb immer im jeweiligen Kontext interpretiert werden, etwa unter Berücksichtigung saisonaler oder externer Effekte. Entscheidend ist am Ende, ob Tracking tatsächlich Entscheidungen verändert. Werden Daten regelmäßig erhoben, aber nie genutzt, lohnt sich der Aufwand kaum. Dominique und Oliver zeigen anhand vieler Beispiele, dass gute Produktentscheidungen meist aus der Kombination qualitativer und quantitativer Erkenntnisse entstehen. Gezielt eingesetztes Nutzungstracking unterstützt damit eine evidenzbasiertere Produktarbeit. Mehr unter: https://produktwerker.de/tracken-von-nutzungsverhalten/
    Mostra di più Mostra meno
    38 min
  • Product Owner ohne Scrum – Widerspruch oder inzwischen oft Alltag?
    Sep 7 2026
    In vielen Unternehmen kann man erleben, dass Menschen sich Product Owner nennen, obwohl ihr Team längst kein Scrum mehr lebt. Aber verdient ein Product Owner ohne Scrum überhaupt noch diesen Namen? Oder verliert der Titel dann seine Grundlage? In Trainings und Organisationen tauchen diese Fragen immer wieder auf. Die Rolle heißt dort dann oft weiterhin Product Owner, im Alltag bestimmt aber längst Kanban oder ein eigenes, vielleicht sogar informelles Vorgehen das Bild. Historisch wurde der Begriff Product Owner durch Scrum verbreitet und bekannt. Zusätzlich taucht er im Scaled Agile Framework auf, dort allerdings mit einer anderen Bedeutung als im ursprünglichen Scrum Guide. Verschwindet Scrum aus einer Organisation, bleibt die Bezeichnung trotzdem oft bestehen. Sie hat sich auch im deutschsprachigen Recruiting fest etabliert. Menschen suchen nach wie vor deutlich häufiger nach Product Owner als nach Product Manager. Der Rollenname überlebt also das Framework, aus dem er stammt. Wechselt ein Team beispielsweise zu Kanban, lässt sich die Rolle Product Owner meist einfach weiterführen. Kanban selbst lässt offen, wer Prioritäten setzt und Entscheidungen trifft. Schwieriger wird es, wenn mit Scrum auch die Rituale verschwinden. Dabei geben diese Rituale einer Person erst die Möglichkeit, Produktverantwortung wirklich wahrzunehmen. Ohne Sprint Review fehlt der regelmäßige Moment für Feedback und Kurskorrektur. Ohne Retrospektive fehlt der Raum für die Weiterentwicklung der eigenen Zusammenarbeit. Und ohne ein sauber priorisiertes Product Backlog tauchen schnell wieder Listen auf, in denen fast alles gleich wichtig erscheint. An genau diesen fehlenden Kadenzen zeigt sich, wie viel von der ursprünglichen Rollenidee verloren geht, sobald ein Product Owner ohne Scrum arbeiten muss und nichts Vergleichbares an dessen Stelle tritt. Zwischen Product Owner als Rollenbezeichnung und Product Ownership als eigentlicher Produktverantwortung liegt ein wichtiger Unterschied. Product Ownership beschreibt, wie viel Entscheidungsgewalt, Kundennähe und Gestaltungsspielraum ein Mensch oder ein ganzes Team für den Erfolg eines Produkts übernimmt. Das gilt unabhängig vom Framework und unabhängig vom Titel auf der Visitenkarte. Werkzeuge wie das Product Ownership Evolution Model oder eine klassische RACI Matrix machen diese Verantwortung sichtbar, statt sie stillschweigend vorauszusetzen. Wer offen mit Führungskräften und Stakeholdern klärt, wie viel Ownership das Unternehmen tatsächlich überträgt, gewinnt echte Klarheit. Das gilt ganz gleich, ob am Ende Scrum, Kanban oder gar kein Framework im Hintergrund steht. Fehlt diese Klarheit, ziehen sich viele Menschen in vertraute Muster zurück und aus ihnen werden reine Verwalter des Backlogs, obwohl der Titel eigentlich Gestaltung verspricht. Diese Lücke zwischen Erwartung und gelebter Rolle erzeugt bei Betroffenen häufig eine stille Unsicherheit. Besonders dann, wenn eine Organisation den Rollenwechsel nie bewusst und offen kommuniziert hat. Manche Unternehmen begegnen dieser Unschärfe mit einem neuen Namen, etwa Product Lead oder Head of Product. Ein neues Etikett allein schafft dabei aber noch keine Rollenklarheit. Solange niemand Entscheidungsbefugnisse, Erwartungen und den Zugang zu Kundinnen und Kunden ausdrücklich benennt, verändert sich wenig. Dominique und Tim geben eine Empfehlung an alle, die sich in genau dieser Situation wiederfinden: Die Frage nach dem passenden Titel tritt in den Hintergrund, sobald echte Klarheit über Entscheidungsrechte, Erwartungen und Handlungsspielräume entsteht. Wer als Product Owner ohne Scrum arbeitet, sollte diese Klarheit aktiv im eigenen Umfeld einfordern. Sonst bleibt oft nur die stille Anpassung an einen unpassenden Titel. Ob am Ende der Titel Product Owner bleibt oder eine andere Bezeichnung ihn ablöst, verliert dadurch spürbar an Bedeutung.
    Mostra di più Mostra meno
    37 min
  • Was ist ein AI Operating System?
    Aug 31 2026
    Lilith Brockhaus spricht in dieser Folge mit Tim über das AI Operating System. Lilith war bereits vor über drei Jahren zu Gast hier im Podcast, damals ging es um visuelle Entwicklungswerkzeuge ohne Programmierkenntnisse (NoCode bzw. LowCode). Seitdem hat sich bei ihr viel verändert. Mit der neuen Marke O/WONDER beschäftigen sie und ihr Team bei VisualMakers sich jetzt mit agentischer Wissensarbeit. Genau darum dreht sich das Gespräch in dieser Folge: Wie baut man ein eigenes AI Operating System für die eigene Organisation auf, was ist ein AI OS überhaupt und warum lohnt sich das gerade für Product Owner? Ein Operating System, unabhängig von AI, ist das Betriebssystem einer Organisation, vergleichbar mit dem Betriebssystem eines Smartphones oder Macbooks, das die Apps verbindet, ihr Zusammenspiel sicherstellt und im Hintergrund alles zusammenhält. Ein AI Operating System überträgt dieses Prinzip auf eine Organisation. Es macht die DNA eines Unternehmens zugänglich und explizit nutzbar, also die Ziele, Prozesse und Werte, die sonst oft nur implizit vorhanden sind. Tim vergleicht es mit einem Notebook, dessen Betriebssystem die Hardware erst bedienbar macht. Übertragen auf KI heißt das für ihn: Ein Operating System macht das Sprachmodell in einer Organisation erst wirklich einsetzbar, für die eigene Arbeit oder für das gesamte Unternehmen. Ein AI Operating System besteht laut Lilith Brockhaus aus vier Ebenen. Die Basis bildet der Wissenslayer mit Zielen, Prozessen und dem Kontext einer Organisation. Darauf folgt die Systemebene mit den Werkzeugen, in denen Daten entstehen, etwa ein Product Management System oder ein CRM. Die dritte Ebene ist die Ausführung. Hier legt das Team fest, welche Aufgaben die KI eigenständig übernehmen darf, zum Beispiel das Schreiben von Tickets nach einem festen Format. Ganz oben liegt, als vierte Ebene, die Oberfläche, also die Touchpoints, über die Menschen mit dem System sprechen, sei es im Chat, in Slack o.ä. oder direkt im Fachtool. Das Sprachmodell selbst bleibt dabei austauschbar und ist nur die Engine hinter dem eigentlichen System. Lilith beschreibt den Wissenslayer in der Folge als wachsende Bibliothek. Ständig kommen neue Bücher dazu, und ein gutes Verzeichnis sorgt dafür, dass Mensch und KI finden, was sie suchen. KI erkennt Muster in Sprache besonders gut. Dadurch lassen sich auch bisher implizite Entscheidungen sichtbar machen, etwa das Bauchgefühl bei der Priorisierung eines Features. Darin ist auch eine Nähe zu Product Principles und zum Double Loop Learning erkennbar. Dabei trifft eine Organisation nicht nur einzelne Entscheidungen, sie entwickelt auch ihre Entscheidungsregeln selbst weiter. Für den Einstieg mit einem AI Operating System empfiehlt Lilith etwas Pragmatisches. Meetings oder Gespräche mit Stakeholdern transkribieren und sich von der KI nach wenigen Wochen zeigen lassen, welche Muster sie darin erkennt. Als erste Basisdateien nennt sie drei Dinge, den Zweck des Unternehmens, das Ideal Customer Profile und eine Beschreibung des eigenen Angebots. Bei O/WONDER aktualisiert sich das Ideal Customer Profile automatisch anhand anonymisierter Vertriebsgespräche und wächst so mit jedem echten Kundenkontakt weiter. Für die Versionierung setzt das Team auf Git. Das gesamte Unternehmenswissen wird dort wie Code behandelt, inklusive der Nachvollziehbarkeit von Änderungen. Für Product Owner gibt es zwei Rollen in diesem Zusammenspiel. Auf der einen Seite bleibt viel Raum für Stakeholdergespräche, Empathie und Entscheidungen, die ein AI Operating System nicht abnehmen kann. Auf der anderen Seite braucht es Menschen, die genau dieses System bauen, pflegen und mit neuem Kontext füttern. Tim und Lilith sind sich einig: Dafür sind Mut und Neugier nötig, gerade weil viele Organisationen noch am Anfang stehen und es kein fertiges Rezept gibt. Wer selbst ausprobieren möchte, wie ein AI Operating System die eigene Arbeit verändert, findet bei Lilith und O/WONDER einen guten Startpunkt.
    Mostra di più Mostra meno
    48 min
  • Product Backlog Priorisierung, wenn Aufwand nicht mehr die Bremse ist?
    Aug 24 2026
    In dieser Folge sprechen Oliver und Dominique über Product Backlog Priorisierung in einer Zeit, in der Aufwand als Bremse mehr und mehr als Kriterium verschwindet. Wenn KI Agenten Features nahezu ohne Realisierungsaufwand bauen, verliert das klassische Rechenspiel aus Wert geteilt durch Aufwand seine Grundlage. Genau diese Verschiebung nehmen die beiden zum Anlass, gängige Priorisierungsmethoden neu zu hinterfragen und erklären, was sich dabei in der Welt der Product Owner verändert. Viele bekannte Priorisierungsformeln setzen Aufwand in den Nenner. Das gilt für den klassischen Vergleich von Wert und Aufwand genauso wie für Ansätze wie Weighted Shortest Job First (WSJF). Überall steckt die Annahme drin, dass Entwicklungszeit eine knappe Ressource bleibt. Sinkt der Aufwand durch KI gestützte Entwicklung Richtung Null, verlieren diese Formeln ihre Rechengrundlage. Product Backlog Priorisierung braucht dann andere Kriterien, denn eine Reihenfolge bleibt trotzdem nötig. Selbst mit vielen parallelen Agents entstehen Abhängigkeiten zwischen Ergebnissen, die eine Sortierung weiterhin erzwingen. Ohne Aufwand als Korrektiv droht das Product Backlog zur reinen To do Liste einer reinen Product Delivery zu werden. Alles, was sich schnell umsetzen lässt, wird dann einfach abgearbeitet. Matt LeMay beschreibt in seinem Buch "[Impact-first Product Teams](https://mattlemay.com/books)" genau diese Gefahr der sog. "Death Spiral". Viele kleine, wirkungsarme Dinge machen ein Produkt am Ende schwerer wartbar und schwerer weiterentwickelbar. Wer sich nur auf kleine, billig gebaute Dinge konzentriert, ohne vorher zu klären, ob sie überhaupt Wert erzeugen, verliert genau diese Fähigkeit. Die eigentliche Frage lautet nicht, was sich bauen lässt, sondern was es wert ist, gebaut zu werden. Als Ersatz für Aufwand bringt Oliver einen Artikel von Jeff Gothelf ins Gespräch. Der Titel lautet [How to prioritize your backlog when effort is no longer the constraint](https://jeffgothelf.com/blog/how-to-prioritize-your-backlog-when-effort-is-no-longer-the-constraint/). Gothelf schlägt zwei Kriterien vor, die in bestehenden Priorisierungsformeln einfach die Spalte für Aufwand ersetzen können. Das erste Kriterium ist der Lernwert, also wie viel Erkenntnis die Umsetzung eines Backlog Items über Nutzerinnen, Markt oder Technik bringt. Das zweite Kriterium ist die Umkehrbarkeit, angelehnt an Jeff Bezos bekannte Unterscheidung zwischen leicht rückgängig zu machenden und kaum revidierbaren Entscheidungen. Aus beiden Achsen entsteht eine Matrix mit vier Feldern, die ganz unterschiedliche Umgänge mit Backlog Einträgen nahelegt. Hoher Lernwert und leichte Umkehrbarkeit markieren den Bereich, in dem sich schnelles, KI gestütztes Bauen besonders lohnt. Hier reicht es, zu bauen, zu messen und bei Bedarf wieder zurückzudrehen. Hoher Lernwert bei schwerer Umkehrbarkeit verlangt dagegen mehr Vorsicht. Oliver und Dominique sprechen über kleinere Spikes, Prototypen oder Fake Door Tests. Diese liefern genau den hohen Lernwert und lassen sich trotzdem leicht wieder zurücknehmen. Niedriger Lernwert kombiniert mit schwerer Umkehrbarkeit gilt beiden als das heikelste Feld überhaupt. Bleibt der Lernwert niedrig und die Entscheidung leicht umkehrbar, lohnt sich meist ein schneller Versuch ohne großen Abstimmungsaufwand. Gerade weil Bauen so günstig wird, gibt es die Gefahr von unreflektierten, teuren Entscheidungen. Wie schmerzhaft eine Umkehrung tatsächlich ausfällt, lässt sich selten allein am Schreibtisch beurteilen. Diese Einschätzung gelingt nur im Gespräch mit denjenigen, die Architektur und technische Realisierung im Detail kennen. Politische oder hierarchische Diskussionen um laute Stimmen und große Budgets lösen die beiden Kriterien ohnehin nicht auf. Sie verschieben aber den Fokus dieser Gespräche weg vom Aufwand hin zu Lernwert und Rückabwicklungsfähigkeit. Genau das verändert nach Einschätzung der beiden auch den Ton solcher Diskussionen.
    Mostra di più Mostra meno
    46 min