Tech für Gründer: Was du als Founder wissen musst, Chris Philipps, Philipps & Byrne

 (00:00:01) Herzlich Willkommen zu einer neuen Folge bei Unicorn Bakery. (00:00:04) Mein Name ist Fabian Tausch und heute sprechen wir über die Tech-Due Diligence bei Finanzierungsrunden. (00:00:10) Was wollen Investoren eigentlich von dir als Gründer wissen? (00:00:13) Wie bereitest du dich und deine Firma darauf vor? (00:00:15) Und was sind so die häufigsten Fallstricke bei Tech-DDs? (00:00:20) Der Einfachheit halber werden wir Due Diligence durch DD abkürzen in häufigen Fällen, glaube ich. (00:00:25) Bei mir ist heute Chris Phillips von Phillips & Byrne. (00:00:29) Spezialisiert auf Tech-DDs, also sehr tief auch einzusteigen. (00:00:35) Sowohl von Gründerseite beauftragt, als auch von Investorenseite beauftragt. (00:00:38) Auch für M&A und andere DDs, wann immer es nötig ist. (00:00:43) Wann immer man sich das anschaut. (00:00:45) Wir fokussieren uns heute auf Finanzierungsrunden, weil sonst müssen wir so viele Sachen parallel betrachten, dass es glaube ich zu vielschichtig wird. (00:00:52) Chris, schön, dass du heute hier bist. (00:00:54) Ja, freut mich Fabian, danke für die Einladung. (00:00:56) Erzähl mal so ein bisschen, wie bist du eigentlich in diese ganze Venture-Welt reingerutscht? (00:00:59) Und dann gucken wir uns mal so ein bisschen mehr Phillips & Byrne und Tech-DDs an. (00:01:04) Ja, ich war ursprünglich mal Geisteswissenschaftler in einem früheren Leben. (00:01:08) Und habe mir dann im Jahr 2000 diese erste große Dotcom-Welle angesehen. (00:01:15) Und ich werde das nie vergessen. (00:01:17) Ich saß zu Hause irgendwo, während ich studierte und las diese ganzen News und irgendwelche Exits und Finanzierungsrunden und Startups. (00:01:24) Ich glaube, Orlando war damals gerade relativ groß. (00:01:28) Und ich merkte einfach, was da für eine Energie drin steckt. (00:01:30) Und dann habe ich mir so gedacht, da will ich Teil von sein. (00:01:33) Und dann bin ich kurz entschlossen Fachinformatiker geworden. (00:01:36) Und habe dann auch direkt in Startups gearbeitet. (00:01:39) Habe auch den Dotcom-Tod im 2001-2002 damals live mitgemacht als Mitarbeiter. (00:01:45) Und bin dann aber in der Branche geblieben. (00:01:48) Und jetzt seit über 20 Jahren mit dabei. (00:01:50) Über 10 Jahre als Interim-CTO aktiv gewesen in verschiedenen Startups. (00:01:55) Und bin dann irgendwann, nachdem ich einige DDs auf CTO-Seite, also auf der anderen Seite des Tisches mitgemacht habe. (00:02:03) Und mich ehrlich gesagt regelmäßig darüber geärgert habe, was für eine Zeitverschwendung das ist. (00:02:08) Habe ich mir gedacht, Mensch, das muss doch anders gehen. (00:02:11) Das muss auch mit mehr Mehrwert gehen, auch für die Startups. (00:02:14) Nicht nur für die Investoren-Seite. (00:02:16) Und das muss doch auch praxisnäher gehen. (00:02:19) Und daraufhin habe ich mich entschieden, selber Tech-DDs zu machen. (00:02:23) Bin von Investoren auch gefragt worden, ob ich für sie Tech-DDs mache. (00:02:26) Bin dann da eingestiegen und habe das im Laufe der Jahre immer weiter professionalisiert. (00:02:30) Was waren so die Sachen, die dich am meisten genervt haben, an wie DDs damals funktioniert haben? (00:02:35) Ja, ich hatte so einen Schlüsselmoment, den ich auch tatsächlich öfter mal zitiere. (00:02:39) Ich habe mal in einer DD gesessen mit einer großen internationalen Beratungsgesellschaft auf der anderen Seite und bin dann gefragt worden, welche DIN-Norm das Schloss zur Tür des internen Serverraums erfüllt. (00:02:54) Also das war wirklich so ein What-the-Fuck-Moment für mich, weil ich gedacht habe, was bitte hat das denn jetzt mit Skalierung von Startups zu tun? (00:03:02) Und das war wirklich so ein Turning Point, wo ich gesagt habe, okay, das muss besser gehen und das muss praxisnäher gehen. (00:03:09) Wir machen zum Beispiel bis heute eigentlich keine internen, Internal-IT-DDs, nur wenn wir danach ausdrücklich gefragt werden, weil wir einfach sagen, das ist kein entscheidendes Kriterium für den Erfolg eines Startups. (00:03:22) Wie differenzieren wir Internal-IT-DD von Tech-DD? (00:03:26) Also nur, dass wir das mal kurz aufgliedern können. (00:03:28) Ja, also Internal-DD ist klassisch so zum Beispiel, wie sieht das Netzwerk, die Netzwerkinfrastruktur in einer Firma aus? (00:03:34) Welche Computer haben die? (00:03:36) Und natürlich gibt es auch bestimmte sicherheitsrelevante Sachen, die vielleicht irgendwie einen Einfluss haben können. (00:03:41) Aber das ist in der Regel nicht das, was wirklich entscheidend ist. (00:03:44) Und Tech-DD ist dann eher der gesamte Prozessor und das wäre so ein Subteil der ... (00:03:48) Wann wird der relevant? Also gibt es dann bestimmt auch noch mal Fälle, oder? (00:03:51) Also klassisch wäre es zum Beispiel bei einem Verkauf. (00:03:54) Da ist es tatsächlich öfters mal der Fall, weil es da natürlich irgendwo zum Teil der Assets dazugehört, weil auch Risiken noch mal ganz anders gewertet werden. (00:04:04) Das könnte so ein Fall sein. (00:04:06) Oder wenn aus irgendeinem Grunde tatsächlich die interne Infrastruktur fest verdrahtet ist mit dem eigentlichen Business. (00:04:13) Lass uns mal Tech-DD gesamtheitlich aufrollen. (00:04:15) Was bedeutet das denn eigentlich, wenn ich das jetzt höre? (00:04:18) Und ein Investor schreibt mir ja, wir müssen jetzt eine Tech-DD machen. (00:04:20) Eine Tech-DD ist eigentlich nichts anderes als ein sehr gründliches Assessment des Status Quo und auch ein Stück weit des Potenzials und der Risiken einer Firma. (00:04:31) Und in der Regel umfasst das Bereiche wie die Organisation, die Technik an sich und bestimmte andere Bereiche, wie zum Beispiel wir machen grundsätzlich auch den ganzen Produktbereich, Product Management mit und angrenzende Bereiche wie zum Beispiel Data. (00:04:47) Das heißt, man schaut rein, man schaut auf Leadership-Themen, man schaut auf Organisationsstruktur, Skalierungsfähigkeiten, man schaut auf das eigentliche Produkt und wie wird das gebaut. (00:04:59) Man schaut auf Plattformen, auf Architektur, auf Infrastruktur, aber auch auf so etwas wie Development Best Practices zum Beispiel und schaut dann und beantwortet entsprechend die Fragestellungen, die für den Investor im Raum stehen. (00:05:13) Zum Beispiel wie skalierungsfähig ist das Ganze, wie stabil und professionell ist das vielleicht auch schon aufgebaut. (00:05:20) Mit welchen Risiken muss ich dabei rechnen? Das sind so Klassiker. (00:05:23) In welcher Phase, also in welcher Finanzierungsrunde kommst du überhaupt zu einer Tech-DD? (00:05:28) Ist das in der Pre-Seed oder Seed-Finanzierung schon relevant oder wird das erst später relevant? (00:05:32) Wir haben früher so unseren Sweetspot eigentlich bei CSA-Finanzierungen gehabt. (00:05:36) Das war meistens das erste Mal, dass eine Tech-DD ins Spiel kam. (00:05:40) Das hat sich in den letzten Jahren ein bisschen geändert und ich bin da ehrlich gesagt nicht ganz traurig drum. (00:05:46) Früher dachte man eigentlich immer, naja, zu so einer Seed-Phase oder sogar Pre-Seed ist das eigentlich nicht notwendig, weil da ja noch nicht so wirklich viel gebaut ist. (00:05:56) Und gerade in der Start-Up-Szene hat sich Gott sei Dank auch ein Stück der Ansatz gedreht, als was man so eine Tech-DD sieht. (00:06:03) Früher war das eher so ein Cover-Your-Ass-Instrument, also lass uns die Risiken abwägen, dass wir nicht in das Falsche investieren. (00:06:10) Und in den letzten zwei, drei Jahren, und ich glaube, da haben wir auch ein bisschen was zu beitragen können, hat sich das gedreht zu einer Hilfestellung auch ein Stück weit. (00:06:19) Also drauf gucken und sagen, was muss denn noch getan werden, um dem Gründerteam tatsächlich zum Erfolg zu verhelfen? (00:06:25) Was können wir tun, um das Start-Up noch weiter zu skalieren oder einfacher zu skalieren? (00:06:31) Und da kommen wir ins Spiel und da kann es meiner Meinung nach auch gar nicht früh genug sein. (00:06:36) Also da kann man auch in Seed oder sogar Pre-Seed reingehen und dann ist es natürlich, hat es wesentlich mehr Sparring-Charakter, weil man sich viel ansieht, was vielleicht eher noch theoretisch hypothetisch ist oder nur in Grundzügen da ist und man muss eher das Potenzial assessen. (00:06:52) Aber dafür kann man in diesem Sparring-Teil halt viel besser über Möglichkeiten reden und sehr oft werden Gründer das auch als sehr hilfreich empfinden. (00:07:00) Okay, soll ich mit meiner Architektur diesen oder den anderen Weg gehen? (00:07:04) Soll ich jetzt vielleicht erst Person X hiren oder Person oder Rolle Y? (00:07:09) Das sind so Sachen, die man dann viel stärker noch mal in einem Pre-Seed oder Seed Assessment rausstellt. (00:07:14) 2D Legends hat ja oft so diesen Charakter von, oh Gott, jetzt krieg ich so einen Riesenfragenkatalog und ich hoffe, ich stehe den irgendwie durch und kriege einfach meinen Termsheet und kann das Investment mitnehmen. (00:07:23) Du hast jetzt gerade gesagt, es ist ja eigentlich auch oftmals eine Chance, wenn man es in einem guten Sparring auch vielleicht hinkriegt, das abzuwickeln, also auch zu sagen, okay, woran kann man danach arbeiten? (00:07:34) Hast du das Gefühl, alle VCs sehen das als Sparring oder ist das für viele auch so, okay, wo finde ich die Fallstricke, um auch zu sagen, okay, komm, wir machen es nicht? (00:07:41) Nee, ich glaube, in einem VC-Umfeld passiert das relativ wenig, weil, ich meine, wir kommen ja relativ spät in diesem Prozess erst ins Spiel und in der Regel hat so ein VC ja auch schon einige Pitchdecks gesichtet bis dahin und mit vielen, vielen Gründern gesprochen. (00:07:57) Und ich glaube, das ist für alle Investoren dann auch erst mal ein schmerzhaftes Event, den Deal dann so spät noch abzusägen. (00:08:04) Deswegen glaube ich nicht, dass wir ein Grund sind, der vorgeschoben wird, um noch mal auszusteigen aus dem Prozess. (00:08:13) Ich glaube, relativ wenige VCs sehen es tatsächlich, als einen vorgeschobenen Grund, einen Fallstrick zu finden. (00:08:19) Es kann dir natürlich passieren, wenn du jetzt ein wirklich heftiges Skeleton in the closet hast, dass eine Tech-DD noch mal ein Grund dafür ist, dass ein Prozess gestoppt wird. (00:08:32) Aber in den meisten Fällen, gerade in den letzten Jahren, hat es eigentlich dazu geführt, dass VCs immer mehr sagen, okay, was müssen wir tun, um es erfolgreich zu machen? (00:08:42) Und da sehe ich auch eine Chance drin. (00:08:44) Und ich sage mal, eine gute DD ist eigentlich ein Conversation Starter über schwierige Themen zwischen einem potenziellen Investor und den Gründern. (00:08:53) Und ich appelliere mal an Gründer, dass sie das auch so sehen, weil letztendlich ist eine Beziehung zu einem Investor ja so ein bisschen wie Daten. (00:09:01) Du musst ja gucken, ob du auch über schwierige Themen gut reden kannst und letztendlich zu einer Lösung führst. (00:09:08) Und in vielen Fällen sind technische Themen da eigentlich ein guter Einstieg. (00:09:13) Ich gebe mal ein Beispiel. (00:09:15) Eine Idee hat ein total gutes Business-Potenzial, hatte aber vielleicht in der Vergangenheit jemanden auf der CTO-Rolle, der oder die noch nicht ganz so Senior war. (00:09:26) Entsprechend sind technische Schulden angehäuft worden. (00:09:29) Du musst die Plattform jetzt noch mal refactoren und erheblich in Tech investieren. (00:09:33) Und vielleicht dauert es auch noch ein halbes Jahr. (00:09:35) Dann ist das natürlich was, was einen Einfluss auf den Business-Plan hat und worüber im Rahmen von so einer DD gesprochen werden sollte. (00:09:43) Und natürlich ist das ein schwieriges Thema für Gründer und natürlich schwingt da auch die Angst mit, dass vielleicht der Prozess noch mal gestoppt wird deswegen. (00:09:52) Nur manchmal frage ich mich, was ist schlimmer? (00:09:55) Ich habe es auch als Interim-CTO hier und da mal erlebt, dass ein Investment erfolgt ist und erst dann eigentlich die Themen auf den Tisch gekommen sind. (00:10:04) Und ich kann sagen, diese Board-Meetings sind da nicht gerade gemütlich. (00:10:07) Deswegen warne ich Gründer immer ein Stück weit davor, damit zu lange zu warten, sondern eher so eine Tech-DD oder auch allgemeine Investmentgespräche als Gelegenheit zu nehmen, solche Themen zu adressieren und zu schauen, okay, wie ist denn die Streitkultur oder die Konfliktkultur in dem Moment und wie einigt man sich denn? (00:10:27) Ist denn auch auf der Investmentseite ein Verständnis dafür da, gemeinsam Lösungen zu suchen, vielleicht auch nochmal so ein bisschen Spielraum im Business planen zu haben oder wird es dann direkt ungemütlich? (00:10:40) Das wäre natürlich im Jahr 2021 ein etwas einfacheres Thema gewesen, als sich alle Investoren um Investments geschlagen haben. (00:10:51) Das ist jetzt 2023 sicherlich ein bisschen schwieriger, aber trotzdem appelliere ich immer an Gründer, das tatsächlich auch zu tun. (00:11:01) Ja, wie du sagst, man muss die Wahl haben, sonst ist es manchmal ein bisschen schwieriger. (00:11:07) Ich glaube, bevor wir uns so drauf einschießen, was denn so die Sache, die ich als Gründer vorbereiten kann, lassen wir uns mal kurz darüber sprechen, weil ich weiß, dass die Frage bei vielen gerade irgendwie so präsent ist. (00:11:18) Was sind die Dinge, wo ein Investor am Ende doch sagt, das sind wirklich die absoluten No-Gos, wir können den Deal auf gar keinen Fall machen. (00:11:27) Das darf auf gar keinen Fall nicht rauskommen, weil das klingt, als ob man es verstecken müsste, sondern in welchem Zustand darf dann am Ende meine Firma nicht sein, sodass der Investor sagt, schwierig, wollen wir nicht machen. (00:11:38) Es ist sehr, sehr selten die eine Sache. (00:11:41) Meistens ist es ein Zusammenspiel aus verschiedenen Komponenten, die da auftreten. (00:11:46) Um mal ein Beispiel zu geben, das Team ist sicherlich eine ganz starke Komponente. (00:11:51) Wenn jetzt das gesamte Gründerteam inklusive der technischen Co-Founderin oder des Co-Founders nicht gut ist, dann wird das sicherlich ein starkes Argument sein, den Deal zu stoppen. (00:12:04) Wenn es nur eine Person ist und vielleicht auch ein Higher-CTO oder noch ein relativ junges Mitglied des Gründungsteams als technischer Co-Founder, und alle sehen das schon und sagen, da ist eine Bereitschaft da, noch mal eine seniore Person für die CTO-Rolle mit reinzuholen, dann ist das in der Regel kein Dealbreaker. (00:12:26) Genauso ist es mit technischen Schulden. (00:12:28) Das ist immer eine Frage des Kontextes. (00:12:30) Man kann als Start-up technische Schulden haben. (00:12:33) Die sind auch ein Stück weit unvermeidbar. (00:12:36) Die Frage ist, an welcher Stelle man die hat und wie sehr ist man noch handlungsfähig. (00:12:41) Und vielleicht auch in Abgrenzung dazu, wie viel Wettbewerb gibt es vielleicht auch in dem Markt. (00:12:47) Quasi jede Woche zählt, eine Roadmap voranzubringen und Marktanteile zu erobern. (00:12:52) Dann sind so technische Schulden natürlich ein bisschen unangenehmer, als wenn man First Mover in einem Bereich ist und dann entsprechend auch noch irgendwo die Zeit hat und den Leeway, sich um seine technischen Schulden zu kümmern. (00:13:05) Die wiegen dann einfach nicht ganz so viel in so einer Tech-DD. (00:13:09) Was bedeutet in deinen Worten Team nicht gut genug? (00:13:12) Letztendlich ist die Frage, ob das Team die Fähigkeit hat, in die nächste Wachstumsphase zu gehen beziehungsweise die Company dort hineinzubringen. (00:13:25) Das heißt, nicht nur im Hier und Jetzt zu sein und die Anforderungen von Hier und Jetzt zu bewältigen, sondern auch schon zu antizipieren, was muss denn als Nächstes geschehen oder vielleicht sogar als Übernächstes und dafür auch schon die Weichen zu stellen. (00:13:40) Ich gebe mal ein Beispiel, um mal so ein Seed-Start-up zu nehmen. (00:13:45) Da ist es vielleicht noch ein Hands-on-CTO, der oder die noch mitentwickelt und vielleicht ein Team von drei, vier Leuten hat, aber schon weiß, dass das Business ein relativ großes Team erfordert von vielleicht 30, 40, 50 Engineers. (00:14:03) Dann sollten schon Key-Positionen, zum Beispiel dann so Moving Forward in der Series A oder nach der Series A, geheiert werden, um letztendlich vielleicht in zwei, drei Jahren auf dieser Teamgröße zu sein. (00:14:17) Es gibt aber genügend CTOs, die machen es ein bisschen anders. (00:14:20) Die sind dann sehr stark im Hier und Jetzt, weil sie auch selber noch sehr Hands-on sind. (00:14:25) Dann vergessen die das und kümmern sich viel stärker um das Hiring der nächsten und übernächsten Person, was dann meistens Entwickler sind. (00:14:33) Auf einmal haben die eine Herrschaft von Entwicklern und Entwicklerinnen da, aber haben letztendlich zum Beispiel keine Engineering Managers, kein VPN-Engineering oder ähnliche Positionen oder haben vergessen, Produkt mit aufzubauen. (00:14:45) Das meine ich damit mit gut genug. (00:14:47) Also immer die Zukunft zu antizipieren, ein Stück weit strategisch zu denken, egal wie weit man okkupiert ist mit Tagesgeschäft und letztendlich immer die Balance hinzubekommen zwischen so Notwendigkeiten von schneller Time-to-Market, regelmäßiger Delivery auf der einen Seite und auf der anderen Seite aber auch einer ausbalancierten Architektur, die ein Stück weit nachhaltig ist. (00:15:11) Ja, ich glaube, es ist einfach wichtig zu verstehen, dass man da immer überlegen muss, dass man sich selbst auch so self-assessment, wo glauben wir, haben wir aktuelle Schwachstellen und sind die so schwerwiegend, dass wir nicht in die nächste Runde kommen oder dass man sagt, man kann die über die nächsten Wochen und Monate ausgleichen. (00:15:27) Und gleichzeitig muss man immer dazu sagen, nur weil ein VC sagt, das Team ist nicht gut genug, heißt das nicht, dass es alle VCs sagen. (00:15:33) Es ist immer so schmaler Grad natürlich auch von wem und wie man das Feedback annimmt als Gründer. (00:15:37) Aber ich glaube, da muss man so ehrlich wie möglich zu sich selbst sein, weil nur dann kriegt man halt auch hin, dass da was sich verändern kann und daraus was entstehen kann. (00:15:46) Ja, das ist richtig. (00:15:48) Ich sage auch immer, eine Tech-DD ist auch letztendlich ein Anlass für Gründer, sich selber nochmal sehr intensives und vor allem auch sehr ehrliches Feedback zu holen. (00:15:56) Nicht nur von den Investoren, sondern aus der Tech-DD auch selber. (00:16:00) Ich kann auch allen GründerInnen nur empfehlen, sich die Reports zukommen zu lassen und vielleicht auch nochmal mit den Auditoren im Nachhinein zu sprechen und tatsächlich wirklich eine DD als Chance zu nutzen, sehr, sehr intensives und detailliertes Feedback über die eigene Tech zu bekommen und was die Schwachstellen sind und was sie moving forward tun können. (00:16:22) Und da gebe ich dir recht. (00:16:24) Natürlich, je nachdem wie Investoren und Funds aufgestellt sind, können Dinge völlig anders gewichtet sein, die als Findings aus einer Tech-DD rauskommen. (00:16:34) Eine Sache, die ich spannend fand, als wir das das erste Mal besprochen haben, ist, ihr nennt das dann, wenn jetzt ein Gründer auf euch zukommt und sagt, hey, lass uns mal gucken, wo stehen wir eigentlich? (00:16:42) Ihr nennt es Health Checks. (00:16:44) Und ich glaube, alles, worüber wir gerade gesprochen haben, wird recht klar, warum das Sinn macht. (00:16:48) Ja, genau. (00:16:50) Der Name kommt daher, dass mir mal ein Gründer gesagt hat, na ja, klar mache ich das jetzt regelmäßig. (00:16:56) Ich gehe auch zweimal im Jahr zum Zahnarzt. (00:16:58) Und das fand ich einen sehr schönen Vergleich. (00:17:01) Und daher einfach dieser Name, der eigentlich schon klar macht, Mensch, wenn du willst, dass deine Firma gesund bleibt, dann kümmer dich halt regelmäßig darum und hol dir das Feedback auch vor einer Finanzierungsrunde. (00:17:16) Das ist zum Beispiel das, was einige Gründer mit uns regelmäßig machen. (00:17:21) Die kommen auf uns zu. (00:17:23) Oft kommen die auch auf uns zu, nachdem sie mit uns durch eine Tech-DD durchmussten. (00:17:27) Und uns am Ende der Tech-DD sagen, Mensch, wir hatten ja überhaupt keinen Bock auf euch. (00:17:31) Aber das war super gründliches Feedback. (00:17:33) Und dann kommen sie eigentlich ein halbes Jahr später oder ein Dreivierteljahr später wieder und sagen, wir haben in ein paar Monaten nur unsere neue Finanzierungshunde. (00:17:41) Könnt ihr uns helfen, uns darauf vorzubereiten, dass uns dabei nichts auf die Nase fällt. (00:17:46) Und das ist natürlich einerseits ein Kompliment, aber das ist auch sehr weise, glaube ich, das zu machen, weil man dann einfach das Risiko minimiert. (00:17:53) So, was bedeutet das denn, wenn ich als Firma gut aufgestellt bin für eine Tech-DD? (00:17:57) Also worüber habe ich mir Gedanken gemacht? (00:17:59) Das kommt ein bisschen auf den Kontext an und natürlich auch auf die Phase an, in der du bist. (00:18:03) Frühphasisch ist das sicherlich was anderes als in der Growth-Phase. (00:18:06) Aber nehmen wir mal vielleicht eine Frühphase, so Series A ungefähr als Beispiel. (00:18:11) Ich habe mir auf jeden Fall schon mal Gedanken darüber gemacht, was eigentlich meine Storyline ist. (00:18:18) Und zwar nicht nur das, was im Pitch Deck steht, sondern auch, wie die Story weitererzählt wird, wenn ich auf Product und Tech gucke. (00:18:26) Weil das sollte im Idealfall, sollte das aus einem Guss sein. (00:18:30) Das heißt, die Architektur und das Team und auch letztendlich die Qualität der Software sollten reflektieren, was man als Business macht. (00:18:41) Um ein Beispiel zu geben, wenn ich ein B2C-Produkt baue, was, sagen wir mal, ist eine Foto-App oder sowas, die jetzt auch erstmal vielleicht for free ist, dann habe ich vielleicht eine höhere Fehlertoleranz, als wenn ich ein FinTech-Produkt baue. (00:19:01) Das heißt, ich gucke auf unterschiedliche Dinge und das muss in meiner Tech reflektiert sein. (00:19:07) Das ist erstmal das eine, dieser Schulterschluss zwischen Business und Business-Modell und Tech. (00:19:13) Das zweite ist, dass ich mir anschauen sollte, wie sieht denn mein Leadership-Team aus und insbesondere mein Tech- und Product-Leadership-Team. (00:19:22) Brauche ich schon eine CTO-Rolle, brauche ich eine CPO-Rolle oder Head-of-Product, VP-Product-Rolle, Talking-of-Head-of-VP etc.? (00:19:30) Ich sollte auch in der Frühphase vielleicht schon mal so eine erste Idee haben, wie ich denn meine Organisation auch aufbauen will und skalieren will, welche Rollen ich dafür brauche. (00:19:40) Und mal so eine Pi-mal-Daumen-Idee, wie groß denn mein Team später werden soll. (00:19:44) Das muss ich sicherlich nicht auf ein, zwei Leute genau wissen, aber ich sollte eine Vorstellung davon haben, ob ich fünf Leute brauche oder 20 oder 50 in zwei Jahren. (00:19:53) Dann muss ich wissen, wie stabil mein Produkt schon ist, ob ich schon einen Product-Market-Fit auch letztendlich habe oder ob sich vielleicht noch mal alles ändern wird, weil das auch einfach einen starken Einfluss darauf hat, wie ich das baue. (00:20:10) Ich baue es sicherlich wesentlich solider, nenne ich das jetzt mal, und nachhaltiger, wenn ich schon eine hohe Confidence darauf habe, dass ich meinen Product-Market-Fit gefunden habe. (00:20:20) Während wenn Experimentieren noch alles ist und viel Pivoten, dann brauche ich eine viel flexiblere Architektur, aber dann muss das sicherlich auch nicht alles so rock-solid sein, was die Qualität angeht, weil ich genau weiß, es besteht einfach eine hohe Wahrscheinlichkeit, dass ich das alles noch mal wegschmeißen muss. (00:20:37) Ich glaube, eine Sache, die man noch ergänzen muss, worüber wir vorhin gesprochen haben, ist so technische Schulden, also Tech-Debt, sich auch Gedanken zu machen, okay, wo stehen wir da eigentlich? (00:20:48) Das spielt ja sehr viel mit dem zusammen, was du gerade gesagt hast, nur noch mal ein bisschen plakativer. (00:20:54) So haben wir Sachen gemacht, wo wir wissen, es ist so ein Workaround und es ist einfach nur, weil wir es jetzt gerade nicht final auflösen konnten und wir mussten es aber schnell liefern, versus haben wir Sachen sehr strukturiert, sehr klar von Tag 1 an gebaut und sich auch wirklich überhaupt mal Gedanken zu machen, wo stehen wir eigentlich produktseitig? (00:21:12) Ich glaube, das vernachlässigen viele und sagen, okay, wir sind jetzt hier und wir machen es von da aus weiter. (00:21:17) Aber wenn man das zu lange macht, kann das natürlich auch problematisch werden. (00:21:21) Bei Tech-Debt unterscheidet man ja auch noch mal zwischen ungeplanten und geplanten Schulden beziehungsweise auch zufälligen Schulden. (00:21:29) Und ich glaube, dass immer noch viele Founders nicht genau wissen, was das ist. (00:21:34) Ich glaube, mittlerweile hat jeder diesen Begriff schon mal gehört. (00:21:38) Und die Analogie zu finanziellen Schulden ist ja auch relativ eingängig. (00:21:42) Aber es ist ja immer die Frage, wie wissentlich ist man bestimmte Kompromisse eingegangen, hat dabei technische Schulden erzeugt und vor allem auch, wo sind die? (00:21:53) Es gibt Stellen, das interessiert mich überhaupt nicht. (00:21:56) Da kann ich perfekt fünf Jahre mit meinen technischen Schulden leben. (00:22:00) Und an anderen Stellen, die ich sehr, sehr oft anfassen muss, hat das einen enormen Impact auf die Produktivität meines Teams. (00:22:07) Das ist aber eine Diskussion, die selten zwischen nicht-technischen Gründern und technischen Gründern oder CTOs geführt wird. (00:22:18) Und deswegen ist das eine Black Box für die meisten Founders. (00:22:22) Du meinst, was dann wirklich relevant ist, was man fixen muss und was man behalten kann? (00:22:28) Was wir doch immer haben im Startup-Umfeld ist die Diskussion Time-to-Market. (00:22:32) Ich muss das jetzt ganz schnell auf die Straße bringen. (00:22:35) Und das ist nun mal in den meisten Fällen die oberste Prämisse. (00:22:39) Das ist erst mal fein. (00:22:41) Nur ich muss immer eine Diskussion darüber haben, um welchen Preis ich das tue. (00:22:46) Wenn ich zwei Monate eher auf die Straße bringen kann und ich muss dann noch mal ein, zwei Monate aufräumen und die ein, zwei Monate hinten dran, die bringen mich nicht um, dann ist ja alles fein. (00:22:58) Wenn ich das aber als generelle Geisteshaltung betreibe, grundsätzlich alles quick and dirty auf die Straße zu bringen, ohne mir sozusagen dieses Rückzahlen von Schulden mit einzuplanen, dann komme ich einfach in eine Situation, wo ich technisch tatsächlich irgendwann den Bankrott erkläre. (00:23:19) Und das sehen wir tatsächlich auch in TechD-Days immer noch. (00:23:23) Das ist sicherlich besser geworden, weil einfach viel mehr Awareness in den Founderteams auch mittlerweile da ist und auch auf Investorenseite. (00:23:30) Nichtsdestotrotz, das ist nach wie vor noch ein Thema, dass diese Diskussion in Startups oft nicht stattfindet oder nicht im Vorfeld. (00:23:39) Und erst eigentlich hinten dran, wenn man schon ein halbes Jahr an seinen technischen Schulden herum oder drumherum laboriert. (00:23:46) Was ist dann eure Empfehlung? (00:23:48) Also wenn ich jetzt als Gründer zurückkomme und sage, ich weiß, ich habe die Diskussion lange nicht geführt, wie kriege ich das denn gerade gebogen? (00:23:55) Na ja, dazu brauche ich zuallererst mal ein bisschen Seniorität im Tech-Team. (00:24:03) Und das ist auch so ein Thema, was wir gerade im deutschen oder mitteleuropäischen Raum sehr oft sehen im Vergleich zu UK oder zu den USA. (00:24:15) Hier wird oft noch an Seniorität in den Frühphasen gespart. (00:24:20) Und dann, manchmal nenne ich das Jugendforscht. (00:24:24) So soll nicht abfällig gemeint sein, aber viele junge Teams bei uns lernen immer noch durch Trial and Error. (00:24:31) Und das ist natürlich extrem teuer. (00:24:33) Das ist in manchen Bereichen okay. (00:24:35) Aber ich brauche zumindest so ab Seed, Pre-Series A, auch ein paar sehr Seniore Leute im Team, die genau solche Diskussionen führen und sagen, okay, wir haben jetzt hier folgende technische Schulden angehäuft. (00:24:49) Wir haben auf der anderen Seite die und die Business-Ziele. (00:24:52) Wie kriegen wir diesen Spagat jetzt hin? (00:24:54) Welche Schulden sind vielleicht erst mal egal? (00:24:56) Die packen wir mal zur Seite, die ignorieren wir. (00:24:58) Oder um was müssen wir uns kümmern? (00:25:00) Und dann ist eben immer die Frage, wie kommen wir da jetzt raus, ohne dass die Kiste erst mal ein halbes Jahr stillsteht? (00:25:06) Weil das können sich die meisten Startups nicht leisten. (00:25:09) Sondern man macht das ja heute schrittweise. (00:25:12) Dass man in einem kleinschrittigen Approach, in dem man gleichzeitig Business-Value generiert, sich langsam aus technischen Schulden herausarbeitet und Innovationen stückweise einbaut, um dann letztendlich über einen Zeitraum von sechs Monaten, zwölf Monaten, 24 Monaten zu einer neuen Zielarchitektur zu kommen. (00:25:31) Dazu braucht man aber auch einfach die Erfahrung und die Seniorität, um sowas leisten zu können, während das Business weiterläuft. (00:25:39) Ich glaube, das ist auch so ein Riesenthema. (00:25:41) Wenn ich weiß, ich habe Tech-Dapp, dann gleichzeitig weiß ich, okay, wir müssen irgendwie weiter vorankommen. (00:25:46) Und irgendwie weiß ich, es wird schlimmer. (00:25:48) Aber wenn es schlimmer wird, wird es problematisch. (00:25:50) Und das so, glaube ich, alleine das im Hinterkopf zu haben, ist schon für viele wahrscheinlich unfassbar unangenehm. (00:25:56) Ich kann auch mal einen Tipp geben, der da hilft. (00:25:59) Viele reden nicht über Non-Functional Requirements. (00:26:03) Wir reden alle über Requirements, also welche Features das Produkt haben soll. (00:26:08) Aber die Non-Functional Requirements, also ob es schnell sein soll, ob es sicher sein soll, ob es kosteneffizient sein soll, etc., darüber wird relativ wenig diskutiert. (00:26:18) Und das ist sehr, sehr oft eigentlich ein Schlüssel zur Vermeidung von technischen Schulden. (00:26:23) Und wir haben einfach festgestellt, dass darüber oft an der Oberfläche Einigkeit besteht oder die Leute glauben, dass sie die haben. (00:26:31) Und wenn man so ein bisschen bohrt, stellt man fest, nee, die haben die Diskussion nie gehabt. (00:26:35) Und das ist spannend. (00:26:36) Wenn ich zum Beispiel jetzt als CTO zu meinem CEO gehe und ich sage, hey, wie sicher soll denn unsere Software sein? (00:26:42) Ja, die soll auf jeden Fall extrem sicher sein. (00:26:44) Ja, Sicherheit ist alles. (00:26:46) Dann sage ich, okay, wie schnell müssen wir denn am Markt sein? (00:26:50) Ja, sofort. (00:26:51) Das ist aber ein Gegensatz. (00:26:53) Und in dem Moment, wo du diese Diskussionen über diese Gegensätze hast, Sicherheit versus schnelle Time-to-Market oder Kosteneffizienz oder andere, in dem Moment hast du eigentlich genau die Diskussion, die in einer Tech-Company extrem wichtig ist, und zwar nicht nur für Tech, sondern eben auch für die Business-Sek, oder? (00:27:12) Ja, ich glaube, das muss man auch einfach erst mal lernen, dass man sich solche Gespräche haben muss. (00:27:16) Lass uns mal eine, also ich glaube, warum wir über DDS sprechen, ist, weil es einmal das ist, so steht zwischen dir und einem Investment als Start-up. (00:27:24) Du kriegst kein Investment, wenn du diese DD nicht bestehst. (00:27:27) Und bei einem Investment ja auch immer die Frage, okay, wie verändert das die Rahmenbedingungen meiner Runde? (00:27:33) Also inwiefern hat eine DD den Einfluss auf eine Bewertung? (00:27:37) Also wir wissen, Investment ja oder nein, hängt von der DD ab, aber inwiefern hat die auch Einfluss auf meine Bewertung? (00:27:44) Das hängt natürlich ein Stück weit auch von den Marktkonditionen ab, muss man ganz klar sagen. (00:27:49) Ich glaube, 2021 hat es diese Diskussionen relativ selten gegeben. (00:27:54) Und in Zukunft wird es die wahrscheinlich wieder ein bisschen häufiger geben. (00:27:58) Als Daumenregel kann ich, glaube ich, sagen, dass im Investmentumfeld bei einer einigermaßen okayen DD wird da nicht um jeden Euro in der Bewertung gefeilscht, sondern da geht es wirklich darum, wenn man sich einigermaßen so im Rahmen des agreed Business-Plans bewegt, dann geht es eher darum, was können wir denn jetzt machen, um es besser zu machen? (00:28:21) Da geht es eher um Action Points. (00:28:23) Wenn natürlich aus unserer Tech-DD rauskommt, dass jetzt erst mal noch zwei Jahre gebaut werden muss, bevor der Revenue auch nur ansatzweise kommen kann, dann ist das natürlich eine andere Diskussion. (00:28:36) Und dann wird mit Sicherheit, wenn da noch investiert werden wollen würde, würde auch über die Bewertung noch mal geredet werden. (00:28:43) Im M&A-Kontext sieht man das natürlich häufiger, aber ich denke, im Funding-Kontext ist man da auch wesentlich pragmatischer und zielorientierter noch mal unterwegs. (00:28:51) Ich glaube, eine Frage, die sich da anschließt, wie finde ich eigentlich heraus, wie gut ich aktuell bin? (00:28:56) Gerade wenn wir viel über Tech reden, das ist ja oft etwas, das sehr organisationsgetrieben ist und jetzt nichts, was ich so einfach da draußen sagen kann, hey, zeig du mir mal deinen Tech, dass ich weiß, wo andere Fehler haben. (00:29:06) Das heißt, oft habe ich vielleicht Unsicherheiten oder Unklarheiten, weil ich das auch nicht so einfach vergleichen kann. (00:29:12) Wie finde ich eigentlich raus, ob mein Tech gut genug ist oder nicht? (00:29:16) Unter CTOs gibt es mittlerweile glücklicherweise schon Communities, wie zum Beispiel Alphalist oder ähnliche Communities, in die du rein kannst und wo du wirklich einen ehrlichen Austausch auch mit Peers haben kannst, CTOs, Co-Founders, um das ein Stück weit herauszufinden. (00:29:33) Du kannst dir natürlich auch Leute wie uns reinholen und wir machen dann eben die Health-Checks, auf die du vorher schon gekommen bist. (00:29:40) Dann werden wir dir das sagen, weil wir natürlich auch einen Benchmark haben und wir können euch sagen, ob ihr in der Industry, in der Funding-Stage, vielleicht auch in einem bestimmten Portfolio oder ähnlichem, wo ihr da steht im Vergleich zu anderen. (00:29:56) Bei Non-Technical-Founders ist das mit den Peers so ein Problem, weil ich festgestellt habe, dass da immer noch so ein bisschen Bragging leider abgeht und da teilweise sehr interessante Geschichten erzählt werden von, ja, mein Tech-Team, wir haben nur zehn Leute, aber die produzieren viermal so schnell wie alle anderen. (00:30:20) Das sind immer noch so Storys, die erzählt werden. (00:30:24) Ich weiß nicht, warum das so ist, aber das ist leider so und das macht natürlich viele Non-Technical-Founders umso nervöser, bei denen das nicht so läuft und ich glaube, da ist tatsächlich ganz gut, sich so einen Reality-Check nochmal von außen auch tatsächlich reinzuholen. (00:30:38) Das andere ist, die Idee zu ermutigen, ist, so früh wie möglich alle Arten von Metriken zu sammeln. (00:30:46) Das können Businessmetriken sein, aber das können auch Metriken aus der Produktentwicklung sein oder technische Metriken. (00:30:54) Das können auch Metriken zum Beispiel zum Deployment sein, wie schnell man Changes durchführen kann und Ähnliches. (00:31:02) Und Metriken lügen in der Regel nicht. (00:31:06) Und Metriken kann man ganz gut vergleichen. (00:31:08) Und ich habe ein Team von 10 Top-Entwicklern, die viermal so schnell entwickeln wie ihr. Das ist keine Metrik. Aber zumindest nicht, wenn sie nicht mit Daten unterlegt ist. (00:31:20) Aber Deploymentmetriken zum Beispiel, hey, wir sind in der Lage ein Change innerhalb von zwei Stunden durchzuführen oder zwei Minuten. (00:31:28) Das ist eine Metrik, die tatsächlich auch eine Relation zum Business hat und die einem hilft, ein bisschen objektiver an so eine Diskussion ranzugehen. (00:31:38) Eine kurze Ergänzung. Ich glaube, für so einen Non-Technical-Founder, also mehr so CEO-Charakter, ich überlege gerade auch, ob man nicht doch irgendwann mal so eine Community baut, so ähnlich wie AlphaList, dass man sagt, okay, man bringt die Leute zusammen, aber man screent die vorher richtig klar, sodass man dann auch irgendwie dieses Bragging ein bisschen außen vor lassen kann und Leute dann wirklich nur reinkommen, um zu sagen, okay, man tauscht sich auch so ehrlich wie möglich aus. (00:32:02) Wird man das immer zu 1000% hinbekommen? Wahrscheinlich nicht. Deswegen bin ich auch immer so ein bisschen zurückhaltend, das zu machen und dokle da schon eine Weile in meinem Kopf rum. (00:32:10) Das ist nicht ganz so einfach, aber ich glaube, es ist schon immer noch notwendig. (00:32:14) Ich fand ja ein sehr spannendes Format, diese Falcon-Formate, die es vor einigen Jahren sehr, sehr verstärkt gab. Ich glaube, das ist wieder so ein kleines bisschen eingeschlafen. Das finde ich aber extrem spannend. Also immer, wenn Leute über ihre Lessons learned erzählen, bin ich auch sofort da und höre gerne zu, weil ich das auch, ehrlich gesagt, irgendwie spannender als die Erfolgsstories finde, mal über die eigenen Fehler und die Learnings zu reden. (00:32:38) Aber ich würde mir wünschen, dass so Falcon-Formate, gerade unter CEOs, wieder ein bisschen mehr en vogue werden. (00:32:46) Ja, absolut. (00:32:48) Du hast gesagt, ihr benchmarkt dann die Startups auch intern und habt ja so ein bisschen eure Reports auch für euch ein bisschen gesammelt. Was sind denn so die wichtigsten KPIs, die man sich anguckt und Metriken? (00:32:58) Weil ich glaube, es ist super schwer zu greifen, wenn man nie damit beschäftigt hat. (00:33:02) Selbst für die Leute, die sich damit viel beschäftigen, ist das schwer zu greifen. Also Tech ist extrem kontextabhängig und es ist zudem auch noch sehr dynamisch. (00:33:14) Das heißt, es verändert sich über die Zeit sehr, sehr schnell. Und das macht einen Vergleich auch tatsächlich nicht ganz trivial, muss man dazu sagen. Wir haben über 500 Projekte gehabt und von daher habe ich schon einen sehr, sehr großen Erfahrungsschatz. (00:33:32) Metriken, die man sich anschauen sollte, sind sicherlich zum Beispiel Deploymentmetriken, die ich gerade genannt habe. (00:33:40) Warum ist das so? Also ein CEO fragt sich vielleicht, warum zur Hölle soll ich mir jetzt Deploymentmetriken anschauen? Da habe ich doch nichts von. (00:33:48) Doch hat man tatsächlich. (00:33:50) Worum geht es? Es geht darum, sehr schnell in kurzen Abständen Business Value zu releasen und es geht darum, schnell Changes durchführen zu können, wenn ich sie brauche, wenn ich mein Business verändern will oder wenn ich auch eine neue Idee habe, wie lange brauche ich denn, um die tatsächlich auf die Plattform zu bringen, also zu spezifizieren, zu entwickeln, auf die Plattform zu bringen etc. Und für sowas ist es super, wenn man diese Metriken hat, weil wenn ich nur alle zwei Wochen mal was releasen kann und wenn das dann schief geht, vier Stunden brauche, um den Mist wieder zurückrollen zu können, dann sagt mir das extrem viel über die Flexibilität meines Businesses aus oder auch Produkt Delivery Matrix. (00:34:32) Also wenn ich eine Idee habe und die Idee ist irgendwo vorvalidiert worden, man sagt, ja, das sollten wir wirklich bauen und es dauert ein halbes Jahr, bis das dann wirklich live gestellt wird, dann sagt mir das auch sehr viel über die Gesundheit meiner Organisation aus. (00:34:48) Das sind so Beispiele. (00:34:50) Andere Beispiele sind sicherlich im technischen, mehr technischen Bereich Performancemetriken, technische Performance oder auch Bugraten oder ganz klassisch, wie viel Prozent meiner Zeit verbringt mein Team denn mit Troubleshooting und Bugfixing? (00:35:06) Weil letztendlich ist das Zeit, die sie nicht in die Entwicklung von neuen Features stecken können. (00:35:12) Und wenn das irgendwo so im Bereich 10 Prozent ist, okay. (00:35:16) Wenn das im Bereich 30, 40 Prozent ist, wie in vielen Startups mit hohen technischen Schulden, die wir sehen, dann ist das ein Problem für mein Business, weil ich unter Umständen 30 Prozent weniger Performance habe als ein Konkurrent da draußen, der ungefähr die gleichen Voraussetzungen und das gleiche Team hat. (00:35:36) Ich glaube, es ist einfach wichtig, so eine grobe Einschätzung mal zu bekommen, worüber mache ich mir überhaupt Gedanken, weil ich glaube, sonst merkt man selber gar nicht, wie viel habe ich mich damit unwissentlich oder wissentlich beschäftigt und wie viel halt auch nicht. (00:35:50) Erst mal kurz zusammenfassend, so ein bisschen abrunden in der Frage, was sind denn über all die Jahre so die Best Practices, wenn es um TechDDs geht? Also ich meine, als Gründer haben sich viele vielleicht auch noch nicht so viele Gedanken gemacht und ich gehe immer davon lieber aus, als dass sich alle zu viel Gedanken gemacht haben. (00:36:06) Was sind so wirklich Best Practices, wenn man es versucht, auf den Kern zu reduzieren? (00:36:12) Meinst du jetzt in der Vorbereitung oder meinst du jetzt, was Startups erfüllen müssen, wenn sie in eine TechDD reingehen? (00:36:18) Ja, grundsätzlich schon eher im Mindset grundsätzlich, weil was du ja nicht willst, ist, dass ein Startup versucht, die TechDD nur zu erfüllen, um irgendwie Investment zu bekommen, sondern grundsätzlich ist es ja eine Guideline, weil man davon ausgeht, dass das die bessere Firma ist, wenn sie diese Richtlinien auch für sich erfüllt und versucht beizubehalten. Das heißt eher so, wie ich von vornherein die Firma darauf setze, dass sie auch dann im Nachgang durch so eine TechDD durchkommt, ich aber ein solides Fundament für meine Firma gebaut habe. (00:36:52) Als allererstes brauchst du eine Organisation, die keine Gaps hat zwischen Business, Produkt und Tech. Ich glaube, das ist schon mal die Grundvoraussetzung, sodass Tech auch tatsächlich den Business-Kontext versteht. (00:37:08) Engineers verstehen, was sie für ein Produkt bauen, was für ein Business Zweck hat, sodass man nicht im Elfenbeintum entwickelt. (00:37:18) Das ist, glaube ich, schon mal die Grundvoraussetzung. (00:37:20) Je mehr Tech beim Business ist, desto mehr muss ich auch sicherstellen, als Founder, selbst wenn ich keinen technischen Co-Founder habe, dass mein CTO oder mein Tech Leadership Personnel tatsächlich nah an mir dran ist, dass ich auch höre, was aus Tech kommt, was aus Product kommt, um wirklich sicherzustellen, dass wir ein gutes Produkt auch langfristig und nachhaltig bauen. (00:37:48) Ansonsten ist wichtig, dass wir eine stabile Architektur haben, die aber flexibel genug ist, um auch Innovationen zuzulassen, um Fortentwicklungen zuzulassen und einen Produktentwicklungsprozess, der das unterstützt. (00:38:04) Das stellen wir auch immer wieder fest, dass sehr häufig junge Founders sehr stark von Needs getrieben werden, die von existierenden Kunden kommen. (00:38:18) Das ist einerseits natürlich eine gute Sache, Customer Feedback mit aufzunehmen, aber das kann halt nicht alles sein. In meinem Produktentwicklungsprozess muss ich halt auch immer noch Platz lassen für eigene Ideen, für Innovationen, für was da draußen am Markt vorgeht. (00:38:34) Das ist tatsächlich für mich immer eine Best Practice und auch ein Stück so eine Aussage über den Reifegrad von der Organisation. Schaffen die das schon? (00:38:44) Oder sind die eher noch getrieben von dem, was ihre Kunden sagen, statt selber proaktiv zu agieren? Im Engineering muss ich mir anschauen, welchen Senioritätsgrad, also auch welchen Reifegrad hat denn einerseits das Team und andererseits die technische Implementierung selber. Also habe ich genug Senior Engineers oder habe ich jetzt vielleicht aus Budgetgründen mir 20 Juniors geheiert, aber habe eigentlich keine Leute, die die führen, die die weiter ausbilden und verbessern und die mir die Bude sauber halten. (00:39:22) Ich kann immer nur empfehlen, schafft euch lieber ein kleines Team an, aber dafür mit einem gesunden Mix von Seniors zu Juniors, also vielleicht am Anfang 2 zu 1, später vielleicht 3 zu 1 und nicht ein Senior auf 3 Juniors oder noch mehr. Und dann so Hygiene-Themen in der Technik selber. (00:39:46) Also habe ich eine testgetriebene Entwicklung zum Beispiel. (00:39:50) Viele Gründer sagen immer, ja, wozu brauche ich Tests? (00:39:54) Das kann ich doch lieber in die Entwicklung von neuen Features stecken. Naja, je größer dein Produkt wird, je größer dein Scope wird, desto schwieriger wird ja manuelles Testen. Das heißt, irgendwann ist die Hälfte einer Mannschaft nur noch damit beschäftigt, sich vor und nach dem Release durch deine Software zu klicken, statt auf Testautomatisierung zu setzen, was ungefähr 20% deiner Entwicklungszeit beanspruchen wird, was dir aber letztendlich das Leben rettet, weil es deine Software dokumentiert, weil es sie klar strukturiert, weil es das Onboarding von neuen Entwicklern schneller macht und weil die Leute ihre Zeit beim Bugfixing verschwenden müssen. (00:40:30) Echt so ein Riesenthema, wenn man da noch nie drüber nachgedacht hat, was so alles auf einen zukommen kann. Gleichzeitig ist es aber so nah am eigentlichen Business-Building-Kern, dass man sich unwissentlich auch viel damit schon beschäftigt hat und ich glaube, für viele fühlt sich DD an wie was komplett Neues. (00:40:46) Ich glaube, je mehr man sich damit beschäftigt, desto eher merkt man, es sind viele der Fragen, die ich mir sowieso stelle, wenn ich meine Organisation baue und wenn ich meine Firma aufstelle und je früher und je klarer ich mir die stelle, desto einfacher werde ich es eben in jeder DD haben, weil das eher nur ich sag es mal in Anführungszeichen nur ein Korrekturmechanismus ist, ob das wirklich so vorbereitet wurde, wie es vielleicht sein sollte und sein könnte und nicht so ein Screening, was komplett an der, also es ist ja nicht an der Realität vorbei, ist ja das, was man eh erreichen möchte. (00:41:18) Ich glaube, wenn man das nochmal auf den Punkt bringen will, was sind so typische Fragen, die mit den Investoren, also was sind so typische Fragen, mit denen Investoren auf uns zukommen? (00:41:30) Das ist in der Regel, wie ist das Leadership-Team insbesondere? (00:41:34) Wie ist Technical Leadership? (00:41:36) Wie ist die Plattform gebaut? (00:41:38) Ist die Plattform maintainable? (00:41:40) Das heißt, mit vertretbarem Aufwand kann man daran weiterentwickeln. (00:41:44) Ist die Plattform skalierbar oder bricht da was zusammen, wenn wir jetzt fünfmal so viel Traffic da drauf schicken? (00:41:50) Ist die Plattform sicher? (00:41:54) Vielleicht auch im Enterprise-Umfeld, ist sie Enterprise-ready? Würden Enterprise-Kunden sie nutzen? (00:42:00) Und hält das Produkt, was das Pitch-Deck verspricht? (00:42:04) Das sind eigentlich so klassische Kernfragen und wenn ich Gründer wäre und von einer DD stünde, würde ich mit den Fragen mal anfangen und würde versuchen, mir die ehrlich zu beantworten oder mir da vielleicht von außen vorab schon mal Feedback zu holen. (00:42:16) Und dann zu guter Letzt, ich meine, ich habe es angesprochen und wir sind immer wieder zurückgekommen, dass ihr so Health-Checks auch für Gründer seid etc. macht. (00:42:24) Wann ist eigentlich der richtige Zeitpunkt, sich zum Beispiel bei euch zu melden? (00:42:28) Einer meiner Mentoren hat immer gesagt, wann willst du wissen, dass du ein Problem hast? (00:42:32) So früh wie möglich. (00:42:34) Und das ist tatsächlich eine Grundregel und deswegen möchte ich Gründer immer dazu ermutigen, das tatsächlich so früh wie möglich in Angriff zu nehmen. (00:42:46) Wenn ich weiß, dass ich in eine Fundingrunde, sagen wir mal in sechs Monaten reingehe, dann würde ich idealerweise jetzt anfangen, mir Feedback zu holen. (00:42:56) Aus dem einfachen Grund, weil das in der Regel ja dann doch nochmal ein paar Wochen dauert, bis man es dann tatsächlich macht und vielleicht auch die Ergebnisse kriegt. (00:43:04) Und dann habe ich exakt den Handlungsspielraum von ein paar Monaten, um mir zu überlegen, was tue ich denn, wenn größere Probleme gefunden werden. (00:43:12) Ich kann nicht nur überlegen, wie verkaufe ich es am besten, das ist die Last-Minute-Variante, sondern ich kann es tatsächlich lösen. (00:43:22) Und das hilft mir ja auch. Das hilft ja nicht nur der DD und der Risikominderung, sondern das hilft mir auch in meinem Business. (00:43:30) Drei bis sechs Monate vorher ist eigentlich so ein idealer Zeitraum, sowas zu machen. (00:43:38) Das heißt, wenn ich jetzt das Gefühl habe, in sechs Monaten habe ich eine Finanzierungsrunde, dann gehe ich auf eure Website, melde mich bei euch und höre mir mal an, was ihr so zu bieten habt. (00:43:50) Zum Beispiel, genau. Sprichst uns an oder auf Konferenzen, findest du uns auch sehr oft. (00:43:54) Machst mit uns vielleicht auch erstmal einfach einen Schnack und wir tauschen uns über deine Tech aus. (00:44:00) Das machen wir auch immer sehr gerne, einfach bei einem Kaffee mal drüber reden, was habt ihr da eigentlich an Team, an Organisation, an Tech und dann gucken wir, wie wir euch helfen können. (00:44:08) Ich würde dazu mal sowohl klar LinkedIn, Website als auch alles, was uns noch einfällt, darunter verlinken, dass man sich direkt bei euch melden kann, wenn man das Gefühl hat, ich muss vielleicht doch nochmal gucken, wo wir da gerade stehen. (00:44:24) Dann sollten Gründer, glaube ich, sich bei euch melden und mal mit euch in Ruhe sprechen. (00:44:32) Chris, hat mir sehr viel Spaß gemacht. Vielen lieben Dank. (00:44:34) Ich glaube, konnte so ein bisschen Licht ins Dunkel bringen. (00:44:38) Was ist die Idee eigentlich? Brauche ich Angst davor haben? (00:44:40) Ich glaube, zusammenfassend kann man sagen, nein, braucht eigentlich keine Angst davor haben. (00:44:44) Außer du guckst halt, du hast morgen deine Idee und guckst heute erst, ob du ein Problem hast. Dann ist es vielleicht ein bisschen schwieriger. (00:44:50) Aber bestimmt ein sehr hilfreiches Thema. (00:44:54) Darfst gerne die letzten Worte an alle Hörer und Hörerinnen richten. (00:44:58) Ja, ich würde nochmal gerne an die GründerInnen appellieren. (00:45:02) Seht eine Idee als Chance. (00:45:04) Als Chance, für euch selber Feedback zu bekommen, als Chance, euch darauf vorzubereiten, bestmöglich, nicht nur für die Idee selber, sondern um euch eigentlich die perfekte Startposition für nach dem Investment zu geben, um dann tatsächlich mit dem neuen Geld hoffentlich richtig loslegen zu können und zu skalieren. (00:45:24) Ja, viel Erfolg dabei. (00:45:26) Danke dir. (00:45:28) Danke.