Foto von Daniel Novta auf flickr unter CC-Lizenz.

Management vs. Produkt. Der ewige Kampf.

Mikromanagement ist der Horror eines jeden Produktmanagers. Produkt braucht Freiraum, um Entscheidungen selbständig treffen und lernen zu können. Aber leider sind Chefs, die von der Roadmap bis zur Button-Farbe alles im Alleingang festlegen, keine Seltenheit. Was schnell wie ein individuelles Problem zwischen Produktmanager und Chef aussieht, ist in Wirklichkeit nur das Symptom eines weit verbreiteten strukturellen Bruchs zwischen Management und Produkt.

Hintergrund und Lösung zu diesem Konflikt beschreibt Stephen Bungay in seinem Buch „The Art of Action“: Nach Bungay wird der Handlungsraum von Unternehmen von wechselnden und komplexen Umweltbedingungen bestimmt, die im Zusammenspiel mit unterschiedlichen persönlichen Interessen, Emotionen und auch Stress zu drei grundlegenden „Gaps“ führen:

  1. Knowledge Gap: The difference between what we would like to know and what we actually know.
  2. Alignment Gap: The difference between what we want people to do and what they actually do.
  3. Effects Gap: The difference between what we expect our actions to achieve and what they actually achieve.

Stephen beschreibt also in etwa dieselben Rahmenbedingungen, die zur Entwicklung des agilen Produktmanagements geführt haben, nur aus Sicht des allgemeinen Managements. Das Grundproblem besteht darin, dass das Methodenset für den Umgang mit den drei Gaps im Management im Vergleich zum agilen Produktmanagement deutlich unterentwickelt ist. Es gibt zwar immer mal wieder zaghafte Versuche, das zu ändern, aber es dominieren weiterhin die Standard-Managementlehren, die sich in Bezug auf die drei Gaps wie folgt äußern:

  1. Knowledge Gap: More detailed information
  2. Alignment Gap: More detailed instructions
  3. Effects Gap: More detailed control

Hypothesen-getriebenes, agiles Lernen hat in dieser Management-Welt keinen Platz. Stattdessen wird von Produkt erwartet, dass jedes Projekt von vornherein anhand von Aufwand und Nutzen klar bewertet werden kann. Jede negative Abweichung vom Plan bezüglich Zeit, Kosten oder Qualität / Outcome bedeutet ein Versagen von Produkt, das durch noch mehr Informationen und noch detailliertere Ansagen und Kontrolle kompensiert werden muss. Leider sind negative Abweichungen in diesem Setup deutlich wahrscheinlicher als positive, so dass sich schnell eine Abwärtsspirale entwickelt, die ohne aktives Eingreifen automatisch eskaliert.

Im fortgeschrittenen Stadium sehen die Symptome in etwa so aus: Das Management beschwert sich über mangelnde Planbarkeit, falschen Output und generell zu wenig Outcome. Das agile Prinzip wird als mangelnder Planungswille und als Ausrede für fehlende Kompetenz auf Seiten des Produktmanagements bewertet. Produkt wiederum beschwert sich über fehlenden (strategischen) Plan, Mikromanagement und zunehmend schwindendes Vertrauen auf Seiten des Managements und verzweifelt letztlich an dem Bruch zwischen der Notwendigkeit, nach oben fixe Planungen abgeben zu müssen, und dem eigenen Anspruch, diesen agil umzusetzen. Im Endstadium dieser gegenseitigen Eskalation gewinnt die höhere Hierarchiestufe. Das Produktmanagement verkommt zur Umsetzungsmaschine für Fixed-Scope-Fixed-Quality-Fixed-Timing-Ansagen aus dem Management. Jegliche Agilität ist tot.

Was ist nun die Lösung? Stephen Bungay definiert drei Grundsätze für das Management:

  1. Limit direction to defining and communicating the intent.
  2. Allow each level to define how they will achieve the intent of the next level up.
  3. Give individuals freedom to adjust their actions in line with intent.

Mit anderen Worten: Die Aufgabe des Managements besteht darin, ein Alignment zum WARUM und WAS sicherzustellen. Produkt hat darauf aufbauend die Verantwortung für die konkrete Ausführung, das heißt bezüglich des WIE. Wichtig ist dabei, dass die Autonomie des Teams nur über Alignment herzustellen ist, wofür beide Seiten gleichermaßen verantwortlich sind. Das immer noch häufig anzutreffende Ideal des Produktmanagers als Mini-CEO, der lediglich über KPIs gesteuert wird, ist mit dem Ansatz genauso wenig vereinbar wie Command/Control von Seiten des Managements. Alignment erfordert Anstrengung von Management und Produktmanagement.

Das notwendige Alignment kann nur über intensive Diskussionen (bei Stephen „Briefing and Backbriefing“) hergestellt werden. Das erfordert einige Übung, denn die iterative Klärung des WARUM und des WAS zwischen Management, Produkt und vielfach noch anderen Stakeholdern ist viel anstrengender als, wie üblich, auf Basis einiger Powerpointfolien gleich mit den Lösungen (dem WIE) zu starten.

Um die Diskussion zwischen Management und Produkt zu vereinfachen, hat Stephen Bungay mit dem „Strategy Briefing“ ein einfaches Framework entwickelt. Im Kern ist es eine Checkliste, die sicherstellt, dass alle notwendigen Aspekte mit einer einheitlichen Sprache besprochen und geklärt werden.

Ein Strategy Briefing besteht aus 5 Elementen:

  1. Der „Context“ besteht aus Fakten und Annahmen. Er beschreibt alle notwendigen Hintergrundinformationen, um das Projekt im Unternehmenskontext einordnen zu können, und begründet, warum das Projekt genau jetzt realisiert werden sollte.
  2. „My Intent“ beschriebt das Ziel des unmittelbaren Projektteams, die Messgröße, um das Ziel (näherungsweise) zu messen, und auch ein konkretes Ziel für die Messgröße.
  3. Der „Higher Intent“ ist die Verbindung zwischen „My Intent“ und den übergeordneten Zielen. Der „Higher Intent“ sorgt also dafür, dass unternehmensweit in eine strategische Richtung gearbeitet wird. Abhängig von der Anzahl an Hierarchiestufen in einem Unternehmen, kann es mehrere kaskadierende Stufen von „Higher Intent“ und „My Intent“ geben, ganz ähnlich zum Prinzip der Objectives and Key Results (OKR).
  4. Die „Key Implied Tasks“ umfassen die Aufgaben und die dafür notwendigen Personen, Zeit und Euros, um den Intent zu verwirklichen. Hiermit ist kein MS-Projekt-Plan gemeint, sondern lediglich ein genereller Check, ob die Erwartungen aus dem Intent grob mit den vorhandenen Mitteln mit einer vernünftigen Wahrscheinlichkeit erreicht werden können.
  5. Die „Boundaries“ schließlich dienen dazu, weitere notwendige Leitplanken für das Projekt zu definieren: Welche Nebenbedingungen müssen eingehalten werden? Was darf das Team alleine entscheiden und was nicht? Was ist explizit nicht im Projektscope enthalten? Welche anderen Projekte / Aufgaben muss das Team parallel noch erfüllen?

Das „Strategy Briefing“ umfasst also nichts Anderes als die ganz wesentlichen Punkte, die vor jedem Projekt geklärt werden müssen, um agiles Produktmanagement zu ermöglichen. Das folgende Bild zeigt ein Beispiel:

Hier noch einige Tipps für die Umsetzung:

  • Ein Strategy Briefing ist kein Formular zum Ausfüllen, es ist ein Hilfsmittel, um Diskussion und Verständnis zu fördern.
  • Management, Produkt und alle andere Stakeholder müssen direkt miteinander sprechen. Der Austausch von schriftlichen Briefings ersetzt keine Diskussion.
  • Bei der Erstellung des Briefings hilft eine Mischung aus Einzel- und Teamarbeit, um alle Perspektiven und Unklarheiten aufdecken zu können.
  • Post-its erlauben ein schnelleres Iterieren.
  • Ein Moderator kann helfen, die Diskussion effizient zu gestalten und alle Beteiligten zu Wort kommen zu lassen.
  • Ein Briefing lebt und sollte, wenn notwendig, im Projektverlauf angepasst werden.

Wer tiefer in das Thema einsteigen will: XING setzt das „Strategy Briefing“ seit einiger Zeit erfolgreich unter dem Namen „Auftragsklärung“ ein. Im Rahmen der MTP Engage in Hamburg zeigen Marc Kadish (Product Director @XING) und ich in einem Workshop am 27. April 2017, wie „Strategy Briefing“ bzw. „Auftragsklärung“ in der Praxis funktioniert.

Über Christian Becker (Gastautor)

Christian ist Gründer und Geschäftsführer von productable und unterstützt Teams dabei, aus Ideen erfolgreiche Produkte und innovative Geschäftsmodelle zu entwickeln. Zuvor hat Christian das Produktmanagement und die User Experience Abteilung bei mobile.de geleitet.

4 Kommentare

  1. Christian L.

    Hi Christian, super spannender Artikel, danke dafür! Eine Kleinigkeit ist mir jedoch nicht ganz klar: wieso sind „People&Time“ bei den Key Tasks gelistet und nicht bei den Boundaries?
    Die Tasks und die Ressourcen in diesem Stadium schon sehr fix zu machen erscheint mir sehr starr, dann muss man ja schon sehr genau verstehen, wie die Tasks umgesetzt werden sollen und wen genau man dafür braucht – quasi müssen dann ja alle Stories schon geschrieben sein.
    Wäre es nicht besser, wenn man als Boundary definiert, dass man maximal X FTEs und Y Euros einplant?

  2. Christian Becker

    Hallo Christian, bei „People & Time“ geht es um einen ganz grundsätzlichen Check, ob der Intent auch erreichbar ist. Ich kenne genug Projekte, wo der Anspruch überhaupt nicht mit der Ausstattung erreichbar ist (wobei ein solcher Stretch auch überhaupt erst die sehr guten Lösungen entstehen lassen kann). Du kannst es von zwei Seiten betrachten: Entweder der Intent ist fix und Du überlegst, welche Leute und wieviel Zeit Du dafür brauchst, dann passt es zu den Tasks. Oder Leute und Zeit sind fix und Du musst schauen, welches Anspruchsniveau Du damit hinbekommst, dann kannst Du es zu den Boundaries packen. Generell gilt bei dem Framework: Jedes Team braucht eine einheitliche Sprache, damit es funktioniert. Im Zweifel passt das Framework an, genau wie XING es für sich gemacht hat.

  3. Frank Feichtinger

    Das Format der Auftragsklärung hat für den PM noch einen Vorteil: es erzwingt die für das Allignment der vielzähligen Management-Stakeholdern erforderliche Diskussion. Ansonsten bekommt man vom COO, CSO, CMO und wie sie alle heissen mehrere und abweichende Aufträge&Erwartungen

Schreibe einen Kommentar

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