Die meisten Unternehmen arbeiten in der Produktentwicklung sequentiell in einem Wasserfall-Prozess (Cagan M. , 2022). Selbst in den Unternehmen, in denen die Entwicklungsteams nach Scrum oder mit anderen agilen Methoden arbeiten, ist Agilität oft auf die Entwicklung an sich beschränkt und in einen größeren Wasserfallprozess eingebettet. Dort arbeiten die Teams in Sprints, um eine Jahres-Roadmap in Form einer Liste von Features umzusetzen – nur eben in mehreren Sprints. Das typische Vorgehen in einem solchen Prozess beschreibt Cagan etwa so:
Der Prozess beginnt damit, dass von einer beliebigen Quelle Ideen generiert werden und den Prozess anstoßen. Oft kommen diese Ideen von Stakeholdern wie Kund:innen, der Sales-Abteilung, Fachabteilungen oder der Geschäftsführung. Wenn die Idee von einer Kundin oder einem Kunden kommt, dann sind es oft prominente Kund:innen, die einen großen Einfluss haben.
Diese Ideen sollen dann priorisiert werden. Daher wird irgendeine Art von Business Case erstellt. Dabei handelt es sich um eine Schätzung, wieviel die Idee wert ist und was sie kosten wird („Wieviel bringt uns diese Idee und was kostet sie uns?“).
Diese Business Cases werden dann in eine Roadmap gegossen. Das bedeutet, es wird etwa für ein Quartal im Voraus geplant, welche Business Cases wann umgesetzt werden. Manchmal werden Roadmaps auch für einen längeren Zeitraum bis zu einem Jahr geplant.
Nun sind die Themen eingeplant und können näher beschrieben werden. Die Produktmanager:in (oder Product Owner, Anforderungsmanager:in, Proxy PO, Projektmanager:in…) schreibt nun die Anforderungen, nachdem er/sie mit Stakeholdern gesprochen hat.
Es folgt eine Art von Design, z.B. ein UX-Design, welches auf diesen Anforderungen basiert.
Danach wird die Idee des Entwickler:innen vorgelegt für die Umsetzung der Anforderung. Ab jetzt kommt Agile ins Spiel und oft wird Scrum verwendet. Das bedeutet, dass die fertigen Anforderungen (z.B. in Form von User Stories) aus dem Product Backlog in das Spint Backlog geschoben werden, heruntergebrochen werden in Tasks und in einen Sprint eingeplant werden.
Der Test passiert bestenfalls innerhalb dieses Sprints durch die Entwickler:innen und das Product Management oder es wird nach dem Sprint getestet.
Am Ende des ganzen Prozesses wird das Feature oder Produkt zu den Kund:innen ausgeliefert im Deployment.
Es wird deutlich, dass, obwohl agile verwendet wird, es sich insgesamt um einen sequentiellen Wasserfall Prozess handelt. Bei einigen mehr, bei anderen weniger. Manchmal kommt Agile früher ins Spiel und die Entwickler:innen und/oder Design werden z.B. bereits in der Anforderungsphase eingebunden.
Dieses Modell bringt laut Cagan folgende Probleme mit sich:
- Ideen werden durch Verkaufsargumente generiert, doch das ist nicht die beste Quelle für Ideen
- Das Produktteam führt nur Vorgaben aus, doch das ist schlecht für Commitment und Motivation (Söldner:innen, keine Enthusiast:innen)
- Die Entscheidung, was gemacht wird, wird am Anfang getroffen, doch zu diesem Zeitpunkt sind viel zu wenig Informationen verfügbar, um zu entscheiden, ob die Idee funktionieren wird
- Das Risiko wird auf das Ende geschoben, wenn Kund:innen das Produkt bekommen und es evtl. nicht wertvoll finden – die Kundenvalidierung kommt viel zu spät. Durch die späten Kundenvalidierung entstehen hohe Opportunitätskosten: Was man alles hätte mit der Zeit und dem Geld Wertvolles und Sinnvolles machen können. Diese Gelegenheit kommt nicht zurück.
- Auch wenn Ideen gut sind, dauert die Umsetzung viel länger als gedacht, was man zu dem Zeitpunkt, wenn die Roadmap – also die zeitliche Planung – erstellt wird, noch nicht wissen kann, da die relevanten Informationen fehlen
- Produktmanager:innen kümmern sich um Anforderungen, also um Eigenschaften der Lösung, doch sollten sie sich um die eigentlichen Probleme der Kund:innen kümmern
- Design kommt so spät in den Prozess, dass es nur noch für optische Aspekte verantwortlich ist, doch es kann viel mehr und auch die Funktionalität an sich mitbestimmen
- Die beste Innovationsquelle sind die Entwickler:innen, welche hier viel zu spät in den Prozess kommen und somit diese Chance verpasst wird
- Die Vorteile von Agile (z.B. dem Scrum Framework) können hier nur in geringem Ausmaß wirken (nur bei der Entwicklung), auch diese Chance verpasst die Organisation durch diesen Wasserfall-Prozess
Insgesamt handelt es sich um einen projekt-lastigen Prozess. Es werden Projekte durchgeführt, die vielleicht auf halber Strecke versanden, deren Sinn verloren geht und die dann vor sich hindümpeln. Es geht dann nur noch um das Durchführen der Arbeiten und darum, irgendeinen Output zu generieren. Stattdessen sollte es darum gehen, sich um die echten Probleme zu kümmern, relevante und wertvolle Ergebnisse (Outcome) zu erzielen. Am Ende kommt etwas dabei heraus, dass die Erwartungen nicht erfüllt und Enttäuschung bei Stakeholdern hervorruft.
Projekte fokussieren die Tätigkeit, die Zusammenarbeit und die Aktivitäten. Doch darum geht es eigentlich nicht. Es geht um das Ergebnis, das Produkt. Es geht um Outcome (wird mit „Produkt“ assoziiert), nicht um Output (wird mit „Projekt“ assoziiert).
Wenn ein Projekt als etwas gesehen wird, dass dem Produkt dient, dann ist dies sicher kein Fehler an sich. Es wird für einen begrenzten Zeitraum ein Team gebildet, dass gemeinsam das Problem eines Kunden betreut und es zu lösen versucht. Das Ergebnis ist das Produkt. Doch je länger man an „Projekte“ denkt und diese in den Fokus des Jobs stellt, desto eher kann ein Projekt zum Selbstzweck werden.
Ein Projekt kann keine Probleme lösen, ein Produkt schon. Ein Projekt ist abstrakt, ein Produkt ist etwas Reales, etwas Greifbares. Projekte sind die Arbeit an sich, immer gleich und immer wieder neu. Jahrelanges Projektgeschäft hat die Tendenz, einen Selbstzweck zu entwickeln. „Wir machen Projekte.“, „Wir machen Projektgeschäft.“
Werden hier Projekte verkauft? Wird Arbeit verkauft und kein Ergebnis? Kein Produkt? Worin liegt der Wert?
Ein weiterer kleiner Hinweis: Gute Produktteams werden besser, wenn sie konstant zusammenbleiben. Dies ist bei Projekten unter Umständen nicht der Fall (Cagan M. , 2022).
Ob Projekt oder Produkt, wichtig ist, dass das Ergebnis im Vordergrund steht: Wichtige Geschäftsprobleme lösen.
Prinzipien des Produktmanagements nach Marty Cagan
Die Probleme, die durch Wasserfall-Prozesse auftreten, können durch drei Grundlegende Prinzipien minimiert werden (Cagan M. , 2022). Dies sind die Prinzipien des zeitgemäßen Produktmanagements:
- Risiken früh behandeln
- Kollaborativ anstatt sequentiell arbeiten
- Zuerst an Probleme denken und nicht an Lösungen
Diese drei Prinzipien nach Marty Cagan werden im Folgenden näher beschrieben.
Prinzip 1: Risiken früh behandeln
Bei der Produktentwicklung gibt es vier grundsätzliche Risiken: Diese Risiken sind:
- Value Risk: Produkt wird nicht gekauft/verwendet
- Usability Risk: Kund:innen können nicht herausfinden, wie das Produkt verwendet wird
- Feasibility Risk: Entwicklung erweist sich als nicht im Rahmen der gegebenen Möglichkeiten als umsetzbar
- Business Viability Risk: Produkt funktioniert nicht für alle Geschäftsbereiche wie Sales oder Rechtsabteilung
Sie sollen vor dem Start der Umsetzung behandelt und adressiert werden. Im Wasserfall-Modell werden diese Risiken an das Ende des Prozesses gelegt, wo Kund:innen das fertige Produkt erstmals in die Hände bekommen. Dort richten sie größeren Schaden in Form von Kosten an.
Prinzip 2: Kollaborativ anstatt Sequenziell
Alle beteiligten entwickeln gemeinsam Ideen und Prototypen. Durch die Beteiligung der Entwickler:innen sind diese Ideen auch technologiegetrieben, was Raum für Innovation bietet und diese fördert. Durch die Anwesenheit von Designer:in und Produktmanager:in wird der Business Value und die Usability von Anfang an gesichert.
Im Wasserfall-Modell muss man mit den Fehlern und Fehlinterpretationen arbeiten, die gemacht wurden, bevor man in der Kette an der Reihe ist. Dies ist durch kollaboratives Vorgehen von Anfang an nicht mehr nötig.
Prinzip 3: Problem anstatt Lösung
Wir wollen uns um echte Probleme kümmern und uns nicht auf eine Lösung fokussieren. So schaffen wir es, den Fokus auf die wichtigen Geschäftsergebnisse zu legen.
Exkurs: Konstruktivistische Denkweise und problemfokussierte Produktentwicklung
Wir neigen dazu, ständig Hypothesen zu bilden und von diesen Hypothesen schnell Lösungen abzuleiten. Das ist oft hilfreich, wenn es um wenig komplexe Sachverhalte geht und einfache Entscheidungen. Doch in der Produktentwicklung sollten wir dies (meistens) vermeiden und zuerst intensiv das Problem erforschen. Von den Vordenker:innen des zeitgemäßen Produktmanagement stammt der Satz:
„Fall in love with the problem, not the solution.“
Steve deShazer, der Vater der lösungsorientierten Beratung, meinte dazu:
„Wenn dir eine Hypothese einfällt, setz dich still in eine Ecke, nimm eine Aspirin und warte, bis der Anfall vorbei ist.“
Es soll bewusstwerden, dass wir immer anhand von Hypothesen handeln und entscheiden. Für ein gutes Produkt lohnt es sich, zunächst Zeit mit dem Problem zu verbringen und zu versuchen, darüber ausreichend passende Hypothesen zu bilden. Wie geht das? Durch Interviews, offene und systemische Fragen, Experimente, MVPs, Prototypen und Tests vor der Umsetzung einer Lösung.
Tool: Systemische Fragen zum Problem
Die folgenden Fragen dienen dazu, ein Problem zu untersuchen und können in Interviews und Team-Meetings hilfreich sein (Schlippe & Schweitzer, 2016):
- Aus welchen Prozessschritten besteht das Problem genau?
- Für wen ist es ein Problem? Für wen ist es keins?
- Wo (an welchem Ort, in welcher Umgebung) tritt das Problem nicht auf, wo nicht?
- Wann (zu welchem Zeitpunkt, in welchen Situationen) tritt das Problem auf, wann nicht?
- Woran würdest du merken, dass das Problem gelöst ist?
- Wer hat es zuerst als Problem bezeichnet?
- Wer würde am ehesten bestreiten, dass es sich überhaupt um ein Problem handelt?
- Wer reagiert am meisten auf das Problem, wer weniger? Und wie reagieren andere Personen auf das Problem?
- Wie erklärst du dir, dass dieses Problem entstanden ist?
- Welche Folgen haben diese Erklärungen für dich und das Team?
- Was hat sich verändert, als das Problem angefangen hat?
- Was würde sich verändern, wenn das Problem aufhört?
Das Thema ist nicht nur im IT-Bereich dienlich. Daumen hoch für den wertvollen Beitrag!