Produktentwicklung / 03
Ein MVP braucht den ersten Kunden, keine kürzere Wunschliste.
Vierzig Funktionen stehen in der Tabelle. Zwanzig zu streichen fühlt sich wie Fortschritt an. Doch warum sollte jemand das Produkt morgen benutzen? Beginnen Sie mit der Aufgabe des ersten Kunden und dem Ergebnis, für das er wiederkommt.
Beschreiben Sie eine Transaktion
Ein beispielhaftes Buchungsprodukt: Ein Kunde findet einen freien Termin, reserviert, bezahlt und erhält eine Bestätigung; der Anbieter sieht eine verlässliche Buchung. Dieser Satz erklärt mehr als Dashboard, KI, Zahlungen und Benachrichtigungen.
Woran lässt sich die Idee prüfen? An der ersten abgeschlossenen Buchung, einem zweiten bezahlten Besuch oder einem Anbieter, der bleiben möchte? Wählen Sie ein Signal nahe am Kundenproblem. Registrierungen allein verraten darüber möglicherweise wenig.
Hypothese
Wer zahlt und welche Aufgabe soll erledigt werden?
Ablauf
Ein Weg von der Anfrage zum erreichten Ergebnis.
Pilot
Echte Nutzende; Fehler und manuelle Hilfe bleiben sichtbar.
Entscheidung
Auf Basis der Daten fortsetzen, ändern oder stoppen.
Beispiel für einen Buchungsdienst: Bei einem anderen Produkt zuerst die Hypothese ändern, dann den Funktionsumfang.
Prototyp, Pilot und erstes Produkt unterscheiden
Ein Prototyp zeigt, ob Menschen eine Idee oder Oberfläche verstehen. Er darf simulierte Daten verwenden und benötigt möglicherweise kein funktionierendes Zahlungssystem. Ein Pilot erprobt eine begrenzte Leistung mit echten Beteiligten und vereinbarter Unterstützung. Ein MVP muss die zentrale Kundenaufgabe unter den zugesagten Bedingungen abschließen können. Diese Ergebnisse sind verschieden. Werden sie im Angebot gleich bezeichnet, lassen sich weder Preise noch Abnahmekriterien sinnvoll vergleichen.
Beschreiben Sie die Entscheidung, die der erste Release ermöglichen soll. Bezahlt ein Anbieter für weniger Terminaufwand? Kommt ein Kunde für eine weitere Sitzung zurück? Legen Sie Teilnehmer, Zugang und Gegenbelege zur Hypothese fest. Eine große Registrierungszahl ist nicht automatisch aussagekräftig, wenn die Menschen die angebotene Leistung nie benötigen. Eine kleine Gruppe mit einer passenden Aufgabe kann wichtige Probleme sichtbar machen. Halten Sie bei der Auswertung fest, welche Unsicherheit durch den Versuch geklärt wurde und welche weiterhin besteht.
Die vollständige Aufgabe vor der Bildschirmliste zeichnen
Verfolgen Sie einen Nutzer vom ersten Kontakt bis zum versprochenen Ergebnis. Berücksichtigen Sie Vorgänge zwischen den Ansichten: eine verspätete Nachricht, eine Terminfreigabe durch den Anbieter oder eine noch offene Zahlung. Notieren Sie, was der Nutzer jeweils weiß und welche Information das Unternehmen zum Fortfahren benötigt. Eine Liste mit Anmeldung, Dashboard und Checkout verdeckt solche Zwischenzustände leicht, obwohl sie für das Vertrauen entscheidend sind.
Bei einem Buchungsprodukt ist die Anbieterseite genauso wichtig wie die Bestätigungsseite des Kunden. Der Anbieter muss Termin, Kontaktweg und Zahlungsstatus verlässlich sehen. Wenn die erste Version nur einen Anbieter und eine Leistung unterstützt, ist das eine nachvollziehbare Eingrenzung. Eine fehlende Wiederaufnahme nach einem Verbindungsabbruch ist dagegen eine Frage der Funktionsfähigkeit. Besprechen Sie den Ablauf mit beiden Seiten. Erst danach lässt sich entscheiden, welche Funktionen das zentrale Ergebnis unterstützen und welche für den ersten Lernschritt zurückgestellt werden können.
Manuelle Arbeit im Pilot ausdrücklich einplanen
Eine Person kann ungewöhnliche Terminwünsche bearbeiten, unsichere Dokumente prüfen oder den ersten Bericht vorbereiten. Machen Sie diese Arbeit im Leistungsumfang sichtbar. Wer übernimmt sie, wie gelangt der Vorgang zu dieser Person und welchen Status sieht der Kunde? Bewusst geplante Handarbeit kann eine teure Verwaltungsoberfläche zunächst ersetzen. Verdeckte Handarbeit führt dagegen zu falschen Annahmen über Kosten, Kapazität und die Reife des Produkts.
Erfassen Sie Häufigkeit und Dauer der Eingriffe. Muss der Gründer jede normale Buchung reparieren, liegt ein Problem im Kernablauf vor. Tritt ein Sonderwunsch selten auf und lässt sich rasch bearbeiten, kann seine Automatisierung warten. Bewahren Sie trotzdem eine klare Struktur: Status, Zuständigkeit und Verlauf sind hilfreicher als private Chatnachrichten. So kann der manuelle Schritt später ersetzt werden. Der Pilot soll zeigen, wo eine Investition sinnvoll ist; er sollte nicht durch unsichtbare Zusatzarbeit erfolgreicher aussehen, als der Betrieb tatsächlich ist.
Seitlich scrollen, um alle Spalten zu sehen.
| Funktion | Entscheidung für den Piloten | Abnahmeprüfung |
|---|---|---|
| Terminauswahl und Buchung | Vollständigen Ablauf entwickeln | Zwei Personen können nicht denselben Termin buchen |
| Sonderfälle bei Umbuchungen | Manuell durch die Administration bearbeiten | Anfrage hat Zuständigkeit und sichtbaren Status |
| Zahlung, falls zur Nachfrageprüfung nötig | Zahlung serverseitig bestätigen | Wiederholte Meldung erzeugt keinen zweiten Kauf |
| Bonus- und Empfehlungsprogramm | Bis zur Prüfung der Kernnachfrage zurückstellen | Daten zeigen einen Bezug zu Wiederholungskäufen |
Web oder Mobile anhand der Aufgabe entscheiden
Eine responsive Webanwendung kann ausreichen, wenn jemand gelegentlich einem Link folgt und eine Aufgabe erledigt. Eine eigene mobile Anwendung ist eher begründet, wenn wiederholte Nutzung, Gerätefunktionen oder Offline-Arbeit das Erlebnis wesentlich verändern. Schreiben Sie diese Anforderungen vor der Framework-Diskussion auf. Der Wunsch nach einer „App“ kann zunächst bedeuten, dass ein Dienst auf dem Smartphone bequem erreichbar sein soll. Daraus folgt noch nicht zwingend die Pflege separater Store-Veröffentlichungen.
Vergleichen Sie auch Kontoeinrichtung, Freigaben, Geräteunterstützung, Updates und Support. Bei einer gemeinsamen Codebasis sollte das Angebot benennen, welche Teile dennoch plattformspezifisch bleiben und wie diese geprüft werden. Umgekehrt sollte eine browserbasierte Lösung keine wichtige Gerätefunktion nur unzuverlässig nachbilden. Prüfen Sie unsichere Fähigkeiten früh mit einem begrenzten technischen Versuch. Ein nachgewiesenes Verhalten auf dem vorgesehenen Gerät ist für die Architekturentscheidung oft hilfreicher als eine lange Liste allgemeiner Vorzüge einzelner Technologien.
Abhängigkeiten vor dem verbindlichen Termin prüfen
Hinter einer kleinen Oberfläche können Kalender, Zahlungsdienst, CRM und vorhandene Datenbanken stehen. Überprüfen Sie Zugriff, benötigte Operationen, Testumgebungen und Beispieldaten, bevor Integrationen als erledigt eingeplant werden. Ein vorhandener Connector unterstützt möglicherweise nicht genau den erforderlichen Schreibzugriff. Das Angebot sollte solche Annahmen offenlegen, besonders wenn Zugang oder Dokumentation von einer anderen Organisation abhängen und nicht durch die Entwicklungsagentur freigegeben werden können.
Bestimmen Sie das führende System für jeden Zustand und den Umgang mit widersprüchlichen Aktualisierungen. Was sieht das Kundenportal, wenn ein Termin direkt im Kalender abgesagt wurde? Was passiert, wenn eine Zahlungsnachricht früher als die Buchungsaktualisierung eintrifft? Nicht jede denkbare Störung braucht sofort einen komfortablen Verwaltungsdialog. Der Kernprozess benötigt aber einen sicheren Zwischenzustand und einen sichtbaren Weg zur Klärung. Solche Entscheidungen machen den Zeitplan belastbarer, weil die schwierigen Übergänge nicht bis zur Schlussabnahme verborgen bleiben.
Zugriffsrechte mit zwei normalen Konten testen
Legen Sie zwei gewöhnliche Testnutzer an und versuchen Sie, über das zweite Konto auf die Daten des ersten zuzugreifen. Prüfen Sie Oberfläche und Serverantwort. Ein ausgeblendeter Knopf ersetzt keine Berechtigungsprüfung beim Lesen oder Ändern der Daten. Leiten Sie Rollen aus den tatsächlichen Aufgaben ab, etwa Kunde, Anbieter und Administration. Das erste Modell darf einfach sein, muss aber die vorgesehenen Grenzen bei relevanten Aktionen zuverlässig durchsetzen.
Nehmen Sie Wiederherstellung des Kontozugangs, Einladungen und Entzug von Berechtigungen in die Abnahme auf. Ein Mitarbeiter kann das Unternehmen verlassen oder eine Einladung an eine falsche Adresse gehen. Wie reagiert das Produkt, ohne andere Datensätze zugänglich zu machen? Wer darf für Supportzwecke Daten sehen, und wie wird dieser Zugriff kontrolliert? Das sind normale Produktanforderungen. Eine geringe Anzahl von Funktionen rechtfertigt keine unklaren Grenzen zwischen Nutzern, Organisationen und den Informationen, die ihnen anvertraut wurden.
Zahlungen unabhängig vom Browser bestätigen
Ein Kunde kann den Checkout schließen, die Verbindung verlieren oder die Seite während der Verarbeitung aktualisieren. Das Produkt benötigt einen Zahlungsstatus, der mit dem Zahlungsdienst abgeglichen werden kann. Eine Erfolgsmeldung im Browser allein ist keine ausreichende Grundlage für nachfolgende Leistungen. Unterscheiden Sie offene, erfolgreiche und fehlgeschlagene Vorgänge so, dass der Kunde den nächsten Schritt versteht. Solange ein früherer Versuch noch geprüft wird, sollte nicht unbedacht eine weitere Zahlung angeboten werden.
Nutzen Sie die dokumentierten serverseitigen Benachrichtigungen und prüfen Sie deren Herkunft. Die Verarbeitung muss mit wiederholten Nachrichten und geänderter Reihenfolge umgehen können. Kontrollieren Sie anschließend Bestellung und Buchung, nicht nur die technische Antwort des Endpunkts. Für Rückzahlungen und unklare Fälle braucht es einen Betriebsweg, auch wenn während des Piloten ein Mensch zuständig ist. Eine verständliche manuelle Klärung ist nützlicher als ein aufwendig gestalteter Checkout, dessen Zahlungszustand der Support später nicht erklären kann.
KI dort prüfen, wo sie das Produktversprechen trägt
Soll das Produkt Dokumente interpretieren oder Fragen anhand einer Wissensbasis beantworten, gehört die Ergebnisqualität in die erste Abnahme. Stellen Sie repräsentative Eingaben zusammen und definieren Sie zulässige Ergebnisse sowie Fälle für Ablehnung oder Prüfung. Trennen Sie fehlende Quelleninformation, falsche Interpretation und fehlerhafte Folgeaktionen. Ein überzeugendes Einzelbeispiel zeigt noch nicht, dass das Produkt seine zentrale Aufgabe unter den vorgesehenen Bedingungen erfüllt.
Berücksichtigen Sie den Betrieb bei Unsicherheit. Wer prüft einen fraglichen Vorschlag, was kann der Kunde korrigieren und was geschieht beim Ausfall des Modelldienstes? Eine Warteschlange, eingeschränkte Antwort oder menschliche Unterstützung können geeignete Lösungen sein. Wählen Sie den Ersatzweg bewusst. Ist der Assistent nur eine zusätzliche Abkürzung zu einem ansonsten vollständigen Buchungsablauf, kann er später folgen. Entscheidend ist die Produkthypothese, nicht der Wunsch, eine KI-Funktion unabhängig von ihrem tatsächlichen Nutzen in die erste Version aufzunehmen.
Angebote mit derselben Abnahmegeschichte vergleichen
Geben Sie allen möglichen Entwicklungspartnern denselben kurzen Ablauf, dieselben Beispieldaten und dieselben beobachtbaren Ergebnisse. Lassen Sie Analyse, Gestaltung, Umsetzung, Integrationen, Tests und Übergabe getrennt erläutern. Abhängigkeiten und ausgeschlossene Leistungen müssen sichtbar sein. Zwei Gesamtsummen sind kaum vergleichbar, wenn eine Fehlerbehandlung und Betriebsanleitung enthält, während die andere lediglich eine Vorführung abdeckt. Klären Sie zuerst diesen Unterschied, bevor Sie über einen Rabatt auf einen unbestimmten Umfang sprechen.
Vereinbaren Sie den Entscheidungsweg im Projekt: Wer beantwortet Fachfragen, wer nimmt Ergebnisse ab und wie wird eine Änderung dokumentiert? Fordern Sie Zwischenlieferungen, die Fortschritt entlang der Kundenaufgabe zeigen. Ein technisch unklarer Punkt kann eine begrenzte Untersuchung vor einem verbindlichen Umsetzungspreis rechtfertigen. Reserven sollten sich auf benannte Unsicherheiten beziehen und klare Auslöser haben. So lässt sich über Budget sprechen, ohne die Schwierigkeiten zu verbergen oder jede spätere Nachfrage automatisch zu einer unbegrenzten Zusatzleistung zu machen.
Nach dem Start die ursprüngliche Entscheidung messen
Erfassen Sie die Schritte, die das Erledigen der Aufgabe belegen: gültige Anfrage, bestätigter Termin, erfolgreiche Zahlung oder erneute Nutzung. Unterscheiden Sie Versuche von Abschlüssen und vermeiden Sie doppelt gezählte Ereignisse. Schauen Sie sich Abbrüche im Zusammenhang mit der tatsächlichen Nutzung an. Eine unverständliche Preisangabe, eine verspätete Bestätigung oder ein technischer Fehler kann das Verhalten besser erklären als eine vermeintlich fehlende Zusatzfunktion.
Bleiben Sie bei der Auswertung an Hypothese und Teilnehmern. Eine kleine Stichprobe kann Bedienfehler zeigen, ohne breite Marktnachfrage zu beweisen. Halten Sie offene Fragen und die nächste notwendige Beobachtung fest. Erweitern Sie das Produkt, wenn Kundenverhalten oder Betriebskosten dafür einen nachvollziehbaren Grund liefern. Wird die Kernaufgabe nicht geschätzt, klären ein Empfehlungsprogramm oder weitere Dashboard-Grafiken dieses Problem meist nicht. Die erste Version soll dem Unternehmen helfen, bewusst über die nächste Investition zu entscheiden.
Umfang reduzieren, Zuverlässigkeit erhalten
Ein Kundentyp, eine Leistung, ein Ablauf. Sonderwünsche kann eine verantwortliche Person zunächst manuell bearbeiten. Empfehlungsprogramm, fünf Tarife und automatische Berichte dürfen warten.
Eingabeprüfung, Zugriffsrechte, Zahlungsstatus und Fehlerbehandlung bleiben Bestandteil des Kernablaufs. Öffnen Sie mit einem zweiten Konto eine fremde Buchung. Laden Sie während der Zahlung neu. Senden Sie zweimal ab. Eine Demo, die nur bei perfekter Bedienung funktioniert, ist kein belastbarer Kundentest.
Eine Mobile-App braucht einen Grund
Eine responsive Webanwendung kann genügen, wenn die Hauptaufgabe über einen Link beginnt. Eine iOS- und Android-App lohnt eine eigene Entscheidung, wenn Gerätefunktionen oder regelmäßige Nutzung das Erlebnis verändern. Schreiben Sie diese Anforderungen zuerst auf.
Dasselbe gilt für KI. Geht es zunächst nur um einen Termin, kann ein Assistent später folgen. Ist das Verstehen eines Dokuments der Produktkern, gehört die Auswertung seiner Antworten in die erste Version.
Die Übergabe gehört zum Auftrag
Klären Sie Eigentum an Domain, Repository, Hosting und Zahlungskonto. Planen Sie Datenexport, Sicherung und einen Meldeweg für Fehler ein. Am Montag nach dem Start muss jemand das Produkt betreiben können.
Beschreiben Sie die erste Version als kurzen Abnahmeablauf mit sichtbaren Ergebnissen. Spätere Ideen bekommen eine eigene Liste. Ausbauen können Sie, sobald Kunden zeigen, wofür sie zurückkommen.
Vor dem Start
- Ersten Kunden und seine vollständige Aufgabe benennen.
- Berechtigungen, unterbrochene Zahlung und doppelte Übermittlung testen.
- Zugriff auf Code, Konten und Betriebsdokumentation vereinbaren.
Redaktioneller Hinweis. Die Beispiele erläutern Entscheidungen oder Tests; sie sind keine Kundenergebnisse.