Wie kann ein Product Owner seine Rolle gut leben und die Gespräche mit Nutzern, Stakeholdern gut füllen? Wie können gute Gespräche entstehen, die sich in guter Qualität auf das Produkt auswirken?

1. ⇈⇈
Impuls
Die Moderations-Toolbox des Product
Owners

2. ⇈⇈
Wir führen Unternehmen in die Zukunft -
mit modernen Technologien und agiler Organisation.

3. ⇈⇈
TYPISCHE HERAUSFORDERUNGEN DES PRODUCT OWNERS
WELCHE STAKEHOLDER GIBT ES DENN SO?
WAS MACHT EIN GUTES MEETING AUS?
POWERFUL QUESTIONS
SPHÄREN DES EINFLUSSES
WAS IST BEI PRODUCT VISION ERSTELLUNG ZU BEACHTEN?
BEI WORKSHOPS ZUM VALUE PROPOSITION CANVAS?
BEI WORKSHOPS ZUM STORY MAPPING?
WELCHE VERÄNDERUNGEN SOLLTE ES BEI MIR GEBEN?
THANKS!
(Backup: Weighted Decision Matrix, Stakeholder Matrix)
AGENDA

4. ⇈⇈
WELCHE BERGE MUSS ICH ERKLIMMEN?
Kontext: Moderation / Facilitation von Gesprächen und Meetings
➔ Gute Entscheidungen müssen gefunden werden
➔ Abgleich Feature-Ideen vs. Vision
➔ Im Gespräch vom Nutzer her denken
➔ Wenn der “Kunde” != Endnutzer ist
➔ Wie können alle Aufgaben unter einen Hut gebracht werden? Time Management, GTD, Timeboxing
➔ Ich kann / darf nicht priorisieren, Prioritäten kommen “von woanders”
➔ ...

5. ⇈⇈
WER SIND DENN STAKEHOLDER?
Welche Stakeholder / -typen gibt es denn so?
➔ Die User!
➔ Das Management!
➔ Die Fachabteilung(en)
➔ Das (Scrum) Team
➔ Vorstand, Gesellschafter / Eigentümer, …
➔ Test-Abteilung
➔ Betrieb
➔ Gesetzgeber (Regulatorik)
➔ ...
Puh, das sind ganz schön viele ...

6. ⇈⇈
WAS MACHT EIN GUTES MEETING AUS?
Wie kann ein Meeting gelingen?
➔ Klare Ziele, klare Agenda
➔ Klares Tooling (Zettel & Stift, oder Miro/Mural, oder Wiki, …)
➔ Klares Timeboxing
➔ “Insel-Gespräche” durchbrechen / Führung behalten VS “still sein, allen genügend Redezeit geben und dennoch das Heft in der Hand
behalten” (Sind wir noch in der Zeit? Wie viele Agendapunkte haben wir noch? Kommen wir voran? Muss etwas auf den
Rettungsring?)
➔ Auf Brainwriting statt Brainstorming setzen (gut für Introvertierte oder wenn ein Teilnehmer seine Gedanken sammeln möchte)
➔ Auf Konsens verzichten, stattdessen auf Konsent setzen (oder Widerstandsmessung, oder Decider & Resolution Protocol, oder …)
◆ Buchtipp: “Decisive” von Chip & Dan Heath
➔ Ein Wiki nutzen: Protokoll eines Meetings (im Meeting per Screenshare eingeblendet), kurz & knapp, leichtgewichtig, kann auch als
Doku von Workshops genutzt werden, Notifications im Nachgang automatisiert
➔ Für Meeting-Feedback sorgen und als Verbesserung für das nächste Meeting nutzen
◆ ROTI
◆ Plus/Delta
➔ Empfehlung Spiel: Meeting Creatures zum Trainieren

7. ⇈⇈
Oder … häufiger mal fragen. Und nochmal fragen. Und nochmal. W-Fragen sind kraftvoll.
➔ Was ist die GoToMarket-Strategie?
➔ Wie binden wir User Research in den Product Discovery Prozess ein?
➔ Wieviel Zeit wenden wir für User Research auf?
➔ Ab wann wird das Scrum Team in der Product Discovery involviert? (Tipp: Frühzeitig!)
➔ Wie organisieren wir (als Team) die Zusammenarbeit mit Stakeholdern?
➔ Ist unser Product Backlog klein genug?
➔ Wie alt ist typischerweise eine User Story?
➔ Wie ist unsere Lead / Cycle Time?
➔ Wie häufig treffen wir uns zum Backlog Refinement? Ist es genug?
➔ Wie gehen wir mit “Pet Projects” von Stakeholdern um? Wie schaffen wir einen Verhandlungsdialog dazu?
➔ Was ist unseren Stakeholdern wichtig? Wer sind unsere Stakeholder?
➔ Wie sieht unsere DoR und DoD aus? Warum so, und nicht anders?
➔ Verändern wir User Stories, sobald sie im Backlog sind?
Offene Fragen stellen -> Antworten sammeln -> Überlegen, welche Richtung Ihr einnehmen wollt.
Fragen alleine, im (Scrum) Team oder im Meeting mit den Gesprächspartnern stellen.
Stellt klare Fragen! Nichts ist schlimmer als indirekte Fragen. Eine Frage endet mit einem “?”. Punkt. :-)
DIE KRAFT VON FRAGEN

8. ⇈⇈
… und was wir im Team? Wo brauchen wir Stakeholder, um etwas zu erreichen?
Fokussiert euch zunächst auf das, was du als PO und ihr im gesamten Team erreichen könnt.
Gruppenarbeit: Ovale auf Flipchart / virtuelles Whiteboard, und im Team Zettel sammeln, was Ihr selbst erreichen könnt und wo
Ihr externe Unterstützung braucht (und was euch daran hindert, es selbst zu können).
1. Punkte, die ihr selbst in der Hand habt: Umsetzen, angehen, über Wirksamkeit freuen.
2. Visualisieren und mit Extern ins Gespräch gehen
WAS KANN ICH SELBST MACHEN?
TEAM
ICH (PRODUCT OWNER)
STAKEHOLDER / EXTERN / ANDERE

9. ⇈⇈
➔ Ein Absatz, alles drin
➔ Zielgruppe, Bedürfnis der Zielgruppe, Mitbewerb, USPs des Produkts
➔ Product Vision ist Nordstern … und darf gerne regelmäßig angepasst werden (veränderliche Ziele)
➔ “good enough”, leicht & schnell
➔ Schafft Orientierung, Product Features / EPICs dagegen abgleichen
➔ 2h-Workshop, strukturiert durchgeführt: Et voilà. Nicht zu kompliziert denken.
EASY, KLEIN, EINFACH, ALLES DRIN

10. ⇈⇈
➔ Product Goal Scrum Guide
◆ “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The
Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal. A
product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could
be a service, a physical product, or something more abstract. The Product Goal is the long-term objective for the Scrum Team. They
must fulfill (or abandon) one objective before taking on the next.”
Kein Widerspruch zu zB Product Vision. Die Product Vision (im Template siehe Slide vorher) prägt strukturierter aus, was das “long-term
objective” für das Scrum Team ist. Eine Product Vision wird durch die Erwähnung eines (abstrakt gesehen) “Product Goal” im Scrum
Guide damit praktischerweise verankert.
WICHTIG:
1. Ganz egal, welches Product Vision Template ihr nutzen wollt: Macht es. Nutzt es.
2. Eine Product Vision oder ein “Product Goal” ist ein veränderliches Ziel, denn die Ziele eines Produkts können sich ändern.
Berücksichtigt dies!
PRODUCT VISION VS PRODUCT GOAL

11. ⇈⇈
➔ Tolles Canvas Tool, um Kundensicht (Nutzen, Schmerz, Kunden-Job(s)) den eigenen Produkten & Services mit ihren
Nutzen-Stiftungen und Schmerz-Killern gegenüberzustellen
➔ Vorsicht vor Biases: Was ist unsere eigene Phantasie & Wunschdenke, was ist “echte” Realität aus Kundensicht?
➔ Customer Interviews füllen die Kundenseite, entweder asynchron oder direkt im Workshop dabei
➔ Mehrere Canvase ausfüllen, je nach Kundenzielgruppe(n)
➔ Canvas als Orientierungspunkt nehmen und durch die gelieferten Produktinkremente oder LoFi/HiFi-Prototypen verifizieren /
falsifizieren
➔ In regelmäßigen Abständen die Canvase überarbeiten
➔ Lasst euch moderativ begleiten, wenn ihr solch einen Value Prop Canvas erstellt
➔ Investiert im ersten Schritt nicht zuviel Zeit (4-6h Workshop)
➔ Schaut, dass ihr möglichst “echte” Kundensichten bekommt, versucht interne Phantasien / Wunschdenke aufzudecken und
geeignete Experimente für das Validieren / Falsifizieren zu fahren
NICHT DEN EIGENEN PHANTASIEN HINGEBEN

12. ⇈⇈
➔ Schafft Orientierung
➔ Kann beim Schneiden von MVP & Releases helfen
➔ “Walking Skeleton”: Lasst eine sequenzielle Geschichte aus der Sicht des Nutzers erzählen
➔ Ideal:
◆ Die Nutzer im Termin mit dabei haben
◆ Die relevanten Stakeholder mit dabei haben
◆ Gemeinsame Sichten durch den Austausch erzeugen
➔ Dedizierte Moderation
➔ Insbesondere auch Entwickler aus dem Scrum Team dabei, um zu verstehen, was das Bedürfnis der Nutzer ist und was sie durch die
Aktivitäten erreichen wollen
➔ Dauer: Je nach Gesprächsbedarf und Software-Komplexität 6h - 3 Tage
➔ Lebendes Skelett, das beständig erweitert wird
➔ (Bitte fragt nicht nach Tooling - es gibt diverse Systeme u.a. Plugins für zB Jira, Geschmackssache)
STAKEHOLDER GUT EINBINDEN

13. ⇈⇈
➔ Implizite Gedanken explizit machen
➔ Spielräume für Entscheidungen definieren (“Delegation Board” oder andere Tools der Wahl)
➔ Gute Entscheidungsmethoden nutzen (Buch “Decisive”, Weighted Decision Matrix, …)
➔ Über Bedürfnisse sprechen, Raum dafür geben um darüber zu sprechen
➔ Gibt es gerade mehr Value, wenn die Entwickler zB User Stories schreiben? So be it!
➔ Für klare Agenden sorgen und jedes Meeting mit ROTI oder Plus/Delta mit KVP versorgen
➔ In den Schuhen der Stakeholder gehen: Auch Stakeholder sind nur Menschen mit Bedürfnissen und Zielen
◆ Sprecht darüber! Im Team & zusammen mit den Stakeholdern
➔ Kundenbrille aufsetzen - nicht nur ich als PO, sondern wir als Team
… VERÄNDERUNG FÄNGT BEI MIR SELBST AN

14. ⇈⇈
Danke, dass Ihr dabei
wart.
Björn Schotte
bjoern.schotte@mayflower.de
Gesprächstermin vereinbaren:
https://calendly.com/bjoernschotte/austausch

15. ⇈⇈
Nutzen wir zum Beispiel gerne in Architektur-Workshops, wenn unterschiedliche
Business-Kriterien auf unterschiedliche Architektur-Ansätze treffen, bewertet und sich
gemeinsam für eine Lösung entschieden werden soll.
1. Alle Stakeholder in einen Raum
2. Alle Business-Kriterien auflisten
3. Jeder Stakeholder hat n Punkte und kann diese frei auf die Business-Kriterien verteilen
Ergebnis: Eine Rangreihenfolge der Business-Kriterien., die die Gewichtung ergeben
1. Jedes Business-Kriterium in Zeilen, jede Lösungsoption in Spalten
2. Bewertung der Lösung auf Skala -2 -1 0 +1 +2: “Wie gut zahlt diese Option auf das Kriterium ein?”
3. Jede Bewertung mit der Gewichtung multiplizieren und in die Zelle eintragen
4. Am Ende die Zahlen in den Spalten aufsummieren
5. Die Option mit der höchsten Punktzahl ist der Favorit
Es ist okay, sich für eine andere Option zu entscheiden.
Die Entscheidung sollte bewusst getroffen werden.
TOOLS: WEIGHTED DECISION MATRIX

16. ⇈⇈
Beispiel
TOOLS: WEIGHTED DECISION MATRIX
Gewichtung Aktuelle Lösung Eigenentwicklung auf Basis
OS Frameworks X, Y, Z
Kommerzielles System
Kann 300 Varianten im ERP
abbilden
75 -75 (-1) 150 (+2) 75 (+1)
Mobile first-Ansatz 23 0 (0) 23 (+1) 46 (+2)
Ist Open Source / nutzt
überwiegend OS
Komponenten
15 -15 (-1) 30 (+2) -30 (-2)
Kann mit unserer
bestehenden Mannschaft
gut abgedeckt werden
20 40 (2) 0 (0) -20 (-1)
SUMME -50 203 71

17. ⇈⇈
Ich habe lange überlegt, ob ich sie euch empfehlen soll. Ich beschränke mich hier auf die Do’s
and Don’ts.
➔ Im Team mappen ist okay. Aber das ist nur eure Phantasie - sucht den Abgleich, ob es wirklich so
ist!
➔ Eine Stakeholder Map veraltet schnell. Empfehlung Updates alle 2-3 Monate
➔ Kann als 4er-Matrix (Bild rechts) gepflegt werden oder als einfache Wiki-Tabelle (s. unten)
TOOLS: STAKEHOLDER MAP