Operative Hektik oder warum man in Q4 die Roadmaps in Ruhe lassen sollte

Das vierte Quartal hat angefangen und in den Boardmeetings und Management-Offsites wird landauf, landab festgestellt, dass man doch eigentlich wieder viel mehr hätte erreichen wollen in diesem Jahr.

Also wird beratschlagt, wie man vielleicht doch nochmal ein paar Meter machen, ein paar Euros verdienen, ein paar mehr Nutzer, mehr Clicks, mehr Upsells realisieren kann. Man beschliesst Marketinginitiativen, sucht nach Gegenmaßnahmen und findet, dass eine Pressemitteilung zu einem neuen digitalen Produkt sich nochmal gut machen würde.

Also ruft man nach “der Roadmap”, schaut auf die Planung und schiebt ein Thema nach hinten um vorne zwei Neue einzuplanen. Der Frage nach Priorität weicht man als Manager aus, weil man eigentlich weiss, dass nur ein Thema Priorität 1 haben kann. Für den Erfolg der Firma sind doch beide Themen wichtig.

Nur warum verstehen die Mitarbeitern das immer nicht? Warum wabert jetzt wieder wochenlang diese gefühlte Unzufriedenheit über die Gänge?

Not to do: Auf Managementebene je Entwicklungsteam mehr als 90 Minuten im Jahr über „mögliche neue Themen” für die Produktentwicklung sprechen.

C-Levels oder Manager einer guten Produkt- bzw. Entwicklungsorganisation dürfen sich noch nicht einmal 90 Minuten im Jahr inhaltlich Gedanken über ihre Roadmap für ein Entwicklungsteam machen. Denn aus 30 Minuten Diskussion und Ideenfindung im Management werden 4 Monate Arbeit für dieses Team!

Wie kommt es dazu?

Nach einem Managementmeeting passiert folgendes: der Manager spricht mit dem verantwortlichen Produktmanager über das “neue Thema” und bittet ihn darum, das asap anzugehen.

Daraufhin macht der Produktmanager ein paar erste Meetings um zu verstehen, wie die Managementanforderung zu den Nutzerbedürfnissen passen und spricht über einige Ansätze mit seinem (Interaktions-)Designer. Denn wenn die Kunden nicht brauchen was das Management sich ausgedacht hat, will der Produktmanager wenigstens seine Bedenken zum Ausdruck bringen.

Nach den ca. 4 Nettostunden, die er dafür gebraucht hat spricht er seine Ideen nochmal mit seinem Manager durch. Dieser mag die Ansätze und bittet darum weiter an dem Thema zu arbeiten. Meistens bekommt das “neue Thema” jetzt noch flux einen griffigen Deckamen. Gerne was griechisches oder den Namen eines Wikingergottes.

Anschliessend beginnt die eigentliche Arbeit. Einige Firmen nennen dasDiscovery-Phase, andere sprechen von der Grobkonzeption. Jetzt werden Personas konkretisiert, Storymaps ergänzt oder gar neu gezeichnet, UseCases oder UserStories formuliert, Scribbels gezeichnet, Prototypen gebaut, Usability-Tests gemacht, Backlogitems geschrieben, Schätzungen gemacht, Features wieder gestrichen, Entwickler anderen Projekten zugewiesen, “noch schnell” das fertig gemacht, was noch in der Implementierung war. All diese Sachen macht der Produktmanager nicht mehr allein. Jetzt läuft die Maschine, jetzt wird richtig Aufwand in das Thema gesteckt. Interaktionsdesigner prüfen was nutzbar ist, Entwickler machen den ein oder anderen “proof of concept”, Marketingstrategen denken schon mal über die Landingpage nach, der PR Kollege überlegt schon mal wie die Pressemitteilung lauten könnte und bei alle dem merkt der Produktmanager, dass das Thema größer und größer wird, die Feature-Ideen zahlreicher und zahlreicher werden und die Erwartungen mehr und mehr zunehmen.

Am Ende sind ca. 4 Wochen ins Land gegangen und nennenswert viele Stunden Arbeit angefallen. Es gibt ein sinnvolles Konzept und, weil man einigen Nutzern schon einen Prototypen zeigen konnte, kann man sich auch sicher sein, dass „das neue Thema” gut ankommen wird. Somit startet man mit der Implementierung.

Erst ist das Entwicklungsteam noch ein wenig verschnupft, weil sie das letzte Thema so schnell abschliessen mussten. Aber der Produktmanager macht seinen Job gut und kann nachvollziehbar erklären warum das “neue Thema” viel spannender und sinnvoller ist und so geht alles seinen normalen, meist agilen Entwicklungsgang.

Doch jetzt wo die Entwickler anfangen die Funktionen in Software zu giessen kommen noch massig Fragen ans Tageslicht und es müssen viele Details besprochen werden. Außerdem machen Sales und Marketing den Go-to-Market-Plan und kommen mit ständig neuen Anforderungen ohne die sich das Produkt “auf gar keinen Fall an den Mann bringen lässt!!!” Das Backlog wird länger und länger.

Weil der Produktmanager seinem Manager aber gerne schnell einen Erfolg vorweisen will und weil er auch weiss, dass Software nicht besser wird, wenn man nur lange genug daran herumschraubt, sagt er häufig den Satz “das machen wir dann später” oder “das ist dann Teil des 2. Meilensteins, wir bauen erst mal die einfache Lösung.”

Dennoch gehen 4 Monate ins Land bis die ursprüngliche Idee aus dem Managementmeeting in einer minimalen Version fertiggestellt ist und “released” werden kann.

“Endlich” denkt das Management. Und manchmal denkt es auch “warum bitte ging das denn jetzt bitte so lange?!?!”. Und alle freuen sich über die Pressemitteilung und dass erste Nutzer die Funktion/das Produkt/die App benutzen. Und der Produktmanager freut sich darauf noch ein paar von den “should haves” umzusetzen nachdem ja in der ersten Version nur die “must haves” das Licht der Welt erblickt haben. Und er will auch gerne auf die erste Welle an Nutzerfeedback hören und ein paar Sachen aufgrund der Kundenwünsche verbessern.

Doch letzte Woche war wieder Managementmeeting… und so kommt “das nächste neue Thema” diesmal mit dem Namen eines spanischen Seefahrers. Und er weiss, er wird jetzt 4 Wochen an dem Konzept dazu arbeiten während das Team “noch schnell” das fertig gemacht hat, was noch in der Entwicklung war. Und dann startet der ganz normale Wahnsinn von vorne.

Warum genau das eine Gefahr für ein Unternehmen darstellt

Der oben beschriebene Ablauf ist der, der in ganz normalen Organisationen mit eingespielten, crossfunktionalen Teams zu finden ist. In solchen Unternehmen birgt diese Geschichte mit dem “neuen Thema” die Gefahr, dass die Qualität des Produktes und der Software auf Dauer leiden.

Denn läuft alles, wie oben beschrieben, kann das Team nach der ersten Iteration nicht noch eine gewisse Zeit an den Details arbeiten. Dabei sind sicher technische Schulden aufgelaufen und im Backlog sind bestimmt noch wichtige Komfort-Funktionen, die für den Nutzer einen echten Unterschied machen würden.

In weniger gut organisierten Unternehmen ist die Gefahr allerdings viel größer. Denn dort wird oft schon vergessen die Ideen aus dem Management mit den Nutzer- bzw. Kundenbedürfnis abzugleichen. Wird das vergessen ist das “neue Thema” dann am Markt oft der totale Flopp.

Die allergrößste Gefahr ist allerdings, dass das Management sich alle paar Wochen ausführlich Gedanken zum Produkt macht und immer neue Ideen an den Produktmanager adressiert. Noch bevor dieser über die letzten Ideen nachdenken konnte. Was dann passiert beschreibt Prof. Dr. Peter Kruse auf wunderbar ironische Weise.

Die Veränderungsgeschwindigkeit auf der Beschlussebene sollte stets größer sein als auf der Umsetzungsebene — eine seiner 8 Regeln für den totalen Stillstand in Unternehmen.

Also machen Sie diesen Fehler nicht!

Das Management sollte folglich gut überlegen, welche seiner Vorhaben/Ideen an den Produktmanager gehen. Und vor allem sollte es eine Kultur im Unternehmen geben wonach Vorhaben auch in der Grobkonzeption mal beerdigt werden. Denn nicht jede Idee muss auch “the next big thing” werden.

Idealerweise arbeitet das Management lieber eine langfristige Produktvision(3–5 Jahre) aus und steuert weniger über einzelne Initiativen.

Und für alle, die wirklich Veränderung wagen wollen: Warum nicht eine Initiativen-Liste für die Management Themen einführen von der sich die Teams inklusive dem Produktmanager das nächste Thema nehmen, wenn sie das Gefühl haben, das aktuelle ausreichend bearbeitet zu haben. Klar muss es auch dafür Regeln geben.

Durch diese Veränderung vom Push- zum Pull-Prinzip verhindert man die Demotivation, die entsteht, wenn man Mitarbeiter bittet ihre aktuelle Arbeit stehen und liegen zu lassen um sich um ein neues Thema zu kümmern. Und man unterstreicht die Wertschätzung, die man für seine Mitarbeiter hat in dem man ihnen signalisiert, dass man ihnen zutraut durchaus im Sinne des Unternehmens zu denken.

Und als Manager in einer solchen Organisation ist man eher Coach als Vorgesetzter. Man begibt sich auf Augenhöhe und kann sich als die Aktivierungsenergie verstehen, die Teams ab und an brauchen um sich vom aktuellen Thema zu lösen um Neues beginnen zu können.

Ein Gewinn für alle und die Vorsorge dafür, dass der Lehrsatz der sozialistischen Leistungstätigkeit lügen gestraft wird: “Operative Hektik überbrückt geistige Windstille.”

In diesem Sinne: ein geruhsames, fokussiertes und erfolgreiches 4. Quartal!

Die 8 Regeln für totalen Stillstand zum Nachlesen

1. Die Unternehmensleitung und die Führungskräfte sollten sich entweder ganz aus der Veränderung raus halten oder versuchen, alles im Griff zu haben. Handeln sie immer in diesen beiden Extremen!
2. Diskussionen über Ziele und Inhalte möglicher Veränderungen sollten konsequent nur auf der informellen Ebene geführt werden. Starten sie Gerüchte und lassen sie diese durch die bestehenden Kommunikationskanäle laufen!
3. Möglichst viele Aktivitäten sollten gleichzeitig angezettelt werden. Vielfalt belebt das Chaos, die Unruhe oder auch die Orientierungslosigkeit. Überfordern sie die Organisation oder das Team mit immer neuen Vorschlägen und Umsetzungsaufgaben zur Veränderung.
4. Es sollte ein umfassender Wettbewerb einberufen werden. Jeder ist darauf hinzuweisen, dass nur der Einsatzbereiteste überlebt. Beschäftigen sie ihre Mitarbeiter mit sich selber und lassen sie zu, das sich Kollegen gegenseitig behindern.
5. Es sollte stets ausdauernd und unnachgiebig nach den zentralen Verursachern des Problems gesucht werden. Wer ist wirklich Schuld? Analysieren Sie bis ins Detail!
6. Es sollte auf keinen Fall öffentlich über den Sinn und Unsinn bestehender Regelungen diskutiert werden. Lassen Sie Ihre Regeln in Frieden! Bestehende Regeln erhalten den status quo.
7. Beschlüsse sollten auf der formellen Ebene möglichst schnell konsensfähig sein, um dann informell in Frage gestellt zu werden. Erreichen sie offiziell ein schnelles Commitment! Dann rudern sie inoffiziell wieder zurück bzw. bringen die Gegenargumente sehr deutlich zur Sprache.
8. Die Veränderungsgeschwindigkeit auf der Beschlussebene sollte stets größer sein als auf der Umsetzungsebene. Maximale Beschlussdynamik bei minimaler Umsetzungsdynamik.

 

Dieser Artikel wurde ursprünglich am 19. Oktober 2014 auf Medium.com veröffentlicht.