Teilen auf

LinkedIn Facebook Twitter

Gehüpft wie gesprungen? Wo liegt der Unterschied zwischen einem Product Manager und einem Product Owner … oder ist das im Grunde der gleiche Job?

Nein, ein Produktmanager und ein Product Owner haben nicht dieselbe Rolle. Sie verfolgen zwar ein gemeinsames Ziel – Produkte, die Usern lieben und nutzen – haben jedoch nicht denselben Verantwortungsbereich.

In der Regel sind Produktmanager für das Warum verantwortlich. Sie erstellen die Produkt-Roadmap auf Grundlage der Bedürfnisse und Wünsche der User. Sie konzentrieren sich auf Geschäftskennzahlen und darauf, ob sich ein Produkt in die richtige Richtung entwickelt.

Product Owner ihrerseits sind für die Erstellung und Abwicklung des Product Backlogs verantwortlich. Sie sind im operativen Prozess involviert und an eine Deadline gebunden. Für sie dreht sich alles um Scrum, das Hin und Her mit den Entwicklern und darum, anstehende Aufgaben zu erledigen.

Doch oft lässt sich keine klare Trennlinie zwischen den beiden ziehen. Je nachdem, wo Sie arbeiten, sind Sie möglicherweise an unterschiedliche Situationen gewöhnt. Um die Unterschiede und die Ähnlichkeiten zwischen diesen beiden Jobs besser zu verstehen, haben wir unseren firmeninternen Produktmanager Yoann Grange gebeten, Klarheit zu schaffen.

Sie haben nur wenig Zeit? Klicken Sie direkt auf den Abschnitt, der Sie interessiert.

[toc]

Welche Verantwortlichkeiten hat der Product Manager? Welche der Product Owner?

Diese Frage beschäftigt mich schon seit über fünf Jahren. Und das so sehr, dass ich bereits 2016 25 Video-Interviews [auf Französisch] mit Product Ownern, Produktmanagern, Heads of Product usw. geführt habe.

Meine Antwort lautet kurz und knapp: Kommt drauf an.

Sie denken jetzt bestimmt „Na klar! Gilt das nicht für alles?“

Aber hier, in diesem Fall, hängt dies tatsächlich von vielen verschiedenen Faktoren ab. Einige werden in diesem Artikel näher behandelt.

Product Manager vs Product Owner: Was wann in Betracht ziehen sollte

Wir dürfen nicht aus den Augen verlieren, dass es Produkte unterschiedlichster Art gibt: Industrieprodukte, landwirtschaftliche Produkte, Dienstleistungen, Chemikalien, Modeprodukte … und Softwareprodukte.

Im SaaS MarTech Bereich herrscht die Meinung vor, dass alle Produkte gleich aufgebaut sind und alle Unternehmen die gleiche Struktur aufweisen. Die Branche tendiert zur Annahme, dass hinter jedem Feature ein Produktmanager und ein Product Owner steckt.

Die Wirklichkeit sieht aber anders aus: Manchmal ist es der eine oder der andere, manchmal beide oder sogar keiner von beiden. Welche Faktoren bestimmen diese Struktur? Sehen wir uns ein paar davon näher an.

1. Dynamik

Das wichtigste Kriterium ist „die Dynamik des Unternehmens“. Was verstehe ich unter diesem Begriff?

Wie neu/alt ist das Unternehmen?

Diese Frage ist wichtig. Sie steht nicht in direktem Zusammenhang mit der Größe des Unternehmens. Sie bezieht sich auch nicht auf die Anzahl der Kunden. Ich kenne zum Beispiel ein Unternehmen mit neun Personen und über 200.000 zahlenden Kunden. Die Firma ist mittlerweile „schon“ sechs Jahre alt und die Produkt-Funktion wird hier mehr oder weniger von allen wahrgenommen.

Wie weit ist das Unternehmen von einem bestimmten „Schlüsselmoment“ entfernt?

Unter „Schlüsselmoment“ verstehe ich Schlüsselphasen oder Ereignisse im Lebenszyklus eines Unternehmens. Zum Beispiel:

• Gründung des Unternehmens
• Verkauf des Unternehmens
• neue Finanzierung
• Steuerprüfung
• Release eines Mitbewerbers
• Krise
• Neuer CEO
• … Sie wissen, wovon ich spreche.

Diese verschiedenen Schlüsseletappen wirken sich auf die Praxis der Produktentwicklung aus.

Sie bestimmen deshalb, was ein Produktmanager und was ein Product Owner macht.

Kurz nach der Gründung eines Unternehmens ist der CEO wahrscheinlich am besten geeignet, die Produktrollen zu betreuen. Häufig ist der CEO (zumindest in skalierbaren SaaS Unternehmen) derjenige, der die Funktion von PO, PM, QA und Support inne hält, was weder eine bewusste Entscheidung noch eine Strategie ist, sondern einfach nur das, was im entsprechenden Moment notwendig ist.

Wie man mit der Dynamik eines Unternehmens umgeht, bestimmt in der Regel außerdem wie „gut“ sich das Unternehmen macht.

Wurde der gegenwärtige Moment antizipiert oder ist er nur das Ergebnis der Reaktion auf den vorhergehenden Moment? Sie können davon ausgehen, dass ein Unternehmen umso „agiler“ ist, je öfter es reagiert. Je mehr Momente antizipiert werden, desto „visionärer“ das Unternehmen. Gleichzeitig agil und visionär zu sein, ist eine große Herausforderung.

2. Die Größe zählt

Mit Größe meine ich nicht nur die Anzahl der Mitarbeiter. Die Größe eines Unternehmens bezieht sich auch auf die Anzahl der:

• Produkte
• Modelle
• Features
• Scopes
• Preistabellen
• oder Märkte, die das Unternehmen anspricht.

Produkte auf die richtigen „Dimensionen“ zurechtzuschneiden und zu entscheiden, ob sie nach Markt, Produktlinie oder Thema aufgeteilt werden sollen, kann eine Lebensaufgabe sein: Die Dinge ändern sich ständig und je schneller sich ein Unternehmen entwickelt, desto öfter sind Änderungen nötig.

Die Größe kann auch durch die Anzahl der User, Kunden, Partner, Händler, Sprachen, Einheitensysteme usw. definiert werden. Noch häufiger aber ergibt sich aus einer Kombination all dieser Faktoren, wie viele PMs, POs und Heads of Product Ihr Unternehmen benötigt.

In vielen NGOs zum Beispiel hängt die Anzahl der Produktmanager von den Spender-Personas ab. Es gibt einen PM für kleine Spendenbeträge (z. B. 10 $ bis 500 $), einen für größere Beträge (500 $ bis 10 000 $) und einen weiteren für noch höhere Beträge. Warum? Weil sich die Erwartungen der verschiedenen Typen von Personas stark unterscheiden. Die Fähigkeit, auf jede Persona einzugehen, trägt langfristig zum Wachstum gemeinnütziger Unternehmen bei.

Kurz gesagt, die Größe eines Unternehmens (sein Kundenportfolio, sein Produktkatalog usw.) kann darüber entscheiden, was der PM macht, was der PO macht und wie viele PMs und POs eingesetzt werden.

3. Weitere Kriterien

Wie viele PMs, POs oder andere Mitarbeiter im Produktbereich benötigt werden, hängt nicht nur von den genannten Faktoren ab. Es können noch zahlreiche andere Faktoren einfließen, z. B.:

• Anzahl der Entwickler
• Anzahl der Designer
• Versandgeschwindigkeit
• technische Stacks
• Tools
• Produktlebenszyklus
• individuelle Wünsche
• Wachstumspotenzial
• abgedeckter Anteil des existierenden Bedarfs
• Legacy-Anteil
• Personalpolitik
• der Markt, den Sie ansprechen
• Schließlich kommt es auch noch darauf an, welche Politik das Unternehmen verfolgt.

Im Großen und Ganzen ist man sich (zumindest in SaaS Unternehmen) darüber einig, dass sich die Trennlinie zwischen PM und PO folgendermaßen ziehen lässt: Vision vs. operative Prozesse, Planung vs. Dringlichkeit, Nutzen vs. Kennzahlen. Doch beide gehören zusammen.

Obwohl sich die beiden Rollen voneinander abgrenzen, sind sie letztlich nicht voneinander zu trennen.

Kein Unternehmen gleicht dem anderen. Deshalb gibt es keine Standardantwort auf die Frage, was ein PM im Vergleich macht. Sie müssen Ihren eigenen Weg finden. Manche Unternehmen werden viele PMs und POs brauchen, manche überhaupt keine. Es ist schon schwierig genug, dafür zu sorgen, dass Menschen erfolgreich zusammenarbeiten. Einfach eine Methode zu kopieren, hilft nicht. Sie müssen Ihr eigenes Konzept finden.

Sollte ich die Frage dennoch beantworten müssen, würde ich sagen, dass PMs eher das letzte Wort bei der Priorisierung haben und für Unternehmenskennzahlen verantwortlich sind. POs hingegen sind für die Einhaltung der Termine des Teams verantwortlich. Doch auch diese Antwort ist immer noch zu simpel.

Kann eine Person sowohl die Rolle des Produktmanagers als auch die Rolle des Product Owners übernehmen?

Ja. Absolut. Das bedeutet nicht, dass es so sein muss, aber dass es definitiv möglich ist.

Tatsächlich ist das bei relativ vielen Startups in ihrer Anfangsphase der Fall. Meistens treten mindestens zwei Personen auf den Plan: eine der beiden ist technikorientiert, die andere eher geschäftsorientiert. Oft übernimmt die geschäftsorientierte Person die Produktfunktion. Sie kann aber auch von beiden oder von der technikorientierten Person übernommen werden.

Wie gesagt sind Vision vs. operative Prozesse, Planung vs. Dringlichkeit, Nutzen vs. Kennzahlen die zwei Seiten von drei verschiedenen Dingen, die die Product-Person bei jeder Entscheidung berücksichtigen muss.

Die Konfiguration aus einem PM mit mehreren POs ist häufiger anzutreffen als ein PO mit mehreren PMs. Aber im Endeffekt, warum nicht? Alles hängt von den oben genannten Kriterien ab.

Besteht Deiner Erfahrung nach ein Gehaltsunterschied zwischen Product Owner und Produktmanager?

Ja. Produktmanager verdienen eher mehr als Product Owner. Auch hier liegt der Grund darin, dass es für beide Rollen eine gewisse Standardauslegung gibt und die Rolle des Product Owners als weniger anspruchsvoll betrachtet wird. Dabei handelt es sich einfach nur um zwei verschiedene Rollen. Pure kognitive Verzerrung.

Der Report Stand der Produktführerschaft 2020 von Pendo zeigt überraschenderweise eine negative Korrelation zwischen „Glücksgefühl“ und Gehalt der befragten Produktmanager auf. Es dreht sich also nicht alles nur ums Geld.

Welche Fähigkeiten muss ein guter Produktmanager und/oder Product Owner mitbringen?

Das ist meine Lieblingsfrage, auf die jeder eine andere Antwort hat. Doch sind sich mehr oder weniger alle einig, dass der Rahmen relativ weit gefasst ist.

Mir sträuben sich die Haare, wenn ein Stellenangebot in etwa so beginnt: „Fachhochschule oder Master-Abschluss in Informatik …“ Für Produktler braucht es mehr als nur technische Kompetenz. Je geradliniger die Menschen denken, die an Ihrem Produkt arbeiten, desto geradliniger ist auch Ihr Produkt. Und desto schneller wird es angenommen.

Zoom und Fokus

Ich würde sagen, dass ein PM/PO in erster Linie fähig sein muss, verschiedene Perspektiven einzunehmen, um ein Problem sowohl aus der Mikro- als auch aus der Makroperspektive zu erfassen.

Manchmal müssen Sie ins kleinste Detail gehen. In anderen Fällen müssen Sie das Gesamtproblem verstehen, das durch das Produkt oder Feature gelöst werden soll. Jederzeit die Perspektive zu ändern, ist der Schlüssel zum Erfolg. Die Makroperspektive hilft Ihnen, die Konkurrenz und den Markt zu verstehen, die Mikroperspektive ermöglicht es, die Details einer Komponente zu verstehen. Sie müssen sich jederzeit vor Augen halten, warum Sie was tun.

Semantik und Semiologie

Mein Fremdsprachen-Hintergrund hat mir gleich zu Beginn geholfen, als Schnittstelle zwischen Entwicklern und Usern/Kunden zu agieren. Ich komme auch heute noch ziemlich oft darauf zurück, um zu entscheiden, was wichtig ist und was nicht. Dieser Hintergrund hilft, sich bei einem User Test auf eine bestimmte Anmerkung zu konzentrieren und bei einem zehnminütigen Video zu erfassen, was wichtig ist. Außerdem versteht man dadurch besser, warum ein Symbol problematisch ist und weshalb die Kombination eines bestimmten Labels mit einem bestimmten Symbol nicht funktioniert, warum beide notwendig sind, warum es besser wäre, überhaupt darauf zu verzichten (allerdings nur für einige User) …

Ob technisch oder funktional, schriftlich oder mündlich, optisch oder akustisch: Bei Sprachen geht es in erster Linie darum, den Sinn zu vermitteln. Von Team zu Team, vom User zur Maschine, von der Spezifikation zum fertigen reellen Feature: Alles dreht sich darum, einander zu verstehen. Obwohl diese Evolution seit so vielen Jahren in Gang ist, sind wir auf diesem Gebiet nicht viel besser geworden.

Das Design zählt ebenfalls dazu. Wer Wireframes und Mockups erstellen kann, hat schon viel gewonnen. Selbst wenn sie nicht in Ihren Aufgabenbereich fallen, können diese Visualisierungsformen einen Prozess beschleunigen oder den Weg für andere Lösungen ebnen.

Wichtig ist auch, was jeder Einzelne unter „Kommunikation“ versteht, denn Sie haben es mit Usern, Dritten, Stakeholdern aller Art, manchmal auch mit den Medien usw. zu tun. Deshalb ist es von Vorteil, wenn Sie eine Präsentation, ein Webinar oder eine Schulung abhalten.

Zu guter Letzt sollten Sie gerne Geschichten schreiben und erzählen. Die meisten Menschen lieben es, Geschichten zu hören, aber nicht jeder schreibt sie auch gerne.

Iteration und Lernprozess

Weitere wichtige Fähigkeiten schließen alles ein, was unter „testen -> messen -> verbessern“ fällt.

„Testen“ heißt zweifeln. Wer sich seiner Sache allzu sicher ist, riskiert zu scheitern. Die Fähigkeit, eine Hypothese aufzustellen ist ebenfalls wichtig. Nehmen Sie nie etwas als Selbstverständlich hin.

Und in puncto Messung kann die Erfahrung mit einem wissenschaftlichen Ansatz hilfreich sein, ebenso wie die Fähigkeit, die Dinge klar zu erkennen und die Performance zu messen. Das schließt analytische (quantitative) Kenntnisse oder verhaltensanalytische (qualitative) Skills ein.

Philosophisch gesehen muss ein erfolgreicher Produktmanager oder Product Owner schon im Vorfeld des Versuchs ein Scheitern in Kauf nehmen. Und er muss akzeptieren, dass er irgendwann mit den Verbesserungen Schluss machen muss, wenn sich der Erfolg einstellt. Eine hundertprozentige Perfektion ist einfach nicht möglich.

Mit welchen KPIs lässt sich der Erfolg von Product Ownern und Product Managern messen?

Ich versuche, nicht mehr jede Frage mit „Kommt ganz darauf an“ zu beantworten. Aber … es kommt wirklich ganz darauf an. Meiner Meinung nach sollten die KPIs von Produktmanagern auf Unternehmenskennzahlen basieren: Wachstum, Umsatz, Abwanderung, Kosten … Für Product Owner zählen Lieferung, Qualität, Teamzufriedenheit.

Welche Kurse kann man belegen, um ein (besserer) Produktmanager zu werden?

Wie gesagt, das erforderliche/minimale Skillset ist extrem breit gestreut. Die gute Nachricht? Etwas Neues zu lernen macht Sie zu einem besseren Menschen und damit auch zu einem besseren Product Mitarbeiter.

Sehen Sie sich selbst zunächst als Person. Wenn Sie sich als Produkt positionieren, neigen Sie dazu, sich auf fehlende oder falsche Dinge zu konzentrieren. Wenn Sie sich als Person sehen und einen ganzheitlichen Blickwinkel einnehmen, ist jede neue Fähigkeit von Interesse.

Wir fungieren auch als Bindeglied zwischen Usern und technischen Teams, um das Beste aus minimalen (oder fortgeschrittene) technischen Kenntnissen herauszuholen, damit Sie die technischen Teams und ihre komplexen Aufgabenstellungen verstehen können.

In den letzten 15 Jahren habe ich für 17 Unternehmen gearbeitet und empfehle deshalb jedem, das Unternehmen oft zu wechseln. Sie wechseln dabei auch noch die Branche? Umso besser!

Welche Lektüre würdest du empfehlen?

Die meisten PM, PO, VP, Heads of Product legen Ihnen eine lange Liste von Bestsellern zum Thema Produktmanagement nahe. In der Regel geht es dabei um Titel wie „Lean UX“, „Lean Startup“, „Wie werde ich ein erfolgreicher Produktmanager“ usw. Ich versuche mich mit einer etwas anderen Liste.

Ich empfehle eher Klassiker, weil sie sich auf die Grundlagen konzentrieren. Selbst bei Klassikern besteht nur eine geringe Chance, dass andere Produktmanager oder Product Owner sie gelesen haben. Die Welt dreht sich immer schneller, doch die Grundlagen ändern sich nicht.

Im Product arbeiten wir für die Menschen. Unser Job ist es, die Menschen zu verstehen, damit wir ihnen helfen können. Wir versuchen, echten Problemen der Menschen mit möglichst risikoarmen Lösungen zu begegnen. Wir sind weit davon entfernt, die Komplexität der Menschheit in ihrem vollen Ausmaß zu verstehen. Einige Menschen stechen jedoch aus der Masse heraus und haben uns Meisterwerke geschenkt:

• Das Reich der Zeichen – Roland Barthes
• Wie man Freunde gewinnt. Die Kunst, beliebt und einflussreich zu werden – Dale Carnegie
• Vorlesungen zur Einführung in die Psychoanalyse – Sigmund Freud
• Strukturale Anthropologie – Claude Lévi-Strauss
• Die Kunst des Krieges – Sun Tzu

NB: Lesen ist gut. Experimentieren ist besser.

Teilen auf

LinkedIn Facebook Twitter