Eine Beziehung zwischen der globalen Developer Community und Telekommunikationsunternehmen aufzubauen, ist aktuell nicht einfach. Mit dem kontinuierlichen Auf- und Ausbau von 5G-Netzwerken ergeben sich jedoch für beide Seiten Gründe und Möglichkeiten, eine Partnerschaft zu überdenken. Wie bewegt man also einen Entwickler zu einer Partnerschaft mit Telcos? Und wie profitieren Telcos von der Partnerschaft mit Entwicklern? Wir haben dazu Marten Schönherr, Gründer und Geschäftsführer der Automat Berlin GmbH, befragt.
Detecon: Entwickler können sowohl mit Telcos also auch mit Hyperscalers, die die Anwendungen der Entwickler global nutzen, zusammenarbeiten. Was bringen Telcos als Mehrwert in die Zusammenarbeit ein?
Schönherr: Die Terminologie, die von Telcos verwendet wird, verdeutlicht bereits die Trennung, die zwischen der Developer Community und Telcos besteht. Entwicklern sind Begriffe wie Hyperscalers und OTTs unbekannt. Mit dem Begriff „Developer Community“ setzt sich dies fort, hier müssten Telcos viel genauer differenzieren. Ein Entwickler kenn sich auch nicht mit den Umsatzquellen der Telcos oder der Telekommunikationsindustrie im Allgemeinen aus. Daher ist es wichtig, Entwickler wie Kunden zu betrachten. Und natürlich spielt Empathie – wie immer in einer Partnerschaft – eine wichtige Rolle.
Um nun eine strukturierte Diskussion darüber zu führen, welchen Mehrwert Telcos der Developer Community bieten können, muss im ersten Schritt ein Verständnis dafür geschaffen werden, was die Entwickler brauchen. Developer Communities sind ganz klar inhaltlich getrieben. Deshalb müssen Telcos sich vorab zum Beispiel diese Fragen stellen, bevor eine relevante Value Proposition in Richtung Developer Community entwickelt werden kann:
- Wie informieren und bilden sich Entwickler weiter? Dabei sollte unterschieden werden, ob sie allein oder im Auftrag eines Unternehmens unterwegs sind.
- Wie erreichen wir die Entwickler, die für uns interessant sind?
- Was können wir als Telekommunikationsunternehmen anbieten, das für Entwickler relevant ist?
Wenn also nicht die Gießkanne genommen werden soll, um alle Entwickler auf dem Markt anzusprechen, müssen zuerst Motive und Hintergründe der relevanten Entwickler verstanden werden, um zu definieren, welche Rolle Telcos spielen können.
Können Sie uns ein Beispiel geben, wie eine Beziehung zu Entwicklern aufgebaut werden kann?
Sogar zwei: Twilio und Amazon Web Services (AWS). Twilio bietet Wholesale Services von Telcos, die sie vorab „vergolden“ und dann über APIs anbieten. Twilio hat es damit geschafft, über einen Software Stack mit Produkten von Telcos einen sehr großen Markt zu erschließen. AWS kann mit seiner langen Liste an SDKs und APIs ebenfalls die relevante Community bespielen und hat sich damit zum Rechenzentrumdienstleister entwickelt. Das sind zwei Modelle, bei denen sich Telcos etwas abgucken können.
Wie profitieren umgekehrt Telcos von der Partnerschaft?
Sie profitieren von der Zukunftssicherheit. AWS und Twilio sind fett in der Domäne der Telcos. Twilio hat es geschafft, zirka eine Milliarde Umsatz allein mit SMS Services zu generieren. Und das mit nur 1500 Mitarbeitern global. Telcos können aktuell auch nicht mit den Rechenzentrumsleistungen von AWS konkurrieren. Sie sollten Angst haben um ihren Bestand, um ihre Märkte – und davor, keinen Erfolg mit ihren aktuellen Produkten und Services zu haben und somit nicht mehr wettbewerbsfähig zu sein. Wenn Telcos zu spät den Mehrwert erkennen, den sie über die Arbeit mit Software Stacks generieren können, bleiben sie auch zukünftig unattraktiv für Entwickler. Aktuell ist der Entwicklungsansatz von Telcos für Softwarefirmen - und damit Entwickler - nicht praktikabel. Daher sollten sie ihre Produktpalette analysieren und prüfen, welcher Teil umgestellt werden kann, damit er attraktiv ist für Developer Communities. Dies muss dann auch entsprechend vermarktet werden.
Zur Person: Marten Schönherr
Marten Schönherr ist Gründer und Geschäftsführer der Automat Berlin GmbH, die auf Softwareentwicklung im Bereich programmierbare Kommunikation spezialisiert ist und Kunden in Europa und Nordamerika bedient. Marten Schönherr verfügt über 20 Jahre Erfahrung in Forschung & Entwicklung in technischen Domänen, u.a. bei der Deutschen Telekom.
Gibt es weitere Argumente?
Langfristig können Telcos bei einer Zusammenarbeit mit Entwicklern darüber hinaus auch von einer Lernkurve profitieren. Diese Lernkurve resultiert im besten Fall in innovativen Use Cases und damit in der Churn Reduktion. Bei neuen Umsatzpotenzialen muss man vorsichtig sein. Neuen Umsatz zu generieren ist ein langer Prozess und selbst dann ist das Umsatzpotenzial zuerst relativ klein und rechtfertigt selten die Investition.
KPN beispielsweise ist eins der ersten Telekommunikationsunternehmen, das einen eigenen API-Shop aufgebaut hat. Darüber wird aktuell eine Fax API für Geschäftskunden vertrieben. Die Idee ist vielleicht nicht sehr kreativ, aber dafür sehr erfolgreich. Der Vertrieb spielt dabei eine wichtige Rolle und muss ebenfalls eine Lernkurve erleben. Das Potenzial für ein API-Angebot für Start-ups wurde vom eigenen Vertrieb nicht gesehen, da der Business Case kurzfristig nicht profitabel war. Telcos verkaufen heute lieber ihre SMS an Twilio, weil der Business Case für den Aufbau eines Software Stacks kurzfristig keinen Umsatz generiert.
Was müssen Telcos tun und welche Fähigkeiten müssen sie besitzen, um erfolgreiche, nachhaltige Partnerschaften mit externen Developer Communities aufzubauen?
Telcos müssen im ersten Schritt Leute einstellen, die Entwickler verstehen, die sich in dem Bereich auskennen und eine Affinität für das Entwickeln von Software haben. Zum Beispiel muss eine API-Dokumentation klar und strukturiert sein, damit Entwickler schnell finden können, was sie benötigen. Die Dokumentation auf Hochglanz zu bringen ist zweitrangig. Telcos sollten bei der Entwicklung eines Offerings lieber klein und spitz anfangen als generisch die komplette Developer Community andressieren zu wollen. Das kann in Form eines kleinen Events mit zehn Leuten passieren. Falls ein erstes Event nicht gut läuft, kann man daraus lernen und die nächste Veranstaltung besser machen. Telcos sollten auch auf keinen Fall auf einem solchen Event versuchen, ihr Produkt zu verkaufen. Ein Produkt sollte mit dem Feedback aus diesen Events Schritt für Schritt entwickelt werden. Erst wenn genug Anforderungen aufgenommen wurden und die Relevanz für die Entwickler klar ist, sollte das Produkt gebaut werden.
Telcos müssen neue Use Cases entwickeln, die für Entwickler relevant sind. Der alte Ansatz, bei dem ein Produkt erst fertig gebaut wird, bevor es angeboten wird, muss umgestellt werden. Telcos laufen sonst Gefahr, etwas zu entwickeln, dass Entwickler gar nicht brauchen. Erste Ideenansätze reichen aus, um sie über relevante Kanäle wie MeetUps und Konferenzen zu verproben. Der Preis allein reicht nicht aus, um Entwickler für sich zu gewinnen. Preis UND Qualität sind entscheidend.
Welche Rolle sollten Telcos zukünftig einnehmen, wenn es um die Zusammenarbeit in externen Ökosystemen mit Entwicklern und anderen Partnern geht?
Telcos sollten die Rolle des Partners/Enablers einnehmen, wenn sichergestellt werden kann, dass beide Seiten ein Interesse an dem Erfolg der Partnerschaft haben. Dies ist der Fall bei der gemeinsamen Entwicklung von Use Cases. Wenn aber von Anfang klar ist, was benötigt wird, nimmt die Telco eher eine Lieferantenrolle ein und der Entwickler ist als Kunde zu betrachten.
Gibt es Positiv- und Negativbeispiele von derartigen Partnerschaften?
AWS hat zu Anfang viel kostenlos an Entwickler rausgegeben, um sie mit diesen Services zu ködern. Entwickler wollen Services erst ausprobieren und den Mehrwert für sich analysieren. Daher ist es wichtig, trotz kommerziellen Interesses, die Infrastruktur zu Beginn umsonst anzubieten. Erst wenn Entwickler Geld mit den Services verdienen, sind sie in der Lage, auch Geld für Services zu zahlen. Telcos sollten für sich definieren, wie viel sie bereit wären, kostenlos bereitzustellen.
Es gibt einige Beispiele von Telcos deren API Bestrebungen zu früh dran waren und dabei aktiv aus Angst vor Spam und Kannibalisierung von innen verhindert wurden (SMS und Telefonie APIs). Das Beispiel von KPN ist positiv in dem Sinne, dass das Projekt durchhält. Auf der anderen Seite machen sie nicht die erwarteten Umsätze. Hier ist ein klassischer Fehler passiert. Das API Team musste Umsatzziele versprechen, die total unrealistisch sind, um das Projekt umsetzen zu dürfen. Das macht das Image solcher Projekte intern schlecht.
Vielen Dank für das Interview!
