Lerne "Nein" zu sagen als Product Owner

**Nein sagen, kann äußerst schwierig sein. Die meisten von uns wollen andere Menschen zufriedenstellen. Wenn wir aber „Nein” sagen, enttäuschen wir denjenigen, der uns um etwas gebeten hat.

Nein zu sagen, ist jedoch ein wichtiger Teil des Jobs eines jeden Product Owners. Der Product Owner hat die Aufgabe, den Wert eines zu liefernden Produkts zu optimieren, und zwar indem er nicht zu jedem Wunsch eines Kunden Ja sagt.**

Jedes Mal, wenn ein Product Owner dem Wunsch für ein Feature nachgibt, muss er zu einem anderen Kundenwunsch in der Zukunft Nein sagen. Die Zeit des Teams ist begrenzt und jedes Ja heute bedeutet, Nein zu einer Gelegenheit in der Zukunft sagen zu müssen.

Daher ist das Nein-Sagen eine Fähigkeit, die jeder Product Owner lernen muss.

Ich möchte Ihnen sechs Richtlinien vorstellen, mit deren Hilfe Sie es schaffen, bestimmt aber höflich Nein zu sagen:

1) Klarheit schaffen: Ist es ein endgültiges Nein? Oder nur ein Nein für den Moment?

Wenn Product Owner den Stakeholdern mitteilen, dass sie ein gewünschtes Feature nicht in die Priorisierung aufnehmen, sollten sie Klarheit schaffen, was ihr Nein genau bedeutet.

Wenn Sie sich sicher sind, dass Sie das Team niemals an diesem Feature arbeiten lassen werden, wecken Sie keine falschen Hoffnungen, indem Sie den Stakeholder ermutigen, Sie zu einem späteren Zeitpunkt noch einmal auf das Feature anzusprechen. Das ist nur Zeitverschwendung und frustrierend, wenn man immer wieder ein Feature ablehnen muss, dass man ohnehin niemals umsetzen wird.

Wenn Sie jedoch glauben, dass Sie das Feature zu einem späteren Zeitpunkt aufnehmen können und das Nein nur für diesen Moment gilt, dann erklären Sie das den Stakeholdern auch genau so. Ein Beispiel:

Es tut mir leid, aber im Moment können wir nicht daran arbeiten. Glauben Sie mir, ich wünschte, wir könnten es. Allerdings haben wir schon ein Commitment für XY abgegeben, woran wir bis August arbeiten. Das Team muss sich jetzt auf dieses Commitment konzentrieren, sonst sind wir vielleicht nicht in der Lage, es zu liefern. Wenn Sie mich aber im August noch einmal daran erinnern, verspreche ich, dass wir Ihren Wunsch in Betracht ziehen.

Bitte achten Sie wie in diesem Beispiel darauf, nicht zu versprechen, das Feature später auf jeden Fall umzusetzen, sondern nur, es später noch einmal in Erwägung zu ziehen.

Achten Sie außerdem darauf, dem Stakeholder oder Kunden die Verpflichtung zukommen zu lassen, erneut ihre Anfrage zu stellen bzw. Sie daran zu erinnern, wenn der Zeitpunkt besser ist. Ich tue dies bewusst, um sicher sein zu können, dass ihnen dieses bestimmte Feature auch wirklich wichtig genug ist. Wenn ein Stakeholder Sie nicht wieder auf das Feature anspricht, bezweifle ich, dass es überhaupt so dringend oder wichtig war.

Aber am wichtigsten ist es, den Stakeholder nicht in dem Glauben zu lassen, dass er tatsächlich in einem Monat noch einmal nach dem Feature fragen kann, wenn Sie es in Wirklichkeit ohnehin nicht umsetzen wollen.

2) Wertschätzung und Empathie für die Kunden ausdrücken

Wenn ein Stakeholder einen Wunsch für ein Feature äußert, sollte der Product Owner dem Stakeholder immer dafür danken und bestätigen, dass er versteht, warum dem Stakeholder das Feature wichtig ist.

Jemand hat sich die Zeit genommen, das Team um etwas zu bitten. Das bedeutet, dass sich diese Person für Ihr Produkt interessiert. Lassen Sie den Kunden wissen, dass Sie es zu schätzen wissen, dass er sich die Zeit genommen hat, danach zu fragen. Etwas in der Art dieses Beispiels reicht völlig aus:

Vielen Dank. Ich weiß es zu schätzen, dass Sie sich Gedanken darum machen, wie unser Produkt noch besser werden kann.

Zusätzlich zu dieser Demonstration von Wertschätzung sollten Product Owner auch Empathie für die Situation des Stakeholders zeigen. Sie sind dabei, etwas abzulehnen, was dem Stakeholder höchstwahrscheinlich sehr wichtig ist. Das Feature soll – zumindest in den Augen des Stakeholders – die von seinem Vorgesetzten vorgegebenen Ziele erfüllen und hat eventuelle sogar finanzielle Auswirkungen.

Zuallererst sollten Sie jedoch versuchen, zu verstehen, warum das Feature so wichtig für den Kunden ist. Sie sollten den Wunsch erst ablehnen, wenn Sie wirklich verstanden haben, warum er dem Stakeholder so wichtig ist.

Ihr Mitgefühl können Sie beispielsweise mit folgender Aussage demonstrieren:

Ich verstehe, dass Ihnen dieses Feature so wichtig ist, um XY zu erreichen.

Aber seien Sie dabei immer aufrichtig. Ich glaube, ich bin nicht der einzige Mensch, der falsches Mitgefühl nicht mag!

3) Nur eine einzige Begründung für Ihr Nein nennen

Wenn man als Product Owner einen Feature-Wunsch ablehnt, ist es besser, eine gute Begründung zu nennen als eine ganze Reihe von Gründen. Menschen neigen dazu, sich bei mehreren Gründen den schwächsten herauszupicken und dagegen zu argumentieren. Hier ein Beispiel:

Stellen Sie sich vor, ich wäre Ihr Kunde und würde Sie bitten, dass Ihr Team die aktuelle Arbeit zugunsten eines von mir gewünschten Features zurückstellen soll. Sie könnten mir z.B. Folgendes sagen:

"Es tut mir leid, aber das geht nicht. Wir haben diesen Sprint schon geplant. Ich müsste ein neues Planning Meeting mit dem Team ansetzen und das werden sie nicht gut finden. Außerdem bin ich mir sicher, dass die aktuellen Arbeiten gerade eine höhere Priorität haben."

Was glauben Sie, welches Argument ich versuchen würde, anzugreifen? Die Notwendigkeit für ein erneutes Planning Meeting oder die Tatsache, dass die aktuelle Arbeit Priorität hat?

Ich würde mir das Argument herauspicken, dass ein weiteres Planning Meeting nötig wäre und das Team das nicht gut finden würde. Ich würde unter Umständen anbieten, das Meeting weniger unangenehm zu gestalten, indem man es in die Mittagspause legt und ich allen Pizza spendiere.

Auch wenn Sie meinen Plan immer noch nicht mögen, habe ich soeben den Fokus der Konversation verändert: Statt über das Feature sprechen wir nun über die Durchführung eines Meetings. Gegen dieses Argument muss man erst einmal ankommen.

Außerdem ist es die falsche Basis, um diese Entscheidung zu treffen.

Bleiben Sie standhaft und nennen Sie den triftigsten Grund dafür, das Feature abzulehnen. Wenn der Stakeholder es schafft, Sie umzustimmen, sollten Sie überlegen, ob Ihre weiteren Argumente stark genug sind, um ein Nein zu rechtfertigen. Wenn nicht, sollten Sie dem Wunsch vielleicht nachgeben.

4) Wir haben das gleiche Ziel

Wenn der Product Owner und der Stakeholder das gleiche übergeordnete Ziel verfolgen, sollte der Product Owner dies erwähnen, wenn er unerwünschte Neuigkeiten äußert.

Product Owner und Stakeholder haben häufig ganz unterschiedliche Ziele. Und ja, manchmal stehen sie in Konflikt. Allerdings gibt es normalerweise auch ein übergeordnetes produktbezogenes Ziel, das man teilt und auf das man sich beziehen kann. Beispiel für ein übergeordnetes Ziel?

Besonders einfach ist dies, wenn beide Parteien im gleichen Unternehmen arbeiten. In diesem Fall kann man sagen:

"So gerne ich das Team daran arbeiten lassen würde, wir müssen uns jetzt wirklich auf [übergeordnetes gemeinsames Ziel] konzentrieren."

"Wie Sie sicher wissen, haben wir alle das gleiche Ziel, nämlich [übergeordnetes gemeinsames Ziel]."

Indem Sie den Kunden daran erinnern, dass Sie ein gemeinsames Ziel haben, machen Sie es ihm leichter, zu verstehen, warum Sie seinen Wunsch ablehnen, selbst wenn er immer noch nicht zu 100% mit Ihrer Antwort einverstanden ist.

5) Erklären Sie dem Stakeholder die Konsequenzen

Wenn man den Wunsch eines Stakeholders zurückweist, sollte man als Product Owner die Konsequenzen erklären, die es hätte, wenn man dem Wunsch nachgeben würde.

Es hilft dem Stakeholder, zu verstehen, warum Sie sich gezwungen sehen, Nein zu sagen. Sie könnten beispielsweise sagen:

"Das Team macht bereits Überstunden. Ich könnte das Feature nicht noch zu deren Arbeit hinzufügen, ohne etwas anderes herauszunehmen, dass wir jemand anderem bereits versprochen haben."

"Wenn wir statt der anderen Arbeiten an Ihrem Feature arbeiten würden, könnten wir die Frist nicht einhalten."

Die Folgen zu erklären, wird dem Stakeholder helfen, Ihre Entscheidung nachzuvollziehen und Empathie dafür zu entwickeln, weshalb Sie seinen Wunsch abgelehnt haben.

6) Bieten Sie eine Alternative

Statt einen Kundenwunsch einfach nur abzulehnen, kann ein Product Owner vielleicht auch eine Alternative anbieten.

Das könnte folgendermaßen aussehen:

"Wir können auf keinen Fall alles machen, was Sie sich vorgestellt haben, aber wie wäre es, wenn wir erst mal einen Teil davon umsetzen?"

"Ich kann das Team jetzt auf keinen Fall daran arbeiten lassen, aber wie wäre es, wenn wir in drei Wochen damit anfangen?"

Aber Vorsicht: Bieten Sie nur einen solchen Kompromiss an, wenn Sie es auch wirklich so meinen.

Keine Angst vor dem "Nein" sagen

Product Owner haben oft Angst davor, Nein zu sagen und den Stakeholder oder Kunden damit zu enttäuschen. Aber einen Wunsch abzuschlagen muss nicht schwer sein.

Ich habe herausgefunden, dass es viel leichter ist, Nein zu sagen, wenn man

• Klarheit schafft,

• einen guten Grund statt vielen angibt,

• empathisch und dankbar ist,

• auf das gemeinsame Ziel hinweist,

• die Konsequenzen eines Ja erläutert und

• eine Alternative anbietet.

Wenn es gut gemacht wird, kann ein Nein die Beziehung zwischen Product Owner und Stakeholder sogar verbessern statt verschlechtern! Weitere Möglichkeiten der Kommunikation mit Stakeholdern gibt es zudem in unseren Trainings. Im Certified Scrum Product Owner Training, werden verschiedene Ansätze und Möglichkeiten der Kommunikation erläutert und praktisch angewendet.

Dieser Beitrag stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.