Die Rolle des Product Managers hat in den letzten Jahren in der Tech-Branche an Popularität gewonnen. Da immer mehr Unternehmen PMs in ihre Organigramme aufnehmen, wird noch viel mit Team-Setups experimentiert, um die bestmögliche Abstimmung zwischen Produkt und Engineering zu finden. Diese beiden Funktionen arbeiten jetzt so eng zusammen wie nie zuvor, und obwohl dies als Rezept für leistungsstarke Teams gilt, kämpfen viele Unternehmen noch immer damit, gute Zusammenarbeit zu erreichen.
Strategien, um es zum Funktionieren zu bringen, sind auf Martin Fowlers Website gut abgedeckt. In diesem Artikel konzentriere ich mich mehr auf die Perspektive des Ingenieurs und darauf, was unsere Erwartungen an einen guten Product Manager sind.
Was man nicht erwarten sollte#
Als Ingenieur selbst habe ich Reibungen von beiden Seiten beobachtet, aber auch einige produktive Partnerschaften. Während man argumentieren kann, dass das Team oder die Organisation das Ergebnis beeinflussen kann, hängt es meist davon ab, wie sehr jede Funktion bereit ist, mit der anderen zusammenzuarbeiten.
Machen wir eine Übung und denken wir über diese Erwartungen umgekehrt nach. Ich glaube, die PM-Rolle steckt noch in den Kinderschuhen, und deshalb nimmt sie verschiedene Formen an, besonders in weniger reifen Unternehmen, die beginnen, ihre Produktentwicklungsstrategien aufzubauen.
Excel-Manager#
Ein Ass mit Makros und Meister darin, Fortschritte im wöchentlichen Steering zu berichten. Das gesamte Projekt sieht aus wie ein geometrisches Kunstwerk mit übereinander gestapelten Balken. Der Excel-Manager kümmert sich wenig um den Produktlebenszyklus und wird alle Chips darauf setzen, dass die Entwickler sich auf diese Deadlines festlegen.
Featurist#
Top-Spezialist für 360-Marktforschung. Sie weiß alles über Steve Jobs und die Geschichte des iPod, kümmert sich um den Produktlebenszyklus, kann sich aber nicht leisten, Zeit mit dem Aufbau von Strategien zu verlieren, weil “Details wichtig sind, es lohnt sich zu warten, um es richtig zu machen”.
Pensionierter Programmierer#
Unzufrieden mit der Vorstellung, für immer Code-Monkey zu sein, hat sie das Engineering auf der Suche nach Glück und Erfolg verlassen. Mit Bedauern auf das Leben zurückblickend, das sie hinter sich gelassen hat, ist der pensionierte Programmierer ein guter Verbündeter und bereit, die Erwartungen der Führung zu managen.
Die Hand des Königs#
Warum seine Ideen teilen, wenn wir alle hier sind, um einem größeren Zweck zu dienen? Wie ein Allpass-Filter geht die Hand des Königs kein Risiko ein, dass Finger auf sie zeigen. Sie ist nur die Botin.
Die Kernidee des Product Managements#
Was die obigen Stereotypen (absichtlich) gemeinsam haben, ist, dass alle Geschäftsentscheidungen an die Führungsebene delegieren, was meiner Meinung nach der größte Game-Changer bei der Product-Manager-Rolle ist. Mehr als Design oder Implementierung ist der PM für den gesamten Produktlebenszyklus verantwortlich, von der Idee über die Implementierung bis zum Kundenfeedback und der Marktperformance.
Die erfolgreichsten Teams, in denen ich gearbeitet habe, sind die, in denen der PM dabei ist, manchmal sogar unter derselben Führungs-/Berichtslinie. PM & EM: Rules of engagement etabliert 3 grundlegende Regeln: Vertrauen, gemeinsame Verantwortlichkeit und getrennte Ownership.
Das Team ins Geschäft einbinden#
Eine der Dinge, die mich immer gestört haben, ist, wie wenig Ingenieure über die Produkte wissen, die sie bauen. Überraschung oder nicht, es ist möglich, ein ganzes Arbeitsleben zu verbringen, ohne zu wissen, wer die Software nutzt, die man baut, und wie viel Geld sie einbringt. Wiederkehrende Diskussionen mit dem Team über die Performance des Produkts sind ein kraftvoller Weg, Innovation zu fördern und die Motivation hoch zu halten.
Eine Roadmap, sie alle zu beherrschen#
Das Erstellen einer technischen Roadmap während der Arbeit in einem Produktteam war eine der kontraproduktivsten Erfahrungen, die ich je gemacht habe. Während es wichtig ist, technische Schulden im Auge zu behalten, zeigt mir die Erfahrung, dass diese Aufgaben ohne Buy-in vom Produkt nie implementiert werden.
Ein guter PM kann die Kosten verstehen, technische Schulden nicht zu bezahlen, und wird sie als Teil der Produktstrategie einbeziehen.
Zieldaten, keine Deadlines#
Wenn du einen Ingenieur stressen willst, frage ihn nach einer ETA oder bitte ihn, sich auf eine von der Führung gesetzte Deadline festzulegen. Software unter Druck zu bauen schadet dem Geschäft nur, da es die Leute dazu zwingt, mehr Fehler zu machen.
Während es auch nicht akzeptabel ist, dass Ingenieure frei sind, große Mengen an Zeit zu verschwenden, sollte der PM flexibel genug sein, entweder das Zieldatum zu verschieben oder den Umfang zu reduzieren.
Schlussbemerkungen#
Was der perfekte PM sein sollte, ist noch eine offene Frage, aber es ist klar, dass wenn sowohl Produkt als auch Engineering daran arbeiten, eine effektive Partnerschaft aufzubauen, die Ergebnisse weitaus produktiver sein können. Aus der Sicht eines Ingenieurs ist der ideale PM kein Stakeholder, sondern ein Peer, ziemlich genau wie der CEO eines kleinen Startups innerhalb des größeren Unternehmens.
