Produktmanagement in der Praxis, 2. Auflage

Kapitel 4. Die Kunst der ungeheuerlichen Überkommunikation

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Der Titel dieses Kapitels ist in vielerlei Hinsicht ein Witz. Aber für arbeitende Produktmanager ist er auch tödlich ernst. Die größten Fehler, die ich als Produktmanager gemacht habe, und die größten Fehler, von denen ich von vielen anderen Produktmanagern gehört habe, bestehen darin, Dinge nicht zu kommunizieren, die entweder zu politisch gefährlich oder zu unbedeutend erscheinen, um sie offen anzusprechen.

Manchmal können Dinge sowohl gefährlich als auch unbedeutend erscheinen. Stell dir zum Beispiel vor, du sitzt in einer Besprechung mit deinem Team und ein Entwickler rattert ein Detail über ein Produkt herunter, das sich nur geringfügig von dem unterscheidet, was du in einem anderen Gespräch mit der Geschäftsführung besprochen hast. Du fängst an, auf deinem Platz zu zappeln. Du bist dir ziemlich sicher, dass sich der Entwickler in deinem Team nur falsch ausgedrückt hat. Schließlich hat dein Team an denselben Produktspezifikationen gearbeitet, die du mit der Geschäftsführung besprochen hast. Auf jeden Fall ist es nur ein kleiner Unterschied. Und das Letzte, was du in diesem Moment tun willst, ist, das Gespräch zu unterbrechen, einen Entwickler in deinem eigenen Team in eine unangenehme Lage zu bringen und die Aufmerksamkeit auf deine eigenen möglichen Fehler zu lenken. Es ist nur eine Kleinigkeit. Niemand wird es bemerken. Es würde keinen Sinn machen, wenn es sich als eine große Sache herausstellen würde! Das ist schon in Ordnung.

Schnitt zu zwei Wochen später. Dein Team stellt das Produkt vor, und ein Mitglied des Führungsteams macht ein säuerliches Gesicht. Ihre Nase rümpft sich und ihre Augen verengen sich. Sie spricht die Worte "Was ist das?" so deutlich aus, dass dein Herz stehen bleibt. Sie schüttelt den Kopf hin und her und unterbricht deinen Entwickler mitten im Satz: "Es tut mir leid, aber das sieht ganz anders aus als das, was ich unterschrieben habe. Ich bin im Moment sehr verwirrt." Dein Team bleibt wie angewurzelt stehen. Alle Augen richten sich auf dich. Nachdem die Reihe von Schimpfwörtern in deinem Kopf zu Ende ist, sagst du dir: "Du hattest Angst, dass es eine große Sache ist, es ist eine große Sache und jetzt ist es zu spät.

Für die meisten arbeitenden Produktmanager ist dieses Szenario nicht hypothetisch. Es passiert ständig, und es passiert immer wieder, auch wenn du dir eine Million Mal schwörst, dass du es nie wieder zulassen wirst. Der potenzielle Nachteil von Unterkommunikation ist riesig und erschreckend. Der potenzielle Nachteil von Überkommunikation ist realistischerweise ein Augenrollen und vielleicht ein paar bissige Kommentare. Da du nie genau wissen kannst, wie viel Kommunikation in einer bestimmten Situation erforderlich ist, ist es immer besser, zu viel zu kommunizieren. Zumindest in der Theorie ist das eine einfache Sache.

In der Praxis kann sich die alltägliche Arbeit einer umfassenden Kommunikation jedoch als sehr schwierig erweisen. Die Entscheidung, im Moment zu kommunizieren, ist viel schwieriger als die Entscheidung, abstrakt zu kommunizieren. In diesem Kapitel findest du einige taktische Hinweise, wie du die ungeheuerliche Überkommunikation zu einem Teil deiner Produktmanagementpraxis machen kannst.

Die Frage nach dem Offensichtlichen

Wenn es so etwas wie Zehn Gebote für das Produktmanagement gibt, dann ist es Ben Horowitz' "Good Product Manager/Bad Product Manager", ein Dokument, das Horowitz als eine Art Ad-hoc-Schulung für die Produktmanager von Netscape verfasst hat, damals in den Tagen des ersten Internet-Booms. "Good Product Manager/Bad Product Manager" ist ein kurzes und einfaches Dokument, das aber etwas sehr Wichtiges bewirkt: Es legt in außergewöhnlich klaren Worten die täglichen Erwartungen an Produktmanager in diesem bestimmten Unternehmen zu dieser bestimmten Zeit fest. "Tu dies, nicht das." Jedes Unternehmen sollte ein Dokument wie "Good Product Manager/Bad Product Manager" haben, in dem die Aufgaben des Jobs in klaren, lehrreichen und verhaltensorientierten Worten dargelegt werden - und in dem ausdrücklich die Verhaltensweisen genannt werden, die zu vermeiden sind.

Meine Lieblingsstelle in "Good Product Manager/Bad Product Manager" besagt ganz einfach: "Gute Produktmanager entscheiden sich für Klarheit, anstatt das Offensichtliche zu erklären. Schlechte Produktmanager erklären nie das Offensichtliche."

Als ich anfing, als Produktmanagerin zu arbeiten, habe ich mich gefragt, was das genau bedeutet - warum ist es wichtig, "das Offensichtliche" zu erklären? Es stellte sich heraus, dass die Dinge, die dir offensichtlich erscheinen, für andere vielleicht nicht offensichtlich sind. Tatsächlich könnten andere Menschen ganz andere Schlussfolgerungen gezogen haben, die ihnen genauso "offensichtlich" erscheinen. Aus diesem Grund bergen die Dinge, die offensichtlich erscheinen, oft das größte Potenzial für katastrophale Missverständnisse.

Die erste Person zu sein, die etwas in Frage stellt, das offensichtlich oder selbsterklärend scheint, kann sich sehr unangenehm anfühlen. Es erfordert Mut, sich einzumischen und zum Beispiel zu sagen: "Nur um sicherzugehen, dass wir alle auf der gleichen Seite stehen, wenn wir nächste Woche über das 'Startdatum' sprechen, ist unser aktueller Plan, eine kleine, geschlossene Betaversion mit einer Gruppe von etwa fünfzig Nutzern zu starten, damit wir einige Daten sammeln können, bevor wir irgendetwas für eine breitere Gruppe einführen." Selbst wenn die Antwort, die du erhältst, ein einheitlicher Chor von "Ja, natürlich, das wussten wir alle" ist, garantiere ich dir, dass mindestens eine andere Person im Stillen denkt: "Puh, ich bin wirklich froh, dass sich jemand zu Wort gemeldet hat, denn das habe ich definitiv nicht gewusst."

Wenn wir uns an den Geschäfts- und Nutzerzielen unseres Teams orientieren, erscheint der Vorteil, das Offensichtliche zu fragen,... nun ja, offensichtlich. Wenn sich herausstellt, dass alle von vornherein auf einer Linie waren, können wir mit noch größerer Sicherheit in unserem gemeinsamen Verständnis vorankommen. Und wenn sich herausstellt, dass nicht alle an einem Strang gezogen haben, können wir alle Missverständnisse offen ansprechen, bevor sie zu einem viel größeren Problem werden.

Unbequeme Informationen in ein großes Meeting einbringen

Julia G.

Senior Produktmanager, mittelständisches Startup

Vor ein paar Jahren saß ich in einer großen Besprechung mit etwa 50 meiner Kollegen, die mit dem Markt zu tun hatten: unser gesamtes Führungsteam für Vertrieb, Kundenerfolg und Marketing. Während des Meetings wurde eine Frage zu einer bestimmten Funktion aufgeworfen, die sich unsere Kunden gewünscht hatten. Unser CEO meldete sich in unserem Firmen-Chat zu Wort, um uns mitzuteilen, dass wir vor kurzem genau diese Funktion ausgeliefert hatten, und um uns zu ermutigen, sie weiterzugeben.

Es gab nur ein Problem: Diese Funktion war für einige unserer Kanäle bereits verfügbar, aber nicht für den Kanal, den wir gerade besprachen. Das war ein großer "Oh-oh"-Moment: Sollte ich mich in dieser großen Besprechung einmischen und darauf hinweisen, dass diese Funktion - die gerade von unserem CEO gefeiert worden war - für die Kunden, die danach fragten, noch nicht fertig war?

Da ich in der Vergangenheit die Konsequenzen erlebt habe, wenn ich diese Dinge nicht angesprochen habe, habe ich mich entschlossen, es zu sagen: "Eigentlich ist diese Funktion auf diesem Kanal noch nicht live, aber wir haben sie für das vierte Quartal geplant." Schweigen. War ich dabei, Ärger zu bekommen? Und dann kam eine neue Nachricht von unserem CEO im Firmen-Chat: "Okay, super, danke für die Info."

In diesem Moment fühlte ich ein Maß an Sicherheit, das ich als Produktmanagerin noch nie zuvor verspürt hatte. Ich war erst vor kurzem zu diesem Unternehmen gekommen, nachdem ich in einer Reihe von Start-ups gearbeitet hatte, in denen oft "gestern" etwas erwartet wurde. Ich hatte eine Tendenz entwickelt, jede Frage als Vorwurf zu verstehen. Wenn mich jemand fragte: "Hey, unterstützen wir das?" hörte ich es als "Warum unterstützen wir das noch nicht?" Ich wollte den Erwartungen immer voraus sein, und wenn jemand auch nur eine Frage stellte, fühlte ich mich, als hätte ich bereits versagt. Den Geschäftsführer mitten in einer großen Besprechung darüber zu informieren, dass eine Funktion noch nicht fertig war, fühlte sich definitiv riskant an. Seine Antwort gab mir das Gefühl, dass er mir vertraut und mich ermächtigt.

Früher habe ich mir immer gedacht: "Wenn ich den Leuten sage, dass das lange dauert oder keine Priorität hat, denken sie, dass ich schlechte Arbeit leiste." Jetzt achte ich darauf, dass ich den Gesprächen vorausgehe und den Leuten sage, was wirklich los ist und nicht, was sie hören wollen. Ich bin mir nicht sicher, inwieweit das an meiner natürlichen Reifung als Produktmanagerin liegt und inwieweit es daran liegt, dass ich in einem Umfeld arbeite, in dem die Leute im Allgemeinen aufmerksam und hilfsbereit sind. Aber ich habe das Gefühl, dass ich dieses neu gewonnene Selbstvertrauen mitbringen würde, selbst wenn ich an einem Ort arbeiten würde, der weniger aufmerksam und unterstützend ist. Das kann unangenehm sein, aber am Ende des Tages kann ich dadurch mehr bewirken.

Nicht ablenken, sondern direkt sein

Vor einigen Jahren erhielt ich an einem Donnerstagabend gegen 21 Uhr eine unerwartete Textnachricht von meinem Manager. Sie lautete: "Hey, es wäre wirklich toll, wenn wir die neue Version der iPhone-App heute Abend im App Store einreichen könnten!"

Ich war verwirrt. War dies eine dringende Forderung? Eine freundliche, aber nicht dringende Bitte? Wurde ich gebeten, jetzt sofort etwas zu tun? Oder wurde mir einfach ein Fenster mit 113 Zeichen in die Vision dieser Person von einer besseren Welt gezeigt? In den meisten Situationen hätte ich mich wahrscheinlich als Produktmärtyrer an meinen Computer geschleppt, die App mürrisch abgeschickt und eine vielsagend überschwängliche Nachricht wie "NATÜRLICH KEIN PROBLEM!!!" zurückgeschickt.

Aber dieses Mal war ich tatsächlich auf einem Konzert, eine gute Stunde von meinem Computer entfernt. (Und ja, ich schäme mich, dass ich während eines Konzerts auf mein Handy schaue.) Da ich nicht in meine übliche Routine der passiv-aggressiven Überarbeitung zurückfallen konnte, ging ich raus und rief meinen Manager an.

"Hey, es tut mir wirklich leid, aber ich bin gerade auf einem Konzert. Aber wenn du willst, dass ich nach Hause fahre und die App einreiche, kann ich das natürlich tun."

Die Stimme am anderen Ende der Leitung war zögerlich.

"Oh, ähm, ja, ich meine, es wäre wirklich toll, es heute Abend in den Laden zu bringen!" Eine Pause. "Aber wenn du auf einem Konzert bist... ich meine... weißt du was, mach dir keine Sorgen, wir können morgen früh darüber reden."

Ich stieß ein fröhliches "Klingt gut, danke" aus und wurde sofort von einem tiefen Gefühl der Angst übermannt. Hatte ich gerade eine unsichtbare Grenze der Work-Life-Balance überschritten? Hatte ich aus Eigennutz etwas Schlechtes für die Firma getan? War ich, wie ich schon lange vermutet hatte, ein schrecklicher, egoistischer Mensch?

Am nächsten Morgen bereitete ich mich darauf vor, meine Strafe zu erhalten. Mein Vorgesetzter schien jedoch bemerkenswert gelassen zu sein. "Oh ja, ich meine, ich habe gestern Abend gemerkt, dass es gut gewesen wäre, die Bewerbung gleich einzureichen, aber es ist völlig in Ordnung, sie heute einzureichen, es wird ja keinen großen Unterschied bei der endgültigen Zeitplanung machen."

In einem für mich untypischen Moment der Direktheit sagte ich: "Okay, kann ich dich um einen Gefallen bitten? Könntest du dich in Zukunft sehr, sehr deutlich ausdrücken, wenn du mich bittest, jetzt etwas zu tun? Als ich deine Nachricht erhielt, war es für mich schwer zu erkennen, wie dringend die Situation wirklich war. Wenn du mich jemals dringend brauchst, um etwas zu tun, dann werde ich alles in meiner Macht stehende tun, um sicherzustellen, dass es erledigt wird. Aber wenn es sich eher um ein 'nice to have' handelt, könntest du das bitte so deutlich wie möglich sagen?"

Etwa 10 Sekunden lang war ich sehr stolz auf mich, weil ich so direkt war. Dann wurde mir klar, dass die meisten Anfragen, die ich an meine Kollegen richtete, immer noch mit einer Version von "Es wäre toll, wenn..." oder "Hey! Meinst du, du könntest vielleicht..." oder "HEY NICE DAY HOW'S THE WEATHER I LIKE SANDWICHES DO YOU LIKE SANDWICHES anyway I was just wondering if you maybe had time to..." begannen.

Da Produktmanager/innen selten direkte organisatorische Befugnisse haben, kann es verlockend sein, jede Anfrage so "nett" wie möglich zu formulieren - vor allem, wenn es darum geht, länger zu bleiben, um ein Produkt zu veröffentlichen oder bereits abgeschlossene Arbeiten zu wiederholen. Aber es ist nicht nett, wenn du nicht genau sagst, worum du bittest (und ob du überhaupt etwas verlangst). Es ist eine Ablenkung von der Verantwortung, ein passiv-aggressiver Versuch, das gewünschte Ergebnis zu bekommen, ohne der "Bösewicht" zu sein.

Die Anziehungskraft von Ablenkungsmanövern, überzogenen Entschuldigungen und allgemeiner Selbstironie ist bei Produktmanagern sehr stark. Aber es ist auch schädlich und gefährlich, sowohl für dich als auch für dein Team. Viele Jahre lang habe ich mich durch Selbstabwertung aus Situationen herausgeschlichen, in denen ich das Gefühl hatte, dass die Leute sauer auf mich sein könnten. Wenn ich meinem Team eine harte Deadline oder eine Anfrage für neue Arbeit vorlegte, sagte ich oft etwas wie "Ratet mal, hier kommt der PRODUKTMANAGER mit einer weiteren FUN DEADLINE FOR EVERYBODY!" Das war ein guter Weg, um die Anspannung abzubauen und zu zeigen, dass ich "zum Team gehöre". Meistens sorgte das zumindest für ein kleines Lachen.

Aber der langfristige Effekt, den das auf das Team hatte, war weder gut noch besonders lustig. Indem ich mich selbst herabsetzte, um meine eigenen Gefühle zu schonen, tat ich absolut nichts, um meinem Team zu vermitteln , warum ich von ihnen verlangte, eine strenge Frist einzuhalten oder etwas zu überarbeiten, von dem sie dachten, es sei bereits erledigt. Mein Ziel war es nicht, das Team auf unser Ziel einzuschwören, sondern das Gespräch so schnell wie möglich zu beenden. Ich habe damit bewusst oder unbewusst zum Ausdruck gebracht, dass die Arbeit, um die ich bat, bedeutungslos war - denn wenn ich die Verantwortung für die Vermittlung der Bedeutung der Arbeit übernehmen würde, wäre ich die Person, die um die Arbeit bittet. Und niemand mag die Person, die nach der Arbeit fragt.

Als Produktmanager musst du manchmal Dinge von deinen Mitarbeitern verlangen, die sie nicht tun wollen. Wenn diese Dinge für den Erfolg deines Teams entscheidend sind, hilf deinem Team zu verstehen , warum und überlege gemeinsam mit ihnen, welche anderen Aufgaben du zurückstellen kannst. Und wenn sie nicht entscheidend für den Erfolg deines Teams sind, solltest du dich fragen, ob du die Zeit deines Teams sinnvoll einteilst oder einfach zu allem ja sagst, was dir vage wichtig erscheint.

Nicht alles ist deine Schuld, und Ergebnisse zählen mehr als Absichten

Produktmanager/innen sind oft dazu angehalten, die volle und eindeutige Verantwortung für alles zu übernehmen, was in ihrem Team schief läuft. "Wenn etwas schief geht", wurde mir früher in meiner Karriere gesagt, "ist es deine Schuld - egal, ob es wirklich deine Schuld ist oder nicht."

Ich nahm mir diesen Rat zu Herzen und nahm mein Produktmartyrium an. Und auf eine seltsame Art und Weise fühlte sich das wie eine Erleichterung an. Wenn in meinem Team etwas schief lief, konnte ich einfach sagen: "Ja, ich bin schuld, ich bin der Schlimmste", und mit meinem Tag weitermachen. Das war viel einfacher, als ein ehrliches Gespräch darüber zu führen, wie das gesamte Team zu einem schlechten Ergebnis beigetragen hat und welche Schritte wir unternehmen können, um in Zukunft bessere Ergebnisse zu erzielen.

Ja, als Produktmanager/in bist du letztendlich für die Ergebnisse deines Teams verantwortlich. Aber diese Verantwortung kannst du nicht allein tragen. Wenn du alles, was schief läuft, als dein persönliches Versagen ansiehst, nimmst du deinem Team eine wichtige Chance, zu lernen und zu wachsen. Nichts widerspricht unserem Leitsatz, sich selbst überflüssig zu machen, mehr als sich selbst als alleinigen persönlichen Schuldigen für alle Fehltritte deines Teams zu sehen, anstatt gemeinsam mit deinem Team an den systemischen Herausforderungen zu arbeiten, die möglicherweise zu diesen Fehltritten beigetragen haben.

Der Grat zwischen dem Ansprechen von systemischen Herausforderungen und persönlichen Schuldzuweisungen kann sehr schmal sein. In den letzten Jahren habe ich oft gehört, dass die Anweisung "gehe von einer positiven Absicht aus" dazu dient, diese Linie zu stärken und schwierige Gespräche zu entpersonalisieren. Und natürlich ist die "positive Absicht" eine gesündere Anweisung als die "persönliche Schuldzuweisung für alles, was schief läuft, auch wenn du nicht wirklich glaubst, dass es deine Schuld ist".

Aber seit der Begriff "positive Absicht" allgegenwärtig ist, hat er auch einige Grenzen aufgezeigt. Im letzten Jahr habe ich leider gehört, dass der Satz als eine Art passiv-aggressive Herausforderung für genau die Gespräche verwendet wurde, die er eigentlich erleichtern sollte: "Wie kannst du es wagen zu behaupten, dass mit meinem Team etwas nicht stimmt? Weißt du nicht, dass ich mein Bestes tue? Was ist aus der 'positiven Absicht' geworden?"

Wie diese alptraumhafte emotionale Rube-Goldberg-Maschine aus Projektionen und Aufschiebungen andeutet, kann allein die Vorstellung, sich auf "Absichten" zu konzentrieren, uns in ein seltsames, düsteres emotionales Gebiet führen. Menschen mit guten Absichten können auf Gedeih und Verderb eine Menge Schaden anrichten, und auch Menschen mit schlechten Absichten stolpern hin und wieder in positive Handlungen. Im Großen und Ganzen habe ich es als hilfreich empfunden, sich bei diesen Gesprächen auf die Ergebnisse und nicht auf die Absichten zu konzentrieren.

In der Praxis bedeutet das oft, dass ich Gespräche über zwischenmenschliche oder teaminterne Herausforderungen mit der Frage "Hat diese Situation zum gewünschten Ergebnis geführt?" moderiere. Wenn zum Beispiel ein Produktmanager zu mir kommt und sich darüber ärgert, dass sein Kollege aus der Technik sich vom Entscheidungsprozess ausgeschlossen fühlt (eine häufige Dynamik in funktionsübergreifenden Produktteams), habe ich mir angewöhnt zu fragen: "War es das gewünschte Ergebnis dieser Situation, dass der technische Leiter vom Entscheidungsprozess ausgeschlossen wurde?" Wenn die Antwort lautet: "Ja, ich hatte keine Zeit, ihn einzubeziehen", oder sogar "Ja, ich traue ihm nicht zu, sich am Entscheidungsprozess unseres Teams zu beteiligen", dann können wir das Gespräch von dort aus weiterführen. Und wenn die Antwort lautet: "Nein, ich habe mein Bestes getan, um alle einzubeziehen, und ich bin mir nicht sicher, warum sie sich übergangen fühlen", dann kann der Produktmanager ein Folgegespräch mit seinem Kollegen aus der Technik führen, um zu verstehen, was passiert ist, und beim nächsten Mal auf ein besseres Ergebnis hinzuarbeiten.

Wenn wir uns selbst als Individuen aus dem Bild nehmen und das gesamte System betrachten, sehen wir, dass unsere Absichten oft weitgehend irrelevant sind. Unsere Aufgabe ist es, Systeme zu verbessern, in der Hoffnung, immer bessere Ergebnisse für unser Unternehmen und unsere Kunden zu erzielen. Wenn ich mit der Frustration oder den verletzten Gefühlen einer Kollegin oder eines Kollegen konfrontiert werde, habe ich es als hilfreich empfunden, mit einer Aussage wie "OK, danke, dass du mir das mitteilst. Es hört sich so an, als hätte das nicht zu dem gewünschten Ergebnis geführt. Wie können wir die Dinge in Zukunft ändern, um ein besseres Ergebnis zu erzielen?" Dieser Wechsel von Emotionen zu Ergebnissen kann helfen, Gespräche umzulenken, die sonst in passiv-aggressive Schuldzuweisungen (oder unverhohlenes Produktmartyrium) ausarten würden .

Abkehr von der Selbstabwertung

M.L.

Produktmanager, 100-Personen-Startup

Ich werde nie den Moment vergessen, in dem mir klar wurde, dass Selbstabwertung nicht länger ein vertretbarer Teil meines Ansatzes im Produktmanagement war. Ich befand mich etwa einen Monat lang in einem besonders herausfordernden Projekt, das mit vielen langen Nächten und Überarbeitungen in letzter Minute verbunden war. Ich fühlte mich wirklich schuldig, weil ich meinem Team all das zugemutet hatte, und tat mein Bestes, um die Anspannung mit übertriebenen Entschuldigungen und dramatischen, selbstironischen Kommentaren wie "Ich weiß, ich weiß, ich bin der Allerschlimmste" und "Ja, das ist alles meine Schuld, aber ihr seid die Besten dafür, dass ihr das Chaos aufräumt, das ich angerichtet habe" zu lindern.

Und dann bekam ich aus heiterem Himmel eine E-Mail von einem Entwickler aus meinem Team, die mich wirklich überraschte. Er war besorgt über die Art und Weise, wie ich über meine eigene Arbeit gesprochen hatte. Er wollte wissen, ob ich mich wirklich so schlecht wegen meiner Arbeit fühle? Glaubte ich wirklich, dass ich nichts zu bieten hatte? Hatte er irgendetwas getan, das mir das Gefühl gab, dass meine Beiträge vom Team nicht geschätzt wurden?

Als ich anfing, eine Antwort zu verfassen, fiel es mir ein: Ich war weder der Meinung, dass ich nichts zu bieten hatte, noch dachte ich, dass alles, was passierte, meine Schuld war. Ohne mir dessen bewusst zu sein, hatte ich die Selbstabwertung als passiv-aggressive und nicht ganz aufrichtige Art und Weise eingesetzt, um zu sagen: "Bitte fordere mich nicht mit den Dingen heraus, um die ich dich bitte." Ich war als Produktmanagerin einfach nicht selbstbewusst oder reif genug, um ein offenes Gespräch mit meinem Team darüber zu führen, warum wir bis spät in die Nacht arbeiteten und Dinge wiederholten, die wir bereits erledigt hatten. Und ich war sicherlich nicht selbstbewusst oder reif genug, um mit der Unternehmensleitung offen über die Nachteile und Kompromisse zu sprechen, die diese langen Nächte und Änderungen in letzter Minute mit sich brachten. Es war einfacher für mich, der Unternehmensleitung zu sagen: "Jawohl, was immer ihr wollt", und dann meinem eigenen Team zu sagen: "Tut mir leid, ich bin scheiße".

Hier ist eine Gedankenübung, mit der ich mir dieses Verhalten abgewöhnt habe. Wenn ich den Drang verspüre, eine selbstabwertende Bemerkung zu machen, frage ich mich: "Wenn mich jemand aus meinem Team unterbrechen würde, um zu sagen: 'Hey, das ist nicht nötig. Du machst einen tollen Job und wir respektieren deine Meinung', wäre ich dann erleichtert oder verärgert?" Wenn die Antwort "erleichtert" lautet, versuche ich, eine offene Rückschau mit meinem Team zu halten, um herauszufinden, ob es noch andere Gründe für mein mangelndes Vertrauen in meine Arbeit gibt. Wenn die Antwort "verärgert" lautet, frage ich mich, welche schwierige Frage oder welches schwierige Gespräch ich vielleicht durch Selbstabwertung ablenken will, und versuche, den Mut aufzubringen, diese Frage oder dieses Gespräch proaktiv mit meinem Team zu führen.

Seit einigen Jahren vermeide ich es, mich selbst herabzuwürdigen, und ich musste viel besser darin werden, offene Gespräche mit meinem Team darüber zu führen, was wirklich los ist und was wir dagegen tun können. Natürlich muss ich mir immer wieder die Frage gefallen lassen, warum wir das tun, was wir tun, oder wie ich eine bestimmte Entscheidung getroffen habe. Aber meine Erfahrung bei der Beantwortung dieser Fragen hat mir geholfen, ein besserer Produktmanager und hoffentlich auch ein weniger defensiver Mensch zu werden.

Die zwei gefährlichsten Wörter im Produktmanagement: "Sieht gut aus"

Zu Beginn meiner Karriere als Produktmanagerin glaubte ich wirklich, dass ich mich aus Schwierigkeiten heraushalten könnte, indem ich sicherstellte, dass jeder Schritt, den ich unternahm, von einer Autoritätsperson oberflächlich "genehmigt" wurde. Bevor ich die vierteljährliche Roadmap meines Teams fertigstellte, musste ich sie in einem Meeting der Unternehmensleitung vorstellen. Und bevor ich Design-Mocks in funktionierende Software umwandelte, schickte ich diese Mocks an alle Stakeholder, von denen ich annahm, dass sie eine besondere Meinung über das Aussehen und die Handhabung unseres Produkts haben könnten. Obwohl ich angeblich Feedback von diesen Stakeholdern einholen wollte, war ich in Wirklichkeit auf der Suche nach einer einfachen Geste der Zustimmung - ein abgehaktes Kästchen, das mir den Rücken freihalten würde, falls die Dinge später schiefgehen würden.

Meistens hatte diese Geste der Anerkennung die Form einer kurzen, passiven Bestätigung wie "Ich hab's" oder "Danke fürs Senden". Und das war wirklich alles, was ich brauchte - und damals auch alles, was ich wollte. Ich dachte, wenn später jemand mit der Arbeit meines Teams nicht einverstanden wäre, könnte ich ihm dieses "Ich hab's verstanden" direkt ins Gesicht sagen und als Sieger hervorgehen: "Ich habe euch das vor einem Monat geschickt und ihr hattet keine Rückmeldung, was bedeutet, dass ihr es jetzt nicht mehr ändern könnt!"

Ich habe schnell festgestellt, dass "keine Rückzieher" keine verbindliche Unternehmenspolitik ist. Wie wir in Kapitel 5 besprechen werden, sind die Stakeholder - insbesondere die Führungskräfte - sehr beschäftigte Menschen, und ein kurzes Nicken in einem Meeting oder eine E-Mail mit "Verstanden, danke" bedeutet nicht unbedingt, dass sie deinen Standpunkt zur Kenntnis genommen haben, geschweige denn, dass sie sich ernsthaft mit ihm auseinandersetzen. In der Welt des Produktmanagements ist alles, was nicht zu einer ausdrücklichen Zustimmung führt, unglaublich gefährlich. Und es gibt keine zwei Worte, die besser als "Sieht gut aus" für unbeteiligte, zweideutige und vage Zustimmung stehen.

Die besten Produktmanager machen es den Leuten mehr oder weniger unmöglich, mit "Sieht gut aus" zu reagieren. Sie stellen immer offene Fragen - auch wenn diese Fragen unangenehm und nervenaufreibend sind. Und wie wir in Kapitel 3 besprochen haben, bieten sie Optionen an, keine Argumente, und fordern von ihren Stakeholdern aktive Beteiligung statt passivem, glasigem Nicken oder Zwei-Wort-E-Mail-Antworten.

Ich habe die Erfahrung gemacht, dass es hilfreich ist, in jedem Meeting oder jeder E-Mail, in der du um Feedback oder Zustimmung bittest, mindestens eine sinnvolle Auswahlmöglichkeit oder eine offene Frage zu stellen. Eine E-Mail, in der es heißt: "Im Anhang findest du unseren Fahrplan für das nächste Quartal. Lass mich wissen, wenn du Fragen hast", mag zwar den Anschein von Transparenz und Zusammenarbeit erwecken, schützt dich aber nicht vor Reaktionen wie "Was zum Teufel ist das und warum habe ich das nicht schon früher gesehen? Im Gegensatz dazu ist es viel wahrscheinlicher, dass du engagierte Antworten bekommst, wenn du in einer E-Mail schreibst: "Anbei findest du unsere Roadmap für das nächste Quartal. Wie du sehen kannst, erwägen wir zwei verschiedene Optionen für die Sprints 6-8. Könntest du uns bitte bis Freitagabend mitteilen, welche Option deiner Meinung nach besser zu den Zielen deines Teams passt?" (Wie wichtig es ist, konkrete und zeitlich begrenzte Anfragen per E-Mail und Chat zu stellen, besprechen wir in Kapitel 13, "Probier's mal zu Hause: Die Irrungen und Wirrungen der Fernarbeit") .

Ein taktischer Ansatz, um über "sieht gut aus" hinauszukommen: Nicht einverstanden sein und sich engagieren

In Gesprächen mit mehreren Interessenvertretern ist der Schwerpunkt "Sieht gut aus" umso verlockender und unwiderstehlicher. So unangenehm es ist, mit einer Person in einem Einzelgespräch nicht einverstanden zu sein, so unangenehm kann es sein, mit 10 Personen in einem 10-Personen-Gespräch nicht einverstanden zu sein. "Sieht gut aus" wird immer der Weg des geringsten Widerstands sein - es sei denn, du tust die schwierige Arbeit, diesen Weg mit einer Menge Widerstand zu versehen.

Zum Glück haben die guten Leute von Intel eine Technik namens "disagree and commit" entwickelt, die genau darauf abzielt. Die Idee hinter "Disagree and Commit" ist ziemlich einfach: Jede Entscheidung, die in einer Gruppe getroffen wird, sollte mit einem positiven Bekenntnis aller Beteiligten zu einem neuen Weg enden. Um zu dieser Verpflichtung zu gelangen, sollten Fragen, Bedenken und Meinungsverschiedenheiten, die sonst unausgesprochen geblieben wären, vorgebracht werden.

Stellen wir uns zum Beispiel zwei verschiedene Meetings vor, in denen entschieden werden soll, ob eine neue Funktion in die kostenlose oder kostenpflichtige Version eines Freemium-Produkts aufgenommen werden soll. Die erste Sitzung läuft nach den traditionellen Regeln des impliziten Konsenses ab: Wenn alle zustimmen (oder zumindest niemand widerspricht), ist die Entscheidung gefallen und man macht weiter. Als Produktmanager in dem Team, das diese Funktion entwickelt, hast du die Aufgabe, einer Gruppe von etwa 10 Stakeholdern auf Direktorenebene deine Argumente zu präsentieren. Nachdem du eine Wettbewerbsanalyse, Nutzungsprognosen und Umsatzziele durchgespielt hast, empfiehlst du nachdrücklich, die Funktion in die kostenlose Version aufzunehmen. "Hat jemand Fragen? Hört sich das nach einem guten Ansatz an?" Ein paar lauwarme Nickerchen, aber allgemeines Schweigen. Du atmest erleichtert auf. "Okay, super!"

Dein Team macht sich sofort wieder an die Arbeit und beginnt mit der Umsetzung einer aufregenden neuen kostenlosen Funktion. Die technischen Details sind ausgehandelt, die Marketingtexte geschrieben und alles scheint auf einem guten Weg zu sein. Dann, zwei Wochen nach dem Treffen, erhältst du eine E-Mail von einem der Geschäftsführer, der deinem Vorschlag zugestimmt hatte: "Tut uns leid, wir müssen die Sache verschieben - es gibt noch ein paar Probleme mit der Preisgestaltung, die wir klären müssen." Warte, was? Du dachtest, alle hätten zugestimmt! Du schickst schnell eine E-Mail zurück und versuchst, deine Wut und Frustration zu unterdrücken: "Danke für die Nachricht. Tut mir leid, ich bin etwas verwirrt - ich dachte, wir hätten uns alle darauf geeinigt, dass dies ein kostenloses Feature sein würde. Ein paar Stunden später erhältst du eine Antwort: "Ja, unser VP of Revenue überdenkt gerade die Preisstrategie und ist sich nicht sicher, ob ein weiteres kostenloses Feature im Moment sinnvoll ist. Ich werde nächste Woche mehr Informationen für dich haben."

Du schüttelst den Kopf und stößt einen tiefen Seufzer aus. Jetzt musst du deinem Team sagen, dass die gesamte Preisstrategie des Unternehmens in Frage gestellt ist und dass zwei Wochen harter Arbeit dadurch in der Schwebe sind. Du weißt, dass dies ein großer Schlag für die Moral und ein großer Rückschlag für die Zeitplanung deines Teams sein wird, aber du weißt nicht, was du tun kannst, außer zu hoffen, zu warten und zu lachen.

Stellen wir uns nun ein zweites Treffen vor, das nach den Regeln des "Disagree and Commit" abläuft: Jede Person in der Besprechung muss eine bestimmte, bestätigende Zusage geben, bevor eine Entscheidung getroffen wird, und jede Person ist dafür verantwortlich, Fragen oder Meinungsverschiedenheiten zu äußern, die sie davon abhalten könnten, diese Zusage zu geben. Nachdem du eine Wettbewerbsanalyse, Nutzungsprognosen und Umsatzziele durchgespielt hast, empfiehlst du abschließend nachdrücklich, die Funktion in die kostenlose Version aufzunehmen. "Okay", sagst du den versammelten Stakeholdern, "wir werden dieses Mal etwas anders machen. Das ist eine wichtige Entscheidung für das Team, und ich möchte sichergehen, dass wir alle Informationen, die ihr habt, auf den Tisch bekommen haben. Ich werde also herumgehen und jeden von euch einzeln bitten, "Ich verpflichte mich" zu sagen, wenn ihr bereit seid, mit dem Ansatz, den wir skizziert haben, weiterzumachen. Und wenn ihr euch nicht verpflichten könnt, dann sagt mir, warum, und wir überlegen uns, was wir dann tun.

Du wendest dich an den Direktor für Produktmarketing. "Sind Sie einverstanden, dass wir eine kostenlose Funktion einführen?" Er scheint ein wenig überrascht zu sein und antwortet hastig: "Ähm, klar, ja, ich sage zu." "Okay, super", sagst du. Du hältst einen Moment inne und fährst dann fort: "Nur um das klarzustellen: Das Ziel ist es, alle Fragen und Bedenken aus dem Weg zu räumen, damit wir die bestmögliche Entscheidung treffen können. Ihr müsst nicht ja sagen, wenn ihr euch nicht sicher seid!" Nach ein paar nervösen Lachern antworten sie: "Ha, nein, danke, ja, ich sage zu! Ich glaube, das macht sehr viel Sinn."

Du wendest dich an den Director of Revenue Operations. Auf Anhieb scheinen sie sich nicht ganz so sicher zu sein. "Eigentlich", sagt er, "bin ich mir nicht sicher, ob ich mich im Moment darauf einlassen kann. Unser VP of Revenue überdenkt gerade unsere Preisstrategie, und ich möchte dir kein definitives Ja geben, bevor wir das nicht geklärt haben." Du hältst inne. "Okay, super, vielen Dank dafür. Wann denkst du, können wir mehr Klarheit darüber bekommen?" Sie antworten: "Ich komme nächste Woche zurück."

In der darauffolgenden Woche führst du mehrere Folgegespräche mit dem Vertriebsteam und bekommst ein besseres Gefühl dafür, wie und warum sich die Preisstrategie des Unternehmens ändert. In der Zwischenzeit macht dein Team mit Arbeiten weiter, die keine feste Festlegung auf einen der beiden Preisansätze erfordern. Schon bald kannst du die Beteiligten des ersten Treffens wieder zusammenrufen und mit der vollen Unterstützung des Director of Revenue Operations erklären, dass sich die Preisstrategie des Unternehmens dahingehend geändert hat, dass mehr Funktionen in den kostenpflichtigen Bereich aufgenommen wurden. Das Hin und Her ist frustrierend, aber du bist sehr erleichtert, dass du diese Änderung vor den Augen deines Teams und deiner Stakeholder durchsetzen konntest.

Wie dieses Beispiel zeigt, löst "Disagree and Commit" nicht alle Unstimmigkeiten und Missverständnisse, die in einer Organisation auftreten können, aber es kann dabei helfen, diese Unstimmigkeiten und Missverständnisse rechtzeitig und produktiv zu erkennen.

Wie bei jeder bewährten Methode hängt die Art und Weise, wie du disagree and commit umsetzt, von deinem Team und deiner Organisation ab. Hier sind einige Tipps zum Ausprobieren:

Führe Unstimmigkeiten ein und lege dich fest, bevor du sie benutzt.

Da "Disagree and Commit" eine formalisierte bewährte Methode ist, die von Unternehmen wie Intel und Amazon unterstützt wird, kannst du sie als vereinbartes Experiment einführen. Das ist wichtig, denn so vermeidest du Situationen, in denen deine Mitarbeiter/innen das Gefühl haben könnten, du würdest "Disagree and Commit" als eine Art passiv-aggressive persönliche Kritik an besonders unentschlossenen Teammitgliedern einführen.

Interpretiere das Schweigen als Ablehnung.

In den meisten Meetings wird Schweigen als stillschweigende Zustimmung gewertet. Jemand schlägt einen Weg vor, schließt sein Angebot mit "Noch Fragen?" ab und wenn niemand antwortet, ist die Sache so gut wie erledigt. Bei "Disagree and Commit" wird nichts akzeptiert, was nicht bestätigt wird, was bedeutet, dass Schweigen als Ablehnung gewertet wird. Sei den Teilnehmern gegenüber sehr deutlich: "Wenn du schweigst, gehe ich davon aus, dass du nicht mit mir übereinstimmst. Lass uns durchgehen und jede Person ihre Gedanken und Bedenken mitteilen." Wenn du das zum ersten Mal versuchst, könnte das einer der unangenehmsten Momente deiner Produktmanagement-Karriere sein, aber du wirst erstaunt sein, welche Erkenntnisse selbst die stillsten Leute im Raum gewinnen können.

In größeren Meetings solltest du einen kurzen Puls-Check machen.

In größeren Besprechungen - vor allem in großen Besprechungen, die per Videochat abgehalten werden - habe ich es oft als hilfreich empfunden, zum Abschluss einer Besprechung kurz zu fragen: "Können mir alle, die für diesen Ansatz sind, ein Daumen hoch geben?" Selbst wenn nur ein oder zwei Personen zögerlich antworten, hast du so die Möglichkeit, tiefer einzusteigen und schnell zu zeigen, dass abweichende Meinungen willkommen sind und ernst genommen werden.

Ziele setzen, testen und lernen.

Was ist also, wenn Menschen sich einfach nicht auf einen Weg nach vorne festlegen wollen? Das ist, ob du es glaubst oder nicht, ein gutes Zeichen. Es bedeutet, dass die Menschen im Raum so engagiert sind, dass sie sich nicht auf etwas festlegen wollen, das sie für falsch halten. Eine Möglichkeit, dieses Gespräch voranzubringen, ist, Erfolgskriterien festzulegen und zu planen, die Entscheidung später zu überprüfen. Dann kannst du überprüfen, ob der gewählte Ansatz funktioniert und entsprechende Anpassungen vornehmen.

Angenommen, du sitzt in einer Besprechung mit deinem Entwicklungsteam und es herrscht Uneinigkeit darüber, ob euer Produktentwicklungszyklus zwei oder sechs Wochen betragen soll. Anstatt zu versuchen, alle zu einem Konsens zu bringen, könntest du sagen: "Wie wäre es, wenn wir uns verpflichten, zweiwöchige Entwicklungszyklen auszuprobieren und uns dann in einem Monat wieder treffen, um zu sehen, ob diese Entscheidung uns hilft, unsere Teamziele zu erreichen, oder ob wir etwas anderes ausprobieren wollen?" So wird sichergestellt, dass eine Entscheidung getroffen wird, und es entsteht ein gemeinsames Verantwortungsgefühl dafür, den Erfolg zu messen und den Kurs in Zukunft anzupassen.

Interpretiere das Ganze nicht völlig falsch und sage: "Es ist egal, ob du zustimmst, denn wir stimmen nicht zu und verpflichten uns!"

Ich kann kaum glauben, dass ich das schreiben muss, aber in einigen Fällen haben Leute die Idee von "widersprechen und sich verpflichten" ins lächerliche Extrem getrieben, indem sie ihren Kolleginnen und Kollegen zugerufen haben: "Es ist egal, ob du mit mir übereinstimmst - wir machen "widersprechen und verpflichten". Erinnere dich daran, dass der Zweck von "widersprechen und zusagen" darin besteht, Zögern, Bedenken und Fragen aufzudecken, die sonst unausgesprochen bleiben würden. Wenn deine Anwendung von "Disagree and Commit" dazu führt, dass Andersdenkende in die Knie gezwungen werden, dann machst du es falsch.

Mit "Disagree and Commit" zu besseren Lösungen kommen

J.A.

Produktmanagement-Berater

Ich arbeitete mit einem kleinen Beratungsunternehmen in Kalifornien zusammen, das Produkte für Medienkonzerne herstellt. Bei einer Sitzung, in der wir interne Abläufe besprachen, kam die Frage auf, wie wir mit Kunden-E-Mails umgehen, die nach der Arbeitszeit eintreffen. Dies war offensichtlich eine Quelle von Spannungen im Team, und die meisten Leute schwiegen, als die Frage direkt gestellt wurde.

Schließlich meldete sich einer der ranghöheren Mitarbeiter des Unternehmens mit den Worten zu Wort: "Nun, es ist wichtig, dass wir unseren Kunden rechtzeitig antworten. Wenn du die E-Mail also zufällig siehst, solltest du einfach darauf antworten." Jemand anderes fragte: "Aber was ist, wenn zwei Leute in dem Thread sind?" Eine dritte Person meldete sich: "Wenn du eine E-Mail nach Feierabend siehst und sie beantworten willst, schickst du zuerst eine Slack-Nachricht an die anderen, die die Nachricht erhalten haben, und sagst ihnen, dass du sie bekommen hast, und DANN schickst du eine Antwort an den Kunden." Ein paar Leute am Tisch nickten. Wir hatten eine gemeinsame Lösung gefunden und wussten, wie es weitergehen sollte.

Aber die Gesichter am Tisch waren immer noch angespannt und ein paar Leute waren immer noch verdächtig still. Ich hatte gerade gelernt, dass man nicht zustimmen und sich verpflichten kann, und das schien mir ein guter Moment zu sein, um es auszuprobieren. Ich teilte allen Anwesenden mit, dass sie diesem Ansatz zustimmen müssten und dass ich bei Schweigen davon ausgehen würde, dass sie mit dem Ansatz nicht einverstanden wären. Als wir am Tisch herumgingen, sagten die meisten zu: "Ja, ich bin bereit, das eine Weile auszuprobieren und zu sehen, was passiert". Aber eine Person - diejenige, die die meiste Zeit des Treffens am ruhigsten war - meldete sich zu Wort: "Ja, ich meine, dieser Plan scheint in Ordnung zu sein ... aber ich sehe nicht ein, warum wir sie in der Nacht zurückmailen müssen. Wenn mir ein Kunde nachts eine E-Mail schickt, schreibe ich ihm am nächsten Morgen zurück. Und mit der Zeit haben sich diese Kunden dieses Verhalten abgewöhnt. Sie schreiben mir zu Beginn des Arbeitstages und nicht erst spät in der Nacht, und dann klappt es meist besser, weil ich mich nicht beeilen muss, zurück zu kommen.

Die Energie im Raum veränderte sich in diesem Moment so dramatisch, als ob sich ein Fenster öffnete oder so. Die Leute, die sich bisher nur lauwarm auf den bisherigen Ansatz eingelassen hatten, erzählten von schief gelaufenen E-Mails, übereilten Fehlentscheidungen und von Abendessen, die durch unklare Erwartungen des Kundenmanagements ruiniert wurden. Das gesamte Team setzte sich mit Begeisterung für einen neuen Weg ein, und dieser Weg wäre nie zustande gekommen, wenn wir uns nicht für den Ansatz "Uneinigkeit und Engagement" entschieden hätten.

Berücksichtigung unterschiedlicher Kommunikationsstile

Für viele Produktmanager/innen ist es ganz natürlich, zu viel zu kommunizieren - das ist einer der Gründe, warum sie sich überhaupt für das Produktmanagement entschieden haben. Aus dieser Perspektive erscheinen Menschen, die weniger dazu neigen, viele Fragen zu stellen, sich in Meetings zu Wort zu melden oder detaillierte schriftliche Antworten zu geben, oft als "schlechte" Kommunikatoren.

In meiner Laufbahn als Produktmanagerin war ich oft frustriert über Leute, die meine Vorliebe für ausführliche schriftliche Kommunikation und spontanes "Riffing" in Meetings nicht teilen. (Diejenigen unter euch, die diesen letzten Satz lesen und denken: "Beides hört sich schrecklich an", ich verstehe und schätze euch). Ich habe lange gebraucht, um zu erkennen, dass es hier nicht um "gute Kommunikation" oder "schlechte Kommunikation" geht, sondern um die vielen verschiedenen Kommunikationsstile, denen du in deinem Beruf wahrscheinlich begegnen wirst.

Als Produktmanager/in musst du dich daran erinnern, dass nicht jeder deinen Kommunikationsstil teilen wird. Sei offen und neugierig gegenüber denjenigen, die dir zunächst als schlechte Kommunikatoren erscheinen. Hier sind ein paar allgemeine Kommunikationsstile, denen ich oft begegnet bin, um dir zu helfen, von einem Ort des Verständnisses und der Empathie auszugehen:

Visuelle Kommunikatoren

Manche Menschen können ein Konzept erst begreifen, wenn sie es visualisiert sehen. Als jemand, der hauptsächlich mit Worten kommuniziert, habe ich lange gebraucht, um das zu akzeptieren. Ich war oft frustriert und habe nur noch mehr Worte gebraucht, wenn meine sorgfältig verfassten Botschaften auf leere Blicke trafen. Wenn du kein visueller Kommunikator bist, können dir die visuellen Kommunikatoren in deinem Team eine großartige Möglichkeit bieten, dein eigenes Denken zu verfeinern und zu fokussieren, indem du deine Ideen schnell skizzierst oder visuelle Prototypen erstellst.

Offline-Kommunikatoren

Bei zahlreichen Gelegenheiten hat mich jemand nach einem Treffen zur Rede gestellt, weil er sich von mir in die Ecke gedrängt fühlte, obwohl ich nur versucht habe, ihn in das Gespräch einzubeziehen. Anfangs habe ich das als eine Art jugendliche Abwehrhaltung abgetan. Aber inzwischen habe ich eingesehen, dass manche Menschen Dinge erst einmal durchdenken müssen, bevor sie sie aussprechen. Wann immer es möglich ist, solltest du Offline-Kommunikatoren in deinem Team vorwarnen und sie über eine bestimmte Frage oder Herausforderung nachdenken lassen, bevor sie ihre Gedanken mitteilen. Stelle außerdem sicher, dass sie im Voraus wissen, ob sie in einem Meeting sprechen oder etwas präsentieren sollen.

Konfrontationsscheue Kommunikatoren

Im Arbeitsalltag des Produktmanagements kann sich ein unkompliziertes "Ja" oder "Sieht gut aus" wie ein seltener und wertvoller Moment reiner Positivität und Ermutigung anfühlen. Aber diese ermutigenden "Ja"-Antworten beruhen nicht immer auf einer gründlichen und nuancierten Bewertung der Frage, um die es geht. Als Produktmanager/in gehört es zu deinen Aufgaben, Klarheit über Bequemlichkeit zu stellen, aber das ist nicht die Aufgabe aller anderen und auch nicht deren Neigung. Wenn du Feedback von jemandem brauchst, dessen erste Reaktion immer "Ja" zu sein scheint, dann bitte um dieses Feedback auf eine Art und Weise, die keine "Ja-oder-Nein"-Antwort zulässt. Nimm die implizite Aufforderung dieser Person an, bei der Art und Weise, wie du um Feedback bittest, sowohl präziser als auch offener zu sein, und das wird dir wahrscheinlich helfen, besseres Feedback von allen in deinem Unternehmen zu bekommen.

Je mehr du über die einzelnen Personen in deinem Team erfährst und ihre individuellen Kommunikationsstile kennenlernst, desto besser kannst du die Kommunikation in deinem Team und deinem Unternehmen fördern. Ich habe die Erfahrung gemacht, dass du den Kommunikationsstil einer Person am einfachsten kennen lernst, wenn du siehst, wie sie dir etwas mitteilt. Menschen vermitteln Informationen in der Regel so, wie sie sie am leichtesten aufnehmen, und du kannst viel guten Willen schaffen, wenn du die Menschen dort triffst, wo sie sind.

Kommunikation ist dein Job - entschuldige dich nicht dafür, dass du deinen Job machst

Effektives Produktmanagement erfordert, dass man viele verschiedene Leute um viel Zeit bittet. Das kann dazu führen, dass sich Produktmanager wie lästige Idioten fühlen, die alle von ihrer "eigentlichen" Arbeit ablenken und sie zwingen, an einem Meeting nach dem anderen teilzunehmen oder eine E-Mail nach der anderen zu beantworten. Zu Beginn meiner Karriere als Produktmanagerin habe ich mein Bestes getan, um diese Situation zu entschärfen, indem ich meinen Kolleginnen und Kollegen versicherte, dass ich alles in meiner Macht Stehende tun würde, um sicherzustellen, dass sie an so wenigen (igitt) Meetings wie nur möglich teilnehmen müssen. Wenn ich doch mal eine Besprechung ansetzen musste, behandelte ich sie wie eine notwendige Unannehmlichkeit und nicht wie eine aufregende Gelegenheit für das Team, gemeinsam wichtige Probleme zu lösen.

Erst viel später wurde mir klar, dass ich damit eine sich selbst erfüllende Prophezeiung geschaffen hatte: Jede Besprechung meines Teams wurde als Zeitverschwendung behandelt und wurde damit zur Zeitverschwendung. In seinem Buch Death by Meeting ( ) (Jossey-Bass) macht Patrick Lencioni ( ) auf einen wichtigen Punkt in Bezug auf Meetings aufmerksam: Wenn die Menschen mit einer schlechten Einstellung an die Meetings herangehen, werden sie auch durch noch so viele Änderungen an den Abläufen nicht besser werden. Das Gleiche gilt für E-Mails und andere Formen der asynchronen Kommunikation. Wenn du deinen Kollegen beibringst, deine E-Mails als lästig zu betrachten, werden sie sie auch so behandeln. Wenn du dich darüber beklagst, dass du mit eingehenden Nachrichten "überfordert" bist, werden deine Kollegen es sich wahrscheinlich zweimal überlegen, bevor sie dich in ein Gespräch einbinden, das für den Erfolg deines Teams entscheidend sein könnte.

Wenn dein Team das Gefühl hat, in Meetings Zeit zu verschwenden, frage es nach den besten und produktivsten Meetings, an denen es kürzlich teilgenommen hat. Arbeitet dann gemeinsam daran, eine klare und realistische Vorstellung davon zu entwickeln, wie eine "gute" Besprechung aussehen sollte. Wenn dein Team mit E-Mails oder Chats überfordert ist, solltest du gemeinsam mit ihnen die Erwartungen an die Kommunikationskanäle, die ihr nutzt, klarer formulieren. (Wir werden das in Kapitel 13 genauer besprechen.) Unterschätze nicht den Wert der Zeit, die dein Team mit der Kommunikation verbringt, sondern sorge dafür, dass diese Zeit gut genutzt wird.

Ziele und Motivationen über dein unmittelbares Team hinaus verstehen

A.G.

Produktmanager, Verlagshaus mit 500 Mitarbeitern

Als ich jünger war, war ich oft frustriert, wenn ich das Gefühl hatte, dass die Leute - meist in anderen Bereichen des Unternehmens - nicht das Richtige taten. Ich dachte, sie seien entweder Idioten oder Trottel, die ihre Macht nur zum Spaß ausüben. Wenn es einen Ratschlag gibt, den ich Menschen geben kann, die mit der Politik am Arbeitsplatz zu kämpfen haben, dann ist es dieser: Gehe davon aus, dass die Leute klug sind und die besten Absichten haben. Das ist kein warmherziges Kumbaya-Mantra, sondern ein taktischer, praktischer Rat, der dir hilft, als Produktmanager zu überleben und erfolgreich zu sein.

Als ich bei einem Verlag arbeitete, war ich damit beauftragt, ein Produkt zu entwickeln, das auf eine große Menge an Inhalten angewiesen war. Der Vizepräsident, der für die Inhalte zuständig war, setzte alles daran, die Inhalte einzuschränken, die wir verwenden konnten. Ich war wütend. "Das ist ein ekelhaftes Machtspiel und er sollte sich schämen. Mein kluger Manager riet mir, mit dem Vizepräsidenten zu sprechen. Das tat ich (überraschenderweise in aller Ruhe), und er erklärte mir, wie die Beschaffung von Inhalten eigentlich funktioniert. Wenn er mir gab, was ich wollte, würde das unseren Content-Partner höchstwahrscheinlich verärgern. Es könnte ihn sogar aus dem Geschäft bringen. Er wollte seine Beziehung und die langfristige Lebensfähigkeit dieser Quelle schützen. Nun denn.

Er war kein Idiot. Nicht einmal ein Idiot. Ich war zwar immer noch nicht mit der Entscheidung einverstanden, aber ich verstand, warum er sie getroffen hatte, und ich musste definitiv nicht wütend darüber werden. Seine Ziele und, was noch wichtiger ist, seine Kunden waren anders als meine. Es war eine sehr demütigende Erfahrung.

Seitdem habe ich in vielen anderen Branchen gearbeitet - im Einzelhandel, in den sozialen Medien, in der Lebensmittel- und Getränkeindustrie - und diese Dynamik ist immer wieder zu beobachten. Andere Bereiche des Unternehmens optimieren oft für andere Dinge: andere Ziele und andere Kunden. Ich weiß, dass Produktmanager/innen oft dazu angehalten werden, eng mit ihrem unmittelbaren Team zusammenzuarbeiten, aber in mancher Hinsicht ist es sogar noch wichtiger, Menschen in anderen Bereichen des Unternehmens kennenzulernen. Mit deinem Team hast du immer noch dieselben Ziele und alltäglichen Sorgen. Aber es kann sein, dass du mit einem anderen Teil des Unternehmens völlig uneins bist und es nicht einmal merkst. Du denkst vielleicht an die Bedürfnisse der Endverbraucher/innen, bist dir aber nicht bewusst, dass die Beziehungen zu den Lieferanten und Partnern, die für den Fortbestand des Unternehmens wichtig sind, nicht funktionieren.

Und jetzt kommt's: Als Produktmanager ist es deine Aufgabe, das alles herauszufinden. Deine Rolle ist per Definition funktionsübergreifend, aber die Rolle der anderen nicht. Du wurdest eingestellt, um zu kommunizieren, während jemand anderes vielleicht eingestellt wurde, weil er gut in Mathe ist oder gute Beziehungen zu Lieferanten hat. Kommunikation ist dein Job, und du kannst nicht erwarten, dass alle anderen das auch können. Meine zwei Lieblingsfragen auf sind: "Was sind deine Ziele?" und "Wofür optimierst du?" Ich benutze sie oft und mit großer Aufrichtigkeit, und mein Leben als Produktmanager (und das Leben eines Nicht-Produktmanagers!) ist dadurch viel besser geworden.

Egregious Overcommunication in der Praxis: Drei häufige Kommunikationsszenarien für Produktmanager

Obwohl Produktmanager/innen mit vielen verschiedenen Menschen in vielen verschiedenen Kontexten kommunizieren, gibt es ein paar Szenarien, die immer wieder vorkommen. In diesem Abschnitt sehen wir uns drei häufige Kommunikationsszenarien für Produktmanager/innen an und wie du sie angehen kannst. Nimm dir nach der Lektüre der einzelnen Szenarien einen Moment Zeit, um darüber nachzudenken, wie du sie angehen würdest. Das wird dir helfen, die Vorschläge mit dem Rhythmus, den Persönlichkeiten und den Problemen, die in deinem Unternehmen eine Rolle spielen, in Einklang zu bringen.

Szenario Eins

Kundenbetreuer: Wir müssen diese Funktion in zwei Wochen bauen, sonst verlieren wir unseren größten Kunden.

Entwickler: Die Entwicklung dieser Funktion wird mindestens sechs Monate dauern, wenn wir etwas machen wollen, das auch nur annähernd stabil und performant ist.(Abbildung 4-1)

Abbildung 4-1. Ein "Notfall"-Antrag trifft auf technischen Widerstand

Was wirklich los ist

Dies ist ein klassischer und häufiger Fall von falsch ausgerichteten Anreizen. Die Aufgabe des Kundenbetreuers ist es, Kunden zu binden. Die Aufgabe des Entwicklers ist es, eine Software zu entwickeln, die nicht peinlich und fehlerhaft ist und mit Klebeband und Schnüren zusammengehalten wird. Für den Kundenbetreuer besteht kein direkter Anreiz, sich darum zu kümmern, ob die Software leistungsfähig ist. Für den Entwickler wiederum besteht (normalerweise) kein direkter Anreiz, sich darum zu kümmern, ob der Kunde gehalten wird - ein unvernünftiger Kunde weniger ist eine Reihe von Last-Minute-Anforderungen weniger. Sowohl der Kundenbetreuer als auch der Entwickler setzen sich für ihre eigenen kurzfristigen Ziele ein.

Was du tun könntest

Sowohl der Kundenbetreuer als auch der Entwickler gehen hier von mehreren Annahmen aus. Braucht dieser Kunde wirklich genau diese Funktion? Werden wir den Kunden wirklich verlieren, wenn wir sie nicht bauen? Versteht der Entwickler die Bedürfnisse des Kunden wirklich, oder nutzt er den Zeitrahmen von sechs Monaten, um ein Nein zu rechtfertigen? Anstatt über die spezifische Funktion zu diskutieren, die dein Kundenbetreuer fordert, solltest du dich mit dem grundlegenden Problem des Kunden auseinandersetzen. Beziehe den Kundenbetreuer als Partner mit ein, um die Bedürfnisse des Kunden besser zu verstehen, und den Entwickler als Partner, um mögliche Lösungen zu erforschen. Vielleicht stellst du fest, dass gar keine neue Funktion erforderlich ist, sondern nur ein kurzes Gespräch mit dem Kunden, um eine bestehende Funktion besser zu verstehen.

Zu vermeidende Muster und Fallen

Okay, dann lass uns entscheiden, ob es sich um zwei Wochen oder sechs Monate handelt.

Sowohl zwei Wochen als auch sechs Monate könnten völlig willkürliche Zeitrahmen sein. Der Kundenbetreuer könnte "zwei Wochen" als Abkürzung für "sehr bald" gesagt haben, und der Entwickler könnte mit "sechs Monaten" gekontert haben, um zu sagen: "Nein, daran will ich nicht arbeiten." Vermeide die falsche Wahl und komm zum Kern des Problems.

Ja, ich stimme zu, dass wir das Problem in zwei Wochen lösen müssen. Und ich stimme zu, dass die Software leistungsfähig und stabil sein muss.

Versuche nicht, beide Seiten zu spielen! Das wird einfach nicht funktionieren. Es gibt wahrscheinlich Möglichkeiten, sich auf ein zielorientierteres Gespräch einzulassen, und es ist deine Aufgabe als Produktmanager, dieses Gespräch zu erleichtern. Im besten Fall entdeckst du eine Lösung, die weniger als zwei Wochen in Anspruch nimmt und nur minimale Bedenken hinsichtlich Leistung und Stabilität hervorruft. Halte das Gespräch offen und forschend, aber versuche nicht, schnell zu punkten, indem du den Leuten sagst, was sie hören wollen.

Unser Planungsprozess findet alle zwei Wochen statt, und wir sind alle voll. Melde dich später wieder bei mir.

Wenn du in einer Welt mit wirklich fixen Iterationen arbeitest, werden kurzfristige Ergänzungen wie diese oft um jeden Preis vermieden, und es gibt gute Gründe, diese Leitplanken aufrechtzuerhalten. Aber gute Gründe halten oft nicht davon ab, solche Anfragen zu stellen, und ich habe festgestellt, dass es hilfreicher ist, sie zu bewerten und nach Prioritäten zu ordnen, als sie ganz zu verscheuchen. (Mehr dazu in Kapitel 12, "Prioritätensetzung: Wo alles zusammenläuft") .

Szenario Zwei

Designer: Ich habe vier verschiedene Versionen dieses Designs gemacht - welche davon gefällt dir am besten?(Abbildung 4-2)

Abbildung 4-2. Ein Designer präsentiert mehrere Optionen

Was wirklich los ist

Der Designer hat vielleicht vier Versionen erstellt, die seiner Meinung nach gleich gut für die Ziele des Projekts geeignet sind, aber subjektive Unterschiede aufweisen (z. B. bei der Farbwahl), bei denen er keine klare Meinung hat. Oder der Designer ist sich über die Ziele des Projekts nicht im Klaren und versucht, die Verantwortung abzuwälzen, indem er dich zwingt, eine Entscheidung zu treffen. Oder der/die Designer/in hat einen Ansatz, von dem er/sie hofft, dass du ihn/sie wählst, und hat ein paar "Dummy"-Optionen erstellt, um den Eindruck zu erwecken, du hättest die Wahl.

Was du tun könntest

Dies ist eine Gelegenheit, dein Vertrauen in den Designer zu zeigen, indem du ihn fragst, welche Option seiner Meinung nach am besten mit den Zielen des Projekts übereinstimmt. Wenn er der Meinung ist, dass eine Option eindeutig die bessere ist, veranlasst ihn das dazu, diese Wahl im Kontext der Ziele und nicht der Präferenzen zu betrachten. Und wenn er keine eindeutige Präferenz hat, zwingt euch das vielleicht dazu, darüber zu sprechen, ob die Ziele des Projekts klar genug sind. Wenn mehrere Optionen gleichwertig erscheinen, könntest du mit deinem Designer besprechen, wie ihr diese Optionen testen könnt, um herauszufinden, welche die Ziele des Projekts am besten erfüllt. Schließlich kann dein Team unterschiedliche Meinungen haben - aber ihr solltet immer die gleichen Ziele haben.

Zu vermeidende Muster und Fallen

Ich mag Wahl B - nehmen wir die!

Das ist eine einfache und verlockende Antwort. Immerhin hat der Designer dich gefragt, was du denkst. In manchen Fällen ist die Frage wirklich so einfach: Dem Designer ist es egal und er will nur, dass du zwischen ein paar subjektiven Varianten wählst. Aber es ist besser, wenn du ein bisschen tiefer gräbst, als eine Entscheidung zu treffen, ohne klare Gründe zu haben, die über deine persönlichen Vorlieben hinausgehen.

Lass uns alle vier vor der ganzen Gruppe vorstellen und sehen, was sie davon halten!

Lange Zeit war das meine Strategie, bis mich ein aufmerksamer UX-Designer darauf hinwies, dass ich unseren visuellen Designer mit "Design by Committee" an den Rand der Kündigung trieb. Es gibt nichts Schlimmeres, als wenn dir ein ganzer Haufen Leute ihre Meinung über die Aufgabe, für die du eingestellt wurdest, aufdrückt.

Das ist mir egal. Was immer du willst, ist in Ordnung.

Es ist sehr selten, dass sich jemand die Mühe macht, etwas viermal zu tun, es sei denn, es gibt einen Grund dafür. Weisen Sie diese Mühe - und die tieferen Probleme, die dahinter stecken könnten - nicht ab, indem Sie sich weigern, sich darauf einzulassen.

...Und eine Bonusfrage

Was wäre, wenn der Designer mir nur eine Option geben würde?

Vermeide die Versuchung, sofort mit einer Kritik anzufangen, auch wenn sie sich wie eine großzügige Kritik anfühlt. Bitte den Designer stattdessen, dir zu erklären, wie er zu seinem Entwurf gekommen ist. Das gibt dir die Möglichkeit, mehr darüber zu erfahren, wie der Designer die allgemeinen Ziele des Projekts versteht, und es könnte sein, dass du den einen oder anderen Kommunikationsfehler entdeckst, den dann ausräumen kannst.

Szenario Drei

Entwickler: Tut mir leid, ich verstehe einfach nicht, warum du uns zwingen willst, diesen ganzen unnötigen Prozess zu verfolgen. Kannst du mich nicht einfach meine Arbeit machen lassen?(Abbildung 4-3)

Abbildung 4-3. Ein Entwickler protestiert gegen "unnötige Verfahren".

Was wirklich los ist

Auch wenn Sätze wie "Dieser Prozess ist einfach viel zu schwer für uns", "Ich will diese ganzen unnötigen Schritte nicht mitmachen" oder "Das ist doch alles Großkonzern-Bullshit" auf den ersten Blick wie das allgemeine Gemurre von Prozessverweigerern klingen mögen (wir werden in Kapitel 7 näher darauf eingehen), sind sie doch wichtige und wertvolle Signale dafür, dass ihr noch einiges zu tun habt. Wenn dein Team sich nicht in deinen Entwicklungsprozess eingebunden fühlt und/oder diesen Prozess als Hindernis für die Erledigung seiner Arbeit ansieht, hast du in deiner Rolle als Kommunikator und Moderator möglicherweise grundlegend fehlgeschlagen, selbst wenn es dir gelungen ist, dein Team dazu zu bringen, einen bestimmten Entwicklungsrahmen oder -prozess formell zu übernehmen.

Was du tun könntest

Zuallererst solltest du das Feedback deines Entwicklers ernst nehmen. Bedanke dich bei ihm für seine Offenheit und mach ihm klar, dass dein Team nur dann erfolgreich sein kann, wenn die Leute ihre Bedenken offen äußern. Anstatt zu versuchen, seine Bedenken in einem persönlichen Gespräch auszuräumen, solltest du ihn fragen, ob er sein Feedback bei der nächsten Teambesprechung wiederholen kann. Dadurch wird deutlich, dass du nicht der brutale Durchsetzer der Prozesse deines Teams sein willst, sondern eher ein Vermittler, der dem Team hilft, die Prozesse zu finden und einzuführen, mit denen es seine Ziele am besten erreichen kann.

Zu vermeidende Muster und Fallen

Probiere es einfach eine Weile aus - ich verspreche dir, dass es dein Leben einfacher machen wird!

Es gibt einen feinen, aber entscheidenden Unterschied zwischen "Ich verspreche, dass es funktionieren wird" und "Lasst uns zusammenarbeiten, damit es funktioniert". Jemanden in deinem Team aufzufordern, Prozessänderungen unkritisch zu akzeptieren, ist eine grundsätzlich ablehnende Geste und keine verbindende und unterstützende Geste. Wenn dein Team sich nicht in seinen Prozess eingebunden fühlt, wird dieser wahrscheinlich fehlschlagen.

Du hast Recht. Vergiss diesen Prozess-Kram - woran willst du arbeiten?

Auch wenn es sich wie eine ermutigende oder zumindest angemessen respektvolle Geste anfühlt, wenn man den Ingenieuren freie Hand lässt, um zu arbeiten, woran sie wollen, so bleiben sie doch von den Auswirkungen ihrer Arbeit auf die Nutzer und das Unternehmen weit entfernt. Irgendwann wird jemand dein Team für die tatsächlichen Ergebnisse seiner Arbeit zur Rechenschaft ziehen. Und je länger dein Team keinen Prozess hat, der seine Arbeit mit den Zielen deines Unternehmens in Verbindung bringt, desto schlimmer wird der Tag der Abrechnung sein.

Ich weiß, ich weiß, ich bin die Schlimmste, aber mein Chef hat gesagt, dass wir ein paar mehr Prozesse einführen sollten. Ich verspreche, dass ich versuchen werde, es so schmerzlos wie möglich zu machen!

Wie wir bereits besprochen haben, ist Selbstabwertung ein gängiger Bewältigungsmechanismus für Produktmanager/innen. Aber wenn du dich selbst zum unfreiwilligen Spielball in dem Bestreben machst, jemand anderem sinnlose Prozesse aufzuzwingen, garantierst du, dass der Prozess sinnlos sein wird. Wenn du nicht glaubst, dass der Prozess, den du verwendest, der richtige ist, aber dein Chef einen Prozess verlangt hat, ist es an der Zeit, dass du ein unbequemes Gespräch mit deinem Chef führst.

Zusammenfassung: Im Zweifelsfall kommuniziere!

Die tägliche Arbeit der Kommunikation erfordert Aufmerksamkeit, Anpassungsfähigkeit und Fingerspitzengefühl. Aber die wichtigsten Entscheidungen, die du als Produktmanager/in triffst, hängen oft von einer einfachen Frage ab: Bist du bereit, etwas anzusprechen, das offensichtlich oder unbequem erscheint oder beides? Je furchtloser du diese Gespräche führst und je mehr Raum du in deinem Team und deiner Organisation für diese Gespräche schaffst, desto erfolgreicher werden du und dein Team sein.

Deine Checkliste

• Übertreibe es nicht mit der Kommunikation. Wenn du dir nicht sicher bist, ob etwas erwähnenswert ist, erwähne es.

• Hab keine Angst davor, "das Offensichtliche" zu fragen. Je offensichtlicher etwas erscheint, desto beharrlicher solltest du darauf bestehen, dass alle auf derselben Seite stehen.

• Erstelle ein Dokument wie "Guter Produktmanager/schlechter Produktmanager", in dem die Verhaltenserwartungen an Produktmanager in deinem Unternehmen klar dargelegt werden.

• Vermeide es, Sätze mit Phrasen wie "Es wäre toll, wenn..." oder "Meinst du, es wäre möglich, dass..." zu beginnen, die die Verantwortung ablenken. Wenn du um etwas bittest, dann bitte darum - und sei dir darüber im Klaren, warum du es verlangst.

• Versuche, Gespräche über Emotionen und Absichten auf das Ergebnis zu lenken, indem du Fragen stellst wie "Hat diese Situation das gewünschte Ergebnis gebracht?"

• Vergiss nie, dass "Sieht gut aus" oft "Ich passe nicht auf" bedeutet, und strebe immer ein engagiertes, positives und spezifisches Feedback und eine Beteiligung an.

• Stelle sicher, dass die Mitarbeiter/innen die Möglichkeit haben, ihre Meinung in Meetings zu äußern, indem du "widersprechen und sich verpflichten" oder eine andere Methode anwendest, die ähnliche Ziele in deiner Organisation erreicht.

• Erinnere dich daran, dass Menschen unterschiedliche Kommunikationsstile haben. Schreibe niemanden als "schlechten Kommunikator" ab oder gehe davon aus, dass er schlechte Absichten hat, wenn sein Stil anders ist als deiner.

• Vermeide die Versuchung, ein "Meeting-Hasser" oder "E-Mail-Hasser" zu sein. Entschuldige dich nicht, wenn du jemanden um seine Zeit bittest, sondern sorge dafür, dass seine Zeit gut genutzt wird.

• Frag deine Teammitglieder nach den wertvollsten und am besten durchgeführten Meetings, an denen sie teilgenommen haben. Arbeite dann mit ihnen zusammen, um eine klare Vorstellung davon zu entwickeln, wie ein "gutes" Meeting für dich aussieht.

• Mache aus taktischen Gesprächen über Dinge wie Designentscheidungen oder Entwicklungszeitpläne strategische Gespräche über Geschäftsziele und Nutzerbedürfnisse.