Was vorher fertig sein muss
Ein klar formulierter Outcome oder eine North Star Metric mit Zielwert liegt vor, an dem sich der Tree aufhängt.
Mindestens 5-10 frische Nutzerinterviews aus dem Zielsegment sind durchgeführt, aus denen Opportunities ableitbar sind.
Was vor Start vorliegen muss
Visuelles Board (Miro, FigJam, Mural) mit hierarchischer Tree-Struktur; Sticky-Farben für Outcome (oben), Opportunities (Mitte), Solutions (unten), Experiments (Boden); Link zur Interview-Datenbank.
Product Trio (Product Manager, Designer, Engineering Lead) als Kern; optional Researcher; ein Owner für den Tree, der zwischen Sessions aktualisiert.
Aktueller Outcome mit Zielwert und Baseline; rohe Interview-Notizen oder Highlight Reel der letzten Interviews; bestehende Solutions/Features im Backlog; Lernstand aus laufenden Experimenten.
1-2 h initial, danach 30-60 min wöchentlich
Outcome oben in den Tree setzen, fett markieren. Drei bis fünf Opportunity-Lanes vorbereiten. Sticky-Konvention festlegen. Tree-Owner und Review-Cadence (z. B. wöchentlich Dienstag) festsetzen.
Die eine Frage, die diese Methode beantwortet
Welche Opportunity adressiert das Team als nächstes mit welcher Solution, und welches Experiment liefert das nächste Lernsignal?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Outcome anchor | 10 min | Outcome oben in den Tree setzen als klarer, messbarer Satz mit Baseline und Ziel. Zeitrahmen explizit (z. B. nächste 12 Wochen). | Outcome muss eine User- oder Geschäftsmetrik sein, kein Output („Feature X launchen“). Falscher Outcome erzeugt falsche Opportunities. |
2Phase 2: Opportunities aus Interview-Daten | 30-45 min | Aus Interview-Highlights Customer-Bedarfe, Pain Points und Wünsche destillieren. Jede Opportunity als Nutzersicht-Satz formulieren („Ich möchte … damit …“). Doppelte zusammenfassen, in 3-5 Lanes clustern. | Opportunities sind keine Solutions. „Faster Checkout“ ist Solution-Sprache, „Ich verliere bei langem Checkout Vertrauen“ ist Opportunity-Sprache. |
3Phase 3: Eine Opportunity wählen | 10 min | Team wählt EINE Opportunity zur Vertiefung. Auswahlkriterien: Outcome-Impact, Anzahl der Erwähnungen in Interviews, Adressierbarkeit. | Mehr als eine gleichzeitig zerfasert den Fokus. Tree wächst über Zeit, nicht in einer Session. |
4Phase 4: Solutions divergieren | 20-30 min | Pro gewählter Opportunity 3-5 Solutions sammeln. Erst quantitative Ideation (auch absurde), dann konvergieren. Solutions als kurze Aktion („Inline-Validierung“, „Optionalfelder verstecken“). | Wenn nur eine Solution entsteht, ist Team-Bias zu stark. Mindestens 3 Solutions erzwingen, sonst entgeht die beste Variante. |
5Phase 5: Experiments unter Solutions | 20-30 min | Pro Solution mindestens ein Experiment definieren, das die riskigste Annahme prüft. Pro Experiment: Hypothese, Methode, Erfolgskriterium, geschätzter Aufwand, Owner. | Experiment ist nicht „Solution bauen und schauen“. Es ist ein gezielter Test der Annahme (Prototyp-Test, Fake Door, Interview). Sonst ist es Delivery. |
Was am Ende rauskommt
Living Tree-Diagramm im kollaborativen Whiteboard mit Outcome, Opportunities, Solutions, Experiments und Status-Markern (offen, läuft, gelernt, verworfen). Plus Learning Log als Text-Liste mit Datum und Ergebnis pro Experiment.
Tree ist living document, einzelne Snapshots monatlich als Foto-Export für Historie. Verworfene Opportunities und Solutions nicht löschen, sondern als „verworfen, weil …“ markieren. Sonst wiederholen sich Diskussionen.
Struktur für Outcome, Opportunities, Lösungen und Experimente.
Outcome
- Messbares Ergebnis:
Opportunities
- Opportunity 1:
- Opportunity 2:
- Opportunity 3:
Solutions
- Lösungsidee je Opportunity:
Experiments
- Test:
- Erfolgskriterium:
- Owner:
- Datum:Konkret gefülltes Szenario
## Opportunity Solution Tree — Activation Q3 (Stand 2026-05-15)
**Outcome**: Activation Rate Session 1 von 22% auf 38% bis 30.09.2026.
### Opportunity-Lane 1: „Ich verstehe nach 30 Sek nicht, was das Produkt für mich tut“ (8 Interviews)
- **Solution A**: Interaktives Onboarding-Tutorial
- Exp A1: Prototyp-Test mit 5 Nutzern, Erfolg = 4/5 erreichen Aha-Moment in 2 min. Owner @lisa, läuft KW 21.
- **Solution B**: Personalisierter First-Run-Screen basierend auf Anmelde-Antwort
- Exp B1: A/B-Test mit 1000 Nutzern, Erfolg = +15% Activation. Owner @ben, geplant KW 23.
- **Solution C**: Erklärvideo auf Empty State
- verworfen (zu hoher Aufwand, Annahme ungeprüft)
### Opportunity-Lane 2: „Ich tippe zu lange, bis ich was sehe“ (5 Interviews)
- **Solution D**: Vorausgefüllte Demo-Daten beim ersten Login
- Exp D1: Fake Door im Login-Flow, Erfolg = 30% Click-Rate. Owner @anna, läuft KW 21.
### Learning Log
- KW 19: Exp 0 (Sample-Onboarding-Email) - +3% Click-Through, kein Activation-Impact. Verworfen.
- KW 20: Exp D0 (Tooltip-Highlights) - kein signifikanter Effekt, n=400.Symptome erkennen, gegensteuern
Im Opportunity-Layer stehen Feature-Vorschläge („Dashboard verbessern“) statt Nutzerbedarfe.
Konvertieren: „warum braucht der Nutzer dieses Feature?“. Antwort wird zur Opportunity, Feature rutscht in den Solution-Layer.
Outcome lautet „Feature X launchen“ oder „Roadmap-Item Y liefern“.
Outcome auf User- oder Geschäftsmetrik umstellen. Was passiert beim Nutzer, wenn der Output geliefert ist? Das ist der echte Outcome.
Team bearbeitet 5 Opportunities gleichzeitig, jede mit 2 Experimenten.
Fokus auf eine Opportunity pro Iteration. Solution-Tiefe schlägt Opportunity-Breite. WIP-Limit auf 2 aktive Experimente.
Tree wird einmal pro Quartal aufgesetzt und dann vergessen, keine Updates aus Experimenten.
Wöchentliche Refinement-Session mit Trio. Tree-Updates sind Pflichtinhalt jedes Reviews, sonst wird er irrelevant.
Unter Solutions stehen Roadmap-Items, die einfach umgesetzt und „getrackt“ werden.
Experiment-Definition strikt: Hypothese, Test-Methode, Erfolgskriterium VOR Bau. Wenn das Ergebnis irrelevant ist für den Bau-Entscheid, ist es kein Experiment.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.