Kundenbedürfnisse verstehen: Product Discovery im B2B

In unseren Trainings sprechen wir oft über einen Moment, den fast alle Produktmanager*innen kennen. Ein Kunde schildert ein Anliegen, und noch während er spricht, entsteht im Kopf schon die passende Funktion. Das ist menschlich. Viele Produktmanager*innen haben den Anspruch an sich selbst, dem Kunden die ideale Lösung von den Lippen abzulesen. Und das Umfeld erwartet es oft auch: Vertrieb, Entwicklung und Kunde wollen eine Antwort. Weitere Fragen wirken da schnell wie Zögern.

Besonders häufig erleben wir das bei Produktmanager*innen mit wenig Erfahrung in der Rolle und bei denen, die aus der Entwicklung kommen. Wer jahrelang technische Probleme gelöst hat, denkt fast automatisch in Lösungen. Im Ingenieursland Deutschland ist das eine Stärke. Im Produktmanagement setzt sie allerdings häufig zu früh ein, bevor das Problem ausreichend geklärt ist.

Dazu kommt, dass auch Kunden ihre Wünsche meistens schon als Lösung formulieren. Wenn beide Seiten im Lösungsmodus sind, entstehen Anforderungen, die genau beschreiben, was gebaut werden soll, und wenig darüber sagen, welches Problem damit gelöst wird. Echte Kundenorientierung verlangt deshalb Aufmerksamkeit und etwas Disziplin, gerade am Anfang beim Problem zu bleiben. Product Discovery gibt dieser Haltung eine Methode, bei Software genauso wie bei Produkten mit Hardware-Anteil.

Warum Kundenwünsche noch keine Kundenbedürfnisse sind

Eine Kundenanforderung ist in den meisten Fällen ein Lösungsentwurf des Kunden. Er hat ein Problem, überlegt, was helfen könnte, und formuliert das Ergebnis als Wunsch an den Hersteller. Das ist legitim. Der Kunde kennt sein Problem allerdings besser als die möglichen Lösungen. Er kennt weder alle technischen Möglichkeiten noch die Probleme anderer Kunden.

Im B2B-Geschäft kommen zwei Verzerrungen hinzu. Viele Wünsche erreichen das Produktmanagement nur über Vertrieb, Service oder Projektleitung, jeweils verdichtet und mit deren Prioritäten versehen. Außerdem ist „der Kunde“ selten eine einzelne Person. Die Anwenderin an der Anlage, der Leiter Qualitätssicherung und der Einkauf haben unterschiedliche Probleme und unterschiedliche Gründe, ein Produkt zu kaufen oder abzulehnen. Einer Anforderung ohne Absender und Kontext sieht man nicht an, wessen Problem sie lösen soll.

Im Produktmanagement unterscheidet man deshalb den Problemraum, also die Situation des Kunden mit ihren Aufgaben, Hindernissen und Folgen, vom Lösungsraum mit Funktionen, Konzepten und Produkten. Product Discovery klärt, welche Probleme es wert sind, gelöst zu werden, und welche Lösungen dazu passen.

Ein Praxisfall: der CSV-Export

Ein Kunde eines Herstellers von Durchflussmessgeräten wünscht sich einen CSV-Export der Messdaten. Auf Nachfrage stellt sich heraus, dass die Qualitätssicherung jeden Monat einen Bericht über vier Messstellen erstellt. Die Daten werden dafür von Hand zusammengeführt, weil Geräte unterschiedlicher Baujahre verschiedene Formate liefern. Und den Bericht gibt es, weil der Auditor bei Abweichungen einen lückenlosen Nachweis verlangt.

Die Nachfragen haben aus einem Funktionswunsch eine Beschreibung der Situation gemacht. Welche Lösung am besten passt, ist damit noch nicht entschieden. Dafür fehlt noch einiges, zum Beispiel, ob andere Kunden dasselbe Problem haben und wie viel es sie heute kostet. Die Technik dahinter ist als „5 Warum-Fragen“ bekannt. Sie funktioniert, solange das Warum neugierig klingt und nicht wie ein Verhör.

Wo Produktmanager*innen Kunden treffen und was diese Gespräche prägt

Zwei Situationen begegnen uns in Trainings immer wieder. Ein Produktmanager ist höchstens einmal im Quartal beim Kunden, weil interne Abstimmungen irgendwie immer vorgehen und der Vertrieb den Zugang kontrolliert. Eine Produktmanagerin verbringt nach eigener Schätzung die Hälfte ihrer Zeit beim Kunden, dort allerdings mit Anforderungsaufnahme, Tests, Implementierung und technischem Support. Beide gewinnen dabei Einblicke. Häufig fehlt aber die Zeit, die Hintergründe eines Problems systematisch zu untersuchen.

Das hat mit dem Zeitpunkt zu tun. Ein Kunde durchläuft mehrere Phasen: Das Problem ist ihm zunächst nicht bewusst, dann wird es spürbar, er sucht nach Lösungen, informiert sich, vergleicht, kauft und nutzt. Viele Anlässe, bei denen Produktmanager*innen Kunden treffen, liegen in den späteren Phasen. Der Kunde denkt dann meist schon in Lösungen.

In Routinegesprächen werden die Entstehung und Vorgeschichte eines Problems häufig nicht gezielt untersucht. Für Produktstrategie und Priorisierung sind gerade diese Informationen besonders wertvoll. Die Termine selbst bleiben trotzdem nützlich. Ein bestehender Termin schafft Zugang. Raum zum Lernen entsteht, wenn ein Teil des Gesprächs ausdrücklich dafür vereinbart ist.

Mehr Quellen als das Kundengespräch

Interviews sind nicht die einzige Quelle für Kundenverständnis. Win/Loss-Gespräche nach gewonnenen oder verlorenen Angeboten zeigen, nach welchen Kriterien Kunden tatsächlich entscheiden. Mitgehörte Hotline-Anrufe machen Alltagsprobleme hörbar, bevor sie im Ticketsystem zu Kategorien werden. Nutzungsdaten zeigen, welche Funktionen genutzt werden, aber nicht, warum.

Hilfreich ist ein Netz aus solchen Horchposten, das regelmäßig Einblicke liefert, auch ohne dass jemand gezielt danach sucht. Jede Quelle hat dabei ihr eigenes Profil in Kosten, Aufwand, Glaubwürdigkeit und Reaktionszeit. Deshalb lohnt es sich, vorab zu klären, welche Information wann gebraucht wird.

Wie Kundeninterviews zu belastbaren Erkenntnissen führen

Ein Kundeninterview in der Discovery ist ein Lerngespräch. Es dient keinem Projektmeilenstein und hat nichts zu verkaufen. Ziel ist, dass der Kunde seine Situation möglichst konkret beschreibt: was passiert ist, was es ihn gekostet hat und wie er sich heute behilft.

Daraus folgen ein paar Regeln für die Gesprächsführung. Meinungen gibt es intern genug, im Gespräch zählen Fakten und konkrete Erlebnisse. Eigene Ideen bleiben draußen, zumindest bis das Problem verstanden ist. Und ein starrer Fragenkatalog verhindert ausgerechnet die Nachfragen, bei denen es interessant wird.

Fragen, die in die Vergangenheit zeigen

Die zuverlässigsten Antworten bekommt, wer nach tatsächlichem Verhalten fragt. Fragen nach der Zukunft laden zu Höflichkeit ein. Kaum ein Kunde sagt im Gespräch, dass er eine Idee überflüssig findet, und kaum einer weiß, was er in einem Jahr für eine Funktion bezahlen würde. Rob Fitzpatrick hat diese Logik in „The Mom Test“ ausführlich beschrieben.

Vorbereitung und Gesprächsführung

So wird aus einer Kundenaussage eine überprüfbare Erkenntnis

Nach dem Gespräch liegen Notizen oder ein Transkript vor. Damit daraus mehr wird als eine gute Geschichte, lohnt eine kurze Auswertung direkt im Anschluss, am besten zu zweit. Fünf Fragen reichen dafür. Angewendet auf den CSV-Fall sieht das so aus:

Die letzte Zeile trägt die meiste Arbeit. Sie trennt, was ein Gespräch gezeigt hat, von dem, was das Team daraus schließt. Und sie legt fest, was die nächsten Gespräche klären sollen.

Die Ergebnisse gehören danach knapp dokumentiert zu Vertrieb und Entwicklung. Der Vertrieb erfährt, was Kunden bewegt, und öffnet beim nächsten Mal eher die Tür. Die Entwicklung versteht, warum eine Anforderung auf der Liste steht.

Von Einzelgesprächen zu Mustern: Segmente, Personas und Jobs-to-be-Done

Ein einzelnes Interview zeigt einen Fall. Belastbar wird eine Erkenntnis, wenn sich zeigt, bei wem das Problem auftritt, wie dringend es ist und wie viele Kunden es betrifft. Drei Ordnungsrahmen helfen dabei, jeweils mit einer eigenen Leitfrage.

In technischen B2B-Märkten wird oft nach Branche oder Unternehmensgröße segmentiert. Das ist leicht zu erheben, trennt aber nicht immer nach dem, was für das Produkt zählt. Ein Messtechnikhersteller kann in der Pharmaproduktion und in der Lebensmittelindustrie auf dasselbe Auditproblem treffen, während zwei Maschinenbauer gleicher Größe völlig unterschiedlich mit Messdaten arbeiten.

Bei Personas lohnt es sich im B2B-Umfeld, mindestens zwischen Anwender, fachlichem Entscheider und Einkauf zu unterscheiden, weil ihre Kaufmotive auseinandergehen. Proto-Personas aus dem Wissen des Teams sind ein brauchbarer Anfang. Sie funktionieren, wenn Annahmen sichtbar als solche gekennzeichnet sind und in den folgenden Gesprächen geprüft werden.

Annahmen im Team sind normal. Heikel werden sie erst, wenn niemand mehr weiß, dass es Annahmen sind.

Jobs-to-be-Done ergänzt die Persona um die Aufgabe. Die Persona beschreibt, wer nutzt und entscheidet. Der Job beschreibt, was erledigt werden muss und woran der Kunde Erfolg misst. Weil er keine Funktion vorgibt, lässt er den Lösungsraum offen.

Continuous Discovery im Produktmanagement

Product Discovery endet nicht mit einem Workshop. Kundenprobleme und Nutzungskontexte verändern sich. Continuous Discovery bedeutet, regelmäßig neue Erkenntnisse zu gewinnen und in laufende Produktentscheidungen einfließen zu lassen. Kurze, gut vorbereitete Gespräche mit Kunden helfen, Annahmen zu überprüfen.

Ein fester Lernrhythmus macht den Unterschied: Welche Entscheidung steht an? Was wissen wir, was vermuten wir? Mit welchen Anwendern können wir sprechen? Welche Beobachtung würde unsere Einschätzung verändern? Produktmanagement und Entwicklung werten die Ergebnisse gemeinsam aus, damit Erkenntnisse Priorisierung und Roadmap beeinflussen.

Bei B2B-Hardware mit langen Entwicklungszyklen eignen sich Servicefälle, Piloten und Prototypentests als zusätzliche Lernquellen. Continuous Discovery ersetzt weder systematische Marktanalyse noch technische Validierung.

Ein praktikabler Einstieg

Wählt eine offene Produktfrage und vereinbart in den nächsten vier Wochen zwei bis drei Gespräche oder Beobachtungen. Haltet fest, was beobachtet wurde, welche Annahme sich verändert hat und welche Konsequenz das für die nächste Entscheidung hat.

Von der Erkenntnis zur Produktentscheidung

Mit verstandenen Problemen beginnt der zweite Teil der Discovery: Lösungen entwickeln, testen und entscheiden. Auch hier hilft ein bewusster Ablauf. Vorab wird geklärt, welche Frage beantwortet werden soll und wer im Kernteam mitarbeitet, mindestens Produktmanagement und Entwicklung. Für das wichtigste Problem entstehen mehrere Lösungsideen. Und jeder Test wird so einfach gestaltet, dass er die konkrete offene Frage zuverlässig beantwortet. Bei Hardware kann das ein Modell oder ein kurzes Video sein, bei Software ein Klick-Prototyp.

Der Aufwand zahlt sich dort am meisten aus, wo Änderungen später teuer werden. Eine falsche Annahme im Konzept zu korrigieren kostet wenig. Dieselbe Korrektur nach Serienanlauf oder Rollout kostet ein Vielfaches.

Ein Opportunity Solution Tree, wie ihn Teresa Torres beschreibt, hält den Zusammenhang zwischen angestrebtem Ergebnis, Kundenproblemen, Lösungsideen und Tests fest. Das beantwortet viele Rückfragen, warum ein Feature auf der Liste steht, bevor sie gestellt werden.