Bevor ein SaaS-Team sein MVP-Budget freigibt, entscheidet eine Frage darüber, ob das Geld gut angelegt ist: Wird der Kunde, für den es entwickeln will, tatsächlich zahlen? Product Discovery beantwortet diese Frage zuerst, und zwar mit Stakeholder-Interviews, Customer Journey Mapping und leichtgewichtigen Prototypen, die das Problem und einen klar umrissenen Käufer validieren, bevor auch nur eine Zeile Produktionscode entsteht. Sie dauert in der Regel 2 bis 6 Wochen.
Die Entscheidung liegt meist bei einem Head of Product, der ein neues Modul plant, oder bei einem Gründer mit einer finanzierten Idee und einem Launch-Termin. Sofort loszulegen fühlt sich schneller an, besonders jetzt, da KI-gestützte Entwicklung in kurzer Zeit eine funktionierende erste Version liefern kann. Eine schnelle Entwicklung hilft einer unvalidierten Idee jedoch nicht weiter: Ein SaaS-Produkt kann technisch sauber gebaut sein und trotzdem scheitern, wenn es für ein Kundenprofil entwickelt wurde, das niemand getestet hat. Die Discovery deckt das in der Prototypphase auf, wo ein Richtungswechsel nur Tage an Designarbeit kostet.
Was Product Discovery tatsächlich umfasst
Product Discovery beantwortet zwei Fragen in fester Reihenfolge. Erstens: Ist das Problem so schmerzhaft, dass jemand dafür bezahlt, es gelöst zu bekommen? Zweitens: Was ist das kleinste Produkt, das es für einen bestimmten Käufer löst? Redwerk behandelt diese Fragen als getrennte Schritte, denn ein Team, das die erste überspringt, entwirft am Ende eine Lösung für ein Problem, das es nur angenommen hat.
Stakeholder-Interviews
Das sind Gespräche mit den Menschen, die das Problem spüren, mit denen, die für die Lösung zahlen würden, und mit den internen Stakeholdern, die das Produkt verkaufen, betreuen oder integrieren müssen. Im B2B-SaaS-Mittelstand ist das selten dieselbe Person: Eine Operations-Leitung spürt den Schmerz, eine Finanzleitung unterschreibt den Vertrag, und die IT entscheidet, ob die Integration erlaubt ist.
Ziel sind Belege für Kaufabsicht, und die typische Falle besteht darin, sie mit Interesse zu verwechseln. Kaufabsicht zeigt sich im Verhalten, etwa wenn ein Interessent offenlegt, was ihn sein aktueller Workaround kostet, den Budgetverantwortlichen vorstellt oder einem bezahlten Pilotprojekt zustimmt.
Customer Journey Mapping
Eine Journey Map zeigt Schritt für Schritt, wie der Zielkunde das Problem heute löst: welche Tools er nutzt, wo Aufgaben zwischen Personen übergeben werden und wo Zeit verloren geht und Fehler entstehen. Bei einem SaaS-Produkt legt diese Map fest, woran das Produkt angebunden werden muss (das CRM, das Abrechnungssystem, die Tabelle, über die der halbe Prozess läuft). Außerdem zeigt sie den einen Schritt, bei dem Software am meisten Aufwand spart, und genau dieser Schritt wird zum Kern des MVP.
Leichtgewichtige Prototypen
Klickbare Wireframes oder ein einfaches interaktives Mockup werden denselben Personen vorgelegt, die interviewt wurden. Ein Prototyp prüft, ob der vorgeschlagene Workflow für den Nutzer sinnvoll ist, bevor jemand Backend-Code schreibt, und eine Änderung kostet ein paar Tage Designarbeit. Denselben Workflow nach dem MVP-Release zu ändern, bedeutet dagegen, Datenbank, API und Oberfläche zu überarbeiten.
Methoden zur Validierung von SaaS-Ideen, die Interesse von Kaufabsicht trennen
Die Validierung von SaaS-Ideen ist der Teil der Discovery, der aus Interviews belastbare Belege macht, auf deren Grundlage ein Budgetverantwortlicher entscheiden kann. Dieselben Methoden funktionieren für ein neues Modul innerhalb einer etablierten Plattform ebenso wie für die Micro-SaaS-Ideen, die ein kleines Team selbst auf den Markt bringen kann. Diese Methoden bewähren sich im B2B-SaaS am besten:
- Problem-Interviews vor dem Lösungs-Pitch. Fragen Sie, wie der Kunde das Problem heute löst und was es ihn an Stunden, Personal oder entgangenem Umsatz kostet. Beschreiben Sie das Produkt erst am Ende, wenn überhaupt.
- Verbindlichkeitstests. Eine Absichtserklärung, ein bezahltes Pilotprojekt, eine Design-Partner-Vereinbarung oder ein rabattierter Vorverkauf sind stärkere Belege als eine lange Liste begeisterter Interviews.
- Workaround-Audits. Wenn der Kunde bereits für eine Teillösung bezahlt oder rund um das Problem einen Tabellenprozess aufgebaut hat, ist der Schmerz echt und hat bereits ein Budget.
- Prototyp-Walkthroughs mit der tatsächlichen Nutzerrolle. Beobachten Sie, wie die Person, die das Produkt täglich nutzen würde, den klickbaren Ablauf ausprobiert. Die Stellen, an denen sie zögert, sind die Stellen, an denen der MVP-Umfang nachgeschärft werden muss.
- Ein Filter auf ein einziges Profil. Jede Erkenntnis wird an einem einzigen Zielkundenprofil gemessen. Feedback von außerhalb dieses Profils wird dokumentiert und für später zurückgestellt.
Was Dauer und Aufwand eines Discovery-Prozesses bestimmt
Die frühe Arbeit gliedert sich in zwei Phasen, die Problemvalidierung und die Lösungsgestaltung, die ersten beiden der sieben Phasen der SaaS-Produktentwicklung. Die Lösungsgestaltung ist der Kern des Discovery-Prozesses mit Stakeholder-Interviews, Journey Mapping und leichtgewichtigen Prototypen, und das Team ist klein: der Gründer (oder in einem etablierten Unternehmen der Product Owner), ein Produktstratege oder Business Analyst und eine UX-Leitung. Die meisten Discovery-Phasen bei Redwerk dauern 2 bis 6 Wochen, je nach Produktkomplexität, Integrationen und dem Umfang der Validierung, den die Idee noch braucht.
Problemvalidierung
Ein bestätigtes Problem, für dessen Lösung jemand zahlt
Gründer plus 1 bis 2 Fachberater aus der Branche
Interesse wird mit Kaufabsicht verwechselt
Lösungsgestaltung (Discovery)
Eine Werthypothese mit einem benannten Käufer
Gründer, Produktstratege oder Business Analyst, UX-Leitung
Das Produkt versucht, mehrere Kundenprofile gleichzeitig zu bedienen
MVP-Umfang und Entwicklung
Ein baubarer, testbarer Produktausschnitt
Product Owner, 2 bis 4 Entwickler, ein QA-Engineer, ein Designer
Zu viele Funktionen verlängern den Zeitplan vor dem Launch
Wo ein Discovery-Projekt innerhalb der Spanne von 2 bis 6 Wochen landet, hängt von vier Faktoren ab:
- wie viele Kundensegmente befragt werden (eines ist günstiger und besser, wie der nächste Abschnitt erklärt)
- wie ausgereift die Prototypen sein müssen
- mit wie vielen bestehenden Systemen das Produkt integriert werden muss
- ob Legacy-Code geprüft werden muss, bevor etwas Neues entworfen wird
Zeigt die Discovery, dass der gewählte Käufer nicht zahlen wird, hat das Team ein paar Wochen Arbeit eines kleinen Teams investiert, um das zu erfahren. Dieselbe Erkenntnis nach dem Launch bedeutet, dass das MVP-Budget aufgebraucht ist und das Produkt eine neue Richtung braucht.
Der häufigste Fehler in der Product Discovery
Der häufigste Fehler in dieser Phase ist der Versuch, drei verschiedene Kundenprofile gleichzeitig zu bedienen. Kaufmännisch wirkt das vernünftig, denn mehr potenzielle Käufer sehen nach mehr Umsatz aus, doch das Ergebnis ist ein mittelmäßiges Produkt für alle.
Zu viel Breite schadet der Validierung auf drei Arten:
- Die Signale aus den Interviews werden gemittelt. Drei Profile beschreiben drei verschiedene Probleme, und die daraus abgeleiteten Anforderungen passen zu keinem der drei genau.
- Das Feedback zum Prototyp fällt lauwarm aus. Jede Gruppe findet den Ablauf teilweise relevant, und das lässt sich leicht als vorsichtige Bestätigung missverstehen.
- Der MVP-Umfang wächst. Die unverzichtbaren Funktionen jedes Profils abzudecken, erhöht das Entwicklungsbudget und verzögert den Launch.
Um das eine Profil zu wählen, das zuerst validiert wird, achten Sie auf:
- den akutesten und häufigsten Schmerz
- einen Budgetverantwortlichen, den Sie während der Interviews tatsächlich erreichen können
- ein Segment, das eng genug ist, dass Sie die ersten zehn Unternehmen aufzählen könnten, an die Sie verkaufen würden
Die Eingrenzung fühlt sich an, als würde der Markt schrumpfen, doch sie ist eine Frage der Reihenfolge: Ein Produkt, das ein Segment gewinnt, kann in angrenzende Segmente expandieren, sobald die Kundenbindung zeigt, dass der Kern funktioniert.
Wie Product Discovery die SaaS-Entwicklung beschleunigt
Gründer und Produktverantwortliche sehen Discovery oft als Wochen, die vergehen, bevor die eigentliche Arbeit beginnt. Diese Zeit holt das Team in der Entwicklung wieder herein. Die SaaS-Entwicklungsleistungen von Redwerk beginnen mit einer Discovery-Phase, die Business-Analyse, Architektur, User Stories, erstes Design und den MVP-Umfang abdeckt, sodass die Entwicklung schneller vorankommt und das erste Release fokussiert und kosteneffizient bleibt.
Die Discovery entfernt die langsamste Art von Arbeit aus der Entwicklung, nämlich Entscheidungen mitten im Sprint:
- Architekturentscheidungen werden früh getroffen. Mandantenfähigkeit, Datenisolierung und das Abrechnungsmodell sind teuer zu ändern, sobald die ersten Kunden auf der Plattform sind. Die Discovery klärt sie, solange sie noch ein Diagramm sind.
- User Stories, die Entwickler schätzen können. Ein Team, das mit priorisierten Stories und einem abgestimmten MVP-Umfang startet, kann Aufwandsspannen nennen, die halten.
- Weniger überarbeitete Screens. Ein Workflow-Problem, das in einem klickbaren Prototyp auffällt, kostet eine Designrevision, dasselbe Problem nach dem Release kostet einen Sprint.
- Integrationsüberraschungen auf dem Papier entdeckt. Die Discovery erfasst die APIs und Systeme, von denen das Produkt abhängt, bevor sich das Team auf einen Zeitplan festlegt.
Sie brauchen für den Start auch keine vollständige Spezifikation. Die meisten Teams, die für eine Discovery zu Redwerk kommen, bringen eine Idee, einen Zielmarkt und eine Deadline mit, und die Spezifikation ist eines der Ergebnisse der Discovery.
Wann Sie die Discovery verkürzen oder auslassen sollten
Eine vollständige Discovery-Phase von 2 bis 6 Wochen ist in manchen Situationen die falsche Wahl:
- Sie haben bereits zahlende Kunden, die nach einer bestimmten Funktion oder einem Modul fragen, und die Aufgabe besteht darin, den Umfang festzulegen.
- Das Produkt ist ein internes Tool für eine bekannte Nutzergruppe, mit der Sie jederzeit sprechen können.
- Ein Vorverkauf oder ein bezahltes Pilotprojekt hat den Käufer bereits validiert, und es fehlt das technische Design.
In diesen Fällen decken ein kurzer Scoping-Workshop und ein Architektur-Review das Risiko ab. Eine vollständige Discovery lohnt sich, wenn der Käufer, das Problem oder die Lösungsgestaltung noch eine Annahme ist.
Von der Product Discovery zum MVP
Ein abgeschlossener Discovery-Prozess übergibt dem Entwicklungsteam ein Paket, und dessen Qualität entscheidet, wie schnell das MVP vorankommt. Bei Redwerk umfasst es in der Regel:
- ein klar benanntes Zielkundenprofil und eine daran getestete Werthypothese
- einen priorisierten MVP-Umfang
- einen Architekturentwurf und Technologieentscheidungen
- Integrationshinweise für jedes externe System, mit dem das Produkt arbeitet
- einen klickbaren Prototyp, der mit echten Nutzern validiert wurde
- eine Roadmap mit Aufwandsspannen für die Entwicklung
Einen genaueren Blick auf jedes dieser Dokumente und darauf, wie sie den Zeitplan verkürzen, bietet unser Artikel über Ergebnisse der Discovery-Phase, die die Entwicklungszeit verkürzen.
Manchmal lässt die Discovery eine technische Frage offen, etwa ob eine Drittanbieter-API die erwartete Last bewältigt oder ob eine KI-Funktion genau genug für den Produktivbetrieb ist. Ein kurzer Proof of Concept beantwortet sie, bevor die MVP-Entwicklung beginnt, sodass sich das Team auf den Entwicklungsplan festlegt und dabei weiß, dass der riskanteste Teil funktioniert.
Im nächsten Schritt wird dieser Umfang zu einem ersten Release. Unser Leitfaden zum SaaS-MVP zeigt, wie Sie das Minimum Viable Product bauen und zu einer vollständigen Plattform ausbauen.
Wie Redwerk Product Discovery für SaaS durchführt
Die Discovery ist die Phase der SaaS-Produktentwicklung, in der ein Irrtum am wenigsten kostet. Redwerk führt sie als erste Phase der SaaS-Produktentwicklung durch, mit eigenem Umfang, Team und Budget, und hat mehr als 250 Discovery-Projekte abgeschlossen. Ein Business Analyst oder Produktstratege arbeitet mit einer UX-Leitung zusammen, Sie sind über die Erkenntnisse aus den Interviews und das Feedback zum Prototyp durchgehend informiert, und das Projekt endet mit einem Entwicklungsplan, den Ihre Geschäftsleitung freigeben kann.
Wenn Sie eine SaaS-Idee haben und wissen möchten, ob sie trägt, bevor das Entwicklungsbudget gebunden ist, sprechen Sie mit Redwerk über eine Discovery-Phase.
FAQ
Was ist Product Discovery?
Product Discovery ist die Phase vor der Entwicklung, in der ein Team bestätigt, dass sich die Lösung eines Problems lohnt, einen Zielkunden auswählt und mit diesem Kunden eine Lösungsgestaltung testet. Sie umfasst in der Regel Stakeholder-Interviews, Customer Journey Mapping und leichtgewichtige Prototypen und endet mit einem priorisierten MVP-Umfang.
Wie lange dauert Product Discovery für ein SaaS-Produkt?
Die meisten Discovery-Phasen dauern 2 bis 6 Wochen. Die Dauer hängt von der Produktkomplexität, der Zahl der zu erfassenden Integrationen und dem Umfang der Validierung ab, den die Idee noch braucht.
Macht KI-gestützte Entwicklung Product Discovery überflüssig?
Nein. KI-Coding-Tools beschleunigen die Entwicklung, können Ihnen aber nicht sagen, ob ein Kunde zahlen wird. Eine schnellere Entwicklung bringt eine unvalidierte Idee früher auf den Markt, und genau das macht die Discovery noch nützlicher.
Was ist der Unterschied zwischen Product Discovery und einem MVP?
Die Discovery validiert Problem, Käufer und Lösungsgestaltung mit Interviews und Prototypen, ohne Produktionscode. Ein MVP ist das erste funktionsfähige Produkt, gebaut auf Basis des Umfangs, den die Discovery erarbeitet hat, und für echte Kunden veröffentlicht.
Brauche ich eine detaillierte Spezifikation, bevor die Product Discovery beginnt?
Nein. Die Spezifikation entsteht in der Discovery. Teams starten meist mit einer Idee, einem Zielmarkt und einer Reihe von Annahmen und schließen mit User Stories, einem Architekturentwurf und einem MVP-Umfang ab.
Erfahren Sie, wie wir AWE Learning geholfen haben, von einer lokalen Lösung in die Cloud zu migrieren und mit einer skalierbaren SaaS-Lösung Nutzer außerhalb der USA zu erreichen
