Unser Team von Railslove arbeitet seit über 10 Jahren mit Startups. Diese oftmals wilden Abenteuer
sind genau das, was uns als Team antreibt und ausmacht: Wir lieben es strategische Partner zu sein
und ein gutes Gründer-Team durch alle Höhen und Tiefen zu begleiten. Unser Auftrag hört dann nämlich
nicht bei Design oder Entwicklung auf und wir können ausspielen, was uns von anderen Teams
unterscheidet: Wir übernehmen die volle Verantwortung für die Produkte und Unternehmen, die wir
mit vorantreiben. Lange Zeit waren wir dabei im Spannungsfeld zwischen Startups und VCs auf Seiten
der Gründer unterwegs, unterstützen die jungen Unternehmen bei ihrem Wachstum und wurden so im
Rahmen von Investitionsrunden als Team selbstverständlich auch Due-Diligence-Prüfungen unterzogen.
Der Anspruch an richtig gute Software-Entwicklung in den Prüfungen gefiel uns, so dass wir fortan
begannen auch mit VCs zu arbeiten, um ihnen durch unsere Mithilfe in Tech DDs anstehende Investments
abzusichern.
Tech DD as a Service
Seit einiger Zeit arbeiten wir daher u.a. mit dem High-Tech Gründerfonds (HTGF) als externes
Gutachter-Team zusammen und beleuchten im Doppel mit den Analysten der VCs Technik, Team und
Prozesse aktueller Deal-Kandidaten. Unsere tägliche Arbeit als Entwicklungsteam im Startup-Umfeld
ist dafür der beste Hintergrund: Wir sprechen die Sprache der Gründer und Entwickler, wissen um
Aufwände und Risiken in einer Roadmap und Kalkulation, erkennen die Anzeichen für zukünftige
Team-Probleme und wir können z.B. in Architektur-Fragen nicht nur bewerten, sondern gleich beraten
– und so endet ein Tech DD mit uns nicht selten in einem Mentoring mit den Gründern, statt schlicht
und distanziert nur “die Sache” zu beurteilen.
Lessons Learned
Wir haben in den Tech DDs zahlreiche spannende Dinge gelernt, die wir durchgeführt haben. Hier sind
sechs Dinge, die jedes Startup in dieser wichtigen Phase beachten sollte:
1. Agile Denkweise vs. Scrum/Kanban/Whatever
Wenn man Teams fragt, ob sie agil arbeiten, sagen prinzipiell alle “Ja na klar, wir machen X” und
sie meinen damit in vielen Fällen ein Vorgehensmodell wie Scrum eines ist. Doch fängt da agile
Softwareentwicklung überhaupt erst an: Werden überhaupt agile Produktentscheidungen getroffen? Wie
werden User in die Produktentwicklung eingebunden und werden schon früh Ideen und Entwürfe
validiert? In welcher Reihenfolge wird ein großes Produkt ausgerollt und wie sehen die
Zwischenschritte auf dem Weg bis zum Ziel aus? Wenn man es über lange Zeit trotz Scrum-Prozess nicht
schafft viele kleine, inkrementelle Produkte zu shippen, dann arbeitet man nicht agil.
1. Wann hat ein Prototyp ausgedient?
Einige unserer erfolgreichsten Startup-Kunden der Vergangenheit kamen mit wilden, selbst
zusammengesteckten Produkten auf CMS-Basis zu uns, die zwar halb auseinanderfielen und einen irren
manuellen Aufwand für die Gründer bedeuteten, aber eines ganz sicher bewiesen haben: Das Produkt
funktioniert und der Umsatz läuft. Wir sind große Fans dieses Ansatzes, schnell mit einfachen
Mitteln Produkte auszuprobieren, Kunden einsammeln, lernen, skalieren. Gründer dürfen dann nur nicht
den richtigen Zeitpunkt verpassen, an dem der Prototyp weggeworfen werden sollte und das Produkt
technisch neu aufgezogen gehört. Skaliert man auf einer wackeligen Basis, so fängt alles nur noch
mehr an zu wackeln bis es schließlich auseinanderfällt.
2. Skalieren heißt auch loslassen
In vielen guten Gründer-Teams findet sich bereits solide Tech-Kompetenz. Der CTO ist dann häufig für
die ersten Code-Zeilen verantwortlich und baut in frühen Phasen das Produkt im Alleingang. Um dann
allerdings mit frischem Geld Fahrt aufnehmen zu können und als Unternehmen zu wachsen, muss man als
Tech-Gründer auch loslassen können, neue Entwickler einstellen, ausbilden und sein Produkt und die
Code-Verantwortung auch in fremde Hände geben. Gründer, die zu sehr an ihrem Produkt klammern, haben
viel größere Schwierigkeiten zu wachsen.
3. Wenn man das Gefühl hat fertig zu sein, ist man bei 80%
Fragt man Gründer-Teams “… und wie weit seid ihr gerade auf dem Weg bis zum Launch?”, dann hört man
alles, aber nichts davon stimmt. Das liegt schlicht daran, dass niemand Aufwand und Fortschritt von
IT-Projekten exakt richtig einschätzen kann. Die Kunst ist also eine Ahnung davon zu haben, wie sehr
man mit seiner Schätzung daneben liegt bzw. wie sehr man ihr Vertrauen kann. Dazu eine einfache
Grundregel: Wenn man sich eine Roadmap aufstellt und deren Aufwand bis zum Ende durchschätzt, dann
entspricht das nicht 100% des anstehenden Aufwandes, sondern maximal 80%. Denn man muss sich einfach
im Klaren darüber sein, was es bedeutet ein neues Produkt zu launchen: Das Finishing einer App rund
um einen Launch mit all seinen Beteiligten und Prozessen, das sind Aufwände, die schnell mal unter
den Tisch fallen. Wenn Euch hier die Erfahrung fehlt, sprecht mit Leuten, die schon mal Produkte auf
den Markt gebracht haben.
4. Recruiting-Realität
“Wenn wir das Investment kriegen, stellen wir drei Entwickler ein…” – So etwas hören wir häufiger
von Gründern. Nur gibt es tendenziell eh zu wenig gute Entwickler auf dem Markt und als Startup kann
man sich zudem die richtig guten auch kaum leisten. Mit Glück findet man ambitionierte Einsteiger,
die man mit auf die Reise nehmen und ausbilden kann. Aber auch hier ist die Konkurrenz zwischen den
Unternehmen hart. Untermauert solche Aussagen also am besten mit bestehenden Kontakten, laufenden
Gesprächen, echten Kandidaten – sonst sind sie unglaubwürdig.
5. Mehr Tech-Strategie, weniger Hype
“In unserem Projekt setzen wir X ein, weil unser Team Bock drauf hatte und das schon immer mal
ausprobieren wollte..” – Ja, das kennen wir, wir sind ja schließlich auch Entwickler und möchten
immer lernen und experimentieren und besser werden und Spaß haben an der Sache. Gerade in Frühphasen
können derart getroffene Tech-Entscheidungen jedoch ganz schön Stress bereiten: Durch die fehlende
Erfahrung mit der Technologie können Aufwände explodieren und sich die Zeit bis zum Launch völlig
ohne Not verzögern. Mit jeder weniger gewöhnlichen und bekannten Technologie im eigenen Stack
schafft man sich außerdem weitere Hürden beim Recruiting neuer Entwickler – was ja eh schon schwer
genug ist! Daher unser Rat: Häufig fährt man mit “abgehangener”, etablierter Technologie zum Start
deutlich besser. Für Experimente ist dann später noch Luft, wenn man erst einmal ein gutes Produkt
am Start hat.
Ihr seid ein Startup-Team und bereitet Euch gerade auf eine Investmentrunde vor? Wir beraten
Gründer-Teams unverbindlich und kostenfrei. Sprecht uns an!
