Blog

Online-Produkte zu entwickeln ist teuer. Wenn das Konzept einmal definiert ist, kann die Kalkulation nur für die Programmierung eines eher kleinen Produktes in etwa so aussehen:

Angesichts solcher Summen werden schnell mögliche Wege für Einsparungen diskutiert. Der erste Hebel ist der Tagessatz der Mitarbeiter. Aber der ist stark von den lokalen Gegebenheiten am Arbeitsmarkt abhängig und nur in engen Grenzen beeinflussbar. Off-Shoring wird zwar gerne probiert, der Kosteneffekt wird allerdings durch größeren Overhead oft genug komplett aufgefressen. Für den zweiten Hebel, die Entwicklungszeit, gibt es wiederum eine Unzahl verschiedener Ansätze und Glaubensrichtungen, aber auch hier ist die Wirkung auf die Entwicklungskosten in aller Regel gering. Hinzu kommt, dass Änderungen an Teamstrukturen und Prozessen enorm viel Zeit in Anspruch nehmen. Unterm Strich sind Einsparungen in Höhe von 10% schon ein großer Erfolg. In unserem Beispiel wären das gerade 21.600 EUR, die irgendwann in der Zukunft bei ähnlichen Projekten realisiert werden könnten.

Wenn schon Entwicklungszeit und Personalkosten nicht substantiell gesenkt werden können, bleibt der dritte Hebel: Die Opportunitätskosten möglichst gering halten, indem die richtigen Dinge umgesetzt werden. Sobald es aber über einfache Optimierungen bestehender, bereits skalierender Produkte hinausgeht, ist der Anteil von „richtigen Dingen“ in Konzepten, die in die Entwicklung gehen, erstaunlich klein.

Auch wenn sich Unternehmen in einer Domäne bereits sehr gut auskennen, viel grundlegende Marktforschung betreiben, regelmäßig und strukturiert Kundenfeedback einsammeln und vor Beginn der Umsetzung in Usability Labs testen, dann sind nach unserer Erfahrung immer noch 75% aller Features in komplexeren Konzepten entweder überhaupt nicht oder nur für eine sehr kleine Teilmenge der Kunden relevant.

Unserer 75%-Heuristik folgend, sind in dem Kalkulationsbeispiel von den 216.000 EUR Gesamtkosten stolze 162.000 EUR potentiell verschwendet. Zusätzlich zu berücksichtigen sind noch andere, schwer zu kalkulierende Opportunitätskosten in Form von entgangenem Umsatz.

Das wahre Potential zur Einsparung liegt also nicht darin, effizient zu sein, sondern das Richtige zu entwickeln. Da aber nur im direkten Kundenkontakt gelernt werden kann, welche 75% der Features nicht relevant sind, kommt es darauf an, möglichst schnell und mit viel Fokus anhand valider Experimente iterativ zu lernen. Je öfter valide Iterationen durchlaufen werden, desto weniger Featurewaste gibt es.

Ist die Entwicklung einmal gestartet, wird Lernen durch die relativ großen Teams teuer. Lernen ist dann auch nur noch begrenzt möglich, da Feedbackloops lange dauern und es schwer ist, bei einer einmal in Schwung gekommenen Entwicklungsmaschine Anpassungen vorzunehmen. Nur die wenigsten Teams stellen Code nach Abschluss eines Sprints oder eines Features wirklich live. Oft findet überhaupt kein Lernen statt, da der Scope von vornherein festgelegt wird und gerade so eben in der vorgesehenen Entwicklungszeit durchgezogen werden kann. Iterationen werden dann oft als Störfaktoren wahrgenommen. Im Zweifel werden bei Problemen eher noch mehr Entwickler auf das Projekt geworfen, um die vorgesehene Anzahl an Features live stellen zu können, als innezuhalten und zu lernen.

Das Ziel muss es immer sein, auch während der Entwicklung weiter zu lernen, aber ein großer Teil der 75% Featurewaste kann bereits VOR dem Entwicklungsstart beseitigtwerden. Dafür müssen allerdings andere Ansätze her als für viel Geld Feedbacktools, Lab-Tests und grundlegende Marktforschung einzukaufen.

Wie das gehen kann, zeigen wir in unser Fallbeispiel. Auch Jake Knapp von Google Ventures beschreibt einen Ansatz sehr anschaulich in seinem Post „The product design sprint: A five day recipe for startups„. In beiden Fällen durchläuft ein kleines Team innerhalb von nur fünf Tagen den Prozess von der Problemdefinition und -durchdringung über Ideation bis hin zum Prototypenbau und zur Validierung mit echten (!) Kunden – bevor überhaupt irgendeine Zeile Code programmiert ist.

Die fünf Tage für eine solche Konzeptdesignphase lassen sich je nach Problemstellung auch noch deutlich verkürzen, aber rechnet man einen Sicherheitspuffer von zwei weiteren Tagen hinzu, um noch zusätzliche Iterationen mit Kunden zu ermöglichen (vorausgesetzt natürlich, dass Konzept hat keine fundamentalen Probleme), sind auf jeden Fall mehr als 15 Iterationen erreichbar – und zwar nicht mit einzelnen ersten Features, sondern mit einem kompletten Userflow. Das reicht nicht nur, um die 75% Featurewaste mit Kosten von 162.000 EUR zu vermeiden, sondern verbessert das Konzept fundamental und ermöglicht dann bei der späteren Umsetzung eine umso steilere Lernkurve, die sich in deutlich früheren und höheren Umsätzen widerspiegelt.

Für das Konzeptdesign werden nicht mehr als 4 Personen benötigt (zum Beispiel 1x Interaction Architect/Designer, 1x Product Manager, 1x Developer, 1x Vertrieb), so dass sich ungefähr die folgenden Kosten ergeben (zuzüglich ggf. noch 20-60 EUR Kosten pro Proband, je nachdem, um welche Kundengruppe es sich handelt und wie diese rekrutiert werden):

Das Ergebnis der vergleichsweise kleinen Investition von rund 17.000 EUR ist imposant. Und wer ehrlich zu sich selbst ist, wird feststellen, dass diese Konzeptkosten in aller Regel auch noch weit unter denen herkömmlicher Vorbereitungsarbeiten liegen.

Es lohnt sich also, zielgerichteter in die Konzeptarbeit vor Beginn der Entwicklung zu investieren und neue Methoden auszuprobieren. Das Risiko ist gering, die Chancen sind riesig. Wer seinen CFO zu einem Experiment überreden möchte, sollte schnell Excel mit seinen eigenen Zahlen und Annahmen füttern.

Foto von Joe Haupt auf flickr unter CC Lizenz