Gefährliche Annahmen – wie ihr das Risiko minimiert, falsch zu liegen

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:

• 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:

1. 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.
2. 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.

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).

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.