Bildquellen: Reddit, WiWo, Heidenheimer Zeitung, Rainbowknight at Wikipedia, Xelibri 4 Mobile Phone, Collage, CC BY-SA 3.0
Die Déformations Professionnelles von Ingenieuren und BWLern
Kennen Sie auch diese Situation? Ein neues Produkt wird gelauncht. Von allen Seiten gibt es Schulterklopfen für all die tollen Features, die das Team ins Produkt integrieren konnte. Bei diesen Funktionalitäten und dieser Produktqualität muss es doch ein Einfaches sein für Marketing und Vertrieb, das Ganze zum großen Erfolg zu machen. Schließlich steckt ja eine Menge technischer Hirnschmalz und eine beträchtliche Entwicklungszeit darin, oder?
Was auf der Launchparty manchem Ingenieur, Techie und unbedarfter Managerin verzücken mag, würde bei erfahrenen Startup Unternehmern und agilen Produktmanagern eher ein Gefühl des Schauderns kreieren. Warum? Weil bei solchen Feature-reichen Big-Bang-Launches zu viele Zeichen auf Verzettelung und unklaren Fokus stehen. Sie sehen vor ihrem geistigen Auge schon all die Probleme im späteren Verlauf, wie z. B. mehr Abhängigkeiten und Tech-Debt, aufwändigere Wartung, viele Change-Requests, hoher Aufwand für Push-Marketing- und Vertriebsschulungsmaßnahmen; usw.
Wenn man das Produktteam fragt, warum all diese Gimmicks und Funktionalitäten eingebaut wurden, lautet die unausgesprochene Wahrheit oft: „Weil wir’s können“. So verbauen z. B. deutsche B2C Cleantech-Hersteller in Ihre Anlagen für den Heimgebrauch Raumfahrt- und Renntechnologien. Der minimale Effizienzgewinn steht in keinem Verhältnis zum Aufwand der erhöhten Komplexität der Anlage. Keiner der chinesischen Konkurrenten würde das tun, auch wenn er es könnte, denn für Kunden ist dies schlicht kein Kaufkriterium. Einer unserer großen deutschen Industriekunden nennt dieses Verhalten »Happy Engineering« — weitläufiger ist es bekannt unter dem Begriff »Over-Engineering«. Im IT-Kontext redet man auch gerne von Bloatware und Featuritis.
Und Wasserfall-artiges Over-Engineering ist auch eines der Grundprobleme von Technologie-getriebenen Innovationen, bei denen eine Lösung ein Problem sucht. Seine Erfinder wissen oft noch nicht für welchen Kunden und Anwendungsbereich sie eigentlich bauen, und können daher auch schlecht abschätzen, welche Eigenschaften und »Darreichungsformen« Ihrer Lösung den meisten Wert stiften werden. Darum packen Sie rein, was geht — alles basiert auf Ihren eigenen Annahmen, was die Welt wohl brauchen könnte. Und selbst, wenn sie nicht in die Falle des Over-Engineering tappen, so interagieren sie traditionellerweise mit Kunden nur über veraltete, klassische Marktforschungsmethoden und bauen dann Produkte, die zwar bei einer selektiven Fokusgruppe Resonanz finden mögen, aber am echten Markt vorbei gehen.
Lange hat dies auch in der Startup-Welt des Silicon Valley so funktioniert. Das Rezept lief so: Mache einen Abschluss an einer Elite-Uni; sammle mit einer tollen Tech(Idee) einen Haufen Geld ein; gib Vollgas und baue das Ganze; dann präsentier’ stolz Dein Baby der Welt und lass Marketing den Rest erledigen. Leitmotto: „Build it and they will come!“ Großkonzerne und Mittelständler tun dies dazu noch mit der in Deutschland üblichen Tendenz zu besonderer Gründlichkeit und »Qualität«. Diese Wette geht aber in den meisten Fällen nicht auf, weil Gründer oder Produktteams dann zwar mit toller Technologie dastehen, es aber für diese keine zahlungsbereiten Kunden gibt, oder jene nicht bereit sind, die sog. »Switching Costs« dafür zu tragen.
For every one of our failures, we had spreadsheets that looked awesome.
Scott D. Cook, Founder of Intuit
In einer solchen Situation hilft es dann auch nicht einen perfekt durchexerzierten Business Plan oder Investment Case zu haben, in dem Marktpotenziale annahmenbasiert aus Studien und Desk-Research extrapoliert wurden. Jonglieren mit historischen Daten ist nämlich wie Rückspiegelfahren im Auto. Man kann nur das perfekt messen und beziffern was in der Vergangenheit war. Auch sind Fremddaten, im engl. „Other People’s Data (OPD)“ genannt, oft problematisch, weil in nicht relevanten Kontexten erhoben. Was Produktteams eher brauchen sind frühe Marktsignale und eigenerhobene kontextspezifische Daten, „Your Own Data (YODA)“ . Zu früh einen Business Plan im stillen Kämmerlein zu schreiben, ohne mal rausgegangen zu sein zu Kunden und Nutzern sorgt also dafür, dass man sein Produkt am Markt vorbeibaut. Denn wie hat Helmuth v. Moltke so schön gesagt: „Kein Plan überlebt die erste Feindberührung“. Man könnte auch sagen: Kein Business Plan überlebt den ersten Kundenkontakt. [ weiter … ]
