Chris Jones - Empowered

Ob das Produkt oder die Dienstleistung eine Versicherungspolice ist, ein Bankkonto oder eine Paketzustellung über Nacht: Im Kern geht es um ein Produkt, das Technologie als Enabler nutzt.

Entsprechend sehen starke Unternehmen es als die Aufgabe ihrer Produkt-Teams an, den Kunden zu dienen, indem sie Produkte schaffen, die die Kunden lieben werden – und die auf diese Weise auch dem Geschäft dienlich sind.

Das ist ein gravierender Unterschied, der sich beinahe auf alles im Unternehmen und wie es arbeitet auswirkt und zu einer viel höheren Motivation und Arbeitsmoral führt. Und der vor allem zu einem viel höheren Grad an Innovation und Wertschöpfung für die Kunden und das Business führt.

In den meisten Technologieunternehmen gibt es keine echte Führung der Produkt-Teams.

Stattdessen sind die Teamleiter hauptsächlich für das Staffing (die Stellenbesetzung) des internen (oder im schlimmsten Fall outgesourcten) Produkt-Teams und für funktionierende Abläufe verantwortlich.

In den meisten Unternehmen gibt es keine Produktstrategie. Und damit meine ich nicht, dass es eine schlechte Produktstrategie gäbe – ich meine wortwörtlich, dass es KEINE Produktstrategie gibt. Die Feature Teams sind einfach da, »um dem Business zu dienen«.

Es gibt sicherlich Gründe dafür, was angefordert oder auf die Roadmap gesetzt wird – aber es gibt kaum eine wirkliche Produktstrategie, geschweige denn die Skills oder die nötigen Daten, um eine zu entwerfen.

Das führt dazu, dass die Stakeholder den Produkt-Teams lange Listen von priorisierten Features und Produkten übergeben, die sie in diesem Quartal oder Geschäftsjahr umsetzen müssen. Die sogenannte »Produktstrategie« ist also einfach, zu versuchen, so viele dieser Zielvorgaben wie möglich zu erfüllen.

Als Technologie-Unternehmen in den letzten zehn bis zwanzig Jahren zu agilen Methoden übergingen, stellten viele Manager und Führungskräfte infrage, ob sie selbst überhaupt noch gebraucht werden, da von den Team-Mitgliedern erwartet wurde, eine viel aktivere Rolle im Arbeitsprozess einzunehmen.

Es mag widersprüchlich klingen, doch der Übergang zu wirklich bevollmächtigten Teams erfordert zwar, sich vom alten Führungsverständnis von »command and control« abzuwenden – doch es bedeutet nicht , dass weniger Führungskräfte und Manager gebraucht werden. Es bedeutet, dass bessere Führungskräfte und Manager gebraucht werden.

Es ist tatsächlich leichter für einen Manager, weiterhin im alten Stil von command and control zu managen (oder sogar zu mikromanagen). Es ist leicht, einem Team eine To-do-Liste oder eine Feature List zu geben und ihm zu sagen, dass es einfach diese Liste so schnell wie möglich abarbeiten soll.

Nun mag dieser Command-and-Control-Stil für den Manager einfacher sein – aber er bringt lediglich Teams hervor, die Dienst nach Vorschrift tun, ohne eine Spur von sinnenhaftem Empowerment.

Dagegen gehören die Produktleiter in starken Unternehmen zu den einflussreichsten Führungskräften überhaupt.

Sie sind dafür verantwortlich, die Product Teams personell aufzustellen und zu coachen; sie sind für die Produktstrategie verantwortlich und dafür, die Strategie in die Praxis umzusetzen; und sie sind dafür verantwortlich, ergebnisorientiert zu führen.

Empowered Product Teams brauchen fähige Manager, Produkt-Designer und Entwickler (Engineers), und es ist die Verantwortung der Führungskräfte und Manager, diese Menschen anzuwerben, einzustellen und zu coachen.

Einer der wichtigsten Beiträge der Produktleitung ist darüber hinaus eine zielgerichtete und überzeugende Produktstrategie, die auf quantitativen und qualitativen Erkenntnissen beruht.

In den meisten Unternehmen sind die Technologie-Teams keine Teams mit Eigenverantwortung, also empowered Teams, sondern schlicht »Feature Teams«.

Feature Teams wirken oberflächlich betrachtet wie Product Teams. Sie sind funktionsübergreifend, mit einem Product Manager, einem Product Designer und einigen Engineers. Der Unterschied besteht darin, dass sie zwar für die Implementierung von Features und Projekten, also für Output, verantwortlich sind – aber da sie keine echte Entscheidungshoheit haben, können sie auch nicht für die Ergebnisse verantwortlich gemacht werden.

Feature Teams verorten und sortieren die Features zunächst auf der Roadmap, dann führen sie vielleicht einige Usability-Tests durch, dann machen sie sich ans Erarbeiten der Features, ans Testen und schließlich an das Deployment (Delivery).

Diese Feature Teams würden von sich behaupten, auch Product Discovery zu machen – aber in Wirklichkeit ist das nur selten der Fall. Denn ihnen wurde schon vorher gesagt, wie die Lösung aussehen soll. Sie wurden nicht dazu ermächtigt, eine eigene Lösung zu kreieren. Ihr Job ist lediglich das Design und das Coding.

In diesen Feature Teams gibt es normalerweise eine Person mit dem Titel des Product Managers, aber was diese Person macht, ist hauptsächlich Projekt management. Sie stellt sicher, dass die Features konzipiert und geliefert werden. Das ist nötig – aber das ist kein Produkt management.

Die Feature Teams erhalten Roadmaps mit Features und Projekten (oder sie müssen die Roadmaps ganz und gar selbst erstellen). Deshalb liegt der Fokus des Teams auf Delivery – auf der Lieferung dieser Features. Die Features selbst sind also der Output. Wenn dieser Output nun keinen Impact auf die Geschäftsergebnisse hat, wen könnte man dafür verantwortlich machen?

Im Gegensatz dazu erhalten die Teams in starken Tech-Unternehmen keine fertigen Feature-Listen. Sie bekommen stattdessen Probleme übertragen, für die sie Lösungen finden müssen. Und vor allem bekommen sie die Verantwortung dafür, diese Probleme auf die bestmögliche Art und Weise, die sie sich ausdenken können, zu lösen. Sie sind »empowered«.

In dem Product-Team-Modell mit Empowerment haben Product Manager eine klare Verantwortlichkeit, und zwar, sicherzustellen, dass die Lösungen nützlich sind (»unsere Kunden werden das Produkt kaufen und/oder es benutzen«) und dass sie existenzfähig sind (»sie entsprechen den Anforderungen unseres Geschäfts«). Gemeinsam mit einem Product Designer, der dafür verantwortlich ist, dass die Lösung usable , also bedienbar ist, und einem Technik-Lead, in dessen Verantwortung liegt, dass sie feasible , also umsetzbar ist, ist das Team in der Lage, bei der Bewältigung dieses gesamten Spektrums an Risiken zusammenzuarbeiten (Value/Wert, Viability/Wirtschaftlichkeit, Usability/Bedienbarkeit und Feasibility/Umsetzbarkeit). Gemeinsam haben sie die Verantwortung für das Problem und sind für ihre Ergebnisse verantwortlich und rechenschaftspflichtig. 2

Fassen wir also zusammen, was Feature Teams von empowered Product Teams unterscheidet:

Feature Teams sind funktionsübergreifend (ein Product Manager, der hauptsächlich Projektmanagement macht, ein Produktdesigner plus einige Entwickler) und werden damit beauftragt, Features zu erstellen und Projekte durchzuführen, statt Probleme zu lösen, und somit geht es ihnen ganz und gar um Output, um Produktion, und nicht um Geschäftsergebnisse.

Product Teams mit Empowerment sind ebenfalls funktionsübergreifend (ein Product Manager, ein Produktdesigner und Entwickler), doch im Gegensatz zu Feature Teams wird von ihnen erwartet, dass sie Probleme lösen, und sie sind außerdem mit der entsprechenden Entscheidungskompetenz ausgestattet, um Lösungen zu finden, die funktionieren – gemessen am Ergebnis. Für deren Erfolg werden sie zur Rechenschaft gezogen. 3

Wenn Sie INSPIRED noch nicht gelesen haben, dann fragen Sie sich vielleicht: Was ist so falsch daran, wenn Geschäftsinhaber und Stakeholder entscheiden, was auf die Roadmap kommt, und somit auch, was die Engineers (Entwickler) bauen sollten?