MoSCoW-Priorisierung:80 Feature-Ideen, 5 bauen

Du hast 80 Feature-Ideen – 50 eigene und 30 weitere, die deine Nutzer vorgeschlagen haben. Die MoSCoW-Priorisierung – Must have, Should have, Could have, Won't have – schrumpft diese 80 Ideen auf die 5 oder weniger Features, die deine Hypothese wirklich testen. Alles andere ist Ablenkung, und das meiste gehört in Won't have.

Obendrein haben Wettbewerber weitere 20 Features, die du nicht hast. Du kannst nicht alle bauen, und du solltest es auch nicht. Hier ist das Framework zum rücksichtslosen Kürzen – die Testfrage für jede Kategorie, wie gute und schlechte Priorisierung auf realen Zeitplänen aussehen, und die Regel, die verhindert, dass du Dinge baust, die du einfach von Hand erledigen könntest.

Was ist MoSCoW-Priorisierung für ein MVP?

MoSCoW sortiert jedes Feature in einen von vier Eimern, jeder mit einer einzigen Testfrage. Antworte ehrlich, und die Liste mit 80 Punkten fällt von selbst zusammen:

Beachte, was in diesem Beispiel den Muss-Test nicht besteht. Prioritätsstufen? Nutzer können die Liste manuell umsortieren. Kategorien und Tags? Nett, nicht zentral. Wiederkehrende Aufgaben? Die lassen sich von Hand anlegen. Ein Feature ist kein Muss, weil es nützlich ist – es ist ein Muss, weil deine Hypothese ohne es nicht testbar ist.

Du baust kein Minimum Viable Product

Du baust ein minimal testbares Produkt. Dieses Umdeuten ändert alles, denn es verankert jede Priorisierungsentscheidung an deiner Hypothese statt an deiner Vision. Die Vision ist für Version 10. Wenn du deine Hypothese nicht in einem Satz formulieren kannst, halte an und kläre das zuerst – sie ergibt sich direkt aus der Validierungsarbeit, die du geleistet hast, bevor du entschieden hast, irgendetwas zu bauen.

Und die „Wird nicht gebaut“-Liste ist der Ort, an dem die Disziplin lebt. Es ist kein Backlog – es ist eine Liste von Features, die du aktiv beschließt, nicht zu bauen, jedes mit einem schriftlichen Auslöser für eine erneute Prüfung: nach 100 Nutzern, nachdem V1 bewiesen ist, oder wenn Nutzer es fünfmal oder öfter anfragen. Den Auslöser aufzuschreiben, hält das Feature davon ab, in Woche zwei wieder in den Umfang zu schleichen.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Der zweite Durchgang: Wirkung gegen Aufwand

MoSCoW bringt dich von 80 auf eine Shortlist. Die Wirkung-gegen-Aufwand-Matrix bringt dich auf fünf. Bewerte jedes verbliebene Feature auf zwei Dimensionen – wie sehr es dem Nutzer hilft (1–10) und wie viele Tage der Bau ehrlich dauert –, und vier Quadranten erscheinen:

• Quick Wins (hohe Wirkung, geringer Aufwand): Das ist dein MVP.
• Große Projekte (hohe Wirkung, hoher Aufwand): Mach diese nach der Validierung, nie davor.
• Lückenfüller (geringe Wirkung, geringer Aufwand): Feinschliff, nur wenn Zeit bleibt.
• Zeitfresser (geringe Wirkung, hoher Aufwand): Baue sie nie – die eigene Reporting-Engine, die vielleicht zwei Nutzer wollen, das KI-Feature, nach dem niemand gefragt hat, komplexe Berechtigungen für Randfälle.

Sei skeptisch gegenüber deinen eigenen Zahlen. Gründer unterschätzen systematisch den Aufwand und überschätzen die Wirkung – also schlage auf jede Schätzung 50 % Puffer auf, hinterfrage jede 9-von-10-Wirkungsbewertung und halte die gesamte Bauzeit unter vier Wochen.

Mach es manuell, bevor du es baust

Stelle bei jedem Feature, das übrig bleibt, noch eine Frage: Kann ich das für die ersten 10 Nutzer manuell erledigen? Wenn ja, bau es noch nicht. Verschicke die E-Mail-Benachrichtigungen selbst. Baue den Wochenbericht in einer Tabelle. Begleite jeden Nutzer in einem persönlichen Gespräch beim Onboarding. Schreibe Rechnungen von Hand. Importiere ihre CSV für sie.

Manuell zuerst launcht schneller, lehrt dich, was Nutzer wirklich brauchen statt was sie sagen zu brauchen, und baut Beziehungen zu den frühen Nutzern auf, die am wichtigsten sind. Und es ist ein getarnter Nachfrage-Check: Wenn du dir nicht die Mühe machen willst, etwas für 10 Nutzer manuell zu tun, warum es dann für 1.000 bauen? Automatisiere erst, wenn du die Aufgabe über 10-mal manuell erledigt hast, sie jedes Mal mehr als 30 Minuten dauert, das Muster konsistent ist und Nutzer ausdrücklich danach fragen.

Wie gute und schlechte Priorisierung aussehen

Dieselbe Aufgabenmanager-Idee, zwei Scope-Entscheidungen. Die schlechte Version: wiederkehrende Aufgaben, Unteraufgaben, Tags und Kategorien, Zeiterfassung, Team-Sharing, eine mobile App, Kalenderansicht, Gantt-Diagramme – 90 Tage Bauzeit. Die gute Version: Aufgabe anlegen, Frist setzen, als erledigt markieren, einfache Listenansicht und ein täglicher E-Mail-Digest, manuell an die ersten 10 Nutzer verschickt – 14 Tage. In zwei Wochen statt drei Monaten ausgeliefert.

Die gestrichenen Features sind ohnehin nicht die wahren Kosten – das entgangene Lernen ist es. Ein CRM für Freelancer, gekürzt von einem Plan mit acht Features und 120 Tagen auf fünf Features (Kontakt hinzufügen, Notizen hinzufügen, Status taggen, einfache Suche, manueller CSV-Export), ging in 21 Tagen live, und die Nutzer offenbarten etwas, das keine Roadmap vorhergesagt hatte: Sie wollten gar kein Projektmanagement, sie wollten Follow-up-Erinnerungen. Ein Landingpage-Builder, gekürzt von einem 60-Tage-Plan auf fünf Templates, editierbaren Text und ein einfaches Formular, lernte, dass Nutzer mehr Templates wollten, nicht Anpassbarkeit. Neunzig zusätzliche Tage Bauzeit wären neunzig Tage gewesen, in denen das Falsche gebaut wird.

Die fünf Fallen, die deinen Scope wieder füllen

1. „Aber das ist zentral für unsere Vision." Die Vision ist für V10. Was ist zentral, um die Hypothese zu testen?
2. „Nutzer haben das erwähnt." Welche Nutzer? Wie schmerzhaft? Zahlen sie dafür? Eine Person, die zahlungsbereit ist, wiegt mehr als zehn „Wäre es nicht cool, wenn …"-Vorschläge.
3. „Es sind nur zwei zusätzliche Tage." Aus zwei Tagen werden mit Debugging zwei Wochen. Streich es; füge es später hinzu, wenn es sich als nötig erweist.
4. „Die Wettbewerber haben es." Die haben Jahre damit verbracht. Du testest, du konkurrierst nicht.
5. „Ohne das können wir nicht launchen." Doch, kannst du. Was ist das absolute Minimum?

Wenn deine finale Liste mehr als fünf Features hat, bist du mit dem Kürzen nicht fertig. Das beste Feature ist das, das du nicht baust: Jede Streichung liefert schneller aus, lernt schneller, kostet weniger und ist leichter zu warten. Dein Ziel ist nicht, ein Produkt zu bauen. Dein Ziel ist, eine Hypothese zu testen.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Häufig gestellte Fragen

Wofür steht MoSCoW?

Must have, Should have, Could have, Won't have. Jede Kategorie hat einen Test: Muss-Feature heißt, die Hypothese lässt sich ohne das Feature nicht testen; Soll-Feature heißt, Early Adopters würden das Produkt auch ohne es nutzen; Kann-Feature heißt, niemand würde aufhören, das Produkt zu nutzen, wenn es fehlte; Won't have heißt, es lenkt vom Kernnutzen ab und wird ausdrücklich gestrichen.

Wie viele Features sollte ein MVP haben?

Fünf oder weniger. Ist deine Liste länger, bist du mit dem Kürzen nicht fertig. Halte die gesamte Bauzeit unter vier Wochen, schlage auf jede Aufwandsschätzung 50 % Puffer auf und hinterfrage jedes „Muss" – die meisten Features gehören in Wird-nicht.

Was ist der Unterschied zwischen Muss und Soll?

Ein Muss-Feature ist ein Feature, ohne das du deine Kernannahme nicht testen kannst – entferne es, und das Experiment ist tot. Ein Soll-Feature verbessert das Erlebnis deutlich, aber Early Adopters würden das Produkt auch ohne es nutzen, daher wartet es bis nach der Validierung von V1.

Wann sollte ich einen manuellen Prozess automatisieren?

Erst wenn du ihn mehr als 10-mal manuell erledigt hast, er jedes Mal über 30 Minuten dauert, das Muster klar und konsistent ist und Nutzer ausdrücklich nach Automatisierung fragen. Bis dahin ist manuelle Arbeit billiger als Code – und sie lehrt dich, was Nutzer wirklich brauchen.