Die Rolle des Produktmanagers ist ein Fehler
(sollecitom.github.io)- Wenn Software-Produktunternehmen product-led als „eine Struktur, in der der PM alle Entscheidungen trifft“ missverstehen, wenden sie ein Modell, das nur zu außergewöhnlichen Gründerpersönlichkeiten passt, auf gewöhnliche Karriere-PMs an
- Bei einem Ansatz, der einer einzelnen Führungsperson die Produktkontrolle gibt, ist nicht der Ansatz selbst entscheidend, sondern wem man sie anvertraut; er setzt seltene Personen mit Vision, Charisma, technischer Stärke und festen Überzeugungen voraus
- Wenn gewöhnliche PMs zu viel Macht bekommen, werden Daten, Frameworks, Freigabeprozesse, Meetings und Rollensysteme nicht zu Werkzeugen der Urteilsbildung, sondern zu Schutzschilden für Verantwortungsvermeidung und Politik
- Diese Entwicklung treibt hervorragende Leute aus dem Unternehmen, und das Unternehmen bleibt in risikoarmen Aufgaben und internen Prozessen stecken und verliert Vision und Talent
- Die Alternative ist keine Struktur rund um den PM-Titel, sondern ein Team aus Menschen, die in ihren jeweiligen Bereichen besessen von Technik und Qualität sind und Product Discovery, Observability, Engineering, Design, Business und Domänenwissen gemeinsam bearbeiten
Das Problem, product-led als PM-Monopol zu missverstehen
- Viele Software-Produktunternehmen werden nicht von Menschen gegründet, die viel Erfahrung im Bau von Softwareprodukten haben, sondern von Menschen, die gut in Finanzierung und im Verständnis der Zielbranche sind
- Solche Gründer starten ein Unternehmen auf Basis ihrer Branchenerfahrung und Beziehungen; wenn sie jedoch alle Entscheidungen selbst treiben, kann die Überzeugung eines Domänenexperten dem Unternehmen schaden
- Manche Gründer erkennen an, dass sie gefährlich sein könnten, und stellen jemanden ein, dem sie Entscheidungen übertragen
- Dabei entsteht das Missverständnis: „Wir dürfen keine Service-Organisation sein, sondern müssen ein Produktunternehmen werden; und weil Produktunternehmen product-led sind, muss der PM verantwortlich sein“
- Product-led bedeutet hier nicht, dass der PM alle Entscheidungen trifft
- Wenn es Widerspruch gibt, kommt häufig das Gegenargument, dass großartige Unternehmen wie Amazon, Apple und Tesla ebenfalls einer einzelnen Person die Kontrolle übertragen
- Viele großartige Unternehmen geben einer Einzelperson die Kontrolle, aber nicht alle großartigen Unternehmen nutzen dasselbe Modell
Voraussetzungen des Modells mit einem einzelnen Entscheider
- Das Modell, die Kontrolle über das Unternehmen einer Person zu geben, ist nicht unbedingt falsch; Erfolg oder Misserfolg hängen davon ab, wem man sie gibt
- Personen wie Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel und Leonardo werden wegen ihrer Vision, ihres Charismas, ihres Selbstvertrauens, ihrer Resilienz und ihrer Exzellenz von der Öffentlichkeit verehrt
- Sie sind der Typ Mensch, der sich alternative Realitäten vorstellt, sich vollständig in die eigene Arbeit vertieft und durch Willenskraft große Veränderungen bewirkt
- Wenn es eine solche Person tatsächlich gibt, kann das Modell der Einzelkontrolle sehr wirkungsvoll funktionieren
Außergewöhnliche Persönlichkeiten sind keine gewöhnlichen PMs
- Große Persönlichkeiten waren keine Produktmanager
- Sie waren Künstler, Mathematiker, Erfinder, Wissenschaftler, CEOs und teils mehrere Rollen zugleich
- Sie waren mehr von ihrer Vision und ihrem Können besessen als von OKRs, KPIs, Daten oder den Meinungen anderer
- Außergewöhnliche Personen können starke Meinungen, ein großes Ego, ihre eigene Arbeitsweise, raue Kanten und Verachtung für Mittelmäßigkeit haben
- Wegen dieser Eigenschaften sind sie in normalen Unternehmen schwer einzustellen, und sie selbst wollen wahrscheinlich in den meisten Unternehmen nicht arbeiten
- Wenn man eine großartige Person findet, sie nicht behindert und ihre Intensität aushält, kann man ihr die Kontrolle über Produkt und Unternehmen anvertrauen
- Realistisch betrachtet ist es schwer, solche Menschen zu finden; sie wollen womöglich nicht mit einem zusammenarbeiten, oder das Unternehmen hält ihr Ego und ihre Intensität nicht aus
Wenn man eine Struktur für große Persönlichkeiten auf gewöhnliche PMs anwendet
- Der größte Fehler besteht darin, ein Betriebsmodell einzuführen, das eine außergewöhnliche Person erfordert, ohne eine außergewöhnliche Person zu haben
- Karriere-PMs, die ein Unternehmen bequem einstellen kann, seien in der Regel keine Personen dieses Niveaus, so die Kritik
- Sie werden als Business-Lakaien, Framework-Fanatiker, Fachexperten, ehemalige Macher auf der Karriereleiter, Metrik-Junkies, MBA-Absolventen usw. beschrieben
- Wenn man „product-led“ so versteht, dass der PM alle Entscheidungen trifft, und dafür einen Karriere-PM einstellt, kann das fatal sein
- Weil diesen PMs Vision, Charisma, Expertise, feste Überzeugungen und technische Fähigkeiten fehlen, bewegen sie sich sicherheitsorientiert und politisch
- Da sie ihre eigenen Defizite kennen, wiederholt sich ein Verhalten, bei dem sie Erfolge für sich beanspruchen und Verantwortung vermeiden
Wie Daten und Prozesse zu Verteidigungsmitteln werden
- Der erste Schritt ist die Bewaffnung von datengetriebener Entscheidungsfindung
- Ohne anzuerkennen, dass sich für jede Behauptung unterstützende Daten finden lassen, stellen sie nur ihre eigene Entscheidung als durch Daten rational dar
- Wenn etwas schiefgeht, geben sie dem Markt, der Datenqualität oder dem Pech des Unternehmens die Schuld und behaupten, es sei nicht ihre Verantwortung
- Der nächste Schritt ist, für alles Frameworks und Rollen einzuführen
- Es tauchen 18-stufige Karriere-Frameworks, quartalsweise Performance Reviews, PI Planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe usw. auf
- Gründe für Vorwürfe werden dann: Prozess nicht befolgt, nicht datengetrieben, zu wenig Dokumentation, Dokumentation nicht aktuell
- In der Organisation entstehen Rollen wie Director of KPIs, Deputy Director of Product Operations oder Global Head of Digital Whiteboard Solutions
- Für alles braucht es Freigaben, und kein Prozess oder Bereich steht vollständig unter der Kontrolle einer einzelnen Person
- In großen Gremien kann jeder „Nein“ sagen, aber niemand kann vollständig „Ja“ sagen
- Auch die Zahl der Meetings explodiert
- Statusberichte, Alignment-Meetings, 1:1s, Staff-Meetings, Strategiediskussionen, Kontext-Settings, Release-Go/No-Go, Projektberichte usw. nehmen zu
- Der letzte Schritt ist, viele schlechte Leute einzustellen
- Eingestellt wird danach, ob jemand keine Bedrohung darstellt; Anzeichen von Exzellenz werden zum Ablehnungsgrund
- Der ideale Hire wird zu einer Allzweckperson, die ohne Widerspruch oder Interesse an Qualität die zugewiesene Arbeit irgendwie erledigt
- Die Zahl der PMs steigt stark, und in jedem Team und Bereich entstehen PM-Hierarchien, die dasselbe Verhalten wiederholen
Was die Organisation verliert
- Sobald die Entwicklung beginnt, dass mittelmäßige Menschen Macht übernehmen, gehen herausragende Menschen letztlich weg
- Entweder werden sie von mittelmäßigen Diktatoren verdrängt, oder sie gehen von selbst, weil sie die Umgebung nicht aushalten
- Das Arbeitstempo kommt zum Stillstand, und etwas umzusetzen wird schmerzhaft, ein großes Commitment und ein riskantes Unterfangen
- Große Visionen werden als unrealistisch behandelt und schnell verworfen
- Die Arbeit des Unternehmens beschränkt sich auf niedrig hängende Früchte und sichere Entscheidungen
- Auch Menschen, die nicht besonders leidenschaftlich für ihr Handwerk sind, spüren den Schmerz und gehen; diejenigen, die abgestumpft genug sind zu bleiben, verschlimmern das Problem weiter
- Das Unternehmen verliert seine besten Talente, vergisst seine Vision, wird nach innen gerichtet und bedeutungslos
- Im besten Fall stirbt es irgendwann; im schlimmsten Fall überlebt es halb, während es leidenschaftliche Menschen in Zombies verwandelt, die ihre eigene Arbeit hassen
Die Alternative ist ein Team alltäglich herausragender Menschen
- Man kann auch ein erfolgreiches Produktunternehmen aufbauen, ohne eine außergewöhnliche Person zu finden, einzustellen, ihr die Kontrolle zu geben und ihre Intensität auszuhalten
- Die Alternative besteht darin, alltäglich herausragende Menschen einzustellen
- Jede Person sollte in einem bestimmten Bereich herausragend sein
- Sie sollte von ihrem Handwerk besessen und von Qualität getrieben sein
- Das Team sollte so zusammengestellt sein, dass sich die jeweiligen Exzellenzbereiche möglichst wenig überschneiden
- Statt individuelle Verantwortlichkeiten kleinteilig aufzuteilen, lässt man diese Menschen die Arbeit tun, die sie lieben, und ihre Zeit und Fähigkeiten für das Unternehmen einsetzen
- Auch solche Menschen können herausfordernd, stur, ego-stark, eigenwillig und launisch sein
- Wenn man ihnen gute Probleme gibt und sie hervorragende Arbeit leisten lässt, widmen sie sich vollständig dem Erfolg des Unternehmens
Wo Leader und PMs hingehören
- Man muss Führung nicht vollständig aufgeben; man kann Team Leads abschaffen und Bereichs-Leads als externe-interne Koordinatoren einsetzen
- Wenn man für jeden Bereich verantwortliche Leader einsetzt, sollte man diese Rolle mit Personen besetzen, die großen Persönlichkeiten nahekommen
- Gemeint sind Menschen, die in Vision, Charisma, Intensität, Leidenschaft und extremem Verhalten Jobs, Musk oder Bezos nahekommen
- Wenn man kurzfristig bequeme, folgsame Menschen, die weniger Aufmerksamkeit verlangen, in Verantwortungspositionen setzt, riskiert man, in die oben beschriebene Situation zu geraten
- Für die PM-Rolle im traditionellen Sinn sieht man in gut funktionierenden Unternehmen keinen Platz
- Dennoch braucht es Menschen, die von Bereichen besessen sind, die traditionell PMs übertragen wurden, etwa Product Discovery oder Product Observability
- Solche Menschen können früher den Titel PM gehabt haben, und das ist an sich kein Problem
- Der Grund für die Einstellung ist nicht der Titel, sondern ihre Obsession und Stärke
- Statt sie in eine separate PM-Rolle zu setzen, stellt man sie in ein Team mit Menschen, die von Engineering, Design, Performance, Business und Domänenwissen besessen sind
Es ist kein reines PM-Problem
- Wenn jemand ohne Vision, Charisma, Leidenschaft, technische Fähigkeiten und Willenskraft verantwortlich wird, entsteht dasselbe Problem
- Der Fokus auf PMs liegt daran, dass es in der Software-Produktentwicklung die Tendenz gibt, Personen mit dem Titel Product Manager verantwortlich zu machen
- Einige PMs sind wirklich außergewöhnlich und können in beiden Modellen sehr gut sein
- Aber solche PMs sind nicht zwingend besser als großartige Menschen mit anderem Hintergrund
- Solche PMs sind eine sehr kleine Minderheit, und die meisten Karriere-PMs kommen nicht annähernd an die Fähigkeit heran, durch Exzellenz zu führen
1 Kommentare
Hacker-News-Kommentare
In meinem aktuellen Unternehmen gibt es viele kluge Leute, aber aus verschiedenen Gründen keinen Produktmanager, und deshalb wird die Arbeit, die ein Produktmanager leisten sollte, einfach nicht gemacht.
Es gibt kaum Ingenieure, die Dinge wie die Pflege von Kundenbeziehungen, Nutzerinterviews, das Entdecken potenzieller Features, das Überzeugen der Führungsebene oder die politische Arbeit zur Ressourcenverteilung machen wollen.
In meinem früheren Unternehmen waren 2 von 3 Produktmanagern inkompetent und wurden entlassen, aber einer war wirklich hervorragend, und schon ein Teil seiner Zeit hat in weniger als einem Jahr mehr bewirkt, als mein jetziges Unternehmen in über zwei Jahren geschafft hat.
Ich stimme zu, dass es nicht genug gute Produktmanager gibt. Die Zahl der Menschen, die gute Produktmanager werden könnten, steigt linear mit der Bevölkerung, aber die Softwareindustrie ist exponentiell explodiert, sodass wir meiner Meinung nach 100-mal mehr PM-Rollen brauchen, als es tatsächlich großartige PMs gibt.
Technisch waren sie auch nicht, also haben sie keine Jira-Tickets verwaltet, und das Management der Führungsebene lag meist bei den Managern.
Diese Produktmanager schienen vor allem Meetings abzuhalten, mit der Führungsebene zu sprechen, mit Ingenieuren zu sprechen, Dokumente zu schreiben und ausufernde Sprint-Planungsmeetings zu moderieren.
Ein Produktmanager, der sich um Kunden-, Nutzer- und Ressourcenprobleme kümmert, könnte deutlich wertvoller sein.
Ich habe immer wieder gehört: „Wir sind ein Engineering-first-Unternehmen“, aber in der Praxis bedeutete das nur, dass die Engineering-Teams nach Belieben den neuesten Technologien hinterhergelaufen sind.
Es gibt 3,5 Kernprodukte, eigentlich eher 4,5, und jedes wurde mit einem anderen Tech-Stack gebaut; dazu kommen noch etwa 8 weitere Produkte, die wir wegen Legacy-Anforderungen unterstützen müssen. Es gibt keine Standardisierung oder Interoperabilität zwischen den Produkten, und kein Wissenstransfer findet statt, sodass die Entwicklungskosten explodieren.
Dieses Jahr musste ich zweimal Ingenieuren mit 20 Jahren Betriebszugehörigkeit erklären, warum es schlecht ist, dass eine API nur TLS 1.3 verwendet, eine andere 1.x und wieder eine andere nicht einmal TLS verlangt.
Die Kunden hassen uns. Für mein Produkt wurde zuerst das Marketingmaterial geschrieben und die Ingenieure sollten dann einfach irgendetwas bauen. Ein einzelner Schritt, um Oracle-Daten nach parquet zu übertragen, wurde mit drei Sprachen und zwei Zwischen-DBs (MySQL und PG) gebaut, und ich konnte gerade noch verhindern, dass auch noch Redis hineingezogen wird.
Glücklicherweise wurden wir vor zwei Jahren von einer Private-Equity-Firma übernommen und haben jetzt ein Ultimatum: Wenn wir kein Geld verdienen, ist Schluss. Das 20 Jahre alte Unternehmen war noch nie profitabel und immer nur ein Cost Center, und selbst wenn wir die Ziele verfehlen, wäre das Universum vermutlich besser dran, wenn die von uns geschaffene Software-Design-Katastrophe verschwindet.
Dumme Produktmanager werden zu pseudohaften Projektmanagern, die nur noch ein weiteres Aufgabenbuch nachverfolgen, während kluge Leute das Geschäft tief verstehen und dann entweder befördert werden oder gehen.
Diese Rolle ist auch schwer zu steuern. Manchmal bekommt man viel Anerkennung für die Arbeit anderer, manchmal bekommt man überhaupt keine Anerkennung und die Karriere stagniert.
Wenn man diese Rolle auf Engineering, Engineering-Management oder allgemeines Management abwälzt, schwächt das die Engineering-Kompetenz. Wenn man Ingenieure einstellen muss, sollte man sie nach dieser Fähigkeit auswählen und vor Außenstehenden schützen; wenn das Team auch noch die gesamte Interaktion übernehmen muss, stellt man Leute mit gemischten Fähigkeiten ein, und am Ende wird die Engineering-Seite verwässert.
Wenn man Produktmanager absichtlich knapp hält, kann das als Zwangsmechanismus dienen, damit sie sich auf die hohe Ebene und die Vision konzentrieren und vermeiden, zu tief einzusteigen, nutzlose Prozesse zu schaffen oder Features übermäßig detailliert zu definieren.
In der Tech-Branche, die durch mehr als zehn Jahre wachstumsgetriebener Niedrigzinsen aufgebläht wurde, konnten viele Leute offenbar schon allein dadurch erfolgreich sein, dass sie einfach zur Arbeit erschienen.
Ein verwirrender Text. Es heißt zwar: „Die PM-Rolle sollte abgeschafft werden“, zugleich aber auch: „Es braucht weiterhin jemanden, der die bisherigen Aufgaben eines PM übernimmt, aber nennt diese Person nicht PM, sondern einfach einen ganz normal hervorragenden Menschen.“
Der Autor hat offenbar schlechte Erfahrungen mit PMs gemacht, und die Bemerkungen über MBAs lassen diese Spuren erkennen; deshalb wirkt es, als wolle er das Kind mit dem Bade ausschütten.
Wenn ein Unternehmen wächst, entstehen spezialisierte Rollen und werden notwendig. Es gibt schlechte PMs, und es ist ein schwieriger Job, aber wenn wir den PM unseres Teams verlieren würden, wäre ich wirklich enttäuscht.
Vielleicht habe ich einfach nur gute Erfahrungen mit PMs gemacht, aber die PMs in unserem Unternehmen verstehen, was Kunden wollen und was das Produkt liefern muss, und gleichen gemeinsam mit dem Engineering Manager ausgewogen ab, was technisch möglich ist und wofür es Umsetzungskapazität gibt.
Wenn der Engineering Manager sagt: „Mit diesem Zeitplan geht es auf keinen Fall“, findet der PM einen Alternativplan für das Produkt.
Dieser Text scheint den mittleren Schritt zu überspringen und einfach nur den Namen ändern zu wollen.
Wer genau entscheidet denn dann, welche Probleme das Team priorisieren soll? Genau das ist die Kernverantwortung der PM-Rolle.
Letztlich scheint der Autor schlechte Erfahrungen mit PMs gemacht zu haben, die diese Priorisierungsentscheidung nicht treffen konnten.
Wegen dieser Person musste ich allerdings an einem der peinlichsten Meetings teilnehmen, die ich je erlebt habe: Eine volle Stunde lang wurde vor Vorgesetzten offengelegt, dass sie das Produkt überhaupt nicht verstand, während diese Vorgesetzten das Produkt sehr wohl verstanden.
Gute PMs helfen enorm, weil sie verstehen, was Kunden wollen, was wir liefern können, welche Zeitpläne realistisch sind und wie man mit Legal- und Business-Stakeholdern umgeht. Ich helfe ihnen, wenn sie die technische Seite prüfen müssen.
Im Team mangelt es selten an Ideen dafür, was man bauen könnte oder wie sich Produkt- und Betriebserfahrung verbessern ließen. Der Product Manager ist die Person, die dafür sorgt, dass das Richtige gebaut wird.
Ich bin PM mit 20 Jahren IT-Erfahrung und denke über einen MBA nach, um Wissen und formales Business-Verständnis zu gewinnen und mein weiteres Wachstum zu unterstützen.
PMs wie ich fangen nicht sofort nach dem MBA, um einen militärischen Ausdruck zu benutzen, mit sinnlosem Aktionismus an.
Das Problem sind die Leute, die direkt von der Highschool über das Studium und den MBA ins Management gehen. Abgesehen von einem kurzen Praktikum während des Bachelorstudiums haben sie oft keinen einzigen Tag Praxiserfahrung.
Ein seltsamer Text. Mit vielen Worten scheint am Ende doch nur gesagt zu werden: „Wenn man Low Performer einstellt, schadet das dem Unternehmen.“
Die Alternative lautet dann sinngemäß: „Stellt gute Leute ein, aber nicht für die PM-Rolle.“
Es liest sich wie von jemandem geschrieben, der schlechte Erfahrungen mit PMs gemacht hat, die sich für Steve Jobs halten. PMs sind auch nur normale Menschen, daher verstehe ich nicht, warum angenommen wird, dass alle mit diesem Titel ein Anspruchsdenken hätten.
Eine Organisation kann Tausende von PMs haben, und alle haben ihre jeweiligen Vorgesetzten. Einfach ein seltsamer Text.
So nach dem Motto: „Stellt keine Product Manager ein, denn sie werden wohl keine großartigen Menschen sein. Stellt stattdessen großartige Menschen ein, und zwar nicht nur einen, sondern das ganze Team!“
Ich weiß nicht, warum sie jeden Tag aufs Neue Low Performer einstellen. Ein untrainierter Schimpanse mit einem Stapel Lebensläufe hätte vermutlich eine bessere Trefferquote.
PMs erfüllen einen sehr konkreten Bedarf. Er lässt sich schwer quantifizieren, aber man kann sagen, dass ohne gute PMs alles auseinanderfällt.
Sie sammeln Informationen darüber, was für normale Nutzer funktioniert und was nicht, hören von Führungskräften, was für den Betrieb des Unternehmens nötig ist, verstehen von Branchenführern, wohin sich die Branche entwickelt, arbeiten mit Design zusammen und destillieren all das in Features, die tatsächlich gebaut werden müssen.
Außerdem bewerten sie gemeinsam mit Engineering, was praktikabel ist und ungefähr wie lange es dauert, streichen zeitintensive, aber wenig wertvolle Features und helfen dabei, dass Schätzungen und Teamgeschwindigkeit einigermaßen vorhersehbar bleiben.
Damit sind bereits 1,5 Vollzeitstellen beschrieben. Wenn man die Produktorganisation abschafft, verteilt sich all diese Arbeit auf das Engineering-Team, und nicht alle im Team können das gut.
Selbst wenn man ein Gleichgewicht findet, entsteht beim Weggang einer einzelnen Person eine unsichtbare Lücke, nach der man bei der Einstellung gar nicht gesucht hat.
Viele Teams scheinen von dysfunktionalen Produktorganisationen verbrannt worden zu sein. Solche Organisationen wirken losgelöst oder desinteressiert an Kunden-, Branchen- und Organisationsperspektiven, verbrennen stattdessen aber enorm viel Zeit in Meetings, in denen Mockups endlos wiederholt werden, micromanagen Designer, bis gute Leute gehen, und binden Engineers in unnötige Produktmeetings.
Ein PM arbeitet eng mit dem Team zusammen, definiert die Roadmap und priorisiert die Arbeit mit dem größten Einfluss auf Kunden und Business.
Wenn ein PM seinen Job gut macht, verstehen Engineers sehr klar, welches Problem sie als Nächstes lösen sollen und warum.
Zweitens ist wichtig, ob diese Person in der Organisation das nötige Standing hat, um mit dem Top-Management über Projekte zu kommunizieren. Wenn beide Eigenschaften vorhanden sind, ist man gut aufgestellt.
Was ich in über 12 Jahren in der Tech-Branche gelernt habe, ist, dass Rollen nur eine Art sind, die Wünsche einer Organisation auszudrücken.
Wenn jemand möchte, dass man in Produkten denkt, schafft man eine PM-Position; wenn man einen Team-Lead will, schafft man eine Engineering-Manager-Position.
Titel sind fiktive Elemente, die es uns erlauben, das RPG namens Arbeit aus verschiedenen Blickwinkeln zu spielen. Am Ende bringt jeder seine eigene einzigartige Kombination aus Talent und Erfahrung an den Arbeitsplatz mit.
Manche Menschen überschreiten oft die Grenzen solcher Rollen, und das ist in Ordnung. Sie haben Ideen und können sich sogar ihren eigenen Titel schaffen.
Organisationen sollten klug genug sein, solchen Menschen Raum zu geben, damit sie wachsen und aufblühen können. Das heißt nicht, dass man als PM keinen Erfolg haben oder keine großartige Arbeit leisten kann, sondern dass Organisationen meist nicht genug Zeit investieren, um die Menschen, die sie einstellen, wirklich kennenzulernen, und ihnen deshalb vorgekochte Rollen anbieten.
Ein Engineer kann auch die Rolle eines PM übernehmen, aber er denkt nicht über alles aus PM-Perspektive nach. Seine primäre Identität ist schließlich nicht PM, sondern Engineer.
Im Zusammenhang mit dem Überschreiten von Rollengrenzen ist mir noch etwas klar geworden: Der wertvollste Teil der Rolle einer Person sind meistens die Verantwortlichkeiten, die nicht explizit definiert sind.
Das ist schwer zu erklären, aber Menschen schaffen oft auf eine Weise Wert, die sich schwer beschreiben oder quantifizieren lässt.
Insgesamt ist das eine ziemlich harsche Sichtweise, aber eindeutig steckt auch viel Wahres darin. Wenn sich in einem Unternehmen eine Produktorganisation bildet, neigt sie dazu, wie vom Autor beschrieben in Komitees, OKRs, Review-Zyklen, Planung und viel Bürokratie abzugleiten.
Ich war früher in einer kundenorientierten Sales-Engineering-Rolle sehr erfolgreich darin, Produkte durch Einfluss zu steuern, und habe naiv die Rolle des Product Managers übernommen, weil ich dachte, ich bekäme damit formale Kontrolle.
Als ich dann dort saß, stellte sich heraus, dass es eine extrem eingeschränkte Bürotätigkeit war, die überhaupt nicht zu mir passte. Es ging größtenteils um Ticket- und Backlog-Management, um Koordination statt Entscheidungen, und um das endlose Schreiben von PowerPoint-Berichten; die kreativste Arbeit war noch, einen Prozess zu entwickeln, mit dem das Unternehmen seine Produkt-Roadmap formalisieren konnte. Nach 6 Monaten bin ich geflohen.
Diese Funktion ist ziemlich nützlich, um Sichtbarkeit darüber zu schaffen, was gebaut wird, und um die widersprüchlichen Prioritäten eines wachsenden Produkts zu verwalten. Aber sie formt oder kontrolliert nicht die Richtung, in die sich das Produkt entwickelt.
Es ist eine Alignment-, Filter- und, wenn man Glück hat, Datensammelfunktion, die eine auditierbare Entscheidungsspur und den Eindruck reifer Entscheidungsfindung erzeugt, damit die MBAs darüber ein wenig ruhiger schlafen können.
Normalerweise habe ich 4 bis 12 neue Feature-Vorschläge (PRDs) pro Monat erstellt; die Zahl variierte je nach Unternehmensgröße und dem Umfang der nötigen Prozesse.
Die Form war immer: „Nutzer haben derzeit Problem X, und um es zu lösen, müssen wir Y bauen. Y sieht so aus ...“
Natürlich gibt es Schwierigkeiten bei Koordination und Kommunikation, aber letztlich ging es immer darum herauszufinden, was als Nächstes gebaut werden sollte.
Ich verstehe, dass nicht jede PM-Rolle so ist, aber ich stimme nicht zu, dass PM nie mehr sein könne als „Alignment/Filterung/Theater der Entscheidungsreife“.
Wenn es einfach nur darum ging, die Reihenfolge in einem bestehenden Backlog festzulegen: Wer hat dann definiert, was neu ins Backlog aufgenommen wird?
Ich stimme zu, dass eine Produktorganisation eher zu einem politischen und bürokratischen Gebilde als zu einer unterstützenden Funktion werden kann.
Persönlich denke ich, dass Produktrollen in die Engineering-Teams eingebettet sein und an dieselbe Führungskraft berichten sollten. Über das Level kann man streiten, aber so könnte man schlechte PMs genauso behandeln wie schlechte Engineers.
Wenn ein Unternehmen natürlich nicht einmal schlechte Engineers loswerden kann, hat es ein anderes Problem.
Der Autor liefert dafür kaum einen Rahmen.
Die Lösung des Artikels riecht nach Great-Man-Theorie.
Der Schlussteil nach dem Motto „Großartige Menschen stellen sich alternative Realitäten vor, widmen sich der Arbeit vollständig und versetzen mit ihrer Willenskraft Berge“ ist zu reduktionistisch.
Berge werden nicht durch Willenskraft versetzt, sondern durch die Menschen unten, die die Vision tatsächlich umsetzen. Im besten Fall richtet diese „große Person“ lediglich die Anreize so aus, dass sich die tatsächlichen Umsetzer und Fachexperten bewegen.
Ich arbeite derzeit bei einem großen Tech-Unternehmen, das fast keine PM-Rollen hat, daher kann ich einen direkten Eindruck schildern.
Bisher ist es gemischt. Ich habe auch in Organisationen mit vielen PMs gearbeitet und stimme zu, dass solche Organisationen nicht besonders gut sind. Aber letztlich muss die Arbeit, die PMs machen, trotzdem erledigt werden.
In unserer Organisation fällt diese Verantwortung offiziell auf Software-Manager und Entwickler ab Senior-Level.
Wenn man zum Beispiel als Senior Engineer eine Initiative des Teams leitet, muss man alle Aktivitäten übernehmen, die sonst ein PM tun würde. Andere Aufgaben übernehmen der Manager oder Senior Manager.
Aus Entwicklersicht ist das ziemlich hart. Man muss als Individual Contributor seine eigene Arbeit erledigen und gleichzeitig andere koordinieren und dafür sorgen, dass die Arbeit abgeschlossen wird.
Das ist nicht nur zusätzliche Arbeit, sondern ehrlich gesagt haben viele Entwickler auch nicht die Fähigkeiten, effektive PMs zu sein. Die teamübergreifende Zusammenarbeit wird ebenfalls schwieriger, weil man Menschen aus unterschiedlichen Berichtslinien koordinieren muss.
Dieser Ansatz führt oft zu mangelnder Ownership, mangelnder Verantwortlichkeit, doppelter Arbeit, Dingen, die durch die Maschen fallen, und allgemeinem Chaos.
Für kleine Initiativen innerhalb eines Teams mit nur wenigen Beteiligten funktioniert er allerdings gut. Er beseitigt den PM-Overhead und gibt den Menschen, die bauen, die Kontrolle. Aber ich bin nicht sicher, ob er auch für größere Initiativen geeignet ist.
Es stimmt, dass viele Entwickler nicht die Fähigkeiten haben, effektive PMs zu sein, aber fairerweise haben auch viele PMs nicht die Fähigkeiten, effektive PMs zu sein.
Die Schwierigkeit, Menschen aus anderen Berichtslinien zu koordinieren, gilt für PMs genauso.
Der entscheidende Unterschied scheint die Frage zu sein, ob es sinnvoll ist, diese Arbeit als eigene Rolle auszugliedern. Ich neige dazu zu denken, dass sich das bei Engineers fast nie lohnt.
Schon beim Titel war ich darauf eingestellt, es nicht zu mögen. Ich dachte, es würde wieder so ein typischer Text nach dem Motto sein: „PMs sind dumm, und ein Unternehmen braucht nur kluge Ingenieure, die die Welt beherrschen.“
Aber so ein Text war es nicht, und ich finde, das Problem selbst wurde fast perfekt erfasst.
Nur die Lösung verflüchtigt sich dann irgendwie mit einer Handbewegung. Sinngemäß heißt es: „Stellt ganz normale großartige Menschen ein, die jeweils in irgendetwas hervorragend sind, von ihrem Handwerk besessen und von Qualität angetrieben, bündelt sie zu einem Team und lasst sie ohne individuelle Verantwortlichkeit arbeiten.“
Klingt gut, aber wer kann ein Beispiel nennen, bei dem das in einem Unternehmen mit mehr als 100 Mitarbeitern tatsächlich funktioniert hat? Ich sehe nicht, wie das in der Realität funktionieren soll.
Valve macht oder machte wohl etwas sehr Ähnliches. Das Mitarbeiterhandbuch[0] war früher ein HN-Dauerbrenner, heute sieht man es kaum noch. Ich frage mich, ob es für sie gut funktioniert.
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
Der Autor scheint wirklich mit ziemlich mittelmäßigen Produktmanagern gearbeitet zu haben. Ich bin selbst PM mit autodidaktischem Engineering-Hintergrund und habe in vielen Bereichen viele mittelmäßige Leute gesehen.
Ich betrachte meine Arbeit hauptsächlich als Risikomanagement. Selbst ein Team aus großartigen Ingenieuren und Designern steht auf dem Weg zur Veröffentlichung eines guten Produkts vor vielen Risiken.
Vielleicht fehlt die Fähigkeit, eine Vision zu vermitteln und andere zu überzeugen, oder die Rechtsabteilung setzt Anforderungen oder Einschränkungen dafür, was möglich ist und was nicht.
Meine Aufgabe ist es, solche Dinge zu steuern, damit die Stärken des Teams zur Geltung kommen und es sich auf das konzentrieren kann, was wirklich wichtig ist: ein gutes Produkt zu bauen und zu veröffentlichen.
Erfolg messe ich daran, wie überflüssig ich geworden bin. Das Ziel ist, nicht mehr gebraucht zu werden: dass das Team den Kontext, das Selbstvertrauen und die Unterstützung hat, um auch ohne mich gute Entscheidungen zu treffen.
Ich arbeite gern daran, dass Ingenieure diese Fähigkeiten aufbauen, und gemeinsam mit meinen Partnern im Engineering Management versuche ich, die Stärken, Schwächen und Ziele jedes einzelnen Ingenieurs zu verstehen und Wege für Wachstum zu finden.
Ich verstehe auch das Argument, dass ich in einer idealen Utopie vielleicht nicht nötig wäre. Aber in den meisten Fällen stößt man auf Herausforderungen und Risiken, wenn man wirklich großartige Arbeit leisten will, und ein guter PM ist dann ein Netto-Wertschöpfer, der dem Team hilft, diese Hürden gemeinsam zu überwinden.
Es geht darum, sicherzustellen, dass das Team den Kontext, die Anforderungen, die Erkenntnisse, die Kennzahlen und die Ziele hat, die es braucht, und versteht, welches Problem für wen und warum gelöst werden soll.
Ein guter PM schafft ein Umfeld so gut, dass Ingenieure denken: „PMs machen doch gar nichts, also braucht man sie nicht.“ Dieses Urteil ist kurzsichtig und ehrlich gesagt beleidigend.