OKRs (Objectives and Key Results)

Ein Objective ist eine kurze, qualitative Absichtserklärung — einprägsam, richtungsweisend und leicht unbequem, sich darauf festzulegen. „Das Standardtool für das Onboarding neuer Produktteams werden“ ist ein Objective. Es ist für sich genommen nicht messbar, und das soll es auch nicht sein.

Jedes Objective trägt drei bis fünf Key Results: spezifische, numerische Ergebnisse, die belegen, dass das Objective erreicht wurde. Gute Key Results haben die Form „Kennzahl X von A auf B bis Datum bewegen“ — etwa „Aktivierungsrate von 34 % auf 50 % anheben“ oder „mediane Time-to-First-Value von 9 auf 3 Tage senken“. Wenn man darüber streiten kann, ob ein Key Result erreicht wurde, ist es falsch formuliert. Die Disziplin besteht darin, dass das Objective inspirierend und die Key Results unzweideutig sind.

Die meisten Teams führen OKRs in einem Quartalsrhythmus, oft eingebettet unter jährlichen Unternehmens-OKRs, mit einem leichtgewichtigen wöchentlichen oder zweiwöchentlichen Check-in zur Aktualisierung der Zuversicht. Am Ende des Quartals wird jedes Key Result bewertet, meist auf einer Skala von 0,0 bis 1,0.

Eine weit verbreitete Konvention — popularisiert durch Googles Adaption von Andy Groves ursprünglicher Intel-Praxis — besagt, dass ein Durchschnitt von 0,7 das Ziel ist, nicht 1,0. Die Logik: Wer durchgängig 1,0 erreicht, hat seine Key Results zu vorsichtig gesetzt. „Stretch“- oder ambitionierte OKRs werden bewusst so gesetzt, dass 60–70 % ein starkes Ergebnis sind. Das funktioniert nur, wenn die Bewertung von Leistungsbeurteilungen entkoppelt bleibt; sobald OKRs direkt in die Vergütung einfließen, setzen Menschen sichere Ziele, und der Stretch verschwindet.

Der häufigste Fehler ist, Key Results als To-do-Liste von Outputs statt als Outcomes zu formulieren. „Den neuen Onboarding-Flow ausliefern“ ist ein Output — man kann ihn ausliefern und trotzdem keine Kennzahl bewegen. „Die Woche-1-Retention auf 45 % erhöhen“ ist ein Outcome. Wenn Key Results nur eine verkappte Roadmap sind, werden OKRs zum Theater: Das Team markiert alles als erledigt, nichts ändert sich, und das Vertrauen in den Rahmen bröckelt.

Weitere wiederkehrende Fehlerquellen: zu viele OKRs (mehr als drei Objectives pro Team zersplittert den Fokus); sie starr top-down zu kaskadieren, sodass sie zu Zuweisungen statt Selbstverpflichtungen werden; sie zu setzen und bis zum Bewertungstag nie wieder anzuschauen; und Bewertungen an Boni zu koppeln, was die Ehrlichkeit tötet, die ambitionierte Ziele brauchen. OKRs sind ein Fokus- und Alignment-Werkzeug, kein Projekt-Tracker — es geht darum, zu verändern, was passiert, nicht zu protokollieren, was gebaut wurde.

Der schwierigste Teil von OKRs in der Praxis ist, Key Results mit einer lebenden Zahl verbunden zu halten statt mit einem Wert, den jemand jeden Freitag von Hand in eine Folie einträgt. Wenn die Kennzahl in einer Tabelle lebt, driften Check-ins ab und die Bewertung wird zur Debatte.

Ein Betriebssystem fürs Produkt hilft hier, indem es die zugrunde liegenden Signale auf einer gemeinsamen Basis hält: AIOProductOS verbindet Produkt-Analytics, Umsatz (MRR/ARR) und Kundenverhalten in einem Datensatz, und sein OKR-Modul kann ein Key Result gegen eine lebende Kennzahl auf der Basis verfolgen — sodass ein Ziel wie „Aktivierungsrate anheben“ oder „Expansionsumsatz steigern“ aus denselben Daten liest, mit denen der Rest des Teams arbeitet, statt aus einer statischen Momentaufnahme. Das hält das Gespräch darauf fokussiert, ob sich der Outcome bewegt — genau darum geht es bei diesem Rahmen.