Opportunity Solution Tree

Der Baum liest sich von oben nach unten in vier Ebenen. An der Wurzel steht ein einzelner angestrebter Outcome — ein messbares Ziel, das das Team verfolgt, etwa die Aktivierung anzuheben oder die Time-to-Value zu senken. Darunter verzweigen sich Opportunities: Kundenbedürfnisse, Schmerzpunkte und Wünsche, formuliert in den Worten der Kunden selbst, aufgedeckt durch kontinuierliche Discovery. Unter jeder Opportunity sitzen Kandidatenlösungen, und unter jeder Lösung sitzen die Annahmetests oder Experimente, die prüfen, ob die Lösung die Opportunity tatsächlich bewegen wird.

Die Struktur ist bewusst ein Baum, keine Liste. Ein einzelner Outcome verzweigt sich in viele Opportunities, jede Opportunity in mehrere Lösungen, jede Lösung in mehrere Tests. Diese Verzweigung zwingt ein Team, auf jeder Ebene mehr als eine Option offenzuhalten, was das Gegenmittel dazu ist, sich auf die erste plausibel klingende Idee festzulegen.

Die Aufgabe des Baums ist es, Discovery-Entscheidungen sichtbar und hinterfragbar zu machen. Weil jede Lösung nach oben zu einer Opportunity zurückverfolgt werden kann und jede Opportunity zum Outcome, kann jeder fragen: „Welches Kundenbedürfnis bedient das, und welches Ziel bewegt dieses Bedürfnis?“ Ein Feature, das diese Fragen nicht beantworten kann, wird als verwaiste Arbeit entlarvt, bevor es einen Sprint verschlingt.

Er verschiebt auch die Priorisierung. Statt ein flaches Backlog von Features zu ranken, vergleicht das Team zunächst Opportunities gegen den Outcome — beurteilt, welches Bedürfnis, wenn gelöst, das Ziel am stärksten bewegen würde — und erst dann werden Lösungen innerhalb des gewählten Zweigs erkundet. Torres nennt das „Opportunities vergleichen, nicht Lösungen“, und es hält Scoring-Frameworks wie RICE ehrlich, indem sichergestellt wird, dass die bewerteten Elemente echte Kundenbedürfnisse sind und keine vorgefertigten Features.

Der häufigste Fehler ist, Lösungen als Opportunities getarnt zu formulieren. „Eine Slack-Integration hinzufügen“ ist eine Lösung; die eigentliche Opportunity ist „Ich verliere den Überblick über Erwähnungen, weil sie in einem anderen Tool liegen.“ Wenn die Opportunity-Ebene voller Features ist, kollabiert der Baum zu einem Backlog und seine vergleichende Kraft geht verloren. Opportunities müssen als Kundenbedürfnisse formuliert werden, in Kundensprache, losgelöst von einer bestimmten Lösung.

Ein zweiter Fehler ist, den Baum als einmaliges Artefakt zu behandeln. Er soll wöchentlich weiterentwickelt werden, sobald neue Interview-Erkenntnisse eintreffen — Zweige werden hinzugefügt, beschnitten und neu gewichtet. Ein Baum, der sich seit einem Monat nicht verändert hat, ist meist ein Zeichen, dass Discovery still zum Stillstand gekommen ist. Eine dritte Falle ist, die Experimentebene ganz zu überspringen und die erste Lösung unter einer Opportunity direkt auszuliefern — das verwirft genau die Optionsgenerierung, für die die Struktur existiert.

Ein Opportunity Solution Tree ist nur so vertrauenswürdig wie die Evidenz hinter jedem Zweig. In der Praxis liegt diese Evidenz — die Interviewnotiz, das Support-Ticket, das Nutzungssignal, der Umsatz hinter dem Account, der sie gemeldet hat — meist in getrennten Tools, sodass Opportunities von Kundenbedürfnissen zurück in Vermutungen abdriften und Outcomes ihren Bezug zum tatsächlichen Account-Verhalten verlieren.

Ein Betriebssystem fürs Produkt wie AIOProductOS hält diese Evidenz auf einer gemeinsamen Basis verknüpfbar: Sein Insights-Feed zeigt Feedback direkt neben dem Customer-360-Datensatz und dem Umsatz dahinter, sodass eine Opportunity zeigen kann, welche zahlenden Accounts sie gemeldet haben, bevor sie sich einen Zweig verdient — und der Outcome an der Wurzel kann gegen echte Produkt-Analytics verfolgt werden statt gegen eine in eine Folie kopierte Zahl. Der Baum bleibt ein Discovery-Werkzeug; die Basis hält die Evidenz darunter aktuell.