#Unternehmensgründung – Hurra, wir schreiben eine App …

Nur:
Wenn es so einfach wäre, würden nicht fast alle scheitern.

Hier eine kleine Geschichte:

Ein Start-up-Team will ein Unternehmen aufbauen, das basierend auf einer APP ein Gewinn bringendes Geschäft realisieren soll. Dahinter steckt ein tüchtiges Team und eine eifrig diskutierte Idee. Idealismus und Schwung sind im Übermaß vorhanden, alle sind bereit sich richtig einzusetzen und materiell einzuschränken, durch Nächte zu gehen und notfalls eigene Lebensziele zu verschieben oder gar zu opfern.

Durch Zufall komme ich dazu. Gerufen, weil das Projekt gefühlt in einer Sackgasse steckt, aber keiner der Teilnehmer sich das eingestehen will. Nach wenigen Sitzungen merke ich, dass das Projekt auf falschem Kurs ist. Das Team steckt schon mitten in der Implementierung, das tut besonders weh.

In meinem Leben habe ich schon einige Gründer zu Grunde gehen gesehen – dies im wahrsten Sinne des Wortes. Also habe ich jetzt eine große Verantwortung. Der kann ich aber nicht gerecht werden, da die Gründer sich in ihren eigenen Gedanken gefangen haben und nicht mehr bereit oder in der Lage sind zu zu hören. Vielleicht verständlich, dass sie schlechte Botschaften gar nicht mehr hören wollen.

Dann warne ich und gehe wieder. Und ein paar Monate später erfahre ich, dass sie „gegen die Wand gefahren“ sind. Deshalb notiere ich im folgenden ein paar allgemeine Empfehlungen an Gründer.

Erste konkrete Empfehlung:
Ohne Blaupause geht es nicht

Was soll man machen, wenn man in einem Projekt merkt, dass es im Team keinen „gemeinsamen Peil“ gibt? Oder noch schlimmer, wenn jeder eine andere Vorstellung vom zu Erreichenden hat?

Meine Empfehlung ist, in einer solchen Situation die Implementierung sofort zu stoppen und zurück auf Start zu gehen. Also wieder in die Phase des „Requirement Engineering“ einzusteigen. Das schmerzt, ist aber die einzige Chance das Projekt zu retten. Als Trost bleibt, dass man das Gelernte nutzen kann.

Aber es muss diesmal ein modernes, agiles, empathisches und lernendes Requirement Engineering sein! Bei dem Finden der Anforderungen für neue und innovative Lösungen geht es um das „experimentelle Erlernen einer fachlichen Situation“. Wer in Innovation bestehen will muss die richtigen Fragen stellen. Und bevor man diese stellen kann muss man sie erst mal finden! Und das ist nicht einfach.

Erst dann darf das „Requirement“ starten. Und erst danach darf man über Lösungen nachdenken. Lösungen findet man durch das Zerlegen des Zieles in die „richtigen“ Anwender-Stories (user story). Mit einer davon beginnt man und betrachtet die zu Grunde liegenden Geschäftsfälle (use case). Die kann man analysieren und beschreiben. Aber bitte mit der „Weisheit der Vielen“ und nicht aus der „Einfalt des Einzelnen“. Gerade, wenn es um Zukunft und Innovation geht!

„Markt erlernen“ geht nur mit „technisch-fachlicher Empathie“. Aber den Markt müssen wir kennen, soll er doch das Produkt letztlich kaufen und einsetzen. Gerade der Markt der Zukunft muss durch Ausprobieren und Experimentieren erkundet werden. Gegen die dogmatischen Vorstellungen im Kopf eines Einzelnen. So muss man andauernd dazu lernen. Im redlichen und optimalen Diskurs, offen und agil.

Wenn diese wichtige Vorarbeit unterlassen wird, werden Dinge programmiert (oder gebaut), die keiner haben will. Die Gedanken des Teams kreisen dann um ein zumindest im Markt fragwürdiges Produkt, das mit seinen technischen und sonstigen Problemen vom wesentlichen Ziel ablenkt und die Kräfte des Teams auffrisst.

Der Misserfolg des Produkts wird oft auf fehlende Funktionalität geschoben. Man müsse nur noch mehr Programmieren, dann käme der Erfolg schon. Das ist ein Irrtum. Wenn dann die vermeintlich so wichtigen Funktionen vorhanden sind, wird es nicht besser. So wird der Misserfolg auf fehlenden Vertrieb und Marketing begründet. Man bräuchte doch nur noch ein paar Millionen für Vertrieb und Marketing … Die man aber nicht bekommt, weil man keinen Geldgeber mit dem vorhandenen Ergebnis überzeugen kann.

Das oder Ähnliches passiert immer dann, wenn der „start up“ nicht schon am Start über eine valide und flexible Blaupause verfügt. Man hat keinen gemeinsamen Nenner, den man lebt und kann so nicht überzeugen. Man braucht also eine Blaupause. Früher hat man die Blaupause „Pflichtenheft“ genannt. Aber die Blaupause beschränkt sich im Gegensatz zum Pflichtenheft auf das Essentielle. Und sie bleibt lebendig.

Das Wort „requirement engineering“ führt leicht in die Irre. Wie der Begriff des „Pflichtenhefts“ nicht zeitgemäß ist, besonders wenn er den Gedanken des „V-Modells“ folgend verstanden wird. „Pflichtenhefte“ von heute müssen agil sein und sich inkrementell iterativ verbessern!

Wenn man eine kleine aber feine Blaupause hat, dann kann man sie im Markt testen. Eine gute Blaupause ist einfach. Sie entwickelt Leben und wird so immer belastbarer. Mein Plädoyer für die „Blaupause“ soll nicht missverstanden werden. Keinesfalls will ich dem Vorgehen im überholten Wasserfall-Modell das Wort reden.

Im Gegenteil, auch die Implementierung muss frühzeitig beginnen. Aber nur mit einer einfachen und wichtigen, vielleicht winzigen User Story, die der Blaupause folgt. Mit etwas Glück kann so schnell der erste „quick win“ eingeheimst werden, der in die weitere Zukunft trägt.

Das Gründen eines Unternehmens bedeutet so eine in mehreren Dimensionen vernetzte Gratwanderung.

Weitere Empfehlungen für Start-ups einfach mal in lockerer Reihenfolge:

Die richtigen Zielgruppen suchen

Anwendersoftware (wie viele andere Produkte auch) hat modellhaft immer mindestens zwei Zielgruppen – die „Fachabteilung“ und die Nutzer. Das unterscheidet Anwendersoftware übrigens auch von einer rein technischen Softwareentwicklung wie z.B. den Bau eines Compilers.

Die Fachabteilung will mit dem Produkt eine Vereinfachung und Verbesserung notwendiger Prozesse erreichen. Der Nutzer soll diese Lösung positiv annehmen, das Produkt muss ihm spürbar helfen, dass er auf angenehme Art und Weise seinen Job besser machen kann.

Business Case

Der ist von herausragender Bedeutung. Wir brauchen eine Story. Wenn man die richtigen Zielgruppen gefunden hat und über eine schöne Blaupause verfügt, dann lässt sich der Business-Case entwickeln. Eingepackt in eine gute Story, die faszinieren kann. Um die potentiellen Partner, die möglichen Vertriebs- und Vermarktungswege, die Multiplikatoren und weitere zu begeistern. Und kann dann die vielen Chancen des Marktes angehen.

Technologie

Erst wenn eine wirklich gute Blaupause vorhanden ist (eventuell unterstützt von Attrappen vulgo „dummies“ genannt), erst wenn man die Oberfläche und die Funktionen „begreifbar“ machen kann, erst wenn Zielgruppen und der Business Case festgelegt sind, erst wenn Prototypen einzelne Funktionen zeigen, dann macht es Sinn den ersten „Erlkönig“ zu bauen. Dieser Erlkönig muss dann zielstrebig und schnell entwickelt werden, direkt zum Ziel ohne viel „Wenn und Aber“.

Und dann kann das agile Rad anfangen sich zu drehen. Der Hauptzweck eines solchen „Erlkönigs“ ist, von und mit ihm zu lernen – und zwar auf allen Ebenen. Und die Idee, das Produkt zu bewerben. Perfektion zählt hier nicht. Entwickler und Ingenieure müssen hier aufpassen, denn sie denken gerne viel zu früh in Technologien. Das kann man später machen, wenn man weiß, was die Evolution denn wirklich annimmt.

Design

Mit dem Logo muss man ganz früh anfangen! Es wird zum Symbol des Teams und strahlt seine Botschaft aus. Als gemeinsames Symbol des Teams. An der Auswahl des Logos sollten so alle beteiligt sein.

Bei der Design-Findung auch für Gebrauchsmuster oder Prototypen orientiert man sich an den modernen Anwendungen. Bilder und Fotos werden bei den Oberflächen der Zukunft eine wichtige Rolle spielen. Schönheit schadet nicht ist aber zweitrangig, die Vermittlung der Botschaft des Produkts steht im Vordergrund. Das hilft auch den Gründern selber ihre Konstrukte abzugleichen.

Finanzierung

Viel zu früh wird oft über die Finanzierung nachgedacht. Wenn ich finanzieren will, muss ich etwas haben. Nicht nur einen Business-Plan, der in der Regel nur ein schlechtes Glaubensbekenntnis darstellt. Ich brauche all das Beschriebene, die Blaupause, den Business Case, das Muster, ein schönes Design, all das muss die Idee vermitteln und die Menschen faszinieren. So kann ich externes Geld eigentlich erst für den Bau des Erlkönigs erwarten. Und das ist auch noch sehr schwierig – in der Regel helfen da nur besondere Verbündete.

Und vor allem: Das Team muss stark sein. VCs, SCs, staatliche Finanzierungen aber auch Partner-Unternehmen oder Privatinvestoren schauen nicht so sehr auf das Produkt. Wichtig ist diesen der „business case“, die Story und vor allem „das Team“. Stark ist ein Team übrigens nur dann, wenn es selber von seinem Produkt so richtig und trotzdem realistisch überzeugt ist.

Allgemeine Anmerkungen

Die „geniale Idee“ gibt es nicht. Sie ist und bleibt „Saga“. Die geniale Idee ist ein Traum der nur zu schnell zum Alptraum wird. Wie Visionen oft zu Halluzinationen führen.

Der Erfolg von start-ups und Innovationsmachern hat viele Väter. Die Entwicklung eines erfolgreichen Produkts ist ein Stück harter Arbeit. Der Weg beinhaltet viele Rückschläge und Irrungen. Den Erfolg kann man nicht herbei zwingen. Man muss versuchen, die Voraussetzungen zu schaffen, damit er sich eines Tages einfindet.

So kann es durchaus Sinn machen – besonders wenn man nicht vom Start weg mit Kosten deckenden Umsätzen operieren kann – durch das Fegefeuer eines Business Plan Wettbewerbs zu gehen. In der Regel bringt das viel. Auch die Erkenntnis, dass das Projekt keinen Sinn macht, ist ein großer Wert. Das spart viel Geld und Zeit. Die Teilnahme an solch einem Wettbewerb kann auch helfen, die „wichtigen“ Netzwerke und die „richtigen“ Mentoren zu finden.

Aber vor allem!

Ein Start-up ist keine schicke Selbstverwirklichung sondern eine sehr riskante und massive Herausforderung. Dazu braucht es ein begeistertes Team, das bereit für die Aufgabe und offen für Veränderung ist. Wenn das nicht gegeben ist, dann Finger weg! Denn wenn Gründen so einfach wäre wie viele denken, würden nicht so viele Gründer auch im Segment der IKT und Welt der schicken APPs scheitern.

RMD

P.S.
Das habe hier meine persönlichen Gedanken aus meinem subjektivem Erleben berichtet. Sie erheben keinen Anspruch auf Wahrheit. Ich glaube, dass jede Gründung anders ist und ihr eigene Geschichte hat.

So gibt es nach meiner Meinung kein allgemeingültiges Kochrezept für „erfolgreiches“ Gründen. Dem folgend was ich beschrieben habe könnte es aber gehen, anders wird es aber nicht gehen!

P.S.1
Die Daten zum Bild: Es ist von 1808 und heißt „Admiralty carriage mount for a British 18-pounder carronade“.
Quelle: Scanned from Chappelle, Howard I., The History of the American Sailing Navy: The Ships and Their Development, New York: W. W. Norton and Company, Inc., 1949, ISBN 1-56852-222-3, Plate VII, facing p. 152.
Unattributed, apparently from U.S. National Archives