Assumption Mapping: Kritische Annahmen identifizieren

Die Methode wurde von Jeff Gothelf und Josh Seiden im Kontext von Lean UX entwickelt und später von David Bland (Precoil) und anderen weiter popularisiert. Sie ist heute Standard in Product Discovery und wird von Startups bis Fortune-500-Unternehmen eingesetzt. Der Grund: Teams, die ihre Annahmen früh validieren, vermeiden bis zu 60% der typischen Produktfehler (Strategyzer 2024).

Warum Annahmen gefährlich sind

Annahmen fühlen sich an wie Wissen – aber sie sind es nicht. Der Unterschied: Wissen basiert auf Evidenz, Annahmen auf Vermutungen. In der Hitze der Produktentwicklung wird dieser Unterschied leicht übersehen.

Das Problem: Teams behandeln Annahmen oft wie Fakten. „Natürlich wollen Nutzer dieses Feature" – aber hat jemand gefragt? „Natürlich können wir das bauen" – aber hat jemand die Komplexität analysiert?

Ich habe ein Startup erlebt, das 8 Monate an einem Produkt baute, dessen Kernannahme („Restaurants wollen ihre Lieferlogistik optimieren") falsch war. Eine zweistündige Assumption-Mapping-Session hätte das Problem am Tag 1 identifiziert. Stattdessen kostete es ein Jahr und sechsstellige Beträge.

Die drei Annahme-Kategorien

Assumption Mapping unterscheidet drei fundamentale Kategorien – inspiriert von Design Thinking und Lean Startup.

Desirability: Wollen Nutzer das?

Annahmen über Nutzerbedürfnisse, Probleme und Präferenzen.

• Haben Nutzer wirklich dieses Problem?
• Ist das Problem schmerzhaft genug, um eine Lösung zu suchen?
• Würden Nutzer diese Lösung unserer Konkurrenz vorziehen?
• Verstehen Nutzer den Wert unserer Lösung?

Viability: Funktioniert das Geschäftsmodell?

Annahmen über Wirtschaftlichkeit und nachhaltiges Business.

• Werden Nutzer dafür bezahlen?
• Ist der Preis richtig?
• Sind die Akquisitionskosten tragbar?
• Ist das Geschäftsmodell langfristig profitabel?

Feasibility: Können wir das bauen?

Annahmen über technische und organisatorische Machbarkeit.

• Haben wir die technischen Fähigkeiten?
• Ist das in unserem Zeitrahmen machbar?
• Haben wir die notwendigen Ressourcen?
• Gibt es rechtliche oder regulatorische Hürden?

Die 2x2-Matrix: Annahmen priorisieren

Nicht alle Annahmen sind gleich wichtig. Die 2x2-Matrix hilft zu priorisieren: Was muss zuerst validiert werden?

    Hoch │                          │
 Risiko  │    TESTEN!               │   Beobachten
(Wichtig)│    (wichtig, wenig       │   (wichtig, viel
         │     Evidenz)             │    Evidenz)
         │────────────────────────────────────────────
         │    Erforschen            │   Zurückstellen
  Gering │    (unwichtig, wenig     │   (unwichtig, viel
         │     Evidenz)             │    Evidenz)
         └────────────────────────────────────────────
                 Wenig                      Viel
                        Evidenz

Quadrant 1: Testen! (oben links)

Hohe Wichtigkeit, wenig Evidenz. Diese Annahmen sind gefährlich – wenn sie falsch sind, scheitert das Projekt. Und wir wissen nicht, ob sie stimmen.

→ Sofort validieren mit Experimenten, Interviews, Prototypen.

Quadrant 2: Beobachten (oben rechts)

Hohe Wichtigkeit, viel Evidenz. Diese Annahmen sind wichtig, aber wir haben bereits Daten dafür.

→ Weiter beobachten, aber nicht priorisieren.

Quadrant 3: Erforschen (unten links)

Geringe Wichtigkeit, wenig Evidenz. Interessant, aber nicht kritisch.

→ Bei Gelegenheit validieren, nicht priorisieren.

Quadrant 4: Zurückstellen (unten rechts)

Geringe Wichtigkeit, viel Evidenz. Weder kritisch noch unsicher.

→ Ignorieren – andere Dinge sind wichtiger.

Workshop-Ablauf: 90 Minuten zur Klarheit

Vorbereitung

• Teilnehmer: Cross-funktionales Team (Product, Design, Engineering, Business)
• Material: Post-its, Stifte, große Wandfläche oder Miro-Board
• Kontext: Produktidee, Feature oder Initiative, die analysiert werden soll

Phase 1: Annahmen sammeln (25 Minuten)

Jeder Teilnehmer schreibt Annahmen auf Post-its – eine pro Zettel. Die Kategorien helfen:

• Desirability: „Wir nehmen an, dass Nutzer..."
• Viability: „Wir nehmen an, dass das Geschäft..."
• Feasibility: „Wir nehmen an, dass wir..."

Format: „Wir nehmen an, dass [Subjekt] [Verhalten/Eigenschaft] [Kontext]."

Beispiele:

• „Wir nehmen an, dass Freelancer bereit sind, 15 €/Monat für Zeiterfassung zu zahlen."
• „Wir nehmen an, dass wir die App in 4 Sprachen lokalisieren können."
• „Wir nehmen an, dass Nutzer die Onboarding-Tour abschließen."

Tipps:

• Quantität zählt – lieber zu viele als zu wenige
• Auch „offensichtliche" Annahmen aufschreiben
• Keine Diskussion während des Schreibens

Phase 2: Annahmen teilen (15 Minuten)

Jeder stellt seine Annahmen kurz vor und klebt sie an die Wand. Ähnliche Annahmen werden gruppiert. Keine Bewertung, nur Verständnisfragen.

Phase 3: Auf der Matrix platzieren (20 Minuten)

Gemeinsam wird jede Annahme auf der 2x2-Matrix platziert.

Für jede Annahme:

Wie wichtig ist diese Annahme? (Wenn sie falsch ist – wie schlimm wäre das?)

Wie viel Evidenz haben wir? (Daten, Forschung, oder nur Vermutung?)

Diskussion ist erlaubt, aber timeboxed. Bei Uneinigkeit: höheres Risiko annehmen (konservativ).

Phase 4: Top-Annahmen identifizieren (10 Minuten)

Die Annahmen im „Testen!"-Quadranten werden priorisiert. Was sind die 3–5 kritischsten Annahmen, die wir zuerst validieren müssen?

Phase 5: Validierungs-Experimente planen (20 Minuten)

Für jede Top-Annahme: Wie können wir sie testen?

• Welches Experiment oder welche Forschung?
• Was wäre ein positives/negatives Signal?
• Wer ist verantwortlich?
• Bis wann?

Annahmen validieren: Methoden

Nicht jede Annahme braucht ein aufwändiges Experiment. Die Methode sollte zur Annahme passen.

Schnelle Validierung (Tage)

• Desk Research: Gibt es bereits Studien oder Daten?
• Interviews: 5–10 Gespräche mit potenziellen Nutzern
• Landing Page: Traffic auf eine Beschreibung leiten und Interesse messen
• Fake Door Test: Feature ankündigen und Klicks messen

Mittlere Validierung (Wochen)

• Umfragen: Quantitative Daten von größerer Stichprobe
• Prototype Testing: Interaktiver Prototyp mit Nutzern testen
• Concierge MVP: Service manuell anbieten, bevor man ihn baut
• Wizard of Oz: Automatisierung vortäuschen, manuell ausführen

Tiefe Validierung (Monate)

• Pilot/Beta: Echtes Produkt mit begrenzter Nutzergruppe
• A/B-Tests: Varianten vergleichen mit statistischer Signifikanz
• Markttest: In einem Markt launchen, bevor man skaliert

Typische Annahmen nach Kontext

B2B SaaS

• „Entscheider haben Budget für dieses Problem"
• „Der Kaufzyklus ist kürzer als 6 Monate"
• „Nutzer können das Tool ohne Training bedienen"
• „IT-Abteilung wird die Integration genehmigen"

Consumer App

• „Nutzer öffnen die App mindestens 3x pro Woche"
• „Nutzer teilen Inhalte mit Freunden"
• „Die Akquisitionskosten sind unter 5 €"
• „Nutzer upgraden von Free auf Paid"

Marketplace

• „Anbieter sind bereit, Provision zu zahlen"
• „Wir können genug Nachfrage generieren, bevor Anbieter abspringen"
• „Die Qualität der Anbieter ist kontrollierbar"
• „Transaktionen laufen über unsere Plattform (keine Umgehung)"

Häufige Fehler bei Assumption Mapping

Fehler 1: Nur offensichtliche Annahmen sammeln

Problem: Die wichtigsten Annahmen sind oft die, die niemand ausspricht – weil sie „selbstverständlich" scheinen.

Lösung: Explizit nach „Was nehmen wir als gegeben an?" fragen. Auch trivial erscheinende Annahmen aufschreiben.

Fehler 2: Alles ist „hoch wichtig"

Problem: Teams tendieren dazu, alles als kritisch einzustufen.

Lösung: Forced Ranking: Wenn nur 3 Annahmen im „Testen!"-Quadranten sein dürfen – welche? Priorisierung erzwingen.

Fehler 3: Keine echte Validierung

Problem: Annahmen werden „getestet", indem man Kollegen fragt oder seine eigene Meinung bestätigt.

Lösung: Echte Evidenz definieren: Was würde uns überzeugen, dass die Annahme falsch ist? Dann nach dieser Evidenz suchen.

Fehler 4: Einmal mappen, nie wiederholen

Problem: Assumption Mapping wird einmal gemacht und dann vergessen.

Lösung: Regelmäßig revisiten – neue Erkenntnisse ändern die Matrix. Besonders nach jeder Validierungsrunde.

Remote Assumption Mapping

Die Methode funktioniert hervorragend remote – mit digitalen Whiteboards.

Setup in Miro/Mural

Annahmen-Bereich: Post-it-Bereiche für Desirability, Viability, Feasibility

2x2-Matrix: Vorbereitet mit klaren Quadranten

Priorisierungs-Bereich: Für Top-Annahmen und Action Items

Anpassungen für Remote

• Mehr Zeit für stilles Schreiben (weniger Ablenkung)
• Voting-Funktion für Priorisierung nutzen
• Breakout-Rooms für paralleles Mapping bei großen Gruppen
• Ergebnis als teilbares Artefakt dokumentieren

Assumption Mapping in agilen Kontexten

Vor dem Sprint

Assumption Mapping eignet sich hervorragend, bevor ein neues Feature in die Entwicklung geht. Die Frage: „Welche Annahmen machen wir, und wie sicher sind wir?"

Im Dual-Track Agile

Discovery Track: Annahmen identifizieren und validieren. Delivery Track: Nur Features bauen, deren kritische Annahmen validiert sind.

Als Teil von Design Sprints

Tag 1 eines Design Sprints beinhaltet oft implizites Assumption Mapping. Es kann explizit gemacht werden, um den Fokus für den Sprint zu schärfen.

Fallbeispiel: E-Commerce-Feature

Situation: Ein Online-Shop will eine „Wunschlisten"-Funktion einführen.

Annahmen gesammelt:

• „Nutzer wollen Produkte für später speichern" (Desirability)
• „Wunschlisten erhöhen die Conversion" (Viability)
• „Nutzer teilen Wunschlisten mit Freunden" (Desirability)
• „Wir können Wunschlisten in 4 Wochen bauen" (Feasibility)
• „Wunschlisten-Nutzer kaufen mehr als andere" (Viability)

Auf der Matrix:

• Testen!: „Wunschlisten erhöhen die Conversion" (wichtig, wenig Evidenz)
• Testen!: „Nutzer teilen Wunschlisten" (wichtig, wenig Evidenz)
• Beobachten: „Nutzer wollen speichern" (wichtig, viel Evidenz aus anderen Shops)
• Erforschen: „4 Wochen Aufwand" (mittel wichtig, wenig Evidenz)

Validierung:

• Fake Door Test: „Wunschliste teilen"-Button zeigen, Klicks messen
• User Interviews: Nach aktuellem Speicher-Verhalten fragen
• Technischer Spike: Aufwand genauer schätzen

Ergebnis: Die Annahme „Nutzer teilen Wunschlisten" wurde widerlegt – kaum jemand klickte auf „Teilen". Das Team baute die Wunschliste ohne Social-Feature und sparte 2 Wochen Entwicklung.

Fazit: Wissen, was wir nicht wissen

Assumption Mapping ist keine Garantie gegen Fehlschläge – aber es reduziert die Wahrscheinlichkeit dramatisch. Die Methode zwingt Teams, ehrlich zu sein: Was wissen wir wirklich? Was nehmen wir nur an?

Die mächtigste Frage des Workshops: „Was müsste falsch sein, damit dieses Projekt scheitert?" Die Antworten auf diese Frage sind die Annahmen, die zuerst validiert werden müssen.

Für Produktteams, die Build-Measure-Learn ernst nehmen, ist Assumption Mapping der erste Schritt. Nicht bauen, was wir für richtig halten – sondern validieren, ob es stimmt. Das kostet Zeit am Anfang, spart aber Monate am Ende.

---

Wie viele Annahmen sind typisch für ein Projekt?

15–30 Annahmen sind normal für eine Produktidee. Davon landen typischerweise 3–5 im „Testen!"-Quadranten. Mehr als 50 Annahmen deuten darauf hin, dass das Thema zu breit ist.

Wann sollte ich Assumption Mapping machen?

Idealerweise früh – bevor signifikante Ressourcen investiert werden. Bei neuen Produkten: vor dem Baubeginn. Bei Features: vor der Sprint-Planung. Bei Pivots: bei der Neuausrichtung.

Wer sollte teilnehmen?

Ein cross-funktionales Team: Product, Design, Engineering, Business. Je diverser, desto mehr blinde Flecken werden aufgedeckt. 4–8 Personen sind ideal.

Was, wenn alle Annahmen „hoch wichtig" sind?

Forced Ranking hilft: Wenn du nur 3 Annahmen testen könntest, welche? Die Priorisierung zwingt zur Ehrlichkeit. Außerdem: Nicht jede Annahme ist wirklich existenziell – kritisch hinterfragen.

Wie unterscheidet sich Assumption Mapping von einer Risikoanalyse?

Risikoanalyse fokussiert auf Bedrohungen und deren Wahrscheinlichkeit. Assumption Mapping fokussiert auf unbewiesene Annahmen und deren Kritikalität. Es gibt Überlappungen, aber der Fokus ist anders: Risiken sind bekannte Gefahren, Annahmen sind unbekannte Unbekannte.

---

Stand: Dezember 2025

Quellen: Jeff Gothelf & Josh Seiden – Lean UX David Bland & Alex Osterwalder – Testing Business Ideas Strategyzer – Assumption Mapping Research Maze – Assumption Mapping in Product Development 2025