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:

Es gibt drei Arten von Annahmen: Problem, Lösung, Implementierung

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:

  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.

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:

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.

Über Petra Wille

Petra Wille ist seit 2013 als freiberufliche Produktmanagerin tätig und arbeitet für Ihre Kunden an neuen Produktideen: immer mit agilen Projektmethoden und meist in internationalen, auch verteilten Entwicklungsteams. Außerdem berät und coacht sie Produktmanager und vermittelt Methoden und Handwerkszeug für ein professionelles, dynamisches Produktmanagement. Neben Ihrer freiberuflichen Tätigkeit ist Petra Wille begeisterte Kitesurferin, schreibt für produktbezogen.de und organisiert die größte, deutsche Produktkonferenz MTP Engage.

5 Kommentare

  1. Sebastian Feige

    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.


  2. Petra Wille Artikelautor

    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


  3. Olde Lorenzen-Schmidt

    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


  4. Petra Wille Artikelautor

    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


  5. Stefanie

    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.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →