Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value
Zielgruppe des Buches
Continuous Discovery Habits richtet sich an alle, die digitale Produkte entwickeln und Produktentscheidungen auf fundierte Kundenerkenntnisse statt auf Vermutungen stützen möchten.
Die wichtigsten Zielgruppen sind:
Product Manager
Product Owner
Product Designer
UX Researcher
Softwareentwickler
Product Leader
Head of Product
CPOs
Gründer
Agile Coaches
Das Buch richtet sich besonders an Teams, die bereits agil arbeiten, deren Produktentscheidungen jedoch noch überwiegend auf internen Meinungen, Stakeholder-Wünschen oder Roadmaps basieren.
Welche Probleme löst das Buch?
Teresa Torres beschreibt ein Problem, das in vielen Unternehmen auftritt:
Produktteams verbringen den Großteil ihrer Zeit mit der Entwicklung von Features, sprechen jedoch nur selten mit ihren Kunden.
Dadurch entstehen typische Probleme:
Features werden entwickelt, obwohl sie keinen Mehrwert schaffen.
Entscheidungen basieren auf Annahmen statt auf Erkenntnissen.
Discovery findet nur zu Projektbeginn statt.
Kundenfeedback kommt erst nach dem Release.
Roadmaps bestimmen die Arbeit stärker als Kundenprobleme.
Produktteams reagieren langsam auf Veränderungen.
Das Buch zeigt einen alternativen Ansatz:
Discovery wird zu einem festen Bestandteil der täglichen Produktarbeit.
Produktteams lernen kontinuierlich von ihren Kunden und treffen dadurch bessere Entscheidungen.
Überblick über das Buch
Die Hauptthese des Buches lautet:
Die erfolgreichsten Produktteams sprechen kontinuierlich mit Kunden und nutzen diese Erkenntnisse, um bessere Produktentscheidungen zu treffen.
Discovery ist keine Phase.
Discovery ist eine Gewohnheit.
Während viele Unternehmen Delivery kontinuierlich verbessern, behandeln sie Discovery häufig als einmaliges Ereignis.
Teresa Torres fordert stattdessen:
jede Woche Kundenkontakt.
kontinuierliches Lernen.
kontinuierliche Validierung.
kontinuierliche Experimente.
kontinuierliche Verbesserung.
Dadurch sinkt das Risiko, am Kunden vorbei zu entwickeln.
Das zentrale Denkmodell
Das gesamte Buch lässt sich auf einen Kreislauf reduzieren:
Gewünschtes Geschäftsergebnis
↓
Kunden verstehen
↓
Probleme erkennen
↓
Lösungen entwickeln
↓
Annahmen testen
↓
Produkt entwickeln
↓
Ergebnisse messen
↓
Neue Erkenntnisse gewinnen
↓
Erneute Discovery
Dieser Kreislauf endet niemals.
Discovery und Delivery gehören zusammen
Ein zentrales Missverständnis lautet:
Discovery findet statt, bevor entwickelt wird.
Teresa Torres widerspricht.
Discovery läuft parallel zur Entwicklung.
Während Entwickler aktuelle Funktionen umsetzen, untersucht das Team bereits:
neue Kundenprobleme.
neue Chancen.
bessere Lösungen.
offene Risiken.
Dadurch entstehen keine langen Forschungsphasen.
Stattdessen entwickelt sich das Produkt kontinuierlich weiter.
Outcome statt Output
Wie Marty Cagan unterscheidet Teresa Torres konsequent zwischen Output und Outcome.
Output
Output beschreibt:
entwickelte Features.
abgeschlossene Tickets.
veröffentlichte Releases.
Output sagt nichts darüber aus, ob Kunden dadurch erfolgreicher werden.
Outcome
Outcomes beschreiben Veränderungen.
Beispiele:
höhere Conversion.
bessere Kundenbindung.
geringere Kündigungsrate.
schnellere Aktivierung.
mehr aktive Nutzer.
Das gesamte Buch orientiert sich an Outcomes.
Ein Produktteam beginnt deshalb niemals mit einer Feature-Idee.
Es beginnt immer mit einem gewünschten Ergebnis.
Der Ausgangspunkt jeder Discovery
Teresa Torres empfiehlt, jede Discovery mit einer klaren Frage zu beginnen:
Welches Ergebnis möchten wir verbessern?
Beispiele:
Mehr Nutzer sollen ihr Konto aktivieren.
Kunden sollen schneller einkaufen können.
Die Nutzung einer Kernfunktion soll steigen.
Die Abbruchrate soll sinken.
Erst wenn dieses Ziel klar ist, beginnt die eigentliche Discovery.
Das Product Trio
Eines der bekanntesten Konzepte des Buches ist das Product Trio.
Discovery ist keine Aufgabe des Product Managers allein.
Sie wird gemeinsam durchgeführt von:
Product Manager
Bringt Wissen über:
Business.
Markt.
Priorisierung.
Strategie.
ein.
Product Designer
Bringt ein:
Nutzerverständnis.
UX.
Interaktionsdesign.
qualitative Forschung.
Softwareentwickler
Bringt ein:
technische Machbarkeit.
Architektur.
technische Risiken.
alternative Lösungsansätze.
Diese drei Perspektiven ergänzen sich.
Die besten Entscheidungen entstehen dann, wenn alle drei gemeinsam mit Kunden sprechen.
Warum Entwickler an Kundeninterviews teilnehmen sollten
Viele Unternehmen schließen Entwickler von Discovery aus.
Teresa Torres hält dies für einen Fehler.
Entwickler:
hören Kundenprobleme direkt.
verstehen den Nutzungskontext.
entwickeln mehr Empathie.
bringen neue technische Ideen ein.
Dadurch entstehen bessere Lösungen.
Wöchentliche Kundeninterviews
Dies ist wahrscheinlich die bekannteste Empfehlung des Buches.
Jedes Produktteam sollte mindestens einmal pro Woche mit einem Kunden sprechen.
Nicht:
einmal pro Quartal.
nur vor einem großen Projekt.
nur bei Problemen.
Sondern jede Woche.
Dadurch entsteht ein kontinuierlicher Strom neuer Erkenntnisse.
Warum wöchentliche Interviews funktionieren
Regelmäßige Interviews bieten mehrere Vorteile:
Erkenntnisse bleiben aktuell.
Trends werden früh erkannt.
Kleine Probleme werden sichtbar.
Discovery wird zur Routine.
Entscheidungen basieren auf aktuellen Informationen.
Anstatt monatelang Annahmen zu treffen, lernt das Team jede Woche dazu.
Gute Kundeninterviews
Ein häufiger Fehler besteht darin, Kunden nach gewünschten Features zu fragen.
Beispiel:
"Welche Funktion wünschen Sie sich?"
Teresa Torres hält diese Frage für wenig hilfreich.
Menschen sind Experten für ihre Probleme.
Sie sind jedoch selten Experten für die passende Lösung.
Bessere Fragen lauten:
Was wollten Sie erreichen?
Wo hatten Sie Schwierigkeiten?
Wie lösen Sie das Problem heute?
Was war besonders frustrierend?
Warum war das schwierig?
Dadurch erkennt das Team die eigentlichen Bedürfnisse hinter den Wünschen.
Das Ziel eines Interviews
Das Ziel lautet nicht:
Eine Idee bestätigen.
Sondern:
Etwas Neues lernen.
Discovery bedeutet deshalb auch, bereit zu sein, die eigenen Annahmen zu verwerfen.
Die wichtigsten Erkenntnisse der ersten Kapitel
Discovery ist eine kontinuierliche Gewohnheit und keine Projektphase.
Produktteams sollten mindestens einmal pro Woche mit Kunden sprechen.
Discovery beginnt immer mit einem gewünschten Outcome und nicht mit einer Feature-Idee.
Das Product Trio aus Product Manager, Designer und Entwickler trägt gemeinsam die Verantwortung für Discovery.
Kundeninterviews dienen dazu, Probleme zu verstehen, nicht Feature-Wünsche zu sammeln.
Kontinuierliches Lernen reduziert das Risiko von Fehlentwicklungen und verbessert die Qualität von Produktentscheidungen.
Im nächsten Teil behandeln wir das Herzstück des Buches: den Opportunity Solution Tree (OST), Opportunity Mapping, das Finden von Chancen, die Entwicklung mehrerer Lösungsansätze sowie das systematische Testen von Annahmen.
Der Opportunity Solution Tree – Das zentrale Werkzeug von Continuous Discovery
Der Opportunity Solution Tree (OST) ist das wichtigste Framework in Continuous Discovery Habits. Teresa Torres entwickelt damit eine Methode, um Produktentscheidungen strukturiert von einem gewünschten Ergebnis bis zur konkreten Lösung zu führen.
Viele Teams springen direkt von einem Problem zu einer Lösung:
Kunde beschwert sich über komplizierten Checkout.
↓
Team entwickelt einen vereinfachten Checkout.
Das Problem:
Es wurde nur eine mögliche Lösung betrachtet.
Vielleicht gibt es bessere Möglichkeiten.
Der Opportunity Solution Tree verhindert dieses vorschnelle Springen.
Er zwingt Teams dazu, zuerst das Problemfeld zu verstehen und mehrere Lösungswege zu untersuchen.
Die vier Ebenen des Opportunity Solution Tree
Der Opportunity Solution Tree besteht aus vier Ebenen:
Desired Outcome
Ganz oben steht das gewünschte Ergebnis.
Die Frage lautet:
Welche Veränderung möchten wir erreichen?
Beispiele:
Mehr Kunden sollen einen Kauf abschließen.
Nutzer sollen schneller den ersten Erfolg erleben.
Kunden sollen länger aktiv bleiben.
Supportanfragen sollen reduziert werden.
Das Outcome beschreibt nicht die Lösung.
Es beschreibt den Erfolg.
Opportunities
Unterhalb des Outcomes stehen Opportunities.
Opportunities sind Kundenprobleme, Bedürfnisse oder Wünsche.
Sie beantworten die Frage:
Welche Möglichkeiten gibt es, das gewünschte Ergebnis zu verbessern?
Beispiel:
Outcome:
"Mehr Kunden sollen den Kauf abschließen."
Mögliche Opportunities:
Kunden verstehen die Versandkosten nicht.
Der Bezahlprozess dauert zu lange.
Kunden haben Sicherheitsbedenken.
Kunden finden bestimmte Produkte nicht.
Wichtig:
Eine Opportunity ist keine Lösung.
Sie beschreibt eine Chance zur Verbesserung.
Solutions
Unterhalb der Opportunities entstehen mögliche Lösungen.
Beispiel:
Opportunity:
"Kunden verstehen Versandkosten nicht."
Mögliche Lösungen:
Versandkosten früher anzeigen.
Beispielrechnungen ergänzen.
FAQ direkt im Checkout anbieten.
Lieferzeit transparenter darstellen.
Der Vorteil:
Das Team betrachtet mehrere Möglichkeiten statt nur eine Idee.
Assumptions
Unterhalb der Lösungen stehen Annahmen.
Jede Lösung basiert auf Annahmen.
Beispiel:
Lösung:
"Versandkosten früher anzeigen."
Annahmen:
Kunden brechen wegen fehlender Transparenz ab.
Frühe Anzeige erhöht Vertrauen.
Kunden verstehen die Darstellung.
Diese Annahmen müssen getestet werden.
Warum der Opportunity Solution Tree wichtig ist
Der OST löst mehrere typische Produktprobleme.
Problem: Zu frühes Springen zu Lösungen
Viele Unternehmen starten mit:
"Wir brauchen eine App."
"Wir brauchen KI."
"Wir brauchen diese Funktion."
Der OST fragt zuerst:
"Welches Problem versuchen wir zu lösen?"
Dadurch entsteht mehr Kreativität.
Problem: Stakeholder bestimmen Features
Ein Stakeholder kommt häufig mit einer fertigen Lösung:
"Wir brauchen einen Export-Button."
Ein Produktteam sollte jedoch fragen:
"Welches Problem steckt dahinter?"
Vielleicht möchte der Nutzer:
Daten teilen.
Berichte erstellen.
Informationen archivieren.
Die beste Lösung könnte völlig anders aussehen.
Problem: Fehlende Priorisierung
Ohne Struktur konkurrieren viele Ideen miteinander.
Der OST hilft bei der Entscheidung:
Welche Opportunity hat:
den größten Kundennutzen?
den größten Einfluss auf das Outcome?
die höchste Wahrscheinlichkeit für Erfolg?
Opportunity Mapping
Opportunity Mapping bedeutet, Kundenprobleme systematisch zu sammeln und zu strukturieren.
Die zentrale Frage lautet:
Warum erreichen Kunden ihr Ziel heute nicht optimal?
Dabei unterscheidet Teresa Torres zwischen:
Kundenproblem
Etwas funktioniert nicht gut.
Beispiel:
"Ich finde wichtige Informationen nicht."
Kundenbedürfnis
Etwas könnte besser funktionieren.
Beispiel:
"Ich möchte schneller Entscheidungen treffen."
Lösungsidee
Eine mögliche Umsetzung.
Beispiel:
"Wir bauen eine intelligente Suche."
Diese drei Ebenen dürfen nicht vermischt werden.
Von Kundeninterviews zu Opportunities
Kundeninterviews liefern zunächst Geschichten.
Beispiel:
"Ich habe gestern zwanzig Minuten gebraucht, um die richtige Einstellung zu finden."
Das Team übersetzt diese Aussage in eine Opportunity:
"Neue Nutzer benötigen zu lange, um zentrale Funktionen zu verstehen."
Diese Opportunity kann anschließend untersucht werden.
Nicht jede Kundenäußerung ist eine Opportunity
Teresa Torres warnt davor, jede Aussage eines Kunden direkt in eine Produktentscheidung umzuwandeln.
Ein einzelner Kunde kann sagen:
"Ich möchte einen Export als Excel-Datei."
Die eigentliche Frage lautet:
Warum?
Mögliche Gründe:
Er möchte Daten analysieren.
Er möchte sie weitergeben.
Er benötigt Dokumentation.
Die eigentliche Opportunity kann ganz anders aussehen.
Lösungen explorieren statt auswählen
Ein häufiger Fehler:
Das Team entwickelt sofort die erste Idee.
Teresa Torres empfiehlt dagegen:
Generiere mehrere mögliche Lösungen.
Warum?
Die erste Idee ist selten die beste.
Mehrere Lösungsoptionen ermöglichen:
bessere Vergleiche.
kreativeres Denken.
geringeres Risiko.
Solution Space
Der Bereich möglicher Lösungen wird als Solution Space bezeichnet.
Ein gutes Produktteam hält diesen Raum möglichst lange offen.
Beispiel:
Opportunity:
"Kunden verstehen unser Produktangebot nicht."
Mögliche Lösungen:
bessere Navigation.
Personalisierung.
Empfehlungen.
Vergleichsfunktion.
bessere Inhalte.
Erst durch Discovery wird entschieden, welche Lösung den größten Nutzen bringt.
Das Produktteam als Problemlöser
Teresa Torres verändert damit die Rolle des Produktteams.
Traditionell:
Management gibt Features vor.
Team setzt um.
Modern:
Team versteht Probleme.
Team untersucht Möglichkeiten.
Team entwickelt Lösungen.
Team misst Ergebnisse.
Das Produktteam wird vom Feature-Lieferanten zum Problemlöser.
Priorisierung im Opportunity Solution Tree
Nicht jede Opportunity verdient Aufmerksamkeit.
Teams müssen entscheiden:
Welche Chancen sind besonders wertvoll?
Teresa Torres empfiehlt mehrere Kriterien.
Kundennutzen
Wie wichtig ist das Problem für Kunden?
Fragen:
Wie häufig tritt es auf?
Wie stark ist die Frustration?
Gibt es bereits Umgehungslösungen?
Geschäftlicher Nutzen
Wie stark unterstützt die Opportunity die Unternehmensziele?
Beispiele:
Umsatzsteigerung.
Kostenreduktion.
Kundenbindung.
Marktanteil.
Sicherheit der Erkenntnisse
Wie gut verstehen wir das Problem?
Eine Opportunity mit vielen Kundenbelegen ist wertvoller als eine reine Vermutung.
Aufwand und Risiko
Manche Lösungen sind sehr komplex.
Eine kleinere Verbesserung kann manchmal größeren Nutzen bringen.
Discovery als Risikoreduktion
Der gesamte Ansatz von Teresa Torres basiert auf einem Prinzip:
Jede Discovery-Aktivität sollte eine wichtige Unsicherheit reduzieren.
Beispiele:
Unsicherheit:
"Kunden verstehen unser Produkt nicht."
Test:
Usability-Test mit Prototyp.
Unsicherheit:
"Kunden würden dafür bezahlen."
Test:
Kaufabsicht messen.
Unsicherheit:
"Die technische Umsetzung ist schwierig."
Test:
Technischer Prototyp.
Die wichtigsten Erkenntnisse dieses Kapitels
Der Opportunity Solution Tree verbindet Business-Ziele, Kundenprobleme und Lösungen.
Teams sollten nicht mit Features beginnen, sondern mit Outcomes.
Opportunities beschreiben Probleme, keine Lösungen.
Gute Discovery untersucht mehrere Lösungswege.
Jede Lösung basiert auf Annahmen, die getestet werden müssen.
Kundenwünsche müssen hinterfragt werden, um das eigentliche Problem zu verstehen.
Das Produktteam ist verantwortlich dafür, die beste Lösung zu finden – nicht nur Anforderungen umzusetzen.
Discovery reduziert Unsicherheit, bevor teure Entwicklung beginnt.
Im nächsten Teil folgen die Kapitel zu Hypothesen und Annahmen, Experimenten, Prototyping, Testmethoden, wie man gute Discovery-Fragen stellt und wie Teams Continuous Discovery dauerhaft als Arbeitsweise etablieren.
Annahmen verstehen und testen
Ein zentraler Gedanke von Teresa Torres lautet:
Jede Produktentscheidung basiert auf Annahmen.
Viele Teams erkennen diese Annahmen jedoch nicht bewusst.
Sie behandeln Vermutungen wie Fakten.
Beispiel:
"Unsere Kunden möchten eine mobile App."
Diese Aussage klingt wie eine Tatsache.
In Wirklichkeit stecken mehrere Annahmen dahinter:
Kunden haben ein Problem, das eine App löst.
Kunden würden die App nutzen.
Die App bietet mehr Nutzen als bestehende Lösungen.
Die Entwicklungskosten stehen im Verhältnis zum Nutzen.
Continuous Discovery macht diese Annahmen sichtbar und überprüfbar.
Warum Annahmen gefährlich sind
Produktteams arbeiten ständig mit Unsicherheit.
Niemand weiß mit hundertprozentiger Sicherheit:
welche Probleme Kunden wirklich haben.
welche Lösung funktioniert.
welche Funktionen genutzt werden.
welche Geschäftsmodelle erfolgreich sind.
Das Ziel von Discovery ist deshalb nicht, absolute Sicherheit zu erreichen.
Das Ziel ist:
Die wichtigsten Unsicherheiten möglichst früh und günstig reduzieren.
Annahmen identifizieren
Teresa Torres empfiehlt, jede Idee genauer zu untersuchen.
Eine einfache Methode:
Frage:
"Was müsste wahr sein, damit diese Idee funktioniert?"
Beispiel:
Idee:
"Wir entwickeln eine KI-basierte Produktempfehlung."
Mögliche Annahmen:
Kunden wünschen personalisierte Empfehlungen.
Empfehlungen erhöhen Käufe.
Kunden vertrauen den Vorschlägen.
Die technische Qualität reicht aus.
Jede dieser Annahmen kann getestet werden.
Die Risikopyramide
Nicht alle Annahmen sind gleich wichtig.
Teresa Torres unterscheidet verschiedene Arten von Risiken.
Value Risk
Wollen Kunden diese Lösung?
Dies ist oft das größte Risiko.
Eine technisch perfekte Lösung ist wertlos, wenn niemand sie benötigt.
Usability Risk
Verstehen Kunden die Lösung?
Eine gute Idee kann scheitern, wenn Nutzer sie nicht bedienen können.
Feasibility Risk
Kann das Team die Lösung realisieren?
Technische Herausforderungen müssen früh erkannt werden.
Viability Risk
Passt die Lösung zum Unternehmen?
Beispiele:
Geschäftsmodell.
Datenschutz.
rechtliche Anforderungen.
strategische Ziele.
Die wichtigste Annahme zuerst testen
Ein häufiger Fehler:
Teams testen einfache Dinge, während die größten Risiken unbekannt bleiben.
Beispiel:
Ein Team optimiert die Farbe eines Buttons.
Gleichzeitig ist unklar, ob Kunden das Produkt überhaupt benötigen.
Die wichtigere Frage wäre:
"Existiert dieses Kundenproblem wirklich?"
Discovery sollte immer mit den größten Unsicherheiten beginnen.
Experimente als Lernwerkzeug
Experimente sind der praktische Weg, Annahmen zu überprüfen.
Ein Experiment beantwortet eine konkrete Frage.
Nicht:
"Wir testen diese Idee."
Sondern:
"Wir möchten herausfinden, ob diese Annahme stimmt."
Eigenschaften guter Experimente
Ein gutes Experiment ist:
Schnell
Es liefert Erkenntnisse innerhalb kurzer Zeit.
Günstig
Es benötigt möglichst wenig Ressourcen.
Aussagekräftig
Es liefert Informationen, die eine Entscheidung ermöglichen.
Fokussiert
Es untersucht eine konkrete Annahme.
Prototyping als Discovery-Methode
Teresa Torres nutzt Prototypen nicht nur für Design.
Prototypen sind Werkzeuge zum Lernen.
Sie ermöglichen:
Ideen sichtbar machen.
Kundenreaktionen beobachten.
Missverständnisse erkennen.
Alternativen vergleichen.
Ein Prototyp muss nicht perfekt sein.
Er muss nur gut genug sein, um eine Frage zu beantworten.
Verschiedene Arten von Prototypen
Konzeptprototypen
Sie zeigen eine Idee auf hoher Ebene.
Geeignet für:
erste Gespräche.
Verständnisfragen.
frühe Validierung.
Wireframes
Sie zeigen:
Struktur.
Navigation.
Informationsarchitektur.
Sie eignen sich besonders für frühe UX-Tests.
Klickbare Prototypen
Sie simulieren ein echtes Produkt.
Damit können Nutzer Aufgaben durchführen.
Technische Prototypen
Sie untersuchen:
technische Machbarkeit.
Performance.
Integrationen.
Kunden mit Prototypen testen
Ein häufiger Fehler:
Kunden werden gefragt:
"Gefällt Ihnen diese Idee?"
Das führt oft zu unzuverlässigen Antworten.
Menschen möchten höflich sein.
Besser:
Beobachte Verhalten.
Beispiele:
Kann der Nutzer eine Aufgabe erledigen?
Versteht er die Funktion?
Wo entstehen Probleme?
Welche Fragen stellt er?
Verhalten liefert bessere Erkenntnisse als Meinungen.
Gute Discovery-Fragen stellen
Die Qualität der Erkenntnisse hängt stark von den Fragen ab.
Schlechte Fragen:
"Gefällt Ihnen unser neues Feature?"
Warum schlecht?
Der Nutzer bewertet eine hypothetische Situation.
Bessere Fragen:
"Wie lösen Sie dieses Problem heute?"
"Was machen Sie, wenn dieses Problem auftritt?"
"Wann hatten Sie zuletzt diese Schwierigkeit?"
Vergangenes Verhalten ist wertvoller als Zukunftsversprechen
Menschen können zukünftiges Verhalten schlecht vorhersagen.
Beispiel:
Frage:
"Würden Sie diese Funktion nutzen?"
Antwort:
"Ja, wahrscheinlich."
Das bedeutet wenig.
Besser:
"Wie haben Sie dieses Problem bisher gelöst?"
Vergangenes Verhalten zeigt tatsächliche Bedürfnisse.
Continuous Discovery und User Research
Teresa Torres grenzt Continuous Discovery von klassischer User Research ab.
Klassische Forschung wird häufig separat durchgeführt:
Research-Team untersucht Kunden.
↓
Bericht wird erstellt.
↓
Produktteam liest Ergebnisse.
Das Problem:
Wissen bleibt oft theoretisch.
Continuous Discovery integriert Forschung direkt in die Produktarbeit.
Das Product Trio spricht selbst mit Kunden und verarbeitet Erkenntnisse sofort.
Die Rolle des Product Designers
Im Continuous-Discovery-Modell verändert sich die Rolle des Designers.
Designer sind nicht nur für Screens verantwortlich.
Sie sind Experten für:
Nutzerverständnis.
Problemdefinition.
Lösungsfindung.
Experimente.
Sie gestalten nicht nur Oberflächen.
Sie gestalten Erfahrungen.
Discovery und Agile Entwicklung
Teresa Torres verbindet Continuous Discovery mit agilen Methoden.
Agil bedeutet nicht nur:
"Schneller entwickeln."
Agil bedeutet:
"Schneller lernen."
Ein agiles Produktteam verkürzt deshalb nicht nur Entwicklungszyklen.
Es verkürzt auch Lernzyklen.
Der ideale Ablauf:
Hypothese
↓
Experiment
↓
Erkenntnis
↓
Entscheidung
↓
Umsetzung
↓
Messung
↓
Neue Hypothese
Die wichtigsten Erkenntnisse dieses Kapitels
Jede Produktidee basiert auf Annahmen.
Gute Teams machen Annahmen sichtbar.
Discovery reduziert Unsicherheit, bevor große Investitionen entstehen.
Die wichtigsten Risiken sollten zuerst getestet werden.
Experimente dienen nicht dazu, Ideen zu beweisen, sondern um zu lernen.
Prototypen müssen nicht perfekt sein, sondern Erkenntnisse liefern.
Kundenverhalten ist zuverlässiger als hypothetische Aussagen.
Discovery gehört in die tägliche Arbeit des Produktteams und nicht in eine separate Forschungsphase.
Im nächsten Teil folgen die weiteren Kernkonzepte des Buches:
Opportunity Priorisierung
Wie man aus Kundeninterviews echte Chancen ableitet
Story Mapping und Opportunity Mapping
Wie Teams gute Lösungen auswählen
Discovery als feste Gewohnheit im Unternehmen etablieren.
Opportunity Priorisierung – Welche Probleme verdienen Aufmerksamkeit?
Nachdem ein Produktteam Opportunities identifiziert hat, entsteht eine neue Herausforderung:
Welche dieser Chancen sollten wir zuerst verfolgen?
Viele Unternehmen priorisieren nach:
Lautstärke eines Stakeholders.
politischem Einfluss.
Aufwandsschätzung.
Bauchgefühl.
Anzahl der Kundenwünsche.
Teresa Torres zeigt einen anderen Ansatz:
Priorisierung sollte sich an Kundennutzen, Geschäftswert und Erkenntnissen orientieren.
Das Ziel ist nicht, möglichst viele Ideen umzusetzen.
Das Ziel ist, die wichtigsten Probleme zu lösen.
Warum Feature-Priorisierung problematisch ist
Eine klassische Priorisierungsliste sieht häufig so aus:
Feature A: hohe Priorität
Feature B: mittlere Priorität
Feature C: niedrige Priorität
Das Problem:
Features sind bereits Lösungen.
Dadurch wird die Diskussion auf die Umsetzung gelenkt.
Die wichtigere Frage lautet:
Welche Kundenprobleme haben den größten Einfluss auf unser gewünschtes Ergebnis?
Erst danach wird über Lösungen gesprochen.
Opportunity Backlog statt Feature Backlog
Teresa Torres empfiehlt, nicht nur eine Feature-Liste zu führen.
Stattdessen sollte ein Team ein Verständnis für Opportunities entwickeln.
Ein Opportunity Backlog enthält:
Kundenprobleme.
Bedürfnisse.
unerfüllte Wünsche.
Nutzungshindernisse.
Verbesserungschancen.
Der Vorteil:
Das Team bleibt offen für verschiedene Lösungen.
Die Bedeutung von Customer Pain
Nicht jede Beschwerde ist gleich wichtig.
Ein Kunde kann sich über eine Kleinigkeit ärgern.
Eine andere Schwierigkeit verhindert möglicherweise eine komplette Nutzung des Produkts.
Deshalb sollten Teams untersuchen:
Häufigkeit
Wie oft tritt das Problem auf?
Intensität
Wie stark beeinträchtigt das Problem den Kunden?
Bedeutung
Wie wichtig ist der betroffene Prozess für das Kundenziel?
Aktuelle Alternativen
Wie lösen Kunden das Problem heute?
Je größer der tatsächliche Schmerz, desto wertvoller die Opportunity.
Der Unterschied zwischen Bedürfnissen und Lösungen
Ein häufiger Fehler in Produktteams:
Eine Lösung wird als Kundenbedürfnis interpretiert.
Beispiel:
Kunde:
"Ich brauche einen Export als PDF."
Oberflächlich:
Opportunity:
"PDF-Export anbieten."
Tiefer betrachtet:
Warum?
Mögliche Gründe:
Daten teilen.
Berichte erstellen.
Informationen archivieren.
Entscheidungen vorbereiten.
Die tatsächliche Opportunity könnte sein:
"Der Kunde benötigt eine einfache Möglichkeit, Ergebnisse mit anderen Personen zu teilen."
Dadurch entstehen mehr Lösungsoptionen.
Das Opportunity-Solution Tree als Entscheidungswerkzeug
Der Opportunity Solution Tree hilft Teams, den Zusammenhang sichtbar zu machen.
Beispiel:
Outcome
Mehr Nutzer schließen die Registrierung ab.
↓
Opportunities
Nutzer verstehen den Nutzen nicht.
Registrierung dauert zu lange.
Nutzer haben Sicherheitsbedenken.
↓
Lösungen
Für "Registrierung dauert zu lange":
weniger Formularfelder.
Social Login.
automatische Datenübernahme.
↓
Experimente
Welche Lösung reduziert tatsächlich Abbrüche?
Diese Struktur verhindert, dass Teams blind eine einzelne Idee verfolgen.
Die Suche nach der besten Lösung
Teresa Torres betont:
Die erste Lösung ist selten die beste.
Gute Teams erzeugen bewusst mehrere Optionen.
Ein Beispiel:
Problem:
"Kunden finden Produkte nicht."
Mögliche Lösungen:
bessere Suche.
bessere Kategorien.
Empfehlungen.
personalisierte Startseite.
Filter verbessern.
Anschließend werden die Optionen getestet.
Divergentes und konvergentes Denken
Ein wichtiges Muster in Discovery:
Divergentes Denken
Viele Möglichkeiten erzeugen.
Fragen:
Welche Probleme gibt es?
Welche Lösungen wären denkbar?
Welche Alternativen existieren?
Ziel:
Den Lösungsraum erweitern.
Konvergentes Denken
Die besten Möglichkeiten auswählen.
Fragen:
Welche Idee hat den größten Nutzen?
Welche Annahme ist kritisch?
Was sollten wir testen?
Ziel:
Fokus herstellen.
Viele Unternehmen wechseln zu früh zur Konvergenz.
Sie entscheiden sich für die erste Idee.
Die Rolle von Experimenten bei Entscheidungen
Discovery ersetzt nicht Entscheidungen.
Sie verbessert Entscheidungen.
Ein Team kann nie alle Unsicherheiten beseitigen.
Aber es kann bessere Entscheidungen treffen.
Beispiel:
Annahme:
"Kunden würden eine Premium-Funktion kaufen."
Experiment:
Landingpage mit Preis testen.
Ergebnis:
Nur wenige Kunden zeigen Interesse.
Entscheidung:
Idee verwerfen oder verändern.
Dadurch wurden Monate Entwicklungszeit gespart.
Continuous Discovery als Gewohnheit
Der wichtigste Begriff im Buch steht bereits im Titel:
Habits
Teresa Torres möchte keine einmalige Discovery-Methode vermitteln.
Sie möchte Gewohnheiten schaffen.
Eine Gewohnheit ist eine regelmäßige Handlung, die automatisch Teil der Arbeitsweise wird.
Die wichtigsten Discovery-Gewohnheiten
Regelmäßiger Kundenkontakt
Empfehlung:
Mindestens wöchentlich Gespräche mit Kunden führen.
Nicht nur bei Problemen.
Nicht nur vor großen Projekten.
Sondern kontinuierlich.
Gemeinsame Discovery im Product Trio
Product Manager, Designer und Entwickler untersuchen gemeinsam:
Kundenprobleme.
Lösungen.
Experimente.
Kontinuierliches Experimentieren
Jede Woche sollte das Team lernen:
Welche Annahmen sind richtig?
Welche sind falsch?
Was verändert unsere Prioritäten?
Discovery-Rhythmus etablieren
Ein praktischer Rhythmus könnte aussehen:
Jede Woche
Kundeninterviews durchführen.
Erkenntnisse dokumentieren.
neue Opportunities bewerten.
Regelmäßig
Opportunity Solution Tree aktualisieren.
Experimente planen.
Lösungen testen.
Kontinuierlich
Ergebnisse messen.
Erkenntnisse teilen.
Strategie anpassen.
Erkenntnisse dokumentieren
Ein häufiger Fehler:
Teams führen Gespräche und vergessen die Erkenntnisse.
Teresa Torres empfiehlt, Wissen sichtbar zu machen.
Dokumentiert werden sollten:
Beobachtungen.
Kundenprobleme.
Opportunities.
Annahmen.
Testergebnisse.
Dadurch entsteht ein gemeinsames Verständnis.
Discovery ist kein zusätzlicher Aufwand
Viele Teams sagen:
"Wir haben keine Zeit für Discovery."
Teresa Torres argumentiert:
Das Gegenteil ist richtig.
Fehlende Discovery erzeugt später mehr Aufwand:
falsche Features.
Überarbeitung.
technische Verschwendung.
enttäuschte Kunden.
Discovery spart Zeit, weil bessere Entscheidungen früher getroffen werden.
Die Verbindung zu Marty Cagans Produktphilosophie
Inspired und Continuous Discovery Habits ergänzen sich.
Marty Cagan beschreibt:
Wie erfolgreiche Produktorganisationen aufgebaut sind.
Teresa Torres beschreibt:
Wie Produktteams täglich arbeiten können.
Gemeinsam entsteht ein modernes Produktmodell:
Cagan
Empowered Product Teams.
↓
Torres
Continuous Discovery Habits.
↓
Ergebnis
Teams, die eigenständig Kundenprobleme entdecken und wertvolle Lösungen entwickeln.
Die wichtigsten Erkenntnisse dieses Abschnitts
Priorisiert werden sollten Probleme, nicht Features.
Eine Opportunity beschreibt eine Chance zur Verbesserung, keine Lösung.
Kundenwünsche müssen hinterfragt werden, um das eigentliche Bedürfnis zu verstehen.
Gute Discovery hält den Lösungsraum lange offen.
Teams sollten erst breit denken und anschließend fokussieren.
Experimente helfen, bessere Entscheidungen zu treffen.
Discovery wird erfolgreich, wenn sie als feste Gewohnheit etabliert wird.
Kontinuierliches Lernen ersetzt starre Produktplanung.
Im nächsten Teil folgen die abschließenden Kapitel:
Wie man Discovery im Unternehmen skaliert
Wie man Teams und Stakeholder einbindet
Messung von Produktwert
Praktische Frameworks für den Alltag
Gesamtzusammenfassung und Checkliste von Continuous Discovery Habits.
Discovery im Unternehmen etablieren und skalieren
Nachdem Teresa Torres die Methoden für einzelne Produktteams erklärt hat, widmet sie sich der Frage, wie Continuous Discovery dauerhaft in einer Organisation verankert werden kann.
Der größte Fehler vieler Unternehmen:
Sie führen neue Prozesse ein, ohne die Denkweise zu verändern.
Ein Unternehmen kann zwar:
neue Meetings einführen.
neue Tools kaufen.
neue Frameworks dokumentieren.
Trotzdem bleibt die Produktentwicklung unverändert, wenn Entscheidungen weiterhin auf Meinungen statt Erkenntnissen beruhen.
Continuous Discovery ist deshalb vor allem ein kultureller Wandel.
Die Rolle der Führungskräfte
Führungskräfte spielen eine entscheidende Rolle.
Sie müssen eine Umgebung schaffen, in der Discovery möglich ist.
Dazu gehören:
Zeit für Kundenkontakt einplanen.
Teams Entscheidungsfreiheit geben.
Experimente erlauben.
Lernen belohnen.
Fehler als Erkenntnisse betrachten.
Wenn Führungskräfte nur schnelle Feature-Lieferungen erwarten, wird Discovery immer verdrängt.
Discovery braucht psychologische Sicherheit
Ähnlich wie Marty Cagan und Kim Scott betont Teresa Torres die Bedeutung von Vertrauen.
Produktteams müssen offen sagen können:
"Wir wissen es nicht."
"Unsere Annahme war falsch."
"Diese Idee funktioniert nicht."
"Wir müssen neu denken."
Wenn Fehler bestraft werden, verstecken Teams Unsicherheit.
Das führt dazu, dass schlechte Ideen länger verfolgt werden.
Stakeholder in Discovery einbinden
Stakeholder sind nicht das Problem.
Das Problem entsteht, wenn Stakeholder zu Lösungsgebern werden.
Ein typisches Szenario:
Marketing:
"Wir brauchen eine neue Kampagne mit dieser Funktion."
Vertrieb:
"Ein Kunde möchte dieses Feature."
Management:
"Der Wettbewerb hat diese Funktion."
Ein modernes Produktteam reagiert nicht mit:
"Ja, setzen wir um."
Es fragt:
Welches Problem steckt dahinter?
Wie wichtig ist dieses Problem?
Welche Kunden sind betroffen?
Welche Alternativen gibt es?
Stakeholder als Quelle von Informationen
Stakeholder besitzen wertvolles Wissen.
Zum Beispiel:
Vertrieb kennt:
Kundenfragen.
Kaufhindernisse.
Wettbewerbsargumente.
Support kennt:
häufige Probleme.
Frustrationen.
Missverständnisse.
Marketing kennt:
Markttrends.
Zielgruppen.
Positionierung.
Discovery bedeutet nicht, Stakeholder auszuschließen.
Es bedeutet, ihre Informationen richtig einzuordnen.
Der Unterschied zwischen Ideen und Problemen
Eine wichtige Fähigkeit eines Produktteams ist das Übersetzen.
Aus:
"Wir brauchen einen besseren Filter."
wird:
"Unsere Kunden finden bestimmte Inhalte nicht schnell genug."
Aus:
"Wir brauchen eine mobile App."
wird:
"Unsere Nutzer benötigen unterwegs Zugriff auf zentrale Aufgaben."
Erst wenn das Problem verstanden ist, beginnt die Suche nach Lösungen.
Produktentscheidungen demokratisieren
Teresa Torres beschreibt eine Veränderung der Entscheidungslogik.
Traditionell:
Die wichtigste Person entscheidet.
Beispiel:
CEO entscheidet.
Bereichsleiter entscheidet.
größter Kunde entscheidet.
Modern:
Die beste Erkenntnis entscheidet.
Das bedeutet:
Entscheidungen basieren auf:
Kundenbeobachtungen.
Experimenten.
Daten.
Tests.
Nicht auf Hierarchie.
Messung des Produktwerts
Continuous Discovery endet nicht mit der Entwicklung einer Lösung.
Ein Produktteam muss überprüfen:
Hat die Lösung tatsächlich einen Unterschied gemacht?
Dafür benötigt es geeignete Messgrößen.
Output-Metriken vermeiden
Viele Unternehmen messen:
Anzahl veröffentlichter Features.
Anzahl erledigter Tickets.
Geschwindigkeit der Entwicklung.
Diese Kennzahlen zeigen Aktivität.
Nicht Erfolg.
Outcome-Metriken verwenden
Bessere Kennzahlen zeigen Wirkung.
Beispiele:
Kundenverhalten
Aktivierungsrate.
Nutzungshäufigkeit.
Wiederkehrende Nutzer.
Abschlussraten.
Geschäftsergebnisse
Umsatz.
Kundenbindung.
Kostenreduktion.
Marktanteil.
Kundenerlebnis
Zufriedenheit.
Weiterempfehlungen.
weniger Supportanfragen.
Discovery und OKRs
Teresa Torres verbindet Continuous Discovery gut mit zielorientierten Methoden wie OKRs.
Ein OKR definiert:
Objective
Was möchten wir erreichen?
Beispiel:
"Wir machen den Einstieg für neue Kunden einfacher."
Key Results
Woran erkennen wir Erfolg?
Beispiel:
Aktivierung neuer Nutzer steigt von 40 % auf 60 %.
Zeit bis zur ersten erfolgreichen Nutzung sinkt um 30 %.
Discovery hilft anschließend dabei, Wege zu finden, diese Ergebnisse zu erreichen.
Die richtige Rolle von Roadmaps
Teresa Torres kritisiert nicht grundsätzlich Roadmaps.
Sie kritisiert Roadmaps, die nur eine Liste von Features darstellen.
Eine bessere Roadmap zeigt:
Ziele.
Probleme.
erwartete Ergebnisse.
Beispiel:
Schlecht:
Q1:
Suchfunktion verbessern.
Dashboard erstellen.
Besser:
Q1:
Nutzer sollen relevante Informationen schneller finden.
Das Team untersucht anschließend die beste Lösung.
Discovery in großen Unternehmen
Große Unternehmen haben besondere Herausforderungen:
viele Stakeholder.
komplexe Prozesse.
Abhängigkeiten.
politische Interessen.
Continuous Discovery hilft dabei, Entscheidungen wieder näher an Kunden und Teams zu bringen.
Skalierung durch Teams, nicht durch Prozesse
Viele Unternehmen versuchen zu skalieren durch:
mehr Meetings.
mehr Dokumentation.
mehr Freigaben.
Teresa Torres empfiehlt stattdessen:
Mehr gute Teams.
Ein Unternehmen skaliert Produktentwicklung nicht durch mehr Kontrolle.
Es skaliert durch:
klare Ziele.
autonome Teams.
gemeinsame Prinzipien.
kontinuierliches Lernen.
Die wichtigsten Werkzeuge aus dem Buch
Opportunity Solution Tree
Nutzen:
Probleme strukturieren.
Lösungen vergleichen.
Annahmen sichtbar machen.
Frage:
"Wie können wir unser gewünschtes Ergebnis erreichen?"
Kundeninterviews
Nutzen:
echte Probleme verstehen.
Annahmen überprüfen.
Frage:
"Wie erleben Kunden die Situation heute?"
Experimente
Nutzen:
Unsicherheit reduzieren.
Frage:
"Was müssen wir lernen, bevor wir investieren?"
Prototypen
Nutzen:
Lösungen schnell testen.
Frage:
"Verstehen Nutzer diese Lösung?"
Outcome-Metriken
Nutzen:
Erfolg messen.
Frage:
"Hat unsere Lösung tatsächlich etwas verbessert?"
Gesamtzusammenhang des Buches
Die Kernidee von Continuous Discovery Habits lässt sich als Kreislauf darstellen:
1. Outcome definieren
Was möchten wir verbessern?
↓
2. Kunden verstehen
Welche Probleme erleben Nutzer?
↓
3. Opportunities finden
Welche Chancen ergeben sich daraus?
↓
4. Lösungen entwickeln
Welche Möglichkeiten gibt es?
↓
5. Annahmen testen
Was müssen wir wissen?
↓
6. Kleine Experimente durchführen
Welche Erkenntnisse gewinnen wir?
↓
7. Lösung umsetzen
Welche validierte Idee entwickeln wir?
↓
8. Wirkung messen
Hat die Lösung den gewünschten Effekt?
↓
9. Neue Erkenntnisse sammeln
Was lernen wir für den nächsten Zyklus?
Praktische Anwendung: Checkliste für Continuous Discovery
Kundenverständnis
Führt das Team regelmäßig Kundeninterviews?
Spricht nicht nur der Product Manager, sondern das gesamte Product Trio mit Kunden?
Verstehen wir Probleme statt nur Wünsche?
Discovery-Prozess
Arbeiten wir mit Outcomes statt Feature-Listen?
Haben wir unsere wichtigsten Annahmen sichtbar gemacht?
Testen wir die größten Risiken zuerst?
Opportunity Solution Tree
Ist klar, welches Ergebnis wir verbessern wollen?
Kennen wir die wichtigsten Kundenprobleme?
Betrachten wir mehrere Lösungswege?
Experimente
Wissen wir, was wir lernen möchten?
Nutzen wir die einfachste Testmöglichkeit?
Treffen wir Entscheidungen anhand von Erkenntnissen?
Produktkultur
Dürfen Teams Fehler und Unsicherheit offen ansprechen?
Haben Teams genügend Entscheidungsfreiheit?
Unterstützt das Management Discovery?
Erfolgsmessung
Messen wir Kundennutzen statt Feature-Auslieferung?
Kennen wir unsere wichtigsten Produktkennzahlen?
Lernen wir aus Ergebnissen?
Die wichtigsten Erkenntnisse aus dem gesamten Buch
Gute Produkte entstehen durch kontinuierliches Lernen, nicht durch perfekte Planung.
Discovery ist keine Phase vor der Entwicklung, sondern eine dauerhafte Gewohnheit.
Kundenprobleme sind wichtiger als Feature-Ideen.
Das Product Trio trägt gemeinsam Verantwortung für Produktentscheidungen.
Der Opportunity Solution Tree verbindet Business-Ziele, Kundenprobleme und Lösungen.
Jede Produktidee basiert auf Annahmen, die getestet werden sollten.
Kleine Experimente reduzieren große Risiken.
Kundeninterviews sollten regelmäßig stattfinden.
Erfolgreiche Produktteams messen Wirkung statt Aktivität.
Autonome Teams mit klaren Zielen entwickeln bessere Produkte als Teams, die nur Anforderungen abarbeiten.
Verbindung zu modernen Produktmanagement-Prinzipien
Continuous Discovery Habits ergänzt andere moderne Produktmanagement-Ansätze:
Verbindung zu Marty Cagans Inspired
Marty Cagan beschreibt die Struktur erfolgreicher Produktorganisationen:
Empowered Teams.
Produktmanager.
Designer.
Entwickler.
Produktvision.
Teresa Torres beschreibt den täglichen Arbeitsprozess:
Kundeninterviews.
Opportunities.
Experimente.
kontinuierliches Lernen.
Verbindung zu Melissa Perris Escaping the Build Trap
Beide Autoren kritisieren die Feature-Fabrik.
Die zentrale Veränderung:
Nicht mehr:
"Wie viele Funktionen liefern wir?"
Sondern:
"Welche Probleme lösen wir und welche Wirkung erzielen wir?"
Abschließende Zusammenfassung
Teresa Torres zeigt mit Continuous Discovery Habits, wie Produktteams von reinen Umsetzungsteams zu lernenden Organisationen werden.
Die wichtigste Veränderung lautet:
Nicht bessere Features machen Produkte erfolgreich. Bessere Entscheidungen machen Produkte erfolgreich.
Diese besseren Entscheidungen entstehen durch:
regelmäßigen Kundenkontakt.
strukturierte Problemanalyse.
kleine Experimente.
messbare Outcomes.
enge Zusammenarbeit im Product Trio.
Continuous Discovery ist damit weniger eine Methode als eine Denkweise:
Jede Woche besser verstehen, was Kunden wirklich brauchen, und daraus bessere Produkte entwickeln.