Produkt-Ziele zu definieren, ist schwierig.
Viele Scrum Teams schrecken davor zurück. Meine kürzliche Umfrage offenbart das Ausmaß: Nur 34 Prozent der Teams setzen sich Ziele.
Für mich ist das erst mal verständlich. Beim Setzen von Zielen steht viel auf dem Spiel – es geht um nicht weniger als den Erfolg des Teams – und Fehler sind deshalb besonders schmerzhaft. In den Scrum Teams und Unternehmen, in denen ich in den letzten Jahren gearbeitet habe, ist mir eine Reihe dieser Fehler aufgefallen.
Hier eine Liste der 10 häufigsten Fehler:
Fehler #1: Das Produkt-Ziel beschreibt ein Feature
Dies ist der mit Abstand häufigste Fehler.
Warum ist es problematisch, wenn das Produkt-Ziel die Fertigstellung eines Features beschreibt?
Die Fertigstellung eines Features ist nur der Anfang. Es ist lediglich der Output, den das Team produziert. Damit das Produkt jedoch erfolgreich ist, braucht es noch mehr. Das Feature muss nutzbar sein, benutzt werden, Kunden müssen dafür bezahlen, und das Unternehmen muss langfristig Gewinn damit erwirtschaften. Somit ist die bloße Fertigstellung ein schlechter Maßstab für den Erfolg und damit auch ein schlechtes Produkt-Ziel.
Diesen Zusammenhang findest du im Logik-Modell nochmal veranschaulicht:
Die Grafik führt uns auch gleich zum nächsten Fehler.
Fehler #2: Das Produkt-Ziel steht im Widerspruch zu Unternehmenszielen
Der Fehler ist drastisch formuliert.
Damit möchte ich dich wachrütteln. Produkt-Ziele sollten niemals im Widerspruch zu Unternehmenszielen stehen. Im Gegenteil: Produkt-Ziele sollten eine Verbindung zu den Unternehmenszielen herstellen.
Im Logik-Modell werden die Unternehmensziele als „Impacts“ dargestellt. Sie beschreiben die Auswirkungen auf den unternehmerischen Erfolg, die die Outputs haben. In letzter Instanz sprechen wir hier von Umsatz, Gewinn oder Marktanteilen.
Betrachte nochmal das Modell sowie Fehler 1 und Fehler 2: Wie sollten Produkt-Ziele jetzt beschrieben werden? Sie sollten Outcomes beschreiben – also ein wünschenswertes Verhalten der Nutzer des Produkts, das sich positiv auf die Unternehmensziele auswirkt. Diese Beschreibung gibt dem Team Flexibilität, welche Features das Produkt haben sollte, und gleichzeitig dem Unternehmen die Gewissheit, dass sich der Erfolg des Teams am Ende in den Unternehmenszielen bemerkbar machen wird.
Hierbei schleicht sich schnell ein weiterer Fehler ein:
Fehler #3: Die Erreichung des Produkt-Ziels liegt außerhalb des Einflussbereichs des Scrum Teams
Beschreibt ein Produkt-Ziel einen Outcome, dann muss das Team auch über die Fähigkeiten verfügen, die Ergebnisse für die Nutzer zu erreichen. Was meine ich damit?
Angenommen, das Produkt-Ziel lautet:
„Wir glauben, dass die Vereinfachung des Checkout-Prozesses auf der Homepage zur Steigerung des Umsatzes beiträgt. Unser Ziel ist erreicht, wenn 65 % der Nutzer den Bestellvorgang beim ersten Versuch erfolgreich abschließen und die Zeit, die der Kunde im Checkout-Prozess verbringt, durchschnittlich um 45 % reduziert wird.“
Dieses Ziel beschreibt zwar eine Verhaltensänderung der Kunden, die sich auf ein Unternehmensziel auswirken könnte, aber wenn das Team nur aus Backend-Entwicklern besteht und niemand Fähigkeiten in UX, UI, Frontend und UX-Writing mitbringt, könnte das Produkt-Ziel außerhalb des Einflussbereichs des Teams liegen.
Hiervor will uns auch der Scrum Guide warnen, er beschreibt Scrum Teams so:
„Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt-Ziel. Scrum Teams sind interdisziplinär, d. h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.“
Interdisziplinarität ist für Scrum Teams kein Nice-to-have, sondern notwendig, um outcomerelevante Ziele eigenständig zu verfolgen.
Fehler #4: Das Produkt-Ziel lässt dem Scrum Team keinerlei Handlungsspielraum
Wie schleicht sich dieser Fehler ein?
Aus meiner Erfahrung beginnt alles mit dem ersten Fehler: Das Produkt-Ziel beschreibt zunächst nur ein Feature. Als wäre das nicht schlimm genug, beschreibt das Ziel dann einen bestimmten Aspekt dieses Features. Hier ein Beispiel:
„Bis zum Ende von Q3 nutzen 65 % unserer Kunden das Feature mehr als einmal pro Woche.“
Was ist mit den Kunden, die das Feature bereits nutzen? Und braucht es nur dieses eine Feature, damit die Kunden zufrieden sind?
Teresa Torres hat für solche Situationen eine hilfreiche Frage parat:
„Ist es möglich, einen zufriedenen Kunden zu haben, der niemals das Feature genutzt hat?“
Wenn die Antwort „Ja“ ist, dann ist das Ziel zu eng gefasst und lässt dem Team zu wenig Handlungsspielraum. Vielleicht wäre es besser, ein Set von Features zum Ziel zu machen oder den möglichen Wert für die Nutzer als Ziel zu definieren.
Fehler #5: Das Produkt-Ziel hat zu viele Abhängigkeiten
Es ist längst kein Geheimnis mehr:
Abhängigkeiten verlangsamen Teams und behindern somit die Agilität des Unternehmens. Aber nicht nur das: Abhängigkeiten führen schnell zu Frust im Team, wenn es ein Ziel verfolgt, dabei aber die Unterstützung anderer Teams oder Personen braucht. Und versteh mich nicht falsch – ich bin ein großer Fan davon, dass mehrere Teams das gleiche Ziel verfolgen. Es gibt kaum einen besseren Mechanismus, um gemeinsame Planung, Zusammenarbeit und Verantwortung für das Ergebnis zu fördern.
Aber wenn ein Softwareentwicklungsteam bei der Erreichung des Produkt-Ziels auf die Marketing- und Vertriebsabteilung angewiesen ist, diese jedoch andere Ziele verfolgen und deshalb nie Zeit haben, dann ist das eine sichere Quelle für Frust – und sorgt für unzufriedene Entwickler.
Fehler #6: Das Produkt-Ziel ist nur richtungsweisend
In den letzten Jahren habe ich einigen Teams geholfen, von einem Output-Ziel zu einem Outcome-Ziel zu kommen.
Dabei habe ich immer das Gleiche festgestellt: Den Teams fehlten einfach Daten. Ihnen fehlten jegliche Informationen über das Kundenverhalten. Sie wussten nicht, welche Features die Kunden nutzen und wie zufrieden sie damit sind.
Die Produkt-Ziele lauteten dann zwangsläufig so:
„Steigerung der Anzahl der Sendungen, die unsere Kunden ansehen.“
Und das ist nicht der Fehler. In dieser Situation ist ein solches Ziel ein guter Anfang. Das Ziel ist richtungsweisend. Aber sich mit diesem Ziel abzufinden – das ist ein Fehler.
Denn Ziele haben auch das Potenzial, dafür zu sorgen, dass die passenden Daten erhoben werden. Betrachte stattdessen dieses Ziel:
„Die Hälfte unserer Zuschauer sieht mindestens eine Show pro Woche bis zum Ende.“
Ein solches Ziel motiviert das Team, die passenden Daten zu erheben.
Fehler #7: Der Erfolg des Produkt-Ziels wird nur durch die Nutzung eines Features gemessen
Es ist ein riesiger Unterschied, ob Kunden das Produkt nutzen – oder ob sie damit erfolgreich sind.
Hier ein Beispiel:
- Was sagt mehr über den Erfolg einer Job-Plattform aus? Die Anzahl der Bewerbungen, die ein Nutzer an Unternehmen verschickt hat – oder die Anzahl der Stellen, die ein Bewerber erhalten hat?
- Was sagt mehr über den Erfolg einer Sprachlern-App aus? Die Anzahl der abgeschlossenen Lektionen – oder die Anzahl der Nutzer, die sich tatsächlich in einer neuen Sprache unterhalten?
- Was sagt mehr über den Erfolg eines Fitnessprogramms aus? Die Anzahl der absolvierten Workouts – oder die tatsächlichen Kilos, die Sportler verloren haben?
Du siehst bestimmt, worauf ich hinauswill.
Wird die Erreichung eines Produkt-Ziels nur an der Nutzung eines Features festgemacht, ist das problematisch – besonders dann, wenn die Nutzung nicht die Erreichung des Ziels des Kunden beschreibt.
Auf diesen Fehler bin ich vor Kurzem erst gestoßen, als ich ein Team im B2B-Bereich unterstützte und irgendwann feststellte, dass die Kunden des Produkts Unternehmen waren. Die Nutzer hatten also keine Wahl, ob sie das Programm nutzen oder nicht. Deshalb war die Nutzungsdauer eine sehr schlechte Erfolgsmetrik.
Sollten wir stattdessen den Net-Promoter-Score messen?
Fehler #8: Der Erfolg des Produkt-Ziels wird nur an der Kundenzufriedenheit gemessen
Damit du verstehst, warum das auch ein Fehler sein kann, müssen wir einen Schritt zurücktreten.
Es gibt drei Stufen von Wert für unsere Kunden:
- Nutzer nutzen unser Produkt. Wir messen dies mit verhaltensbasierten Messungen, z. B. durch Produktanalysen wie Google Analytics oder Amplitude.
- Nutzer mögen das Produkt. Wir messen dies mit Stimmungsanalysen, z. B. Net-Promoter-Score oder Feedback-Umfragen.
- Nutzer haben einen Nutzen davon. Hierfür gibt es keine vorgefertigte Messung – das hängt stark von den Zielen der Nutzer ab.
Für die letzte Stufe ein Beispiel:
Nutzt du Spotify? Wenn ja, bezahlst du auch dafür? Falls ja, wäre das ein starker Indikator dafür, dass du einen Nutzen aus Spotify ziehst. Oder anders ausgedrückt: Würdest du weiterhin dafür zahlen, wenn du nichts davon hättest?
Nach diesem Exkurs zurück zum Fehler: Kundenzufriedenheit zu messen ist wichtig. Sich aber nur darauf zu verlassen, ist problematisch. Kundenzufriedenheit allein ist häufig keine gute Beschreibung des Werts für den Kunden.
Fehler #9: Das Scrum Team wird für die Erreichung des Produkt-Ziels haftbar gemacht
Dieser Fehler ist fatal.
Natürlich müssen sich Teams für ein Ziel verantwortlich fühlen – sonst wird es kaum erreicht. Genau deshalb betont der Scrum Guide, dass das Team Verantwortung für das Produkt-Ziel übernimmt:
„Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen.“
Doch hier liegt ein wichtiger Unterschied: Commitment bedeutet nicht Haftung.
Ein Team, das für das Erreichen eines Ziels haftbar gemacht wird, wird Risiken vermeiden. Genau das ist die Kritik an leistungsabhängigen Boni – Menschen konzentrieren sich dann nur noch darauf, ihren Bonus zu sichern, anstatt mutige Entscheidungen zu treffen. Daniel Pink beschreibt dieses Problem ausführlich in seinem Buch Drive: The Surprising Truth About What Motivates Us.
Die Produktentwicklung ist jedoch voller Unsicherheiten. Niemand kann zu Beginn mit absoluter Sicherheit vorhersagen, was funktionieren wird und was nicht. Teams müssen ausprobieren, experimentieren – und das bedeutet, dass Fehlschläge dazugehören. Wenn sie jedoch unter Druck stehen, das Ziel um jeden Preis zu erreichen, werden sie weniger testen und sich nur auf sichere Optionen konzentrieren.
Das ist das Gegenteil von Innovation.
Fehler #10: Das Produkt-Ziel wird nicht regelmäßig überprüft und angepasst
Dieser Fehler knüpft an den letzten an.
Ob ein Team ein Produkt-Ziel erreicht oder nicht, kann zu Beginn niemand sagen.
Deshalb muss der Fortschritt bei der Erreichung des Ziels regelmäßig überprüft werden. Alles andere wäre ein Fehler.
Aber du glaubst nicht, wie oft ich schon das Argument gehört habe: „Wir hatten in den letzten drei Monaten nicht so viel Zeit, an diesem Ziel zu arbeiten – lass uns das Fortschritts-Review auf Ende nächsten Quartals verschieben.“
Die Antwort muss klar „Nein“ lauten.
Wird der Fortschritt bei der Zielerreichung nicht regelmäßig überprüft, berauben wir uns der Möglichkeit, zu lernen – und das Unternehmen der Möglichkeit, das Ziel anzupassen oder die Umstände für das Team zu verbessern.
Deshalb sollte der Fortschritt bei der Erreichung des Ziels immer im Review besprochen werden – so, wie es der Scrum Guide vorsieht:
„Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern vor, und die Fortschritte in Richtung des Produkt-Ziels werden diskutiert.“
Suchst du weitere Unterstützung bei der Definition der Ziele deines Teams?
Dann empfehle ich dir meine „Professional Agile Leadership – Evidence-Based Management“-Schulung. In den letzten Jahren sind bereits 169 Führungskräfte, Product-Owner und Scrum Master meiner Empfehlung gefolgt und haben das Training besucht.