Skip to main content

Diese 3 Fehler ruinieren dein Stakeholder-Management – machst du sie auch?

March 17, 2025

Lass uns gleich zum Punkt kommen:

Stakeholder-Management ist eine der wichtigsten Fähigkeiten von Scrum Teams. Mehr noch: Je besser Product-Owner ihr Stakeholder-Management beherrschen, desto erfolgreicher wird das Team sein. Davon bin ich überzeugt. Warum? Nach 10 Jahren in Scrum Teams weiß ich nur zu gut, was passiert, wenn Fehler im Management der Stakeholder begangen werden. Du kennst die Auswirkungen bestimmt auch: Es kommt zu Konflikten und die Zusammenarbeit über die Grenzen des Teams hinweg leidet.

Heute will ich dir von drei solchen Fehlern berichten – in der Hoffnung, dass du sie vermeidest:

Fehler #1: Stakeholder-Management bedeutet für dich, Product-Roadmaps zu erstellen

Was kommt dir bei Stakeholder-Management in den Sinn?

99 Prozent meiner Leser denken erst mal an Stakeholder-Matrizen, Product-Roadmaps, Story-Maps, Gantt-Charts und Deadlines. Du auch? In der heutigen Welt, mit all unserer Technologie und all den Tools, lässt sich schnell vergessen, woher der Ausdruck „Management“ in Stakeholder-Management kommt. Das Wort geht auf das lateinische manus („Hand“) zurück. Daraus entstand das Verb manuāre, was so viel bedeutet wie „führen, mit der Hand lenken“. Wie führen oder lenken wir in unserer modernen Arbeitswelt?

Durch Worte.

Und nicht mehr mit der Hand. Wir führen durch die Dinge, die wir sagen, und durch die Art und Weise, wie wir sie sagen. Es geht doch eigentlich ums Überzeugen. Möchtest du als Product-Owner deine Stakeholder besser managen? Dann investiere deine Zeit nicht darin, bessere Roadmaps zu erstellen, sondern darin, wieder mit Worten zu überzeugen. Lerne Rhetorik. Nach Aristoteles ist Rhetorik die Kunst, in jeder Situation das überzeugendste Argument zu finden. Was meine ich damit?

Stell dir vor, du wärst Anwalt.

Vielleicht bist du Saul Goodman aus „Better Call Saul“, Jack McCoy aus „Law & Order“ oder Alicia Florrick aus „The Good Wife“. Dein Mandant ist Johan. Und Johan wurde beim Klauen im Aldi erwischt. Da es nicht das erste Mal war, findest du dich mit ihm im Gerichtssaal wieder.

Da die Videoüberwachung eindeutig zeigt, wie Johan stiehlt, gibt es keinen Zweifel an seiner Schuld. Die einzige offene Frage ist das Strafmaß. Nun bist du dran: Verteidige ihn. Welche Argumente kannst du für Johan vorbringen, die sein Strafmaß mindern könnten?

Mir fallen diese Punkte ein:

  • Johan hatte eine schlimme Kindheit. Er wurde mehrfach von seinem Vater misshandelt.
  • Johan gelobt Besserung und engagiert sich seit dem Vorfall in einem Heim für junge Obdachlose. Der Leiter des Heims lobt Johans Arbeit in den höchsten Tönen.
  • Johan hat sich persönlich beim Leiter der Aldi-Filiale entschuldigt.

Haben diese Argumente die Wirkung, dass sich die Richterin in Johan hineinversetzen und besser verstehen wird, warum er sich falsch verhalten hat? Glaubst du, dass die Richterin das Strafmaß aufgrund dieser Argumente reduzieren wird?

Ich glaube, schon.

Was können wir von diesem Beispiel für Stakeholder-Management lernen? Ob es um die Reduzierung des Strafmaßes oder um die Erhöhung des Jahresbudgets geht – je überzeugendere Argumente du vorlegen kannst, desto erfolgreicher wirst du sein.

Wenn du die Stakeholder deines Produkts managen willst, dann denke wie ein Anwalt im Gerichtssaal.

Fehler #2: Du denkst, Stakeholder lassen sich von Behauptungen überzeugen

Stakeholder-Management findet nicht im Gerichtssaal statt.

Das hoffe ich zumindest für dich.

Deshalb braucht es beim Stakeholder-Management andere Beweise als vor Gericht. Beim Stakeholder-Management bedienen wir uns der Beweise, die wir mithilfe von Aktivitäten des Produktmanagements sammeln.

Daraus ergibt sich eine Vielzahl von Beweisen, aber nicht alle sind gleich glaubwürdig. Welchen wir mehr Aufmerksamkeit schenken sollten, lässt sich mit dem „Confidence Meter“ von Itamar Gilad beschreiben. Itamar Gilad bekleidete in den letzten zwanzig Jahren mehrere Senior-Produktmanagement-Positionen, unter anderem bei Google und Microsoft.

Hier sein „Vertrauensmesser“ im Überblick:

  • Keine Beweiskraft: Selbstüberzeugung und thematische Unterstützung. Mit thematischer Unterstützung sind Vision oder Strategie, aktuelle Trends oder Buzzwords, externe Umfragen, Makrotrends und Produktmethodik gemeint.
  • Geringe Beweiskraft: Hier führt Itamar die Meinung anderer an. Zum Beispiel: Das Team, das Management, externe Experten, Investoren oder die Presse halten etwas für eine gute Idee. Geringe Nachweise liefern auch Schätzungen und Pläne, z. B. Entwicklungs- oder UX-Machbarkeitsbewertungen, Roadmaps oder Zeitpläne für das Projekt sowie das Geschäftsmodell.
  • Geringe bis mittlere Beweiskraft: Hier geht es um anekdotische Beweise. Zum Beispiel, dass eine Behauptung durch einige Produktdaten, Top-Verkaufsanfragen, 1 bis 3 interessierte Kunden oder den Hinweis: „Ein Mitbewerber hat es …“, gestützt wird. In diese Kategorie fallen auch Marktdaten, die durch Umfragen, Smoke-Tests oder Wettbewerbsanalysen erhoben wurden.
  • Mittlere Beweiskraft: Diese Beweiskraft ergibt sich erst aus Benutzer- oder Kundennachweisen. Als Beispiele nennt Itamar viele Produktdaten, Top-Benutzeranforderungen, Interviews mit 20+ Benutzern, Usability-Studien oder Rückmeldungen zu MVPs. Etwas höhere Beweiskraft liefern Tests, beispielsweise Langzeit-Nutzerstudien, groß angelegte MVPs, Alpha-/Beta-Releases oder A/B-Experimente.
  • Die höchste Beweiskraft liefern nur die Daten nach der Markteinführung. Im Produktmanagement nennen wir dies auch „Launch Data“.

Wie du sehen kannst, gibt es sehr unterschiedliche Beweise dafür, wie sehr wir einer Idee vertrauen sollten.

Nicht nur wir selbst werden diesen Hinweisen unterschiedlich viel Glauben schenken, sondern auch deine Stakeholder. Willst du deine Stakeholder also für deine Ideen gewinnen, dann bedeutet das, glaubhafte Beweise zu finden. Ähnlich wie ein Anwalt, der mit Zeugen spricht, Protokolle auswertet und sich durch Berge von Akten wühlt, müssen Product-Owner Nutzer und Kunden befragen, Usability-Studien beauftragen und A/B-Experimente durchführen, um dann – vielleicht nicht vor Gericht, aber vor ihren Stakeholdern – zu argumentieren, welcher Idee sie folgen sollten.

Diese Suche nach Beweisen, dass eine Idee die richtige ist, nennen wir im Produktmanagement Entdeckung und Validierung.

Wenn du darüber mehr erfahren willst, dann empfehle ich dir den Besuch der „Professional Product Discovery and Validation“-Schulungen. Boris Steiner und ich helfen dir hands-on, wie du Entdeckung und Validierung auch in deinem Team umsetzen kannst – also wie du Beweise findest, um die Stakeholder von deinen Ideen zu überzeugen.

Fehler #3: Du stellst Stakeholder vor die falsche Wahl

Eine Warnung:

Baruch Fischhoff, Professor an der Carnegie Mellon University, hat mit seinen Kollegen 105 Mädchen im Teenageralter befragt, welche Entscheidungen sie in letzter Zeit getroffen haben. Dabei fiel ihm auf, dass viele ihrer Entscheidungen keine echten Wahlmöglichkeiten beinhaltet hatten.

Er nannte diese Art von Entscheidung „ob- oder ob-nicht“-Entscheidung. Beispiel: „Gehe ich heute zur Schule oder nicht?“ Das Problem?

Diese Entscheidungen schränken die Perspektive stark ein. Andere Optionen werden gar nicht erst in Erwägung gezogen.

Wollen wir Stakeholder von Ideen überzeugen, sollten wir sie nicht vor eine „ob- oder ob-nicht“-Entscheidung stellen. Die Frage sollte nicht lauten, ob ein Feature umgesetzt wird, sondern, welches Feature umgesetzt wird.

Das ist auch der Unterschied zwischen einer Product-Roadmap und einem Product-Backlog:

Das Product-Backlog hilft uns, Vergleichsentscheidungen zu treffen – also die Option mit dem meisten Wert auszuwählen. Eine Product-Roadmap beraubt uns dieser Möglichkeit. Hier wurde bereits entschieden, „ob oder ob nicht“ etwas entwickelt wird.

Willst du weniger Konflikte und mehr Zusammenarbeit mit deinen Stakeholdern?

Dann stürze dich nicht auf das nächste Tool.

Sondern investiere deine Zeit darin, die Grundlagen der Überzeugung zu lernen. Hier fünf Bereiche, die ich dir ans Herz legen möchte:

Willst du deine Stakeholder-Management-Fähigkeiten nicht im Eigenstudium verbessern? Dann empfehle ich dir den Besuch des „Professional Scrum Product Owner – Advanced“-Trainings.

Dort geben dir Peter und ich nicht nur viele Techniken und Vorgehensweise an die Hand, sondern setzen sie direkt mit dir um.  

Über 205 Product Owner sind in den letzten Jahren unserer Empfehlung bereits gefolgt.


What did you think about this post?