Hauptgedanke

Im B2B sind derjenige, der die Software nutzt, und derjenige, der sie kauft, selten dieselbe Person. Der Käufer zahlt, wägt zwischen konkurrierenden Projekten ab, vertritt dieses eine gegenüber seinen Vorgesetzten, trägt das Risiko, wenn es scheitert, und fragt sich, ob der Rollout durchzuhalten ist. Seine Kriterien sind also nicht die des Nutzers: Er bewertet eine Entscheidung, kein Werkzeug.

Daraus ergeben sich drei Situationen, und man begegnet ihnen häufig. Ein Produkt, das bei den Anwendern beliebt ist und sich nicht verkauft. Ein Produkt, das ein echtes Problem löst und beim Kauf blockiert wird. Ein gutes Produkt, das aber nicht zu der Art passt, wie die Organisation entscheidet — Verfahren, Freigabeschwellen, Anforderungen an die Umkehrbarkeit, Fähigkeit des internen Teams, den Rollout zu stemmen.

Beim Nutzer zu bestehen und beim Kunden zu bestehen, sind also zwei getrennte Prüfungen, und wer die erste besteht, ist von der zweiten nicht befreit.

Warum das wichtig ist

Das trennt zwei Diagnosen, die man verwechselt, wenn ein Verkauf scheitert. Ein Produkt, das sich trotz zufriedener Nutzer nicht verkauft, hat kein Problem mit seinem Nutzwert; es hat ein Problem mit seinem Wert für den Käufer, und eine bessere User Experience behebt das nicht.

Das sagt auch, was man über die Nutzungsweisen hinaus herausfinden muss: was den Kauf antreibt und was ihn blockiert, vor wem sich der Käufer rechtfertigen muss und was seine Organisation verlangt, bevor sie unterschreibt.

Nuancen und Grenzen

Die Trennung ist nicht immer scharf: In einer kleinen Organisation können Nutzer und Käufer dieselbe Person sein, und die Überlegung fällt auf einen einzigen Satz von Kriterien zurück.

Und die Akzeptanz bei den Nutzern fällt bei der Kaufentscheidung ins Gewicht — sie ist ein Argument für den Käufer, keine Garantie.

Offene Fragen

• An welchem Punkt einer Produkt-Discovery sollte man den Käufer aufsuchen, wenn der Zugang zu den Anwendern leichter und ergiebiger ist?