Product-Ownership ist nicht einfach:
- Es gibt die unterschiedlichsten Anforderungen an das Produkt.
- Das Product Backlog ist überladen mit Features.
- Stakeholder aus Entwicklung, IT, Marketing, Sales und Betrieb haben alle eine Meinung, was als Nächstes getan werden muss.
Nur leider sind sie niemals einer Meinung.
Wenn diese Situation auch deiner Realität entspricht, dann lies weiter. In diesem Artikel lernst du ein einfaches Vorgehen kennen, mit dem du Features im Product Backlog priorisierst. Es wird dir helfen, alle Stakeholder einzubeziehen und zufriedenzustellen.
Schlüsselunterscheidungen: Anforderung und Lösung
Beginnen wir mit einer Schlüsselunterscheidung:
Anforderungen: Sie beantworten die Frage: Was soll das Produkt einem Anwender bieten? Oder aus der Anwendersicht formuliert: Wie benutzt jemand das Produkt? Welches Ergebnis kann erreicht werden? Bei einer Anforderung geht es um die Funktion, die das Produkt erfüllt. Deshalb spricht man hier auch von funktionellen Anforderungen.
Lösungen: Hierbei handelt es sich um die konkrete Umsetzung, die implementiert werden soll. Häufig findet man auch den Begriff Features statt Lösungen.
Ich habe bewusst Anforderungen und Lösungen geschrieben. In meinem „Professional Scrum Product Owner“-Training habe ich die Erfahrung gemacht, dass die Verwendung der Synonyme Funktionen und Features häufig zu Missverständnissen führt.
Features beschreiben die „Werkzeuge“, die Nutzer im Produkt verwenden, um Aufgaben oder Aktionen auszuführen. Die Funktionalität hingegen beschreibt, wie dieses Feature tatsächlich funktioniert und welche Ergebnisse damit erzielt werden können.
Ein Beispiel, an dem der Unterschied sofort offensichtlich wird:
Die Anforderungen oder Funktionen eines Produkts könnten sein:
- Eingeben
- Suchen
- Finden
- Teilen
Features oder Lösungen, die ein Produkt dem Anwender bieten könnte, wären:
- Hashtags filtern
- Kategorien browsen
- Freitextsuche
Beschränken wir uns nur auf die Anforderung „Suchen“, dann könnte ein Nutzer das Werkzeug Freitextsuche verwenden, um zu suchen.
Dieses Beispiel zeigt sofort, vor welcher Herausforderung Product Owner tagtäglich stehen. Es gibt die unterschiedlichen Lösungen „Hashtag“, „Kategorie“ oder „Freitextsuche“, um die Anforderung „Suchen“ zu realisieren.
Und aus meiner Erfahrung als Produkt Owner kann ich dir versichern, dass jeder Stakeholder eine andere Meinung hat, welche Lösung umgesetzt werden sollte. Das Marketing wünscht sich Hashtags, um auf der Höhe der Zeit zu sein. Der Vertrieb hingegen wünscht sich eine Freitextsuche, da er fürchtet, dass die Anwender Hashtags nicht verstehen werden. Aus Sicht der Entwickler wäre es am wenigsten Aufwand, mit Kategorien zu arbeiten.
Willkommen im Produkt-Management-Vakuum
Diese Situation bezeichne ich als das Produkt-Management-Vakuum.
Wie in einem Vakuum die Materie fehlt, fehlen in der Produktentwicklung klare Priorisierungskriterien. Anders ausgedrückt: Es fehlt eine transparente Art und Weise, wie entschieden werden kann, welche Lösung sich am besten für die gegebene Anforderung eignet.
Zwei falsche Ansätze:
Analyse-Paralyse-Ansatz: In durch Wasserfallentwicklung geprägten Unternehmen wird das Vakuum mit Analyse gefüllt. Es wird analysiert, was technisch möglich und was am preiswertesten in der Umsetzung ist. Die Gefahr hierbei besteht darin, dass es ewig dauert und das Resultat einer Analyse häufig nur eine weitere Analyse ist. Ich bezeichne dies gerne als Paralyse durch Analyse.
Scrum-Fantasie-Land: Angehende Product Owner, die noch über wenig wirkliche Berufserfahrung im Produktmanagement verfügen, glauben, dass der Product Owner dies einfach entscheidet. In Scrum entscheidet der Product Owner jedoch nur über das „Was“ und nicht über das „Wie“. Ferner bin ich der festen Überzeugung, dass man sich über lange Sicht nicht im Product-Owner-Sattel halten kann, wenn man einfach über die Köpfe der Stakeholder hinweg entscheidet. Ich bezeichne diesen Ansatz gerne als Scrum-Fantasie-Land.
Da keiner dieser Ansätze wirklich zielführend ist, suchen wir nach einem Ansatz, mit dem wir schnell Entscheidungen treffen und gleichzeitig alle Stakeholder einbeziehen können.
Der richtige Ansatz lautet:
Wertgetriebene Entwicklung
Dieses Vorgehen ist bereits seit dem Jahr 1970 bekannt und geht auf Tom Gilb zurück.
Um Anforderungen und Lösungen zu priorisieren und die Stakeholder dabei einzubeziehen, gehst du am besten in drei Schritten vor:
Schritt 1: Beschreibe den Wert, den die Lösung realisieren soll
Was bedeutet Wert?
Wert beschreibt die Anforderung an den Wert aus der Sicht eines potenziellen Nutzers oder Stakeholders. Der Wert beschreibt, wie gut das Produkt macht, was es macht. Er versucht, eine Aussage über den Nutzen für den Anwender zu machen.
Hier einige Beispiele:
- Einfach zu bedienen (Geringe Anzahl von Klicks)
- Spart Zeit (Verwendung der Lösung spart dem Nutzer Zeit im Vergleich zu den anderen Lösungen)
- Relevant (Mitbewerber verwenden diese Lösungen bereits)
- Schnell (Ladezeit beträgt unter X Sekunden)
Weitere Beispiele für Wertanforderungen findest du in der „The Elements of Value“-Pyramide von Bain & Company. In der Pyramide findest du viele Ideen für Kundenwert.
Weitere Bereiche, die einbezogen werden können, sind:
- Finanzieller Wert (Kosten, neue Kunden zu finden; Onboarding-Kosten)
- Unternehmenswert (Einfach zu warten, Qualität)
- Marktwert (Welche Position sichert diese Lösung dem Unternehmen am Markt?)
Allerdings genügt es für den Anfang, dich auf den Kundenwert zu fokussieren, da am Ende die Kunden über den Erfolg oder Misserfolg entscheiden.
Schritt 2: Wähle 5 bis 10 Werte und priorisiere sie mit den Stakeholdern
Jetzt geht es darum, das Produkt-Management-Vakuum zu füllen.
Erarbeite mit den Stakeholdern eine Liste von 5 bis 10 Werten, die am wichtigsten sind, aus allen möglichen Wertanforderungen. Wichtig: Wir sprechen hier nicht über Anforderungen und Lösungen!
Die Frage, die beantwortet werden soll, lautet:
Auf welche Wert-Anforderungen sollten wir uns in den nächsten 3 bis 6 Monaten konzentrieren?
Die gemeinsame Entscheidung darüber, was auf diese Liste kommt und was nicht, wird dein Leben als Product Owner so viel leichter machen. Fragen, auf was wir uns in den nächsten Monaten fokussieren und welche Features umgesetzt werden sollen und welche nicht, werden dann viel einfacher zu beantworten sein. Du kannst dich immer auf die gemeinsame Wert-Anforderung-Liste beziehen und sagen, dass wir uns darauf verständigt haben.
Schritt 3: Triff Entscheidungen mit der Wert-Entscheidungstabelle
Wie können wir nun, mit all dieser Vorarbeit, entscheiden, ob ein Hashtag, wie vom Marketing gewünscht, Freitextsuche, wie vom Vertrieb gewünscht, oder Kategorien, wie von den Entwicklern vorgeschlagen, die passende Lösung für die Anforderung „Suche“ ist?
Dazu kannst du eine einfache Tabelle verwenden:
Die Priorisierung der Anforderungen und Lösungen wird basierend auf den Wertanforderungen vorgenommen. Am besten machst du dazu einen Workshop, in welchem du die Stakeholder bittest zu bewerten, wie die unterschiedlichen Lösungen den Wertanforderungen entsprechen.
Die Priorisierung erhältst du mit folgender Formel:
(Wert_1 + Wert_2 + Wert_3) / Kosten = Priorität
Zusammengefasst: Mit diesen drei Schritten hast du das Produkt-Management-Vakuum mit wertgetriebener Entwicklung gefüllt.