Projekt- vs. Produktorganisation

Ist es sinnvoller, in Produkten statt in Projekten zu denken? Und worauf kommt es bei der agilen Entwicklung an? Wir verraten, was passiert, wenn Teams in einer Produktorganisation zu echten Problemlöser:innen werden.

Wirklich agil muss man in der Erreichung der Ergebnisse sein

Eins haben digitale Produkte wie Netflix, Google, Amazon oder Zalando gemeinsam: Sehr viele Menschen nutzen sie sehr gerne. Dann gibt es wiederum Produkte, bei denen es hakt und der Mehrwert auf der Strecke bleibt.

Erstere stammen meist von Teams, die sehr produktfokussiert agieren und sich auf schnelle Ergebnisse konzentrieren. Letztere oft von Unternehmen, die projektbasiert oder nach dem Wasserfallprinzip entwickeln. Und selbst, wenn agile Frameworks wie Scrum, Kanban & Co. im Einsatz sind, gibt es einen entscheidenden Unterschied: Agil darf man nicht nur in seinen Prozessen, sondern man muss es im Ergebnis sein.

Die Probleme projektbasierter Produktentwicklung

Ein Problem der projektbasierten Produktentwicklung liegt vor allem darin, dass IT-Departments als Dienstleistende für die Fachabteilungen agieren: Der Auftrag wird erteilt, linear abgearbeitet und schon ist der grüne Haken dran.

Was dabei auf der Strecke bleibt, ist die crossfunktionale Zusammenarbeit: Product Owner:innen und Product Manager:innen werden zu „Feature-Übersetzer:innen“ degradiert, während die Teams keine Produktprobleme lösen. Auch sind zuviele Stakeholder:innen involviert, die in einer intransparenten Produktentwicklung nicht verstehen, worauf es jetzt gerade ankommt und Features statt Ergebnisse priorisieren wollen. Dazu wird die Projektführung am Budget gemessen: Aber ist ein 3-Millionen-Projekt erfolgreicher als ein niedriger budgetiertes, wenn das Ergebnis keinen Mehrwert erzielt?

Und so lautet das Motto noch viel zu oft: Unser Projekt ist erfolgreich, wenn es abgeschlossen ist. Dabei sollte es vielmehr lauten: Unser Produkt ist erfolgreich, wenn es die definierten Businessziele unterstützt. 

Projekt- vs. Produktorganisation auf einen Blick 

Klassisches Projektdilemma: Hohe Kosten, niedriger Umsatz

Damit scheint das klassische Projektmanagement zum Scheitern verurteilt: Intransparente Prozesse, hoher Koordinationsaufwand und verringerte Produktivität sind öfter der Fall, als einem lieb ist. Und während die Kosten steigen, gehen Umsätze durch eine eine zu lange Markteinführung verloren. 

Langfristig noch schwerer wirkt sich das auf die User Experience aus: Lange Release-Zyklen bedingen langsame Iterationen und so dauert es, bis ein Feature echten Mehrwert liefert. Verzichtet man dann noch auf die Discovery oder User Research, werden die Probleme der Nutzenden nicht wirklich gelöst und keine zahlenden Kund:innen konvertiert.

Sind agile Frameworks wie Scrum gescheitert?

Sind wasserfallartige oder agile Frameworks wie Scrum damit gescheitert? Natürlich nicht, denn es kommt auf das zu bauende Produkt an. Wer aber Produkte schneller, kostensparender und nutzerzentrierter auf den Markt bringen will, darf nicht nur prozessagil sein. Vielmehr müssen Unternehmen ihre gesamte Art und Weise transformieren, wie sie Probleme angehen und lösen.

Anstatt dass Stakeholder:innen ihre gewünschten Features priorisieren und diese an ein Feature-Team weitergeben, müssen Produktteams Probleme selbstständig angehen. Sie müssen ermächtigt sein, Lösungen zu finden, die wertvoll, brauchbar und wirtschaftlich realisierbar sind. Dafür braucht es eine starke Produktorganisation, die auf stabilen Säulen ruht.

Was es für eine starke Produktorganisation braucht

People & Skills: Produkt-, Design- und Entwickler:innenteams müssen mit ausreichend Ressourcen befähigt sein, autonom und crossfunktional zusammenzuarbeiten – und zwar mit einer starken Führung von der Discovery bis zur Delivery. 

Strategy & Alignment: Es braucht eine klare Produktvision, aus der sich die Strategie und Roadmap mitsamt Problemen und Ergebnissen ableiten. Dafür muss das gesamte Product Leadership Team (z.b. Head of Product, Head of Engineering und auch Head of Design) eng zusammenarbeiten.

Mode of Work: Während die Produktleitung effektiv coacht und den Zielkontext liefert, sind die Teamtopologien passgenau auf die zu lösenden Probleme zugeschnitten. Um Nutzer:innen häufigen Mehrwert zu bieten, releasen die Teams oft, lernen daraus und setzen die Erkenntnisse erneut um.

Output & Outcomes: Führungskräfte und Teams werden nicht am verfügbaren Budget gemessen, sondern allein an den Ergebnissen und ihrem Impact auf die festgelegten Businessziele. 

Produktorganisation: Schritt für Schritt zum besten Outcome

Dein Unternehmen möchte den ersten Schritt zur Produktorganisation gehen? Dann gilt es, Verständnis zu schaffen: Was ist das überhaupt, welche Vorteile bietet sie und was müssen wir dafür tun? Jede:r muss verstehen, dass das Thema die gesamte Organisation betrifft. Dafür ist aktives Change-Management nötig. Sonst werden Rollen nicht verstanden, Prozesse nicht nachvollzogen und Engagements verringert.

Dann erfolgt die Transformation des gesamten Unternehmens: Es geht nicht mehr um Budgets, sondern um Ergebnisse. Viele Stakeholder:innen müssen erst lernen, Ziele zu setzen und Verantwortung abzugeben. Das ist ungewohnt und erfordert eine neue Führungskultur bzw. Kompetenz im Product Leadership.

Der Kern der Entwicklung bleibt hingegen agil: Produktteams releasen in schnellen Zyklen von ein bis zwei Wochen, sie lernen und setzen die neuen Erkenntnisse konsequent um. Das kann dann mit Scrum, Kanban oder einem anderen Framework geschehen – entscheidend ist, dass das Mindset stimmt, Probleme autonom gelöst werden und der Outcome im Fokus steht.