Stakeholder-Management: Die Kunst, Nein zu sagen

Eine gute Produktentwicklung erfordert die Identifizierung und Ausrichtung auf die magische Überschneidung zwischen Wünschbarkeit, Machbarkeit und Realisierbarkeit – wo Innovation lebt. Produktmanager sind ständig in der Position, das Gleichgewicht zwischen diesen Bereichen verteidigen zu müssen und den Kräften entgegenzuwirken, die darum konkurrieren, ein Produkt auf Kosten der anderen zu weit in eine Richtung zu ziehen. Das bedeutet, im Laufe der Produktentwicklungsreise oft und zu vielen Menschen Nein zu sagen.

Zu Beginn meiner Karriere arbeitete ich an einem Projekt im Automobilbereich und entwickelte eine App, die maschinelles Lernen nutzte, das durch Umgebungsdaten und Benutzerverhalten informiert wurde, um Fahrern intelligente Vorschläge zu machen. Als ich dem Team beitrat, stand die App kurz vor der Markteinführung und das Management wollte sie unbedingt veröffentlichen, aber mir wurde bald klar, dass sie noch lange nicht produktionsreif war.

Obwohl die App optisch ansprechend war, wurden einige der grundlegendsten Designfragen ignoriert, wie z. B. „Welches Problem lösen wir und für wen?“ und "Wie verzweifelt sind die Menschen, dass dieses Problem gelöst wird?"

Die App verfügt über eine Funktion, die das Wetter am Zielort des Fahrers anzeigt. Aus Benutzergewohnheiten und Verkehrsdaten konnte der Algorithmus ableiten, wohin ein Fahrer fahren könnte und wie lange es dauern würde, bis er dort ankommt, und eine einfache Wetter-API-Integration zeigte die Wettervorhersage für das Ziel zum Zeitpunkt der Ankunft. Dies schien ein netter Anwendungsfall zu sein, aber in Wirklichkeit kümmerte es niemanden. Als ich meine eigene Nutzerforschung durchführte, einschließlich einer bezahlten Umfrage unter europäischen Autofahrern, war die Antwort ein klares „Meh“. Das ist wohl das schlechteste Feedback, das Sie bekommen können: Es bedeutet, dass Ihr Produkt ein irrelevantes Problem gelöst hat, und zeigt an, dass die Dimension der Erwünschtheit extrem niedrig ist. Rentabilität ist dann eine verlorene Sache: Es ist unmöglich, ein rentables Geschäft mit einem Produkt aufzubauen, das niemand will. Wir mussten das Ganze verschrotten.

Wie konnte das passieren? Die Antwort ist kompliziert, aber sie läuft darauf hinaus, dass ein kritisches Wort nicht ausgesprochen wurde, wo es hätte lauten sollen: Nein.

Kernkompetenz und Assets des Unternehmens waren Inferenz-Engines für maschinelles Lernen und hochgradig skalierbares Architekturdesign. Der Leiter der Datenwissenschaft war ein mächtiger Interessenvertreter, der seine Inferenzmaschinen in einer Kundenanwendung sinnvoll einsetzen wollte. Sein Einfluss hatte zum Teil zu einem Produkt geführt, das vollständig technikzentriert war. Die Entwicklung wurde vom technologisch Machbaren getrieben, statt vom Kundenwunsch.

Es schien, dass niemand diesem Interessenvertreter nein gesagt hatte, und wenn sie es versucht hatten, war es nicht effektiv gewesen.

Produktstrategie heißt Nein sagen

Nein sagen ist schwer. Die Leute hören das Wort nicht immer gerne, und es besteht oft die Befürchtung, dass es wichtigen Beziehungen schaden könnte, wenn man es sagt. Als Produktmanager sind Beziehungen von zentraler Bedeutung für unsere Rolle, aber auch sicherzustellen, dass unsere Produkte erfolgreich sind und im Gleichgewicht bleiben.

Wie lehnen Sie also die Bitte von jemandem ab, während Sie die Beziehung intakt halten? Ich empfehle diese Praktiken:

• Stellen Sie sich auf Erfolg ein.
• Sag nicht zu schnell nein.
• Formulieren Sie die Anfrage neu.
• Fördern Sie ein Klima der Mitwirkung.

Setzen Sie auf Erfolg

Zu Beginn eines Projekts ist es wichtig, dass sich alle auf eine gemeinsame Vision für den Erfolg des Produkts („Warum machen wir das?“) und auf eine Reihe von Metriken einigen, die zur Messung des Fortschritts verwendet werden („Wie werden wir wissen wenn wir es gut machen?”). Wenn man sich nicht einig ist, wie Erfolg aussieht, ist es nur eine Frage der Zeit, bis es zu Konflikten kommt.

Es ist hilfreich, einen Rahmen zu verwenden, um Ziele zu dokumentieren und sie auf etwas Messbares abzubilden. Ich verwende gerne eine lose Version von Googles HEART-Framework, das die Benutzererfahrung in Kategorien für Zufriedenheit, Engagement, Akzeptanz, Bindung und Aufgabenerfolg organisiert und dann Ziele, Signale und Metriken für jede dieser Kategorien artikuliert. Ziele beziehen sich auf das, was Sie zu erreichen versuchen, Signale unterteilen jedes Ziel in Benutzeraktionen, und Metriken verfolgen diese Aktionen, um zu messen, wie Sie auf quantifizierbare Weise abschneiden.

Bei einem kürzlich durchgeführten Verbraucher-App-Projekt wollte ich ein begrenztes Pilotprojekt durchführen, um festzustellen, ob Benutzer unseren Prototyp nützlich fanden und weiterhin damit interagieren wollten. Ich habe mich hauptsächlich auf die Engagement-Kategorie des HEART-Frameworks konzentriert. Dann musste ich Signale und Metriken identifizieren, um den Fortschritt in Richtung dieses Ziels zu verfolgen:

• Ziel: Benutzer möchten mit der App interagieren und sie weiterhin verwenden.
• Signal: Benutzer öffnen die App häufig.
• Metrik: Prozentsatz der Benutzer, die die App mindestens zweimal am Tag öffnen.

Dieser Prozess der Identifizierung und Ausrichtung auf Ziele mag einfach erscheinen, ist aber nicht einfach. In diesem Fall waren es Gespräche mit dem Kunden und unserem Vertriebsteam, unabhängige Recherchen und mehrere Team-Workshops. Basierend auf den Informationen, die ich aus dieser Entdeckung gewonnen habe, konnte ich das fertige HEART-Framework während des Kickoff-Meetings mit dem Kunden präsentieren. Wir sind alle Punkte durchgegangen und haben bei Bedarf angepasst.

Es ist entscheidend, sicherzustellen, dass alle Beteiligten in den Zielsetzungsprozess einbezogen werden, und alle dazu zu bringen, sich darauf zu einigen, welche Signale und Metriken verfolgt werden müssen, eliminiert die Notwendigkeit, im Verlauf eines Projekts wiederholt Nein zu sagen. Es gibt Ihnen auch Daten, auf die Sie hinweisen können, wenn sich jemand mit einer Anfrage an Sie wendet, die außerhalb der Parameter des Plans liegt.

Sagen Sie nicht zu schnell nein

Selbst wenn sich die wichtigsten Stakeholder darüber einig sind, wie Erfolg aussieht, und der Weg in die Zukunft klar scheint, ist eines sicher: Jemand wird irgendwo mit einer unvorhergesehenen Frage auf Sie zukommen.

Sagen Sie in diesem Fall nicht zu schnell nein. Selbst wenn Sie sicher sind, dass die Anfrage unvernünftig ist, beendet eine direkte Ablehnung die Konversation und könnte die Beziehung beschädigen. Es untergräbt auch den Produktfindungsprozess. Als Produktmanager müssen wir das Gesamtbild sehen, und wenn wir Menschen zuhören, die nicht unserer Meinung sind, verringern wir unsere blinden Flecken.

Sie können natürlich immer noch nein sagen, aber Sie müssen reflexartige Reaktionen vermeiden. Diese führen zu binären Diskussionen, die das Ergebnis von Schwarz-Weiß-, Richtig-oder-Falsch-, Gewinn-oder-Verlust-Denken sind: Entweder man setzt etwas um oder man tut es nicht.

Um zu effektiveren, nuancierteren Diskussionen zu gelangen, müssen Sie Anfragen gemäß den vereinbarten Kriterien organisieren, die Sie als Teil Ihres Zielsetzungsprozesses festgelegt haben.

Anstatt einen Stakeholder zu fragen: „Ist diese Funktion für Sie wertvoll?“ Fragen Sie „Wie wertvoll ist diese Funktion für Sie?“ Das daraus resultierende Gespräch sollte Ihnen die Informationen liefern, die Sie benötigen, um an einer nach Wichtigkeit geordneten Liste von „Wünschen“ mitzuarbeiten. Es ist wichtig, dass diese Rangfolge von 1 bis n reicht, ohne dass mehrere Elemente denselben Platz in der Hierarchie einnehmen. Das gibt allen eine Stimme im Priorisierungsprozess und erspart Ihnen, Anfragen einseitig ablehnen zu müssen. Einige Anfragen bleiben auf der Strecke, wenn die Gruppe sie zugunsten wichtigerer herabstuft.

Formulieren Sie die Anfrage neu

Eine anfangs unvernünftig erscheinende Anfrage kann mit einer subtilen Überarbeitung zu positiven Ergebnissen führen. Hören Sie zunächst zu, was gesagt wird. Hören Sie wirklich zu. Legen Sie Ihre Annahmen beiseite und versuchen Sie zu verstehen, woher die andere Person kommt, und finden Sie dann Gemeinsamkeiten. Wenn Sie ein wenig tiefer graben, indem Sie „Warum“ fragen – nicht unbedingt die fünf Male, von denen Sie gehört haben; zwei bis drei reichen in der Regel aus – vielleicht entdecken Sie einen Faktor, der für ein gemeinsames Ziel spricht.

Sogar eine absolut vernünftige Anfrage kann von einem tieferen Eintauchen und etwas Reframing profitieren. Ich erinnere mich an eine Situation, in der ich an einem Business-Intelligence-Tool für einen B2B-Mobilitätsdienst gearbeitet habe. Mein Klient hat mich nicht unerwartet gebeten, die Abonnentenzahlen zu erhöhen. Während die Motivation für die Erhöhung der Anzahl zahlender Abonnenten offensichtlich erscheint, wollte ich sicherstellen, dass ich das vollständige Bild habe, also fragte ich: „Warum?“

Es stellte sich heraus, dass sich das fragliche Produkt dem Ende seines Lebenszyklus näherte und mein Mandant vor dem Ersatz durch ein neues Produkt den letzten Gewinn herausquetschen wollte. Mit diesen Informationen formulierte ich die Anfrage um: „Wie können wir den Umsatz kurzfristig erheblich steigern und gleichzeitig die Grundlagen für die bevorstehende Produkteinführung schaffen?“

Letztendlich bestand die beste Lösung darin, sich überhaupt nicht mit Abonnentenzahlen zu beschäftigen, sondern die Preisgestaltung besser am Wert auszurichten. Die Kunden zahlten ein festes monatliches Abonnement, unabhängig davon, wie oft sie das Tool für Fahrgasttransaktionen nutzten. Je mehr Reitertransaktionen sie jedoch verarbeiteten, desto mehr Wert schöpften sie aus dem Tool. Die Kunden reichten von einzelnen Taxifahrern, die nur eine Handvoll monatlicher Transaktionen tätigten, bis hin zu multinationalen Frachtunternehmen – mit Dutzenden von Tochtergesellschaften und Tausenden von Fahrzeugen – die Hunderttausende von monatlichen Transaktionen tätigten. Dasselbe feste monatliche Abonnement war für die kleinen Kunden zu hoch und für die großen zu niedrig.

Durch kleine Preisanpassungen haben wir den Umsatz gesteigert und gleichzeitig eine gestaffelte Preisstruktur (basierend auf der Anzahl der Transaktionen) für das in Kürze erscheinende Produkt eingeführt. Das neue Modell senkte den Preis für die meisten Kunden und erhöhte ihn für die größten Kunden, die überproportional davon profitiert hatten.

Indem Sie Anfragen auf diese Weise neu formulieren, können Sie Win-Win-Situationen schaffen. Die Person, die die Anfrage vorbringt, fühlt sich gehört und respektiert, und Sie gewinnen Erkenntnisse, die einen Mehrwert schaffen können, ohne den Produktentwicklungsprozess zu entgleisen.

Fördern Sie ein Klima des Beitrags

Eines der größten Risiken beim Neinsagen besteht darin, dass Ablehnungen den Geist der Offenheit und Zusammenarbeit untergraben können, den Sie sowohl innerhalb als auch außerhalb Ihres Teams zu fördern versuchen. Ideen inspirieren, unabhängig davon, ob sie relevant werden oder nicht, und das Letzte, was Sie tun möchten, ist, den Fluss von Kreativität und Kommunikation aufzuhalten.

Ich habe einmal mit einem jungen QA-Ingenieur zusammengearbeitet, der eine Fülle von Ideen hatte. Bei fast jedem Treffen stellte er mehrere Fragen und machte freiwillig Vorschläge. Seine Lösungen waren oft nicht umsetzbar, und einige von ihnen hätten als nicht hilfreich oder irrelevant abgetan werden können. Aber sein Engagement und seine Begeisterung waren von unschätzbarem Wert. Er war voll und ganz darauf bedacht, das bestmögliche Produkt zu liefern, und seine Beiträge regten andere an und inspirierten sie. So eine Einstellung ist ansteckend.

Sie möchten eine Umgebung schaffen, in der sich Menschen ermutigt fühlen, Gedanken und Ideen auszutauschen, und dafür belohnt werden. Ihr Team sollte durch die Möglichkeit, Dinge zu verbessern, motiviert werden, anstatt durch den Gedanken entmutigt zu werden, entlassen, ignoriert oder lächerlich gemacht zu werden. Die Implementierung einiger einfacher Praktiken kann dazu beitragen, die psychologische Sicherheit Ihres Teams zu gewährleisten.

Erkennen Sie Ideen und Anfragen öffentlich an. Das schafft Vertrauen und zeigt, dass Sie Vorschläge wertschätzen und bereit sind, sie zu berücksichtigen. Richten Sie eine Anfragebox, eine Confluence-Seite oder ein anderes öffentliches Forum ein, auf das alle Beteiligten zugreifen können. Wenn eine Anfrage eingeht, protokollieren Sie sie und senden Sie eine Nachricht an den Anfragenden, in der Sie ihm für seinen Beitrag danken.

Ich weiß, dass dies kontrovers sein kann, aber ich gehe manchmal so weit, das Produkt-Backlog für alle zu öffnen. Dies kann besonders hilfreich sein, um das Engagement des Produktteams zu fördern und es Teammitgliedern wie QA-Testern und Designern zu ermöglichen, Dinge zu notieren, auf die sie gestoßen sind. Die Regeln sind einfach: Jeder kann am Ende des Backlogs etwas hinzufügen, und während der Verfeinerungen (oder anderen wöchentlichen Meetings) teilen die Teammitglieder, was sie hinzugefügt haben, und erklären, warum. Nur der Produktmanager kann die Reihenfolge der Ausgaben ändern oder Artikel löschen. Viele Leute gehen davon aus, dass es zu Chaos und Anarchie führen wird, jedem diese Zugriffsebene zu gewähren, aber das ist nicht der Fall. Ich habe das bei Organisationen unterschiedlicher Größe ausprobiert und es scheitert nur, wenn die Leute zu schüchtern sind, ihre Ideen einzubringen.

Sobald Sie eine Lösung implementiert oder eine Funktion veröffentlicht haben, die auch nur grob mit einer dieser protokollierten Anfragen zusammenhängt, würdigen Sie den Anforderer öffentlich. Dies ist besonders wichtig, wenn die Lösung keine klare Erfüllung der ursprünglichen Anfrage ist, sondern eher eine umformulierte Version. Wertschätzung für alle zu zeigen, die an einem Erfolg beteiligt sind, schafft Wohlwollen, baut Kameradschaft auf und ermutigt die Menschen, sich weiterhin zu beteiligen.

Abwägen der Vor- und Nachteile des Nein-Sagens

Wenn Sie sich die Zeit nehmen, wirklich zuzuhören und zu verstehen, woher die Interessengruppen kommen, müssen Sie Vorschläge selten direkt ablehnen. Aktives Zuhören, transparente Kommunikation und gegenseitiger Respekt sind wichtige Bestandteile bei der Bearbeitung von Anfragen, die zunächst problematisch oder unangemessen erscheinen. Meistens besteht die Kunst des Nein-Sagens nie darin, wirklich „Nein“ zu sagen.

Es wird Situationen geben, in denen es unmöglich ist, einen gemeinsamen Nenner zu finden, und ein direktes Nein erforderlich ist, um das Produkt und das Projekt zu schützen. In anderen Fällen könnten Sie gezwungen sein, Dinge durchzuziehen, mit denen Sie nicht einverstanden sind. So sehr Ihre Aufgabe darin besteht, das Gleichgewicht zwischen Wünschbarkeit, Machbarkeit und Durchführbarkeit zu wahren, gibt es eine vierte Dimension zu berücksichtigen: Pragmatismus. Um die Dinge voranzubringen, sind Kompromisse der Schlüssel, und manchmal bedeutet das, ein Nein ganz zu vermeiden.

Das Schöne an der agilen Produktentwicklung ist, dass ihr iterativer Charakter viele Möglichkeiten zur Kurskorrektur bietet. Schließlich ist das Ziel Bauen-Messen-Lernen, nicht Diskutieren-Streiten-Entgleisen.