Von vager Produktidee zu klarer Zielgruppe, Problemhypothesen und ersten Lernschritten.
Ein priorisierter Lernplan mit Zielgruppe, Opportunity, Annahmen und erstem Test.
Du kannst entscheiden, welche Opportunity zuerst gelernt oder getestet wird und welche Lösungsideen noch nicht reif für Delivery sind.
Den Test durchführen, Evidenz auswerten und danach Opportunity, Annahmen oder Lösungshypothese aktualisieren.
Welches konkrete Problem welcher Menschen in welchem Kontext ist durch Evidenz belegt, sinnvoll begrenzt und offen genug für mehrere Lösungen?
Der Problem Frame verhindert, dass das Team direkt in Lösungen springt, bevor Zielgruppe, Problem und Entscheidungsbedarf geklärt sind.
Der geschärfte Problemraum wird anschließend in Opportunities, Lösungen und Experimente aufgeteilt.
Welche evidenzgestützten Wege können das gewünschte Outcome über Kundenbedürfnisse und geprüfte Lösungen erreichen?
Der Opportunity Solution Tree verbindet Outcome, Nutzerbedürfnisse, Lösungsideen und Experimente in einer gemeinsamen Landkarte.
Die Landkarte macht sichtbar, welche Annahmen hinter den attraktivsten Pfaden liegen.
Welche Annahmen sind für die Idee entscheidend und haben die schwächste unterstützende Evidenz?
Assumption Mapping priorisiert die Annahmen, bei denen Risiko und Wissenslücke am größten sind.
Die riskanteste Annahme wird danach in einen konkreten Lernschritt übersetzt.
Welche Annahme würde die Idee bei Irrtum am stärksten beschädigen und besitzt zugleich die schwächste belastbare Evidenz?
Der Test fokussiert die Discovery auf die Annahme, die eine Lösungsidee am ehesten kippen kann.
Das Testergebnis entscheidet, ob der Pfad fortgesetzt, angepasst oder verworfen wird.
Die Artefakte bleiben zugeklappt, bis du sie wirklich brauchst.
Gegenstand, Evidenz, Rollen, Ablauf und Review festlegen.
# Problem Framing Workshop: Arbeitsvorlage
## Fragestellung
Noch zu klären
## Gewünschtes Ergebnis
Noch zu klären
## Rahmen
Vollständiger Durchlauf
Zeit: 90–150 Minuten mit vorab gesammelter Evidenz.
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
## Vorbereitung für diesen Umfang
### Methodische Grundausstattung
- **Materialien:** Evidenz aus Research und Betrieb, Stakeholder- und Kontextkarte, Annahmenlog, Problem-Frame und How-Might-We-Frage
- **Rollen:** Facilitator · Problem Owner · Betroffene/Kund:innenperspektive · Fach- und Delivery-Perspektiven · Entscheider:in
- **Vorab-Infos:** Entscheidungsanlass, vorhandene Evidenz und harte Grenzen sammeln; Lösungsideen zunächst parken.
- **Gesamter Zeitbedarf:** 90–150 Minuten mit vorab gesammelter Evidenz.
- **Setup:** Arbeitsfläche mit Evidenz · Akteure · Wirkung · Grenze · Frage vorbereiten; Beispiel und eigene Daten trennen.
### Für die Arbeitsschritte bereitstellen
#### Evidenz: Evidenzbild
- Entscheidungsanlass, vorhandene Evidenz und harte Grenzen sammeln; Lösungsideen zunächst parken.
- Evidenz aus Research und Betrieb, Stakeholder- und Kontextkarte, Annahmenlog, Problem-Frame und How-Might-We-Frage
#### Akteure: Akteurskontext
- Evidenzbild
#### Wirkung: Problemkern
- Akteurskontext
#### Grenze: Scope
- Problemkern
#### Frage: Arbeitsfrage
- Scope
## Problem Framing Workshop · Arbeitsstruktur
### Evidenzbild
Beobachtungen, Daten und Zitate sammeln; Fakten, Interpretationen und Lösungen trennen.
...
### Akteurskontext
Betroffene, Kontext, gewünschter Fortschritt und heutige Hürden konkret beschreiben.
...
### Problemkern
Unerwünschtes Ergebnis, Bedeutung und beobachtbare Auswirkung formulieren, ohne Ursache oder Lösung vorwegzunehmen.
...
### Scope
In-Scope, Out-of-Scope, Constraints, Annahmen und offene Wissenslücken verhandeln.
...
### Arbeitsfrage
Frame in eine offene How-Might-We-Frage übersetzen und gegen Evidenz, Lösungsoffenheit und Handlungsraum prüfen.
...
Die leere Vorlage enthält nur Arbeitsimpulse.
[Fachquelle · eigene Lehrdarstellung](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)
## Evidenz: Evidenzbild
Erwartetes Artefakt: Evidenzbild
Beobachtungen, Daten und Zitate sammeln; Fakten, Interpretationen und Lösungen trennen.
Eintrag:
...
- [ ] Ist jeder Befund auf Quelle oder Fall zurückführbar?
## Akteure: Akteurskontext
Erwartetes Artefakt: Akteurskontext
Betroffene, Kontext, gewünschter Fortschritt und heutige Hürden konkret beschreiben.
Eintrag:
...
- [ ] Ist eine konkrete Personengruppe in einer Situation statt ein Marktsegment benannt?
## Wirkung: Problemkern
Erwartetes Artefakt: Problemkern
Unerwünschtes Ergebnis, Bedeutung und beobachtbare Auswirkung formulieren, ohne Ursache oder Lösung vorwegzunehmen.
Eintrag:
...
- [ ] Beschreibt der Kern Ergebnis und Wirkung statt Symptomwort oder Lösungswunsch?
## Grenze: Scope
Erwartetes Artefakt: Scope
In-Scope, Out-of-Scope, Constraints, Annahmen und offene Wissenslücken verhandeln.
Eintrag:
...
- [ ] Sind Grenze und Nicht-Scope entscheidungsrelevant und nachvollziehbar?
## Frage: Arbeitsfrage
Erwartetes Artefakt: Arbeitsfrage
Frame in eine offene How-Might-We-Frage übersetzen und gegen Evidenz, Lösungsoffenheit und Handlungsraum prüfen.
Eintrag:
...
- [ ] Erlaubt die Frage mehrere Lösungswege und bleibt sie beim belegten Bedarf?
## Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/problem-framing-workshop/run-sheet
Plane den Einstieg und den laufenden Arbeitsrhythmus für Outcome, Opportunities, Lösungen und Tests.
# Opportunity Solution Tree: Arbeitsvorlage
## Fragestellung
Noch zu klären
## Gewünschtes Ergebnis
Noch zu klären
## Rahmen
Kontinuierliche Discovery strukturieren
Zeit: Laufende Praxis; kein Gesamtzeitlimit
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
## Vorbereitung für diesen Umfang
### Methodische Grundausstattung
- **Materialien:** Outcome-Definition, Forschungsnotizen mit Quellen, Opportunity-Clustering, gemeinsame Baumfläche und Platz für Lösungshypothesen und Experimentkarten.
- **Rollen:** Produkttrio oder cross-funktionales Team aus Product, Design/Research und Engineering; Discovery-Verantwortung hält Baum und Evidenz aktuell.
- **Vorab-Infos:** Outcome, Zielgruppe und aktuelle Produkt- oder Kundenbelege sammeln. Kundenaussagen von Interpretationen trennen.
- **Gesamter Zeitbedarf:** Kein einzelner Workshop. Einstieg und erste Struktur in etwa 1–2 Stunden; Interviews, Tests und Aktualisierungen laufen in wiederkehrenden Discovery-Zyklen.
- **Setup:** Outcome oben, Opportunities darunter, Lösungen unter der gewählten Opportunity und Experimente auf Lösungsannahmen abbilden. Nur eine Ziel-Opportunity gleichzeitig vertiefen.
### Für die Arbeitsschritte bereitstellen
#### Outcome: Ein steuerbares Outcome festlegen
- Produktstrategie und Zielgruppe
- Verfügbare Kennzahl oder beobachtbarer Verhaltensindikator
#### Opportunities: Kundenbedürfnisse strukturieren
- Story-basierte Kundengespräche oder Beobachtungen
- Outcome und bestehende Opportunity-Notizen
#### Fokus: Eine Ziel-Opportunity auswählen
- Outcome
- Opportunity Map und zugehörige Kundennotizen
#### Lösungen: Mehrere Lösungswege erkunden
- Ziel-Opportunity und Erfolgssignal
- Produkt-, Design- und technische Perspektiven
#### Lernen: Annahmen testen und Baum aktualisieren
- Lösungsoptionen und explizite Annahmen
- Zugriff auf geeignete Nutzer oder Daten
## Opportunity Solution Tree
### Outcome
Welches steuerbare Ergebnis soll sich verbessern?
...
### Kunden-Opportunities
Welche Bedürfnisse, Pain Points oder Wünsche aus konkreten Kundensituationen könnten das Outcome beeinflussen?
...
### Ziel-Opportunity
Welche Opportunity wählen wir für die nächste Discovery-Runde und warum?
...
### Lösungsoptionen
Welche unterschiedlichen Wege könnten diese Opportunity bedienen?
...
### Annahmen und Tests
Welche riskante Annahme prüft welcher Test, und welche Entscheidung folgt?
...
Leere Vorlage: genau ein Outcome wählen, Opportunities mit Beleg verknüpfen, Ziel-Opportunity markieren, darunter Lösungshypothesen und Tests dokumentieren.
[Quelle: Teresa Torres, Product Talk](https://www.producttalk.org/opportunity-solution-trees/)
## Outcome: Ein steuerbares Outcome festlegen
Erwartetes Artefakt: Outcome als Wurzel des Baums
Ergebnis · Zielgruppe · Messsignal
Eintrag:
...
- [ ] Kann das Team das Outcome mit Produktentscheidungen beeinflussen?
## Opportunities: Kundenbedürfnisse strukturieren
Erwartetes Artefakt: Kundenbezogene Opportunities mit Belegen
Bedürfnis oder Hindernis · Quelle · offene Frage
Eintrag:
...
- [ ] Ist jede Opportunity aus Kundenwissen hergeleitet?
- [ ] Enthält sie noch eine Lösung in Verkleidung?
## Fokus: Eine Ziel-Opportunity auswählen
Erwartetes Artefakt: Gewählte Ziel-Opportunity mit Begründung
Opportunity · Evidenz · Begründung
Eintrag:
...
- [ ] Ist die Opportunity relevant und ausreichend verstanden, um Ideen zu entwickeln?
## Lösungen: Mehrere Lösungswege erkunden
Erwartetes Artefakt: Lösungsoptionen mit Annahmen
Option · adressierte Opportunity · wichtigste Annahme
Eintrag:
...
- [ ] Gibt es verschiedene Wege, die Opportunity zu bedienen?
## Lernen: Annahmen testen und Baum aktualisieren
Erwartetes Artefakt: Aktualisierter Baum mit Tests und Entscheidungen
Annahme · Test · Evidenz · Entscheidung
Eintrag:
...
- [ ] Prüft der Test eine wichtige Annahme der Lösung?
- [ ] Ist die nächste Entscheidung vor dem Test benannt?
## Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/opportunity-solution-tree/run-sheet
Checkliste für kritische Annahmen nach Risiko und Wissensstand.
- [ ] Annahme als überprüfbare Aussage formuliert
- [ ] Risiko bewertet
- [ ] Wissensstand bewertet
- [ ] Datenquelle oder Testidee ergänzt
- [ ] Riskiest Assumption markiert
- [ ] Erfolgskriterium definiert
- [ ] Owner und Datum gesetztKurzer Plan für Hypothese, Testdesign, Erfolgskriterium und Entscheidung.
# Experiment Plan
## Hypothese
Wir glauben, dass ...
## Zielgruppe
Für wen testen wir?
## Testdesign
Was machen Teilnehmende oder Nutzende konkret?
## Erfolgskriterium
Wir werten den Test als positiv, wenn ...
## Risiken und Grenzen
Was kann der Test nicht beweisen?
## Entscheidung danach
Wenn positiv: ...
Wenn negativ: ...
## Owner und Datum
...