Alle Aktivitäten eines Entrepreneurs kosten Zeit. Das Gleichgewicht zwischen diesen "Pulls" zu finden, ist eher eine Kunst als eine Wissenschaft, doch es gibt ein fundamentales Prinzip, das präsent sein muss, um die Produktivität zu maximieren: Flow. Im ersten Teil des Artikels hat sich Lean-Startup-Experte Ash Maurya dem Flow-Konzept mithilfe zweier Definitionen genähert. Nun zeigt der Autor spezifische Work-Hacks, die er nutzt, um Voraussetzungen für Flow zu schaffen.
Täglichen Flow erzeugen
Grundsätzlich gruppiere ich meine tägliche Arbeit in drei Kategorien: geplante Macher-Aktivitäten, geplante Manager-Aktivitäten und ungeplante Macher-/Manager-Aktivitäten.
Work-Hack 1: Unterbrechungsfreie Zeitblöcke für Macher-Arbeiten etablieren
Meine geplanten Macher-Aktivitäten bestehen in der Regel aus Coding und dem Schreiben von Aufgaben, die ich zuvor identifiziert habe. Weil diese Aktivitäten einen Zeitblock ohne Unterbrechungen brauchen, plane ich sie für sehr früh am Morgen ein (6 bis 8 Uhr). Normalerweise plane ich diesen Block am Abend vorher, und diese Aufgaben sind die ersten und einzigen, denen ich mich zunächst widme. Ich lese keine E-Mails und schaue nicht auf Twitter. Um diese Zeit ruft niemand an, also sind Unterbrechungen auf ein Minimum zurückgefahren. Zwei-Stunden-Blöcke funktionieren für mich am besten.
Work-Hack 2: Macher-Ziele so früh wie möglich am Tag erreichen
Ich habe sowohl langes Aufbleiben als auch frühes Aufstehen probiert, und ich bevorzuge letzteres, da es nicht von Schlaf unterbrochen wird und bessere Voraussetzungen für den Flow der Aktivitäten des Tages bietet. Persönlich finde ich auch, dass es den Tenor für den Rest des Tages beeinflusst, wenn ich gleich morgens etwas Wichtiges fertig bekomme. Je nach Wochentag plane ich mitunter weitere Zwei-Stunden-Blöcke für den Vor- oder Nachmittag ein, aber diese erreichen nicht die Intensität des ersten und können auch häufiger von dringenderen Dingen unterbrochen werden.
Work-Hack 3: Manager-Aktivitäten so spät wie möglich einplanen
Geplante Manager-Akivitäten wie Kunden-Meetings sind leichter zu planen, da es klare Zeitfenster und Kalendertermine gibt. Solange es keinen Planungskonflikt gibt, bevorzuge ich es, sie auf den Nachmittag zu legen, damit sie meinen morgendlichen Flow nicht unterbrechen.
Work-Hack 4: Immer auf ungeplante Aktivitäten (speziell Kunden-Support) vorbereitet sein
Unerwartete Unterbrechungen können im Tagesverlauf von überall her kommen – Server-Vorfälle, Anrufe beim Kunden-Support usw. Sie müssen auf Unterbrechungen vorbereitet sein, speziell auf welche durch Kunden. Sowohl Server-Alarme als auch Kundenanrufe über eine 800-Nummer werden direkt auf mein Mobiltelefon weitergeleitet. In diesem Zusammenhang ist es gut, das Five-Whys-Prinzip anzuwenden, um sicherzustellen, dass sich unerwartete Vorfälle nicht wiederholen.
Wöchentlichen Flow schaffen
Neben der Tagesorganisation für Flow gruppiere ich auch diverse Arbeiten nach Wochentagen.
Work-Hack 5: Die besten Tage für Customer Development identifizieren
Beispielsweise sind Montage und Freitage normalerweise schlecht, um neue Kundenkontakte zu initiieren, da sich viele entweder noch vom Wochenende erholen oder sich darauf vorbereiten. Ich plane diese Arten von Customer Development zwischen Dienstag und Donnerstag ein.
Work-Hack 6: "Langsame" Tage der Kunden produktiv nutzen
Da Montage und Freitage aus Kundenperspektive eher langsamer sind, nutze ich diese Tage für größere Macher-Aufgaben wie das Schreiben von Blog-Artikeln. Meine Blog-Post-Themen identifiziere ich oftmals Freitags, am Wochenende umreiße ich sie grob, schreibe und prüfe sie am Montag und veröffentliche sie am Dienstag.
Work-Hack 7: Face-Time mit Kunden ausbalancieren
Nicht alle Aktivitäten im Zusammenhang mit Customer Development erfordern Face-Time. Jenseits des initialen Customer-Discovery-Stadiums gibt es eine starke Tendenz, mehr auf asynchrone Kommunikation mithilfe von Tools wie der E-Mail, Foren und Online-Usability-Tests zu setzen. Während all diese Tools toll sind, um das Aufkommen an Echtzeitstörungen zu verringern und zu skalieren, finde ich es wichtig, weiterhin Gelegenheiten für direkte Gespräche mit bestehenden und neuen Kunden zu finden. Improvisierte Konversationen sind die beste Möglichkeit, etwas über improvisierte Probleme zu lernen. Ich hab unsere 800-Nummer auf alle Seiten gepackt und ermutige Kunden, wann immer möglich zum Telefon zu greifen, statt zu mailen.
Software-Verschwendung eliminieren
Software auf Basis von Spezifikationen zu bauen, ist schwer genug. Daher ist es in einer Startup-Umgebung, in der sowohl Probleme als auch Lösungen weitgehend unbekannt sind, optimal, um wenig Code herum zu iterieren statt um viel Code.
Work-Hack 8: Überproduktion vermeiden, indem Kunden Features anfragen
Customer-Pull ist ein weiteres Konzept aus dem Lean-Denken, das besagt, dass kein gutes Produkt und dass keine gute Dienstleistung produziert wird, ehe nicht ein Kunde danach fragt. In diesem Stadium investiere ich über 80 Prozent meiner Anstrenungen in die Optimierung bestehender Features statt in die Entwicklung neuer. Customer Development dreht sich nur darum, ein MVP zu identifizieren, auf das Kunden anspringen; Kundenvalidierung dreht sich darum zu testen, ob diese Resonanz skalieren wird. Wenn nicht, besteht die Lösung nicht im Hinzufügen von Features, sondern womöglich in einem Pivot und darin, zurück zu Schritt eins zu gehen – Customer Discovery.
Work-Hack 9: Um drei bis fünf belastbare Metriken herum iterieren
In früheren Artikeln habe ich mein Conversion-Dashboard schon detailliert besprochen. Einige belastbare Metriken sind alles, was ich brauche, um die kritischsten Build-Measure-Learn-Loops, die ich angehen muss, zu identifizieren und zu priorisieren. All die Daten auf diesem Dashboard werden automatisch gesammelt und in Form eines einseitigen Berichts präsentiert, den ich in Echtzeit ansehen kann.
Work-Hack 10: Software so bauen, dass sie fließt
Vielleicht ist Ihnen aufgefallen, dass ich keine speziellen Tage festgelegt habe, an denen Software gebaut, getestet oder ausgeliefert wird. Das liegt daran, dass ich einem Continuous-Deployment-Prozess folge (den auch Eric Ries bekannt gemacht hat), der vorsieht, dass Software automatisch gebaut, getestet und gepackt wird, sobald eine Macher-Aufgabe erledigt ist. Ich brauche nichts weiter zu tun, als den Code einzuchecken. Ein Klick und der Code wird an die Kunden ausgeliefert.
Zur Erinnerung noch einmal die Definition von Womak und Jones:
Verschwendung ist jede menschliche Aktivität, die Ressourcen absorbiert, aber keinen Wert schafft.
Herstellungsprozesse wurden traditionell um Maschinenzeit herum arrangiert; Aufgaben wurden in Stapel und Warteschlangen aufgebrochen. Das Lean-Denken fordert diesen Ansatz heraus und ruft danach, Aufgaben so um menschliche Zeit herum zu organisieren, dass Flow entstehen kann. Das Ausliefern von Software ist gar nicht so anders als der klassische Produktionsprozess. Während es sicher einfacher ist, webbasierte Software mit Continuous Deployment ständig zu aktualisieren, kann mit ein bisschen Disziplin auch Desktop-Software zum Fließen gebracht werden. Mein Continuous-Deployment-Prozess ist aber Thema eines anderen Artikels.
