Opportunity Solution Tree
Was ist es?
Visuelles Discovery-Werkzeug von Teresa Torres (Product-Discovery-Coach, Gründerin von Product Talk), 2016 als Teil ihres Continuous-Discovery-Frameworks eingeführt und im Buch "Continuous Discovery Habits" (2021) ausführlich beschrieben. Der Baum verbindet ein Geschäfts-/Produktziel über mehrere Ebenen mit konkreten, testbaren Experimenten:
Outcome (Ziel): Ein klares, messbares Ergebnis an der Wurzel – explizit ein Produkt-Outcome, keine reine Feature-Lieferung und kein reines Geschäftsziel, sondern eine messbare Verhaltensänderung der Kunden
Opportunity Space (Chancen): Erkenntnisse aus Kundengesprächen über unerfüllte Bedürfnisse, Ziele und Schmerzpunkte, die zum Ziel beitragen könnten
Solutions (Lösungen): Mögliche Wege, diese Bedürfnisse zu erfüllen
Experiments/Assumption Tests: Tests der zugrunde liegenden Annahmen, insbesondere der riskantesten, bevor in die eigentliche Umsetzung investiert wird
Zentrales Prinzip: Erst mit einer kleinen, gut abgegrenzten Opportunity beginnen und diese in ihre zugrunde liegenden Annahmen zerlegen – kleinere Opportunities führen zu kleineren, schneller testbaren Lösungen.
Zielgruppe
Product Trios (PM, Design, Engineering), die kontinuierliche Kundendiscovery statt reiner Feature-Fabrik betreiben wollen
Teams, die regelmäßig (idealerweise wöchentlich) Kundenkontakt haben oder aufbauen wollen
Organisationen, die ihre Roadmap outcome- statt output-getrieben ausrichten möchten (nicht "Feature X liefern", sondern "Kundenverhalten Y verändern")
Product Coaches/Leads, die Discovery-Entscheidungen transparent und nachvollziehbar gegenüber Stakeholdern dokumentieren müssen
Weniger geeignet für: Teams ohne Zugang zu echten Kunden oder ohne Kapazität für regelmäßige Interviews (die Methode lebt von kontinuierlicher Evidenz), sowie für sehr kleine, klar umrissene Einzelaufgaben ohne strategischen Ziel-Bezug
Vorteile
Zwingt Teams, den Problemraum (Opportunities) vollständig zu durchdenken, bevor über Lösungen gesprochen wird – verhindert das häufigste Scheitern in der Produktarbeit: den direkten Sprung vom Ziel zur Feature-Liste
Macht implizite Annahmen explizit sichtbar und ermöglicht so gezieltes Testen der riskantesten Annahmen statt ganzer, aufwendiger Lösungen
Ermöglicht es, Discovery-Arbeit stakeholdergerecht in verdaulicher Form zu zeigen, statt nur Rohdaten oder fertige Schlussfolgerungen zu präsentieren
Fördert schnelleres Testen durch kleinere Opportunities/Lösungen statt großer, evergreen-Chancen
Lebendiges Artefakt, das mit fortlaufenden Kundengesprächen kontinuierlich aktualisiert wird statt einmalig erstellt zu werden
Nachteile / Risiken
Der größte Fehlerfall ist nicht die falsche Baumstruktur, sondern ein "ausgehungerter" Baum – die Opportunity-Ebene ist nur so ehrlich wie die zugrunde liegende Kundenevidenz, und viele Teams aktualisieren diese bestenfalls quartalsweise
Torres' Benchmark sieht wöchentliche Kundeninterviews vor, doch Umfragen zeigen, dass weniger als jedes fünfte Produktteam diesen Takt tatsächlich erreicht – der nötige Rekrutierungs-/Interview-/Synthese-Aufwand ist für viele Organisationen kaum leistbar
Erfordert ein bereits klar formuliertes, messbares Produkt-Outcome an der Wurzel – ist dieses vage, wird der gesamte Baum instabil
Baum kann bei komplexen Produkten schnell groß und unübersichtlich werden, Pflege und Priorisierung erfordern Disziplin
Wie bei jedem Framework besteht die Gefahr, es "nach Lehrbuch" statt organisationsspezifisch angepasst anzuwenden – echter Mehrwert entsteht erst durch Anpassung an die eigenen Rahmenbedingungen
Alternativen / ergänzende Frameworks
Ansatz | Ausrichtung |
|---|---|
Impact Mapping (Gojko Adzic) | Ähnliche Grundidee (Ziel → Akteure → Verhalten → Deliverables), aber weniger auf kontinuierliches Kundeninterviewing ausgelegt |
Opportunity Assessment (Marty Cagan) | Einmalige Vorprüfung einer einzelnen Idee, kein fortlaufender Baum |
Jobs-to-be-Done | Liefert oft die inhaltliche Grundlage für die Opportunity-Ebene des Baums |
Drivers Model / Metric Tree | Kennzahlenbasierte Zerlegung eines Ziels, ohne die qualitative Kundenopportunity-Ebene |
Design Sprint (Google Ventures) | Schnelles, zeitlich begrenztes Testen einzelner Lösungen statt fortlaufender Discovery-Struktur |
Lean Startup / Build-Measure-Learn | Ähnliches Prinzip des Annahmentests, aber ohne explizite Baum-Visualisierung |
Sonstiges wichtig für die Entscheidung
Das Outcome an der Spitze legt den gesamten Scope der Discovery fest – es hilft dem Team zu verstehen, welche Opportunities überhaupt relevant sind und welche Art von Lösungen in Frage kommt
Am Ende eines Discovery-Zyklus entscheidet das Team entweder, eine Idee weiter zu verfeinern und auszuliefern, oder festzustellen, dass die Opportunity nicht lieferbar ist und eine neue Ziel-Opportunity zu wählen
Für die Einführung ist ein funktionierendes Product Trio (PM, Design, Engineering) mit tatsächlichem Entscheidungsmandat wichtig – ohne dieses "empowered team"-Setup bleibt der Baum eine reine Dokumentationsübung
Es existieren mittlerweile spezialisierte Tools (Jira-Discovery-Plugins, dedizierte OST-Software) sowie KI-gestützte Interview-Tools, die die Interview-Taktzahl praktisch skalierbarer machen – für Teams mit chronischem Ressourcenmangel bei Kundenkontakt relevant
Offizielle Vertiefung: Torres bietet einen eigenen Kurs ("Product Discovery Fundamentals" bei Product Talk Academy) für die strukturierte Einführung im Unternehmen an
Fazit für Entscheider
Sehr wertvolles Werkzeug für Teams, die Produktentscheidungen konsequent an Kundenoutcomes statt an Feature-Wünschen ausrichten wollen, und die bereit sind, kontinuierlich echten Kundenkontakt zu investieren. Der Nutzen steht und fällt mit der Disziplin, den Baum mit frischer Kundenevidenz zu füttern – ohne regelmäßige Interviews wird aus dem lebendigen Discovery-Werkzeug schnell ein statisches, veraltetes Diagramm.