Ein unerwartetes Projekt: Rückblick auf 20 Jahre Arbeit mit Startups im Technologiesektor

Vor fünf Jahren haben wir eines der ungewöhnlichsten, aber zugleich auch spannendsten Projekte in Angriff genommen, das wir je durchgeführt haben, denn es hat uns geholfen, mehr und Besseres über unsere Kunden zu erfahren und ihnen dabei zu helfen, bei ihren technologischen Entscheidungen den richtigen Weg einzuschlagen. Interessanterweise kam die Anfrage von jemandem, der damals nicht einmal wie ein typischer Kunde wirkte: einer sehr großen Venture-Capital-Firma aus den Vereinigten Staaten. Diese Firma hatte eine Investitionsrunde für eines der Start-ups geleitet, das wir mit aufgebaut hatten, und da sie wussten, dass wir sehr eng mit ihnen zusammengearbeitet hatten, stellten sie uns eine faszinierende Frage: „Ihr habt mit vielen Start-ups gearbeitet – speichert ihr Daten über alles, was ihr tut?“

‍

In diesem Moment vermutete ich, dass sie etwas kaufen wollten, das wir für ein Start-up entwickelt hatten, das in der Vergangenheit gescheitert war. Ich dachte über die Konsequenzen nach: Unsere Arbeit ist zu 100 % vertraulich, und wir hatten mit unseren Kunden Geheimhaltungsvereinbarungen unterzeichnet, sodass es wenig Sinn machte, das Gespräch weiterzuführen – außerdem würde ich niemals meine über 20-jährige Karriere aufs Spiel setzen. Also antwortete ich etwas misstrauisch: „Ja, aber diese Informationen sind nicht verfügbar.“

‍

Der Mann fragt mich ziemlich eindringlich noch einmal: „Kennst du den Begriff ‚Muster‘?“

‍

Als ehemaliger Dozent für Software-Design antwortete ich selbstbewusst: „Natürlich, ich habe dieses Konzept 18 Jahre lang unterrichtet.“

‍

Er fuhr fort: „Nun, ich würde gerne herausfinden, ob sich im gesamten Code und in anderen Informationen, die ihr habt, Muster erkennen lassen, die bei erfolgreichen Start-ups immer wieder auftauchen. Wenn du denkst, dass das möglich ist, lass uns in ein paar Tagen darüber sprechen…“

‍

Ich war zugleich verblüfft und begeistert; ich hätte nicht gedacht, dass das seine Absicht war, aber plötzlich fand ich die Idee fantastisch. Erfolgsfaktoren im Verhalten der Start-ups zu finden, mit denen wir in der Vergangenheit zusammengearbeitet haben … genial!

‍

Nachdem ich lange darüber nachgedacht hatte, nahm ich seinen Vorschlag einige Tage später an, allerdings mit einer interessanten Wendung: „Lass es uns tun, aber darüber hinaus wollen wir eine Aufgabe angehen, die wir für noch nützlicher halten: Wir wollen herausfinden, welche Gemeinsamkeiten gescheiterte Start-ups aufweisen.“ Unsere Logik: Scheitern kommt häufig und in großer Zahl vor, während Erfolg ein seltenes Ereignis ist – oder besser gesagt: eine Seltenheit. 

‍

Zum Hintergrund: Wir unterstützen Start-ups bereits seit 26 Jahren. Wir haben angefangen, als man sie in Lateinamerika noch gar nicht so nannte. Wir begannen mit einigen „Vorgängern“ heutiger Lösungen wie Bumeran (eine lateinamerikanische Version von Match.com) oder Yahoo Encuentros (die Vintage-Version von Tinder) und helfen weiterhin vor allem in Argentinien und den Vereinigten Staaten weiteren Unternehmen bei der Entwicklung ihrer Produkte. Diese langjährige Erfahrung ermöglichte es uns, sowohl die Gründer bei ihren Entscheidungen zu unterstützen als auch die Besonderheiten zu berücksichtigen, die mit der Entwicklung von Technologie für ein Unternehmen einhergehen, das noch nicht erfolgreich ist und viele Male „umschwenken“ wird, bis es sein Ziel erreicht (oder scheitert). Aus verschiedenen Gründen, von denen viele endogen und andere weniger endogen sind, weist unser Portfolio eine Erfolgsquote auf, die etwas mehr als das Zehnfache des regionalen Marktdurchschnitts beträgt, und genau das machte uns für die Durchführung der Studie interessant.

‍

Um die Analyse durchzuführen, haben wir mehrere Experten aus dem Digbang-Team zusammengebracht. Wir alle arbeiten seit vielen Jahren im Bereich Technologie und Daten, hatten aber das Glück, eine unserer Führungskräfte in unseren Reihen zu haben, die über eine mathematische Ausbildung verfügt. Mit ihrer Hilfe entwickelten wir eine kleine Untersuchungsmethode, bei der wir durch die Analyse von Code, Analysen und Projektverfolgung schließlich ermittelten, welche unabhängigen Variablen als Prädiktoren am relevantesten waren, um die Gruppe der erfolgreichen und die Gruppe der erfolglosen Fälle zu bestimmen.

‍

Da es sich um eine interne Studie handelt, gibt es eine gute und eine schlechte Nachricht. Die schlechte: Wir können sie nicht veröffentlichen. Die gute: Im vergangenen Jahr erhielten wir die Erlaubnis, einige Daten zu dem, was wir als „Fail-Predictors“ bezeichnen, zu veröffentlichen. Hier sind einige der Erkenntnisse, die wir am interessantesten fanden, zusammen mit ein paar tragikomischen Geschichten, die wir erlebt haben. Die Stichprobe, die wir für die Studie herangezogen haben, umfasste 130 Startups aus verschiedenen Branchen und unterschiedlicher Größe – ungefähr die Anzahl der Unternehmen, denen wir bis dahin bei ihrer Entwicklung geholfen hatten – und die sowohl von technischen als auch von nicht-technischen Gründern geleitet wurden.

‍

Erste Schlussfolgerung: Startups, die sich stärker auf die Technologie als auf den Nutzer konzentrierten, scheiterten dreimal häufiger (mit Ausnahme von DeepTech-Unternehmen).

Ein recht ungewöhnliches Beispiel, das diese Schlussfolgerung verdeutlicht, war ein Unternehmen, das uns dazu veranlasste, einen Stresstest durchzuführen, um nach sechs Monaten 200.000 Nutzer pro Tag bewältigen zu können. Die Realität sah jedoch – jenseits der Fantasien des CTO – so aus, dass die höchste Nutzerzahl in der gesamten Geschichte des Startups 3.000 Nutzer pro Tag nicht überstieg. Ein weiteres ähnliches Beispiel: Ein sehr bekanntes Start-up (mit einer Investition von über 20 Millionen), das wir von Grund auf aufgebaut hatten, stellte einen CTO ein, der das gesamte Produkt in seiner Lieblingssprache neu programmierte. Er brauchte dafür ein ganzes Jahr und setzte ein Team ein, das dreimal so groß war wie das, das das Produkt ursprünglich entwickelt hatte – und das Start-up schloss weniger als ein Jahr später seine Pforten.

‍

Zweite Schlussfolgerung: Der Unterschied zwischen erfolgreichen und erfolglosen Start-ups hinsichtlich der Anzahl der Änderungen, die in den folgenden 12 Monaten am ursprünglichen Prototyp (oder Plan) vorgenommen wurden, war enorm … mehr als viermal so groß.

Ein Beispiel hierfür war ein Blockchain-Startup, das seine „MVP-Phase“ um 21 Monate verlängerte und dabei praktisch das gesamte Produkt, das wir in der Discovery-Phase entworfen hatten, fertigstellte, um bei der Markteinführung ein „unschlagbares“ Produkt zu haben. Das Warten zahlte sich nicht aus: Zwei Monate nach der Markteinführung überstieg der Aufwand für die notwendigen Änderungen, um das „ideale Produkt“ an die Bedürfnisse der ersten Nutzer anzupassen, bereits sechs Monate Arbeit, und nach zehn Monaten wurde das Team aus Budgetgründen verkleinert.

‍

Dritte Erkenntnis: Mehr als 70 % der gescheiterten Startups haben fast 20 % ihres Codes für Funktionen verschwendet, die sie nicht nutzen (oder die nur von 5 % ihrer Nutzer genutzt werden).

Als ich versuchte, mich an eine Anekdote zu dieser Aussage zu erinnern, passierte mir etwas Seltsames. Das Problem ist so allgegenwärtig, dass ich mich auf keine bestimmte Anekdote konzentrieren kann. Im Allgemeinen lassen sich zwei Gruppen unterscheiden: diejenigen, die voreilig Dinge entwickeln, die sie nie nutzen, und diejenigen, die jedes Szenario verallgemeinern wollen und dabei zweifellos einen äußerst eleganten, wartbaren und skalierbaren Code erstellen – sie würden an der Universität eine 10 bekommen, aber für diese Szenarien ist das sehr unrealistisch.

In all diesen Fällen besteht unsere Aufgabe nicht nur darin, diesen Unternehmen dabei zu helfen, ihre Produkte zu konzipieren und zu entwickeln, sondern auch darin, sie so zu beeinflussen, dass sie von solchen Vorurteilen nicht beeinträchtigt werden. Unserer Erfahrung nach ist es einfacher, Unternehmen positiv zu beeinflussen, deren Gründer kein Techniker ist, sowie solche, in denen ein technischer Gründer eine erfolgreiche Laufbahn als CTO vorweisen kann (und dabei keine Rolle als Programmierer im Projekt einnimmt). 

Wir haben verschiedene Theorien, warum das so ist, aber das würde einen Artikel erfordern, der noch länger wäre als dieser hier, und wir haben uns schon einige Feinde gemacht, als wir sie erwähnt haben … also behalten wir sie lieber für persönliche Gespräche unter vier Augen und vermeiden es, öffentlich darüber zu sprechen, damit uns niemand an den Kopf springt ;)

‍

Demian Schnaidman ist CEO bei Digbang. Hier kannst du dich mit Demian in Verbindung setzen.

‍

‍