Wer ein Produkt entwickelt oder ein Startup gründet, der trifft Annahmen. Und das ständig. Zum Beispiel Annahmen über die Nutzer oder Kunden: wer sie sind, wie viele sie sind, wie alt sie sind, was für ein Problem sie haben, dass sie ein Problem haben oder darüber wie man dieses Problem lösen könnte.
Man könnte es mit einer Webseite oder einer App lösen. Oder einfach mit einem Kaffeesirup, der automatisch ne Katze auf den Kaffee zaubert. (siehe Bild) Vorausgesetzt natürlich es gibt Leute, die das Problem haben, dass ihr Kaffee immer so langweilig aussieht, sie Kaffee gerne mit Sirup trinken und Katzen ihre Lieblingstiere sind. Ihr seht wohin uns das führt: in den Wald.
Die meisten dieser Annahmen sind übrigens gut und harmlos und helfen uns dabei, die komplizierte Wirklichkeit zu abstrahieren. Einfach “damit man mal weiterkommt und das jetzt nicht nochmal diskutieren muss”.
Aber es gibt auch weniger harmlose Vertreter: oft werden Annahmen unbemerkt zu Wahrheiten im Unternehmen. Ganz langsam und schleichend und plötzlich weiß keiner mehr, dass dieser Glaubenssatz eigentlich nur mal “so eine Annahme war”. Und plötzlich basiert die komplette Quartalsplanung auf einer einzigen Annahme. Upssss….. das ist gefährlich.
Was tun? Gefahr erkannt, Gefahr gebannt!
Mit einer einfachen Methode lassen Annahmen sich klar also solche ausweisen und auf ihr Risikopotenzial untersuchen. Diese Methode will ich hier kurz skizzieren.
Gefunden habe ich sie in einem Video von Laura Klein zum Thema “Identify and Validate Your Riskiest Assumptions”. Das Video lohnt sicher einen Blick. Aber natürlich erst nachdem du diesen Artikel gelesen hast :-)
Schritt 1: Annahmen notieren
Der erste Schritt ist denkbar einfach: man notiert einfach alle Annahmen, die in einem Unternehmen oder zu einem bestimmten Produkt gerade herumschwirren. Das sind in der Regel ziemlich viele. Davon darf man sich nicht abschrecken lassen. Post-it´s oder Karteikarten funktionieren für diesen Schritt richtig gut, denn analog wird einem die Menge an Annahmen erst richtig bewusst.
Man findet die Annahmen übrigens, indem man z.B. mit den Kollegen einmal über das Produkt, Projekt, die aktuelle Ausrichtung etc. spricht. Dabei gilt es sehr aufmerksam und kritisch zuzuhören: Was ist Fakt und belegbar und von welchen Sachen denken die Kollegen nur, dass sie Fakt sind? Das sind dann die Annahmen.
Um in unserem Beispiel mit dem Katzendekor auf dem Kaffee zu bleiben:
- Annahme: Es gibt Menschen, die ihren Kaffee optisch gerne aufwerten würden.
- Annahme: Es gibt Menschen, die nur dann glücklich mit ihrer Kaffeedeko sind, wenn auf dem Kaffeeschaum eine Katze abgebildet ist.
- Annahme: Es gibt von der beschriebenen Gattung ausreichend Menschen um mit Katzen-Kaffee-Sirup-Dekor ein Geschäft zu machen.
Schritt 2: Annahmen clustern
Liegen alle Annahmen auf dem Tisch geht es um eine Einordnung:

Es gibt drei Arten von Annahmen: Problem, Lösung, Implementierung
- Welche Annahmen behandeln die Nutzergruppe und ihr eigentliches, natürliches und ursprüngliches Problem? Die wichtige Frage hier ist: gibt es überhaupt ein Problem? Vieles was man z.B. in Personas findet fällt in diese Kategorie.
- Welche Annahmen beschreiben eine Lösung für eines der angenommenen Probleme? In diese Kategorie fallen harmlos erscheinende Entscheidungen wie die, dass “für diese Zielgruppe eine App genau das richtige ist”. Hier ist die wichtige Frage: Ist das die richtige und einzige Lösung für das Problem?
- Und welche Annahmen behandeln die eigentliche Implementierung? Hier ist die zentrale Frage: können wir das bauen/herstellen und verkaufen ehe wir pleite sind? Mit etwas Übung geht dieser Schritt ganz schnell. Sofern man papierbasiert arbeitet notiert man einfach ein P, L oder I auf der jeweiligen Karte und legt die selbige auf einen von drei Stapeln. Wer lieber digital Arbeitet kann natürlich auch hinter den Annahmen eine neue Spalte mit einer Kennung einführen.
Schritt 3: Annahmen einschätzen
Jetzt kommt der Teil, den man besser nicht alleine sondern in Gesellschaft macht. Es geht nun darum die Annahmen einzuschätzen und sie in ein Koordinatensystem einzuordnen. Man sortiert jede der Karten/Annahmen in zwei Gruppen ein:
- Wenn die auf der Karte notierte Annahme wahr ist, dann ist das:
- tödlich für das Unternehmen/Produkt.
- verheerend für das Unternehmen/Produkt.
- etwas nervig.
- eigentlich toll.
- Dass diese Annahme wahr ist, ist:
- wahrscheinlich.
- unwahrscheinlich.
Wer mit Papier arbeitet kann an einer Wand oder dem Fußboden folgendes Koordinatensystem anzeichnen. Die Karten werden dann einzeln vorgestellt und in kleiner Runde wird beschlossen wo im System diese Annahme einzuordnen ist.

Wenn diese Annahme wahr ist, ist das… und Dass diese Annahme wahr ist, ist…
Dabei haben sich Gruppen von 4–7 Leuten bewährt. Idealerweise entstammen die Teilnehmer unterschiedlichen Abteilungen/Disziplinen und es sind Teilnehmer aus den Abteilungen mit viel Kundenkontakt (Sales, Customer Care) mit am Tisch. Auch Teilnehmer aus dem Management haben sich als sehr hilfreich erwiesen. Sie haben oft nochmal einen ganz anderen Blick auf die Dinge.
Ist die Einordnung erfolgt gilt es die weiteren Schritte zu planen. Alle Karten, die im grauen Bereich des Koordinatensystems liegen bleiben im Spiel. Alle anderen Karten “scheiden aus”.
Für die Karten in den Bereichen a-c stehen jetzt unterschiedliche Sachen auf dem Programm:
a. Karten im a-Bereich müssen unbedingt ernst genommen und untersucht werden. Hier braucht es einen sicheren Beweis, dass keine Schlussfolgerung in der Produktentwicklung sich auf diese Annahmen stützen. Das wäre fatal!
b. Für Karten im b-Bereich gilt: es muss ausreichend Evidenz gefunden werden um sicherzustellen, dass es wirklich unwahrscheinlich ist, dass die Annahmen wahr sind.
c. Für Karten in c-Bereich gilt: Wenn eine Aussage wahr ist und das einen nervt gibt es vielleicht eine Möglichkeit zu beeinflussen wie nervig es wird? Hier gibt es also vielleicht eine Art Plan-B. Mit dieser erneuten Betrachtung scheiden aber auch diese Karten aus dem Spiel aus. Genug um diese Annahmen gekümmert.
Die Hypothese
Für alle Annahmen in Bereich a und b gilt es nun Problem-, Lösungs- und Implementierungs-Hypothesen zu finden und diese zu testen.
Die Art des Tests bestimmt die Kategorie der Annahme:
- “Problem Assumptions” werden z.B. mit einem Fakedoor-Test validiert
- “Solution Assumptions” kann man mit einem klickbaren Prototyp belegen. Bei bestehenden Produkten können natürlich auch einfach Nutzer und Kunden in großer Zahl befragt (Surveys) oder A/B-Tests gefahren werden.
- und “Implementation Assumptions” lassen sich überprüfen in dem das Entwicklungsteam vielleicht die technische Machbarkeit mit einem “proof of concept belegt.
Wie ausführlich diese Tests ausfallen sollten hängt wie gesagt von der abc-Verortung der Annahme ab. Die Frage sollte sein: brauchen wir einen echten Beweis oder reichen uns Anhaltspunkte für die Richtigkeit unserer Annahmen? (Proof vs. Evidenz)
- Evidenzen bekommt man leicht durch Guerilla-Interviews: man geht in ein Café, spricht einfach Leute an und interviewet sie zu dem jeweiligen Thema.
- Geht es darum mehr Sicherheit zu erlangen sind die gängigen Leans-Startup Testmethoden eine gute Wahl.
Zum Testen von Hypothesen könnte man selbstverständlich auch einen halben Roman schreiben. Aber das haben schon genug Leute an anderer Stellen gemacht. Hier eine kleine Übersicht:
- Hypothesen-getriebenes Unternehmertum (DE)
- Lean Experiment Techniques (EN)
- Experiment examples to get you started to test your idea (EN)
Was tun mit den Erkenntnissen?
Ok. Also. Wir hatten Annahmen, haben sie geclustert und bewertet, Hypothesen gebildet, diese getestet und wissen jetzt welche Annahmen zutreffen (Proof) oder sehr wahrscheinlich zutreffen (Evidenz).

Einige Annahmen haben den Prozess nicht überlebt…
Damit lässt sich jetzt doch prima arbeiten! Nur wie hält man die Erkenntnisse sinnvoll fest?
Hier kommen die ganz normalen Methoden des Produktmanagements zum Tragen. Alles was wir über die Nutzer und deren Problem gelernt haben stellen wir z.B. in Personas und Storymaps zusammen. Und der Prototyp, den wir für die Validierung der “Solution Assumptions” gebaut haben kann einfach aufgrund der gewonnenen Erkenntnisse angepasst und dann weiter verwendet werden.
Zusammenfassung
Annahmen sind gefährlich, wenn aus ihnen unbemerkt Firmen-Glaubenssätze werden. Daher sollte man sie notieren und klar als Annahmen kennzeichnen. Clustert man sie nach “Gefährlichkeit” und “Wahrscheinlichkeit” lässt sich bestimmen wie man mit den Annahmen am besten umgeht: gar kein Produkt bauen? Ein Produkt bauen aber anders als ursprünglich geplant? Eine günstigere Lösung für die Implementierung suchen? Alles valide Punkte und mögliche Findings.
Wichtig ist: geht offen an die Sache ran. Vielleicht findet ihr unbequeme Wahrheiten. Aber sie bewahren euch vor größerem Schaden. Denn nichts ist schlimmer als ein Produkt zu bauen, nachdem kein Hahn kräht.
Dieser Artikel ist ursprünglich auf medium.com erschienen.
Danke für den interessanten Artikel.
Mich hat das sehr an das Annahmen Board
http://collaborative-ux-design.com/scoping/annahmen-map
erinnert.
Für mich persönlich etwas einfacher zu erfassen und anzuwenden — vom Prinzip und der Zielsetzung her aber sehr ähnlich.
In jedem Fall ist es eine sehr gute Idee, Annahmen als solche zu identifizieren und das transparent für Alle zu machen.
Sebastian! Danke für deinen Kommentar. Kannte ich noch gar nicht, dass andere Framework…. da lese ich mich gleich mal rein. Liebe Dienstagsgrüße, Petra
Hi Petra,
ich habe deinen Beitrag und die schöne Strukturierung von Annahmen vor der Entwicklung eines neuen Produkts oder der Gründung eines Startups, mit großem Interesse gelesen und dachte im ersten Moment: Ja, genau richtig!
Dann habe ich Deine Vorschläge zur Überprüfung von grundlegenden Annahmen gelesen (Fake Door/ A/B-Testing) und dabei etwas gestutzt.
Dies sollte ja wahrscheinlich kein Research-Beitrag sein aber mir schien es doch sinnvoll auf Folgendes hinzuweisen:
Diese Research-Methoden haben nur für relativ kleine (Gestaltungs-) Fragestellungen Aussagekraft und kommen daher gerade im Rahmen der “Problem Assumptions” nicht so richtig in Betracht. Dafür greifen sie einfach zu kurz. Sie können einem Team aufgrund ihrer methodischen Einschränkungen nicht in dem erforderlichen Umfang darüber aufklären, ob ihre Annahmen (in Bezug auf das neue Produkts oder das neue Startup) richtig oder falsch sind. Zudem kann die Datenerhebung und Auswertung hierbei recht aufwändig werden, wenn man nicht bereits über das technische Setup verfügt.
Hier würde ich immer einen einfachen, schlichten explorativen Konzept-Test mit halbstrukturierten Interviews und den relevanten Zielgruppen vorziehen, um die Annahmen aus unterschiedlichen Kunden-Perspektiven, zu beleuchten und zu hinterfragen.
Später mögen dann andere Methoden helfen, Detailfragen und darauf aufbauende Annahmen zu untersuchen.
Herzliche Grüße und Danke noch mal für Deine Anregungen
Olde
Moin Olde,
mit deiner Anmerkung hast du total recht. Die genannten Methoden sind nicht ausreichend um alle offenen Fragen zu klären. Sie sind in der Tat immer nur für kleine Teilaspekte hilfreich. Um das aber nuanciert im Artikel wiederzugeben hätte ich aber einen ganz schönen Umweg nehmen müssen. Darauf habe ich verzichtet und freue mich umso mehr, dass diese Diskussion hier entsteht und das noch etwas unterfüttert.
LG, Petra
Im Prinzip sind das Schritte, die man auch in der qualitativen Sozialforschung geht. Dort und in diesem Fall geht es darum, sich die eigenen Annahmen bewusst zu machen um sie dann aus einem neuen Blickwinkel zu betrachten. Also die Explikation von implizitem Wissen & (Vor)Urteilen.
Ein sehr sinnvolles Verfahren, mit dem sich übrigens in vielen Fällen Klarheit schaffen lässt.
Vielen Dank für Deinen Beitrag. Leider funktioniert der Link “Hypothesen-getriebenes Unternehmertum (DE)” nicht:
https://www.innovationsnotizen.de/lean-startup-hypothesen-getriebenes-unternehmertum/
Ich mag die Idee und werde das mal ausprobieren. Allerdings hab ich ein kleines Verständnisproblem. Du schreibst von den “Bereichen a-c”, die unterschiedlich weiter bearbeitet werden sollen. Welche “Bereiche” sind das denn? Ich vermute, das sind nicht die Quadranten aus dem Diagramm, oder? Sind die Grenzen der Bereiche a-c die Kategorien “Nervig”, “Verheerend” und “Tödlich”? Das macht für mich gerade am meisten Sinn. Liege ich damit richtig?
Oh man, Lydia! Danke, dass du meine QA machst… da habe ich Dösbaddel doch glatt das falsche Bild verwendet. Habe es jetzt oben im Beitrag geändert. Hoffe das hilft? Du warst aber auf der richtigen Spur. Ganz LG :-) Petra