Rezension: „The Lean Startup“ von Eric Ries

Nicht mehr ganz taufrisch, trotzdem Basis einer Management-Schule, die aktueller denn je ist: The Lean Startup. Ich habe seit langem mal wieder Zeit zum Lesen gehabt und mir den Titel von Eric Ries zu Gemüte geführt.

Schlanke Produktentwicklung

Die zentrale Annahme, die sich durch das 2011 erschienene Buch zieht, lautet: Je schneller man als Startup ein Produkt auf den Markt bringen kann, desto eher ist man in der Lage, dessen Erfolg zu überprüfen und das Feedback wiederum in die Verbesserung des Produkts einfließen zu lassen. Das erste Produkt – das sogenannte „minimum viable product“ (MVP) – wird möglichst schnörkellos veröffentlicht, um direkte Rückmeldungen der Kunden zu erhalten. Umfangreiche Features oder sogar „Perfektion“ sind nicht erwünscht. Diese Zeitersparnis führt dazu, dass keine Ressourcen verschwendet, sondern optimal für weitere Optimierungen eingesetzt werden können. Eric Ries beschreibt diesen Kreislauf als „Build-Measure-Learn“ und erteilt damit allen Modellen eine Absage, die auf langen Entwicklungslaufzeiten basieren. Stattdessen plädiert er für das sogenannte „validated learning“ als einer Methode, mit der man vorher aufgestellte Hypothesen überprüft und anhand der Resultate konstant sein eigenes Geschäftsmodell hinterfragt. Dabei setzt er weniger auf die häufig verwendeten „vanity metrics“, also die häufig genutzten empirischen Datenmodelle, mit denen klassischerweise Entwicklungen verfolgt und Erfolge erkannt werden, sondern auf für das jeweilige Experiment relevante Werte.

Was man von Toyota lernen kann

Die Lean-Startup-Methode basiert grundsätzlich auf dem vor allem durch Toyota bekannt gemachten „lean manufacturing“. Diese revolutionäre Produktionsweise, die den japanische Produzenten zum weltgrößten Automobilbauer hat wachsen lassen, hinterfragt grundsätzlich die bis dato geltenden Erkenntnisse bezüglich optimaler Massenfertigungsprozesse. Produktionszyklen werden dabei beschleunigt und Arbeitseinheiten verkleinert. Und was seinerzeit dabei half, den stark fragmentierten japanischen Automobilmarkt zu erobern, gilt laut Eric Ries auch für Entrepreneure in gänzlich anderen Branchen. Er präsentiert zahlreiche Beispiele von Unternehmen, die mit der „schlanken“ Methode ihre Produktentwicklung komplett neu aufgestellt haben und so in der Lage waren, Produkte an den Markt zu bringen, die schneller der Nachfrage entsprachen.

Und das ist auch gleichzeitig einer meiner größten Kritikpunkte an dem anderweitig sehr erhellenden Text: Eric Ries führt eine ganze Reihe von Anwendungsfällen an und reitet dabei auf einzelnen Punkten für meinen Geschmack zu sehr herum. Die Grundlagen seines Modells sind meines Erachtens nicht übermäßig schwer zu verstehen, und wenn man davon ausgeht, dass es im Einzelfall immer Variationen geben muss, hätte man sich die eine oder andere Ausschmückung auch sparen können.

Dessen ungeachtet ist The Lean Startup ein wichtiger Text und seine Lektüre vor allem denen zu empfehlen, die versuchen, ihre E-Commerce-Projekte immer noch mit den Rezepten von vorgestern bewältigen zu wollen.

3 Gedanken zu „Rezension: „The Lean Startup“ von Eric Ries

  1. Matthias

    Naja „Dessen ungeachtet ist The Lean Startup ein wichtiger Text und seine Lektüre vor allem denen zu empfehlen, die versuchen, ihre E-Commerce-Projekte immer noch mit den Rezepten von vorgestern bewältigen zu wollen.“ Dann haben Sie einfach den Unterschied zwischen Produktentwicklung und Projektentwicklung noch nicht verinnerlicht oder gar verstanden. Produktentwicklung ist sehr einfach schlank und agil zu halten, Projektentwicklung kann das nicht oder nur mit großen Abhängigkeiten zu Dritten (Kundenanforderungen usw.) schaffen und somit ist eine sehr agile Entwicklung immer mit sehr großen Risiken verbunden. Gerade im E-Commerce Bereich sind so viele unerfahrene Kunden vorhanden, dass dies zwangsläufig zu problematischen oder unter Umständen verlustreichen bzw. qualitativ schlechten Projekten führen muss. Ich finde diese Darstellung sehr undifferenziert und pauschalisierend. Ein wenig kritische Reflexion ihrer eigenen subjektiven Meinung scheint hier angebracht.

    „zahlreiche Beispiele von Unternehmen, die mit der “schlanken” Methode ihre Produktentwicklung“ … mehr muss man dazu nicht sagen, es ist die fehlende Reflexion der agilen Jünger, die schlechte Qualität in E-Commerce Projekten erzeugt und Standardsoftware oft schlecht dastehen lässt, weil die Projektbeteiligten einfach gar keine Ahnung von dem haben, was sie da eigentlich tun und was ihre Mitwirkungspflichten sind.

    “minimum viable product” (MVP) – wird möglichst schnörkellos veröffentlicht, um direkte Rückmeldungen der Kunden zu erhalten => auch hier ist ganz klar, dass nicht über die Konsequenzen und die Kosten nachgedacht wurde. Desto schneller die Zyklen, desto wahrscheinlicher, dass das Kundenfeedback zu spät passiert und spätere Zyklen negativ beeinflusst. Genauso kritisch ist, dass Kunden dann dazu tendieren diesen Ansatz aber nicht zu verinnerlichen und somit mvp Produkte eher als fertiges Produkt zu sehen, was den Kommunikationsaufwand erheblich erhöht und somit die Kosten usw.

    Gefällt mir

    Antwort
    1. Roman Zenner Autor

      Danke für das konstruktive Feedback. Ich bin jedoch der Meinung, dass die Trennung zwischen Produkt- und Projektentwicklung nicht so scharf ist bzw. sein muss, wie Sie sie darstellen. Und ich bezweifele auch, dass es bezüglich des Komplexitätsgrades zwischen den beiden zwangsläufig große Unterschiede gibt. Auch bei Produkten, die innerhalb eines Unternehmens entwickelt werden, gibt es jede Menge Stakeholder – nur sind diese innerhalb des Unternehmens zu finden und sind eben nicht der (externe) Kunde.

      Ich habe auch die Erfahrung gemacht, dass es bei vielen Projektbeteiligten einen teilweise krassen Mangel an entsprechendem Know-How gibt. Hier bin ich aber der Meinung, dass das nicht nur der jeweils verwendeten Management-Methode geschuldet ist, sondern generell eine Folge mangelhaften Wissens-Managements ist. Und das kann bei Wasserfall genau so der Fall sein wie bei agiler Entwicklung. A propos: wenn agile Entwicklung gleich immer als Freibrief für qualitativ minderwertige Arbeit verstanden wird, ist das schlicht ein Vorurteil. Genau wie bei jeder anderen Methode bedarf es auch hier einer Qualitätskontrolle, sauberer Prozesse und klarer Verantwortlichkeiten.

      Gefällt mir

      Antwort
      1. Matthias

        So scharf negativ, wie es evtl. herüberkam, sollte es auch nicht sein. Grundsätzlich kann agile Entwicklung (und soll es auch) genauso qualitativ hochwertig sein wie andere Methoden. Der Kunde hat vielmehr auch den Vorteil viel direkter Einfluss nehmen zu können, was letztlich auch das Problem daran ist, der Kunde muss vielmehr auch Einfluss nehmen und die Ressourcen und Zeit zur Verfügung stellen.

        Ich gehe absolut mit, dass oft Wissensmanagement Probleme und „Buzzword Riding“ hier ein großes Problem ist. Es wird z.B. oft auch nicht verstanden, dass agil nicht heißt, schneller zu sein, sondern eine andere Herangehensweise ist, mit anderen Zeitfressern (Meetings, Abstimmungen, evtl. mehrfache QA aufgrund Kundenfeedback usw.) und dafür anderen Vorteilen.

        Trotzdem muss ich sagen, dass es meiner Meinung nach deutlich einfacher ist in der Produktentwicklung agil zu arbeiten, als in Projektentwicklungen, es aber durchaus sehr erfolgreich gehen kann, wenn alle den gleichen Wissensstand haben und entsprechend mitziehen.

        Gefällt mir

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s