Wie verkauft man, wenn der Nutzer nicht der Käufer ist?

• In Situationen, in denen der Nutzer das Produkt verwendet, aber nicht zahlungsberechtigt ist, ist der entscheidende Punkt, herauszufinden, wer tatsächlich die Befugnis und den Einfluss hat
• Der Entscheidungsträger mit der tatsächlichen Befugnis ist nicht zwingend dieselbe Person wie der Käufer oder der erste Nutzer
• In kleinen Organisationen ist Zeitersparnis wichtig, daher ist die Wahrscheinlichkeit hoch, dass Entwickler Tools direkt einführen und den Kauf anschließend durch Überzeugungsarbeit nach oben anstoßen
• In großen Organisationen sind Sicherheits- und Verfahrensvorgaben stark, daher liegt die Kaufentscheidung bei CTO oder Management, und ein langer Sales-Zyklus ist nötig
• Die kaufberechtigte Person ist nicht zwangsläufig identisch mit dem Budgetverantwortlichen; entscheidend ist die Person, die den Produktwert am stärksten spürt und vorantreiben kann
• Eine effektive Strategie besteht darin, Nutzern konkrete Daten und Überzeugungsmaterialien bereitzustellen, damit sie das Management überzeugen können, und diesen Prozess zu unterstützen
• Der letztendliche Erfolg liegt in der Gestaltung eines Prozesses, der Nutzer dabei unterstützt, die Rolle des internen Sales zu übernehmen

---

Einleitung – Ausgangspunkt der Frage

• Wie sollte man vorgehen, wenn die Nutzer, die das Produkt tatsächlich verwenden, und die Kunden, die die Kaufentscheidung treffen, nicht dieselben sind?
• Der Hintergrund ist typischerweise ein B2B-Software-Sales-Kontext, in dem Entwickler das Produkt ausprobieren und CTO oder Director of Engineering die endgültige Entscheidung treffen

Die grundlegende Frage nach Befugnissen

• Die Frage „Wer hat die wirkliche Macht?“ ist der zentralste Punkt überhaupt
• Entscheidend für den Kaufprozess sind nicht einfach nur die Berechtigung zur Kartenzahlung oder die Priorität, ein Produkt auszuprobieren, sondern tatsächlicher Einfluss und Motivation

Szenarien nach Organisationsstruktur

Im Fall kleiner Organisationen: flache Struktur und schnelle Entscheidungen

• Häufig sind es Entwickler, die sich mit dem Produkt befassen und die Einführung tatsächlich vorantreiben
• Die Hauptmotivation eines CTO ist schneller Go-to-Market und schnelle Iteration, weshalb Tool-Vorschläge von Entwicklern erheblichen Einfluss auf die Entscheidung haben
• Oft zeigt sich eine Trojan-horse-artige Verbreitung, bei der Entwickler ein Tool schnell kostenlos ausprobieren und später in eine bezahlte Nutzung wechseln

Im Fall großer Organisationen: Sicherheit und Compliance als zentrale Einschränkungen

• Es gibt Einschränkungen jenseits der Zeit, etwa im Bereich Sicherheit, und Entscheidungen der Führungsebene wirken sich stark auf den gesamten Prozess aus
• Eigenständige Installation oder Käufe durch Nutzer (Entwickler) sind nicht erlaubt, und der Sales-Zyklus ist lang und komplex
• Die Maßstäbe für die Wahrnehmung von Wert und Risiko konzentrieren sich weniger auf UI/UX oder DX als auf Sicherheit und das Endergebnis

Perspektive von echtem Einfluss und Wert

• Budgetverantwortliche sind nicht immer die Personen mit der tatsächlichen Befugnis
• Wichtig ist, wer Hebelwirkung hat und wessen Anreize den Prozessfortschritt am stärksten beeinflussen
• Man muss realistisch erfassen, wer tatsächlich in der Lage ist, den Gegenwert des Preises gegen den Produktwert einzutauschen

Konkretes Beispiel für den Einführungsprozess eines Produkts

1. Nutzer/Entwickler registriert sich für das Produkt
2. Nutzung einer kostenlosen Trial in der lokalen Umgebung
3. Direkte Erfahrung des tatsächlichen Funktionswerts (z. B. Vergleich vor/nach einem Pull Request, Hervorhebung von Problemen)
4. Wahrnehmung des Werts → Erwartung höherer Arbeitseffizienz und Automatisierung
5. Der Nutzer überzeugt die Führungsebene von der Notwendigkeit
6. Die Führungsebene genehmigt oder lehnt nach internem Test und Budgetprüfung ab
7. Die Führungsebene genehmigt den endgültigen Kauf
8. Kauf des Produkts abgeschlossen, weitere Verbreitung innerhalb der Organisation

Fragen zu den Anreizen beider Seiten

• Die grundlegende Motivation von Entwicklern, ein Tool vorzuschlagen, verstehen (Arbeitskomfort, Hervorhebung der eigenen Fähigkeiten, Erreichen von Unternehmenszielen usw.)
• Die Kaufmotivation der Führungsebene verstehen (Steigerung der Entwicklungseffizienz, schnelleres Erreichen von Unternehmenszielen usw.)
• Wenn diese Kernmotive vorhanden sind, wird folgende Strategie vorgeschlagen

Praktische Reaktionsstrategie

1. Nutzern Überzeugungswerkzeuge wie präzise Vorher-/Nachher-Vergleichsberichte bereitstellen, damit sie die Führungsebene überzeugen können
   • Dabei sind nicht abstrakte Ratschläge, sondern Ergebnisse auf Basis quantitativer Daten wichtig
   • Konkrete Zahlen wie „wie viel Zeit im Vergleich zur bisherigen Vorgehensweise eingespart wurde“ sind der Schlüssel zur Überzeugung
2. Durch Interviews mit Kunden (Entwicklern) verstehen, wie tatsächliche Kaufgespräche ablaufen, und Hindernisse im Überzeugungsprozess im Voraus beseitigen

• Statt also direkt die kaufberechtigte Person zu überzeugen, sollte man alle Rahmenbedingungen und konkreten Materialien bereitstellen, damit der Nutzer die Rolle des internen Sales erfolgreich ausfüllen kann
• In diesem Prozess führt der Erfolg des Nutzers direkt zum Erfolg des Vendors (eine Win-Struktur für Nutzer, Vendor, Führungsebene und Unternehmen)

Fazit und Zusammenfassung

• Die beste Strategie ist, Nutzer dabei zu unterstützen, die Rolle des internen Sales erfolgreich zu übernehmen
• Der Fokus sollte darauf liegen, quantitative Belege und konkrete Materialien zum Produktwert bereitzustellen, die zur Überzeugung der Führungsebene nötig sind
• Zuvor muss die Entscheidungsstruktur je nach Organisationsgröße und Einschränkungen sorgfältig analysiert werden
• Abschließend wird betont, dass eine Struktur entsteht, in der mit dem Erfolg des Nutzers gleichzeitig auch Vendor und Unternehmen erfolgreich sind