Gib einen Suchbegriff ein, um Kapitel, Beiträge, Lektionen und Seiten zu finden.

Praxisfall

Frag nach dem Prozess, bevor du über dein Produkt sprichst

Starte die funktionale Discovery mit dem Arbeitsalltag des Kunden, nicht mit Features. Ein Ablauf für 25 Minuten, gute Fragen und die Warnsignale.

6 Min. LesezeitTeilen

Starte die funktionale und technische Discovery damit, wie der Kunde heute arbeitet. Frag nach Rollen, Abläufen, Systemen und Engpässen, bevor du ein einziges Feature beschreibst. Seine Antworten bestimmen, was deine Demo zeigt und was sie weglässt. Ohne sie rätst du nur, und der Kunde merkt das.

Das Wichtigste

  • Frag zuerst nach dem Prozess. Über das Produkt sprichst du erst, wenn du die Arbeit kennst.
  • Halte in 25 Minuten eine feste Reihenfolge ein: Organisation, Systeme, Betrieb, Schmerz, Kultur, Vision.
  • Ein Gespräch ohne vereinbarten nächsten Schritt war ein Plausch und keine Discovery.

Die Situation

Nimm an, du hast ein erstes Gespräch mit einem neuen Account. Der Vertrieb hat "einen kurzen Blick aufs Produkt" versprochen. Das Team des Kunden sitzt im Call und erwartet eine Tour. Deine Demo ist bereit, und der Drang, sie zu starten, ist groß.

Das Handbuch ist hier klar. Mach nie eine Demo ohne vorherige Discovery. Eine Demo vor der Discovery ist wie ein Arzt, der Medikamente verteilt, bevor er die Ursache kennt. Sie kommt zu früh und kann sogar schaden.

Warum Prozessfragen bei Käufern wirken

Prozessfragen sind leicht zu beantworten. Niemand muss ein Budget verteidigen oder eine Schwäche zugeben, um zu erklären, wie ein Auftrag durchs Team läuft. Das senkt die Abwehr, die ein Vertriebsgespräch sonst auslöst.

Sie drehen außerdem die Rollen um. Fragst du, wie die Arbeit läuft, erklärt der Kunde und du lernst. Das Kapitel nennt das deinen Vorsprung. Das Vertrauen wächst, während du seine Ziele erkundest, und die Demo danach wird persönlicher.

Auch Käufer bewerten dich in dieser Phase. Wer ihr Umfeld, ihre Kultur und ihre Probleme treffend beschreibt, hebt sich von den anderen ab. Mit Feature-Gesprächen schaffst du das nie, denn dabei geht es um dich.

Die ersten Vertriebsgespräche bleiben meist bei großen Zielen. Die funktionale und technische Discovery (FTD) danach entscheidet oft, ob der Deal gelingt. Hier wird aus der Sales Discovery (öffnet in neuem Tab) etwas, auf dem du eine Demo bauen kannst.

Was du tust

Plane für die erste FTD-Runde 25 Minuten ein. Das Handbuch empfiehlt diese Länge. Sie passt in einen vollen Kalender und zeigt Respekt vor der Zeit des Kunden. Bitte um die Leute, die die Arbeit machen, nicht nur um die Person, die unterschreibt.

Geh die acht Phasen der Reihe nach durch

  1. Das Gespräch eröffnen. Frag nach der Rolle und dem Weg dorthin. Das zeigt Interesse und lockert die Runde.
  2. Die Organisation abbilden. Teamgrößen, Rollen und wer an wen Arbeit übergibt.
  3. Nach Abläufen und Systemen fragen. Welche Tools laufen heute, und wie hängen sie zusammen? Hier muss dein Produkt andocken.
  4. Den Betrieb ansehen. Such nach Abhängigkeiten, Engpässen und Schwachstellen.
  5. Den Schmerz finden. Finde heraus, wo es am meisten wehtut und was es kostet.
  6. Den Blick weiten. Nachbarteams haben vielleicht dasselbe Problem. Dort steckt oft zusätzlicher Nutzen.
  7. Kultur und Einführung klären. Frag, wie sie das letzte neue Tool eingeführt haben. Dein Plan muss zu diesem Muster passen.
  8. Mit der Vision schließen. Frag, wo sie hinwollen. So bestätigst du, dass ihr dasselbe seht, und bereitest das nächste Treffen vor.

Fragen, die beim Prozess bleiben

Feste Formulierungen helfen, wenn die Nervosität dich zum Produkt zieht. Probier diese, in deinen eigenen Worten:

  • "Zeig mir, was passiert, von der Anfrage bis zum Abschluss."
  • "Wo wartet dieser Schritt auf jemand anderen?"
  • "Was habt ihr gemacht, als es das letzte Mal schiefging?"
  • "Welches System hat die Antwort, und wer kopiert sie von dort?"
  • "Wenn das in einem Jahr gut läuft, was ist dann für euer Team anders?"

Die Frage nach dem letzten Mal bringt am meisten. Sie ersetzt eine allgemeine Klage durch ein echtes Beispiel, das du später in der Demo zeigen kannst. Bleibt eine Antwort dünn, frag noch einmal nach dem Warum. Die 5-Why-Methode geht jedes Mal eine Ebene tiefer, bis du die Ursache erreichst.

Gib wieder, was du gehört hast, bevor du zur nächsten Phase gehst. "Der Auftrag liegt also im Postfach, bis die Finanzabteilung ihn freigibt. Stimmt das so?" Eine Korrektur kostet hier wenig. Dieselbe Korrektur vor dem ganzen Team in der Demo kostet dich den Raum.

Was du mitnimmst

Du gehst mit vier Dingen raus. Ein ausgefülltes Opportunity Scoping Document (öffnet in neuem Tab). Eine Liste der Lücken, sortiert nach Wirkung und Dringlichkeit. Das Rohmaterial für deine Demo-Geschichte. Und einen nächsten Schritt, dem der Kunde zugestimmt hat. Fehlt der letzte Punkt, hattest du ein nettes Gespräch. Eine Discovery war es nicht.

Schick danach eine kurze Zusammenfassung und bitte den Kunden, sie zu korrigieren. Das Handbuch nennt diesen Schritt Feedback und Validierung. Zeigen sich Lücken, grab tiefer, bevor du die Demo (öffnet in neuem Tab) baust. Die ganze Methode und das Cheat Sheet stehen im Kapitel zur funktionalen Discovery (öffnet in neuem Tab). Die FTD-Vorlage findest du auf der Seite mit den Vorlagen (öffnet in neuem Tab).

Was schiefgehen kann

Der Kunde besteht auf dem Produkt

Manchmal ist der Wunsch nach einer Demo fest. Lehn ihn nicht ab. Gib einen kurzen Überblick, was die Lösung kann, oder zeig eine "Look and Feel"-Demo der Oberfläche. Kommen Detailfragen, nimm sie auf und biete einen genaueren Blick nach der vollen Discovery an. Du kannst auch in der Demo Fragen stellen, damit sie selbst zur Discovery wird.

Das ist das stärkste Argument gegen das ganze Vorgehen, und manchmal gewinnt es. Ein technischer Evaluator mit einer Shortlist will vielleicht nur sehen, ob dein Tool die Aufgabe löst. Dann verschafft dir eine kurze frühe Demo die Discovery-Runde. Halte sie knapp und beende sie mit einer Frage: "Wie läuft dieser Schritt heute bei euch?"

Dünne oder vorsichtige Antworten

Kunden beschreiben oft nur das große Bild. Manche halten Infos zurück, weil sie einen Pitch fürchten. Sag, warum du fragst und was du mit den Antworten machst. Hör dann zu, bevor du präsentierst. Bitte um ein aktuelles Beispiel statt um eine allgemeine Beschreibung.

Die Runde ist sich nicht einig

In großen Organisationen nennen die Leute verschiedene Hauptprobleme. Sieh das als Information und nicht als Fehlschlag. Sprich mit mehreren Stakeholdern und passe die Fragen an jede Rolle an. In einer kleineren Firma steuert vielleicht eine Person den ganzen Prozess. Dann reicht oft eine gute Runde. Bei einem großen Account planst du eine Runde pro Team, das den Ablauf berührt.

Zu wenig Zeit

Eine gehetzte Runde übersieht Dinge, und du verstehst den Bedarf nur zum Teil. Plane lieber zwei kürzere Runden statt eines vollgestopften Interviews. Hab Geduld mit dem Kalender des Kunden. Ein echter Dialog schlägt einen gehetzten Fragebogen.

Die Signale

Es läuft gut, wenn der Kunde seinen eigenen Bildschirm teilt oder den Ablauf skizziert. Es läuft schlecht, wenn du mehr redest als er oder deine Notizen Features statt Schritte enthalten. Ertappst du dich beim Beschreiben deines Produkts, schau auf die Liste und stell die nächste Frage.

Mehr Fragen nach Rolle findest du in den wichtigsten Fragen für Presales (öffnet in neuem Tab). Warum Käufer sich bei einem Pitch zurückziehen, liest du in Käufer hassen nicht den Vertrieb, sondern das Verkauftwerden (öffnet in neuem Tab).

Weiterlernen

Drei Wege, tiefer einzusteigen als mit einem Artikel.

Dr. Johannes Hangl mit dem PreSales Handbook

Über den Autor

Dr. Johannes Hangl

Presales-Leader mit über zehn Jahren in B2B-Software. Ich schreibe darüber, was in echten Deals funktioniert: Discovery, Demos und die menschliche Seite im Vertrieb.

Auf LinkedIn folgen (öffnet in neuem Tab)Mehr über mich

Themen:

Feedback oder Fehler melden

Fehler gefunden oder eine Idee? Jede Meldung wird ein Ticket, das ich abarbeite.

Worum geht es?

10 bis 4000 Zeichen. Bitte lass persönliche Daten weg.

Deine Nachricht wird als GitHub-Issue gespeichert, ohne deine E-Mail-Adresse. Details stehen in der Datenschutzerklärung.