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

Element	Beschreibung	Beispiel
Vision	Wohin wollen wir?	"Marktführer für HR-Software im Mittelstand"
Ziele	Was wollen wir erreichen?	"Retention Rate um 20% steigern"
Themen/Epics	Große Arbeitspakete	"Onboarding optimieren"
Zeitrahmen	Grobe Einordnung	Now, Next, Later oder Q1, Q2, Q3
Stakeholder	Wer ist betroffen?	Entwicklung, Marketing, Sales

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 (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:

Ähnliche Post-its gruppieren

Cluster benennen (z.B. "Onboarding", "Performance", "Mobile")

Duplikate entfernen

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.

Dimension	Frage	Skala
Reach	Wie viele Nutzer betrifft es?	Nutzer pro Quartal
Impact	Wie stark ist der Effekt?	3 = massiv, 2 = hoch, 1 = mittel, 0.5 = gering
Confidence	Wie sicher sind wir?	100% = hoch, 80% = mittel, 50% = niedrig
Effort	Wie viel Arbeit ist es?	Personenmonate

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.

Kategorie	Bedeutung	Anteil
Must have	Ohne das geht nichts	~60%
Should have	Wichtig, aber nicht kritisch	~20%
Could have	Wäre schön	~20%
Won't have	Nicht jetzt	-

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.

	Geringer Aufwand	Hoher Aufwand
Hoher Wert	Quick Wins → Sofort	Big Bets → Priorisieren
Geringer Wert	Fill-ins → Später	Time Sinks → Vermeiden

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

Zeitraum	Themen	Begründung
Q1	Onboarding optimieren	Höchster RICE-Score, keine Abhängigkeiten
Q1	Performance-Verbesserung	Quick Win, parallel möglich
Q2	Mobile App v2	Nach Onboarding-Learnings
Q2-Q3	Enterprise-Features	Abhängig von Mobile App

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, Kundenfeedback), 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

Tool	Stärke	Preis
ProductPlan	Dediziertes Roadmap-Tool	Ab 39$/Monat
Aha!	Enterprise-Features	Ab 59$/Monat
Monday.com	Flexibel, gut integriert	Freemium
Miro	Visuell, kollaborativ	Freemium
Notion	All-in-One, anpassbar	Freemium
Google Sheets	Kostenlos, einfach	Kostenlos

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

Persönliche Erfahrung: Der Workshop, der Sales und Produkt versöhnte

Bei einem B2B-SaaS-Unternehmen moderierte ich einen Roadmap-Workshop, der als "angespannt" angekündigt wurde. 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.

Wir begannen mit Phase 1: Context Setting. Ich bat den Sales-Lead, die drei größten Lost Deals des Quartals vorzustellen – und warum sie verloren gingen. Dann bat ich den Product Lead, die drei wichtigsten Metriken zu zeigen – 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.

Wie oft sollte ein Roadmap-Workshop stattfinden?

Quartalsweise ist ein guter Rhythmus. Jährlich für die große Richtung, quartalsweise für die konkrete Planung.

Wer sollte die Roadmap "ownen"?

Der Product Owner oder Product Manager. Aber: Die Roadmap entsteht gemeinsam. Ownership heißt nicht Alleingänge.

Wie detailliert sollte eine Roadmap sein?

Je näher, desto detaillierter. Now: Konkrete Epics. Next: Themen. Later: Richtungen. Keine konkreten Features für Q4 im Januar planen.

Wie gehe ich mit Stakeholdern um, die ihre Features durchdrücken wollen?

Auf Daten zurückgreifen. RICE-Scoring macht die Diskussion objektiver. "Dein Feature hat einen Score von 200, dieses andere hat 800 – welches sollten wir zuerst machen?"

Was tun, wenn die Roadmap nicht eingehalten werden kann?

Transparent kommunizieren, neu priorisieren. Eine Roadmap, die nie angepasst wird, ist entweder perfekt geplant (unwahrscheinlich) oder wird ignoriert.

Dieser Artikel wurde zuletzt aktualisiert im Dezember 2025.