OKR und Product Management verknüpfen

Die Verbindung des agilen Zielemanagements mittels OKR (Objectives and Key Results) und Product Management Methoden ist ein naheliegender Gedanke. Weil eine OKR Eigenschaft Agilität ist, kann diese sehr einfach in die gesamte Organisation übertragen werden und damit auch außerhalb von IT-Teams. Das wiederum wirkt sich positiv auf die dortigen täglichen, agilen Prozesse aus.

Wo Argumente auf dem Papier sofort überzeugen, zeigt die Praxis jedoch oft schnell, dass die Alltagsverknüpfung von Methoden wie OKR (agile Ziele) und  Scrum oder anderen (agiles Product Management) oft nicht ganz einfach sind. Kein Handbuch beschreibt, wie OKR und Epics zusammen spielen, was OKR für die Product Roadmap bedeuten, welche Meetings zusammen passen oder wie gute OKR für eine Product Discovery aussehen. In der Zusammenarbeit mit Tim Herbig als Product Management Experten ist eine Zusammenführung entstanden, die genau diese Fragen des Alltags beantworten soll. 

Sonja Mewes und Tim Herbig, Experten für OKR und Product Management

Kleiner Ausblick:

Zwei Aspekte haben wir dabei als Erfolgsfaktoren identifiziert:

1) die bestmögliche Trennung der Warum-Ebene (Ziele) und der Was-Ebene (Aufgaben) und

2) das Bewusstsein über die Individualität der OKR und Product Management Prozesse selbst, die keine allgemeingültigen Verbindungen erlauben.

Wie diese zwei Ebenen bestmöglich im Alltag verbunden werden können findest du im folgenden Artikel. Nach einer Einleitung in die Grundlagen von OKR und Product Management stellen wir mit theoretischen und praktischen Beispielen mögliche Verknüpfungen vor.

Agile Ziele mit OKR - das Warum

OKR Definition

OKR ist ein Führungs-Tool, dass den Fokus für die ganze Organisation auf die Umsetzung der richtigen Dinge sicherstellt. 

Durch das quartalsweise Formulieren von Objectives (Zielen) und Key Results (Erfolgs-Messkriterien) wird der nächste Schritt als eine Art Mini-Vision für alle greifbar gemacht. OKR beschreiben so das Warum Dinge getan werden sollen. Sie gelten oft quartalsweise für die gesamte Organisation. Davon abgeleitet entstehen außerdem OKR für alle Bereiche und Teams, die den Anteil der jeweiligen Einheiten zur Erreichung des Organisations-OKR abbilden.

Objectives sind die qualitative Beschreibung der Ziele, die inspirierend, im Quartal und unabhängig vom jeweiligen Team erreichbar sind.

Key Results machen als wichtigen Bestandteil die Objectives messbar. Weil sie quantifizieren, wie die optimale Zielerreichung aussieht, schaffen sie Klarheit für alle Beteiligten. Das können zum Beispiel Messkriterien in Bezug auf Umsatz, Wachstum, Nutzer, Qualität oder Performance sein.

Durch die Art und Weise der Zieldefinition und des Monitorings werden unter anderem Transparenz, Synchronität, Agilität und Engagement in der Organisation gestärkt. Alle haben so eine gemeinsame Orientierung, die jedes Quartal neu justiert wird. Die Vorteile dieses Ansatzes im Vergleich zu individuellen Bonusvereinbarungen oder 3-Jahresplänen liegen schnell auf der Hand.

Eine ausführliche Beschreibung von OKR findest du in diesem Artikel

OKR Definition

OKR Definition

OKR Kaskade

OKR Kaskade

OKR Beispiel

Um die Bedeutung von OKRs für agile Produktteams zu verdeutlichen, schauen betrachten wir das Beispiel der SaaS-Analytics Firma Analytico an. Analytico möchte mit Software lernende Organisationen ermöglichen. So könnte ein OKR für das folgende Quartal aussehen:

  • Objective Q3: Neues Kundensegment “Online Marketers” gewinnen
  • >Key Result 1: 100.000 neue Online Marketer Kontakte
  • >Key Result 2: 50.000 € Umsatz mit Kunden aus diesem Segment
  • >Key Result 3: Durchschnittl. Kundenzufriedenheit im Segment von 30 auf 75% steigern
  •  

Nach der Formulierung folgt die Aufgabenplanung - das Was getan werden soll. In diesem Fall könnten Maßnahmen wie eine Online Marketing Kampagne oder ein Projekt zur Produktverbesserung einige von vielen Möglichkeiten sein, die Key Results zu erreichen.

OKR als Priorisierungsinstrument

Zwischen dem Beginn und dem Ende eines Quartals, an dem das Ziel erreicht werden soll, liegen allerdings viele Tage, E-Mails, Meetings, Arbeitspaketplanungen - also die vielen kleinen Entscheidungen des Arbeitsalltages. Sind hier die OKR nicht jedem Mitarbeiter präsent, können sie nicht als Entscheidungshilfe für den besten Weg zur Zielerreichung dienen.

Deswegen ist es ratsam, OKRs nicht nur quartalsweise zu Formulieren, in einem Dokument abzulegen und erst am Ende des Quartals zur Bewertung wieder hervorzuholen. Ganz im Gegenteil: OKRs müssen zum Leben erweckt und für jeden sichtbar in den Arbeitsalltag integriert werden. Nur wer seine OKRs kennt, kann auch seine Arbeit auf sie ausrichten. Sind OKRs zum Beispiel bei Entscheidungsprozessen in einem Teammeeting oder einer Sprintplanung sichtbar, können alle Aufgaben exakt nach den OKRs priorisiert werden.

Webinar zum Thema

Agile Product Management - das Was

Wirkung statt Features

Falls du noch gar nicht mit OKR arbeitest, aber noch Argumente suchst, damit ihr von einer reinen Feature-Factory hin zu wirksamer Produkterstellung kommst, schau doch gerne in dieses Video:

Product Management Übersicht

Um Product Management mit agilen Zielen zu vergleichen, beziehungsweise zu zusammenzuführen werfen wir zunächst noch einen kurzen Blick auf dessen Definition. Festzuhalten ist zunächst, dass es wie mit vielen modernen Themen in diesem Sinne keine einheitliche Definition gibt. Bekannte Methoden für die agile Entwicklung von Produkten wie Scrum sind zwar sehr detailliert ausformuliert, beinhalten jedoch hauptsächlich den konkreten Umsetzungsaspekt und weniger die Vorstufen der Planung.

In unserem Falle wollen wir den Product Management Prozess in 3 Schritten beschreiben. Der Vergleichbarkeit halber benutzen wir hier die Englischen Begriffe:

  • 1
    Product Planning - Langfristiger Ausblick mit Themen-basierten Roadmaps
  • 2
    Product Discovery - Identifikation möglicher Lösungen für Kundenprobleme
  • 3
    Product Delivery - Umsetzung der priorisierten Produktlösung in iterativen Schritten

PRODUCT Planning

Typischerweise ist in Organisationen eine gewisse Vorausplanung der Produktentwicklung getrieben durch Stakeholder wie große Kunden oder Investoren notwendig. Deshalb gibt es oft sogenannte Jahres-Roadmaps, die oftmals termingetrieben bestimmte Themenblöcke der Produktentwicklungen für die Zukunft oder eben mindestens das nächste Jahr im Voraus skizzieren. In Zeiten von einfacher Vorhersage-Möglichkeit und nach Wasserfall-Methodik organisierten Projekten war dies ein passendes Instrument.

In einem agilen Umfeld jedoch soll jederzeit auf neue Erkenntnisse von Kundenbedürfnissen oder anderen Einflüssen aus der Umfeld reagiert werden können. Deswegen ist es auch im Planning notwendig, flexiblere Formen von Roadmaps zu benutzen. Der Unterschied zur klassischen, zeitbasierten Roadmap liegt in der Detailtiefe. Je näher ein Thema auf der Roadmap rückt, je detaillierter ist dieses bereits bekannt und beschrieben. Je weiter weg ein Thema ist, je unkonkreter ist es beschrieben und erfährt nur eine zeitliche Einordnung in die groben Kategorien "bald" und "später".

Agile Product Management Roadmap Vergleich

Product Roadmap Vergleich

Eine Herleitung dieses Ansatzes findest du zum Beispiel im Video von C. Todd Lombardo in seinem Talk im Rahmen der Mind the Product San Francisco 2018:

PRODUCT Discovery

Mit einer Themen-basierten Roadmap wissen alle grob, eben welche Themen in der Zukunft bearbeiten werden. Konkretisiert werden diese dann in der Discovery-Phase. Hier findest du heraus, was entwickelt werden soll, oder auch welche Lösungsansätze für Kundenprobleme möglich sein können.

Eine Discovery enthält mehrer iterative Schritte, die auch hier wieder in jedem Produktumfeld anders gelebt werden. Typischerweise sind Auftragsklärung, Erforschung der Nutzerprobleme, Ideenfindung, Kreation von Prototypen, Validierung und weiterer Feinschliff zum Beispiel mittels User Story Mapping Teilschritte. Das Ergebnis ist ein mit echten Kundenbedürfnissen abgeglichenes Produktkonzept in Form eines Epics, dass entweder verworfen wird oder aber in der nächsten Phase (Delivery) in ein echtes Produkt umgesetzt wird.

Agile Product Management Discovery Zyklus

Product Management Discovery Zyklus 

PRODUCT Delivery

Die Umsetzungsphase nimmt je nach Produkt und Team oft die meisten Ressourcen in Anspruch. Jetzt geht es um echte Detailarbeit und das Erschaffen eines realen Produktes. Ein gesamtes Team von Product Managern, Designern und Entwicklern arbeitet bei der Anwendung von Methoden wie Scrum oder Kanban in kurzen Sprints an der Produkterstellung.

Ein Sprint dauert typischerweise zwei Wochen. In dieser Zeit werden auf der einen Seite die für diese Zeit geplanten Aufgaben in Form von User Stories und Tickets umgesetzt werden. Gleichzeitig wird der nächste Sprint durch das Beschreiben von Funktionalitäten und Design vorbereitet.

Am Ende des Sprints werden in der Sprint-Review die erstellten Ergebnisse präsentiert. In der anschließenden Retro reflektiert das Team die grundsätzliche Zusammenarbeit und mögliche Potentiale gemeinsam. 

Das kann dann zum Beispiel so aussehen:

Agile Product Management Delivery Zyklus

Product Management Delivery Zyklus

Inhaltlich wird bei agilen Methoden des Product Managements das “Was” organisiert und damit die konkreten Aufgabenblöcke für die Produktweiterentwicklung organisiert.

Ohne eine Verbindung der einzelnen Aufgaben zu den übergeordneten Firmenzielen kann schnell der Fokus verlorengehen. Produktentwicklung wird dann schnell zum Selbstzweck, gerne auch #Featurefactory genannt. 

Verbindung von OKR und Product Management grundsätzlich

Zusammengefasst kann man die beiden ausführlicher beschriebenen Methoden wie folgt beschreiben: 

Die Unternehmens-Vision (oder -Strategie) und davon abgeleitet die Produkt-Vision sind das langfristige “Warum”. Warum existiert mein Unternehmen? Wofür stehe ich? Was möchte ich mit meinem Produkt langfristig erreichen? Davon lassen sich die quartalsweisen OKR ableiten, die eine Art Mini-Warum darstellen. 

Demgegenüber befindet sich das “Was”, das Product Management mit seinen konkreten Themes, Epics, User Stories und letztendlich Tasks. Themes und Epics umfassen dabei oft einen mittelfristigen Zeithorizont. Sie beschreiben meist größere Themenblöcke oder Features, die einen längeren Entwicklungszeitraum benötigen. User Stories und Tasks hingegen haben kürzere Zeiteinheiten, weil sie innerhalb der zweiwöchigen Sprint bearbeitet werden sollen.

OKR Agile Product Management Vergleich Definitionen

OKR und Product Management Verbindung: Einordnung in Warum und Was

Beispiel Analytico

So spielen zum Beispiel OKR und Product Management für die Softwarefirma Analytico zusammen:

Das formulierte Objective "Neues Kundensegment “Online Marketers gewinnen" gibt Orientierung für den folgenden Product Management Prozess.

Die Discovery-Phase hat zum Ziel, konkrete Kundenprobleme und mögliche Lösungen für diese zu identifizieren. Das Ergebnis, zum Beispiel das Feature "Kostenloser Lead Magnet Test", wird als Epic beschrieben.

In der Delivery-Phase bespricht und bearbeitet das Product Team dann gemeinsam in Sprints konkrete User Stories, wie die Erstellung einer Facebook Schnittstelle. 

Verbindung der Artefakte

Zeitliche Verbindung

OKR und Product Management sind besonders eng verbunden bei den zeitlich mittelfristigen Artefakten des Produktprozesses. Themes und Epics sollten deswegen auf jeden Fall mit den aktuellen OKR synchronisiert werden.

Gibt es bereits vorhandene Themes/ Epics im Themenpool, priorisiert das OKR, welche dieser vorhandenen Artefakte aus der Roadmap als nächstes bearbeitet werden sollten. Gibt es noch keine Themes/ Epics, die auf die Erfüllung des aktuellen Quartals-OKR einzahlen, gibt das OKR die Richtung für eine neue Discovery-Phase vor. Damit sind indirekt auch User Stories und Tickets mit den jeweils aktuellen OKR synchronisiert.

Wird ein Epic dann in Form von User Stories / Tickets in einem Sprints bearbeitet, sollten abgeschlossene User Stories in erheblichem Maße die Key Result Fortschrittsmessung voranbringen. User Stories, die keine Wirkung auf diesen Kriterien erzielen sind entsprechend wirkungslos und erfordern eine Überarbeitung oder das Andenken ganz anderer Wege. 

OKR Agile Product Management Verbindung Epics

Verbindung OKR und Epics

Verbindung Key Results und User Stories

Prozessuale Verbindung

OKR werden üblicherweise in einer Tabelle oder in einem spezifischen OKR Tool festgehalten und gemonitored.

Sie können mit Epics und User Stories oder Tickets verbunden werden, in dem man an jedes dieser Artefakte ein (Pflicht-)Feld einfügt. In diesem Feld wird dann das OKR, auf das das Artefakt einzahlt mit Text oder als Nummer genannt.

Es kann auch immer Tickets geben, die keinem konkreten OKR zugeordnet werden können, da die dringend notwendige Aufgabe vielleicht zu Beginn des Quartals noch nicht bekannt war oder einfach eine gewisse Notwendigkeit von Maintenance-Aufgaben immer besteht. Dies ist überhaupt kein Problem, sollte aber trotzdem transparent gemacht werden und vor allem bei der OKR Definition durch eine Art geblockte Ressourcen für Maintenance berücksichtigt werden. Sind zum Beispiel immer 20% der Ressourcen dafür eingeplant, kann auch nur mit 80% der Ressourcen für die OKR Erreichung geplant werden.

Das Management von Zielen und Aufgaben in einem Tool zu verbinden ist häufig nicht empfehlenswert. Es gibt zwar beispielsweise OKR-Plugins für Jira, aber meist arbeitet nicht die gesamte Organisation mit nur einem Tool als Aufgabenmanagement.

Verbindungen der Routinen

Über die Verbindung von OKR und Epics und deren abgeleiteter User Stories ist bereits wichtige Grundlage für das erfolgreiche Zusammenwirken von Zielen und Aufgaben gelegt.

Die Erreichung der mit OKR quartalsweise formulierten Ziele kann vor allem dann erfolgreich werden, wenn OKR tatsächlich in alle täglichen und wöchentlichen Entscheidungsprozesse der Produktentwicklung integriert werden. Das heißt in jedem Stand-Up Meeting, in jeder Review, in jedem Planning, etc. sollten sie das sichtbare Priorisierungstool für Entscheidungen sein.

Vor dem Sprint:

  • Backlog-Refinement: Durch die Hinzunahme der OKRs als Priorisierungswerkzeug kann das Team gemeinsam auswählen (da jetzt die Entscheidungsgrundlage klar ist), statt diese Priorisierung alleine dem Product Owner zu überlassen. Dieser bringt zwar weiterhin die Perspektive zu Nutzer- und Geschäftsbedürfnissen mit ein und das Team die Perspektive zur technischen Umsetzbarkeit. Durch die Möglichkeit der gemeinsamen, sachlich am OKR orientierten Entscheidung ergibt sich die Möglichkeit, auf einfache Weise das Commitment zum Ziel und zur Arbeit und auch den Fokus im gesamten Team zu unterstützen.
  • angle-right
    Feedback & Estimation: An dieser Stelle ergeben sich keine direkten Verbindungen mit OKR. In der finalen Auswahl der Tickets für den Sprint sollte jedoch neben technischen Abhängigkeiten immer auch das Potential der einzelnen Tickets in Bezug auf die Key Result Erreichung eine Rolle spielen. 

Im Sprint:

  • Sprint-Planning (zweiwöchentlich) und OKR Check-In (zweiwöchentlich): Das regelmäßig OKR Check-In und das Sprint-Planning können in Product Teams zusammengeführt werden. Begonnen wird mit dem Blick auf den Status Quo der Key Results und der Überlegung, welche nächsten großen Pakete für die Erreichung der Key Results notwendig sind. Im Planning wird so OKR als Priorisierungswerkzeug benutzt. Analog zum Backlog-Refinement wählt das Team gemeinsam aus, was die nächsten wichtigen Schritte zur Team-OKR Ereichung sind. Im Gegensatz zur alleinigen Entscheidung durch den Product Owners, kann auch hier wieder hohes Commitment zum Ziel und zur Arbeit und auch der Fokus im gesamten Team ermöglicht werden.
  • angle-right
    Daily Stand-Up: Durch die Planung des Sprints mittels OKR Priorisierung ist hier keine zusätzliche Verknüpfung notwendig. Die OKR könnten aber grundsätzlich an Artefakten wie dem Scrumboard sichtbar gemacht werden, um die OKR jederzeit zu erinnern und erledigte Aufgaben und deren Anteil am Fortschritt der Zielerreichung sichtbar zu machen.
  • Sprint-Review und OKR Check-In (zweiwöchentlich): Ursprünglich war eine Review dafür angedacht, dass der oder die Product Owner nach einer erfolgreichen Vorstellung der im Sprint erzielten Ergebnisse (Output) diese abnimmt. Heute wird die Review in vielen Organisationen eher dazu verwendet, Stakeholdern außerhalb des Teams Ergebnisse zu präsentieren und gleichzeitig Feedback dazu einzuholen. Werden die Ergebnisse zusätzlich in Verbindung mit ihrem Einfluss auf das Ziel vorgestellt, wird außerdem die Wirksamkeit (Outcome) sichtbar gemacht. Oft sind messbare Wirkungen nicht im selben Sprint abbildbar. Deswegen eignet es sich neben aktuellen Ergebnissen auch ältere Ergebnisse nochmals mit dann bekannten Messergebnissen in die Review zu integrieren.
  • Sprint-Retro (zweiwöchentlich) und OKR Review/Retro (quartalsweise): Da sich die Retrospektive explizit auf die Zusammenarbeit des Teams im abgelaufenen Sprint bezieht, gibt es an dieser Stelle keine explizite OKR Verbindung. Ausnahme: ein Team-OKR bezieht explizit sich auf die Veränderung eben dieser Zusammenarbeit. Die OKR Retro findet dann zu Quartalsende organisationsweit statt. Möglicherweise kann dieser Termin dann in vorhandene Retro-Termine der Teams integriert werden. Die OKR Retro findet dann zu Quartalsende organisationsweit statt. Möglicherweise kann dieser Termin dann in vorhandene Retro-Termine der Teams integriert werden.

Verbindungen der Zyklen

OKR Zyklus versus Roadmap

Wenn in Organisationen mit einer statischen Planung der Roadmap bis zu einem Jahr im Voraus gearbeitet wird, ist dieser Rhythmus nicht einfach mit quartalsweisen Zielen zu verbinden. Auf der einen Seite sollen schnelle Zielanpassungen Flexibilität und Reaktion auf notwendige Marktveränderungen ermöglichen. Auf der anderen Seite ist die Produktplanung bereits lange im Voraus festgelegt. Es besteht die Gefahr, dass Ziele nicht vom Warum, also der Vision abgeleitet werden, sondern vom was, einer reinen Ergebnisperspektive ohne Wirksamkeit.

Da eine gewisse Vorausplanung der Roadmap in vielen Organisation notwendig ist, um zum Beispiel Stakeholder oder Kunden einen Eindruck über die Weiterentwicklung zu geben, ist eine pragmatische Synchronisation mit OKR notwendig. Dies ist beispielsweise möglich, wenn neben Quartals- auch Jahres-OKR formuliert werden.

Dieses oder diese OKR geben dann eine inhaltliche Orientierung, was der nächste große Schritt zur Erreichung der Vision (Warum tun wir etwas) im kommenden Jahr darstellen soll. Mit diesem Wissen kann die Roadmap (Was tun wir) mit den Zielen der Organisation abgeglichen werden.

Wird außerdem die Roadmap von einer zeitbasierten Planung auf einen themenbasierte Planung mit nur groben Zeitrastern erarbeitet, passen Jahres-OKR und Roadmap und damit OKR und Product Management insgesamt gut zusammen.

OKR Zyklus versus Sprint Zyklus

Ähnlich asynchron ist das quartalsweise Formulieren der Ziele und das zwei-wöchentliche bearbeiten der Aufgaben in Sprints. Prinzipiell lassen sich leicht sechs Sprints einem Quartal zuordnen. Einzelne Phasen von Discovery oder Delivery würden jedoch nicht natürlicherweise immer zu einem Quartal gehören. 

In der Delivery-Phase ist es bei der Arbeit mit OKR jedoch möglich und notwendig, die Sprints entsprechend zu planen, dass sie mit dem OKR Zyklus gleich getacktet sind. Das bedeutet zwar gelegentlich eine unnatürliche Auftrennen von Themen, unterstützt so aber einen stimmigen Gesamtprozess in der Organisation.

Weniger einfach gestaltet sich die Synchronisierung des öfteren für Discovery-Phasen. Je nachdem wie lange sie dauern, kann es notwendig sein, dass sie beispielsweise inhaltlich schon Arbeit für das nächste Quartal oder Halbjahr vorbereiten, ohne die entsprechenden OKR dazu zu kennen. An dieser Stelle gibt das Jahres-OKR oder ein anderes höheres Ziel wie die Strategie oder Vision selbst die Orientierung. Um Discovery-Phasen von Beginn an in den richtigen Kontext einzubetten, gibt es neben OKR eine Vielzahl weiterer Alignment-Tools.

Die versprochenen Beispiele für OKR für Delivery-Phasen folgend an dieser Stelle in Kürze

OKR Agile Product Management Verbindung Sprint

OKR und Product Management Verbindung: Roadmap und Sprints

Die versprochenen Beispiele für OKR für Delivery-Phasen folgend an dieser Stelle in Kürze. Hast du selbst gute Beispiele, die du mit anderen teilen möchtest? Dann schreibe uns an sonja@beautifulfuture.de

Back To Top