Das Team von flaschenpost.ch denkt heute kritisch über seine erste grosse Investitionsentscheidung – ein Rückblick auf das Gelernte.

von Dominic Blaesi, Gründer flaschenpost.ch

Startup-Tagebuch von Dominic Blaesi

Nachdem Renzo und ich (wie im letzten Startup-Diary erzählt) 2008 100% bei Flaschenpost einstiegen, war für uns klar, dass wir unsere Marktleistung noch einmal deutlich verbessern wollen. Dabei waren wir angetrieben von der Überzeugung, dass die Verkäufe praktisch von alleine kommen werden, wenn wir nur über das „perfekte Angebot“ verfügen. Unter Angebot verstanden wir damals vor allem unseren Webshop. (Diese Sichtweise stellte sich natürlich als viel zu eng heraus – doch darüber mehr in einem späteren Beitrag.)

Feature-Overload?

Ausgehend von dieser Überzeugung kamen wir zum Schluss, dass unsere Aufgabe und der Schlüssel zum Erfolg darin bestanden, den „besten Weinshop der Schweiz“ zu bauen. Wir setzten also ein entsprechendes Projekt auf und begannen unsere Anforderungen zu definieren und den neuen Shop zu spezifizieren. Unerfahrenerweise taten wir das auf der grünen Wiese und entwickelten einen Wunschkatalog an Funktionalitäten und Designanforderungen, der durch kein Standardsystem mehr zu erfüllen war. Da wir praktisch alle Features als „must- have“ taxierten, blieb uns nichts anderes übrig, als eine Eigenlösung zu bauen. Diese Entscheidung verhiess Schwindel erregend hohe Kosten – grösser als die gesamten bisherigen Investitionen. Überzeugt davon, die richtigen Annahmen getroffen zu haben, entschieden wir uns dennoch, diese (bis heute grösste) Investition zu tätigen. Eine Entscheidung, die ich rückblickend kritisch beurteile…

NPV als Messlatte

Was würde ich heute anders machen? Zunächst würde ich die Annahmen, die einer solch bedeutenden Investition zugrunde liegen, eingehend hinterfragen. Innerhalb unserer Grundüberlegung (Webshop = Erfolgsfaktor No.1) war unsere Entscheidung sicherlich konsistent und richtig. Hätten wir die Bedeutung des Webshops aber anders eingestuft – was wir heute zugunsten der Vermarktung tun würden – wäre eine Investition dieses Umfangs nicht rechtfertigbar gewesen.

Zweitens würde ich versuchen, die Opportunitätskosten der durch das Projekt gebundenen Mittel zu ermitteln und den NPV (Net Present Value = abdiskontierter Wert aller durch die Investition generierter künftiger Zahlungsströme abzüglich der Anfangsinvestition) der geplanten Investition anderen Investitionsmöglichkeiten gegenüber stellen. Eine Investition ist nie Selbstzweck und damit gilt es, die immer gleiche Frage zu beantworten: Wie erreiche ich mein Ziel (in unserem Fall das möglichst rasche Erreichen der Gewinnschwelle) mit minimalem Mitteleinsatz?

IT-Erfahrung: Buy statt Make

Obschon uns die erwähnten Konzepte bestens vertraut waren, haben wir sie bei unserer grössten Investitionsentscheidung einfach ausser Acht gelassen! Weiter würde ich versuchen, so viel Erfahrung wie möglich zu organisieren. Gerade bei IT- Projekten hängt der Erfolg vom Erfahrungsschatz der involvierten Personen ab. Da weder Renzo und ich, noch unsere Agentur zum damaligen Zeitpunkt ein e-Commerce-Projekt von vergleichbarem Umfang realisiert hatten, war dieser kritische Erfolgsfaktor für unser Projekt nicht gegeben – was wir mit einem entsprechenden Lehrgeld bezahlten.

Während die obigen drei lessons learned vermutlich allgemein gelten, bezieht sich der letzte Punkt vor allem auf den IT-Bereich: Ich würde es heute tunlichst vermeiden, eine Eigenlösung zu entwickeln.

In der Rubrik Startup-Diary schildern Jungunternehmer wöchentlich, mit welchen praktischen Problemen sie in ihrem Gründeralltag konfrontiert werden und welche Lösungsansätze sie gefunden haben.
Bei allen Vorzügen, die ein eigenes System mit sich bringt, indem man die unbequeme Triage zwischen „nice-to-have“ und „must-have“ weniger machen muss, sind die Kosten und die Risiken einer Eigenentwicklung meist höher, als die einer Standardlösung. Und auch hier gilt: Keine Funktionalität ist Selbstzweck, sodass das Weglassen von nicht unbedingt nötigen Anforderungen meist die Kosten senkt, ohne den Nutzen des Systems empfindlich zu beeinträchtigen.