Discovery & Research
Product Discovery: herausfinden, was sich zu bauen lohnt
Product Discovery ist die Arbeit, die vor dem Bauen passiert: herausfinden, welche Probleme Kundinnen und Kunden wirklich haben und welche Lösung sie nutzen würden. Sie ist das Gegenstück zur Delivery, in der das Team die Lösung zuverlässig entwickelt und ausliefert. Beides läuft in modernen Produktteams parallel. Der Grund ist einfach: Viele Ideen funktionieren in der Praxis nicht so, wie das Team es erwartet hat. Discovery sorgt dafür, dass ihr das früh und günstig herausfindet.
Worum es bei Discovery geht
Marty Cagan beschreibt Product Discovery als den Weg, vier Risiken anzugehen, bevor viel Entwicklungszeit fließt: Wird das Produkt gekauft oder genutzt (Wert)? Können Menschen es bedienen (Bedienbarkeit)? Kann das Team es mit vertretbarem Aufwand bauen (Machbarkeit)? Funktioniert es für das Unternehmen (Wirtschaftlichkeit)? Jede Discovery-Aktivität sollte mindestens eines dieser Risiken verringern. Wer das im Blick behält, verliert sich nicht in Recherche um ihrer selbst willen.
Problemraum und Lösungsraum
Ein hilfreiches Bild ist das Double Diamond des britischen Design Council. Es teilt die Arbeit in zwei Rauten: Zuerst wird der Problemraum geöffnet und wieder eingegrenzt (Entdecken, Definieren), danach der Lösungsraum (Entwickeln, Ausliefern). Der häufigste Fehler in Produktteams ist, die erste Raute zu überspringen und sofort über Lösungen zu sprechen. Dann wird zwar schnell gebaut, aber oft am eigentlichen Problem vorbei.
Die wichtigsten Methoden
Discovery ist kein starres Verfahren, sondern ein Werkzeugkasten. Diese Methoden decken die meisten Situationen ab:
| Methode | Prüft vor allem | Aufwand |
|---|---|---|
| Kundeninterviews | Problem und Kontext (Wert) | gering |
| Analyse von Nutzungsdaten | tatsächliches Verhalten | gering bis mittel |
| Klickbarer Prototyp | Bedienbarkeit und Wert | mittel |
| Technischer Spike | Machbarkeit | mittel |
| Fake-Door- oder A/B-Test | Nachfrage im echten Produkt | mittel |
| Design Sprint | eine große Frage in fünf Tagen | hoch, aber zeitlich begrenzt |
Für die Interviews gilt: Fragt nach vergangenem Verhalten, nicht nach Meinungen über die Zukunft. „Wann haben Sie das zuletzt gemacht, und wie lief das?“ liefert belastbarere Antworten als „Würden Sie diese Funktion nutzen?“. Das Denken in Jobs to be Done hilft, die Aufgabe hinter einem Wunsch zu verstehen. Clayton Christensen und Kollegen haben das 2016 in der Harvard Business Review ausführlich beschrieben.
Struktur mit dem Opportunity Solution Tree
Teresa Torres hat mit dem Opportunity Solution Tree ein einfaches Werkzeug geschaffen, das Discovery sichtbar macht. Ganz oben steht das angestrebte Ergebnis, etwa eine höhere Aktivierungsrate. Darunter sammelt das Team Chancen, also Kundenbedürfnisse, Probleme und Wünsche aus Interviews. Erst darunter folgen Lösungsideen und schließlich Experimente, die diese Ideen prüfen. Der Baum zwingt dazu, jede Idee auf ein Kundenproblem und ein Ziel zurückzuführen. Torres empfiehlt außerdem, Discovery kontinuierlich zu betreiben: Das Team spricht regelmäßig, idealerweise wöchentlich, mit Kunden, statt einmal im Jahr eine große Studie zu beauftragen.
Ein Ablauf für den Start
- Ziel klären: Welches Ergebnis soll sich verändern? Formuliert es als Outcome, nicht als Funktion.
- Annahmen sammeln: Was muss stimmen, damit eure Idee funktioniert? Sortiert die Annahmen nach Risiko und Wissensstand.
- Mit Kunden sprechen: Fünf bis acht Interviews zeigen oft schon wiederkehrende Muster. Haltet die Erkenntnisse kurz und für alle zugänglich fest.
- Riskanteste Annahme testen: Mit dem kleinsten Experiment, das eine Antwort liefert, zum Beispiel einem Papierprototyp oder einer Landingpage.
- Entscheiden: Weiterverfolgen, anpassen oder verwerfen. Auch ein verworfenes Konzept ist ein Ergebnis, weil es Entwicklungszeit spart.
Wer macht Discovery?
Discovery ist Teamarbeit. Cagan empfiehlt, dass Produktmanagement, Design und Entwicklung gemeinsam daran arbeiten, weil jede Disziplin andere Risiken am besten einschätzen kann. Entwickler erkennen technische Möglichkeiten, die andere übersehen, Designerinnen sehen Bedienprobleme früher. Der Produktmanager sorgt dafür, dass Ziel und Geschäftsmodell im Blick bleiben. Mehr zur Rolle steht im Ratgeber zu den Aufgaben eines Produktmanagers.
Wann ist genug Discovery?
Es gibt keinen festen Endpunkt. Eine gute Faustregel lautet: Ihr seid bereit für die Umsetzung, wenn die vier Risiken für die nächste Ausbaustufe ausreichend beantwortet sind und ihr wisst, woran ihr Erfolg messen werdet. Für kleine, leicht rückgängig zu machende Änderungen genügt wenig Discovery. Für große, teure oder schwer umkehrbare Entscheidungen lohnt sich mehr. Nach dem Start geht die Discovery weiter, denn echte Nutzungsdaten sind die beste Quelle für die nächsten Fragen. Wie ihr anschließend zwischen den gefundenen Chancen auswählt, zeigt der Ratgeber Priorisierungsmethoden.
Fazit
Product Discovery reduziert das Risiko, etwas zu bauen, das niemand braucht. Sie beginnt beim Problem, nutzt einfache Methoden wie Interviews und Prototypen und macht Annahmen überprüfbar. Teams, die Discovery regelmäßig betreiben, treffen bessere Entscheidungen und verschwenden weniger Zeit mit Funktionen, die später kaum jemand nutzt.
Quellen
- Marty Cagan: Product Discovery, Silicon Valley Product Group
- Marty Cagan: The Four Big Risks, Silicon Valley Product Group
- Design Council: The Double Diamond
- Teresa Torres: Opportunity Solution Trees, Product Talk
- Clayton M. Christensen u. a.: Know Your Customers’ “Jobs to Be Done”, Harvard Business Review (2016)
- GV: The Design Sprint