Die meisten Produktteams kennen ihre impliziten Annahmen nicht, diskutieren sie nicht oder verfolgen sie nicht. Das können Annahmen über den Markt, die Bedürfnisse des Benutzers oder die Technologie sein. Dies schafft ein großes und verborgenes Problem für viele Teams: Die Arbeit auf der Grundlage von unausgesprochenen Hauptannahmen stellt ein großes Risiko für das Produkt dar. Was ist, wenn sich eine Annahme als falsch erweist? Das könnte die gesamte Produktidee zum Scheitern bringen! Dank des Dunning-Kruger-Effekts würde ich sogar sagen, dass ein Team umso mehr Vertrauen in ein großartiges Produkt hat, je weniger es über seine Annahmen weiß.
Unsere Lösung dafür besteht darin, die Annahmen auf die gleiche Weise zu behandeln wie die Aufgaben. Wir nutzen dies, um kritisch zu untersuchen, warum und wie wir unsere Produkte bauen. Annahmen sind nicht dazu da, um validiert zu werden, wie viele Leute es ausdrücken, sondern um getestet zu werden! Das Testen einer Annahme sollte mit dem Versuch beginnen, sie als falsch zu beweisen, nicht mit dem Versuch, sie als richtig zu beweisen. Es ist immer leicht, Gründe für etwas zu finden - aber wird es einem Advocatus Diaboli standhalten, der versucht, es zu demontieren?
Dieser Prozess mag schwerfällig, intellektuell herausfordernd und arbeitsintensiv klingen. Und das ist wahr, es ist all das. Aber ich denke, das sind gute Neuigkeiten: Wenn es schwer ist, wird Ihre Konkurrenz es wahrscheinlich nicht schaffen! Und auch wenn es schwer ist, wird es am Ende Zeit und Geld sparen, das andere Teams verschwenden, indem sie die falschen Features auf die falsche Art und Weise bauen. Fangen wir also an: Was ist ein Assumption Board und wie können Sie es in Ihren Prozess integrieren?
Das Assumption Board
Dieses Board funktioniert genau wie das Sprint- oder Entwicklungsboard, das Sie von SCRUM oder KanBan kennen. Es ist ein Board mit Tickets, die sich durch mehrere Stufen bewegen, die die zu erledigende Arbeit verfolgen. Hier sind die Etappen:
Annahmen (Backlog)
Wie ein Rückstand ist dies der Posteingang, der Beginn der Reise jeder Annahme. Wenn ein Projekt gestartet wird, sollte dieser in einem Workshop mit dem Produktteam und den Interessenvertretern aufgefüllt werden. Eine Annahme hat die Form "Wir gehen davon aus, dass ...", z.B. "Wir gehen davon aus, dass die Benutzer von der Menge der Funktionen in der App des Konkurrenten A überwältigt sind".
Fragen (ToDo, Sprint Backlog)
Aus einer Annahme müssen wir eine Frage ableiten, die es uns erlaubt, diese Annahme zu testen. Die Formulierung der Frage ist entscheidend, denn sie wird bestimmen, welche Art von Antworten wir erhalten. Die Frage sollte die Annahme prüfen, sie aber nicht in irgendeine Richtung lenken. Wenn Sie sich zu sehr mit diesem Thema beschäftigen, kann es vielleicht helfen, einen Kollegen oder eine Kollegin zu bitten, eine kritische, neutrale Frage zu formulieren. Ein Beispiel kann lauten: "Mehr als 90% der Merkmale in Produkt A von Wettbewerber B werden nie verwendet". Eine Frage stellt direkt eine Aufgabe für einen UX Designer oder Reseacher dar (oder einfach für jede Person, der diese Frage am Herzen liegt), die durch das Ausdenken von Wegen zur Beantwortung dieser Frage angegangen werden kann.
Researching (Doing)
Der Prozess der Erforschung einer Frage beinhaltet zunächst die Erstellung eines Experiments zur Datenerhebung. Je nach Fragestellung kann das ein Schatten der Benutzer, kontextbezogene Untersuchungen, Interviews, Umfragen, Statistiken, Usability-Tests oder viele andere gängige UX-Methoden sein. Dieser Schritt umfasst die Planung und Durchführung des Experiments sowie die Analyse der gesammelten Daten und das Ziehen von Schlussfolgerungen in Bezug auf die Frage. Der gesamte Prozess und die Struktur sollte in dem jeweiligen Ticket nachvollzogen werden, um ihn für jeden Gutachter transparent zu machen.
Review
Jedes gute wissenschaftliche Experiment wird überprüft, und nur eine überprüfte und kritisch geprüfte Schlussfolgerung ist als Entscheidungsgrundlage sicher. Daher sollte sich ein Kollege in diesem Schritt den gesamten Prozess, die Methoden, Daten und Schlussfolgerungen ansehen. Wenn weitere Daten gesammelt werden müssen, um die Bedenken eines Gutachters auszuräumen, so sei es so.
Bereit (Done)
Sobald die Recherche durchgeführt und überprüft wurde, ist das Ticket bereit, weiterzumachen. Es gibt zwei Wege, die es beschreiten kann: Fragen, die den Kern des Produkts berühren, werden zu strategischen Ressourcen. Sie werden entweder zur Dokumentation in dieser Tafel aufbewahrt oder in ein internes Wiki oder eine andere Form der strategischen Dokumentation verschoben. Es ist wichtig, einen sichtbaren Platz dafür zu finden, da dieses Wissen als Leitfaden für zukünftige Entscheidungen genutzt werden sollte.
Fragen, die konkretere Fragen zum Produkt stellen, werden zu Feature-Ideen und wandern in den Entwicklungsrückstand. Dort muss der Produkteigentümer eventuell mit Designern und Entwicklern Rücksprache halten, um eine Vorstellung davon zu bekommen, wie hoch der Implementierungsaufwand wäre, und mit dem Forscher klären, wie hoch der Nutzen für den Benutzer wäre. Mit diesen Informationen kann der Produkteigentümer dann die Funktion innerhalb des Entwicklungsrückstands priorisieren, wo sie sich jetzt befindet. Es ist vorteilhaft, dieses Ticket aufzubewahren und weiter zu verschieben, so dass jeder, der es in Zukunft anfasst, auf alle Forschungsdaten, Methoden und Schlussfolgerungen zugreifen kann.
Ergebnis
Sobald dieser Ansatz vollständig in den Entwicklungsprozess integriert ist - alle Feature-Ideen durchlaufen das Assumption Board, bevor sie in einen Entwicklungssprint eingeplant werden - hat er die Kraft, nicht nur den Entwicklungsprozess, sondern auch das gesamte Produkt neu auszurichten. Es ist die faktenbasierte Art und Weise, Produkte zu entwickeln, die nicht auf Ratespiele und pures Glück angewiesen ist, um die richtige Lösung zu finden.
.svg)
.svg){kind=small}