Markt und Produkte – Strömungsabriss im Feedbackzyklus

The number one reason for business screwups is the lack of a market need for a new product – Jurgen Appelo.

Eine Priorisierung ist nur eine Momentaufnahme. Die besten Produkte entstehen in der kontinuierlichen Zusammenarbeit mit Kunden. Egal welche Tools und Modelle man verwendet, es bleibt die Frage, wie häufig man dafür mit dem Kunden zusammenkommen sollte.

Agilisten zeigen gerne das Video vom Nordstrom Innovation Lab, um zu verdeutlichen, was agiles Arbeiten eigentlich bedeutet: Ein Entwicklungsteam setzt sich in die Filiale eines Optikers und entwickelt, in direkter Interaktion mit den Kunden, eine App zur Auswahl von Brillen. 

Stefan Roock von it-agile hat in seinem Beitrag über den Agilen Kernzyklus destilliert, was den Kern agiler Zusammenarbeit ausmacht:

Das Umsetzungsteam und der Endkunde arbeiten in möglichst direktem Kontakt. Der Problemlösungskreislauf zwischen ihnen ist so eng wie möglich. Je näher das Vorgehen an diesem Kernzyklus liegt, umso besser wird das Produkt wahrscheinlich den Bedarf des Kunden treffen. 

Nicht jedes Produkt lässt sich wie im Nordstrom Innovation Lab direkt beim Kunden entwickeln, aber oft reisst im Eifer der Entwicklung der Feedbackkanal zum Kunden komplett ab. Kommt man nur am Anfang eines Projektes mit dem Kunden zur Definition von Lasten- und Pflichtenheft zusammen, ist man maximal weit vom Kernzyklus entfernt. Es ist in diesem Fall fast zwangsläufig, dass gegen Ende des Projekts einige böse Überraschungen auf alle Beteiligten warten. Dinge wurden etwa falsch verstanden und nicht geklärt, die Bedürfnisse des Kunden haben sich verändert und/oder mögliche Synergien durch kurze Feedback-Zyklen wurden verschenkt.

Es gibt eine Reihe von Methoden, die Empfehlungen geben, wie man den Feedbackzyklus mit dem Kunden optimal ausgestaltet: Scrum fordert, dass man Mindestens einmal im Monat den Zyklus durchläuft und z.B. im Review ein Teilprodukt präsentiert und auf Basis des Feedbacks die Entwicklung anpasst. Als Framework gibt Scrum aber wenig Hinweise, wie genau die konkrete Ausgestaltung passieren soll (siehe Scrumguide).

Design Thinking oder kurz DT ist ein Ansatz für Produktdesign, der danach strebt, das Optimum aus dem Widerstreit von Kundenbedürfnisse und technischen Möglichkeiten herauszuholen. DT ist damit sehr nah am agilen Kernzyklus dran. Es gibt verschiedene Schulen des Design Thinking. Die d.school der Stanford University z.B. definiert 5 Schritte mit flexibler Reihenfolge:

1. Empathize: Interviews führen, Handlungen beobachten, Menschen in ihrem Kontext verstehen, Gedanken aussprechen, Gefühle offenlegen, Storys suchen
2. Define: Kernproblem synthetisieren, inspirierende Perspektive gewinnen, Kriterien für die Bewertung konkurrierender Ideen festlegen
3. Ideate: Raum der Lösungsmöglichkeiten aufziehen, so viele Ideen wie möglich generieren, Brainstorming, aussichtsreichste Ideen auswählen.
4. Prototype: schnelle, billige Prototypen bauen, die Antworten auf wichtige Fragen für die finale Lösung liefern können. Bsp.: Wand mit Post-its, Rollenspiel, Storyboard,  Bastelei
5. Test: Prototypen den Kunden zeigen und Feedback einsammeln.

Auch Lean Startup ist eine Vorgehensweise um Produkte zu bauen, die optimal auf Kundenbedürfnisse zugeschnitten sind. Im Gegensatz zu Design Thinking betrachtet es Produktentwicklung als strukturiertes Experiment, bei dem im wissenschaftlichen Sinne zuvor aufgestellte Hypothesen überprüft werden. Es gibt 3 Schritte:

1. Build: Ideen schnell in Produkte verwandeln
2. Measure: Reaktionen von Kunden messen
3. Learn: Strategie fortführen oder verändern (pivot)

Jurgen Appelo kombiniert wiederum Design Thinking und Lean Startup zum Innovation Vortex. Dieser “Wirbelsturm” dreht sich in der Geburtsphase eines Business Modells sehr schnell. Man hat bisher nur wenig Erkenntnisse über die Bedürfnisse des Kunden und arbeitet dicht am agilen Kernzyklus, um möglichst schnell seine Annahmen zu validieren. Je stärker das Produkt am Markt etabliert ist, umso langsamer dreht sich der Vortex. Man schmeißt nicht mehr bei jeder neuen Erkenntnis alles über den Haufen, muss mehr auf Bestandskunden, CI, die eigene angewachsene Organisation und andere entstandene Strukturen achten.

Fazit: Eine gute Produktentwicklung erfordert schnelles Feedback vom Kunden. Dieses sollte mindestens einmal im Monat, gerade am Anfang der Entwicklung aber tendenziell schneller passieren. Mit leichtgewichtigen Prototypen sollten die kritischen Hypothesen zum Produkt überprüft werden. 

Der Innovation Vortex ist übrigens Teil des Shiftup-Workshops, den ihr bei mir in Hamburg und demnächst auch online buchen könnt. Informationen dazu findet ihr hier: Shiftup-Workshop.

Literatur

Jurgen Appelo 2019: Startup, Scaleup, Screwup*: 42 Tools to Accelerate Lean and Agile Business Growth (English Edition): Wiley

Michael Lewrick 2018: The Design Thinking Playbook*: Mindful Digital Transformation of Teams, Products, Services, Businesses and Ecosystems: Wiley

Eric Ries 2011: The Lean Startup*: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses: Currency

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Markt und Produkte – Priorisierung

Your most unhappy customers are your greatest source of learning – Bill Gates

Stell dir vor, in deinem Garten steht eine Tulpe, so teuer wie dein ganzes Haus! Im Jahre 1637 bezahlte man in den Niederlanden für bestimmte Tulpenzwiebeln 10.000 Gulden pro Stück, dem Gegenwert eines Hauses in bester Lage in Amsterdam. Das durchschnittliche Jahreseinkommen lag zu der Zeit bei etwa 150 Gulden. Die Tulpenkrise gilt als eine der ersten Spekulationsblasen, bei der Marktpreise erzielt wurden, die weit über dem eigentlichen Produktwert lagen.

Auch wenn es einen Product Owner natürlich freuen kann, wenn sein Produkt hohe Preise erzielt, ist es in der Regel sicherer, dafür nicht auf Spekulationsblasen angewiesen zu sein.  Es gibt auch heutzutage keine unfehlbare Methoden, um vorauszusagen, wie gut sich ein Produkt am Markt verkaufen wird. Was bleibt sind Tools, die dabei helfen, die Beziehung zwischen Produkt und Markt analytischer zu betrachten, als nur auf sein Bauchgefühl zu hören. In der folgenden Tabelle sieht man eine kleine Übersicht solcher Methoden mit Vor- und Nachteilen. Wie Business Value Poker funktioniert, haben wir schon in einem älteren Beitrag beschrieben. Weiter unten werde ich noch auf das Kano-Modell und die RICE-Formel eingehen.

Eine der bekanntesten Methoden hieraus ist das Kano-Modell. Es setzt die Kundenzufriedenheit ins Verhältnis zur Güte der Produkteigenschaften. Hierdurch werden drei Arten von Eigenschaften unterschieden:

Aus einer Tulpenzwiebel sollte eine Tulpe erblühen. Ein Auto sollte mit Steuerrad kommen. Dies nennt man Basismerkmal. Es erscheint einem selbstverständlich, wenn es aber nicht eintritt, ist die Enttäuschung groß.

Blüht eine Tulpe in Regenbogenfarben, könnte es sich um ein Begeisterungsmerkmal handeln. Diese Eigenschaft vermisst man gar nicht, wenn sie nicht da ist. Aber sie begeistert einen, weil etwas sehr besonderes diese Tulpe von der Konkurrenz abhebt. Bei einem Auto würde einen vielleicht eine Funktion begeistern, die völlig automatisch Brötchen holt.

Bei einem Leistungsmerkmal steigt die Kundenzufriedenheit je stärker dieses ausgeprägt ist. Je größer die Tulpe oder je schneller das Auto, umso glücklicher der niederländische (bei der Tulpe) bzw. deutsche Kunde (beim Auto). 

Das RICE-Modell kommt wiederum mit vier Eigenschaften, bzw. Faktoren daher:

• Reach: Wieviele Leute/Events sind betroffen?
• Impact: Impact für eine Person, z.B. 3 für massive, 2 für high, 1 für medium 0.5 für low
• Confidence: Zuversicht bezüglich der Schätzungen … 0-100%
• Effort: Personenmonate / Komplexität aus dem Schätzpoker

Mit folgender Formel kann dann die Priorität für ein Feature berechnen werden.

Aber Achtung, die Formel sollte nicht darüber hinwegtäuschen, dass die einzelnen Werte stark interpretierbar sind. Auf jeden Fall sollte man darauf achten, dass die Bewertung der Features konsistent bleibt und keine Genauigkeit vortäuscht, wo es keine gibt. Es bietet sich an verschiedene Kategorien für die vier Bereiche festzulegen. Etwa die Confidence in 5 Abschnitte von 20% zu zerteilen. Lange über einzelne Prozentpunkte zu diskutieren, ist reine Zeitverschwendung.

Darstellbar ist das RICE-Modell in 4-dimensionalen Matrizen, z.B. mit Achsen für Effort und Impact, Radien gemäß der Reichweite/Reach und einer Farbkodierung für Confidence.

Bei der Auswahl eines Priorisierungsmodells muss man sich der unterschiedlichen Vor- und Nachteile bewusst sein. Die Übersicht in diesem Artikel soll dir dabei als Hilfestellung dienen. 

Über Anregungen und Feedback freue ich mich wie immer sehr.

Literatur

Donald G. Reinertsen 1997: Managing the Design Factory*: A Product Developers Tool Kit: Free Press

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Domain Driven Design (PO-Tools Nr.2)

Hier die Fortsetzung meines Beitrags zu Product Owner Tools.

Domain Driven Design

Für die Modellierung des Produkts bedienen wir uns verschiedener Methoden aus dem Domain Driven Design (DDD), insbesondere Context Maps und Event Storming Workshops:

Context Map

Context Maps können helfen um Rahmenbedingungen zu definieren und/oder zu visualisieren.

In Zusammenarbeit mit dem Entwicklerteam und Domänen Experten modelliert man den Produktkontext und die Schnittstellen zu angrenzenden Bereichen, also welche Fachdomänen von dem Produkt berührt werden und welche nicht.

Event Storming Workshop

Eine Methode zum Ermitteln und Validieren der Kontextgrenzen ist Event Storming: In einem gemeinsamen Brainstorming erschließen sich Entwickler und Fachexperten die Domäne und bringen sich gegenseitig auf ein gemeinsames Verständnis.

Dies sind die grundlegenden Schritte zu dem Vorgehen:

Die richtigen Leute einladen.

Idealerweise benutzt man einen großen Meetingraum mit sechs bis acht Leuten. Es sollten die Personen anwesend sein, die die richtigen Fragen stellen können, in der Regel sind das die Entwickler. Sowie die Personen, die die Antworten dazu haben, die Domänenexperten.

Keine Limitierung

Wenn man eine Domäne noch nicht kennt, kann man auch nicht wissen wieviel Platz man braucht um sie zu modellieren. Deswegen sollte man den Platz nicht begrenzen. Idealerweise bereitet man die Wände des gesamten Raums mit einer Papierrolle vor.

Entdecke die Domäne anhand von Events (Ereignissen).

Events werden immer in der Vergangenheitsform aufgeschrieben. Man verwendet orangene Stickies für die Events und ordnet diese in einer zeitlichen Abfolge. Der Workshop startet mit der Frage an die Domainexperten: “Was ist das für euch wichtigste Event”. Der erste orangene Sticky wird in die Mitte der Wand geklebt. Dann geht es weiter mit der Frage: “Was passiert davor” und “Was passiert danach” usw.

Entdecke die Auslöser von Events

Was muss passieren, damit ein Event eintritt. Manche Events werden durch eine Aktion ausgelöst (Commands). Für Commands werden blaue Stickies verwendet.

Events können durch externe Systeme oder andere Events ausgelöst werden. Für externe Systeme werden pinke Stickies verwendet. Die Auslöser von Events werden an das Event selber geklebt.

Entdecke Aggregate und ordne das Chaos

Hier geht es nicht um Aggregate im technischen Sinne. Es geht darum zusammengehörige Events in Clustern zusammenzufassen. Beispielsweise könnten alle Events die den Shop betreffen zum Aggregat Shop zusammengefasst werden. Aggregate selber können Commands entgegen nehmen und Ereignisse auslösen.

Entdecke Subdomains

Im letzten Schritt werden Aggregate zu Subdomains zusammengefasst. Hier wird ermittelt für welchen Bereich des Prozesses welche Fachexperten zuständig sind. Ausgehend von den Subdomains können dann die Kontextgrenzen und Kontextzusammenhänge definiert werden.

Fortsetzung HIER

Gregor Meyenberg ist Product Owner bei Goodgame Studios

Product Owner Tools – Teil 1

von Gregor Meyenberg

Der Gedanke, dass ich als Produkt Owner meine eigenen Produktideen verwirklichen kann war für mich stets verlockend. Nach einigen Jahren weiß ich aber, dass die Realität der Arbeitswelt meist anders aussieht. In sehr vielen Fällen muss ich die Idee eines anderen übernehmen, mich selbst dafür begeistern, um dann wiederum andere von der Idee begeistern zu können und schließlich das Produkt effizient in die Umsetzung bringen.

Damit das gelingt, ist es wichtig die Intention des geplanten Produktes im Detail zu durchdringen. Wir stellen hier ein paar Tools vor, die sich für Product Owner bei Goodgame Studios (GGS) im Alltag bewährt haben.

Rahmenbedingungen

Bei GGS gibt es verschiedene zentrale Abteilungen, die für die Game-Studios und andere zentrale Bereiche Produkte liefert (Shop, Landing Pages etc.). Sich veränderndende Produktwünsche und -prioritäten sind eine ständige Herausforderung. Anstatt für jedes Produkt ein neues Team aufzusetzen geben wir neue Produkte an bestehende Teams. So verhindern wir einen ständigen Neustart des Tuckman Cycle (Forming – Storming – Norming – Performing).

Der Auftrag

Eine Fachabteilung tritt mit einer neuen Produktidee in der Regel an den Product Owner heran, den sie bereits kennt. Um ein Gefühl für die Priorität zu bekommen, versuchen wir initial den erwarteten Business Value abzuschätzen (Revenue Uplift, Steigerung der Registrierungen, Erhöhung der Retention etc.).

Geht es um ein größere Produktidee entscheiden die Product Owner des Bereichs gemeinsam, welche Teams für die Entwicklung in Frage kommen. Die Entscheidung basiert immer auf dem Wert des neuen Produktes in Relation zu dem Wert der Lieferung, die ein Product Owner bereits in seiner Roadmap geplant hat.

Jeder Product Owner in dessen Team eine Umsetzung  des neuen Produktes Sinn ergibt, liefert drei mögliche Umsetzungsoptionen, legt die jeweiligen Auswirkungen anhand seiner Roadmap dar und listet Vor- und Nachteile für das Unternehmen in einer knappen Zusammenfassung.

Die Gruppe der Product Owner aggregiert die besten Optionen und stimmt sie (bei besonders großem Impact) mit dem Management ab. Dazu betrachten wir insbesondere den “Cost of Delay”. Nach der Entscheidung für eine Option geht der Arbeitsauftrag ins Backlog des gewählten Teams.

Story Mapping

Damit Entwickler, Product Owner und Stakeholder ein gemeinsames Verständnis der Produktidee entwickeln, hilft es gemeinsam die “Geschichte” zum Produkt zu erarbeiten. Gerade zu Beginn eines Projektes führen wir dazu gerne Story Mapping Workshops durch.

Das Big Picture und die Projektziele sollten für alle Beteiligten gut sichtbar gemacht werden, z.B. mit einer Product Wall.

Der “User” sollte immer im Vordergrund stehen. Letztendlich ergibt sich die Daseinsberechtigung der Software daraus, dass sie für jemanden von Nutzen ist.

Insofern kann man sich als Product Owner die zentrale Frage stellen, wessen Leben man zum Positiven verändern will und warum?

Daraus ergibt sich dann der Business Case.

Produktvision

Die Produkt-Vision ist ein Steuerungs-Werkzeug für die Produktentwicklung. Sie ermöglicht es allen Projektbeteiligten immer wieder zu validieren, ob die geplante Arbeit auf die Vision einzahlt.

Produkt-Vision neben dem Team-Taskboard

Eine gute Vision wird oft in intensiven Gesprächen mit den Stakeholdern erarbeitet, z.B. im Zusammenhang mit oben genanntem Story Mapping Workshop. In seinem Management3.0-Buch listet Jurgen Appelo hilfreiche Qualitätskriterien für eine Vision auf:

Zudem orientieren wir uns an den zahlreichen Templates für Product Visionen, wie dem Business Model Canvas oder Roman Pichlers Product Vision Board.

Am Ende sollten sich alle Beteiligten auf die Vision committen, von der Geschäftsleitung bis zum Entwicklungsteam.

Fortsetzung HIER.

Gregor Meyenberg ist Product Owner bei Goodgame Studios