Product Operating Model

Ein Product Operating Model beschreibt, wie ein Unternehmen seine Arbeit an digitalen Angeboten organisiert. Gemeint sind damit Dinge wie eine App, eine Website oder ein Online-Dienst. Klassisch wird solche Arbeit in Projekten erledigt: Jemand entscheidet oben, was gebaut werden soll, ein Team baut es, danach löst sich das Team wieder auf. Im Product Operating Model ist es anders. Ein festes Team bleibt dauerhaft für ein Angebot zuständig und verbessert es immer weiter. Es bekommt ein Ziel genannt, zum Beispiel „weniger Nutzer sollen beim Bezahlen abbrechen“, und darf selbst herausfinden, wie es dieses Ziel erreicht.

Warum Firmen vom Projekt zum Produkt wechseln

Der Kern des Problems ist eine falsche Erfolgsmessung. In der Projektwelt gilt ein Vorhaben als gelungen, wenn es pünktlich und im Budget fertig wurde. Ob die gebaute Funktion danach jemand benutzt, taucht in dieser Rechnung gar nicht auf. Es gibt Untersuchungen, nach denen ein großer Teil aller neu gebauten Software-Funktionen kaum oder nie genutzt wird. Das ist teuer bezahlte Arbeit ohne Wirkung.

Dazu kommt der Wissensverlust. Wenn ein Team nach der Auslieferung auseinandergeht, verschwindet das Wissen über den Code und über die Nutzer mit ihm. Das nächste Team muss sich alles neu erarbeiten oder baut daneben. Ein dauerhaftes Team dagegen sammelt über Jahre ein Verständnis dafür an, was bei seinen Nutzern funktioniert und was nicht.

Besonders sichtbar wird der Unterschied bei KI-Funktionen. Ein Chatbot oder eine Empfehlungsfunktion ist nach dem Start nicht fertig, sondern muss ständig beobachtet und nachjustiert werden. Antworten werden schlechter, Nutzer stellen unerwartete Fragen, neue Modelle kommen auf den Markt. Ein Projektteam, das sich nach der Auslieferung auflöst, passt zu dieser Realität schlecht.

Empowered Teams, Outcomes und Discovery

Die Grundeinheit ist das sogenannte empowered team, also ein Team mit echter Entscheidungsbefugnis. Typischerweise sitzen darin ein Product Manager, ein Designer und mehrere Entwickler zusammen. Diese Gruppe entscheidet gemeinsam, welche Lösung sie ausprobiert. Die Führungsebene gibt das Ziel und die Grenzen vor, nicht den Bauplan.

Gemessen wird an Outcomes statt an Output. Output heißt: Wie viele Funktionen wurden ausgeliefert? Outcome heißt: Was hat sich für Nutzer oder Geschäft messbar geändert? Ein Team kann in einem Quartal fünf Funktionen bauen und trotzdem nichts erreicht haben. Umgekehrt kann eine einzige kleine Änderung eine Kennzahl deutlich verbessern.

Damit man nicht monatelang am Bedarf vorbei baut, gehört Discovery dazu. Das ist die Phase vor dem eigentlichen Bauen: Man spricht mit Nutzern, baut billige Testversionen und prüft Ideen an echten Menschen. Erst was diesen Test übersteht, wird richtig entwickelt. Man kann sich das wie einen Kochtest vorstellen: lieber vorher probieren als hinterher den ganzen Topf wegwerfen.

Woran man es in Stellenanzeigen und Quartalsberichten erkennt

Der Begriff stammt aus dem Umfeld von Marty Cagan und der Beratungsfirma SVPG und ist vor allem seit seinem Buch „Transformed“ von 2024 verbreitet. Man trifft ihn in Stellenausschreibungen für Product Manager, in Beraterangeboten und in Präsentationen großer Konzerne. Wenn eine Bank oder ein Versicherer eine „Produkttransformation“ ankündigt, ist meist genau dieses Modell gemeint.

Für Anleger ist es ein Signal, aber ein vorsichtig zu lesendes. Der Umbau kostet Geld und dauert Jahre, weil sich Rollen, Budgets und Karrierewege ändern müssen. Häufig bleibt es bei neuen Titeln: Aus dem Projektleiter wird ein Product Owner, entschieden wird aber weiter oben. Fachleute nennen das spöttisch Product Theater. Ein brauchbarer Prüfstein ist die Frage, ob Teams Ziele oder Aufgabenlisten bekommen.