Outbound für Developer Tools

Zwei Publika, gegensätzlicher Geschmack, eine Nachricht

In den meisten B2B-Softwaremärkten überschneiden sich Käufer und Nutzer genug, dass eine Nachricht beiden genügt. Bei Entwicklerwerkzeugen fallen sie auseinander, und zwar nicht entlang der Hierarchie, sondern entlang dessen, was jeder als Beleg akzeptiert.

Der Engineering Manager oder Plattformverantwortliche, der unterschreibt, denkt an Kosten, Risiko, Einführung und daran, was passiert, wenn der Anbieter verschwindet. Der Entwickler, der das Werkzeug benutzen wird, denkt daran, ob es tatsächlich funktioniert, was es unter Last tut und ob es eine weitere Schicht ist, die er künftig pflegen muss.

Eine Nachricht rein für den Unterzeichner wirkt auf den Entwickler wie Marketing, und er beendet sie leise und ohne Begründung. Eine Nachricht rein für den Entwickler erreicht nie ein Budget. Sie muss beides leisten, praktisch also eine technische Aussage mit ihrer kaufmännischen Folge: was das System tut, und was das spart.

Das Veto wird von außen unterschätzt. In Engineering-Organisationen wird ein ungeliebtes Werkzeug nicht eingeführt, gleich wer es gekauft hat, und der Vertrag läuft bei der Verlängerung still aus. Am Entwickler vorbei zu verkaufen erzeugt eine Unterschrift und zwölf Monate später keinen Umsatz.

Bottom-up und Top-down sind verschiedene Produkte

Anbieter von Entwicklerwerkzeugen versuchen regelmäßig, beide Bewegungen mit einer Nachricht zu fahren, und die beiden sind strukturell unvereinbar.

Bottom-up heißt, ein einzelner Entwickler führt das Werkzeug ein, ohne jemanden zu fragen, und der Account wächst später in einen Vertrag. Das verlangt eine kostenlose Stufe, die wirklich nützlich ist, Selbstbedienung ohne Gespräch und eine Dokumentation, die einen Vertriebsmitarbeiter ersetzt. Outbound spielt hier eine kleine Rolle, vor allem beim Überführen bestehender Nutzung in einen Vertrag.

Top-down heißt, die Organisation entscheidet die Einführung, meist wegen Governance, Kostenkonsolidierung, Compliance oder eines gesetzten Standards. Hier funktioniert Outbound, und die Nachricht handelt von der Organisation statt vom einzelnen Entwickler.

Der Fehler ist ein Bottom-up-Produkt, das top-down verkauft wird. Die Nachricht erreicht einen Engineering-Leiter, er fragt das Team, und das Team kennt es nicht und hat keinen Grund, es zu wollen. Der umgekehrte Fehler ist ein Top-down-Produkt, das bottom-up vermarktet wird: Entwickler probieren es, mögen es, und niemand zahlt, weil der Wert erst auf Organisationsebene entsteht.

Ein Mischfall existiert und ist der schwierigste: Produkte, die einzelne Entwickler gern nutzen und die erst im Verbund Geld wert sind. Dort ist die richtige Reihenfolge, die bestehende Nutzung im Zielunternehmen zu kennen, bevor die erste Nachricht rausgeht, und genau diese Nutzung zum Anlass der Ansprache zu machen.

Entscheiden Sie vor der Sequenz, welches von beiden Sie sind. Die Antwort steht meist auf der Preisseite.

Mechanismus schlägt Nutzenversprechen

Klassische B2B-Textlehre sagt, man solle Nutzen statt Funktionen schreiben. Bei Entwicklerwerkzeugen ist dieser Rat schädlich, weil ein Nutzenversprechen ohne Mechanismus das Erkennungszeichen eines Produkts ist, das nicht funktioniert.

Entwickler bewerten über das Wie. Eine Nachricht, die sagt, das Produkt verkürze Build-Zeiten, sagt nichts Prüfbares. Eine Nachricht, die sagt, es zwischenspeichere die Auflösung von Abhängigkeiten über Branches hinweg, sodass inkrementelle Builds einen bestimmten Schritt überspringen, sagt etwas, das ein Entwickler sofort gegen den eigenen Aufbau halten kann, und der Nutzen ergibt sich, ohne behauptet zu werden.

Das löst zugleich das Zwei-Publika-Problem, denn ein klar benannter Mechanismus ist auch für einen Manager lesbar. Er liest ihn als Genauigkeit, und Genauigkeit ist auf jeder technischen Tiefe ein Glaubwürdigkeitssignal.

Eine gute Prüfung vor dem Absenden: streichen Sie den Produktnamen aus der Nachricht. Bleibt ein Satz übrig, den ein Entwickler nachvollziehen kann, taugt sie. Bleibt nur eine Beschreibung übrig, die auf zwanzig andere Anbieter ebenso passt, fehlt der Mechanismus.

Die Kehrseite: Unschärfe kostet hier mehr als in jeder anderen Kategorie. Wörter wie nahtlos, leistungsstark und Plattform sind nicht nur schwach, sie werden als Versuch gelesen, das Konkrete zu vermeiden.

Der Einwand ist immer derselbe

Unabhängig vom Produkt lautet die erste Antwort in einer Variante immer gleich: dafür haben wir schon etwas, oder das haben wir intern gebaut.

Das stimmt meist, und dagegen zu argumentieren verliert. Jede Engineering-Organisation ab einer gewissen Größe hat ein internes Skript, eine Tabelle, ein leicht verbogenes Open-Source-Werkzeug oder einen früheren Anbieter. Das Werkzeug existiert. Die Frage ist, was es kostet, es zu behalten.

Die produktive Antwort verschiebt das Gespräch von der Funktion zur Wartung. Wem gehört das interne Werkzeug. Was passiert, wenn diese Person geht. Wie viel Entwicklerzeit ist im letzten Quartal hineingeflossen. Was deckt es nicht ab, das inzwischen Anforderung ist. Keine dieser Fragen handelt von Ihrem Produkt, weshalb sie beantwortet werden.

Ein zweiter Einwand folgt oft direkt danach: der Aufwand der Einführung. Auch er wird nicht durch Argumente entkräftet, sondern durch eine belastbare Zahl. Wie lange dauert die Einrichtung bei einem Team dieser Größe, gemessen, nicht geschätzt, und was muss dafür angefasst werden.

Interne Eigenbauten haben zudem einen vorhersagbaren Bruchpunkt: sie funktionieren, bis die Organisation über die Annahmen hinauswächst, unter denen sie geschrieben wurden. Ein Unternehmen genau dann anzusprechen, wenn es diese Schwelle überschreitet, bedeutet anzukommen, wenn die interne Antwort bereits zu versagen beginnt, und das ist mehr wert als jeder Wettbewerbsvergleich.

Was für Entwickler als Beleg zählt

Kein Logo, kein Zitat über eine erfreuliche Partnerschaft und keine Prozentzahl ohne Ausgangsbasis.

Was wirkt, grob nach Stärke:

• Ein nachvollziehbarer Benchmark mit genannter Methodik, einschließlich der Bedingungen, unter denen das Ergebnis nicht gilt. Die Grenzen zu veröffentlichen macht den Rest glaubwürdig.
• Eine öffentliche technische Aufarbeitung eines echten Problems und seiner Lösung, unabhängig davon, ob sie etwas verkauft. Das ist das haltbarste Gut, das ein Anbieter besitzen kann, und es verkauft, bevor die Ansprache beginnt.
• Einsicht in Quellcode oder Spezifikation. Alles, was ein Skeptiker prüfen kann, verwandelt Skepsis in Bewertung.
• Ein benanntes Team im Produktivbetrieb in vergleichbarer Größenordnung, technisch beschrieben statt als Kundengeschichte.

Was der Glaubwürdigkeit aktiv schadet: erfundene Kennzahlen, Vergleichstabellen mit offensichtlich schwach gezeichneter Wettbewerbsspalte und Marketingsprache auf technischen Aussagen. Entwickler erkennen alle drei schnell, und die Erkenntnis ist dauerhaft.

Auslöser, die einem Kauf vorausgehen

Vier beobachtbare Veränderungen gehen dem Kauf von Engineering-Software zuverlässig voraus.

Das Überschreiten einer Teamgröße. Praktiken, die bei acht Entwicklern funktionieren, brechen bei fünfundzwanzig und brechen bei achtzig anders. Jede Schwelle erzeugt Bedarf an einer Werkzeugkategorie, die darunter unnötig war. Teamgröße ist aus Stellenanzeigen, öffentlichen Profilen und der Menge technischer Veröffentlichungen ablesbar.

Eine Migration. Cloud-Anbieter, Sprachversion, Framework, Zusammenführung in ein Monorepo oder ein neues Deployment-Modell. Migrationen öffnen alle angrenzenden Entscheidungen gleichzeitig und werden von den beteiligten Teams häufig öffentlich beschrieben.

Ein Vorfall. Ein öffentlicher Ausfall, eine Sicherheitsmeldung oder ein Compliance-Befund bewegt Budget schneller als jede Ansprache. Sofort danach anzusprechen ist geschmacklos und meist kontraproduktiv. Sechs bis acht Wochen später, wenn die Maßnahmen aus der Nachbetrachtung finanziert werden, ist es passend.

Die erste Plattform- oder Infrastrukturstelle. Der erste dedizierte Plattform-Entwickler bedeutet, dass die Organisation Developer Experience zur Aufgabe erklärt hat. Diese Person kommt mit Mandat, leerem Werkzeugkasten und einer Liste von Beschwerden ihrer neuen Kolleginnen und Kollegen.

Kanäle, und wo man nichts zu suchen hat

E-Mail an die Engineering-Leitung wirkt, bei geringem Volumen und hoher Konkretheit. LinkedIn wirkt für dieselbe Zielgruppe mit leichterer Hand. Das Telefon wirkt hier schlechter als in fast jeder anderen B2B-Kategorie, weil ein unerwarteter Anruf als Störung gilt.

In Deutschland kommt hinzu, dass Paragraf 7 UWG die kalte Werbe-E-Mail auch im B2B als unzumutbare Belästigung behandelt, weshalb LinkedIn hier nicht nur taktisch, sondern rechtlich der sinnvollere Erstkontakt ist. Dies ersetzt keine Rechtsberatung.

Drei Orte bleiben tabu. Sprechen Sie Entwickler nicht über GitHub-Issues, Pull Requests oder Repository-Diskussionen an. Dieser Raum ist kein Kanal, und ihn als solchen zu nutzen erzeugt öffentliche, dauerhafte und berechtigte Kritik. Bauen Sie keine Interessentendatenbank aus Beitragslisten von Open-Source-Projekten. Und automatisieren Sie keine Personalisierung aus dem öffentlichen Code einer Person, was aufdringlich wirkt statt aufmerksam, auch wenn die Daten öffentlich sind.

Die Grenze ist schlicht: ein berufliches Postfach ist ein zumutbarer Ort für ein Geschäftsangebot, ein gemeinsam genutzter technischer Arbeitsraum nicht.

Ehrlich messen

Die Antwortquote ist in dieser Kategorie ein schwaches Signal, weil technische Zielgruppen unabhängig von der Qualität weniger antworten als kaufmännische. Zwei bessere Maße existieren.

Das erste ist, was nach einer Antwort passiert. Gespräche über Entwicklerwerkzeuge, die irgendwohin führen, enthalten fast immer eine technische Bewertung, weshalb die aussagekräftige Umwandlung von Termin zu Test oder Machbarkeitsnachweis geht, nicht zum Termin selbst. Eine Pipeline voller Termine, die nie eine Bewertung erreichen, hat ein Nachrichtenproblem, kein Mengenproblem.

Das zweite sind beeinflusste Selbstanmeldungen. In jedem Unternehmen mit kostenloser Stufe zeigt sich ein Teil des Outbound-Werts darin, dass ein Entwickler das Produkt einige Tage nach der Nachricht an seinen Vorgesetzten still ausprobiert, ohne jede Zuordnung. Anmeldungen aus Zielunternehmen zu beobachten statt Antworten von Zielkontakten erfasst einen echten Effekt, den eine Antwortquotenauswertung vollständig übersieht.

Wir fahren Outbound für technische Produkte so, wie es nötig ist: kleine Listen, echte Recherche, mechanismusgetriebene Texte und Nachfassen, das die langsame Entscheidungsgeschwindigkeit von Engineering-Organisationen respektiert. Feste Preise: 3.750 EUR im ersten Monat, danach 2.850 EUR monatlich, jederzeit kündbar.