Roadmap-Workshop: Vom Feature-Wunschkonzert zur priorisierten Timeline

Ein Roadmap-Workshop ist ein strukturiertes Format, in dem Produktteams gemeinsam mit Stakeholdern eine priorisierte Timeline für die Produktentwicklung erarbeiten. Statt eines Feature-Wunschkonzerts, bei dem jeder seine Ideen durchdrücken will, entsteht eine Roadmap, hinter der alle stehen. Das Ergebnis: Klarheit über Prioritäten, Alignment zwischen Teams und eine realistische Planung für die kommenden Quartale.

---

Warum Roadmaps oft scheitern

Fragen Sie zehn Personen, was eine Produkt-Roadmap ist – Sie erhalten zehn verschiedene Antworten. Für manche ist es eine Feature-Liste mit Deadlines. Für andere ein strategisches Kommunikationstool. Für wieder andere ein Versprechen an Kunden.

Diese Unklarheit führt zu Problemen:

Problem 1: Die Wunschliste Jede Abteilung bringt ihre Wünsche ein. Sales will Feature A (weil ein Großkunde es fordert), Marketing will Feature B (für die Kampagne), Support will Feature C (weil Tickets nerven). Ohne Priorisierung wird die Roadmap zur unerfüllbaren Wunschliste.

Problem 2: Die Festlegungsfalle Roadmaps werden als Versprechen interpretiert. "Feature X kommt in Q2" – und wenn nicht, ist das Team unzuverlässig. Diese Angst vor Festlegung führt zu vagen Roadmaps ohne Aussagekraft.

Problem 3: Fehlende Stakeholder-Einbindung Wenn die Roadmap im stillen Kämmerlein entsteht, fehlt die Akzeptanz. Stakeholder fühlen sich übergangen und torpedieren die Umsetzung.

Ein Roadmap-Workshop adressiert alle drei Probleme: Er schafft Klarheit über Kriterien, vermittelt die Natur einer Roadmap als "lebendiges Dokument" und bindet alle relevanten Personen ein.

---

Was eine gute Roadmap ausmacht

Die Elemente

Die Zeitachsen

Now / Next / Later: Flexibles Format ohne feste Daten. Gut für unsichere Umfelder.

• Now: Aktuelle Arbeit (die nächsten 4-6 Wochen)
• Next: Nächste Priorität (2-3 Monate)
• Later: Ideen für die Zukunft (kein Commitment)

Quartals-Roadmap: Konkretere Zeitrahmen, aber keine genauen Daten.

• Q1: Januar-März
• Q2: April-Juni
• etc.

Release-Roadmap: Orientiert an konkreten Releases.

• v2.1: Feature A, B
• v2.2: Feature C, D

---

Der Roadmap-Workshop: Schritt für Schritt

Teilnehmer

• Kern-Team: Product Owner/Manager, Lead Developer, Designer
• Stakeholder: Sales, Marketing, Support, Customer Success
• Optional: Key Accounts, Management

Empfehlung: 6-12 Personen. Weniger ist oft besser – zu viele Teilnehmer führen zu endlosen Diskussionen.

Dauer

• Halber Tag (gut 4 Stunden): Für quartalsweise Aktualisierungen
• Ganzer Tag: Für jährliche Planung oder Neuausrichtung

Phase 1: Context Setting (30 Minuten)

Ziel: Alle auf den gleichen Stand bringen.

Inhalte:

• Produktvision und -strategie rekapitulieren
• Wichtige Metriken teilen (Retention, NPS, Churn)
• Markt- und Wettbewerbsentwicklung skizzieren
• Ressourcen-Realität klären (Team, Budget, Timeline)

Wichtig: Diese Phase wird oft unterschätzt. Ohne gemeinsames Verständnis der Ausgangslage sind Priorisierungsdiskussionen fruchtlos.

Phase 2: Input sammeln (45 Minuten)

Ziel: Alle Ideen, Wünsche und Anforderungen auf den Tisch bringen.

Methode: Stakeholder-Canvas

Jeder Stakeholder-Bereich beantwortet:

• Was brauchen eure Kunden/Nutzer am dringendsten?
• Was blockiert euch in eurer Arbeit?
• Welche Marktchancen seht ihr?

Silent Brainstorming: Erst schreiben, dann teilen. Ein Thema pro Post-it. Keine Diskussion in dieser Phase – nur Sammeln.

Phase 3: Clustern und Verstehen (30 Minuten)

Ziel: Struktur in die Ideen bringen.

Ablauf:

1. Ähnliche Post-its gruppieren
2. Cluster benennen (z.B. "Onboarding", "Performance", "Mobile")
3. Duplikate entfernen
4. Kurze Klärung: Was genau ist gemeint?

Pause (15 Minuten)

Phase 4: Priorisieren (60 Minuten)

Ziel: Entscheiden, was zuerst kommt.

Hier liegt die eigentliche Arbeit. Es gibt verschiedene Frameworks – wählen Sie eines, das zu Ihrer Situation passt.

---

Priorisierungs-Frameworks

RICE-Scoring

RICE steht für Reach, Impact, Confidence, Effort. Jedes Feature wird auf diesen vier Dimensionen bewertet.

Formel: RICE Score = (Reach × Impact × Confidence) / Effort

Beispiel:

• Feature A: (1000 × 2 × 80%) / 2 = 800
• Feature B: (500 × 3 × 100%) / 4 = 375

Feature A hat den höheren Score und wird priorisiert.

MoSCoW

Einfacher als RICE, aber weniger objektiv.

Regel: Must-haves müssen realistisch in den Zeitrahmen passen. Wenn 90% "Must have" sind, stimmt etwas nicht.

Value vs. Effort Matrix

Einfaches visuelles Tool.

Kano-Modell

Kategorisiert Features nach Kundenerwartung:

• Basis: Wird erwartet, fehlt → Unzufriedenheit
• Leistung: Je mehr, desto zufriedener
• Begeisterung: Nicht erwartet, aber begeistert

---

Phase 5: Timeline erstellen (45 Minuten)

Ziel: Die priorisierten Themen in einen zeitlichen Rahmen bringen.

Schritt 1: Kapazität klären

Wie viel kann das Team realistisch umsetzen? Typischer Fehler: Zu viel einplanen.

Faustregel: 70% der Kapazität verplanen. Der Rest geht für Bugs, Support, Unvorhergesehenes drauf.

Schritt 2: Abhängigkeiten identifizieren

Manche Themen bauen aufeinander auf. Diese Abhängigkeiten müssen in die Timeline einfließen.

Schritt 3: Themen einordnen

Schritt 4: Visualisieren

Die Roadmap sollte auf einen Blick verständlich sein. Digitale Tools wie ProductPlan, Aha! oder ein simples Miro-Board helfen.

---

Phase 6: Alignment und Commitment (30 Minuten)

Ziel: Sicherstellen, dass alle die Roadmap verstehen und mittragen.

Runde 1: Verständnisfragen

• Ist etwas unklar?
• Fehlt etwas Wichtiges?

Runde 2: Bedenken

• Was könnte uns stoppen?
• Welche Risiken sehen wir?

Runde 3: Commitment

• Können wir das gemeinsam tragen?
• Was brauchen wir, um erfolgreich zu sein?

---

Nach dem Workshop: Die Roadmap leben

Kommunikation

• Intern: Roadmap im Team-Wiki oder Projektmanagement-Tool zugänglich machen
• Stakeholder: Regelmäßige Updates (monatlich oder quartalsweise)
• Extern: Für Kunden aufbereitete Version (ohne interne Details)

Review-Rhythmus

• Wöchentlich: Kurzer Check – sind wir on track?
• Monatlich: Detaillierter Review – müssen wir nachjustieren?
• Quartalsweise: Nächster Roadmap-Workshop für kommenden Zeitraum

Änderungsmanagement

Eine Roadmap ist kein Gesetz. Wenn sich Prioritäten ändern (neuer Wettbewerber, Marktveränderung, Kunden-Feedback), muss sie angepasst werden.

Regel: Jede Änderung transparent kommunizieren und begründen.

---

Typische Fehler und wie sie vermieden werden

Fehler 1: Feature-Listen statt Outcomes

❌ "Login mit Social Media implementieren" ✅ "Registrierungsrate um 20% steigern"

Roadmaps sollten Ziele und Probleme beschreiben, nicht Lösungen. Die konkrete Lösung kann sich ändern.

Fehler 2: Zu detailliert für den Zeitraum

Je weiter in der Zukunft, desto unschärfer sollte die Roadmap sein. Q1: konkrete Themen. Q4: grobe Richtung.

Fehler 3: Keine Kapazitätsprüfung

Eine Roadmap mit mehr Themen als das Team schaffen kann, ist ein Rezept für Frust. Realistisch planen.

Fehler 4: HiPPO-Dominanz

HiPPO = Highest Paid Person's Opinion. Wenn der Chef seine Lieblingsfeatures durchdrückt, war der Workshop umsonst. Der Facilitator muss gegensteuern.

Fehler 5: Roadmap als Vertrag

"Aber das stand doch in der Roadmap!" – Eine Roadmap ist ein Plan, kein Vertrag. Pläne ändern sich. Das muss von Anfang an kommuniziert werden.

---

Tools für Roadmaps

Für den Workshop selbst reichen Post-its und ein Whiteboard. Das Tool wird für die Dokumentation und laufende Pflege relevant.

---

Praxisbeispiel: Der Workshop, der Sales und Produkt versöhnte

Ein Beispiel: Bei einem B2B-SaaS-Unternehmen wurde ein Roadmap-Workshop vorab als "angespannt" angekündigt. Sales und Produkt waren seit Monaten im Clinch. Sales versprach Kunden Features, die Produkt nicht liefern konnte. Produkt baute Dinge, die Sales nicht verkaufen konnte.

Der Workshop begann mit Phase 1: Context Setting. Der Sales-Lead stellte die drei größten Lost Deals des Quartals vor – und warum sie verloren gingen. Dann zeigte der Product Lead die drei wichtigsten Metriken – Retention, NPS, Feature-Adoption.

Die Erkenntnis: Sales verlor Deals wegen fehlender Enterprise-Features. Aber die bestehenden Kunden churnen wegen schlechter Performance. Beides war richtig, beides war wichtig.

Statt "Sales will X, Produkt will Y" wurde daraus: "Wir müssen Performance stabilisieren UND Enterprise-Features bauen." Die RICE-Priorisierung zeigte: Performance zuerst (hoher Reach, da alle Kunden betroffen), dann Enterprise (hoher Impact, aber geringerer Reach).

Am Ende stand eine Roadmap, die beide Seiten trugen. Nicht weil alle glücklich waren – sondern weil alle verstanden, warum.

---