Viable, testable, unsable & loveable Products

Bild: Wikimedia Commons/Visitor7 - CC BY-SA 2.0

Zu den interessanteren Beiträgen der letzten Tage gehörte für mich ein Bericht über den Auftritt von Henrik Kniberg, über den ich ja schonmal geschrieben hatte, auf der Agile Tour Bangkok. Im Wesentlichen ging es dabei um skaliertes Agile, und er scheint da viele richtige und wichtige Sachen gesagt zu haben. Was mir aber besonders aufgefallen ist, ist ein Seitenaspekt den ich ähnlich sehe: die Kritik am Konzept des Mimimum viable Product (MVP, kleinstes lebensfähiges Produkt).

Die Grundidee des MVP ist zunächst einmal völlig richtig: statt alles auf einmal zu wollen und daran zu scheitern oder statt das Produkt "schichtweise" aufzubauen (DB → Backend → Frontend), wodurch es erst ganz zum Schluss benutzbar wird, geht man einen anderen Weg - man erstellt eine kleine, aber nutzbare Komponente (z.B. eine Webseite mit einer Service-Telefonnummer), dann eine zweite (z.B. ein Kontaktformular), dann eine dritte, eine vierte, etc. Jede Erweiterung ist idealerweise die kleinstmögliche durch die eine neue Funktion entsteht. Die Folge sind kleinere Merges, kleinere Test Runs, kleinere Seiteneffekte, weniger Bugs und größere Stabilität. Das Problem daran: dem Kunden/Auftraggeber sind die vielen kleinen Schritte nicht immer einfach zu verkaufen, und oft muss man sich in Reviews anhören, dass es kaum, gar nicht oder nur schleichend vorangehen würde, im schlimmsten Fall, dass man unfertige oder unbrauchbare Produkte präsentieren würde.

Kniberg versucht dem zu begegnen indem er das Minimum viable Produkt differenziert betrachtet und in verschiedene Untertypen aufteilt:

• Der erste Typ ist das Earliest testable Product
  Beispielsweise könnte das die allererste Form eines CMS sein, die zunächst nur mit unformatiertem Text befüllbare Seiten anlegt. Testbar, aber noch weit davon entfernt den Ansprüchen der Benutzer gerecht zu werden.
• Der zweite Typ ist das Earliest usable Product
  Um beim Beispiel zu bleiben: Der Text der erstellten Seiten ist formatierbar, es lassen sich Bilder und Videos einbetten, die Redakteure können damit bereits arbeiten, selbst wenn noch einiges fehlt.
• Typ drei ist das Earliest loveable Product
  Freigabe-Workflows, Verschlagwortung, Social Media-Einbindung und Autorenprofile - jetzt ist eigentlich alles da um an den Markt zu gehen. Es geht zwar noch mehr, aber vermarkten lässt sich das Ganze bereits.

Der Vorteil an diesem Vorgehen: man kann mit den verschiedenen Untertypen die verschiedenen Teil-Zielgruppen da abholen wo es Sinn macht - etwa die IT-Abteilung des Kunden mit dem Earliest testable Product, die Redakteure mit dem Earliest usable Product und das Marketing mit dem Earliest loveable Product. Jeder bekommt in etwa das was er will, keiner bekommt etwas vorgesetzt was ihn völlig über- oder unterfordert, Konfliktpotential entsteht gar nicht erst. Und in der Praxis ist so etwas bereits jetzt in gewisser Weise üblich, was sich zum Beispiel darin ausdrückt, dass die Geschäftsführung nur zu den Reviews im Vorfeld größerer Releases kommt. Während sich das aber eher selbst reguliert bieten Knibergs Untertypen die Gelegenheit Erwartungsmanagement zu betreiben und die verschiedenen Stakeholder dorthin zu bekommen wo es Sinn macht und wo sie auch selber sein möchten.

 

Nachtrag 26.01.2016:

Kniberg hat seine Gedanken nochmal ausführlich selbst aufgeschrieben.