Roadmaps klingen am Anfang fast immer logisch
Eine Roadmap ist schnell überzeugend, solange sie nur nach vorne erzählt wird. Erst kommt das Feature, dann die Kampagne, dann die Kundengespräche, dann der größere Deal. Auf dem Papier sieht das nach Führung aus. In der Realität übersieht ein frühes Team dabei oft die Stellen, an denen ein Projekt nicht durch schlechte Arbeit scheitert, sondern durch falsche Annahmen, übersehene Abhängigkeiten oder zu späte Klärung.
Ein Pre Mortem Sprint dreht die Perspektive um. Das Team stellt sich vor, das Projekt sei in acht Wochen gescheitert. Dann wird gefragt, warum das passiert ist. Diese Frage klingt negativ, ist aber hochpraktisch. Sie erlaubt ehrliche Risiken, bevor Menschen ihr Gesicht an einen Plan gehängt haben. Je früher diese Risiken sichtbar werden, desto leichter lassen sie sich entschärfen.
Meine klare Meinung: Viele Gründerteams planen zu optimistisch, weil Optimismus als Tempo getarnt ist. Sie wollen nicht bremsen, also sprechen sie lieber über Meilensteine als über Bruchstellen. Ein Pre Mortem Sprint ist kein Pessimismus. Er ist ein kurzer Realitätstest, damit Tempo nicht auf Hoffnung gebaut wird.
Der Sprint braucht nur eine Stunde und klare Rollen
Ein brauchbarer Pre Mortem Sprint beginnt mit einer konkreten Projektentscheidung. Nicht allgemein über Wachstum sprechen, sondern über ein neues Angebot, einen Produktrelease, eine Kampagne, einen Partnerkanal oder eine größere interne Umstellung. Je konkreter das Vorhaben, desto klarer werden die Risiken. Danach schreibt jede Person still auf, warum das Projekt scheitern könnte. Erst danach wird gesprochen. So verhindert das Team, dass die lauteste Person den Risikoraum vorgibt.
Die wichtigsten Fragen sind bewusst einfach:
- Was müsste passieren, damit dieses Vorhaben trotz guter Absicht scheitert?
- Welche Annahme prüfen wir zu spät?
- Wo hängt der Plan an einer Person, einem Kunden, einem Tool oder einer Freigabe?
- Welches Frühzeichen würden wir ignorieren, wenn wir unter Druck stehen?
- Welche kleine Schutzmaßnahme lohnt sich vor dem Start?
Der Tiefenpunkt liegt bei der letzten Frage. Ein Pre Mortem ist wertlos, wenn er nur Sorgen sammelt. Jedes wichtige Risiko braucht eine Entscheidung. Entweder das Team akzeptiert es bewusst, prüft es vor dem Start oder baut eine Sicherung ein. Diese Sicherung kann klein sein. Ein Kundengespräch vor der Umsetzung, ein technischer Spike, eine klare Stoppregel, ein Alternativkanal oder eine Person, die eine Abhängigkeit absichert.
Gute Teams machen Risiken entscheidbar statt dramatisch
Ein plausibles Szenario: Ein kleines Softwareteam plant einen neuen Reportingbereich, weil zwei größere Interessenten danach gefragt haben. Die Roadmap wirkt vernünftig. Im Pre Mortem entstehen andere Fragen. Was, wenn beide Interessenten unterschiedliche Reports meinen? Was, wenn die Datenqualität bei Bestandskunden nicht reicht? Was, wenn der Gründer alle fachlichen Entscheidungen freigeben muss? Was, wenn die Funktion im Vertrieb gut klingt, aber in der Nutzung keinen täglichen Wert liefert?
Aus diesen Fragen entsteht kein Projektstopp. Es entsteht ein besserer Start. Das Team führt vor der Entwicklung drei konkrete Reportinggespräche, baut einen klickbaren Entwurf statt direkt Backendlogik und definiert, welche Metrik nach dem Launch zeigen soll, ob der Bereich genutzt wird. Die Roadmap bleibt mutig, aber sie bekommt Prüfpunkte.
Wichtig ist die Grenze: Ein Pre Mortem darf nicht zur Angstveranstaltung werden. Wenn jedes Risiko gleich schwer wirkt, verliert das Team Energie. Deshalb sollten am Ende nur die drei kritischsten Risiken bearbeitet werden. Alles andere wird notiert, aber nicht überhöht. Führung heißt auch, manche Unsicherheit bewusst zu tragen.
Hilfreich ist außerdem ein kurzer Blick nach dem ersten Projektabschnitt. Das Team prüft dann, welche Sorge berechtigt war, welche übertrieben war und welches neue Risiko sichtbar wurde. So wird der Sprint nicht zu einem einmaligen Ritual, sondern zu einer kleinen Lernschleife für bessere Planung.
Mein Fazit: Ein Pre Mortem Sprint ist eine der günstigsten Formen von Projektqualität. Er schützt Gründerteams vor Plänen, die nur deshalb stabil wirken, weil niemand die Schwachstellen früh ausspricht. Wer Risiken vor dem Start benennt, entscheidet nüchterner. Genau dadurch wird eine Roadmap nicht langsamer, sondern belastbarer.
Quelle: Pexels
