Vor zwei Wochen hätte ich für eine MVP-Scoping-Session einen Miro-Board aufgesetzt. Eine Woche vorher Templates suchen, Sticky Notes vorbereiten, Workshop-Skript schreiben. Diese Woche habe ich stattdessen zwei Stunden mit Claude einen eigenen Story-Map-Builder konzipiert, ihn auf Vercel deployt, ein Supabase-Backend angeschlossen und die Live-URL ans Team geschickt. Alle waren am Ende aufs MVP eingeschworen, nicht trotz, sondern wegen des Tools.

Wie der Eigenbau entstanden ist

Story-Mapping nach Jeff Patton ist eine bekannte Methode: Journey-Steps horizontal, Stories vertikal, MVP-Linie quer durch die Karten. In der Praxis scheitert das Format oft an drei Dingen:

1. Karten haben keinen Bezug zu Hypothesen.
2. Entscheidungen werden in der Session getroffen, aber nirgendwo dokumentiert.
3. Die Übergabe vom Workshop in das Backlog ist manuelle Arbeit, die niemand macht.

Genau diese drei Lücken wollte ich schließen.

Die ersten zwei Stunden waren reines Konzept: Welche Spalten? Welche Swim-Lanes? Wie sind Hypothesen mit Karten verknüpft? Brauchen wir Drag-and-Drop oder reicht ein Klick-Toggle? Wer darf editieren, wer nur lesen? Wie kommen die MVP-Karten in Linear? Diese Fragen habe ich mit Claude durchgegangen, eine Skizze gemacht, eine Datenstruktur festgelegt. Der Plan stand, bevor eine Zeile Code geschrieben war. Danach hat Claude den Build übernommen, ich habe iteriert.

Die Features

Das Tool ist eine einzelne Web-App mit zwei Seiten: Story-Map und DACI-Matrix. Auf der Story-Map sehen alle Beteiligten dieselben Daten in Echtzeit, dank Supabase. Die linke Sidebar listet neun Hypothesen (H1 bis H9). Klick auf eine Hypothese filtert die Map: nur Karten, die diese Hypothese adressieren, bleiben sichtbar. Die Karten sitzen in einem Grid aus Journey-Steps, in vier Swim-Lanes: MVP, Next, Nie, Undecided. Ein Modal erlaubt das Anlegen neuer Karten in der Session selbst, mit Titel, Begründung in einem Satz, Hypothesen-Chips und Swim-Lane. Der Coverage-Panel oben zeigt, welche Hypothesen bereits abgedeckt sind und welche im MVP fehlen. Die rechte Sidebar ist ein Decision-Log: jede Lane-Änderung wird automatisch festgehalten, mit Zeitstempel.

Drei Aktionen lösen den Übergang aus der Session in die echte Arbeit aus. Snapshot für Claude kopiert eine Markdown-Zusammenfassung des aktuellen Stands ins Clipboard und lädt JSON herunter. Damit kann ich nach der Session mit Claude an einer detaillierten Spec weiterarbeiten. MVP-Cards in Linear ist ein Bulk-Sync: alle Karten in der MVP-Lane werden als neue Linear-Issues angelegt. Vom Whiteboard ins Backlog mit einem Klick. Drucken / PDF ist die Print-View für Stakeholder, die nichts mit Linear oder Vercel zu tun haben.

Die DACI-Matrix daneben hat eigene Features: Zeilen für Entscheidungs-Typen, Spalten für Rollen, Zellen mit zyklischem Klick durch D, A, C, I, leer. Header sind direkt editierbar, Zeilen und Spalten lassen sich live hinzufügen. Auch hier: Snapshot für Claude und JSON-Export.

Was ich dabei gelernt habe

Es war mein erster Vercel-Deploy. Ich kannte die Plattform aus dem Hörensagen, hatte aber nie eine eigene App dort gehosted. Der Schritt von "lokaler Prototyp" zu "Live-URL, die mein Team aufrufen kann" hat fünf Minuten gedauert, nicht eine halbe Stunde, wie ich erwartet hatte. Was länger gedauert hat: die Supabase-Konfiguration. Realtime-Sync zwischen mehreren Browsern in derselben Session ist nicht trivial, weil Identitäten, Auth und Konfliktlösung dazukommen. Claude hat das Setup übernommen, aber ich musste die Konzepte verstehen, weil Bugs erklärt werden wollen. Postgres Row-Level-Security war ein Begriff, den ich nicht kannte. Jetzt schon.

Die größte methodische Lehre: Anpassungen unterwegs sind keine Schwäche, sondern Teil des Builds. Während der zwei Stunden haben wir gemeinsam Sachen verworfen, neu eingebaut, anders strukturiert. Drag-and-Drop kam später dazu, weil sich in der Konzept-Phase gezeigt hat, dass Klick-Toggle für Lane-Wechsel nicht reicht. Die Hypothesen-Chips wurden eingeführt, weil ich beim Skizzieren gemerkt habe, dass Karten ohne Hypothese-Bezug das Anti-Pattern sind, das ich vermeiden will. Diese Iterationen wären in einem klassischen Build mit ausgelagertem Engineering nicht möglich gewesen.

Was die Session gemacht hat

In der Session saß das Team vor dem Tool. Der erste Stand war vorbereitet: alle 9 Hypothesen drin, Karten als Vorschläge in Undecided. In der ersten halben Stunde wanderten Karten in MVP, Next oder Nie, jede Verschiebung kurz begründet, der Decision-Log schrieb alles mit. War ein Punkt strittig, zeigte das Coverage-Panel die Antwort: ist diese Hypothese sonst nirgends abgedeckt? Wenn nicht, musste etwas in die MVP-Lane.

Die zweite Stunde war intensiver, und hier zeigte sich der Wert der DACI-Matrix. Die Rollen waren vorab geklärt: Wer die UX verantwortet, war als Approver markiert. Als eine Karte zum Onboarding-Flow ins MVP-Tier rutschte, kam von dort das Veto, die Lane funktioniere ohne diese Karte nicht. Die Diskussion war in zwei Minuten durch, weil DACI klargemacht hatte, wer hier den letzten Anstoß gibt. Parallel sorgte die moderierende Rolle dafür, dass keine Hypothese verwaiste, während der Driver Karten umhängte und Begründungen festhielt. Nicht die Personen entschieden den Streit, sondern die vorher verteilten Verantwortlichkeiten.

Am Ende stand: ein dokumentiertes MVP, Hypothesen explizit zugeordnet, ein Decision-Log mit Begründungen, und durch den Linear-Bulk-Sync war der ganze MVP-Scope fünf Minuten später als Issues im Repo. Was vorher zwei Wochen gedauert hätte, war an einem Nachmittag geklärt.

Was ich mir vornehme

Ich möchte das Pattern wiederholen, aber bewusster mit dem zeitlichen Trade-off umgehen. Zwei Stunden Konzeptarbeit vor einer wichtigen Session lohnen sich, wenn die Session selbst sonst zwei Tage gekostet hätte und das Ergebnis halb-strukturiert in einem Miro-Export verschwunden wäre. Das ist nicht jede Session. Für Routine-Standups oder kurze Abstimmungen ist der Eigenbau Overkill. Ich brauche ein Gespür dafür, wann der Aufwand passt.

Außerdem will ich die Tool-Sammlung als modulare Bausteine begreifen. Story-Map und DACI sind wiederverwendbar. Beim nächsten Projekt werde ich vermutlich nicht von Null anfangen, sondern aus der bestehenden Codebase forken. Das ist eine zusätzliche Lernkurve: Wie behalte ich diese Bausteine sortiert und wartbar, ohne dass die Sammlung selbst zur neuen Last wird.

Kritische Einordnung

Der Eigenbau funktioniert, weil ich mit Claude einen Co-Pilot habe, der Code schreibt. Ohne diese Hebelwirkung wäre der Aufwand für das Tool höher als der Nutzen. Es bleibt also ein Privileg, an das andere Teams ohne KI-Zugang nicht so leicht herankommen. Ich überschätze auch nicht, was eine einzelne Session ändert: Team-Alignment in zwei Stunden hält nur, wenn die Folge-Arbeit darauf aufbaut. Wenn das Tool nach der Session in der Schublade verschwindet, war der Aufwand umsonst. Und schließlich: die ganze Methode steht und fällt mit der Qualität der Hypothesen, die ich vorher formuliert habe. Schlechte Hypothesen führen zu schlechtem Scope, egal wie schön die Story-Map aussieht.