Was ist der On Product Index?

Der On Product Index ist eine Metrik des Evidenzbasierten Managements und gehört zur Key Value Area Ability to Innovate. Mit dieser Kennzahl kannst Du messen, wie gut es Deiner Organisation gelingt, neuen Nutzen und Wert für ihre Kunden zu stiften.

Laut EBM Guide ist der On Product Index „The percentage of time teams spend working on product and value.“

Legst Du beispielsweise 7,5h pro Arbeitstag zugrunde, die Mitglieder Deines Teams arbeiten jedoch nur 2,5h davon wirklich am Produkt, beträgt der On Product Index 33 %.

Mit dem On Product Index machst Du also sichtbar, wohin die verfügbare Zeit eines Teams eigentlich fließt. (Erfahrungsgemäß sind viele Teams mit ganz vielen Dingen beschäftigt, nur nicht mit der Arbeit an ihrem eigenen Produkt.)

Bevor Ihr in Eurer Organisation den On Product Index nutzt, solltet Ihr Euch gemeinsam darüber klar werden, was für Euch „Arbeit am Produkt“ überhaupt bedeutet.

Viele Manager setzen das gerne mit der Zeit gleich, in der „Code geschrieben“ wird. Verwendet Ihr jedoch das Scrum Framework, dann ist auch das gemeinsame Backlog Refinement und sogar die Scrum Events Arbeit am Produkt. Denn all das sind zwar keine Tätigkeiten, die direkten Wert stiften, jedoch notwendig sind, um Euer Produkt insgesamt besser zu machen.

Wie alles im Leben hat auch der On Product Index seine Vor- und Nachteile.

Der größte Vorteil des On Product Index besteht für Euch darin, eine Metrik zu besitzen, mit der Ihr Eure Innovationsfähigkeit messen könnt. So könnt Ihr ermitteln, ob Veränderungen in Eurer Organisation wirklich den gewünschten Effekt erzielen. Gleichzeitig eignet sich der On Product Index auch hervorragend als Key Result, falls Ihr OKR verwendet.

Wenn Euer Objective beispielsweise lautet:

„Die Innovationsfähigkeit unseres Produktteams verbessern“

Dann könnte dies ein sehr geeignetes Key Result sein, um die Erreichung des Objectives messbar zu machen:

„Den On Product Index von 33 auf 50 Prozent steigern.“

Der größte Nachteil am On Product Index ist der Aufwand, den jeder einzelne betreiben muss, wenn diese Metrik wirklich aussagekräftig sein soll. Denn es muss ja jeder Mitarbeiter täglich festhalten, wohin seine Arbeitszeit fließt. Teams, die mit digitalen Ticketsystemen arbeiten, haben es da noch am leichtesten, weil es für viele dieser Tools Time-Tracking-Funktionen gibt. In Teams, die das nicht haben, gerät der On Product Index schnell zu einem groben Schätzwert.

Ein weiterer Nachteil entsteht, wenn diese Metrik falsch verstanden wird. Misst Deine Organisation mit dem On Product Index beispielsweise „Zeit, die beim Kunden abrechenbar ist“, gerät das Ganze leicht aus den Fugen.

Natürlich ist es wünschenswert, möglichst produktiv zu arbeiten. Aber wenn der Blick nur auf abrechenbarer Zeit liegt, fallen andere Tätigkeiten schnell aus dem Blick. Viele Mitarbeiter werden damit beginnen, keine Produktpflege mehr zu betreiben, kein Code Refactoring durchzuführen und sich keine Gedanken über Software-Architektur mehr zu machen.

Sei Dir also darüber bewusst, was Du messen möchtest, und welche Folgen es haben wird!

Der On Product Index wird durch viele Faktoren beeinflusst und je nach Organisation können sie natürlich sehr unterschiedlich sein. Allerdings existieren drei Faktoren, die erfahrungsgemäß immer wieder auftauchen, weshalb ich sie hier kurz ansprechen möchte.

Moderne Großraumbüros bringen viele Vorteile mit sich. Sie sorgen jedoch auch für sehr viele Unterbrechungen bei der täglichen Arbeit. Mit einer Fokuszeit kann es Deinem Team gelingen, Zeiträume zu gestalten, in denen Störungen so gut wie möglich unterbunden werden. Anrufe, Termine oder Sonderaufgaben sind in der Fokuszeit verboten, damit Dein gesamtes Team konzentriert an seinem Sprint arbeiten kann. Fokuszeit ist daher ein guter erster Schritt in die richtige Richtung, um Ruhe in die eigene Arbeit zu bringen und den On Product Index zu erhöhen.

In vielen Organisationen entstehen mit der Zeit Experten zu allen erdenklichen Themen. Meistens liegt das daran, dass Manager ihnen immer wieder die gleichen Aufgaben zuweisen, weil sie diese effizient umgesetzt haben möchten. Langfristig entstehen dadurch jedoch echte Wissensinseln. (Weil sich niemand anderes je damit beschäftigen musste bzw. durfte.) Solange dieser Experte noch im Team ist, stellt das oft kein großes Problem dar.

Das Problem entsteht dann, wenn der Experte innerhalb des Unternehmens in ein anderes Team wechselt. Die meisten Unternehmen versäumen es dann, die im Team entstandene Wissenslücke zu füllen, weil der Experte ja noch „irgendwie da“ ist. Sobald dann eine dieser besagten Spezialaufgaben ansteht, wird der Experte aus seinem neuen Team herausgezogen, um diese Aufgabe zu erledigen.

Dieses Problem lässt sich natürlich nur langfristig auflösen. Wenn Ihr in Eurem Team ein Mitglied habt, das Expertenwissen besitzt, das für sein vorheriges Team relevant ist, solltet Ihr darauf achten, dem anderen Team dabei zu helfen, das Problem in Zukunft selbst lösen zu können.

Vermeidet es deshalb, die Aufgabe für andere zu erledigen, sondern unterstützt sie dabei, die Aufgabe selbst zu lösen, indem Ihr Euer Wissen weitergebt.

Ein weiterer (trauriger) Klassiker ist die Unterstützung von Kundenprojekten durch die Software-Produktentwicklung. Viele Projektteams sind nicht ausreichend gut aufgestellt, um Projekte vollkommen eigenständig umzusetzen. Um eine anstehende Deadline halten zu können, werden dann gerne Software-Entwickler aus der Produktentwicklung herangezogen, um eine schnelle Lösung für den jeweiligen Kunden zu erzielen.

Wenn es ganz schlecht läuft, gibt sich ein Unternehmen der Illusion hin, Ihr Produkt im Rahmen eines Projektes zu verbessern.

Arbeitet also daran, Projekte so umsetzen zu können, dass das Projektteam das Projekt ohne weitere Unterstützung umsetzen kann.

Soviel von meiner Seite zum On Product Index. Falls Du noch Fragen, Anregungen, Idee oder Kritik zu dieser Metrik hast, schreib mir gerne einen Kommentar hier unten auf der Seite! Ich freu mich auf Dein Feedback.