Warum das MVP zu groß wird

Stellen Sie sich folgendes vor: Sie entwickeln für Ihr Unternehmen ein neuartiges Produkt. Zur Unterstützung des Außendienstes planen Sie eine Smartphone-App mit Spracheingabe und geobasierten Funktionen, damit die Mitarbeiter weniger suchen müssen und mehr Zeit für die Kunden haben.

Sie haben einen Lean Canvas aufgesetzt und sogar Ihrem CEO ein Budget für die Produktentwicklung abgerungen. Ihr Team freut sich auf die neue Herausforderung und hat schon einen ersten Design Thinking Workshop geplant. Nach Diskussionen und Klärungen mit Stakeholdern haben Sie ein initiales Backlog erstellt und mit dem Team geschätzt. Sie planen, mit dem MVP-Ansatz (Minimum Viable Product) herauszufinden, ob Ihre Ideen am Markt funktionieren.

Jetzt stellen Sie jedoch fest, dass die Umsetzung der Features für das MVP so viel kosten würde, dass vom Budget kaum noch etwas übrigbleiben würde. Eigentlich wollten Sie doch mit dem MVP erstmal „die Finger ins Wasser halten“ und schauen, ob Ihre Kunden und Nutzer Ihre Vorstellungen bestätigen.

Ein zu großes MVP kann die Produktentwicklung gefährden

Wenn Sie einen großen Teil des Budgets bereits verplant haben, wie werden Sie dann auf Änderungswünsche der Nutzer reagieren? Haben Sie dafür noch genügend Budget – oder hat das MVP schon zu viel verbraucht?

Das Feedback aus dem MVP könnte Ihnen ja sogar nahelegen, einen ganz anderen Weg einzuschlagen. Beispielsweise könnten Sie durch das MVP herausfinden, dass die Spracherkennung in der Außendienst-App für Personen- und Straßennamen so gar nicht funktioniert. Als Folge stellen Sie vielleicht die App um auf die Anzeige und Auswahl über Kacheln. Oder Sie gestalten den Prozess neu, so dass Ihr Call Center den Außendienstmitarbeitern die jeweilige Adresse als Ziel elektronisch übermitteln kann. Derartige Erkenntnisse sind das eigentliche Ziel eines MVP.

Wie können Sie reaktionsfähig bleiben und verhindern, dass Ihr MVP das Budget ausschöpft?

Zu viele gute Ideen für das MVP

In den frühen Phasen der Produktentwicklung entstehen viele spannende Ideen und Vorschläge. Oft kann man hier schon erkennen, dass die Gesamtmenge zu groß wird, selbst wenn sich alle Stakeholder über die Notwendigkeit eines sehr eng gefassten MVPs einig sind.

Ihr wichtigstes Tool als Product Owner ist eine klare Priorisierung des Backlogs. Dabei müssen Sie auch häufig „Nein“ sagen, wenn ein Stakeholder eine aus seiner Sicht wichtige Anforderung durchsetzen will. Oft ist es jedoch schwierig, den Wert eines Features innerhalb eines umfangreichen Produktes in Euro zu bestimmen. Wenn Sie einen relativen Wert zuordnen, beispielsweise zwischen eins und zehn, dann können Sie mit den Stakeholdern zusammen die unterschiedlichen Sichtweisen zeitnah diskutieren. Dabei decken Sie frühzeitig Annahmen und Ziele auf, die Sie sonst häufig erst spät im Projekt kennenlernen.

Zur Einordnung hilft auch die Betrachtung mit dem Kano-Modell. Dies unterscheidet Features beispielsweise in die Kategorien Basismerkmale, Leistungsmerkmale und Begeisterungsmerkmale. Das Kano-Modell ist sehr wichtig zum Verständnis guter Produkte und wird Thema eines separaten Blog-Artikels werden.

Das Produkt „rund“ machen, schon beim MVP?

Aber auch der Product Owner kann – ohne es zu wollen – das MVP aufblähen. Häufig kann man beobachten, dass er Sorge hat, sich vor Kunden oder vor einer anderen Abteilung zu blamieren. Dementsprechend fügt er dem MVP Features hinzu, die man zum Ausprobieren der zentralen Produktidee nicht braucht. Hier hilft der Mut zur Lücke! Vor allem, weil Sie erst durch das Validieren Ihrer Annahmen für den eigentlichen Kern der Idee herausfinden können, was die Kunden wirklich brauchen. Alles andere sind Wetten, basierend auf Annahmen und daher mit hohem Risiko.

Die Konkurrenz schläft nicht

Eine andere mögliche Ursache für zu große MVPs ist häufig die Angst vor der Konkurrenz. Was ist, wenn ein Wettbewerber die rudimentär umgesetzte Idee klaut und eine viel bessere Version baut? Oder wenn er bereits ein ähnliches Produkt in Vorbereitung hat und man plötzlich mit diesem konkurriert? Auch hier ist der Vorteil der echten, durch Kunden und Anwender validierten Nützlichkeit des MVP um ein Vielfaches höher als die tatsächliche Gefahr durch die Konkurrenz. Denn auch die muss ja erstmal herausfinden, was wirklich funktioniert. In diesem Rennen gewinnt derjenige, der am schnellsten den wirklichen Kundenwunsch erreicht.

Fail fast – and fail cheap!

Der MVP-Ansatz hilft Ihnen, das höchste Risiko in der Produktentwicklung zu validieren: Ihre Annahmen! Gehen Sie immer davon aus, dass das Feedback zu wesentlichen Änderungen führen wird, und fokussieren Sie das MVP auf die wichtigsten, wertschöpfenden Features. Je früher Sie die Richtung korrigieren können, desto länger reicht Ihr Budget!

Falls Sie durch einen Prototyp oder Proof of Concept noch vor der Umsetzung des MVP experimentieren können, dann können Sie sogar noch früher die Richtung anpassen – und noch mehr sparen.

Sehr kostengünstig können Sie vor allem aus den Erfahrungen anderer Produkt Owner lernen. Eine Gelegenheit bietet sich bei dem Conciso-Meetup am 27.06.2019 zum Thema „Arbeiten mit MVPs“. Besuchen Sie uns, und bringen Sie Ihre Fragen mit!

Bilder von unsplash.com