Zurück
Joshua Schär
6. December 2021

Mit Continuous Discovery zu besseren Entscheidungen in der Produktentwicklung

Am diesjährigen UX Fest hat Teresa Torres über Continuous Discovery gesprochen: ein Ansatz der viele Herausforderungen und Probleme löst, denen ich in Produkt-Teams regelmässig begegne.

Was ist Continuous Discovery?

Continuous Discovery beschreibt eine relativ neue Denkweise, wie Produkte entwickelt werden. Bis anhin ist die Praxis weit verbreitet, dass man zuerst entscheidet, was gebaut werden soll (Product Discovery) und dies anschliessend entwickelt und veröffentlicht (Product Delivery).

Nun, ähnlich wie das Ausliefern von Software mittlerweile kontinuierlich geschieht (Continuous Delivery), verwandelt sich auch die Discovery-Phase in eine kontinuierliche, ständige Recherche und Entdeckung, eben die Continuous Discovery.

Es geht nicht mehr nur um die Bereitstellung neuer Funktionen, sondern um das Schaffen von effektivem Mehrwert für die Kundinnen und Kunden und das Unternehmen.

Kundenbedürfnisse verändern sich mit der Zeit

Digitale Produkte sind nie fertig, sondern werden laufend angepasst. Nach jedem Release ändern sich aber auch die Bedürfnisse, Probleme und Wünsche der Kundinnen und Kunden. Wenn wir diese nicht kennen verpassen wir den Anschluss und entwickeln Features, die niemand benötigt. Aus diesem Grund muss auch die Entdeckungsphase kontinuierlich und fortlaufend geschehen.

In Produkt-Teams schlägt zudem oft der Curse of Knowledge Bias zu: wir treffen Entscheidungen aus einem Standpunkt heraus, den die Kundinnen und Kunden nicht haben. Continuous Discovery kann dem entgegenzuwirken.

Zu guter Letzt hilft Continuous Discovery dabei, Entscheidungen zu treffen, von denen nicht nur die Kundinnen und Kunden, sondern auch das Unternehmen selbst profitieren.

Was heisst das nun konkret?

Die folgende Definition von Continuous Discovery hilft, den Ansatz klarer vom projektbasierten Ansatz zu unterscheiden.

Wöchentliche Interaktionen mit Kundinnen und Kunden

In Produkt-Teams werden täglich zahlreiche Entscheidungen getroffen. Von kleinen Entscheidungen, wie dem Text auf einem Button (obwohl dies nicht immer ganz unwichtig ist, wie die berühmte Geschichte vom $300 Million Button zeigt), bis hin zu grossen Entscheidungen wie z.B. welche Features auf die Roadmap kommen oder welche Zielgruppen bedient werden.

Wenn man jede Woche mit Kundinnen und Kunden spricht, bekommt man viel früher Feedback und kann bessere Entscheidungen treffen. Das ist etwas anderes, als Ideen und Features zu validieren, denn diese Validierung geschieht oft erst relativ spät. Es bleibt dann zu wenig Zeit für effektive Änderungen und oftmals werden nur noch kosmetische Anpassungen vorgenommen.

Menschen, die unsere Produkte verwenden, sollten deshalb regelmässig und fortlaufend eine Rolle spielen. Und je mehr Interaktion wir mit ihnen haben, desto besser wird die Grundlage für unsere täglichen Entscheidungen.

Lass sie mitgestalten!

Wie oben beschrieben, ist der Zeitpunkt sowie die Art des Feedbacks wesentlich. Entwicklerinnen und Entwickler wollen entwickeln und releasen. Da bleibt keine Zeit mehr um Feedback einzuholen und es bleibt bei kosmetischen Änderungen.

Deshalb müssen wir bereits die ersten Skizzen und Zeichnungen unserer Ideen mit den Kundinnen und Kunden validieren. So können wir unser Wissen darüber, was mit Technologie möglich ist mit den Bedürfnissen und Problemen der Kundinnen und Kunden kombinieren und Produkte entwickeln, die über lange Zeit hinweg funktionieren und nützlich sind.

Entscheidungen in kleinen, gemischten Teams fällen

Die zweite Zeile der Definition von Continuous Discovery geht darauf ein, wer genau diese Entscheidungen trifft. Grundsätzlich gilt: je mehr Leute involviert werden, desto länger dauert der Prozess.

Traditionellerweise funktioniert es oft so, dass Produkt-Manager / Product Owner die Anforderungen definieren und diese dem Design Lead weitergeben. Die Designer erledigen dann ihre Arbeit und übergeben diese den Entwicklerinnen.

Dieses Vorgehen bringt eine Menge Nacharbeit mit sich: Stossen Designer auf gewisse Probleme, müssen die Anforderungen neu diskutiert und angepasst werden. Anschliessend geschieht das gleiche nochmals, wenn die Ergebnisse den Entwicklerinnen übergeben werden, so dass sowohl die Anforderungen als auch das Design nochmals überarbeitet werden müssen.

Teresa schlägt deshalb vor, dass die Entscheidungen von einem Trio – bestehend aus Product Owner, Design Lead und Tech Lead – gefällt werden.

sdfsdf

In der Realität gibt es selbstverständlich noch viele weitere Rollen. Hier gilt es, dieses Team strategisch den Bedürfnissen und Themen anzupassen. Die Idee des Trios ist, die richtigen Leute für die richtige Entscheidung zusammenzubringen, indem rollenübergreifend (cross-functional) zusammengearbeitet wird.

Das bedeutet nicht, dass die Produkt-Managerin entscheidet, der Designer entwirft und die Entwicklerin programmiert. Es bedeutet, dass diese drei Rollen zusammenkommen, um zu entscheiden, was der beste Weg zum gewünschten Ergebnis ist. Indem im Trio alle denselben Wissensstand über Research, Anforderungen und Machbarkeit haben, können schneller gute Entscheidungen getroffen werden.

Research Experimente in Häppchen

Es ist unrealistisch, jede Woche einstündige Interviews mit 10 Personen durchzuführen. Wir sollten nicht Forschung um der Forschung willen betreiben, sondern solche die uns hilft das gewünschtes Ergebnis zu erreichen. Deshalb muss Research in kleine Häppchen heruntergebrochen werden.

Für diesen Zweck hat Teresa Torres den sogenannten Opportunity Solution Tree entwickelt. Dadurch werden die erwünschten Ergebnisse klar definiert. Dies unterscheidet sich von dem, was viele Produkt-Teams nach wie vor tun: Sie leben immer noch in einer Welt auf der bestimmte Features auf einer Roadmap aufgelistet werden. Diese Liste wird oft direkt vom Management beeinflusst, welches nicht selten kein wirkliches Verständnis für das Produkt und kaum Kenntnisse über die Anwenderinnen und Anwender hat.

Dadurch verändert sich das Mindset: von der Frage, welche Dinge wir bauen sollen (Output) hin zur Frage, welches Ergebnis wir erreichen wollen (Outcome). Ein Outcome repräsentiert immer ein bestimmtes Geschäftsergebnis und wird anhand eines bestimmten Verhaltens gemessen. So wird sichergestellt, dass man einen Kundennutzen schafft, der auch den Geschäftswert steigert. Bei OKR entspricht das Outcome einem Key Result.

Die Spannung zwischen Kundenbedürfnissen und Business Needs auflösen

Nachdem also das Outcome (Ergebnis) definiert ist, müssen Opportunities (Möglichkeiten) eruiert werden, um dieses Ergebnis zu erreichen. Die Opportunities basieren den Bedürfnissen, Problemen oder Wünschen unserer Kundinnen und Kunden.

Nun gibt es sehr viele solcher Möglichkeiten, aber nicht alle unterstützen bzw. steigern den Wert unseres Geschäfts. Wir müssen also diejenigen Opportunities finden, die zum erwünschten Geschäftsergebnis führen. Damit können wir die Spannung zwischen Kundenbedürfnis und Business Needs auflösen. Und genau diese Spannung habe ich in den letzten fünf Jahren in Produkt-Teams sehr oft miterlebt bis hin zur Frage: Was ist wichtiger, das Firmenziel oder die Kundenbedürfnisse?

Interviews eignen sich gut, um Bedürfnisse, Probleme und Wünsche der Kundinnen und Kunden zu ermitteln. Aber auch das Verkaufsteam oder das Support-Team sind gute Quellen, um an neue Opportunities zu kommen.

Wie aber gelangt man an Kundinnen und Kunden, die sich die Zeit nehmen, Fragen zu beantworten und von ihren Erfahrungen zu erzählen?

Mit den richtigen Fragen Opportunities herausfinden

Sobald man an die Leute heran kommt, muss man nur noch die richtigen Fragen stellen. Das ist aber alles andere als einfach. Wir alle sind ziemlich schlecht darin, unser eigenes Verhalten richtig zu erinnern. Fragen nach dem „Was“, dem „Wann“ und dem „Wie oft“ laufen deshalb oft ins Leere. Und unsere Wünsche und Probleme bei der Benutzung von Produkten können wir nur selten präzise formulieren.

Wie können wir dies umgehen? Indem wir Erlebnisberichte und Geschichten sammeln. Teresa nannte in diesem Zusammenhang ein Beispiel, wie sie es bei Netflix gemacht haben: „Erzähl mir davon, als du das letzte Mal Netflix verwendet hast“. Im Kontext von Business Applikationen (wo ich oft tätig bin), könnte die Frage lauten: „Erzähl mir davon, als du Arbeitsablauf X das letzte Mal gemacht hast“. Entscheidend ist, dass die Befragten in diesem spezifischen Kontext verankert bleiben, so dass wir zuverlässigere Berichte erhalten.

Die beste Lösung für das gewünschte Outcome finden

Wurden Opportunities gefunden, gilt es nun Lösungen für diese spezifischen Opportunities zu erarbeiten – und zwar möglichst viele. Warum? Damit man diese miteinander vergleichen kann, um so an die bestmögliche Lösung zu kommen.

Produkt-Teams sind normalerweise überfordert mit all den Ideen, wie man das Produkt weiterentwickeln könnte. Aber sie sind nicht überfordert, wenn es um konkrete Lösungen für eine bestimmte Opportunity geht. Man wählt also eine Opportunity aus und vergleicht die Lösungen, welche genau diese Opportunity adressieren.

Das ist deshalb wichtig, weil wir dazu tendieren eine bestimmte Idee zu bestätigen (der sogenannte Confirmation Bias). Wir verpassen dadurch alle Hinweise darauf, dass die Idee eben doch nicht so gut ist. Wenn man mehrere Lösungen miteinander vergleicht und dann die beste davon auswählt, kann man dieses Problem entschärfen.

Die nachfolgende Illustration ist eine Zusammenfassung dieses Beitrags und lehnt sich direkt an die von Teresa Torres verwendete Grafik an.

Opportunity Solution Tree
Der Opportunity Solution Tree nach Teresa Torres.

Es würde mich sehr interessieren, ob und welche Produkt-Teams bereits auf diese Art und Weise arbeiten und ob sich diese Denkweise besser eignet, als der projektbasierte Ansatz mit Hand-Offs und Silo-Denken. 🙊

Teresa Torres‘ Buch „Continuous Discovery Habits“ ist brandneu und bereits jetzt ein Bestseller. Mehr Informationen zum Thema findet man auf der Webseite https://www.producttalk.org.