Eine erste Version sollte eine wichtige Aufgabe vollständig lösen. „MVP“ steht für „Minimum Viable Product“: ein möglichst kleiner, sinnvoll nutzbarer Produktumfang. Es geht darum, früh herauszufinden, ob die Lösung im Alltag hilft – mit einem Budget, das zur offenen Frage passt.

Wählen Sie einen Nutzer und ein klares Ergebnis

Angenommen, Sie planen eine Lern-App. „Lernen leichter machen“ ist als Ziel zu groß. „Lernende können eigene Karteikarten anlegen, üben und ihren Fortschritt wiederfinden“ beschreibt dagegen einen Ablauf, den man bauen und ausprobieren kann.

Eine Lehrkräfteverwaltung, Gruppen-Chats, Abonnements und automatisch erzeugte Lerninhalte könnten später sinnvoll sein. Für den ersten Test müssen sie nicht automatisch dazugehören. Entscheidend ist, welche Annahme Sie zuerst prüfen möchten: Nutzen Menschen die Lernmethode regelmäßig? Oder bezahlen Schulen für eine gemeinsame Verwaltung? Das führt zu unterschiedlichen ersten Versionen.

Teilen Sie Wünsche in drei Gruppen

  • Muss zum Start funktionieren: Ohne diese Funktion kann die wichtigste Aufgabe nicht erledigt werden.
  • Später sinnvoll: Die Funktion verbessert oder erweitert das Produkt, ist für den ersten Nutzertest aber nicht nötig.
  • Bewusst nicht geplant: Eine Funktion klingt passend, gehört jedoch nicht zu Ihrem Ziel oder Budget.

Diese Einteilung verhindert Missverständnisse. „Chat später“ bedeutet beispielsweise, dass ein Nachrichten-System nicht stillschweigend zum ersten Angebot gehört. Wenn neue Erkenntnisse die Prioritäten verändern, wird der Umfang vor der Umsetzung neu abgestimmt.

Denken Sie den kleinen Ablauf zu Ende

Auch ein kleines Produkt braucht klare Antworten auf alltägliche Fragen: Was sieht eine Person beim ersten Öffnen? Was passiert ohne Daten? Lassen sich Fehleingaben korrigieren? Bleiben wichtige Daten nach dem Schließen erhalten? Wie wird ein Fehler verständlich angezeigt?

Falls Konten dazugehören, müssen Sie außerdem festlegen, wer welche Daten sehen und ändern darf. Falls Zahlungen dazugehören, ist eine erfolgreiche Zahlung nur ein Teil des Ablaufs. Fehlgeschlagene oder abgebrochene Zahlungen brauchen ebenfalls ein vereinbartes Verhalten. Ein kleiner Umfang spart Funktionen, nicht die notwendigen Schritte innerhalb der gewählten Funktion.

Eine brauchbare Grenze für das Angebot

Statt „komplette Lernplattform“ könnte eine erste Version so beschrieben werden:

Eine Web-App für einzelne Lernende. Eigene Kartensätze anlegen, bearbeiten und üben. Fortschritt speichern. Eine Sprache. Noch keine Gruppen, Zahlungen oder automatisch erzeugten Inhalte. Wie Anmeldung und Speicherung gelöst werden, wird im Konzept festgelegt.

Das ist ein Beispiel für eine Eingrenzung, kein fertiges Paket oder Preisversprechen. Sobald Konten, ein Server oder mehrere Plattformen benötigt werden, muss das ausdrücklich in die Aufwandsschätzung einfließen.

Legen Sie vor dem Start fest, was Sie lernen möchten

Wählen Sie eine überschaubare Testgruppe und eine Frage, die Sie beantworten können: Schaffen die Testpersonen den Kernablauf ohne Erklärung? Kommen sie freiwillig wieder? Welche Stelle sorgt für Rückfragen? Notieren Sie Beobachtungen, bevor Sie weitere Funktionen beauftragen.

Sie brauchen für die Anfrage noch keinen perfekten Funktionskatalog. Eine Beschreibung des wichtigsten Ablaufs und eine Liste „Muss / später / nicht vorgesehen“ sind ein sehr guter Anfang. Unsere Briefing-Vorlage hilft beim Aufschreiben.