Feature Priorisierung und Roadmap
Du hast dein MVP gelauncht, Kundeninterviews geführt und vielleicht einen Beta-Test durchgeführt. Jetzt hast du eine lange Liste von Feature-Wünschen, Bug-Reports und eigenen Ideen. Die grosse Frage: Was baust du als Nächstes?
In diesem Beitrag zeige ich dir, wie du Features systematisch priorisierst und eine Roadmap erstellst, die dein Startup voranbringt -- ohne dich in Feature-Creep zu verlieren.
Warum Feature-Priorisierung so wichtig ist
Die meisten Startups scheitern nicht an zu wenigen Ideen -- sie scheitern an zu vielen. Jedes Feature, das du baust, kostet:
- Entwicklungszeit: Wochen bis Monate
- Geld: Entwicklergehalt, Tools, Infrastruktur
- Komplexität: Jedes Feature macht dein Produkt komplexer
- Wartung: Jedes Feature muss dauerhaft gewartet werden
- Fokus: Jede Stunde, die du in Feature A investierst, fehlt für Feature B
Als Startup hast du begrenzte Ressourcen. Jedes Feature, das du baust, muss den maximalen Wert liefern.
Die Feature-Liste: Alles an einem Ort
Bevor du priorisierst, sammle alle Feature-Ideen an einem zentralen Ort. Quellen:
| Quelle | Art der Inputs |
|---|---|
| Kundeninterviews | Schmerzpunkte, Wünsche |
| Beta-Test-Feedback | Feature-Requests, Bug-Reports |
| Kundensupport | Häufige Fragen und Probleme |
| Wettbewerbsanalyse | Features, die Wettbewerber haben |
| Eigene Ideen | Strategische Features |
| Analytics-Daten | Nutzungsverhalten-basierte Ideen |
| Sales-Team | Features, die im Vertrieb fehlen |
Feature-Request-Template
Für jede Feature-Idee dokumentiere:
| Feld | Beschreibung |
|---|---|
| Feature-Name | Kurzer, beschreibender Name |
| Beschreibung | Was soll das Feature tun? (2 bis 3 Sätze) |
| Quelle | Wer hat es vorgeschlagen? |
| Häufigkeit | Wie oft wird es angefragt? |
| Nutzersegment | Welche Nutzergruppe profitiert? |
| Problem | Welches Problem löst es? |
| Geschätzer Aufwand | T-Shirt-Grösse: S/M/L/XL |
| Abhängigkeiten | Braucht es andere Features zuerst? |
Die 5 besten Priorisierungs-Frameworks
Framework 1: RICE-Score
RICE steht für Reach, Impact, Confidence, Effort und ist eines der bewährtesten Frameworks:
| Faktor | Beschreibung | Skala |
|---|---|---|
| Reach | Wie viele Nutzer erreicht das Feature pro Quartal? | Anzahl |
| Impact | Wie stark verbessert es die Erfahrung? | 0,25 / 0,5 / 1 / 2 / 3 |
| Confidence | Wie sicher bist du bei deiner Einschätzung? | 50% / 80% / 100% |
| Effort | Wie viele Personenmonate braucht es? | Anzahl |
Formel: RICE = (Reach x Impact x Confidence) / Effort
Beispiel:
| Feature | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| Push-Benachrichtigungen | 500 | 2 | 80% | 2 | 400 |
| Dark Mode | 200 | 0,5 | 100% | 1 | 100 |
| Export-Funktion | 100 | 3 | 80% | 3 | 80 |
| Multi-Sprache | 300 | 1 | 50% | 4 | 37,5 |
Ergebnis: Push-Benachrichtigungen haben die höchste Priorität.
Framework 2: MoSCoW-Methode
MoSCoW kategorisiert Features in vier Gruppen:
| Kategorie | Bedeutung | Anteil am Aufwand |
|---|---|---|
| Must have | Unverzichtbar, ohne das funktioniert nichts | 60% |
| Should have | Wichtig, aber nicht kritisch | 20% |
| Could have | Wäre schön, aber nicht nötig | 15% |
| Won't have (this time) | Bewusst ausgeschlossen -- nicht jetzt | 5% (Planung) |
Vorteil: Einfach, schnell, gut für Team-Diskussionen Nachteil: Keine Rangfolge innerhalb der Kategorien
Framework 3: Kano-Modell
Das Kano-Modell kategorisiert Features nach ihrer Wirkung auf die Kundenzufriedenheit:
| Kategorie | Beschreibung | Beispiel |
|---|---|---|
| Basis-Features | Werden erwartet, ihr Fehlen frustriert | Login funktioniert, Seite lädt schnell |
| Leistungs-Features | Mehr davon = mehr Zufriedenheit | Schnellere Suche, mehr Filterooptionen |
| Begeisterungs-Features | Überraschen positiv, werden nicht erwartet | Personalisierte Empfehlungen, smarte Automatisierung |
| Indifferente Features | Kunden ist egal, ob vorhanden oder nicht | -- |
| Reverse Features | Ihr Vorhandensein stört | Zu viele Benachrichtigungen, überladene UI |
So verwendest du das Kano-Modell:
Frage für jedes Feature zwei Fragen:
- "Wie würdest du dich fühlen, wenn dieses Feature vorhanden ist?"
- "Wie würdest du dich fühlen, wenn dieses Feature NICHT vorhanden ist?"
Antwortmöglichkeiten jeweils: begeistert / erwartet / egal / stört / akzeptabel
Aus der Kombination der Antworten ergibt sich die Kategorie.
Framework 4: Value vs. Effort Matrix
Die einfachste Methode: Zeichne ein 2x2-Raster:
| Geringer Aufwand | Hoher Aufwand | |
|---|---|---|
| Hoher Wert | Quick Wins -- SOFORT machen | Grosse Projekte -- Planen |
| Geringer Wert | Fill-ins -- Wenn Zeit übrig | Zeitfresser -- NICHT machen |
Vorteil: Visuell, intuitiv, perfekt für Workshops Nachteil: Subjektiv, keine präzise Rangfolge
Framework 5: Opportunity Scoring
Basierend auf dem Jobs-to-be-Done-Framework:
Frage Kunden:
- "Wie wichtig ist es für dich, [Job/Aufgabe] zu erledigen?" (1 bis 10)
- "Wie zufrieden bist du mit der aktuellen Lösung?" (1 bis 10)
Opportunity Score = Wichtigkeit + (Wichtigkeit - Zufriedenheit)
Features mit hohem Opportunity Score sind die grossen Chancen -- wichtig für den Kunden, aber aktuell schlecht gelöst.
Welches Framework für welche Situation?
| Situation | Empfohlenes Framework |
|---|---|
| Frühphase, wenig Daten | Value vs. Effort Matrix |
| MVP-Ausbau, kleine Feature-Liste | MoSCoW |
| Wachstumsphase, viele Anfragen | RICE |
| Kundenzentrierte Entwicklung | Kano oder Opportunity Scoring |
| Team-Workshop, schnelle Entscheidung | MoSCoW oder Value vs. Effort |
Eine Produkt-Roadmap erstellen
Die Roadmap ist der Plan, der zeigt, welche Features wann kommen. Aber Vorsicht: Eine Roadmap ist kein Versprechen -- sie ist ein lebendiges Dokument, das sich ändert, wenn du Neues lernst.
Roadmap-Typen
| Typ | Zeithorizont | Detailgrad | Geeignet für |
|---|---|---|---|
| Now/Next/Later | Kein fester Zeitraum | Niedrig | Frühphase |
| Quartals-Roadmap | 3 Monate | Mittel | Wachstumsphase |
| Release-Roadmap | Pro Release | Hoch | Reife Produkte |
| Themen-Roadmap | Variabel | Mittel | Strategische Planung |
Für Startups empfohlen: Now/Next/Later
Dieses Format ist flexibel genug für die Ungewissheit der Frühphase:
NOW (nächste 2 bis 4 Wochen)
- Konkretes Feature 1 (in Entwicklung)
- Konkretes Feature 2 (als nächstes)
- Bug-Fix Batch
NEXT (nächste 1 bis 3 Monate)
- Thema A (z.B. "Onboarding verbessern")
- Thema B (z.B. "Zahlungsoption erweitern")
LATER (3+ Monate)
- Strategische Idee 1
- Strategische Idee 2
- Langfristige Vision
Roadmap-Vorlage für ein österreichisches Startup
Hier ein konkretes Beispiel für eine Plattform zur Ferienwohnungs-Vermittlung im Burgenland:
NOW (Dezember 2026)
- Buchungsbestätigung per E-Mail (Must have, Aufwand: S)
- Kalender-Synchronisation mit Google Calendar (Should have, Aufwand: M)
- 5 kritische Bugs aus dem Beta-Test fixen
NEXT (Q1 2027)
- Thema: "Zahlungsabwicklung" -- Stripe-Integration für Online-Zahlung
- Thema: "Gastgeber-Onboarding" -- Vereinfachter Registrierungsprozess
- Thema: "Sichtbarkeit" -- SEO-Optimierung der Inserate
LATER (Q2 2027+)
- Bewertungssystem für Gäste und Gastgeber
- Multi-Sprache (Englisch, Ungarisch)
- Mobile App (nativ)
Feature-Priorisierung in der Praxis: Ein Workshop-Format
Hier ein bewährtes Format für einen Priorisierungs-Workshop mit deinem Team:
Vorbereitung (30 Minuten vorher)
- Alle Feature-Ideen auf Karten/Post-its schreiben
- RICE-Score oder Value/Effort für jedes Feature vorbereiten
- Raum mit Whiteboard oder Miro-Board vorbereiten
Phase 1: Sammeln (15 Minuten)
Jedes Teammitglied fügt Feature-Ideen hinzu, die noch fehlen. Keine Diskussion -- nur sammeln.
Phase 2: Klären (20 Minuten)
Jede Feature-Idee wird kurz vorgestellt (30 Sekunden pro Feature). Ziel: Alle verstehen, worum es geht.
Phase 3: Bewerten (30 Minuten)
Jedes Teammitglied bewertet jedes Feature nach Value und Effort (oder RICE). Unabhängig voneinander, ohne Diskussion.
Phase 4: Diskutieren (30 Minuten)
Wo gibt es grosse Abweichungen in der Bewertung? Diese Features werden diskutiert, bis ein Konsens entsteht.
Phase 5: Priorisieren (20 Minuten)
Basierend auf den Bewertungen wird die Reihenfolge festgelegt. Die Top 3 bis 5 Features kommen in die "NOW"-Spalte der Roadmap.
Phase 6: Committen (15 Minuten)
Das Team committet sich auf die Prioritäten. Ab jetzt wird nur an diesen Features gearbeitet -- nichts anderes schleicht sich rein.
Umgang mit Feature-Requests von Kunden
Kunden sind eine wichtige Feedback-Quelle -- aber nicht jeder Feature-Request sollte umgesetzt werden.
Die 80/20-Regel für Feature-Requests
In der Regel kommen 80 Prozent der Requests von 20 Prozent der Nutzer. Und oft sind es die lautesten Nutzer -- nicht unbedingt die repräsentativsten.
Framework für den Umgang mit Requests
| Frage | Aktion |
|---|---|
| Passt es zu unserer Vision? | Nein: Höflich ablehnen |
| Haben mehrere Kunden es angefragt? | Nein: Auf Wiederholungsliste setzen |
| Löst es ein echtes Problem? | Nein: Nice-to-have-Liste |
| Ist der Aufwand vertretbar? | Nein: Später-Liste |
| Alle Fragen mit Ja? | In die Priorisierung aufnehmen |
Wie du "Nein" sagst
"Nein" zu sagen ist eine der wichtigsten Fähigkeiten eines Produktmanagers. Hier einige Formulierungen:
- "Danke für den Vorschlag! Das passt aktuell nicht in unsere Roadmap, aber ich nehme es auf unsere Liste für zukünftige Versionen."
- "Interessante Idee! Wir konzentrieren uns gerade auf [Thema]. Darf ich dich kontaktieren, wenn wir daran arbeiten?"
- "Das ist ein guter Punkt. Aktuell lösen wir das mit [Workaround]. Wir beobachten, wie viele Nutzer sich das wünschen."
Häufige Fehler bei der Feature-Priorisierung
Fehler 1: HiPPO-Entscheidungen
HiPPO steht für "Highest Paid Person's Opinion" -- wenn die Chefin oder der Chef entscheidet, welche Features gebaut werden, ohne Daten zu berücksichtigen.
Lösung: Nutze Frameworks (RICE, MoSCoW) und stütze Entscheidungen auf Daten.
Fehler 2: Feature-Creep
Du fügst ständig kleine Features hinzu -- "ist ja nur eine Kleinigkeit". Die Summe dieser Kleinigkeiten frisst deine Kapazität.
Lösung: Alles -- wirklich alles -- muss durch den Priorisierungsprozess.
Fehler 3: Shiny Object Syndrome
Jede Woche eine neue Priorität, weil etwas Neues spannend erscheint.
Lösung: Priorisierungen maximal einmal pro Sprint (2 Wochen) ändern.
Fehler 4: Nur auf Kunden-Feedback reagieren
Kunden sagen dir, was sie wollen -- aber nicht immer, was sie brauchen. Henry Ford soll gesagt haben: "Hätte ich die Leute gefragt, hätten sie schnellere Pferde gewollt."
Lösung: Kombiniere Kundenfeedback mit eigener Vision und Datenanalyse.
Fehler 5: Die technische Schuld ignorieren
Wenn du nie in Refactoring, Performance oder Sicherheit investierst, wird dein Produkt langsam, instabil und angreifbar.
Lösung: Reserviere 20 bis 30 Prozent deiner Kapazität für technische Verbesserungen.
Fehler 6: Keine Roadmap kommunizieren
Wenn dein Team nicht weiss, wohin die Reise geht, arbeiten alle in verschiedene Richtungen.
Lösung: Teile deine Roadmap mit dem gesamten Team und aktualisiere sie regelmässig.
Roadmap-Tools für Startups
| Tool | Kosten | Besonderheit |
|---|---|---|
| Notion | 0 EUR (Basis) | Flexibel, alles in einem |
| Linear | 0 EUR (Basis) | Modern, entwicklerfreundlich |
| Trello | 0 EUR (Basis) | Visuell, Kanban-Board |
| ProductBoard | Ab 20 EUR/Monat | Speziell für Produktmanagement |
| Coda | 0 EUR (Basis) | Flexibel wie ein Spreadsheet |
| GitHub Projects | 0 EUR | Direkt im Code-Repository |
| Miro | 0 EUR (Basis) | Visual Roadmaps, Workshops |
Für Startups in der Frühphase empfehle ich Notion oder Linear -- beides ist kostenlos und bietet genug Funktionalität für die ersten 12 Monate.
Von der Roadmap zur Umsetzung
Eine Roadmap ist nur so gut wie ihre Umsetzung. Hier ein paar Tipps:
Sprint-Planung
Arbeite in 2-Wochen-Sprints:
- Wähle die Top-Features aus der "NOW"-Spalte
- Brich sie in konkrete Aufgaben herunter
- Schätze den Aufwand (in Stunden oder Story Points)
- Weise Aufgaben zu
- Am Ende des Sprints: Was wurde geschafft? Was nicht? Warum?
Kapazitäts-Aufteilung
Eine bewährte Aufteilung für Startups:
| Bereich | Anteil | Beispiel (40h/Woche) |
|---|---|---|
| Neue Features | 50% | 20 Stunden |
| Bug-Fixes | 20% | 8 Stunden |
| Technische Verbesserungen | 20% | 8 Stunden |
| Exploration/Prototyping | 10% | 4 Stunden |
Feedback-Loop schliessen
Nach jedem Sprint oder Release: Welche Auswirkung hatte das neue Feature auf deine Metriken? Wurde das erreicht, was du erwartet hast? Dieser Feedback-Loop ist das Herzstuck der Lean Startup Methode.
Feature-Priorisierung und Product-Market-Fit
Die Feature-Priorisierung ist eng mit dem Product-Market-Fit verknüpft. Vor dem PMF sollte deine Priorisierung darauf abzielen, den Fit zu finden. Nach dem PMF geht es darum, den Fit zu stärken und zu skalieren.
| Phase | Priorisierungs-Fokus |
|---|---|
| Vor Problem-Solution-Fit | Features, die das Kernproblem besser lösen |
| Vor Product-Market-Fit | Features, die Retention und NPS verbessern |
| Nach Product-Market-Fit | Features, die Wachstum und Skalierung ermöglichen |
Wenn du noch keinen PMF hast, ist es oft besser, bestehende Features zu verbessern als neue hinzuzufügen. Mehr Features lösen selten das Grundproblem.
Fazit
Feature-Priorisierung ist keine einmalige Aufgabe -- es ist eine laufende Disziplin, die den Erfolg deines Startups massgeblich beeinflusst. Die besten Produkte sind nicht die mit den meisten Features, sondern die mit den richtigen Features.
Meine Top-3-Empfehlungen:
- Nutze ein Framework (starte mit RICE oder Value vs. Effort) statt aus dem Bauch zu entscheiden
- Sage öfter Nein als Ja -- jedes Feature, das du nicht baust, ist Kapazität für das, was wirklich zählt
- Aktualisiere deine Roadmap regelmässig -- mindestens alle 2 Wochen
Dein Ziel: Eine klare, fokussierte Roadmap, die dein Team auf die wichtigsten Dinge ausrichtet und dich Schritt für Schritt näher an den Product-Market-Fit bringt -- oder ihn verstärkt, wenn du ihn schon hast.
Dein nächster Schritt
Bei Startup Burgenland unterstützen wir dich bei der strategischen Feature-Priorisierung und Roadmap-Planung -- damit du deine begrenzten Ressourcen optimal einsetzt. Hol dir jetzt den Gründungszuschuss und mach deine Produktstrategie zum Wettbewerbsvorteil.
Dieser Beitrag ist Teil der Serie "MVP und Product-Market-Fit" auf Startup Burgenland. Alle Beiträge findest du in unserem Blog.
Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.