Produkt Mindset vs. Projekt Mindset? Um was geht es da?

Oder auch „Was ist eine Produkt Organisation“?

Die Begriffe Produkt Mindset oder auch Produkt Organisation machen seit einiger Zeit die Runde. Diese Seite fasst die wichtigsten Informationen zu diesem Thema zusammen.

Das IT-Mindset (Projekt Mindset) vs. Produkt Mindset

Marty Cagan schreibt häufig vom Projekt- und Produkt Mindset (oder auch Produkthaltung), Scrum sagt ganz klar, dass es ein Framework zur Entwicklung von Produkten ist und auf Twitter findet man häufiger #NoProject Tweets. Da ich vor langer Zeit selbst als Projektleiter ausgebildet wurde und gerne in Projekten denke, ein Grund nachzuforschen, wo denn das Problem liegt.

Zunächst eine Tabelle, um herauszufinden, was mit Projekt und Produktmindset gemeint ist. Diese Tabelle basiert auf einem Artikel von Marty Cagan und meinen eigenen Beobachtungen. Ich habe einige Punkte leicht abgewandelt und eigene Punkte aufgenommen bzw entfernt.

Projekt Mindset Produkt Mindset
Sinn
  • „Sagt uns, was wir tun sollen, und wir bauen es Euch“ (Söldner)
  • „Wir lösen die Probleme der Kunden“ (Problemlöser)
Anforderungen
  • Anforderungen werden von Stakeholder eingesammelt
  • in Roadmaps priorisiert
  • implementiert
  • Wir wissen nicht, was das beste Produkt ist und müssen dies in mehreren Iterationen mit Wendungen und Änderungen herausfinden (Product Discovery)
Mitarbeiter
  • Projekt Management
  • Upfront Business Analysts / Requirement Engineers
  • Outsourcing
  • (starke) Produkt Manager
  • User Experience Experten
  • Entwickler mit Blick für den Kunden
Budget
  • feste Projektbudgets
  • vorab definierter Scope
  • große Liefereinheiten (Badges)
  • basierend auf Ergebnissen (Outcome)
  • kleine Liefereinheiten (Badges)
Steuerungsziele
  • Sicherheit
  • Vorhersehbarkeit
  • Auslastung
  • Neues lernen
  • Wertmaximierung
  • Innovationen
Prozess
  • lange Phasen
  • „Staffellauf“
  • Iterative und inkrementelle Vorgehen
  • „Rugby“
Organisation
  • Funktionsorientierte Arbeitsgruppen (Entwickler, Designer, Tester, Produkt Manager…)
  • Übergabe / Staffellauf
  • eine Person arbeitet in vielen Teams für viele Projekte (Auslastung)
  • Crossfunktionale, lieferfähige Teams
  • Zusammenarbeit
  • Eine Person arbeitet in einem Team für ein Produkt
Verantwortung
  • Aufgrund der Verteilung auf viele Arbeitsgruppen sehr diffus
  • Fingerpointing, wenn etwas schief geht
  • Fehler werden bestraft
  • klare Verantwortung für das Ergebnis beim Team
  • Team übernimmt Verantwortung
  • Fehler sind Lernmöglichkeiten

Wenn es um Innovationen und die erfolgreiche Entwicklung eines neuen Produktes geht, sind die Punkte auf der linken Seite suboptimal und eine Orientierung bzw. ein Wandel zu den Punkten auf der rechten Seite wird nicht nur von Marty Cagan empfohlen. Die Tabelle gibt es zum Selfassessment als Download.

Produkt Mindset in a Nutshell

Alex Rinke, Gründer von Celonis, fasst im Alles auf Aktien Podcast (Minute 45) das Produkt Mindset zusammen:

Worauf wir uns morgens fokussieren und das ist wirklich so:
Wir stehen morgens auf, überlegen uns,
welche Produkte können wir bauen,
wie können wir unsere Leute motivieren,
wie können wir besser werden,
wo können wir Kunden gewinnen,
wo können wir Kunden zufrieden machen
und darauf fokussieren wir uns“ 

Alex Rinke, Gründer von Celonis

Siloorganisation vs. Produkt Organisation

Was ist eine Silo-Organisation?

Unter Siloorganisation verstehe ich eine Organisation, die nach Arbeitsfunktionen aufgestellt ist. Es gibt Abteilungen wie Sales, Marketing, Projekt Management, Produkt Management, Entwicklung A (z.B. Hardware, Frontend) Entwicklung B (z.B. Software, Backend) , Qualitätssicherung, Einkauf.

Das Problem der Siloorganisation ist, dass die einzelnen Silos das gemeinsame Ziel der Organisation schnell aus den Augen verlieren. Stattdessen fokussieren und optimieren die Organisationseinheiten auf Proxyziele bzw. Indikatoren wie Verkaufsabschlüsse, Kampagnengröße, Anzahl Features. Die Siloorganisation ist für mich das in Organisationsform gegossene IT-Mindset, von dem Marty Cagan gerne spricht (siehe Tabelle).

Prinzipien einer Produkt Organisation

Die Probleme der Siloorganisationsform sind lange bekannt und wissenschaftlich untersucht. Als Lesetip empfehle ich das New New Product Development Game von Nonaka und Takeushi. Bereits 1986 machte diese Studie wichtige Prinzipien sichtbar, die für eine Produkt Organisation entscheidend sind:

  • Eingebaute Instabilität: Es werden herausfordernde Ziele formuliert, aber keine detaillierten Produktvorstellungen oder Arbeitsanweisungen. Das Team erhält viele Entscheidungsfreiheiten, muss aber auch mit den extrem fordernden Zielen und der dadurch entstehenden Unsicherheit klarkommen.
  • Selbstorganisierte Projektteams
  • Überlappende Entwicklungsphasen: weg vom Staffellauf zwischen den Silos, hin zu einer Rugby ähnlichen, gemeinsamen Team Bewegung.
  • „Multilearning“ – Lernen findet auf vielen Ebenen und Dimensionen statt. Dazu zählt auch, dass die Mitarbeitenden in verschiednen Disziplinen aktiv werden und Wissen akkumulieren.
  • Subtile Kontrolle: Management setzt das Ziel und den Rahmen und hält sich ansonsten mit Interventionen zurück.
  • Lernen als Organisation: es muss sichergestellt werden, dass sich das Gelernte in der Organisation verbreiten kann.

Konkrete Schritte zur Produkt Organisation

Basierend auf dem New New Product Development Game und vielen weiteren Veröffentlichungen aus der Product Community halte ich folgende konkreten Maßnahmen für hilfreich:

(Die Liste wird fortlaufend aktualisiert – es lohnt also ein Lesezeichen und ein erneuter Besuch).

Nutze herausfordernde, ergebnisorientierte Ziele und Kennzahlen

Die Organisationseinheiten in einer Siloorganisation verliert das eigentliche Ziel aus den Augen. Anstelle von wirtschaftlichen Zielen- oder Markt und Kundenbedürfnissen treten Proxyziele wie arbiträre Produkt Eigenschaften, Anzahl von Produkt Eigenschaften, Auslastung oder Velocity von Teams.

Daher müssen gemeinsame, ergebnisorientierte Ziele wieder in den Mittelpunkt der Aufmerksamkeit gestellt werden:

  • Welche Geschäftsziele versuchen wir zu erreichen?
  • Welche Geschäftskennzahlen sollen sich wie verändern?
  • Welchen Markt- oder Kundennutzen versuchen wir bereitzustellen?
  • Wie messen wir diese? (Geschäftsziele / Erfüllung Marktbedürfnisse / Kundennutzen)
  • Was können wir tun, um diese Ziele zu erreichen?

Diese Ziele werden nicht in einem 2-Tages-Top-Executive-Offsite-Workshop ermittelt und dann der Organisation übergestülpt.

Diese Ziele sind Teil eines kontinuierlichen und gemeinsamen Dialoges (von oben nach unten, von unten nach oben und seitwärts), mit vielen Feedbackschleifen und kontinuierlichen Anpassungen.

Hilfreiche Methoden

Finde und fördere starke Produkt Menschen

Finde und fördere Menschen in deiner Organisation, die in der Lage sind eine gesamtheitliche Perspektive auf das Produkt zu liefern. Dazu gehört die Kenntnis des Marktes und der Kunden, aber auch die Möglichkeiten und Fähigkeiten der Organisation.

Ein starker Produkt Mensch

  • hat ein gutes Gespür für die Entwicklungen am Markt und beim Kunden
  • ist Experte für den Markt, die Kunden, den Anwender und kennt die dafür notwendigen Daten.
  • ist begeistert seinem Produkt und kann andere davon begeistern
  • schafft Klarheit und Perspektive (Vision und Strategie)
  • arbeitet erfolgreich mit anderen Menschen (Stakeholder, Entwicklungsteam) zusammen
  • kennt Methoden und Prozesse, um ein gutes Produkt zu entwickeln (Scrum, Product Discovery, Delivery, …)

Viele der Punkte werden in unseren Product Owner Trainings vermittelt.

Höre den Produkt Menschen zu und unterstütze sie

Marty Cagan hat den Satz geprägt „Produkt als Katalysator für Veränderung“. Was er damit meint ist, dass man aus der Perspektive des Produktes viele Impulse für positive Veränderungen in einer Organisation gewinnen kann. Also nicht Veränderung, der Veränderungen wegen, sondern um die Fähigkeit der Organisation zu stärken, ein gutes Produkt zu entwickeln.

Die Produkt Menschen haben einen guten Produkt-Blick auf die „Pains und Gains“ der Organisation und deren Prozesse.

  • Können gute Entscheidungen schnell getroffen werden? Wenn nein, wo hängt es? Was bremst die Entscheidungen aus?
  • Können Experimente schnell durchgeführt werden? Funktionieren die Feedbackschleifen zum Markt und Kunden?
  • Sind die Teams in der Lage in guter Geschwindigkeit iterativ zu liefern?

Bespreche diese Fragen mit deinen Produkt Menschen, bzw. höre ihnen zu, welche Themen sie sehen. Identifiziere gemeinsam mit ihnen die größten Hebel für Verbesserungen. Entwickelt gemeinsam mögliche Verbesserungsmaßnahmen und unterstütze diese.

Empowered Teams – aka Task Force

Es gibt eine sehr lange bekannte und oft erfolgreich durchgeführte Praktik, die sehr schnell Produkt Fokus herstellt: die „Task Force“.

Eine Taskforce ist die Reaktion auf das Problem, dass eine bestimmte Aufgabe aufgrund siloinduzierter Probleme nicht gelöst werden kann:

  • Fehlender Fokus auf die Aufgabe
  • bremsende Abhängigkeiten
  • ineffektive und ineffiziente Kommunikationsmuster
  • langwierige Entscheidungsprozesse

Eine Task Force zieht die notwendigen Personen zusammen (= weniger Abhängigkeiten und deutliche vereinfachte Kommunikation) und gibt ihnen ein klar definiertes Ziel (= messerscharfer Fokus).

Die Idee eines Empowered Teams entspricht weitestgehend einer auf Dauer angelegten, nachhaltigen Task Force. Ein Scrum Team ist in gewisser Weise eine dauerhaft und nachhaltig agierende Task Force.

Diese „ermächtigten“ Teams sind die kleinste Einheit in einer erfolgreichen Produkt Organisation. Sie sind in der Lage komplexe Probleme zu lösen und innovative Lösungen zu entwickeln (eine einzelne Person ist dazu häufig nicht in der Lage).

Daher sind „ermächtigte“, lieferfähige Produkt-Teams ein zentraler Baustein der Produkt Organisation. Die Teams müssen in der Lage sein, Entscheidungen selbst zu treffen und möglichst eigenständig zu liefen. Abhängigkeiten, sowohl bei Entscheidungen aber auch zu anderen Teams bremsen die Feedbackschleifen aus, die eine Produktorganisation benötigt, um gute Produkte zu bauen.

Eine gute Grundlage / Betriebssystem für diese Produkt Teams ist das Scrum Framework, für das wir Trainings anbieten.