Product Discovery: Klären, was gebaut wird, bevor geliefert wird

Product Discovery ist die Arbeit vor der Entwicklung, die klärt, ob ein Vorhaben Kunden nützt und sich bedienen lässt. Außerdem prüft sie, ob es technisch gelingt und sich für das Unternehmen rechnet. Diese vier Risiken testet ein Team mit kleinen Experimenten, bevor es Wochen oder Monate in die Umsetzung investiert. Delivery stellt sicher, dass Dinge richtig gebaut werden, Discovery stellt sicher, dass die richtigen Dinge gebaut werden.

Viele Organisationen haben ihre Lieferfähigkeit in den vergangenen Jahren verbessert und stellen danach fest, dass pünktlich gelieferte Funktionen trotzdem nicht genutzt werden. Die Ursache liegt vor der Lieferung, in einer Anforderung, die nie geprüft wurde. Dieser Beitrag beschreibt, wie Discovery aufgebaut ist, welches Experiment zu welchem Risiko passt und woran die Geschäftsführung erkennt, dass ein Vorhaben bereit für die Umsetzung ist.

Was ist Product Discovery und wie unterscheidet sie sich von Delivery?

Product Discovery ist der Teil der Produktarbeit, in dem ein Team herausfindet, welche Lösung für welches Problem es lohnt zu bauen, während Delivery diese Lösung zuverlässig in den Betrieb bringt. Der Produktmanager Marty Cagan hat die Unterscheidung in seinem Buch „Inspired“ von 2017 popularisiert. Er beschreibt, dass die meisten Ideen nicht so funktionieren wie erhofft und dass ein Team deshalb Evidenz sammeln muss, bevor es Entwicklungskapazität bindet.

Der Unterschied zeigt sich im Ergebnis. Delivery liefert Software, Prozesse oder Services, die der Planung entsprechen. Discovery liefert eine begründete Entscheidung: bauen, ändern oder verwerfen. Beide Arbeitsweisen laufen parallel, was in der Fachwelt als Dual-Track-Vorgehen bezeichnet wird. Ein Team entwickelt, was bereits geprüft ist, und prüft zugleich, was als Nächstes kommt. Wie eine fertige Arbeit definiert wird, ist Thema des Beitrags zur Definition of Done. Discovery ergänzt sie um die Frage, ob das Fertige überhaupt gebraucht wird.

Die vier Risiken, die Discovery prüft

Discovery prüft vier Risiken: den Wert für Kunden, die Bedienbarkeit, die technische Machbarkeit und den Geschäftsnutzen. Cagan führt diese vier Risiken als Raster für jede Produktidee ein. Das Raster hat den Vorteil, dass es Diskussionen von der Meinung zur Evidenz lenkt, weil jedes Risiko ein eigenes Experiment verlangt.

Wer nur den Wert prüft, übersieht den häufigsten Grund für späte Überraschungen. Eine Lösung, die Kunden wollen, kann an einer Schnittstelle scheitern, die niemand untersucht hat, oder am Vertrieb, der sie nicht verkaufen will. Deshalb gehören Entwickler und Fachbereiche von Beginn an in die Discovery, lange vor der Übergabe.

Welche Methoden gibt es, und wie wählt man sie aus?

Die Methode richtet sich nach dem Risiko, das am größten ist, und nach der Zeit, die die Entscheidung wert ist. Drei Ansätze haben sich durchgesetzt. Der Design Sprint von Jake Knapp, 2016 in dem Buch „Sprint“ beschrieben, führt ein Team in fünf Tagen von einem Problem zu einem getesteten Prototyp. Er eignet sich, wenn ein neues Angebot geklärt werden muss und die wichtigen Entscheider eine Woche lang verfügbar sind. Die Continuous Discovery von Teresa Torres, dargestellt in „Continuous Discovery Habits“ von 2021, setzt auf wöchentliche Kundengespräche und einen Chancenbaum, der Ergebnis und Chancen mit Lösungen und Experimenten verbindet. Sie passt zu Teams, die ein bestehendes Produkt laufend weiterentwickeln. Der Lean-Startup-Ansatz von Eric Ries aus 2011 verlangt ein kleinstes Produkt, das eine Annahme prüft, und eignet sich für Vorhaben mit hoher Unsicherheit über die Nachfrage.

In Unternehmen jenseits der Softwarebranche lässt sich das Prinzip übertragen. Eine neue Dienstleistung wird zuerst an zwei Pilotkunden von Hand erbracht, ein neuer interner Prozess auf einem einzigen Standort erprobt. Der Maßstab bleibt gleich: Je teurer die Umsetzung, desto mehr Belege verlangt die Entscheidung. Wie früh Rückmeldungen von Kunden eingebaut werden, hängt mit der Verkürzung der Lieferzeit zusammen, die der Beitrag zur Time-to-Market beschreibt.

Wer verantwortet Discovery im Unternehmen?

Discovery verantwortet ein kleines, dauerhaftes Team aus Product Owner, einer Fachperson für Gestaltung oder Prozesse und einem Entwickler. Der Product Owner verantwortet die Entscheidung, was gebaut wird, und bündelt die Belege. Die Rolle ist im Mittelstand oft überladen, weil sie Anforderungen sammelt und zugleich die Entwicklung koordiniert, während sie Prioritäten verteidigt. Der Beitrag zum Product Owner im Mittelstand zeigt, welche Entscheidungsrechte die Rolle braucht, damit sie diese Aufgabe erfüllen kann.

Die Geschäftsführung beeinflusst die Qualität der Discovery stärker als jedes Team. Sie entscheidet, ob ein Team Ideen verwerfen darf, ohne dass dies als Misserfolg gilt, und ob Budget an Evidenz oder an die Rangfolge der Fürsprecher geknüpft wird. Wo Budgets für das ganze Jahr vorab auf Funktionen festgelegt werden, bleibt für Discovery kein Spielraum. Der Beitrag zu agilen Festpreisprojekten beschreibt einen Weg, Umfang von Budget zu trennen.

Prüfliste: Ist das Vorhaben bereit für die Umsetzung?

Ein Vorhaben ist bereit für die Umsetzung, wenn die folgenden sechs Aussagen mit Ja beantwortet werden können.

• Das Problem ist mit mindestens fünf Kunden oder Nutzern besprochen, und die Aussagen liegen schriftlich vor.
• Mindestens ein Experiment hat gezeigt, dass Kunden handeln, etwa bestellen, buchen oder Daten bereitstellen.
• Ein Prototyp wurde von Nutzern ohne Anleitung bedient.
• Die Entwickler haben Umfang und Schnittstellen geprüft und schätzen das größte technische Risiko als beherrschbar ein.
• Die Wirtschaftlichkeitsrechnung beruht auf Annahmen, die der Fachbereich bestätigt hat.
• Es gibt eine Kennzahl mit Ausgangswert sowie die Schwelle, unter der das Vorhaben beendet wird.

Fehlen zwei oder mehr Antworten, bleibt das Vorhaben in der Discovery. Das kostet wenige Wochen und verhindert, dass ein Team Monate an einer Funktion arbeitet, die später niemand nutzt. Wie aus einer freigegebenen Lösung ein verlässlicher Termin wird, beschreibt der Beitrag zur Release-Planung.

Discovery mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management arbeitet er als Delivery Manager, Projektmanager und Product Owner und führt die Phase vor der Umsetzung so, dass Entscheidungen auf Belegen beruhen.

Das Vorgehen folgt dem Niehues Delivery Model. Für Discovery zählen drei Prüffragen besonders: Welches Geschäftsergebnis soll sich messbar verändern? Was ist der Ausgangswert, und woran messen wir den Erfolg? Beweist der Prototyp den Nutzen im echten Ablauf mit echten Daten? Den Einstieg bildet eine kostenfreie Erstberatung von 30 Minuten, die Sie über den Kontakt vereinbaren. Umfang und Konditionen eines Vorhabens werden dort besprochen.