Meine Checkliste, wenn Du „lean“ arbeiten willst. Learnings aus zwei Jahren mit Lean Startup

Eric Ries hat mit seinem Buch „The Lean Startup“ vor drei Jahren die Startup-Szene gründlich aufgemischt mit einem Versprechen, das süßer nicht sein könnte: Mit Lean Startup wirst du schnell und sicher ein ungemein erfolgreiches Produkt entwickeln.

Der Kerngedanke:

  1. Baue eine einfache Version deiner Produktidee.
  2. Bringe sie so schnell wie möglich auf den Markt.
  3. Verfolge genau, was passiert und passe deine Produktidee an.

Lean Startup hat zweifellos die Art und Weise, wie Produkte heute entwickelt werden, ungemein beflügelt. Der Startup-Boom in Deutschland, speziell in Berlin, ist ohne Lean nicht denkbar. Eine ganze Generation von Produktmanagern ist von Lean Startup inspiriert und versucht es in die Praxis zu übertragen – für die Entwicklung ganzer Geschäftsmodelle, einzelner Produkte und Services oder für die Optimierung bestehender Angebote.

Das ist freilich nicht so einfach, wie es in der Grundformel klingt. Als Head of UX Consulting bei relevantive berate ich Startups und Großkonzerne bei der Umsetzung von Lean Startup in der High Tech Industrie. Deren Produkte sind Apps, Portale, Streaming-Dienste, Content-Plattformen usw. In den zwei Jahren, die wir damit arbeiten, haben sich manche Erwartungen erfüllt, manchmal wurden wir ernüchtert.

Dabei hat der Grundgedanke von Lean Startup für mich nichts an Faszination verloren. Für alle Produktmanager, denen das auch so geht, und die lean arbeiten wollen, hier meine Leanings.

Zunächst: Lean Startup in Reinform wird sehr selten angewandt. 
Ich kenne genau ein einziges Startup, das sich mit einer Value Proposition statt einem fertigen Produkt auf den Markt gewagt hat. Die Anfänge von Zalando („Schrei vor Glück“, Verlag Orell Füssli) sind Legende, werden aber bis heute selten kopiert.

Heute relativ verbreitet ist ein Vorgehen, das ich Pragmatic Lean nennen würde: Solange das Produkt in einer frühen Phase ist, wird in einer geschlossenen Umgebung getestet (UX-Tests, Prototypen, Beta-User u.ä.). Sobald das Produkt Kunden hat und live ist, wird mithilfe von multivariaten Tests und Analytics optimiert.

Für mich ist das Wesentliche an Lean nicht das Testen an sich. Sondern eher, was vor dem Testen passiert und wie mit den Ergebnissen verfahren wird.

1. Lean braucht Prozesse „nach vorn“

Wer versucht, ein Produkt lean zu entwickeln, sollte ein Setup zur Hand haben, wie getestet werden kann. Sobald ein Experiment startet, muss für das gesamte Team klar sein, wer was wann tun und nicht tun wird.

Fragen, die geklärt sein müssen:

  • Wie und wo können wir testen?
  • Ist gerade eine bestimmte Zielgruppe wichtig? Wenn ja, welche?
  • Woher bekommen wir unsere (Test-)Kunden?
  • Wie lautet unsere Hypothese?
  • An was machen wir fest, ob unsere Hypothese stimmt?
  • Wie lange bzw. wie oft wollen wir testen? Ab wann ist für uns ein Ergebnis signifikant?

Mein Tipp:

Wählt wenige Methoden, die so präzise aufgesetzt sind (oder extern bereitgestellt werden), dass ihr das Testen gewissermaßen ohne nachzudenken abspulen könnt. Schafft am besten eine Position im Unternehmen, die sich nur um die Organisation rund um das Testen kümmert. In Startups ist das ein Praktikant, in größeren Firmen sind das externe Dienstleister oder eigene Abteilungen.

Entwickelt feste Zyklen, in denen ihr testet (z.B. alle zwei Wochen). Macht das Produkt genau für die aktuelle Fragestellung testreif (mal ist das ein neues Interface, mal ein Papier-Prototyp). Stimmt Experiment-Zyklen eng mit Scrum-Sprints ab und entscheidet, ob Ihr ein MVP in oder neben Scrum-Sprints entwickelt. Für Prototypen muss nicht zwingend Software geschrieben werden, aber es hilft immer, wenn ein Entwickler mit über den Prototypen nachdenkt.

Schafft Klarheit was das Thema Datenschutz, Privacy und Data Security in Experimenten angeht. Wenn diese Themen das Testen verhindern, könnt ihr nicht lean entwickeln.

2. Lean braucht Prozesse „zurück“

Das oft Unterschätzte an Lean Startup ist der Umgang mit Irrtümern: Wenn sich nämlich eine Idee, die vielversprechend scheint, als Irrtum herausstellt. Wer lean arbeiten will, sollte ein Setup zur Hand haben, was in diesem Fall passieren muss.

Dabei geht es um praktische Fragen:

  • Was passiert inhaltlich?
  • Wie sieht die Nachbearbeitung von Testergebnissen aus?
  • Wie holen wir aus einer falschen Hypothese ein konstruktives Learning?
  • Wie schaffe ich es als Produktmanager, das Team erneut zu motivieren, ggf. für einen ganz anderen Weg?
  • Was passiert technisch?
  • Wie können wir ein neues Feature zurück bauen?
  • Zwingen wir beim nächsten Release alle Nutzer unserer App zum Update oder supporten wir die alte Version weiter?
  • Wer ist dafür verantwortlich?
  • Wie lösen wir das zeitlich?
  • Was passiert mit den Kunden?
  • Wie gestalten wir vertragliche Regelungen rund um ein Experiment? Gibt es Tests nur mit Beta-Usern?
  • Gibt es zeitlich begrenzte Angebote/Versionen?
  • Wie kommunizieren wir unsere Änderungen/Experimente?

Mein Tipp:

Klärt alle diese Fragen, bevor ihr testet. In den seltensten Fällen finden Produktmanager heute bereits Antworten oder fertige Prozesse für Irrtümer. Sie müssen sie erst selbst entwickeln. Teams, die nicht wissen was passiert, wenn eine Hypothese falsch ist, haben Angst vor dem Ergebnis.

Teams, die ihre Strategie nicht ändern können, obwohl sie falsch ist, verlieren die Motivation oder reden sich Fakten schön. Beides ist fatal.

Umgekehrt gilt auch: Wenn ihr von Anfang an wisst, dass ihr Dinge nicht ändern könnt, braucht ihr sie nicht zu testen.

3. Lean braucht ein starkes Produktmanagement

In Unternehmen und Startups begegnen uns zwei grundlegende Vorgehensmodelle:

  • Marketing-getriebene Entwicklung
  • Produkt-getriebene Entwicklung

Aus meiner Sicht schaffen es nur die Produkt-getriebenen Teams, lean zu arbeiten. Das gilt für alle Branchen und Geschäftsmodelle, sei es SaaS, Marktplätze, Communities oder eCommerce.

Der Unterschied liegt in der Sicht auf das zu entwickelnde Produkt. Für Marketing-Experten ist eine Website / eine App / eine digitale Plattform nur ein Vertriebskanal, über den etwas angeboten und kommuniziert wird. Das eigentliche Produkt ist ein Abo, eine Dienstleistung, Content oder konkrete Produkte wie Bücher oder Turnschuhe.

Dabei ist die Art und Weise, wie z.B. ein Abo von den Kunden genutzt werden kann, in der digitalen Welt entscheidend. Würden bis heute Musik-Downloads auf Websites angeboten, die denen von Krankenkassen ähneln, wäre die CD wohl nie verschwunden.

Eine Website ist eine eigene Welt, in die ich mich hinein begebe, und in dem ich ein Produkt erlebe. Diese Welt muss sorgfältig entwickelt werden (Customer Experience).

Lean braucht starke Produktmanager, die an den Details arbeiten und ein Mandat für die Entwicklung der Customer Experience haben.

Mein Tipp:

Lean ist in der Marketingabteilung nicht gut aufgehoben. Sucht eure Jobs in Unternehmen, in denen es ein starkes Produktmanagement gibt, das sich klar von den Aufgaben des Marketing abgrenzt. Je stärker die Position des Produktmanagement, desto wahrscheinlicher ist es, lean arbeiten zu können. Für Lean ideal wäre, selbst die Ergebnis-Verantwortung (P&L) beim Produktmanagement zu verorten. Das liefert die besten Argumente, lean zu arbeiten. Achtet bei der eigenen Aufgabenbeschreibung und in den persönlichen KPIs darauf, dass die Entwicklung einer Customer Experience erklärtes Ziel ist.

4. Lean braucht häufige und harte Entscheidungen

Lean wurde als Idee schnell auch von größeren Unternehmen aufgegriffen. Meist wird als Vorteil von Lean Startup betont, dass es Risiken in der Produktentwicklung minimiert. Build-Measure-Learn scheint Sicherheit zu garantieren. Damit passt es vermeintlich gut in eine Risiko-scheue Umgebung und zu ebensolchen Persönlichkeiten.

Die Wirklichkeit sieht anders aus. Produktmanager, die lean arbeiten, müssen sehr Risiko-bereit und in der Lage sein, sehr harte Entscheidungen zu treffen. Damit ist Lean für die Produktmanager und deren Teams wesentlich unbequemer als ein herkömmlicher Entwicklungsprozess.

Mein Tipp:

Seid euch darüber im Klaren, dass ihr mit Lean unter Umständen jede Woche eine unangenehme Entscheidung treffen und vertreten müsst. Als Produktmanager müsst ihr euer Team über längere Zeit für eine Idee begeistern und sie am Ende doch revidieren können. Das verlangt besondere Führungsqualitäten.

Das beste Umfeld bieten aus meiner Sicht Unternehmen, die unter hohem Wettbewerbsdruck operieren und sich verändern müssen.

5. Lean schafft Werte

Alles in allem ist Lean Startup also eher eine Art Extremsport im Produktmanagement. Warum macht man es überhaupt? Wie kann man im Unternehmen für Lean argumentieren?

Für mich ist ein Argument schlagend: Mit Lean Startup baut man unbezahlbares und nicht käufliches Business-Know-How auf.

Mit jeder Iteration sammelt das Entwicklungsteam Wissen über Chancen im Markt, über die richtigen Angebote und über die richtigen Zielgruppen. Dieses Wissen ist im Team verankert und wird von Mal zu Mal wieder in die Weiterentwicklung eingebracht. Das geschieht auf allen Ebenen (Business Development, Marketing, IT, Design, Kommunikation), trotz oder sogar wegen aller Rückschläge.

Dieses Wissen ist ein Wettbewerbsvorteil!

Meine Faustregel: 
Nach einem Jahr Lean Startup ist eine Firma in Bezug auf Business-Know-How um 3 Jahre weiter. Nach einem Jahr konventioneller Entwicklung ist unter Umständen einfach nur ein Jahr vergangen und das Team weiß über das Business, in dem es operiert, so wenig wie zuvor.

Wie sind eure Erfahrungen mit Lean Startup?

Setzt ihr in eurem Unternehmen Lean Startup ein? Wenn ja würde ich mich freuen, wenn ihre eure Erfahrungen mit uns teilt! Was lief gut, wo traten Probleme auf und was habt ihr dabei gelernt?

 

 

 

Über Angela Kreitenweis (Gastautor)

Angela Kreitenweis ist Head of UX Consulting bei relevantive in Berlin. Dort entwickelt sie für Unternehmen Prozesse und Vorgehensweisen, um die Kundenperspektive ins Unternehmen zu bringen. Sie berät große Unternehmen wie BMW oder die Allianz zu Lean und Design Thinking und ist als Mentor für verschiedene Startups im Einsatz, auch in Acceleratoren wie Axel Springer Plug and Play oder hub:raum. Von Haus aus ist Angela Interaction Designer, studierte an der HfG in Schwäbisch Gmünd und in Zürich und hat als UX Designer zwei Startups von der ersten Idee bis zum Launch begleitet. Anschließend war sie für D-LABS (Hasso Plattner Venture) als Project Director tätig und war weltweit für UX-Studien unterwegs, unter anderem in USA, China und Brasilien. Wenn nicht in der Arbeit ist Angela oft auf Meetups in Berlin oder München zu treffen, vorallem wenn es um die Themen Produktentwicklung, Service Design, Sharing Economy oder Quantified Self geht. Sie twittert unter @AKreitenweis.

Ein Kommentar

  1. Detlev Petersen

    Hallo,

    vorweg gesagt, ich nutze Lean Startup selbst nicht. Den Ansatz finde ich aber gut. Das hat verschiedene Gründe.

    Wir nutzen bei uns SCRUM, jedoch denke ich, dass der Austausch über das Optimieren und Korrigieren der Arbeitsinhalte und Arbeitsweisen zu wenig stattfindet. Lean Startup scheint mir hier stärker den Gedanken zu berücksichtigen, periodisch und permanent mit vollem Bewusstsein das eigene Tun zu reflektieren. Iteratives Vorgehen kann auch schnell darauf reduziert werden, ein Review der Ergebnisse durchzuführen und neue Handlungsprioritäten zu bestimmen. Das ist dann zwar agil und zeigt Probleme beim Planen und Umsetzen auf, berührt aber nicht zwangsweise den Kern dessen, was für ein effektiveres Arbeiten zu besprechen und zu diskutieren wäre. Dieses Korrektiv, die stärkere Auseinandersetzung mit dem, was wie gemacht wird, scheint Lean Startup zu adressieren.

    Das starke Produktmanagement würde ich auch aus anderer Sichtweise befürworten. Für mich ist das Produktmanagement der Prioritätengeber für langfristige und projektübergreifende Ziele, während das Projektmanagement Prioritäten für kurzfristige Ziele setzt, damit die wichtigsten Probleme zuerst bearbeitet und erledigt werden. Ohne Produktmanagement fehlt mir das Gleichgewicht zwischen kurzfristigen und langfristigen Handlungsprioritäten. Ist das Gleichgewicht gestört, bin ich entweder mitten in einem aufgescheuchten Hühnerhaufen oder reite auf der langsamsten Schnecke ins Ziel, um dort festzustellen, dass schon längst keiner mehr wartet. Ein Produkt muss mehr als nur für 1 Projekt etwas taugen, damit ich für hohe Entwicklungsaufwendungen die Möglichkeit habe, in den Bereich einer wahren Wertschöpfung zu kommen und nicht auf Ebene einer Wertevernichtung zu verharren. Dafür benötige ich ein Produkt, was sich projektspezifisch bzw. kundenspezifisch konfigurieren lässt, während das Produkt an sich und dahinter das Gleiche ist, halt nur mal in jenem und mal in einem anderen Gewand.

    Viele Grüße
    Detlev

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.