Product Discovery: Methoden, Ablauf und typische Fehler

Product Discovery ist die Arbeit, mit der ein Produktteam vor und während der Umsetzung klärt, welches Problem es lösen soll und ob eine Lösung wertvoll, bedienbar, technisch machbar und für das Unternehmen tragfähig ist. Das Ergebnis ist eine belegte Entscheidung: bauen, anpassen, weiter untersuchen oder nicht bauen.

Ein freigegebenes Budget beantwortet diese Fragen nicht. Entscheidend ist, auf welchen Annahmen Ihre Produktidee beruht und welche davon noch ungeprüft sind. Dieser Beitrag zeigt Ihnen den Ablauf in fünf Schritten, die passenden Methoden je Risiko und die Fehler, die Discovery wirkungslos machen.

Was ist Product Discovery?

Product Discovery macht offene Annahmen sichtbar und prüft sie, bevor Sie viel Umsetzungskapazität binden. Sie schafft eine Grundlage für nachvollziehbare Investitionsentscheidungen und senkt das Risiko, das Falsche zu bauen. Markterfolg garantiert sie trotzdem nicht.

Die wichtigsten Begriffe in Kürze:

Product Discovery: herausfinden, was sich zu bauen lohnt, und die Annahmen dahinter prüfen.
Product Delivery: die gewählte Lösung in guter Qualität umsetzen und betreiben.
Outcome: die Verhaltensänderung oder das Geschäftsergebnis, das Sie erreichen wollen. Ein Output ist dagegen das gebaute Feature.
Opportunity: ein unerfülltes Bedürfnis, ein Schmerzpunkt oder ein Wunsch von Kunden. So definiert es Teresa Torres.
Assumption Test: ein kleiner Test, der eine einzelne Annahme mit beobachtbarem Verhalten prüft.

Die Nielsen Norman Group beschreibt Discovery als vorgelagerte Phase, in der ein Team den Problemraum erforscht und das Problem eingrenzt. Wir fassen den Begriff etwas weiter: Er umfasst auch Lösungsideen und Assumption Tests und gehört ebenso zur Weiterentwicklung bestehender Produkte.

Zwei Begriffe klingen ähnlich und meinen etwas anderes. Jira Product Discovery ist ein Tool von Atlassian zum Sammeln, Priorisieren und Planen von Ideen. Im E-Commerce steht „Product Discovery“ außerdem für die Produktsuche im Shop.

Product Discovery vs. Product Delivery

Discovery begründet, ob und worin Sie investieren. Delivery setzt die gewählte Lösung zuverlässig um und bringt sie in den Betrieb.

Aspekt	Product Discovery	Product Delivery
Leitfrage	Welches Problem und welche Lösung rechtfertigen die Investition?	Wie setzen wir die gewählte Lösung zuverlässig um?
Tätigkeit	Probleme untersuchen, Alternativen vergleichen, Annahmen testen	Entwickeln, integrieren, testen, betreiben
Ergebnis	Begründete Entscheidung mit benannten Restrisiken	Nutzbare Produktänderung mit geprüfter Qualität
Maßstab	Lerngeschwindigkeit und Qualität der Evidenz	Vorhersagbarkeit und Qualität
Typische Artefakte	Problem Statement, Opportunity Solution Tree, Prototypen, Testergebnisse	Backlog, User Stories, Code, Releases

Beide Arbeiten hängen zusammen und laufen im selben Team. Ein gefülltes Backlog oder eine technische Spezifikation belegt noch keinen Nutzerwert. Umgekehrt liefert Delivery Erkenntnisse, die neue Discovery-Fragen aufwerfen.

Warum Product Discovery? Die vier Risiken nach Marty Cagan

Marty Cagan (SVPG) unterscheidet vier Risiken, die ein Produkt scheitern lassen können. Sie bilden das Raster für fast jede Discovery.

Risiko	Leitfrage	Typische Prüfmethode	Hauptverantwortung nach Cagan
Value	Kaufen Kunden die Lösung, nutzen Anwender sie?	Problem-Interviews, Verhaltensdaten, Nachfragetests	Product Management
Usability	Finden Nutzer heraus, wie sie die Lösung bedienen?	Aufgabenbasierter Usability-Test mit Prototyp	Product Design
Feasibility	Kann das Team die Lösung mit Zeit, Skills und Technologie bauen?	Technical Spike, Integrationsprüfung	Lead Engineer
Business Viability	Funktioniert die Lösung für Vertrieb, Recht, Partner, Finanzen und Marke?	Prüfung mit Fachbereichen, Wirtschaftlichkeitsrechnung	Product Management

Für Ihr Unternehmen entstehen daraus konkrete Fragen zu Datenschutz, Beschaffung, Vertrieb, Betrieb und Wirtschaftlichkeit. Das sind Anwendungen der vier Risiken und keine zusätzlichen Kategorien.

Die Reihenfolge ergibt sich aus Ihrer Lage. Beginnen Sie mit der offenen Annahme, deren Widerlegung Ihre Entscheidung am stärksten verändern würde. Cagan selbst hält das Value-Risiko meist für das schwierigste.

Ablauf: Product Discovery in fünf Schritten

Der folgende Ablauf ist ein Vorschlag, den Sie an Ihre Lage anpassen. Die ersten beiden Schritte entsprechen grob den Phasen Discover und Define im Double Diamond des Design Council. Die Schritte drei bis fünf führen von der Problemdefinition zur Entscheidung.

Ziel und Outcome klären
Den Problemraum erforschen
Problem definieren und Opportunity priorisieren
Lösungen entwickeln und riskante Annahmen testen
Entscheiden und mit Delivery verbinden

Schritt 1: Ziel und Outcome klären

Klären Sie Geschäftsziel, Zielgruppe, anstehende Investitionsentscheidung und Rahmenbedingungen. Trennen Sie dabei Output und Outcome.

Ein hypothetisches Beispiel: „Ein Self-Service-Portal bauen“ beschreibt einen Output. „Kunden schließen einen bestimmten Vorgang ohne Hilfe des Supports ab“ beschreibt den gewünschten Outcome.

Halten Sie den Discovery-Auftrag schriftlich fest: Outcome, Zielgruppe, anstehende Entscheidung, vorhandene Evidenz, offene Fragen und wer entscheidet. Ergänzen Sie Budgetgrenzen, Abhängigkeiten von bestehenden Systemen und verbindliche Vorgaben. Leiten Sie Erfolgskriterien aus Ihrer Ausgangslage ab. Pauschale Zielwerte aus anderen Unternehmen helfen dabei wenig.

Schritt 2: Den Problemraum erforschen

Verbinden Sie vorhandene Analytics, Supportanfragen und Prozessdaten mit Interviews und Beobachtungen. Daten zeigen, wo Vorgänge abbrechen. Gespräche zeigen, unter welchen Bedingungen das passiert.

Unterscheiden Sie Nutzer, Käufer, Freigebende und interne Stakeholder. Ihre Interessen können auseinanderliegen. Eine Anforderung aus dem Vertrieb ist deshalb noch kein Beleg für einen Nutzerbedarf.

Fragen Sie nach konkreten vergangenen Situationen. „Wie haben Sie den Vorgang zuletzt erledigt?“ liefert mehr Kontext als „Würden Sie ein Portal nutzen?“. Teresa Torres erklärt diesen Ansatz in ihrem Beitrag zu Story-Based Customer Interviews. Klären Sie früh, wie Sie Teilnehmende erreichen und den Datenschutz einhalten.

Schritt 3: Problem definieren und Opportunity priorisieren

Eine brauchbare Problemdefinition benennt Nutzer, Situation, Hindernis und Folge. Im Beispiel könnte sie lauten: Kunden können einen Vorgang nicht abschließen, weil ihnen der Bearbeitungsstatus fehlt, und rufen deshalb den Support an. Ob diese Erklärung stimmt, prüfen Sie an Ihren Research-Ergebnissen.

Bewerten Sie Opportunities nach ihrem Bezug zum Outcome, nach der Relevanz für Kunden und nach der vorhandenen Evidenz. Torres nennt dafür vier Gruppen von Faktoren: Größe der Opportunity, Markt, Unternehmen und Kunden. Verzichten Sie auf Punkteformeln, die mehr Genauigkeit vortäuschen, als Ihre Daten hergeben.

Schritt 4: Lösungen entwickeln und riskante Annahmen testen

Vergleichen Sie mehrere Lösungen für die gewählte Opportunity. Ein fehlender Bearbeitungsstatus erfordert nicht automatisch ein komplettes Portal. Eine Statusbenachrichtigung oder ein verbesserter bestehender Prozess könnte das Problem ebenfalls lösen.

Notieren Sie für jeden Ansatz die Annahmen zu Value, Usability, Feasibility und Viability. Halten Sie für jeden Assumption Test vorab fest:

welche Frage er beantworten soll,
welche Methode und welche Teilnehmenden oder Daten Sie nutzen,
woran Sie ein stützendes oder widersprechendes Ergebnis erkennen,
welche Entscheidung daraus folgt.

Ein bedienbarer Prototyp beweist weder Zahlungsbereitschaft noch technische Machbarkeit. Auch ein positives Ergebnis beseitigt nicht jede Unsicherheit, es senkt sie für die geprüfte Annahme.

Schritt 5: Entscheiden und mit Delivery verbinden

Am Entscheidungspunkt haben Sie vier Optionen: bauen, gezielt weiter untersuchen, den Ansatz ändern oder nicht bauen. Halten Sie fest, welche Evidenz die Entscheidung trägt und welche Unsicherheit bleibt.

Wenn Sie bauen, leiten Sie den MVP-Scope aus der priorisierten Opportunity und den getesteten Annahmen ab. Eine Sammlung aller Stakeholder-Wünsche ist kein MVP-Scope. Erste Akzeptanzkriterien beschreiben fachliches und technisches Verhalten. Im Beispiel: Kunden schließen den definierten Vorgang ab und erhalten eine eindeutige Bestätigung. Ist das Backend nicht erreichbar, zeigt das System keine Erfolgsmeldung und bietet einen nachvollziehbaren nächsten Schritt.

Zur Übergabe gehören Kontext, Research-Ergebnisse, Entscheidungen, Grenzen, offene Risiken und die geplante Erfolgsmessung. Das Team bleibt dasselbe. Wie aus einem validierten Ansatz ein erstes Produkt wird, zeigt unser Beitrag vom Prototyp zum KI-MVP.

Product Discovery Methoden: Welche Methode prüft welches Risiko?

Wählen Sie die Methode nach der offenen Frage, nicht nach ihrer Bekanntheit. Eine Methode kann mehrere Risiken berühren. Was Sie aus dem Ergebnis ableiten dürfen, hängt vom Testaufbau ab.

Methode	Wofür	Prüft vor allem	Schritt
Stakeholder-Interviews	Ziele, Rahmenbedingungen, frühere Versuche verstehen	Viability	1, 2
Story-Based Customer Interviews	Konkrete Situationen, Bedürfnisse und Schmerzpunkte erheben	Value	2
Daten- und Funnel-Analyse	Sehen, wo und wie oft ein Problem auftritt	Value	2, 3
Assumption Mapping	Annahmen sammeln und nach Risiko ordnen	alle	3, 4
Opportunity Solution Tree	Outcome, Opportunities, Lösungen und Tests verbinden	Value	3, 4
Usability-Test mit Prototyp	Beobachten, wo Nutzer scheitern	Usability	4
Nachfrage- oder Fake-Door-Test	Echtes Verhalten statt Zustimmung messen	Value	4
Technical Spike	Eine konkrete technische Unsicherheit klären	Feasibility	4
Wirtschaftlichkeits- und Fachbereichsprüfung	Kosten, Vertrieb, Recht und Betrieb klären	Viability	4, 5
A/B-Test	Klar abgegrenzte Varianten mit ausreichend Traffic vergleichen	Value, Usability	nach dem Start

Zwei Hinweise aus den Quellen: Höfliche Zustimmung zu einer Idee ist keine belastbare Nachfrage, denn Menschen bewerten Lösungen nach ihrem idealen Selbstbild, wie Torres beschreibt. Und ein isolierter technischer Versuch belegt noch nicht, dass Sie die gesamte Lösung betreiben können. Halten Sie deshalb fest, unter welchen Bedingungen Sie getestet haben.

Ein A/B-Test eignet sich für klar prüfbare Varianten, wenn genug Traffic vorhanden ist. Für frühe Produktideen ohne Nutzer ist er selten das passende Werkzeug.

Der Opportunity Solution Tree

Der Opportunity Solution Tree von Teresa Torres stellt dar, auf welchen Wegen ein Team ein gewünschtes Outcome erreichen kann. Er hat vier Ebenen:

Outcome an der Wurzel, möglichst ein Produkt-Outcome, das das Team beeinflussen kann.
Opportunities: Bedürfnisse, Schmerzpunkte und Wünsche aus Kundeninterviews.
Solutions: Lösungsideen für eine ausgewählte Opportunity.
Assumption Tests: Tests, mit denen das Team die Lösungen vergleicht.

Torres nennt Voraussetzungen: eine Vorstellung von Zielkunden und Wertversprechen, ein klares Outcome und einige story-basierte Interviews vor dem ersten Baum. Opportunities stammen aus echten Gesprächen. Oft entpuppt sich eine vermeintliche Opportunity als verkleidete Lösung. Ihr Prüfstein dafür: Gibt es mehr als einen Weg, das Bedürfnis zu erfüllen?

Der Baum macht Ihre Entscheidungslogik sichtbar, auch gegenüber Stakeholdern. Research und Priorisierung nimmt er Ihnen nicht ab.

Discovery-Phase, Continuous Discovery und Dual-Track Agile

Eine Discovery-Phase bereitet eine abgegrenzte Investitionsentscheidung vor. Sie passt, wenn vor einer größeren Freigabe wesentliche Fragen offen sind, etwa bei einem neuen Produkt, einem neuen Markt, einer Fusion oder einer neuen Regulierung. Diese Anlässe nennt auch die Nielsen Norman Group.

Continuous Discovery hält den Kontakt zu Kunden während der gesamten Produktentwicklung aufrecht. Torres empfiehlt Produktteams, mindestens wöchentlich mit Kunden zu sprechen. Mit einer Budgetfreigabe endet die Unsicherheit nicht.

Dual-Track Agile beschreibt, dass Discovery und Delivery parallel laufen. Jeff Patton betont, dass es zwei Arten von Arbeit sind und nicht zwei Teams. Discovery soll Ideen deutlich verändern oder verwerfen, und das Lernen geht nach dem Release weiter.

Die fünf Schritte dieses Beitrags lassen sich deshalb wiederholen. Ein technischer Test kann Fragen aufwerfen, die zurück zum Problemverständnis führen. Planen Sie solche Rückkopplungen ein, statt einen starren Phasenplan festzulegen.

Wer gehört ins Discovery-Team?

Das Product Trio verbindet Product Management, Design und Engineering. Product Management bringt Outcome, Priorisierung und Unternehmenskontext ein. Design konzentriert sich auf Nutzerverständnis und Interaktion. Engineering prüft technische Möglichkeiten, Grenzen und Alternativen. Entscheidend ist, dass diese Disziplinen gemeinsam lernen und Erkenntnisse nicht bei einer Person liegen bleiben.

In größeren Organisationen müssen weitere Beteiligte rechtzeitig mitwirken: Datenschutz, Informationssicherheit, Vertrieb, Support, Betrieb und betroffene Fachbereiche. Dazu kommt ein Sponsor, der Zugang zu Menschen und Daten verschafft und die Entscheidung verantwortet. Klären Sie vor dem ersten Test Entscheidungshoheit, Freigaben und Eskalationsweg.

Wie sich die Rollen im Alltag verteilen, hängt von Ihrer Organisation ab. Unsere Beiträge zu Product Owner vs. Product Manager und zu den Aufgaben eines Product Owners helfen bei der Abgrenzung.

Was leistet ein Product Discovery Workshop?

Ein Workshop ist ein Arbeitsformat innerhalb der Discovery. Er hilft, den Auftrag zu klären, Evidenz zu sortieren und riskante Annahmen zu priorisieren. Bringen Sie vorhandene Research-Ergebnisse, Produktdaten und Rahmenbedingungen mit. Am Ende sollten die Entscheidungsfrage, die offenen Annahmen, ein Testplan und die Verantwortlichkeiten feststehen.

Ohne Kontakt zu Nutzern oder andere belastbare Evidenz validiert ein Workshop kein Produkt. Einigkeit im Raum ersetzt keine Beobachtung echter Nutzer.

Was am Ende einer Product Discovery vorliegen sollte

schriftlich festgehaltenes Ziel und Outcome
definierte Zielgruppe und ein mit Evidenz belegtes Problem
priorisierte Opportunities und die betrachteten Lösungsalternativen
getestete Annahmen mit Ergebnis und Aussagegrenzen
eine nachvollziehbare Entscheidung und benannte Verantwortliche für Restrisiken
bei „bauen“: MVP-Scope, ausdrückliche Nicht-Ziele, erste Akzeptanzkriterien und ein Plan, wie Sie das Outcome nach dem Release messen
bei „nicht bauen“: die Begründung und die Bedingungen, unter denen Sie neu bewerten

Typische Fehler in der Product Discovery

Fehler	Folge	Besser
Mit einem fertigen Feature starten	Das eigentliche Problem bleibt ungeprüft	Zuerst Outcome und Problemhypothese formulieren
Stakeholder-Zustimmung als Nutzerevidenz werten	Entscheidung am Bedarf vorbei	Interne Anforderungen und Nutzerbeobachtungen trennen
Methoden nach Beliebtheit wählen	Das größte Risiko bleibt offen	Mit der Annahme beginnen, an der die Entscheidung hängt
Nur Usability testen	Value und Viability bleiben ungeklärt	Jedes der vier Risiken bewusst prüfen oder begründet zurückstellen
Engineering spät einbinden	Integrationsprobleme zeigen sich erst in der Delivery	Kritische Abhängigkeiten vor der Lösungswahl untersuchen
Kriterien erst nach dem Test festlegen	Ergebnisse werden passend interpretiert	Erfolgskriterien und Konsequenzen vorab notieren
Ohne Entscheidungsfrage weiterforschen	Discovery wird zur Dauerschleife	Die fehlende Evidenz konkret benennen und zeitlich begrenzen
Ergebnisse ohne Belege übergeben	Scheinsicherheit in Delivery	Aussagegrenzen und Restrisiken mit übergeben
Discovery nach der Freigabe beenden	Neue Unsicherheiten bleiben unbemerkt	Kundenkontakt und Messung nach dem Release fortsetzen

Wie viel Discovery ist angemessen?

Die Tiefe richtet sich nach dem Risiko und danach, wie viel Zeit Ihnen bleibt.

Torres gibt eine Faustregel: Teams, die neu in der Discovery sind, schätzen Risiken noch schlecht ein und sollten etwas mehr Discovery machen, als sie für nötig halten. Patton empfiehlt, einzelne Tests auf Stunden bis wenige Tage zu begrenzen, damit die Kosten nicht davonlaufen.

Häufige Fragen

Wie lange dauert Product Discovery?

Eine feste Dauer gibt es nicht. Sie hängt davon ab, wie groß die Unsicherheit ist, wie schnell Sie Nutzer erreichen, welche Daten vorliegen und wie weitreichend die Entscheidung ist. Legen Sie statt einer Dauer die Entscheidungsfrage fest und begrenzen Sie einzelne Tests zeitlich.

Wer ist für Product Discovery verantwortlich?

Meist führt ein Product Trio aus Product Management, Design und Engineering die Discovery. Nach Marty Cagan verantwortet das Product Management das Value- und das Viability-Risiko, das Design das Usability-Risiko und das Engineering das Feasibility-Risiko. Die Investitionsentscheidung trifft eine vorab benannte verantwortliche Person im Unternehmen.

Was ist der Unterschied zwischen Product Discovery und Design Thinking?

Beide überschneiden sich beim Problemverständnis und beim Prüfen von Lösungen. Design Thinking ist ein allgemeiner Innovationsansatz. Product Discovery richtet diese Arbeit auf eine konkrete Produktentscheidung aus und begleitet ein Produkt auch nach dem Start weiter.

Ist Jira Product Discovery dasselbe wie Product Discovery?

Nein. Jira Product Discovery ist ein Tool von Atlassian, mit dem Teams Ideen und Feedback sammeln, priorisieren und Roadmaps erstellen. Product Discovery ist die Arbeitsweise dahinter. Ein Tool kann sie unterstützen, Interviews und Assumption Tests ersetzt es nicht.

Brauchen auch kleine Features eine Product Discovery?

Nicht jedes Backlog-Item braucht eine eigene Discovery. Die Tiefe richtet sich nach dem Risiko. Bei kleinen, gut verstandenen Änderungen reicht oft eine kurze Prüfung. Sobald neue Zielgruppen, neue Probleme oder teure Annahmen im Spiel sind, lohnt sich gezielte Discovery.

Fazit: Eine belegte Entscheidung ist das Ziel

Product Discovery prüft, ob sich eine Investition lohnt, bevor sie groß wird. Klären Sie zuerst, welche Produktentscheidung ansteht, welche Annahme sie kippen könnte und welche Evidenz Ihnen fehlt. Wählen Sie die Methode nach dem größten offenen Risiko und halten Sie das Ergebnis so fest, dass Delivery damit arbeiten kann. Auch ein begründetes „nicht bauen“ ist ein gutes Ergebnis, denn es schützt knappe Umsetzungskapazität.

Wenn Sie vor einem neuen Produkt oder einem größeren Feature stehen, unterstützen wir Sie mit einem Product Discovery Sprint: Problem, Zielgruppe, Scope und MVP strukturiert klären, anschließend Anforderungen und Umsetzung. Mehr dazu auf unserer Seite Product Engineering, ein Gespräch können Sie direkt über das Kontaktformular anfragen.