Inception Deck

 

Software is one of those unique activities that combines design, construction, art, and science all rolled up into one. Teams face thousands of decisions and trade-offs every day. And without the right context or big-picture understanding, it’s impossible for them to make the right trade-offs in an informed or balanced way.

Jonathan Rasmusson, The Agile Samurai

Insbesondere beim Start eines neuen Produkts ist die Volatilität und Unsicherheit extrem hoch; dennoch ist es erforderlich, ein gemeinsames Verständnis zum Produkt zu erringen, um einen gemeinsamen Absprungpunkt zu finden. Hier hilft das Inception Deck.

Nutzen des Inception Deck: Erwartungs-Management-Tool

Häufig ist unseren Auftraggebern der Entwicklungs-Umfang und der dahinterliegende Nutzerbedarf nicht klar. Zu allem Überfluss besteht darüber auch kein gemeinsames Verständnis.  

Das ist eine große Herausforderung für einen Product Owner (PO).

Insbesondere, wenn man nicht aus dieser Organisation stammt. Es gilt also Ruhe zu bewahren und sehr freundlich aber sehr vehement nachzufragen und möglichst früh die Strukturen als auch Motive des Auftraggebers aufzudecken. Stelle Dir Fragen wie:

• Wer möchte das Projekt und warum?
• Wer möchte das Projekt nicht (oder anders) und warum?
• Gibt es vielleicht doch eine Verbindung zwischen den Gründen?

In diesem Spannungsfeld stößt man häufig auf komplementäre oder konkurrierende Ziele.

Wenn zwei dasselbe wollen …

Manchmal wollen Personen zwar dasselbe, haben aber unterschiedliche Feature-Wünsche im Kopf. Oder sie haben unterschiedliche Ziele und versehentlich denselben Feature-Wunsch. In beiden Fällen liegt ein Dissens vor, der erst im fortgeschrittenen Projektverlauf zu Tage tritt. Zumeist dicht gefolgt von einer Krisensitzung, um „endlich mal die Strategie“ zu klären. Demotivation auf allen Seiten inklusive.

Solange der strategische Ausgangspunkt nicht klar ist, schlägt jede operative Umsetzung zwangsläufig fehl! Es wird immer falsch sein oder nur halbrichtig, weil der Abgleich zum Ziel fehlschlägt. 

Das Inception Deck ermöglicht es dem PO, die Erwartungen der Stakeholder auf ein gemeinsames Ziel hin auszurichten und abzugleichen. Es fasst den strategischen Ausgangspunkt zusammen und bietet somit eine gemeinsame Denkplattform. Es ermöglicht einen erfolgreichen Start in die operative Arbeit.

Das Inception Deck lässt sich leicht zusammenfassen und immer wieder als Grundlage hervorziehen. Wenn man das Dokument versioniert, kann man sogar den Verlauf der Produktfindung dokumentieren.

Jetzt aber mal zur Sache! Was ist da drin?

Inception Deck in der Übersicht

Das Inception Deck beinhaltet 10 Punkte, die bearbeitet werden, bevor das Vorhaben in die operative Phase starten kann.

Die Punkte 1 bis 5 beantworten das „Why„, die Punkte 6 bis 10 das „How„.

Punkt 1: Warum sind wir hier?

Hier wird festgehalten, was der Grund für die Entwicklung des Produkts ist. Warum investiert das Unternehmen?

Damit ein Projektteam erfolgreich sein kann, muss es das „Warum“ hinter dem, was es baut, verstehen. Folgende Punkte befähigen Teams:

• Bessere, fundiertere Entscheidungen treffen
• die gegensätzliche Kräfte/Anforderungen und Kompromisse besser auszubalancieren
• Bessere, innovativere Lösungen zu finden, weil sie selbständig denken können

Um die oben beschriebene Situation zu vermeiden, empfehle ich eine Impact Map für das „Warum“. Denn bei einer Impact Map werden Ziele zu einem möglichen Output (Feature) gemappt.

Diese Übung zwingt Sponsoren dazu, sich auf Ziele zu einigen und den Zusammenhang möglicher Features zu diskutieren.

Wenn Du mehr zur Impact Map wissen möchtest: hier zum Nachlesen oder Video gucken auf Youtube.

Im weiteren Verlauf können dann Tools wie Visions- und Missions-Beschreibung als auch User Story Mapping ergänzt werden. Diese sind für das Inception Deck jedoch nicht erforderlich.

Punkt 2: Elevator Pitch erstellen

Der Elevator Pitch fasst alles zusammen, um schnell das Wesentliche des Produkts oder Idee zu vermitteln. Der Elevator Pitch lautet:

• For [target customer]
  → Erklärt, für wen das Projekt ist oder wer von seiner Nutzung profitieren würde. Ergänzend würde ich eine Prototyp-Persona anfügen.
  
• who [statement of need or opportunity]
  → Erläutert das Problem oder Bedürfnis, das der Kunde lösen möchte.
  
• the [product name]
  → Erweckt das Produkt zum Leben. Namen sind wichtig, weil sie die Absicht kommunizieren.
  
• is a [product category]
  → Erklärt, was dieses Produkt eigentlich ist oder tut.
  
• that [key benefit, compelling reason to buy]
  → Erläutert, warum unser Kunde dieses Produkt überhaupt kaufen möchte.
  
• Unlike [primary competitive alternative]
  → Erläutert, warum wir nicht schon das verwenden, was es bereits gibt.
  
• our product [statement of primary differentiation]
  → Erklärt wie sich das Produkt von konkurrierenden Alternativen unterscheidet oder besser ist. Dies ist der wichtigste Punkt. Hier rechtfertigen wir den Budgeteinsatz für das Produkt.

Punkt 3: Product Box erstellen

Wenn es dein Produkt im Geschäft zu kaufen gäbe: Wie sähe die Verpackung aus? Was würde draufstehen, das potenzielle Käufer und Nutzer begeistert?

Es sollte ein Slogan, Bild und die Top-3-Benefits genannt werden. Die Präsentation kann man auch wahlweise um ein Moodboard ergänzen.

Punkt 4: Die NOT Liste

Produktmanager und POs kennen das Spiel: „Cut it in half“, „YAGNI“ (You ain’t gonna need it) – eine klare Benennung von in und out of Scope ist entscheidend. Die visuelle Aufbereitung zeigt auf einen Blick, was vorgesehen, nicht vorgesehen ist und was noch unklar ist.

Zur Bestimmung des Scopes kann auch ein Blick auf die erstellte Impact Mapp helfen.

Punkt 5: Die Nachbarn treffen

Welche Abteilungen und Stakeholder müsst ihr einbinden, bevor das Produkt live geht? Wer ist darüber hinaus noch einzubeziehen? Eine frühzeitige Klärung, ermöglicht es Euch Stakeholder frühzeitig einzubinden und Überraschungen zu vermeiden.

Punkt 6: Die Lösung zeigen

Wie sieht die grobe technische Architektur des Produkts aus?

Nutze Architekturdiagramme, um zu zeigen, wie das Produkt aufgebaut sein könnte. Versuche die Erwartungen rund um die risikoreichen Bereiche bestmöglich zu klären und stelle sicher, dass die Lösung zum Vorgehen und bestehenden Strukturen passt. Das ist aus mehreren Gründen vorteilhaft. Es …

• legt die Erwartungen an Tools und Technologie fest
• visualisiert die Annahmen über Projektgrenzen und -umfang
• zeigt das mögliche Risiko auf

Punkt 7: Was hält uns nachts wach?

Benenne mögliche Risiken die bestehen, welche den Erfolg des Produkts beeinträchtigen könnten. Adressiere sie und benenne mögliche Konsequenzen, die sie auf das Produkt haben können.

Klassische Punkte sind bspw. die Einbindung von Kunden, Crossfunktionale Teams oder „shared“ Ressources. 

Je früher Abhängigkeiten oder Herausforderungen offengelegt werden, desto besser können Konsequenzen adressiert und Erwartungen gemanaged werden.

Punkt 8: Wie groß ist das?

Der Punkt, der mich immer am meisten beunruhigt. Schätzungen am Mount Stupid. Wir wollen es agil halten, dennoch benötigen wir eine grobe Indikation für eine erste Budgetfreigabe. Der Kunde will schließlich wissen, wie groß der Invest für die Wette ist.

Die Vorhersagekraft ist natürlich stark eingeschränkt, weil man noch nicht alle Details kennt, Anforderungen neu auftauchen oder sich ändern werden und man auf Basis des Kundenfeedbacks (oder Sponsorenfeedbacks) Anpassungen durchführt. Ein Scope Leap kann auch durch ein Inception Deck nicht ausgeschlossen werden. Die Umwelt dreht sich weiter und vielleicht hat ein Mitbewerber mittlerweile einen Impuls gegeben, den man jetzt an dieses Produkt hängt.   

Wie machen wir das also? Wir nutzen häufig Magic-Estimation-Sessions und geben grobe Abschätzungen auf Monatsbasis. Je nach Komplexität des Projekts ermitteln wir einen Unsicherheitsfaktor, um eine Landezone von X Monaten mit +/- X Wochen zu ermitteln. Das sind jedoch nur Schätzungen und keine Commitments – das ist oft schwer verdaulich. Wo Agilität aus Auftraggeber-Sicht unangenehm klingt, sollte man die Stärken von Agilität benennen:

• Unser Ziel ist es, den Scope so klein wie möglich zu schneiden, um das Risiko zu minimieren. Je früher wir mit einem Produkt live sind und einen Wert stiften, desto besser.
• Die frühe Lieferung ermöglicht auch schnelle Kundenvalidierung. Der Scope kann flexibel angepasst werden.
• Unser Kunde wird regelmäßig zu Reviews eingeladen, um den aktuellen Stand zu sehen und Feedback geben zu können.
• Außerdem nutzen wir agile Metriken, um Forecasts zu geben, sodass ein Fortschritt transparent nachvollziehbar ist.

Punkt 9: Was muss dran glauben, wenn es eng wird?

Welche Hebel sind für die Produktentwicklung am wichtigsten: Ist es Zeit, Umfang, Budget, Qualität?

Dieser Punkt sollte je nach Entwicklungsstand und Situation erneut besprochen werden. Jedoch ist die Diskussion um die Optionen im Vorfeld hilfreich, da sie auf „neutralem Boden“ geführt wird. Zudem kann dies die Priorisierung im Projekt beeinflussen. Ein kleiner Reminder:

Punkt 10: Was braucht es?

Nachdem der Scope grob bekannt ist und die erste Schätzung vorliegt, ist es möglich, Zeit, Kosten und die cross-funktionale Teamzusammenstellung grob zu bestimmen.

Um die Schätzung weiterhin zu unterstreichen, ist es empfehlenswert, Landing Zones (Bandbreite) anstatt einer Punktlandung zu kommunizieren.

Über diese Informationen hinaus empfehle ich für weitere Klarheit ein Team Canvas, ein POCC oder eine RACI-Matrix zu ergänzen.

Wie erarbeitet man ein Inception Deck?

Die Erstellung kann zwischen ein paar Tagen und zwei Wochen dauern. Das Inception Deck soll in einem kollaborativen Workshop ausgefüllt werden. Grundlegende Idee ist es, die richtigen Leute in einen Raum zu bekommen und ihnen die skizzierten Fragen zu stellen. Die richtigen Personen für das Inception Deck sind alle, die einen wesentlichen Beitrag (Kunden, Stakeholder, Entwickler, Tester, Analysten) zur effektiven Durchführung leisten.

Zudem kann man gleich die Stakeholder mit einbeziehen, denn das Inception Deck ist nicht nur ein Werkzeug für Produktentwicklungsteams, sondern auch für Stakeholder, um eine kritische Go-/No-Go-Entscheidung zu treffen.

POs sollten diesen Workshop und verbundenen Prozess aktiv für sich nutzen. Vermeide ein Design by Committee, in dem die Sponsoren und/oder Stakeholder das Produkt ausfechten und man als Product Owner in die Rolle eines Roadmap-Administrator oder Facilitators abrutscht. Nutze Dein Wissen und Erfahrungen und bereichere den Prozess.

Inception Decks: Was es nicht ist.

Ich möchte explizit darauf hinweisen, dass die Verwendung eines Inception Deck niemanden von der (vermeintlich) „leidlichen“ Kundenvalidierung und den üblichen Überraschungen der Produktentwicklung erlöst. Produkte und Markterfolg lassen sich leider immer noch nicht unter Labor-Bedingungen antizipieren.

Zudem soll es auch kein Lastenheft oder Projektsteckbrief in neuem Gewand sein. 

Gibt es ein Template? 

Natürlich gibt es hierfür ein Template – die Power-Point-Vorlage findet ihr auf The Agile Warrior.

Wenn ihr noch mehr erfahren wollt, habe ich noch ein besonderes Schmankerl für euch: In einer Ausgabe des Produktwerker-Podcasts spreche ich mit Tim Klein über das Inception Deck, erläutere die zehn Fragestellungen und zeige euch, wie ich vom Einsatz des Inception Decks profitiere.

Quelle und Bildquelle: The Agile Samurai by Jonathan Rasmusson Published by Pragmatic Bookshelf, 2010