Der Lean-Productmanagement-Zyklus – 4. Setzen des Feature-Sets für das Minimal Viable Product (MVP)

Dieser Artikel beschäftigt sich mit dem 4. Schritt des Lean-Productmanagement-Zyklus.

Einen Überblick über den Lean-Productmanagement-Zyklus finden Sie hier.

4. Setzen des Feature-Sets für das Minimal Viable Product (MVP)

Da in der digitalen Produktentwicklung agil und iterativ inkrementell vorgegangen werden kann, und sich diese Methode als Best-Practice für komplexe Produkte herausgestellt hat, ist es auch beim Lean-Productmanagement so, dass ein Minimales Feature-Set ausgewählt wird und dieses dann laufend verbessert und erweitert wird. Wir sprechen also von der Entwicklung von MVPs und das damit verbundene Experimentieren und sammeln von Wissen und Informationen um weitere Verbesserungsmaßnahmen umzusetzen und den Product-Market-Fit zu optimieren. Auch hier ist die die Priorisierung und Fokussierung auf Kernfunktionalitäten entscheidend. Wir wollen ein Minimal Viable Product¹, weil die Implementierung des gesamten Wertangebots zu lange dauern würde und sich somit das Risiko, dass wir in die falsche Richtung entwickeln, massiv erhöhen würde. Als Leitsatz könnte hier dienen, dass wir schnelles Feedback vom Markt wollen und diesen Wissensgewinn über Funktionalität des Produkts stellen.

Am Anfang ist es sogar noch ratsam das ganze nicht Minimal Viable Product zu nennen weil die Eigenschaft „viable“, also „lebensfähig“ noch nicht bewiesen ist. In der ersten Iteration ist es also viel mehr ein MVP-Kandidat der erst beweisen muss, dass er einen Mehrwert für Kunden liefert und diese bereit sind dafür zu bezahlen.

Doch wie kommen wir jetzt zu den Feature-Set für das Minimal Viable Product?

Bis zu diesem Schritt haben wir uns als Produktentwicklungsteam im Problembereich aufgehalten, und wertvolle Informationen von Vertretern unserer Zielgruppen gesammelt und daraus Hypothesen und Wertangebote unseres Produkts formuliert. Jetzt ist jedoch die Zeit gekommen in den Lösungsbereich zu wechseln. Das Umsetzungsteam muss jetzt gemeinsam mit dem Produktmanagement so viele Feature-Ideen für die geplanten Wertangebote finden wie möglich. Dies kann durch Brainstorming oder andere Kreativmethoden geschehen. Sind genügend Ideen für Features zusammengetragen können diese in Product-Backlog-Items (PBIs) überführt werden und priorisiert bzw. ausgewählt werden. In diesem Schritt ist vor allem darauf zu achten, dass die zu erstellenden PBIs mit passender User-Story erstellt werden; und dabei ist insbesondere auf den Mehrwert und das Why des Features zu achten. Es ist schließlich das Ziel, am Ende dieses Schrittes 2-3 Kernfeatures identifiziert zu haben die den größten Mehrwert für den Kunden liefern.

Aufbau von Product-Backlog-Items (PBIs)

Product-Backlog-Items bestehen im Idealfall aus mehreren Teilen. Je nachdem in welcher Phase der Produktentwicklung wir uns befinden können und sollen diese mehr oder weniger detailliert sein. Dabei ist auch die Umsetzungsmethode ein starker Einflussfaktor. Bei Scrum beispielsweise werden PBIs im Refinementmeeting nocheinmal mit dem Team überarbeitet und mit wertvollen Informationen angereichert. Für die ersten PBIs in frühen Iterationsphasen des Lean-Productmanagement-Zyklus ist ein hoher Detaillierungsgrad noch nicht sinnvoll. Mindestens sollten PBIs aber

eine User-Story,
eine kurze Beschreibung,
Akzeptanz-Kriterien,
Story-Points,
Value-Points
ggf. Mockups/Wireframes

enthalten.

Die User-Stories werden in einem Satz mit folgenden Aufbau festgehalten:

„As a <userrole>, I want to <do something>, so that I can <desired benefit/need>.“

Die Granularität der PBIs ist beim Aufbau eines Backlogs entscheidend. PBIs sollten nicht zu groß und nicht zu klein sein. Die Faustregel ist, dass sie noch leicht überschaubar sind, und in wenigen Arbeitstagen/Arbeitswochen vom Team umgesetzt werden können., sodass sie leicht innerhalb einer Iteration (eines Sprints) umgesetzt werden können. Um den Wert (Value) einordnen zu können und Story-Points vergeben zu können, kann es auch hilfreich sein die PBIs in die drei Kategorien des Kano-Modells einzuordnen² (vgl. siehe „Der Einsatz des Kano-Modells in der Entwicklung digitaler Produkte“):

Must-Have-(Basis-)Features,
Leistungs-Feature
Begeisterungs-Feature.

Dabei kann jedes PBI mit dem entsprechenden Tag #MustHaveFeature, #Leistungsfeature oder #BegesiterungsFeature versehen werden. Um nun auch noch den Return On Investment (=ROI) zu ermitteln müssen die PBIs noch geschätzt werden.

Beim Schätzen von Story- und Value-Points ist es ratsam gerade am Anfang des Lean-Productmanagement-Zyklus auf geeignete Schätzmethoden zurückzugreifen. So kann es Sinn machen am Anfang eine Magic-Estimation oder ein Estimation-Game zu machen.

Erst wenn das Backlog auch diese Informationen aufweist, kann der ROI berücksichtigt werden.

ROI = (geschaffener Mehrwert – Aufwand) / Aufwand

Wenn wir also wissen welches Features den besten ROI hat und den meisten Mehrwert für den Kunden darstellt, kann das Feature-Set für den MVP-Kandidaten fixiert werden.

Dazu empfiehlt es sich die PBIs in die verschiedenen Ausbaustufen zu Gruppieren. Also all jene Features die sofort im MVP-Kandidaten umgesetzt werden sollen, in einer ersten Gruppe zu sammeln, alle die in der nächsten Ausbaustufe umgesetzt werden sollen in eine separate Gruppe zu gruppieren und all jene Features die erst in einer späteren Ausbaustufe gemacht werden sollen weil sie eher noch Ideen sind in einer dritten Gruppe zu dokumentieren. So wird der benötigte Überblick für das Umsetzungsteam und die Stakeholder gewahrt. Erst dann kann im nächsten Schritt des Lean-Productmanagement-Zyklus die Umsetzung des MVP-Kandidaten angegangen werden.

Artefakte und Outcome aus diesem Schritt:

In diesem Schritt wurde der Problembereich verlassen und das Team hat sich dem Lösungsbereich zugewandt. Es wurde das Wertangebot aus dem vorherigen Schritt verwendet um Featureideen zu generieren, diese zu konkretisieren und in User-Stories und PBIs zu gießen. Die PBIs wurden in die Kategorien des Kano-Modells eingeteilt und mit allen notwendigen Informationen angereichert um diese dann einer sinnvollen Schätzung durch das Team zuführen zu können.

Durch geeignete Schätzmethoden wurde sowohl der Aufwand (Story-Points), als auch der erwartete Mehrwert (Value-Points) durch das Team geschätzt und somit eine Basis für die Return On Investment Betrachtung geschaffen. Durch all diese gesammelten Informationen konnte der Produktmanager gemeinsam mit dem Team das Feature-Set für den MVP-Kandidaten und für spätere weitere Ausbaustufen fixieren.

Artefakte:

Brainstorming Dokumentation (z.B. Mindmap) an Features im Problembereich
Product-Backlog-Items Kategorisiert in Kano-Modell-Kategorien
User-Stories, Akzeptanz-Kriterien, Value-Points, Story-Points, für PBIs
Mehrere Bereiche oder Gruppen und somit eine Priorisierung des Product-Backlogs.
Feature-Set für den MVP-Kandidaten in Form des Product-Backlogs