Product Discovery: Methoden richtig wählen und anwenden

Product Discovery ist die faktenbasierte Arbeit daran, herauszufinden, was sich zu bauen lohnt, bevor Sie es bauen. Am besten gelingt das mit Kundeninterviews und Beobachtung, Analysedaten, Wettbewerbs- und Geschäftsrecherche, technischer Recherche, dem Kartieren von Annahmen, Prototypen und Usability-Tests. Die eine richtige Methode gibt es nicht. Sie wählen nach der Unsicherheit, die Sie reduzieren müssen, und kombinieren dann zwei oder drei Methoden, damit eine Erkenntnisquelle die andere überprüft. Dieser Leitfaden zeigt, wie das geht, wie Sie einen Discovery-Workshop durchführen und wie Discovery neben der Umsetzung ihren Platz findet.

Kurz zusammengefasst

• Discovery ist ein Entscheidungsprozess: das Problem verstehen, Lösungen erkunden, sie testen und dann festlegen, was gebaut wird.
• Wählen Sie die Methoden nach dem Risiko. Interviews für Motivation, Analysedaten für Muster, technische Recherche für Machbarkeit, Prototypen für das Lösungsrisiko.
• Kombinieren Sie mindestens zwei Methoden (Triangulation), bevor Sie Budget für eine Umsetzung freigeben.
• Ein Discovery-Workshop braucht ein Ziel, eine Entscheidung, eine kleine Gruppe und datierte Fakten. Für die meisten ersten Sitzungen genügt eine Agenda von 90 Minuten.
• Discovery und Umsetzung sind keine aufeinanderfolgenden Abteilungen. Dasselbe Team sollte beides tun, und zwar laufend.

Was Product Discovery wirklich ist

Eine 2025 academic review of product discovery beschreibt Discovery als den Prozess, Bedürfnisse und Probleme von Nutzer:innen zu verstehen und zu überprüfen, mögliche Lösungen zu erkunden, sie zu testen und zu entscheiden, was gebaut wird. Entscheidend ist das Wort entscheiden. Discovery ist kein Forschungsprojekt, das in einer Präsentation endet. Es endet mit einer Wahl: so bauen, anpassen oder lassen.

Der discovery study guide der Nielsen Norman Group fasst es als Erforschen des Problemraums, das Eingrenzen der lohnenden Probleme und das Sammeln von genügend Belegen, um den nächsten Schritt zu kennen. Dort steht auch, dass Discovery meist drei Arten von Arbeit umfasst: Nutzerforschung, Geschäftsrecherche und Analyse sowie technische Recherche zu den verfügbaren Technologien und Möglichkeiten.

Diese Dreiteilung ist für Gründer:innen nützlich. Die meisten gescheiterten Produkte sind nicht an schlechtem Code gescheitert. Sie sind gescheitert, weil niemand geprüft hat, ob es Kund:innen interessiert, ob das Geschäftsmodell trägt oder ob die Technologie die Aufgabe zu vernünftigen Kosten erfüllen kann. Jedes davon ist eine eigene Frage, und jede braucht ihre eigene Methode.

Atlassian boils discovery down to four questions:

1. Werden Kund:innen die Idee schätzen und nutzen?
2. Kommen sie damit zurecht?
3. Kann die Entwicklung sie umsetzen?
4. Unterstützt sie die Geschäftsstrategie und die Bedürfnisse der Beteiligten?

Behalten Sie diese vier Fragen im Blick. Jede Methode weiter unten beantwortet eine oder mehrere davon.

Die wichtigsten Discovery-Methoden

Die folgende Liste ist nach der Art der Unsicherheit gegliedert, die jede Methode reduziert, nicht nach Mode. Sie werden nie alle in einem Projekt einsetzen.

Kundeninterviews und Beobachtung

Interviews sind der Ausgangspunkt fast jeder Discovery-Arbeit. Maze groups interviews with competitor analysis and product analytics als Weg, um in der Lernphase die Probleme und Schmerzpunkte der Nutzer:innen zu verstehen. NN/G ergänzt, dass explorative Forschung dieser Art discovery study guide ist. Das ist in Ordnung, solange Sie fünf Gespräche nicht als statistisches Ergebnis behandeln.

Praktische Regeln, die Zeit sparen:

• Fragen Sie nach vergangenem Verhalten, nicht nach künftigen Absichten. «Erzählen Sie mir vom letzten Mal, als Sie das getan haben» ist besser als «Würden Sie das nutzen?»
• Sprechen Sie mit Menschen, die das Problem jetzt haben, nicht mit solchen, die es eines Tages haben könnten.
• Halten Sie getrennt fest, was gesagt wurde, und was Sie darin sehen. Diese Unterscheidung wird im Abschnitt zum Workshop erneut wichtig.
• Beobachtung, also jemandem bei der Aufgabe im eigenen Umfeld zuzusehen, bringt oft Behelfslösungen ans Licht, die im Interview vergessen gehen.

Teresa Torres plädiert laut Mind the Product für at least weekly customer touchpoints durch das Team, das das Produkt baut, mit kleinen Forschungsaktivitäten auf ein gewünschtes Ergebnis hin. Für ein Startup ist das realistisch: ein bis zwei kurze Gespräche pro Woche kosten weit weniger als eine grosse Studie pro Jahr.

Analysedaten und Verhaltensdaten

Interviews sagen Ihnen, warum. Analysedaten sagen Ihnen, wie viele und wo. Wenn Sie bereits ein laufendes Produkt oder eine Website haben, schauen Sie, wo Nutzer:innen abspringen, welche Funktionen unberührt bleiben und wonach gesucht wird. Falls Sie noch kein Produkt haben, können Daten aus einem bestehenden Ablauf (Support-Tickets, Bestelldaten, Tabellenexporte) dieselbe Rolle übernehmen.

Die wissenschaftliche Übersicht führt Analysedaten neben Interviews und Beobachtung unter den zentralen Discovery-Methoden. Nutzen Sie Zahlen, um die Stellen zu finden, die eine genauere Prüfung verdienen, und gehen Sie dann zurück zu den Menschen, um sie zu verstehen.

Wettbewerbs- und Geschäftsrecherche

Die Wettbewerbsanalyse ist die günstigste Methode auf dieser Seite. Sie suchen nicht nach Dingen zum Kopieren. Sie suchen danach, wofür Kund:innen bereits bezahlen, welche Lücken die Konkurrenz offen lässt und welche Versprechen alle im Markt machen (und die deshalb nichts bedeuten). Die Geschäftsrecherche deckt die andere Seite ab: Stückkosten und Erträge, Preislogik, Verkaufszyklus, Regulierung und ob die Idee zur Strategie des Unternehmens passt, das sie trägt.

Das entspricht Atlassians vierter Frage. Eine Idee, die Nutzer:innen lieben, die das Unternehmen aber weder finanzieren noch betreiben kann, bleibt eine gescheiterte Idee.

Technische Recherche

Das ist die Methode, die am häufigsten übersprungen wird, und jene, bei der ein technischer Partner am meisten beitragen kann. Mind the Product weist darauf hin, dass technical feasibility is one uncertainty to check before committing to execution. In der Praxis heisst das:

• Sind die benötigten Daten tatsächlich zugänglich, und in welcher Qualität?
• Bieten die Systeme, an die Sie anbinden müssen (ein Shop, ein CRM, ein ERP), nutzbare Schnittstellen?
• Gibt es einen Machbarkeitsnachweis, der zeigt, dass der schwierige Teil funktioniert?
• Was würde der Betrieb kosten, nicht nur die Entwicklung?

Ein technischer Testlauf von ein bis zwei Tagen, der diese Fragen beantwortet, kann Monate an Nacharbeit verhindern. Er schärft auch den Umfang, weil Sie lernen, was günstig und was teuer ist, bevor Sie etwas zusagen.

Fünf Mal Warum und die Problemdefinition

Die wissenschaftliche Übersicht zählt Five Whys zu den etablierten Methoden. Sie nehmen ein genanntes Problem («Kund:innen brechen den Bestellvorgang ab») und fragen so lange warum, bis Sie bei einer Ursache ankommen, auf die Sie einwirken können. Das ist einfach und schnell, und es funktioniert am besten mit den Leuten, die das Problem täglich sehen, etwa im Support und im Verkauf. Behandeln Sie die Antworten als Hypothesen zum Prüfen, nicht als Schlussfolgerungen.

Die Problemdefinition ist der nächste Schritt: Schreiben Sie das Problem als einen klaren Satz über eine bestimmte Person in einer bestimmten Situation. Wenn sich das Team auf diesen Satz nicht einigen kann, hilft keine Funktionsliste.

Journey Mapping und Chancenkarten

Eine Journey Map legt die Schritte offen, die Kund:innen durchlaufen, samt dem, was sie bei jedem Schritt tun, denken und fühlen. Markieren Sie die Reibungspunkte. Eine Chancenkarte gruppiert diese Schmerzpunkte und unerfüllten Bedürfnisse anschliessend so, dass das Team sieht, welche Gruppe am grössten oder am teuersten ist. Beide Methoden machen das gemeinsame Verständnis sichtbar, weshalb sie in Workshops gut funktionieren.

Annahmen kartieren

Jede Idee beruht auf Annahmen: dass Kund:innen das Problem haben, dass sie zahlen, dass sie ihre Gewohnheiten ändern, dass die Anbindung funktioniert. Listen Sie sie auf und ordnen Sie jede auf zwei Achsen ein: wie wichtig sie für die Idee ist und wie wenig Belege Sie dafür haben. Die Annahmen in der oberen Ecke, wichtig und unbelegt, prüfen Sie zuerst.

Productboard empfiehlt, jede Lösungsidee auf four kinds of risk before committing to build zu prüfen: Nutzen, Bedienbarkeit, Machbarkeit und wirtschaftliche Tragfähigkeit. Wenn Sie jede Annahme mit einer dieser vier Bezeichnungen versehen, wird offensichtlich, zu welcher Methode Sie greifen sollten.

Ideen entwickeln und priorisieren

Sobald das Problem klar ist, entwickeln Sie mehrere mögliche Lösungen, nicht eine. Skizzieren Sie, sammeln Sie Ideen oder schreiben Sie kurze Lösungsbeschreibungen. Priorisieren Sie danach anhand der gesammelten Belege, nicht danach, wer am lautesten argumentiert hat. Eine einfache Bewertung nach Kundennutzen, Aufwand und Risiko genügt. Das Ziel ist eine kurze Liste prüfenswerter Optionen, kein sortierter Rückstand mit fünfzig Punkten.

Prototypen und Usability-Tests

Prototypen beantworten die Fragen, die Gespräche nicht klären können: Können Menschen das tatsächlich bedienen, und löst es das Problem so, wie sie es erleben? Ein klickbarer Entwurf, in wenigen Tagen gebaut, reicht oft aus, um den Hauptablauf mit fünf oder sechs Personen zu testen. Maze beschreibt die letzte Discovery-Phase als Maze groups interviews with competitor analysis and product analytics. Testen Sie zuerst den riskantesten Teil der Idee, nicht den hübschesten.

Methoden wählen und kombinieren

Die wissenschaftliche Übersicht sagt deutlich, dass die Wahl der Methode 2025 academic review of product discovery ist: Man sollte nicht annehmen, dieselbe Methode passe für jedes Produkt, jedes Team und jede Phase. Ein praktikabler Weg zur Entscheidung:

Wenn Ihre grösste Unsicherheit ist …	Beginnen Sie mit	Bestätigen Sie dann mit
Haben die Leute dieses Problem wirklich?	Interviews, Beobachtung	Analysedaten, Umfrage
Wie gross oder wie verbreitet ist es?	Analysedaten, vorhandene Daten	Interviews zur Erklärung der Muster
Werden sie unsere Lösung wählen?	Prototyp, Usability-Test	Ein kleines Experiment im Echtbetrieb
Können wir es zu vernünftigen Kosten bauen?	Technischer Testlauf, Machbarkeitsnachweis	Prüfung der beteiligten Systeme
Trägt die Geschäftsrechnung?	Wettbewerbs- und Preisrecherche	Gespräche mit möglichen Käufer:innen

Drei Grundsätze halten die Mischung ehrlich.

Passen Sie die Methode an die Phase an. Ganz am Anfang, mit wenig Belegen, nutzen Sie breite qualitative Methoden. Später, wenn eine konkrete Lösung vorliegt, wechseln Sie zu engeren Tests von Bedienbarkeit und Machbarkeit. Mind the Product vertritt die Ansicht, dass technical feasibility is one uncertainty to check before committing to execution. Wenn Sie das Problem, die Nutzer:innen und den technischen Weg bereits kennen, ist eine lange Discovery-Phase Verschwendung.

Triangulieren Sie. NN/G empfiehlt discovery study guide, um die Sicherheit zu erhöhen. Wenn Interviews sagen, eine Funktion sei wichtig, die Analysedaten aber zeigen, dass niemand das nächstliegende Gegenstück nutzt, haben Sie einen Widerspruch, den Sie vor der Umsetzung klären sollten.

Passen Sie sich Ihrem Umfeld an. Die wissenschaftliche Übersicht hält fest, dass die richtige Mischung von Produktart, Teamstruktur, Kultur und lokalen Rahmenbedingungen abhängt. Für Teams in der Schweiz heisst das: Planen Sie für Nutzer:innen in mehreren Sprachen, seien Sie klar darin, welches Schweizer Marktsegment Sie bedienen, und prüfen Sie früh, ob Datenschutz- oder Branchenvorgaben beeinflussen, wie Sie Forschungsdaten und Nutzerdaten erheben und speichern dürfen. Stellen Sie diese Fragen in der Discovery, wenn eine Änderung ein Gespräch kostet, und nicht nach dem Start.

Eine realistische erste Runde für ein Startup in der Seed-Phase: acht bis zehn Interviews, eine Prüfung von drei oder vier Mitbewerbern, ein halbtägiger technischer Testlauf zur riskantesten Anbindung und ein klickbarer Prototyp, getestet mit fünf Personen. Das sind ein paar Wochen Teilzeitarbeit, kein Quartal.

Einen Discovery-Workshop durchführen

Ein Workshop ist eine Methode, um mehrere Personen zu einer gemeinsamen Entscheidung zu bringen. Learning Loop empfiehlt ihn dann, wenn several people need shared understanding for a meaningful decision: bei der Wahl zwischen Chancen, bei widersprüchlichen Deutungen von Forschungsergebnissen, beim Offenlegen von Annahmen oder beim Festlegen des nächsten Lernschritts. Wenn eine Person allein entscheiden kann, lassen Sie den Workshop sein.

Vorbereitung vor dem Termin

• Ein Ziel und eine Entscheidung. «Entscheiden, welches von drei Kundenproblemen wir zuerst prüfen» ist ein Workshop-Ziel. «Über unser Produkt sprechen» nicht.
• Eine kleine, interdisziplinäre Gruppe. Produkt, Design, Entwicklung und jemand mit Kundennähe. Dazu eine entscheidungsbefugte Person, die entscheidet, falls sich die Gruppe nicht einig wird.
• Datierte Rohdaten. Bringen Sie Interviewnotizen, Daten und Screenshots mit Datum mit, damit alle sehen, wie alt jede Information ist.
• Rollen. Eine Moderation, eine Protokollführung und ein gemeinsames Board. Trennen Sie auf dem Board Belege (was wir gesehen oder gehört haben) von Deutung (was wir darin sehen).

Boldare merkt zu Recht an, dass sich die Agenda daran ausrichten sollte, why the group is meeting and what result it should produce, und dass es kein allgemeingültiges Set an Methoden gibt. Betrachten Sie jede Vorlage als Ausgangspunkt.

Eine 90-Minuten-Agenda, die funktioniert

Der Leitfaden von Learning Loop schlägt folgende Aufteilung vor:

Minuten	Block	Ergebnis
25	Ziel und Belege	Gemeinsames Bild von Ziel und Fakten
15	Annahmen	Liste der Annahmen, riskante markiert
20	Chancen kartieren	Gruppierte Probleme und Chancen
15	Probleme priorisieren	Ein Problem oder Ziel ausgewählt
15	Nächster Forschungsschritt	Massnahme, verantwortliche Person und Überprüfungstermin

Den letzten Block vergessen Teams am häufigsten. Ein Workshop, der ohne benannte Verantwortung und ohne Überprüfungstermin endet, bringt nichts.

Wann Sie ein längeres Format brauchen

Für ein neues Produkt ohne gemeinsame Vision kann ein ganztägiges Format gerechtfertigt sein. Airfocus veröffentlicht eine longer template, die von der Vorstellungsrunde über Produktvision, Kurzpräsentation, Kennzahlen, Personas, User Stories und Prioritäten bis zum User-Story-Mapping und einem Abschluss mit nächsten Schritten reicht. Sie ist gründlich, verlangt aber auch einen ganzen Tag von erfahrenen Leuten. Nutzen Sie sie also, wenn es der Einsatz rechtfertigt.

Mockitt beschreibt eine andere Struktur aus sechs Blöcken: frame the decision and constraints, read the evidence, group opportunities, identify risky assumptions, design the next test, and commit. Die dort aufgeführten Ergebnisse lohnen sich als Checkliste: eine formulierte Entscheidung, Beobachtungen mit Quellenangabe, ein ausgewähltes Problem oder Ziel, die Annahme, die die Entscheidung am ehesten verändert, ein Testplan mit verantwortlicher Person und ein Überprüfungstermin.

Welches Format Sie auch wählen: Beurteilen Sie den Workshop danach, was er hinterlässt, nämlich eine Entscheidung, einen Test und ein Datum.

Discovery gegen Umsetzung

Discovery fragt, ob sich etwas zu bauen lohnt. Die Umsetzung baut es auf Produktionsniveau. Das Playbook von Productboard sagt, Discovery four kinds of risk before committing to build, statt sie zu ersetzen: Sie erkunden Bedürfnisse, schlagen Lösungen vor und überprüfen sie, dann wählen Sie eine zum Bauen.

Der häufige Fehler besteht darin, beides als zwei Phasen zweier Gruppen zu behandeln, mit einer Übergabe in der Mitte. Die Silicon Valley Product Group vertritt die Haltung, dass discovery and delivery are two core activities the same cross-functional team should perform continuously. Zu jedem Zeitpunkt mögen Produktverantwortliche und Designer:innen eher zur Discovery und Entwickler:innen eher zur Umsetzung tendieren, doch alle beteiligen sich an beidem. Beides zu trennen, schadet aus dieser Sicht der Eigenverantwortung und der Innovationskraft.

Atlassian argumentiert ähnlich und empfiehlt boils discovery down to four questions, mit Roadmaps, die laufend aktualisiert werden, sobald neue Daten und Fortschritte aus der Umsetzung vorliegen. Und Maze betont, dass Maze groups interviews with competitor analysis and product analytics: Teams sollten die Phasen erneut durchlaufen, wenn sich der Forschungsbedarf über die Lebensdauer des Produkts verändert.

Was das für ein kleines Team konkret bedeutet:

• Holen Sie eine Entwicklerin oder einen Entwickler in Interviews und Prototyp-Besprechungen. Sie erkennen Machbarkeitsprobleme früh und hören die Sprache der Nutzer:innen aus erster Hand.
• Halten Sie die Discovery-Arbeit klein und häufig. Ein wöchentlicher Rhythmus schlägt eine dreimonatige Studie, die in einem Bericht endet, den niemand liest.
• Lassen Sie die Umsetzung die Discovery speisen. Veröffentlichen Sie in kleinen Schritten, messen Sie die echte Nutzung und machen Sie aus dem Gelernten die nächste Fragerunde.
• Nutzen Sie eine klare Regel für den Moduswechsel: Ist die Unsicherheit hoch, lernen Sie; ist sie gering, bauen Sie.

Genau deshalb zählt die Kontinuität der Personen so stark, wenn Sie mit einem externen Studio arbeiten. Wenn die Entwickler:innen, die das Produkt bauen, nicht Teil des Lernens waren, geht das Gelernte bei der Übergabe verloren.

Wo wir ins Spiel kommen

Bei Ampersand wird die Discovery-Arbeit von denselben erfahrenen Entwickler:innen geführt, die später bauen. So geht das, was wir über Ihre Nutzer:innen, Systeme und Rahmenbedingungen lernen, nicht zwischen einer Beratung und einer Übergabe verloren. Teams in der Frühphase bieten wir Beratung und technische Leitung auf Teilzeitbasis, technische Audits und Due Diligence. Wir bauen Websites, Apps, Plattformen, Anbindungen und KI-Automatisierung. Unsere Preisseite listet die Pakete auf, darunter Guidance für CHF 799 pro Monat und Run & monitor für CHF 750 pro Monat. Weitere Mandate werden projektbezogen bemessen. Wenn Sie eine Idee haben und deren riskanteste technische Annahme prüfen möchten, bevor Sie sich auf eine Umsetzung festlegen, melden Sie sich über unsere Website.

Häufige Fehler, die Sie vermeiden sollten

• Meinungen mit Belegen verwechseln. Ansichten von Beteiligten sind Eingaben, keine Ergebnisse. Kennzeichnen Sie sie auf dem Board entsprechend.
• Forschen ohne Entscheidung im Blick. Wenn von der Antwort keine Wahl abhängt, führen Sie die Untersuchung nicht durch.
• Nur das Einfache testen. Teams testen Schaltflächenfarben, weil es einfach ist, und überspringen die Preisannahme, die das Produkt zu Fall bringen könnte.
• Nur eine Methode einsetzen. Eine Umfrage allein oder Interviews allein lassen blinde Flecken. Kombinieren Sie sie.
• Discovery als Phase behandeln. Sobald das Produkt live ist, ändern sich die Fragen, aber sie hören nicht auf.

Häufige Fragen

Welche Discovery-Methoden sind für ein Startup am nützlichsten?

Beginnen Sie mit Kundeninterviews, einer raschen Prüfung der Mitbewerber, dem Kartieren der Annahmen und einem klickbaren Prototyp, den Sie mit einer Handvoll Nutzer:innen testen. Ergänzen Sie einen technischen Testlauf, wenn die Idee von der Anbindung an andere Systeme abhängt. Das ist günstig, schnell und deckt die Risiken bei Nutzen, Bedienbarkeit und Machbarkeit ab.

Wie lange sollte Product Discovery dauern?

Das hängt davon ab, wie viel Unsicherheit Sie mit sich tragen. Eine fokussierte erste Runde aus Interviews, einem technischen Testlauf und einem Prototyp-Test passt in ein paar Wochen Teilzeitarbeit. Die laufende Discovery begleitet die Umsetzung danach in kleinen wöchentlichen Aktivitäten statt in einem langen Block.

Worin unterscheidet sich ein Discovery-Workshop von einer normalen Sitzung?

Ein Workshop hat ein Ziel, eine Entscheidung, eine festgelegte Gruppe, vorbereitete Belege und verteilte Rollen. Er endet mit einem gewählten Problem, einem nächsten Test, einer verantwortlichen Person und einem Überprüfungstermin. Eine normale Sitzung endet oft mit einer Diskussion und ohne Verbindlichkeit.

Ist Product Discovery dasselbe wie die Umsetzung?

Nein. Discovery verringert die Unsicherheit darüber, was sich zu bauen lohnt, während die Umsetzung es auf Produktionsqualität bringt. Trotzdem sollte beides laufend vom selben interdisziplinären Team getan werden, statt von einer Gruppe an die nächste übergeben zu werden.

Quellen

• 2025 academic review of product discovery
• discovery study guide
• at least weekly customer touchpoints
• technical feasibility is one uncertainty to check before committing to execution
• Maze groups interviews with competitor analysis and product analytics
• four kinds of risk before committing to build
• boils discovery down to four questions
• discovery and delivery are two core activities the same cross-functional team should perform continuously
• several people need shared understanding for a meaningful decision
• longer template
• frame the decision and constraints, read the evidence, group opportunities, identify risky assumptions, design the next test, and commit
• why the group is meeting and what result it should produce