Chris Jones - Empowered

Ein eindeutiger Lackmustest wäre, wenn ein wichtiger Branchenanalyst anböte, Ihr Unternehmen zu besuchen, um über Ihr Produkt etwas zu hören. Entweder würde der Produktmanager selbst ein Briefing geben, oder er würde zumindest erhebliche Zeit mit der Vorbereitung einer Person zubringen, die das Briefing geben wird (gewöhnlich der Product Marketing Manager).

Es gibt zahllose prozessbezogene Kenntnisse und Verfahren, und neue Methoden kommen laufend hinzu. Das wichtigste Ziel für jene von uns, die verantwortlich für das Coaching von Product Managern sind, ist es, sicherzustellen, dass der PM sich in allen Methoden auskennt, die für die bevorstehenden Aufgaben geeignet sind.

Der neue PM muss mindestens die vier verschiedenen Arten der Produktrisiken verstehen (Value, Usability, Feasibility und Viability), die verschiedenen Modelle, wie mit diesen Risiken umgegangen werden kann, und wie jene Risiken qualitativ und quantitativ getestet werden können.

Es gibt viele Online-Quellen und Schulungen. Außerdem befasst sich mein Buch INSPIRED im Detail mit diesen Methoden der Product Discovery.

Wenn ich PMs coache, lasse ich sie gewöhnlich das Buch lesen, und dann stelle ich sicher, dass sie die Methoden verstehen, indem ich verschiedene Szenarien beschreibe und den oder die PM frage, wie er oder sie damit umgehen würde. Ich vergewissere mich, dass angemessen über Risiken nachgedacht wird und dass die Stärken und Grenzen jeder Methode verstanden werden.

Für Produkte, die in Produktion sind und deren Traffic (Anzahl der Besucher auf der Website) signifikant hoch ist, gibt es wichtige Methoden, die als Product Optimization/Produktoptimierung bezeichnet werden und die der Produktmanager verstehen und effektiv anwenden können muss.

Dies bedeutet üblicherweise, dass eine der gängigen kommerziellen Methoden erlernt wird und dann eine laufende Reihe von A/B-Tests durchgeführt wird – hauptsächlich, um den Produkttrichter zu optimieren, aber auch für andere Zwecke gut nutzbar.

Im Allgemeinen stehen Methoden der Product Delivery im Fokus der Techniker, sprich der Software-Entwickler im Team. Jedoch ist es für den Produktmanager wichtig, die angewandten Delivery-Methoden (zum Beispiel kontinuierliche Delivery/Lieferung) zu verstehen und in einigen Fällen – wie bei der Release-Planung – eine aktivere Rolle zu übernehmen.

Zum Beispiel kann vielleicht für bestimmte große Produktveränderungen ein Parallelbetrieb eingefordert werden. Der Product Manager muss wissen, was diese Methode mit sich bringt – besonders hinsichtlich zusätzlicher Entwicklungskosten –, um adäquate Entscheidungen bezüglich der Auslieferung zu treffen.

Die Entscheidung darüber, welchen Development Process (Entwicklungsprozess) die Techniker verwenden, um Software zu entwickeln und abzuliefern, ist Sache der Techniker und der technischen Leitung. Jedoch spielt der PM eine Rolle im Prozess, und er muss verstehen, welche Verantwortlichkeiten er hat.

Die meisten Teams benutzen als Methode etwas wie Scrum, Kanban und/oder XP (Extreme Programming). Häufig verwenden Teams eine Mischung davon.

Ich empfehle gewöhnlich, dass der neue PM einen CSPO-Kurs (Certified Scrum Product Owner) besucht, wenn er es nicht bereits getan hat. Der einfache und kurze Kurs wird ihm erklären, welche Verantwortlichkeiten er als Product Owner für das Team hat.

Die meisten Unternehmen haben auch eine Methode für das Managen der Produktrückstände standardisiert, also wird der neue PM auch diese Methode erlernen müssen.

Beachten Sie einen Punkt, über den ich mich immer wieder beschwere: Zu viele Product Manager hatten nur eine CSPO-Schulung und verstehen dann nicht, warum sie als Product Manager versagen. Hoffentlich ist an diesem Punkt klar geworden, dass die CSPO-Aufgaben, obgleich wichtig, nur eine sehr kleine Teilmenge der Verantwortlichkeiten eines Product Managers in einem empowered Product Team sind.

Bislang haben wir hauptsächlich Gebiete (Produktkenntnis, Prozesskenntnisse und Methoden) besprochen, in denen praktisch jeder, der bereit ist, sich da hineinzuknien, erfolgreich sein kann. Und ich würde behaupten, ohne diese Grundlage ist alles andere unwichtig.

Gleichwohl liegt der Unterschied zwischen einem lediglich kompetenten und einem wirklich erfolgreichen PM oft in seiner Sozialkompetenz.

Es gab lange Zeit eine Debatte in der Produktwelt darüber, ob diese sozialen Kompetenzen erfolgreich gelehrt oder durch Coaching übermittelt werden können. Meiner Erfahrung nach gilt für die meisten, wenn auch nicht für alle Menschen, dass man ihnen helfen kann, ihre Sozialkompetenzen signifikant zu verbessern und zu entwickeln. Aber sie müssen das wollen.

Wenn die Person keine große Sozialkompetenz besitzt und auch kein ernstgemeintes Interesse an einer Verbesserung zeigt, dann sollte der Manager dieser Person dabei helfen, einen geeigneteren Job zu finden.

Beim modernen Product Management dreht sich alles um die rund laufende Zusammenarbeit zwischen den Bereichen Produkt, Design und Technik. Es beginnt damit, sicherzustellen, dass der Product Manager gut über den eigentlichen Beitrag von Design und Technik unterrichtet ist.

Der PM muss selbst weder im Design noch in der Technik bewandert sein (die meisten sind es nicht, obwohl viele Product Manager glauben, dass sie großartige Designer sind), aber sie müssen deren Beiträge zu würdigen wissen, indem sie verstehen, dass das, was Design und Technik mit an den Tisch bringen, genauso essenziell wichtig ist wie das, was der PM mitbringt.

Als Nächstes muss der PM Beziehungen aufbauen, die für echte Zusammenarbeit nötig sind und die auf Vertrauen und gegenseitigem Respekt gründen.

In meinem Coaching von PMs hat das meiste, was ich tue, sobald das oben erläuterte Basiswissen erworben wurde, mit Zusammenarbeit zu tun.

Wenn ich mich mit einem Product Team zusammensetze, um über ein Problem zu reden, das es zu lösen versucht, verbringe ich selten Zeit nur mit dem PM. Fast immer sitze ich auch mit dem Product Designer und dem Tech Lead zusammen.

So ist einfach das Produktwesen heutzutage. Aber während dieser Sitzungen bin ich Zeuge zahlloser Interaktionen. Danach ziehe ich oft den PM beiseite und versuche darzulegen, was ich beobachtet habe im Hinblick auf sein Bemühen, Vertrauen aufzubauen. Wo waren seine Interaktionen während des Treffens hilfreich, wo kontraproduktiv?

Ein einstündiges Treffen, bei dem ein Problem oder eine Zielvorgabe diskutiert wird, ergibt gewöhnlich viele gute Beispiele, die ich als Coaching-Gelegenheit für den PM verwenden kann. Wie engagiert ist der Rest des Teams? Verhalten sich die Team-Mitglieder empowered , lösen sie also Probleme eigenverantwortlich, oder geben sie sich wie Befehlsempfänger? Bringen Designer und Entwickler mögliche Lösungen an den Tisch, oder legen sie nur Punkte dar, welche der PM eingebracht hat? Verbringen sie zu viel Zeit mit Reden (z. B. Planung) und nicht genug Zeit mit Versuchen (z. B. Prototyping)? Wie werden Meinungsverschiedenheiten gelöst?

Viele Punkte bezüglich der Teamarbeitsfähigkeiten gelten auch für die Fähigkeiten der Zusammenarbeit mit Stakeholdern, aber es ist tatsächlich einfacher, Vertrauen und Beziehungen zu den eigenen Teamkameraden aufzubauen (z. B. zu Designern oder Entwicklern), weil man mit ihnen jeden Tag interagiert – fokussiert darauf, das gemeinsame Problem zu lösen.