mantro

Die Technologie funktioniert. Du hast es verifiziert. Du hast Daten. Du hast Nachweis-Punkte. Der CTO ist überzeugt. Der Business Unit Leader sieht das Potenzial.

Und dann passiert nichts.

Oder — schlimmer — es passiert doch etwas. Ein Team versammelt sich. Ein Prototyp wird gebaut. Ein Markt wird identifiziert. Aber irgendwo zwischen Validierung und Kommerzialisierung bleibt das Venture stecken. Die Technologie ist solide. Der Markt existiert. Aber das Unternehmen materialisiert sich nie vollständig.

Das ist das am meisten unterschätzte Fehler-Muster im Corporate Venture Building. Es ist nicht die Technologie, die fehlerhaft ist. Es ist nicht der Markt, der verschwunden ist. Es ist, dass drei komplett unterschiedliche Disziplinen behandelt wurden, als wären sie eine.

Die drei Übergänge, die wie eine aussehen

Das ist das Kern-Argument, das ich im ersten Artikel der Vorgänger-Serie dieser Serie machte: 95% der Patente werden nie zu Unternehmen. Aber das ist nur die halbe Geschichte. Weil wenn jemand tatsächlicheinsteigt zum Bauen — wenn ein Konzern Execution-Verantwortung übernimmt — der Fehler verschwindet oft nicht. Er verschiebt sich. Die Infrastruktur-Lücke, die akademische Spinouts tötet, ist anders von der Infrastruktur-Lücke, die Corporate Ventures tötet. Aber das Fundamental-Problem bleibt das gleiche.

Technologie, Produkt und Unternehmen sind drei komplett separate Domänen. Jede hat ihre eigenen Disziplinen. Jede erfordert unterschiedliche Fähigkeiten. Und Versagen bei irgendeinem von ihnen, in irgendeiner Phase, tötet das Venture.

Lass mich sie trennen:

Übergang 1: Technologie zu Produkt

Eine Technologie ist eine Fähigkeit. Sie löst ein Problem, aber normalerweise löst sie es auf eine spezifische Weise, für einen spezifischen Kontext, auf einer spezifischen Skala.

Die Bewegung von "die Technologie funktioniert" zu "das Produkt funktioniert" erfordert Übersetzung. Markt-Übersetzung.

Du musst wissen:

Wo schafft diese Technologie messbaren Kundenwert?
Welches Problem löst sie wirklich, relativ zu dem, was heute existiert?
Bei welcher Skala funktioniert sie? (Eine Batterie-Technologie, die bei 100g brillant funktioniert, kann bei 1kg wertlos sein.)
Was ist die minimal viable technische Fähigkeit? (Die meisten R&D Teams wollen die Technologie perfektionieren. Die meisten Märkte wollen sie "gut genug" zu einem Preis, den sie zahlen.)
Welche Trade-offs musst du machen, um sie zu kommerzialisieren? (Speed vs. Kosten, Flexibilität vs. Dauerhaftigkeit, Upfront-Investition vs. Betriebsausgaben.)

Die Technologie-Disziplin ist "Können wir es bauen?" Die Produkt-Disziplin ist "Werden Kunden dafür zahlen?"

Das sind nicht die gleiche Frage.

"Die Technologie-Disziplin ist 'Können wir es bauen?' Die Produkt-Disziplin ist 'Werden Kunden dafür zahlen?' Das sind nicht die gleiche Frage."

In Deep Tech ist dieser Übergang, wo viele Ventures stolpern. Ein Advanced Materials Unternehmen entwickelt einen überlegenen Verbundstoff. In Labor-Bedingungen übertrifft er bestehende Lösungen um 40%. Aber bei kommerzieller Skala kostet der Produktionsprozess 3x mehr, als der aktuelle Markt-Leader charged. Die Technologie funktioniert. Das Produkt nicht. Noch nicht, jedenfalls — und das nach €5M Investition in eine Pilot-Facility zu entdecken ist teuer.

Übergang 2: Produkt zu Unternehmen

Angenommen, du hast das gelöst. Du hast ein Produkt, das Kunden wollen und für das sie zahlen werden.

Ein Unternehmen um dieses Produkt zu bauen erfordert ein komplett anderes Set von Disziplinen:

Team-Design — das Produkt funktioniert, weil das ursprüngliche Entwicklungs-Team es intimately verstand. Kannst du Entscheidungs-Fähigkeit über dieses initiale Team hinaus skalieren?
Finanzarchitektur — Unit Economics, Kapitaleffizienz, Preis-Strategie, Cash Flow Management, Break-Even Roadmap.
Governance-Struktur — wer entscheidet was, durch welchen Prozess, mit welcher Autorität?
Stakeholder-Architektur — das Produkt wurde vielleicht für einen Entscheider gebaut (den CTO, den Business Unit Head, den Innovation Officer). Ein Unternehmen muss mehrere Stakeholder mit konfliktierenden Incentives zufriedenstellen.
Kapitalstruktur — wie Kapital in das Venture fließt, wie Risiko geteilt wird, wie der Exit funktioniert.
Operativer Rhythmus — wie Entscheidungen getroffen werden, wie Fortschritt gemessen wird, wie Probleme eskaliert und gelöst werden.

Ein starkes Produkt kann eine schlechte Unternehmens-Architektur sein. Du kannst das beste Produkt auf dem Markt haben und trotzdem scheitern, weil das Team nicht executen kann, die Cap Table broken ist, das Finanzmodell nicht funktioniert, oder die internen Stakeholder nicht aligned sind.

"Du kannst das beste Produkt auf dem Markt haben und trotzdem scheitern, weil das Team nicht executen kann, die Cap Table broken ist, das Finanzmodell nicht funktioniert, oder die internen Stakeholder nicht aligned sind."

Ich habe beide gesehen. Ich habe beide gebaut. Und ich kann dir sagen: das sind unterschiedliche Probleme.

Die Compound-Natur der Lücken

In Software sind diese Übergänge relativ schnell. Ein Prototyp kann Product-Market Fit in Wochen testen. Eine Unternehmens-Struktur kann schnell angepasst werden. Kapitalanforderungen sind normalerweise managebar.

In Deep Tech — Materialien, Hardware, Biotech, Advanced Manufacturing — hat jeder Übergang längere Timelines und höhere Kosten. Eine falsche Entscheidung beim Technologie-zu-Produkt Übergang kann Millionen in Facilities, Equipment und Regulatorischer Navigation kosten. Eine falsche Entscheidung beim Produkt-zu-Unternehmen Übergang kann Jahre von Umstrukturierung bedeuten, bevor du institutionelles Kapital aufbringst.

Das ist, warum Sequenzierung in Deep Tech so sehr zählt. Aber Sequenzierung ist nur bedeutungsvoll, wenn du anerkennst, dass jeder Übergang fundamental unterschiedliche Expertise erfordert.

Wo das in Konzernen fehlschlägt

Corporate Ventures treffen diese Lücken mit besonderer Kraft. Hier ist warum:

Die Technologie existiert bereits — sie ist interne R&D, oder sie wird von einer Partner-Institution beschafft. Es gibt keine Mehrdeutigkeit über den ersten Schritt. Jemand hat bereits Verantwortung für die Technologie übernommen.

Aber die Übersetzung von "wir haben diese Technologie" zu "das könnte ein Geschäft sein" landet normalerweise auf welchem Executive die Überzeugung hatte, das Venture zu pushen. Oft ist das der CTO, der Head of Innovation, oder ein visionärer Business Unit Leader.

Diese Person versteht einen Übergang gut. Selten verstehen sie alle drei.

Der CTO versteht die Technologie tief. Er versteht möglicherweise nicht Markt-Übersetzung oder Finanzarchitektur.

Der Innovation Officer versteht den Business Case und kann Investor-Narrative bauen. Er versteht möglicherweise nicht die technische De-Risking oder die Team-Architektur, die Produkt zu Operation verwandelt.

Der Business Unit Leader versteht den Markt und den Kunden. Sie versteht möglicherweise nicht Venture Governance oder wie man Decision-Making über ein neues Team skaliert.

Solange das Venture klein und intern bleibt, ist diese Fehlausrichtung versteckt. Aber sobald der Konzern echtes Kapital committen muss — sobald das Venture eine Funding Gate erreicht, oder das Geschäft an ein Operating Team übergeben muss — werden die Lücken sichtbar. Oft sind sie sichtbar, zu spät um sauber zu reparieren.

Was wirklich passiert

In einem echten Beispiel, das ich durchgearbeitet habe:

Ein großer Industrie-Konzern hatte eine vielversprechende Sensor-Technologie für Condition Monitoring entwickelt. Die Technologie war solide. Der Markt war real — Predictive Maintenance ist ein bekannter Schmerzpunkt. Der Business Unit Leader war überzeugt. Ein internes Team wurde zusammengestellt.

Innerhalb von sechs Monaten hatten sie einen Prototyp. Innerhalb von neun Monaten hatten sie erste Kunden. Im Monat zwölf realisierten sie, dass der Produkt-zu-Unternehmen Übergang nie passiert war.

Der CTO hatte die Technologie-Auswahl geleitet. Der Business Unit Leader hatte Kunden identifiziert. Aber niemand hatte das Gründungs-Team designed. Niemand hatte das Finanzmodell gebaut. Niemand hatte Governance-Strukturen geschaffen, die außerhalb der Corporate Hierarchie funktionieren. Wenn es Zeit wurde, einen CEO zu hired und zum unabhängigen Betrieb zu übergehen, hatte das Unternehmen keine Cap Table, keine klare Entscheidungs-Autorität und keinen operativen Rhythmus außerhalb des Corporate Approval-Prozesses.

Das Venture scheiterte nicht, weil die Technologie scheiterte oder der Markt verschwand. Es scheiterte, weil niemand alle drei Übergänge als einzeln, integriertes Build ownete. Jeder Übergang wurde von einer anderen internen Funktion gehandhabt — und keine hatte das Mandat oder die Fähigkeiten, ein Unternehmen von Grund auf zu bauen.

Was das für Venture Building bedeutet

Wenn du Ventures in oder neben einem Konzern baust, musst du jeden Übergang als separates Design-Problem behandeln:

Übergang 1 — Technologie zu Produkt:

Das handelt von Markt-Übersetzung. Wer hat den höchst-wertvollen Schmerzpunkt? Wie löst diese Technologie ihn besser als Alternativen? Was ist die minimal viable technische Fähigkeit? Du brauchst Leute, die in Technologie und Markt versiert sind, nicht nur eine.

Übergang 2 — Produkt zu Unternehmen:

Das handelt von Architektur. Es includes Team-Design, Finanzmodell-Konstruktion, Governance-Struktur und Kapitalarchitektur. Das ist Engineering, nicht Kreativität. Es ist genauso technisch wie die Technologie selbst, und es ist wo die meisten Ventures zusammenbrechen.

Übergang 3 — Unternehmen zu Skalierung:

Das handelt von Operativer Infrastruktur — Hiring, Prozesse, Delegation, Übergabe von Builder zu Operator. Das ist der Übergang vom Build-Modus zu nachhaltigen Geschäft.

Jeder dieser Übergänge ist lernbar. Jeder hat Muster. Jeder hat einen Satz von Disziplinen, die Ventures unterscheiden, die es schaffen, von denen, die nicht.

Aber sie sind nicht austauschbar, und sie als ob sie es wären zu behandeln ist, wie du am Ende mit einer Technologie, die funktioniert, ein Produkt, das sich verkauft, und trotzdem kein Unternehmen endet.

"Technologie, die funktioniert, Produkt, das sich verkauft, und trotzdem kein Unternehmen — das ist das Venture Building Fehler-Muster, das alle misst."

Hier ist die unbequeme Wahrheit für Corporate Innovation Teams: Alle drei Übergänge erfordern Fähigkeiten, die im Konzern nicht existieren. Der CTO kann Übergang 1 leiten. Niemand in der Organisation ist für Übergang 2 ausgestattet — weil ein Unternehmen von Grund auf zu bauen ist nicht das, was etablierte Organisationen tun. Und Übergang 3 scheitert, wenn der Konzern versucht, das Venture zu früh zurück in seinen eigenen operativen Rhythmus zu absorbieren.

Die Ventures, die überleben, sind die, wo jemand End-to-End Execution-Verantwortung für alle drei Übergänge übernimmt — nicht als Advisor, nicht als Consultant, sondern als der Builder, der das Outcome ownt. Das bedeutet, das Venture außerhalb der Unternehmens-Operativ-Struktur zu bauen, mit dem Konzern's strategischer Überwachung aber nicht der Konzern's Tages-Beteiligung.

Es fügt Disziplin hinzu. Es fügt strukturelle Separation hinzu. Aber es ist der Unterschied zwischen einem Patent, das nie zu einem Unternehmen wird und einem Venture, das Skalierung schafft.