Am zweiten Tag der Product Owner Days ging es um das Outcome Based Roadmaps, die Nutzung von Bedürfnissen und Erwartungen, Yoga- und Star Wars-Prinzipien für Product Owner:innen, das Product Operating Model von Marty Cagan und Erfahrungen aus den ersten Tagen eines Startups.
In diesem Beitrag findest Du die Zusammenfassungen der einzelnen Beiträge, die ich mir angehört habe.
Outcome Based Roadmaps
Büşra Coşkuner eröffnete den zweiten Tag mit ihren Erfahrungen mit Outcome Based Roadmaps. Die wesentliche Aufgabe von Produktmenschen ist es das Richtige zu bauen. Das bedeutet eine Abkehr von der Umsetzung von Features und eine Zuwendung zur Lösung von Problemen. Eine der wichtigen Methoden dafür sind Outcome Based Roadmaps.
Eine Outcome Based Roadmap ist ein strategisches Planungstools, die die Umsetzung der Produktstrategie konkretisieren, indem sie aufzeigt, wie die Produktvision erreicht werden soll möchte. Diese Roadmaps orientieren sich dabei an messbaren Veränderungen im Verhalten oder Zustand von Kund:innen oder Unternehmen und nicht nur an der Auslieferung spezifischer Produktfunktionen. Roadmaps sind weder Release-Pläne noch Projektpläne. Pläne & Backlogs leiten sich aus Roadmaps ab.
Outcomes beschreiben die Veränderung eines Verhaltens oder eines Zustands für Kund:innen, Anwender:innen oder Unternehmen. Sie können quantitativ oder qualitativ beschrieben werden. Eine quantitative Beschreibung basiert auf Metriken. Eine qualitative Beschreibung beinhalten Formulierungen darüber, was angefangen, aufgehört oder besser gemacht werden sollen. Beispiele:
- „Den Produktkatalog häufiger öffnen.“,
- „Anfangen die Produktseite häufiger zu teilen.“
Die Formulierung von Outcomes basiert auf einem übergeordneten Produktzielen, das von einem Geschäftsziel abgeleitet wurde. Sie definieren, woran der Fortschritt in Richtung des Ziels gemessen werden kann.
Bei der Entwicklung der Roadmap empfiehlt Büşra in folgenden Schritten vorzugehen:
- Warum: Das übergreifende Ziel beschreiben, z.B. „Durchschnittlichen Einkaufswert vor Retoure erhöhen“
- Wer: Auf eine Haupt-Zielgruppe fokussieren, z.B. „Bestandskund:innen, die Hochzeitskleidung kaufen.“
- Product Objectives: Produktziele für die Erreichung des übergreifenden Ziels sammeln, z.B. „Menschen sollen mehr Produkte in den Warenkorb legen und kaufen“.
- Outcomes: Definieren, was im nächsten Quartal erreicht werden soll. Das können Hypothesen, konkrete Outcomes oder Metriken sein. Beispiele: „Bestandskund:innen sollen mehr Items sehen.“, „Bestandskund:innen sollen mehr relevante Produkte finden.“, „Bestandskund:innen sollen mehr zusammenpassende Produkte sehen.“, „Das Shopping-Erlebnis verbessern.“
- Wie: Erkenntnisse aus User Research und bestehenden Nutzungsdaten sammeln und daraus Möglichkeiten für Lösungen ableiten.
- Lösungsideen: Lösungsideen gesammelt, z.B. „Rabatte“, „Gutscheine“, „Passende Produkte im Warenkorb anzeigen.“
- Wann: Es werden die konkreten Meilensteine beschrieben. Eine Outcome Based Roadmap beinhaltet keine fixen Termine, sondern Zeiträume, z.B. Quartale.
- Research & Discovery: Definition von Risiken und Forschungsbedarfen.
Eine der größten Herausforderungen bei der Erstellung von Outcome Based Roadmaps ist die Tendenz, schnell von der Problemidentifikation zur Lösungsfindung zu springen. Büşra empfiehlt für den Fall, dass das passiert, Lösungsideen nicht abzuwürgen, sondern aufzunehmen und die Diskussion wieder zurück zum Problemraum zu moderieren.
Die Roadmap sollte für die verschiedenen Stakeholder (z.B. CEO, Vertrieb, Produktmarketing, Entwicklungspartner, Kund:innen) gezielt aufbereitet werden. Sie besteht am Ende aus unterschiedlichen Sichten, die bei der Arbeit damit oder bei der Kommunikation helfen.
Roadmaps sollen Orientierung geben, sorgen für ein gemeinsames Verständnis und kommunizieren das Wozu, sie verbinden die Sichten von Unternehmen und Kund:innen, sie helfen das Richtige zu tun und sie relativieren Diskussionen.
Buchtipp: Product Roadmaps Relaunched
Wie Du Produkte entwickelst, die Anwender:innen lieben.
In meinem Vortrag bei den PO-Days habe ich mich damit beschäftigt, wie man Produkte entwickelt, die Anwender:innen nicht nur nutzen, sondern auch lieben. Bei DATEV haben wir uns intensiv damit auseinandergesetzt, wie Bedürfnisse und Erwartungen der Kund:innen in den Mittelpunkt unserer Produktentwicklung gestellt werden können, um positive User Experiences zu schaffen, die sowohl unsere Mitglieder und Kund:innen als auch DATEV erfolgreich machen.
Eines habe ich dabei gelernt: Der Schlüssel zu erfolgreichen Produkten liegt nicht mehr allein in technologischen Innovationen – diese sind heute oft zu kostspielig, um als Alleinstellungsmerkmal zu dienen. Vielmehr werden Produkte begehrenswert, wenn sie ein echtes Bedürfnis erfüllen und das Nutzererlebnis die Erwartungen übertrifft. Dabei ist es entscheidend, interdisziplinäre Teams zu bilden, die Technologie, Fachwissen und Design harmonisch verbinden, um Erwartungen nicht nur zu erfüllen, sondern zu übertreffen.
Ich habe betont, wie wichtig es ist, hinter die Fassade zu schauen und das “Warum” hinter bestimmten Tätigkeiten zu ergründen. Die “Jobs to be done”-Methode hilft dabei, die wirklichen Bedürfnisse der Kund:innen zu verstehen und Produkte zu entwickeln, die diese Bedürfnisse adressieren. Doch nicht alle Bedürfnisse sind gleich wichtig. Durch quantitative Validierung kann sichergestellt werden, dass in die Bedürfnisse investiert wird, die für Kund:innen am wichtigsten sind.
Ein tiefes Verständnis für Kund:innen und regelmäßiger Kontakt sind das Fundament, auf dem Etnwicklungsteams aufbauen sollten. Dabei ist es entscheidend, aus jeder Interaktion zu lernen und unsere Annahmen kontinuierlich zu hinterfragen. Experimente spielen eine große Rolle bei der Entwicklung von Produkten, die wirklich begeistern. Sie helfen zu verstehen, was wirklich Wert für Kund:innen liefert, wie es sein muss, damit es verstanden wird, was technisch machbar ist und was wirtschaftlich für das Unternehmen nötig ist. Es geht darum herauszufinden, wie die verschiedenen Anforderungen in Einklang gebracht werden können.
Abschließend habe ich die Bedeutung des kontinuierlichen Lernens hervorgehoben. Die Fähigkeit, schnell auf Basis von Kundenfeedback zu reagieren und Produkte anzupassen, ist essentiell. Dafür brauchen wir eine technische Infrastruktur, die es uns ermöglicht, Feedback effektiv und direkt nach der Nutzung zu sammeln sowie ins Team zu tragen. So schaffen wir es, Produkte zu entwickeln, die nicht nur genutzt, sondern auch geliebt werden.
Zusammengefasst waren meine wesentlichen Aspekte, die man betrachten sollte, um Produkte zu entwickeln, die Anwender:innen lieben:
- Bedürfnisse & Erwartungen analysieren und verstehen
- Neue Vorhaben sollten ein untererfülltes Bedürfnis erfüllen
- Team kompetent aufstellen
- Experimentieren und Validieren
- Die Journey aus Anwendersicht ganzheitlich betrachten.
- Kontinuierliches Lernen auf Basis von Kundenfeedback & -verhalten
Möge die Macht mit dir sein – was Product Owner von Yogis und Jedi lernen können
Nadja Deuerlein (BRZ Software) sprach in ihrem Beitrag über Skills für Product Owner:innen. Spannend fand ich dabei, wie Nadja Parallelen zwischen den Lehren von Yoga sowie Jedi-Rittern und der Welt des Produktmanagements zog. Sie konnte damit sehr unterhaltsam veranschaulichen, wie Selbstachtsamkeit, Balance und Disziplin die Arbeit von Product Ownern bereichern können.
Die wesentlichen Erkenntnisse aus ihrem Vortrag waren für mich:
Subjektivität der Wahrheit: Wie Yogis lehren, ist die Wahrnehmung von Realität subjektiv und kann stark variieren. Product Owner:innen sollten sich dieser Vielfalt der Perspektiven bewusst sein und offen für die Meinungen anderer bleiben, um ein umfassenderes Bild der Bedürfnisse ihrer Stakeholder und Nutzer zu erhalten.
Teilen von Wissen: Ähnlich wie die Jedi, sollten Product Owner:innen ihr Wissen mit dem Team und Stakeholdern teilen, um gemeinsam bessere Lösungen zu finden.
Fehler als Lehrer: In beiden Philosophien werden Fehler und Versagen als wichtige Lernchancen gesehen. Diese Perspektive hilft Product Ownern, eine positive Fehlerkultur zu fördern, aus Misserfolgen zu lernen und kontinuierlich zu verbessern.
Energie effizient nutzen: Sowohl Yogis als auch Jedi betonen, dass es wichtig ist Energie sinnvoll einzusetzen. Product Owner:inner sollten ihre Ressourcen gezielt für die wichtigsten Aufgaben nutzen und nicht nach Perfektion zu streben, sondern nach wirksamen Lösungen.
Entscheidungen und Handlungen: Inspiriert von Yoda’s Worten „Tu es oder tu es nicht. Es gibt kein Versuchen“, sollten Product Owner klare Entscheidungen treffen und diese konsequent verfolgen.
Selbstachtsamkeit: Der Vortrag betonte, wie wichtig es für Product Owner:innen ist, aus sich selbst zu achten, ihre eigenen Grenzen zu erkennen und sich kontinuierlich weiterzuentwickeln.
Transformed: Das Product Operating Model
Sohrab Salimi (Agile Academy) sprach in seinem unfassbar guten Vortag über den super-modernen Ansatz „Product Operating Model“. Dieser stammt von Marty Cagan und wurde erst am Vortag veröffentlicht.
Wenn man sich mit der Organisationsentwicklung von bestehenden Unternehmen beschäftigt, sollte man immer davon ausgehen, dass die diese Unternehmen, insbesondere, wenn es sie schon länger gibt, viel richtig machen. Bei der Organisationsentwicklung geht es meistens nicht darum, die negativen Dinge aufzuzeiten. Es geht darum mit neuen Modellen und Vorgehensweisen die Messlatte höher zu setzen.
Bei der Organisationsentwicklung ist nicht nur wichtig, was man tut, sondern auch in welcher Konsequenz bzw. mit welcher Disziplin. Erfolgreiche Unternehmen, zeichnen sich dadurch aus, dass sie:
- Freiräume für Veränderung schaffen,
- Entscheidungen dezentralisieren,
- Fokus auf die relevanten Themen setzen,
- Nicht an alten Sachen festhalten,
- In kurzer Zyklen Experimentieren, um Unsicherheit zielgerichtet zu eliminieren und
- durch Product Discovery lernen und Mitarbeitende zu häufigen Kontakten mit Kund:innen ermutigen.
Das Product Operating Model ist kein Prozess oder Framework. Es ist ein konzeptionelles Modell, welches die Muster aufzeigt, die die besten Unternehmen von anderen unterscheiden. Es betrachtet drei wesentliche Fragen:
„Wie machen Unternehmen Delivery?“
Die Art und Weise, wie diese Unternehmen liefern, bildet eine wesentliche Rahmenbedingung. Erfolgreiche Unternehmen liefern sehr häufig und regelmäßig ihre Produkte mit Mehrwert für ihre Kund:innen aus. (Amazon beispielsweise mehrere tausend Mal am Tag) Die Teams müssen dafür selbstorganisiert sein, Entscheidungen selbst treffen können, den Erfolg ihre Ergebnisse selbst monitoren und interdisziplinär aufgestellt sein. Sie müssen über alle Fähigkeiten verfügen, um eine hohe Liefergeschwindigkeit zu erreichen. Dadurch können diese Unternehmen schnell Feedback einsammeln und lernen.
„Wie machen Unternehmen Discovery“
Die Art und Weise, wie Unternehmen Probleme lösen, ist der zweite Aspekt. Hier geht es darum, dass Teams keine Features genannt bekommen, die sie bauen sollen, sondern Probleme, die sie lösen sollen. Eine gute Discovery und Lösungsfdindung setzt einen regelmäßigen Kundenkontakt voraus.
„Wie entscheiden Unternehmen, welche Probleme gelöst werden sollen.“
In vielen Unternehmen werden solche Entscheidungen vom Top-Management getroffen. Die Herausforderung dabei ist, dass das Top-Management in der Regel zu weit weg von den Problemen ist und zu wenig Kontakt mit Kund:innen hat, um kompentent darüber entscheiden zu können. In erfolgreichen Unternehmen haben Top-Manager:innen regelmäßig Kontakt mit Kund:innen.
Erfolgreiche Unternehmen dezentralisieren Entscheidungen. Sie bringen diese an die Stelle im Unternehmen, an dem sie kompetent entschieden werden können. Dafür brauchen die Entwicklungsteams, in denen entschieden wird, Mut. Sie müssen den Kontext kennen und brauchen eine Orientierung, wo sich das Unternehmen hin entwickeln will. Diese Orientierung und der Kontext kommen aus den Top-Management.
Führungskräfte müssen viel Zeit dafür Aufbringen, dass Teams entscheidungsfähig werden. Sie müssen ein Sicherungsnetz schaffen, damit Mut entstehen kann. Sie müssen für den Aufbau der nötigen Kompetenzen sorgen. Das geht nicht schnell. Dafür braucht es in der Regel Jahre.
Plötzlich entflammt eine Nicht-Software Idee – einfach aus dem Nichts starten
Kerstin Neumann berichtete in ihrem Vortrag von dem spannenden Prozess der Entwicklung und Umsetzung einer Produktidee außerhalb des Softwarebereichs. Kerstin teilte ihre persönlichen Erfahrungen und die Herausforderungen, die sie bei der Verwirklichung einer Produktidee, die plötzlich und unerwartet entstand, meisterte.
Die Kernpunkte des Vortrags waren:
Auslöser und Inspiration: Ein emotionales Erlebnis mit einem existierenden Produkt, das ein Bedürfnis weckte, jedoch nicht erfüllte, diente als Initialzündung für Kerstins Produktidee. Diese Erfahrung unterstrich die Bedeutung, Produkte zu entwickeln, die tatsächlich durchdacht sind und die Bedürfnisse der Nutzer erfüllen.
Erste Schritte und Prototyping: Kerstin betonte, wie wichtig es ist, mit dem zur Verfügung stehenden Wissen und Ressourcen zu beginnen und schnell in die Phase des Prototypings einzusteigen, um die Idee greifbar zu machen.
Problem- und Lösungsraum: Ein wesentlicher Teil des Prozesses bestand darin, den Problemraum gründlich zu erforschen, um sicherzustellen, dass die Lösung wirklich ein relevantes Bedürfnis adressiert. Dies beinhaltete qualitative Interviews und den Einsatz von Personas zur besseren Definition der Zielgruppe.
„Löse Dich von Deiner Lösungsidee, auch wenn Du sie mega findest.“
Feedback und Iteration: Die Wichtigkeit des Feedbacks von potenziellen Nutzern und die Bereitschaft, sich von der ursprünglichen Lösungsidee zu lösen, waren entscheidend für die Weiterentwicklung des Produkts. Prototypen-Tests lieferten wertvolle Einblicke, die zur Anpassung und Verbesserung des Produkts führten. Durch das Ausprobieren mit potentiellen Kund:innen entstanden schnell erste Fans.
Überwindung von Herausforderungen: Kerstin sprach über die Schwierigkeiten, die mit der Herstellung eines physischen Produkts verbunden sind, wie zum Beispiel die Auswahl der Materialien und die Sicherstellung der Machbarkeit. Auch die Wichtigkeit der Dokumentation für die Sicherheit und Geschwindigkeit im Entwicklungsprozess wurde hervorgehoben.
Skalierung: Die Anzahl der Themen, um die man sich in einem Startup kümmern muss, nimmt schnell zu. Neben der Produktentwicklung muss man sich beispielsweise um die Produzierbarkeit, Planung der Markteinführung, Vertrieb, Preisgestaltung, Schutzrechte und vieles mehr kümmern. Auch wenn am Anfang noch alles klar und überschaubar erscheint, so wird doch bald eine Priorisierung nötig.
Pläne ändern sich, schnell: Wenig läuft am Anfang so, wie man es sich vorstellt und plant. Man muss immer wieder umplanen und Entscheidungen in Unsicherheit treffen. Man muss immer wieder Business-Risiken eingehen, um Geschwindigkeit zu erzeugen und Flaschenhälse aufzulösen.
Siehe auch
- Gesamtfazit zu den Product Owner Days 2024
- Tag 1: Produktmanagement für Infrastruktur, Opportunity Solution Tree, Führungskompetenzen, Wettgrößen & PO-Rolle
