Schlagwort-Archive: product

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

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.

ddd1

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.

eventstorming

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 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.

storymap

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.

emails

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:

criteria.jpg

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 Gregor Meyenberg ist Product Owner bei Goodgame Studios