So definieren Sie einen MVP-Umfang in 3 Stunden

Als ich als Produktmanager von einem jungen Zahlungsabwicklungsunternehmen eingestellt wurde, hatte das Unternehmen Schwierigkeiten, ein Bestandsverwaltungssystem zeitnah zu erstellen und bereitzustellen. Die vorhandene Lösung war eine einfache Tastatur-App, die nicht benutzerfreundlich war und infolgedessen zu einer erheblichen Kundenabwanderung führte. Meine Aufgabe bestand darin, ein Team zu leiten, das mit dem Aufbau des Inventarsystems beauftragt war, das die Möglichkeiten der App über die Tastaturfunktionalität hinaus erweitern sollte.

Da wir auf einer verkürzten Zeitachse arbeiten mussten, habe ich einen einfachen, aber radikal effizienten Ansatz entwickelt, um ein Minimum Viable Product (MVP) mit Kernfunktionen zu konzipieren, zu entwerfen und zu bauen, das den Wünschen unserer Benutzer entspricht. Der Prozess verdichtete das Scoping eines MVP zu einer intensiven dreistündigen Sitzung – statt Tagen oder Wochen – und sparte unserem Team Monate an Entwicklungszeit.

Dieser beschleunigte MVP-Scoping-Prozess kann verwendet werden, um jedes Produktteam zu leiten, und kann auf die Erstellung jedes Zero-to-One-Produkts angewendet werden.

Überblick über den Anwendungsfall

Problem: Die einfache Tastaturfunktion der App bot Benutzern, die Verkäufer waren, nicht die Möglichkeit, Inventar zu verwalten oder Artikel auszuwählen, um sie einer Kundenbestellung hinzuzufügen.

Einschränkungen: Die Unternehmensleitung wollte eine Lösung, die innerhalb von acht Wochen geliefert wurde; eine potenzielle Spendenrunde hing zum Teil vom Erfolg einer verbesserten Version des Produkts ab.

Kontext: Aufgrund einer Marktanalyse und nachdem ich einige Zeit mit vielen unserer Benutzer verbracht hatte, stellte ich fest, dass diese Anbieter ein Bestandsverwaltungssystem benötigten, um ihren Verkaufsfluss zu optimieren. Ich habe zugesehen, wie sie die Bestellungen der Kunden bearbeitet haben: Zuerst haben sie die gewünschten Artikel auf Zettel geschrieben, die Artikel mit Taschenrechnern gezählt und dann die Bestellungen in die App eingegeben. Sie benutzten drei Werkzeuge, obwohl sie nur eines hätten brauchen sollen.

Lösung: Wir mussten eine Lösung entwickeln, mit der Benutzer ihre Bestände in einen digitalen Katalog laden, diese Bestände verwalten und ausgewählte Artikel antippen können, um sie dem Einkaufswagen eines Kunden hinzuzufügen – alles innerhalb der App.

Die Design-Sprint-Entscheidung

Da wir bereits wussten, welches Produkt wir entwickeln mussten, verzichtete ich auf einen typischen Design-Sprint – einen vier- bis fünftägigen Workshop, in dem Teams zusammenarbeiten, um eine große geschäftliche Herausforderung zu identifizieren, Ideen von Kunden zur Lösung des Problems zu sammeln, ein Konzept für ein Produkt entwickeln, einen Prototyp entwerfen und mit dem Testen beginnen.

Design-Sprints sind eine effektive Methode zum Erstellen von MVPs – für diejenigen, die Kernprobleme identifizieren müssen und die ausreichend Zeit haben, um Lösungen zu entwickeln. In jungen Unternehmen oder neuen Geschäftseinheiten in bestehenden Organisationen sind jedoch typischerweise Kernprobleme offensichtlich: Konzepte wurden entwickelt, und der Produkt-/Marktfit wurde normalerweise bestimmt, bevor Produktmanager, Ingenieure und Designer hinzugezogen wurden.

Das folgende Flussdiagramm zeigt die Schritte auf, die ich unternommen habe, als ich entschieden habe, dass der beste Weg, mit diesem Projekt fortzufahren, darin besteht, den Design-Sprint zu überspringen und mit der dreistündigen Sitzung zu beginnen, die auch als Team-Kickoff bezeichnet wird. Bei diesem Meeting führten die Teilnehmer ein Brainstorming durch, generierten Dutzende von Ideen für Funktionen und reduzierten die Liste dann auf das, was für das MVP erforderlich war.

Der MVP-Entwicklungsprozess

Vorbereitung

Vor der dreistündigen Sitzung sollten Sie Informationen über Ihre Benutzerpersönlichkeiten sammeln, indem Sie mit aktuellen oder potenziellen Kunden sprechen und diese beobachten und Marktforschung betreiben.

Erstellen Sie dann eine Präsentation für die Designer und Ingenieure. Es sollte erklären:

• Das Problem, das Sie zu lösen versuchen.
• Das Produkt, das Sie bauen.
• Wie das Produkt dieses Problem in Bezug auf Metriken und UX löst.
• Die prognostizierte Auswirkung des Produkts auf Ihr Geschäft und das Ihrer Kunden.
• Die Missionen und Ziele und Schlüsselergebnisse (OKRs) auf Unternehmens- und Teamebene sowie wie das Produkt hilft, diese Missionen zu erfüllen und diese OKRs zu erreichen.

Die Präsentation sollte den Designern und Ingenieuren ein solides Verständnis des Produkts vermitteln, um mit der Festlegung des MVP-Bereichs fortzufahren.

Das dreistündige Kickoff-Meeting

Der Kickoff sollte das gesamte Entwicklungsteam einbeziehen und es ihm ermöglichen, an jeder Phase des Prozesses teilzunehmen, von der Ideenfindung und Story-Erstellung bis hin zur Entwicklung des MVP-Konzepts. Dazu gehören Senior-, Junior- und assoziierte Produktmanager; Produkteigentümer; Produkt-Leads (falls zutreffend); UX-Designer; Software-Ingenieure; und QA-Ingenieure.

Kurzer Tipp: Obwohl es unorthodox ist, empfehle ich, Ingenieure vor der Bauphase einzubeziehen. Sie liefern normalerweise großartige Ideen und haben eine Leidenschaft für das Produkt, das sie zu verbessern versuchen. Die meisten von ihnen genießen es, an der Gestaltung des MVP beteiligt zu sein; Es hilft ihnen, sich stärker in das Projekt zu investieren und von den anderen Teams geschätzt zu werden.

Versammeln Sie alle in einem Konferenzraum oder virtuellen Arbeitsbereich. In unserem Fall hatten wir 10 Personen. Blockieren Sie drei Stunden.

Das Produkt und die User Journeys (60 Minuten)

1. Liefern Sie die Präsentation. (15 Minuten)

2. Beginnen Sie damit, alle Benutzerpersönlichkeiten für Ihr Produkt zu identifizieren. Auch wenn Sie noch keine Flows oder Funktionsarbeiten identifiziert haben, können Sie die Anzahl der Flows definieren, die erstellt werden müssen. (10 Minuten)

   Kurzer Tipp: Übertreiben Sie es nicht, indem Sie mehr Personas als nötig hinzufügen. Nach der MVP-Veröffentlichung wird das Kundenfeedback zeigen, ob Sie zusätzliche Rollen benötigen.

   Anwendungsbeispiel: Wir hatten drei Personas: den Filialleiter (oder Administrator), den Kassierer und den Endkunden. Es gab andere potenzielle hochrangige Personen, wie z. B. Ladenbesitzer, aber für die Zwecke eines MVP konnten diese vom Administrator abgedeckt werden.

3. Bilden Sie die Benutzerreise von Anfang bis Ende ab. Weisen Sie jeder Persona eine Farbe zu, um jeden Schritt des Ablaufs zu identifizieren, auf den ein Benutzer trifft. Kleben Sie für persönliche Besprechungen Haftnotizen an die Wand oder verwenden Sie ein Whiteboard. Verwenden Sie für virtuelle Meetings ein FigJam-Board oder ähnliches. (35 Minuten)

   Kurzer Tipp: Lassen Sie das Team alle seine Ideen teilen – und gehen Sie ins Detail. Jeder Schritt des Ablaufs wird zu einem zu erstellenden Feature – und jeder Benutzer erhält einen separaten Ablauf –, aber der Prozess zum Skizzieren der Schritte ist derselbe.

   Anwendungsbeispiel: Hier ist die Funktionsliste für unsere Kassierer-Persona:

   • Öffnen Sie die Point-of-Sale-App.
   • Melden Sie sich mit einer PIN an.
   • Identifizieren Sie den ersten Artikel für den Kundenkauf.
   • Identifizieren Sie die Menge für den Artikel.
   • Identifizieren Sie alle zusätzlichen Artikel für den Kundenkauf.
   • Fügen Sie einen Rabatt auf einen Artikel hinzu (falls zutreffend).
   • Summieren Sie die Kosten aller Artikel im Warenkorb (an dieser Stelle wird der volle Kaufpreis inklusive Mehrwertsteuer angezeigt).
   • Schließen Sie den Checkout und die Zahlungsabwicklung ab.
   • Bestätigen Sie den Kauf.
   • Erlauben Sie dem Kunden, ein Trinkgeld hinzuzufügen.
   • Schließen Sie den Verkauf ab.
   • Zeigt die Summe aller Tagesverkäufe an.
   • Erhalten Sie nach einer vorbestimmten Inaktivitätsdauer (z. B. fünf Minuten) eine Zeitüberschreitung.

   Hinweis: Diese Liste enthält die meisten Funktionen, an die wir für diese Persona gedacht haben. Wir haben insgesamt etwa 60 Funktionen für alle Personas entwickelt, mit minimaler Überschneidung, da Kassierer, Filialleiter und Endkunde alle auf unterschiedliche Weise mit der Anwendung interagieren. Abhängig von der Art des Produkts, das Sie entwickeln, kann es bei den Benutzertypen zu deutlich mehr Funktionsüberschneidungen kommen.

   

Wesentliche Merkmale der User Journeys (45 Minuten)

1. Gruppieren Sie Funktionen für jeden Benutzertyp in den diskreten Teilen jeder Benutzerreise auf einem realen oder virtuellen Whiteboard. Zeichnen Sie dann eine horizontale Linie auf die Tafel. Identifizieren Sie über der Linie die Sätze, die für das Funktionieren des Produkts erforderlich sind. Platzieren Sie unter dem Strich Funktionen, die nett zu haben sind, aber bis zu späteren Versionen warten können. (30 Minuten)

   Kurzer Tipp: Teilen Sie die Designer und Ingenieure in Gruppen auf, um diesen Schritt abzuschließen, und kommen Sie dann wieder zusammen, um Notizen auszutauschen. Dies ist besonders hilfreich bei Besprechungen mit 10 oder mehr Personen.

   Anwendungsbeispiel: Für unsere App hatten wir zu diesem Zeitpunkt 12 Funktionssätze, die das Laden von Artikeln in den Bestandskatalog, die Preisgestaltung, die Auswahl von Artikeln zum Hinzufügen zum Warenkorb eines Kunden, das Auschecken und Abschließen des Verkaufs, das Nachbestellen von niedrigem Bestand, und mehr. Wir haben die Anzahl der Feature-Sets schließlich auf vier reduziert.

   Dieser Eliminierungsprozess half uns festzustellen, dass die Sicherheitsanmeldung eines Benutzers in der ersten Iteration der App nicht erforderlich war. Keiner fügte einen Rabatt oder ein Trinkgeld hinzu. Wir haben auch entschieden, dass der Kassierer nicht in der Lage sein muss, die Summe aller täglichen Verkäufe als Teil eines MVP anzuzeigen, der Filialleiter oder -besitzer jedoch möglicherweise.

2. Verfeinern Sie die Liste der Funktionen. Fragen Sie: „Wenn dies weggelassen würde, würde das Produkt dann noch funktionieren?“ Wenn die Antwort ja lautet, lassen Sie diese Funktion aus dem MVP weg – bewahren Sie sie für eine spätere Iteration des Produkts auf. Wenn die Antwort nein ist, müssen Sie diese Funktion in das MVP aufnehmen. Am Ende dieses Prozesses wissen Sie, was wirklich erforderlich ist, um Ihr Produkt funktionsfähig zu machen. Oft besteht dies nur aus drei oder vier Merkmalen für jeden Satz. (15 Minuten)

   Hinweis: Vermeiden Sie es, zu viele Feature-Sets in das MVP zu integrieren. Während Sie mit abweichenden Meinungen darüber rechnen sollten, was am wichtigsten ist, ist es Ihre Aufgabe als Produktmanager, die Entscheidung zu treffen. Sie haben Ihre Recherchen durchgeführt und verfügen über Daten, die Ihre Entscheidungen stützen. Meiner Erfahrung nach sind viele Produkte zunächst robuster aufgebaut, als sie sein müssten, und die meisten Unternehmen würden es vorziehen, den Benutzern so schnell wie möglich etwas zum Testen und Feedback in die Hand zu geben.

Produktdesign, Tests und Engineering (75 Minuten)

1. Lassen Sie die Designer die Kernfunktionen in ein Drahtgitterdesign des MVP integrieren, das die Ingenieure verwenden, um die Architektur des Produkts zu erstellen. (45 Minuten)

2. Lassen Sie die Produktspezialisten und Designer an einigen leichten UX-Tests des Wireframe-Designs zusammenarbeiten. (15 Minuten)

   Hinweis: Es gibt nur sehr wenige Produktmanagement-Szenarien, in denen Sie ohne Einbeziehung des Endkunden entwickeln sollten, aber im Fall von Rapid Testing und Entwicklung können Sie einen Designprototyp intern oder mit Freunden und Familie testen, die Ihr Produkt nicht kennen. Wenn sie verwirrt sind, werden einige Ihrer Benutzer es auch sein.

3. Geben Sie die entworfenen Wireframes an die Ingenieure, damit sie mit dem Aufbau der Architektur des MVP beginnen können. Sie haben nicht alles, was sie brauchen – oder die Zeit –, um eine vollständige Lösung zu erstellen, aber sie können loslegen, und die von ihnen erstellte Architektur wird beim Abschluss des MVP verwendet. In der Zwischenzeit können die Produkt- und Designteams ihre Wireframes weiter testen, wobei interne Teammitglieder oder Freunde und Familie als Benutzer fungieren. Wenn Teams gleichzeitig an diesem Schritt arbeiten, spart das Zeit. (15 Minuten)

Je geschickter Sie diesen Prozess anwenden, desto einfacher wird es, zu erkennen, welche Funktionen Kernkomponenten eines MVP sind und welche später erstellt werden können. Die Praxis wird Sie auch davor bewahren, die falschen Dinge zu bauen: Sie haben vielleicht etwas für die „spätere“ Liste im Kopf, nur um später zu erfahren, dass kein Kunde es will.

Ergebnisse und Key Takeaways

Vor unseren Bemühungen war unsere App eine Tastatur mit den Zahlen 0 bis 9, einem Dezimalpunkt und einer Ladetaste. Aufgrund dieser Einschränkung und des dadurch verursachten ineffizienten Arbeitsablaufs war unsere Kundenbindung im Laufe eines Jahres gering – etwa 20 %. Obwohl wir schneller als unsere Konkurrenz neue Benutzer gewonnen hatten, verloren wir sie fast genauso schnell.

Während des gesamten Erstellungsprozesses des MVP haben wir vier Schlüsselfunktionssets erstellt, die alle einen minimalen Umfang, aber eine hohe Qualität aufweisen. Ein Benutzer könnte jetzt:

1. Laden Sie Artikel direkt von einem Mobilgerät ins Inventar, indem Sie einfach eine Kamera verwenden, einen Namen eingeben und einen Preis eingeben.
2. Wählen Sie diese Artikel aus und fügen Sie sie dem Einkaufswagen eines Kunden hinzu.
3. Schließe den Verkauf ab, während du dir die verkauften Artikel ansiehst.
4. Sehen Sie sich die Anzahl der verkauften Artikel in einem bestimmten Zeitraum an.

Die Kunden waren von dem verbesserten Produkt begeistert. Die Retentionsrate lag bei 45 % bei neuen Benutzern, die innerhalb der ersten Woche nach dem Laden von Artikeln mindestens fünf Mal die Katalogfunktionalität zum Auschecken nutzten.

Dank der Effizienz unseres MVP-Scoping-Prozesses haben wir unsere vollständig fertige App in etwa zwei Monaten erstellt und ausgeliefert. Dieser Prozess hätte mit einem traditionellen Entwicklungsansatz wahrscheinlich vier Monate oder länger gedauert – wenn das Produkt überhaupt jemals gebaut worden wäre.

Dieser beschleunigte Prozess spart Zeit und Geld. Ein vollständiger Design-Sprint kann teuer werden. Mit dem Kickoff-Meeting zu beginnen, macht meinen Prozess von Anfang an wirtschaftlicher, und diese Einsparungen werden durch die viel kürzere Gesamtentwicklungszeit verstärkt.

Die beiden Prozesse können jedoch auch zusammenarbeiten: Wenn Ihr Team einen Design-Sprint abgeschlossen hat, um ein zentrales Geschäftsproblem und die Lösung, die Sie erstellen müssen, zu definieren, können Sie meinen Prozess verwenden, um Ihren MVP-Umfang effizienter zu definieren.

Denken Sie daran, dass dieser Prozess erst der Anfang ist: Ein MVP ist eine laufende Arbeit, die in späteren Versionen weiter verfeinert wird. Sobald es vollständig erstellt und zur Auslieferung bereit ist, empfehle ich, einen Beta-Schalter hinzuzufügen, den Benutzer deaktivieren können, um zur alten App-Erfahrung zurückzukehren. Wenn Sie Verhaltenssoftware wie Heap nutzen, um zu verfolgen, wie viele Benutzer diese Option nutzen, erhalten Sie eine gute Vorstellung davon, was hinzugefügt oder geändert werden muss, um Ihr Produkt in der nächsten Iteration zu verbessern.