Der Stakeholder-Wert als Kompass der Produktentwicklung (Teil 1)
Gute Anforderungen sind wichtig für eine erfolgreiche Produktentwicklung – soweit erst einmal nichts Neues. Doch was nützen perfekte Anforderungen, wenn sie auf falschen oder unvollständigen Annahmen beruhen? Das ist in der Praxis erschreckend oft der Fall. Gerade bei der Entwicklung von innovativen Produkten haben wir anfangs oft ein falsches Verständnis vom Stakeholder-Wert der Lösung. Und selbst wenn nicht, so verändert er sich der Wert mit der Zeit, denn Kundenwünsche, Märkte und Technologien entwickeln sich weiter.
Wir sind recht gut darin, Wert in der Entwicklung zu verfolgen. Doch das nützt wenig, wenn es in der Stufe davor kein klares Verständnis davon gibt, was „Wert“ überhaupt bedeutet. Daher müssen wir zum einen den Stakeholder-Wert nicht nur erfassen und aktuell halten, sondern auch während der Entwicklung als Kompass im Auge behalten.
In diesem Artikel geht es darum, wie wir zu einem Werteverständnis kommen, dass von der Produktentwicklung aufgegriffen und effektiv genutzt werden kann. Wie die Nutzung in der Produkt konkret aussehen kann, wird in einem zukünftigen Teil 2 beschrieben.
Wert messen heißt Problem verstehen
Wert entsteht immer dann, wenn ein Stakeholder durch eine Lösung ein für ihn relevantes Problem besser gelöst bekommt. Das klingt banal, ist aber in der Praxis selten klar definiert. Bevor wir also über Funktionen, Features oder Design sprechen, müssen wir verstehen, welches Problem wir eigentlich lösen und wie stark der Schmerz dieses Problems ist. Hier zwei Beispiele dazu:
- Die Automobilindustrie versucht sein einer Weile, sich weniger auf das Produkt „Auto“ zu fokussieren, sondern mehr auf das Problem „Mobilität.“
- Eine Luxusuhr scheint das Problem „Zeit anzeigen“ zu lösen, doch das wichtigere zu lösende Problem ist „Status zur Schau stellen.“
Um kein wichtiges Problem zu übersehen, hilft die folgende Liste. Probleme können in eine der folgenden Kategorien fallen:
- Funktional: etwas kann nicht getan werden
- Performance: es ist zu langsam, schwach oder ineffizient
- Qualität: es fällt aus, verschlechtert sich oder frustriert
- Ökonomisch: es ist zu teuer
- Compliance: es verstößt gegen Regeln oder birgt Risiken
- Emotional: es fühlt sich unangenehm oder uninspirierend an
- Ökologisch: es schadet Nachhaltigkeit oder Reputation
Wert ist dynamisch und muss regelmäßig gemessen und aktualisiert werden!
Selbst wenn wir den Stakeholder-Wert verstanden uns zu Beginn der Entwicklung in guten Anforderungen manifestiert haben, ergeben sich zwei Probleme:
- Der Wert verändert sich, etwa durch neue Kundeninformationen oder Markttrends.
- Der Wertfluss wird nicht während der Entwicklung beobachtet, also wie sich Aktivitäten entlang der Entwicklung tatsächlich auf den Kundennutzen auswirken.
Diese Lücken kosten Geschwindigkeit und Effizienz. Product Velocity erfordert dagegen, dass Stakeholder-Wert kontinuierlich gemessen und nachgeführt wird, genau so, wie wir in DevOps kontinuierlich Qualität oder Performance überwachen.
OKRs als Brücke zwischen Strategie und Entwicklung
Ein bewährtes Werkzeug für diese Verbindung sind Objectives & Key Results (OKRs). Sie verbinden strategische Ziele („Objective“) mit konkreten, messbaren Ergebnissen („Key Results“).
OKRs werden oft zur skalierbaren Führung von Unternehmen eingesetzt. Prominente Organisationen, die OKRs einsetzen, sind Google und Intel. Diese Unternehmen nutzen OKRs, um Geschäftsziele fest in der Organisation zu verankern. Abteilungen, wie die Produktentwicklung, haben dann konkrete Key Results, die zum Erreichen der Ziele beitragen.
Jedes Key Result hat einen klaren Owner. Damit entsteht Autonomie mit Alignment: Teams können eigenständig handeln, ohne die gemeinsame Richtung zu verlieren. Gleichzeitig entsteht Transparenz, welche Aktivitäten tatsächlich Wert liefern. Die Produktentwicklung hat damit ein Werkzeug um sicherzustellen, dass Aktivitäten auf die Geschäftsziele ausgerichtet sind.
OKRs sind damit ein mächtiges Werkzeug für Alignment mit internen Anforderungen.
Value Framework als Brücke zwischen Entwicklung, Marketing und Vertrieb
Ein Value Framework hingegen schafft Alignment mit den produktspezifischen Anforderungen, was insbesondere für die Zusammenarbeit mit Marketing und Vertrieb wichtig ist.
In vielen Unternehmen arbeiten Entwicklung, Marketing und Vertrieb in schlecht verbundenen Silos, was Reibungsverluste verursacht. Doch moderne Vertriebsframeworks wie Command of the Message schaffen es, einen roten Faden von Stakeholderproblem bis zum Feature aufzubauen:
Dabei haben die einzelnen Boxen die folgende Bedeutung
- Vorher-Szenarien: Beschreiben die Ausgangssituation und die bestehenden Probleme oder Engpässe aus Stakeholder-Sicht.
- Negative Konsequenzen: Zeigen auf, welche Auswirkungen das ungelöste Problem hat, wie Kosten, Frust oder Ineffizienz.
- Nachher-Szenarien: Beschreiben, wie die Situation aussieht, wenn das Problem gelöst ist (wobei erst einmal egal ist, wie das Problem gelöst wurde).
- Positive Konsequenzen: Der messbare Nutzen und die Verbesserung für Stakeholder oder Kunden.
- Erforderliche Fähigkeiten: Listen die Funktionen oder Eigenschaften auf, die nötig sind, um den gewünschten Zustand zu erreichen. Hier schauen wir uns zum ersten Mal einen konkreten Lösungsansatz an.
- Metriken: Definieren, wie Erfolg gemessen wird: quantitativ oder qualitativ
So ein Value Framework ist typischerweise 1–2 Seiten lang. Marketing nutzt es für die Erstellung von Marketingmaterialien; der Vertrieb nutzt es in Kundengesprächen; und die Entwicklung nutzt es, um die Nutzer besser zu verstehen und die Entwicklung auf die Verbesserung der Metriken auszurichten.
Was Frameworks wie SAFe oft übersehen
Was ich eben beschrieben habe, ist eigentlich das Versprechen vom Scaled Agile Framework (SAFe). Viele Organisationen glauben, mit SAFe den Wertfluss bereits im Griff zu haben. Doch in der Praxis führt SAFe oft zum Messen der Effizienz der Prozesse und vernachlässigt dabei den Stakeholder-Nutzen. Das Framework zeigt, wo Wert entstehen sollte, prüft aber nicht, ob er tatsächlich entsteht. Leider verkommt SAFe häufig zum Selbstzweck.
Das bedeutet nicht, dass SAFe nutzlos ist. Aber um zu funktionieren muss SAFe richtig implementiert und gelebt werden. Und das kommt in der Praxis eher selten vor. (Wer positive Case Studies kennt, gern bei mir melden!).
Ausblick: Wie geht es in der Produktentwicklung weiter?
Wenn die Organisation auf den Stakeholder-Wert ausgerichtet ist, dann können wir uns damit beschäftigen, wie wir die Werteströme innerhalb der Organisation optimieren. Dazu verfolgen wir die folgenden vier Elemente, die, laut Mik Kersten, die Werte tragen und zu deren Realisierung beitragen:
| Flow-Element | Liefert | Getrieben durch | Beschreibung | Beispiel-Artefakte |
|---|---|---|---|---|
| Features | Neuen Geschäftswert | Kunden | Neue Funktionen, die einen geschäftlichen Nutzen schaffen und für den Kunden sichtbar sind | Epic, User Story, Anforderung |
| Defekte | Qualität | Kunden | Behebungen von Qualitätsproblemen, die das Kundenerlebnis beeinträchtigen | Bug, Problem, Incident, Change |
| Risiken | Sicherheit, Governance, Compliance | Sicherheits- und Risiko-Beauftragte | Arbeiten zur Behebung von Sicherheits-, Datenschutz- oder Compliance-Schwachstellen | Schwachstelle, regulatorische Anforderung |
| Technische Schulden | Beseitigung von Hindernissen für zukünftige Lieferung | Architekten | Verbesserung der Software- und Betriebsarchitektur zur Erhöhung der Lieferfähigkeit | API-Erweiterung, Refactoring, Infrastruktur-Automatisierung |
Wie das im Detail funktioniert ist ein Thema für Teil 2, der für Dezember 2025 geplant ist.
Fazit: Wert ist kein Artefakt, sondern ein kontinuierlicher Fluss
Wir wissen, wie man Anforderungen nachverfolgt, Designs validiert und Tests automatisiert. Doch das alles nützt wenig, wenn der Bezug zum Wert verloren geht.
Die Zukunft erfolgreicher Produktentwicklung liegt darin, Wert wie ein Systemparameter zu behandeln: messbar, rückgekoppelt und kontinuierlich. Nur, wenn die Organisation dies aufbereitet an die Produktentwicklung gibt und gemeinsam pflegt, ist Product Velocity möglich.
