Written by:
Last Published:
5. November 2026
•
Der Product-Discovery-Prozess ist die kurze, strukturierte Phase vor der Entwicklung, in der Sie gemeinsam mit Ihrer Agentur entscheiden, was gebaut werden soll, in welcher Reihenfolge und zu welchen Kosten. Ist das nur eine höfliche Umschreibung dafür, schon vor dem Bauen Rechnungen zu stellen? Nein. Richtig durchgeführt, ist es eine überschaubare Investition, die Sie vor den weitaus höheren Kosten bewahrt, das Falsche zu entwickeln.
Stellen Sie es sich wie eine Baugrunduntersuchung vor, bevor das Fundament gegossen wird. Niemand zahlt gerne für ein Bodengutachten. Aber jeder ist froh darüber, wenn man dadurch verhindert, dass man später auf eine unterirdische Quelle unter dem Küchenboden stößt. Product Discovery erfüllt bei Software den gleichen Zweck: Sie deckt versteckte Probleme auf, solange deren Lösung nur ein Gespräch kostet und keinen kompletten Neuaufbau.
Dieser Leitfaden richtet sich an die Auftraggeber: Gründer, Product Owner oder Führungskräfte, die über Umfang und Budget entscheiden, nicht an die Entwickler selbst. Er erklärt den Prozess in der Praxis, nicht in der Theorie. Die hier beschriebene Version ist die Scoping-Session von Imaginary Cloud – Sie erhalten also Einblick in einen echten, bewährten Prozess und keine allgemeine Theorie.
Product Discovery verwandelt eine Idee in konkrete Entscheidungen, bevor Geld in die Programmierung fließt. In einer Scoping-Session arbeiten Projektmanager, Entwickler und Designer gemeinsam mit Ihrem Team in drei Phasen (Business Case, Nutzerperspektive und technischer Plan). Am Ende erhalten Sie einen definierten Projektumfang, priorisierte Funktionen, Personas, eine Architektur auf hoher Ebene, identifizierte Abhängigkeiten, einen Projektplan und eine Kostenschätzung. Der Wert liegt in dem, was verhindert wird: unkontrolliertes Ausufern des Projektumfangs (Scope Creep), unzuverlässige Schätzungen und böse Überraschungen zum Ende hin. Der beste Test für eine gute Discovery ist die Frage, ob ein anderes Team allein auf Basis dieser Ergebnisse das Produkt bauen könnte.
Product Discovery ist der Prozess, bei dem vor Beginn der Entwicklung entschieden wird, was gebaut werden soll und ob es überhaupt gebaut werden sollte. In Zusammenarbeit mit einer Agentur ist dies ein kurzer, strukturierter Prozess, der eine Idee in einen Leistungsumfang, eine priorisierte Feature-Liste, einen technischen Ansatz und eine Kostenschätzung verwandelt.
Was bedeutet Product Discovery also in einfachen Worten? Es ist die entscheidungsfindende Hälfte der Produktentwicklung. Teresa Torres von Product Talk beschreibt es als einen Entscheidungsprozess, getrennt von der Delivery, also dem eigentlichen Bauen, Ausliefern und Warten. Marty Cagan beschreibt in seinen Beiträgen für die SVPG die Ziele der Discovery als die Klärung, ob echte Nutzer das Produkt wollen und ob man etwas bauen kann, das nutzbar, nützlich und machbar ist.
Und was es nicht ist: Es ist kein Design (auch wenn Design einfließt). Es ist kein Angebot (auch wenn am Ende eine Kostenschätzung steht). Und es ist keine Garantie dafür, dass die Idee gut ist.
Manchmal ist das wertvollste Ergebnis ein klares „Noch nicht“. Das ist ein Erfolg, kein Scheitern.
Sie brauchen kein ausgefeiltes Briefing. Sie brauchen ehrliche Antworten auf eine Handvoll Fragen: Welches Problem lösen Sie für wen, unter welchen Rahmenbedingungen und wer trifft die Entscheidungen? Je mehr davon Sie im ersten Gespräch klären können, desto weniger Annahmen fließen in den Leistungsumfang ein.
Nichts davon ist eine formale Zugangsvoraussetzung. Es ist lediglich das Material, auf dem das Gespräch aufbaut. Bringen Sie mit, was Sie haben, und sagen Sie offen, was Sie noch nicht wissen.
Noch ein Punkt zur Vorbereitung, und der ist kein Dokument: Stellen Sie sich darauf ein, herausgefordert zu werden. Eine gute Discovery-Session hinterfragt die Idee, und ein Unternehmen, das dafür offen ist, profitiert deutlich mehr davon.
Die Scoping-Session von Imaginary Cloud besteht aus drei Phasen: Analyse, Discovery und Planung. Sie bringt Projektmanager, Entwickler und Designer zusammen und führt vom Business Case über den Nutzer hin zum technischen Plan.
Die Session basiert auf einem nutzerzentrierten Ansatz, der Projektmanagement-Planung mit der Expertise von Entwicklern und Designern verbindet. Hier erfahren Sie, was die einzelnen Phasen beinhalten, was Sie tun und was Sie daraus mitnehmen.
Das Team beginnt mit der Idee selbst. Gemeinsam klären Sie die geschäftlichen Anforderungen, legen den Zeitplan fest, listen die wichtigsten Wettbewerber auf, skizzieren grobe Personas (fiktive, aber datenbasierte Profile Ihrer typischen Nutzer) und definieren die Hauptziele. Hier kommen die Fragen aus Ihrer Vorbereitungsliste zum Einsatz.
Was Sie tun: die Idee, die Ziele und die Rahmenbedingungen erläutern und die kritischen Fragen zum Business Case beantworten.
Was damit erreicht wird: der Business Case und die Ziele, die den Rahmen für die nächsten beiden Phasen bilden.
Nun verlagert sich der Fokus vom Unternehmen auf die Menschen, die das Produkt nutzen. Ihr Team und unseres erstellen gemeinsam Nutzer-Personas, um zu verstehen, wie diese mit dem Produkt interagieren werden. Anschließend listen und priorisieren wir User Stories – kurze Beschreibungen dessen, was ein Nutzer tun muss und warum. Die Gewichtung basiert auf der Lebenszyklusphase des Produkts sowie auf Nutzer- und Produktzielen. Das Ergebnis bildet die Grundlage für den Entwicklungsplan.
Was Sie tun: bringen Sie Ihr Wissen über Ihre Nutzer ein und beteiligen Sie sich an der Priorisierung. Hier entscheiden Sie, was am wichtigsten ist und was warten kann.
Was dabei entsteht: Nutzer-Personas sowie priorisierte User Stories und Funktionen.
In der letzten Phase werden Prioritäten in einen technischen Ansatz überführt. Das Team identifiziert und priorisiert die Hauptfunktionen, entwirft eine technische Lösung, die Komplexität und Reichweite abwägt, und erfasst externe Abhängigkeiten von Drittanbietern, wie etwa für Zahlungsabwicklungen, Social Login und Cloud-Dienste.
Was Sie tun: Prioritäten bestätigen, Einschränkungen bei Tools und Infrastruktur aufzeigen und auf den vorgeschlagenen Ansatz reagieren.
Was dabei entsteht: eine Architektur auf hoher Ebene, eine Liste der Abhängigkeiten von Drittanbietern sowie ein Projektplan mit Zeitplanung und Kostenschätzung.
Imaginary Cloud legt keine feste Dauer für die Scoping-Session fest, was sinnvoll ist, da dies davon abhängt, wie klar Ihre Idee ist und wie komplex das Produkt ausfällt. Zur Orientierung: Das Service Manual der britischen Regierung besagt, dass eine Discovery-Phase typischerweise etwa vier bis acht Wochen dauert – kürzer bei bekannten Problemstellungen, länger bei neuen. Diese Richtlinie ist für öffentliche Dienste geschrieben, betrachten Sie sie daher als Anhaltspunkt, nicht als Versprechen. Fragen Sie Ihre Agentur nach einem Zeitplan, der speziell auf Ihr Projekt zugeschnitten ist.
Ein guter Product-Discovery-Prozess endet mit Dokumenten, auf deren Grundlage Sie das Produkt entwickeln oder an ein anderes Team übergeben könnten. Sie sollten einen Projektumfang und eine Roadmap, priorisierte Funktionen und User Stories, Personas, eine Architektur auf hoher Ebene, eine Liste der Abhängigkeiten, einen Projektplan sowie eine Kostenschätzung erhalten.
Diese Liste entspricht dem, was die Scoping-Session von Imaginary Cloud liefert. Um die Qualität zu beurteilen, nutzen Sie den sogenannten Übergabetest: Könnte ein anderes, kompetentes Team diese Dokumente lesen und das Produkt kalkulieren und entwickeln, ohne ein einziges klärendes Gespräch führen zu müssen? Wenn die Antwort nein lautet, fehlt etwas oder die Angaben sind zu vage. Führen Sie diese vier Prüfungen durch, bevor Sie das Ergebnis als abgeschlossen betrachten:
Eine gute Discovery sorgt zudem dafür, dass sich Ihr eigenes Team einig ist. Achten Sie auf Ergebnisse, die von den Stakeholdern abgenommen werden können, wie etwa eine vereinbarte Prioritätenliste und eine gemeinsame Definition des ersten Releases. Wenn sich die Geldgeber des Projekts und die Nutzer des Produkts nicht darüber einig sind, was „fertig“ bedeutet, ist die Discovery der kostengünstigste Zeitpunkt, um dies herauszufinden.
Dann hat die Discovery ihren Zweck erfüllt. Eine Discovery, die zu dem Ergebnis „nicht wie geplant“ oder „noch nicht“ führt, erspart Ihnen die Kosten, dies erst während der Entwicklung festzustellen. Sie haben dann die Wahl: den Projektumfang anpassen, zunächst eine kleinere Version testen oder das Projekt beenden.
Die Richtlinien der britischen Regierung betonen denselben Punkt: Eine Discovery endet mit der Entscheidung, ob man fortfährt – und ein Abbruch an diesem Punkt ist ein legitimes Ergebnis. Auch das, was Sie behalten, ist wertvoll. Die Forschungsergebnisse, Personas, Prioritäten und technischen Erkenntnisse bleiben bei Ihnen und verkürzen in der Regel den nächsten Anlauf.
Vereinbaren Sie dies im Voraus. Fragen Sie Ihre Agentur, was passiert, wenn die Discovery die Richtung des Projekts ändert und wie der nächste Schritt definiert und kalkuliert wird.
Die Discovery schützt Ihr Budget, indem sie Unbekanntes in Entscheidungen verwandelt, bevor die Ausgaben für die Entwicklung beginnen. Umfang, Prioritäten und technische Abhängigkeiten werden auf dem Papier festgelegt – wo Umplanungen kostengünstig sind – und nicht im Code, wo sie teuer werden.
Hier ist der Mechanismus in drei Schritten.
Erstens: Der Projektumfang bleibt stabil. Wenn Funktionen aufgelistet und nach Nutzer- und Produktzielen priorisiert werden, müssen sich „Wenn wir schon dabei sind“-Erweiterungen rechtfertigen. Der Aufwand fließt dorthin, wo er am meisten bewirkt.
Zweitens: Die Kostenschätzung basiert auf einer soliden Grundlage. Eine Kostenschätzung, die auf priorisierten Funktionen und einer definierten Architektur aufbaut, ist eine verlässlichere Geschäftsprognose als eine Schätzung basierend auf einem einseitigen Briefing. Imaginary Cloud beschreibt die frühe Planungsphase selbst als Methode, um Fokusbereiche zu identifizieren und zusätzliche Kosten sowie Verzögerungen zu vermeiden.
Drittens: Risiken werden frühzeitig erkannt. Ein Zahlungsanbieter, der Ihren Markt nicht unterstützt, eine Anmeldemethode, die Ihre Nutzer nicht verwenden, oder eine Funktion, deren Umsetzung weitaus komplexer ist als gedacht: All das lässt sich in der Planungsphase kostengünstiger aufdecken als im neunten Sprint.
Wir können Ihnen keine prozentuale Ersparnis versprechen, und wir wären bei jedem vorsichtig, der dies tut. Die Ersparnis hängt davon ab, wie viele Fehlentscheidungen durch die Discovery-Phase verhindert werden – und das lässt sich immer erst im Nachhinein beurteilen.
Was wir jedoch sagen können, ist, dass diese Logik seit Langem etabliert ist. Das Double Diamond-Modell, ein Design-Framework mit vier Phasen (Discover, Define, Develop und Deliver), stellt die ersten beiden Phasen vor die letzten beiden. Jakob Nielsens Forschung zur Usability plädiert für mehrere kleine Testrunden mit zwischenzeitlichen Überarbeitungen anstelle einer einzigen großen Studie.
Zwei öffentliche Fallstudien von Imaginary Cloud zeigen diese Methode in der Praxis, ohne Zahlen zu nennen, die auf ihren Seiten nicht explizit aufgeführt sind. Bei Aurora Analytica, einer Analyseplattform für klinische Studien, einigten sich Produktverantwortliche, Entwickler und Designer auf Funktionen und Prioritäten im Rahmen eines MVP-Ansatzes (Minimum Viable Product, die kleinste Version, mit der eine Idee an echten Nutzern getestet werden kann), und Designentscheidungen wurden auf ihre technische Machbarkeit geprüft. Bei VestaConnect, einer Plattform zur Pflegekoordination, wurde ein MVP mit Beta-Nutzern getestet, deren Feedback in die Roadmap einfloss, woraufhin das Produkt später von der Beta-Phase in ein Bezahlmodell überging. Weitere Informationen finden Sie in unseren Fallstudien und lesen Sie mehr über unseren MVP-Ansatz.
Für Führungskräfte ist Discovery eine Möglichkeit, Kapital in Etappen zu binden. Sie zahlen einen überschaubaren Betrag für fundiertere Informationen und entscheiden dann, ob die vollständige Umsetzung finanziert werden soll. Das senkt das Risiko, verbessert die Prognosegenauigkeit und kann die Zeit bis zum ersten Mehrwert verkürzen.
Hier erfahren Sie, wie sich dies auf die Anliegen eines Vorstands oder Finanzleiters übertragen lässt.
Um das Projekt in Ihrem Unternehmen zu rechtfertigen, nutzen Sie Ihre eigenen Zahlen. Was hat das letzte Projekt gekostet, bei dem während der Entwicklung die Richtung geändert werden musste? Was kostet ein verpasster Sprint an Teamzeit und entgangenen Einnahmen? Discovery beseitigt diese Risiken nicht, verlagert die Beantwortung der wichtigsten Fragen jedoch an den Punkt, an dem sie am kostengünstigsten ist.
Beurteilen Sie die Agentur nach dem, was Sie am Ende in den Händen halten, und nach der Art der Zusammenarbeit – nicht nach der Verkaufspräsentation. Lassen Sie sich die Ergebnisse schriftlich zusichern, finden Sie heraus, wer tatsächlich am Tisch sitzt, und klären Sie, was passiert, wenn die Discovery den ursprünglichen Plan ändert.
Unabhängig davon, welche Agentur in die engere Wahl kommt, trennen diese Fragen eine echte Discovery von einem langen Verkaufsgespräch:
Die Scoping-Sitzung von Imaginary Cloud wird von Projektmanagern und Entwicklern durchgeführt, wobei Designer die UX- und Interface-Arbeit übernehmen. Sie beinhaltet eine Kostenschätzung und einen Projektplan. Imaginary Cloud arbeitet dabei in zwei Modellen: Team-Erweiterung und Managed Projects.
Nicht jedes Projekt erfordert den vollständigen Product-Discovery-Prozess. Eine kleine, klar definierte Änderung an einem bestehenden Produkt erfordert vielleicht nur ein Gespräch, nicht drei Phasen. Das Risiko liegt am anderen Ende: eine vage Idee, die die Discovery überspringt und ihre Lektionen erst während der Entwicklung lernt.
Ein schlankerer Ansatz ist sinnvoll, wenn das Problem gut verstanden ist, die Nutzer bekannt sind, die Technologie vertraut ist und die Änderung begrenzt bleibt. Wenn Sie unsicher sind, fragen Sie die Agentur, welche Phasen Sie verkürzen können und welches Risiko dadurch bestehen bleibt.
Die häufigsten Fehler sind das Überspringen der Discovery, weil die Idee klar erscheint, die Behandlung der Schätzung als Festpreis, das Ausschließen von Entscheidungsträgern und das Verschweigen von Einschränkungen. Alle vier sind mit ein wenig Vorbereitung vermeidbar.
Product Discovery ist die Arbeit, bei der vor Beginn der Entwicklung entschieden wird, was gebaut werden soll und ob es überhaupt gebaut werden sollte. In Zusammenarbeit mit einer Agentur kombiniert dieser Prozess Geschäftsanalyse, Nutzerforschung und technische Planung zu einem Leistungsumfang, einer priorisierten Feature-Liste und einer fundierten Kostenschätzung.
Es ist die Phase zu Beginn eines Projekts, noch vor der Entwicklung, in der Sie Ihre Annahmen über das Problem, die Nutzer und den technischen Ansatz testen. Sie endet mit der Entscheidung, fortzufahren, anzupassen oder das Projekt zu stoppen, sowie mit den Unterlagen, die für die Planung der Umsetzung erforderlich sind.
Eine Scoping-Sitzung umfasst drei Phasen: Analyse des Business Case, Ermittlung von Nutzerbedürfnissen und Prioritäten sowie Planung der Architektur und des Projekts. Das Ergebnis ist ein Leistungsumfang mit Roadmap, priorisierten Funktionen und User Stories, Personas, einer Architekturübersicht, einer Liste von Abhängigkeiten, einem Projektplan und einer Kostenschätzung.
Agenturen verwenden unterschiedliche Begriffe für dasselbe Konzept: Discovery-Sprint, Workshop, Phase oder Scoping-Sitzung. Was zählt, ist das Ergebnis. Fordern Sie die Liefergegenstände schriftlich an und gleichen Sie diese mit der oben genannten Liste ab: Leistungsumfang, Prioritäten, Personas, Architektur, Abhängigkeiten, Plan und Kostenschätzung.
Das hängt von der Komplexität Ihres Produkts und dem Reifegrad Ihrer Idee ab. Imaginary Cloud nennt keine feste Dauer. Die Richtlinien der britischen Regierung für öffentliche Dienste geben einen typischen Rahmen von etwa vier bis acht Wochen an. Fragen Sie Ihre Agentur nach einem Zeitplan für Ihr Projekt.
Imaginary Cloud veröffentlicht keine Preise. Die Sitzung beinhaltet einen Zeitplan und eine Kostenschätzung für Ihr Projekt; ein Angebot können Sie über das Business-Development-Team anfordern. Die Kosten variieren je nach Umfang des Produkts, daher ist das Angebot die verlässliche Antwort.
Machen Sie den Übergabetest: Könnte ein anderes kompetentes Team auf Basis der Unterlagen ohne Rückfragen mit der Entwicklung beginnen? Prüfen Sie, ob die Funktionen priorisiert sind, Abhängigkeiten benannt wurden, die Schätzung ihre Annahmen offenlegt und die Sitzung mit einer klaren Entscheidung endet: fortfahren, anpassen oder pausieren.
Fragen Sie danach, was Sie erhalten und in welchem Format, wer teilnimmt, wie die Sitzung abläuft, worauf die Schätzung basiert, wer die Rechte an den Ergebnissen hält und was passiert, wenn sich der Plan ändert. Bitten Sie außerdem darum, mit einem Kunden zu sprechen, der denselben Prozess bereits durchlaufen hat.
Oft ja. Designs zeigen, wie das Produkt aussieht, aber nicht, ob der Umfang priorisiert ist, die Architektur solide ist oder die Abhängigkeiten von Drittanbietern erfasst wurden. Die Planungsphase deckt diese Punkte ab. Wenn Ihre Designs fundiert sind, kann die Discovery-Phase schlanker ausfallen, sollte aber nicht übersprungen werden.
Sie entscheiden, ob Sie fortfahren möchten. Wenn ja, bilden der Umfang, die Roadmap und der Projektplan die Grundlage für die Entwicklung. Imaginary Cloud arbeitet mit zwei Modellen: Team-Erweiterung, bei der Entwickler Ihrem Team beitreten, und Managed Projects, bei denen wir das Projekt intern mit unseren eigenen Prozessen umsetzen.
Der Product-Discovery-Prozess ist ein risikoarmer Weg, um herauszufinden, was Ihre Idee wirklich braucht und was dafür erforderlich ist. Wenn Sie ein Produkt im Sinn haben und sehen möchten, wie eine Scoping-Sitzung dafür aussehen würde, können Sie mehr über die Scoping-Sitzung lesen oder mit unserem Team sprechen. Bringen Sie Ihre Idee, die Rahmenbedingungen und die schwierigen Fragen mit. Wir liefern den Plan.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
