Was macht eigentlich ein Software Produktmanager?
Tags: softwareentwicklung
Kategorie Software Engineering | 5 Kommentare »
Momentan verbringe ich einen signifikanten Anteil meiner Arbeitszeit als Produktmanager und weniger als technischer Projektleiter, da ich die Arbeit eines Kollegen übernehmen muss. Das ist eine willkommene Abwechslung, gibt es mir doch die Gelegenheit, etwas tiefer die verschiedenen Aufgabengebiete eines Software Produktmanagers zu beleuchten.
Aufgabe des Software Produktmanagers
Wenn mich jemand fragt, was meine Aufgabe als Software Produktmanager ist, dann antworte ich halb im Scherz: „Leuten ihre Anforderungen ausreden“. Natürlich ist man als Produktmanager froh, wenn es Erweiterungswünsche von Anwendern und Beratern gibt, aber traurige Realität des Produktmanagerdaseins ist es, dass einem wesentlich mehr unerfüllte Wünsche als zur Umsetzung benötigte Ressourcen vorliegen. Deshalb ist es eine der wichtigsten Aufgaben eines Produktmanagers Anforderungen zu sammeln, zu sichten, zu verwalten, zu priorisieren, zu planen und zu realisieren. Und eben auch unsinnige oder nicht in die Produktstrategie passende Anforderungen abzulehnen. Gerade mit Letzterem tun sich viele Produktmanager schwer.
Quellen für Anforderungen
Das Sammeln von Anforderungen bezeichnet man gemeinhin als Roll-in Prozess. Anforderungen kommen aus ganz unterschiedlichen Quellen, etwa:
- Kunden
- Partner
- dem eigenen Support
- den eigenen Beratern
- den eigenen Entwicklern
- dem eigenen Vertrieb
- von Konkurrenten
- allgemein von Marktentwicklungen
Als Produktmanager muss man deshalb all diese Quellen im Blick haben und versuchen, die Anforderungsströme zu kanalisieren. Bei meinem Arbeitgeber können zum Beispiel Kunden und Partner neue Anforderungen über eine Community Seite vorschlagen und Vorschläge von anderen durch Punktevergabe unterstützen. Ideen aus der internen Entwicklung hingegen gehen direkt an mich beim Mittagessen. Die lange Liste der Anforderungsquellen zeigt aber auch, dass man sich als Produktmanager eigentlich keine Anforderungen ausdenken muss, denn das machen schon genügend andere Leute :-)
Bei Anforderungen muss man aber immer bedenken, dass die meisten Leute immer nur an die Sachen denken, die sie aktuell beschäftigen. Für einen Berater sind zum Beispiel immer die Anforderungen am wichtigsten, deren fehlende Umsetzung ihm im aktuellen Projekt das Leben gerade schwer macht. Auch bei Kunden ist das ähnlich. Von daher gilt es, neue Anforderungen mit verschiedenen Quellen abzugleichen, um zu verstehen, ob das Problem für mehrere Quellen relevant ist.
Anforderungen organisieren
Da man sich die Anforderungen nur schwer merken kann, muss man sie verwalten. Dafür gibt es mindestens so viele Ansätze wie Produktmanager. Bewährt hat sich die Verwendung von Software für diese Aufgabe. Jede Anforderung wird in einer Art Posteingang eingetragen und zum Beispiel einem Produkt oder einer Komponenten zugeordnet. Dabei sind zwei Punkte sehr wichtig:
- Man muss immer die Quelle der Anforderung dokumentieren, damit man zum Beispiel später, wenn es an die Realisierung geht, nachfragen kann, was überhaupt das konkrete Problem war. Manchmal erübrigen sich dann Anforderungen von selbst, weil inzwischen schon eine andere Lösung gefunden wurde.
- Anforderungen, von denen man gleich weiß, dass sie nie umgesetzt werden, sollte man gar nicht erst eintragen, sondern der Quelle erklären, warum die Anforderung wenig Chancen auf Realisierung hat. Dadurch verhindert man, dass man nicht erfüllbare Erwartungen weckt und man reduziert auch die zu verwaltende Anzahl von Anforderungen.
Das konkrete Ablagesystem ist immer abhängig von der eigenen Produktstruktur und es gibt vermutlich keine Ideallösung. Hat man zum Beispiel die Ablage nach Produkten organisiert, dann bekommt man bei Anforderungen, die mehrere Produkte betreffen, Probleme. In solch einem Fall kann man viele Auswege wählen, aber man sollte tunlichst nicht die Anforderung in jedem betroffenen Produkt duplizieren.
Eine wichtige Aufgabe ist es, ähnliche Anforderungen immer wieder zu konsolidieren, um einen Wildwuchs an Anforderungen zu vermeiden. Gute Softwarewerkzeuge, die zum Beispiel eine netzartige Ablagestruktur unterstützen, können hier von großer Hilfe sein.
Produktstrategie
In jedem BWL Fach wird gepredigt, dass am Anfang immer eine Strategie mit klarer Zieldefinition stehen sollte, bevor es an die Umsetzung geht. Manchmal wird das auch in der Praxis befolgt :-) Auch im Produktmanagement ist die Definition einer klaren Produktstrategie von zentraler Bedeutung, denn eine klare Produktstrategie hilft bei der Priorisierung von Anforderungen, der Definition des Releaseumfangs und bei der späteren Marktkommunikation. Eine Produktstrategie zwingt auch die verschiedenen Stakeholder wie Vertrieb, Entwicklung, Marketing, Support, Geschäftsführung usw. sich auf einen Kompromiss zu einigen oder gemeinsam für zusätzliche Ressourcen zu kämpfen.
Idealerweise wird die Produktstrategie aus den Unternehmenszielen abgeleitet. Zielt eine Firma zum Beispiel auf eine Ausweitung ihrer eigenen Beratungsleistung, so bekommen Anforderungen, die eine Anpassbarkeit der eigenen Software erlauben, eine höhere Priorität.
Man kann aus einer Produktstrategie ein großes Werk machen. Ich befürworte hingegen einen pragmatischen Ansatz. Eine gute Produktstrategie passt auf ein Blatt, zum Beispiel in Form einer Tabelle, in der man für jedes Produkt kurzfristige und langfristige Ziele stichpunktartig dokumentiert. Eine Produktstrategie sollte allgemeinverständlich sein und die Verwendung irgendwelcher Bullshit Begriffe vermeiden. Nur was man klar, kompakt und unmissverständlich ausdrücken kann, hat man auch selbst verstanden. Marketing kann später immer noch eine weichgespülte Suppe von hippen Begriffen für Analysten und Marktbeobachter daraus machen :-)
Mit einer klaren Produktstrategie im Hinterkopf fällt das Priorisieren von Anforderungen nicht schwer. Soll ein Produkt zum Beispiel nicht intensiv weiterentwickelt werden, kann man Anforderungen an dieses Produkt ignorieren. Hier ist natürlich Fingerspitzengefühl gefragt, da es vielleicht cleverer ist, mit jedem Release kleine Erweiterungen einzubauen, um die Lebendigkeit des Produkts öffentlich zu dokumentieren, bis ein Ersatz marktreif ist. Weiterhin ist es selbstverständlich, dass man als Produktmanager die Priorisierung nicht allein vornimmt, sondern letztendlich ein Gesamturteil auf Basis der Quellen und der Produktstrategie entwickelt. Als guter Produktmanager ist man Mediator der verschiedenen Interessengruppen.
Releaseplanung
Sind Anforderungen erst einmal priorisiert, dann ist die Releaseplanung relativ einfach. Von den Kollegen aus der Entwicklung oder anhand des eigenen Erfahrungsschatzes bildet man zu den Anforderungen mit höchster Priorität eine grobe Aufwandsschätzung. Weiterhin bestimmt man mit Vertrieb, Geschäftsführung und Marketing einen geeigneten Releasetermin.
Anhand des zeitlichen Rahmens, der verfügbaren Ressourcen und den grob geschätzten Anforderungen kann man dann den Umfang des Release planen. Dabei ist es selbstverständlich, dass sich kurze Entwicklungszeiten von 3-4 Monaten wesentlich zuverlässiger planen lassen als Releases in 1 oder 2 Jahren. Häufige Releases, auch im B2B Umfeld, bieten zudem die Möglichkeit schneller auf Marktänderungen reagieren zu können. Deshalb stellen viele etablierte Softwareanbieter auf entsprechende agile Vorgehensmodelle um, um diese Flexibilität auch realisieren zu können.
Weitere Aufgaben eines Software Produktmanagers
Während die Aufnahme, Dokumentation, Verwaltung und Releaseplanung von Anforderungen zu den unumstrittenen Kernaufgaben eines Produktmanagers gehören, gibt es eine Vielzahl weiterer Aufgaben, die Produktmanager häufig übernehmen. Das ist dann aber abhängig, wie die Rolle des Produktmanagers in einer Firma geschnitten ist, wie komplex das Produktportfolio ist, ob es weitere Stellen wie Softwarekonzeption oder Produktmarketing gibt, usw.
In einem späteren Beitrag werde ich auf ein paar weitere spannende Aufgabengebiete eingehen, die die enorme Bandbreite der Aufgaben eines Software Produktmanagers veranschaulichen.
Update:
- meine Erfahrung zur Verknüpfung von Scrum und Produktmanagement
Sehr interessanter Artikel! Was mich aber noch interessieren würde, ist die Rolle des PMs im Kontext von Scrum und der Product Owner Rolle. Wo liegt denn deiner Meinung nach die Grenze zwischen den Verantwortungsbereichen eines PMs und eines POs?
Aus meiner Sicht ist ein Produktmanager gleich einem Product Owner im Scrum. Aber auch hier gibt es ganz viele Grautöne. So kann es zum Beispiel sein, dass ein Produktmanager sich mehr auf das Management der Anforderungen und Produktstrategie kümmert, während ein anderer Mitarbeiter die Rolle des Product Owners übernimmt, die Detailkonzepte ausarbeitet und die Umsetzung betreut.
Meiner ganz persönlichen Meinung nach ist es aber besser, wenn der Produktmanager direkt in den Entwicklungsprozess mit einbezogen wird. Man sollte lieber das Produktportfolio unter mehreren Produktmanagern aufteilen, damit jeder das Produkt von Strategie über Planung und Konzeption bis zur Umsetzung betreut. Dadurch hat man als Produktmanager einen besseren Überblick, was mit welchem Aufwand umsetzbar ist und trifft bei der Priorisierung realistischere Entscheidungen.
Aber ich wollte ja sowieso noch einen Beitrag schreiben, wo ich auch das nochmal vertiefen muss. Es fehlt ja auch noch die Abgrenzung zum Produktmarketing und der ganzen Rollout Unterstützung. Ich fürchte aber, dass wird jetzt 10 Tage dauern, bis ich mal wieder Zeit für einen Beitrag finde…
http://qz.com/117868/want-to-develop-the-best-product-learn-to-say-no-to-good-ideas/
Das schwerste und wichtigste am PM, imho.
@Jonas Genau, ist aber auch leichter gesagt als getan :-)
[…] ich die Hauptaufgaben eines Software Produktmanagers vorgestellt habe, kam die Frage auf, wie das Zusammenspiel von Produktmanagement und Scrum […]