Sie sind ein Produktmanager, der für die Entwicklung eines neuen Produkts verantwortlich ist, und Sie haben monatelang recherchiert, um eine Richtung und eine Vision für das Produkt festzulegen. Die Produktentwicklung läuft gut, und jetzt haben Sie andere Abteilungen wie Marketing, Grafikdesign, Vertrieb und Betrieb einbezogen, um eine Support-Kette für das Produkt aufzubauen.
Wenn sich mehr Manager dieser Bereiche engagieren, werden viele von ihnen ihre eigenen Ansichten darüber haben, wie die Dinge funktionieren sollten. Als Techniker können Sie sich beispielsweise vorstellen, dass das Entwicklungsteam eine neue Architektur implementiert, die Webdienste verwendet, um Ihren Kunden und internen Entwicklern benutzerdefinierte APIs zur Verfügung zu stellen, die den anderen Entwicklern helfen, Ihr Produkt durch die Nutzung der bereitgestellten Dienste zu erweitern. Das Marketing- und Betriebspersonal kann die Architekturänderung jedoch als unwichtig ansehen, da sie nicht über das technische Wissen verfügen, um zu verstehen, wie die neue Architektur andere Produkte unterstützen könnte, die mit dieser Technologie erstellt wurden.
Was Sie wollen, ähnelt dem, was Marketing und Betrieb wollen, aber da sie kein Verständnis für Softwareentwicklung haben, verstehen sie möglicherweise nicht, woran die Entwickler arbeiten. Sie nutzen dann ihren Einfluss, um andere in der Organisation davon zu überzeugen, die Architekturentwicklung zu überspringen.
Während es vorteilhaft sein kann, Abteilungsleiter in Besprechungen einzubeziehen – anstatt nur die Ressourcen, die sie Ihrem Team zugewiesen haben – ist es in diesen Fällen manchmal schwieriger, die Richtung Ihres Produkts zu kontrollieren.
Welche Tipps oder Anregungen gibt es, um Unterstützung von anderen Führungskräften zu gewinnen, ohne dass diese zwangsläufig das Projekt mit ihrem Einfluss übernehmen?
Ich würde Ihre Frage so beantworten, dass es um den "Umgang mit anderen Managern" ging, denn "andere verhindern" würde bedeuten, dass Sie die Meinung anderer nicht hören wollen und vielleicht etwas Flexibilität verlieren.
Ein großer Teil der Rolle eines Produktmanagers ist genau das, was Sie beschreiben. Manchmal sind die neuen Vorschläge oder Ideen großartig, aber manchmal müssen Sie die ursprüngliche Idee bewahren, um Verzögerungen zu vermeiden und sicherzustellen, dass das Endprodukt sinnvoll ist.
Je nachdem, wo die Vorschläge oder neuen Anforderungen liegen, verwende ich unterschiedliche Taktiken, aber hier sind einige (jede mit ihren eigenen Vor- und Nachteilen):
Die obigen Ideen sind zwar nicht erschöpfend, aber die wichtigsten Taktiken, die ich in der Vergangenheit als hilfreich empfunden habe, um nicht umsetzbare Vorschläge abzuwehren. Im Allgemeinen finde ich, dass ich viel bessere Ergebnisse mit dem „weichen Verkaufen“ erziele und versuche, angenehm und zugänglich zu sein, indem ich meine Argumentation erkläre und Ideen aufschiebe, anstatt sie abzulehnen.
Ich habe eine strengere Antwort auf Ihre Frage gefunden. Ich würde es als "Was nicht tun"-Antwort behandeln, aber wenn Sie die Disputanten loswerden möchten, können Sie Folgendes versuchen:
Das ist die Herausforderung, wenn Sie Ihre eigenen Projekte durchführen. Da Sie eine Vision haben und Ihr Produkt in- und auswendig kennen, ist es schwieriger, die Vision, die Sie haben, in Begriffe zu übersetzen, die andere Menschen verstehen können. Mein Vorschlag ist, sich die Zeit zu nehmen, das, was die Entwickler bauen, in Begriffe zu übersetzen, die das Endergebnis beschreiben. Auf diese Weise können Marketing und Operations ihre Bemühungen an dem ausrichten, was Realität werden wird.
Der Schlüssel liegt in der Trennung der Benutzeranforderungen von der technischen Bereitstellung. Sie geben an, dass das, was Sie wollen, dem ähnelt, was Marketing und Betrieb wollen, also scheint die Seite der Benutzeranforderungen kein Problem für Sie zu sein – Sie wollen alle mehr oder weniger dasselbe.
Die eigentliche Herausforderung besteht also darin, die Marketing- und Betriebsleiter auf das „Was“ und nicht auf das „Wie“ zu konzentrieren. Sie haben die technische Verantwortung: Sie haben einen gewissen geschäftlichen Einfluss. Ein Ansatz, den ich in der Vergangenheit erfolgreich verwendet habe, ist etwa so: „Lassen Sie uns nicht auf die technischen Details eingehen, wie dies entwickelt wird. Ich werde die Fähigkeit liefern, das zu tun, was Sie wollen, und ich werde Ihnen auch etwas Flexibilität geben, um oder hinzuzufügen Funktionalität in der Zukunft ändern. Sie wollen sicher nicht, dass ich Kompromisse bei der Zukunftsfähigkeit mache, nur um gerade jetzt ein paar Tage zu sparen, oder?“ Sie müssen vielleicht an ein paar Bereiche denken, in denen sie zukünftige Änderungen wünschen, nur um dies in einen Kontext zu stellen, aber es funktioniert.
Persönlich würde ich zuerst priorisieren, was die wirklichen Bedürfnisse sind, die den Erfolg des Kunden ermöglichen, und was die Produktvision ist, die in der Unternehmensstrategie enthalten ist.
Vielleicht würde eine API tatsächlich helfen und ist ein hervorragender technologischer Fortschritt, aber bietet sie heute wirklich einen Mehrwert?
Es gibt viele „Frameworks“ für die Priorisierung oder Filterung, wie WSJF, das in SAFe vorgeschlagen wird. Moskau ist ein anderes.
Wenn Sie eine "Genehmigung" für die technischen Funktionalitäten erhalten möchten, betten Sie diese in die "Funktionalität" ein. Stellen Sie sicher, dass das Funktionale das Ziel ist, wo das Technische das Mittel dazu ist.
jmort253
Bartosz Rakowski