Produktmanagement ist eine klassische Schnittstellenfunktion und unterscheidet sich von Branche zu Branche, von Unternehmen zu Unternehmen und von Produkt zu Produkt. Während die Aufgaben eines Product Owners für den Entwicklungsprozess in Scrum sehr gut definiert sind, sind die übrigen Aufgaben weniger klar umrissen.

Schlussendlich ist es aber immer das Ziel eines Product Owners das Produkt erfolgreich zu machen. Insofern müssen alle Aufgaben die dafür notwendig sind klar sein – und wenn man nicht selbst dafür verantwortlich ist, muss klar sein wem die Aufgabe zugeordnet ist.

Stellt Euch also die Fragen:

Was sind meine Aufgaben für den Produkterfolg?

Wer ist sonst noch für wichtige Themen verantwortlich?

Sind notwendige Aufgaben nicht zugeordnet?

Klärt wer die Aufgaben übernimmt, die nicht zugeordnet sind – es ist sehr einfach: Wenn es kein anderer macht, macht es das Produktmanagement.

Ich finde zwei Frameworks sehr hilfreich um sich einen Überblick über alle Aufgaben zu verschaffen:

Während Roman Product Ownership von der agilen Seite aus betrachtet und vor allem darstellt, was für Aufgaben anfallen, um ein Produkt zu entwickeln und zu managen, ist das ISPMA Framework eher auf klassischen funktionalen Bereichen aufgebaut. Ich erwähne es hier vor allem, da es vielleicht dem ein oder anderen leichter fällt die Struktur zu verstehen und da es auf ein paar zusätzliche Punkte eingeht.

Roman unterteilt sein Framework in Core und Supporting Areas.

Die Kernaufgaben sind

  • Vision and Leadership
  • Strategy and Research
  • Business Model and Financials
  • Product Roadmap
  • User Experience and Product Backlog
  • Product Lifecyle Management

Zu den Supporting Areas gehören angrenzende Bereiche wie Marketing, Sales and Support, Project Release Management, Process, etc. Die Core Areas sind also klare Produktmanagement Aufgaben, während die Supporting Areas eher andere Bereiche unterstützen oder Mittel zum Zweck sind.

Roman sieht sein Framework als Grundlage um verschiedene Rollen, z.B. einen Technical Product Owner zu defineren. Product Roadmap, User Experience and Product Backlog Product und Lifecyle Management sehr operativen Charakter haben und immer im Verantwortungsbereich eines klassischen Product Owners liegen, sind Vision and Leadership, Strategy and Research und Business Model and Financials eher strategischer Natur. Abhängig von der Größe von Produkt und Firma sind diese oder große Teile davon dann vielleicht bei einem Head of Product, Chief Product Officer oder Chief Product Owner – Teile davon vielleicht sogar im Marketing oder einer anderen Abteilung.

Das ISPMA Framework unterteilt in Core Software Product Management, Participation und Orchestration – also sehr ähnlich wie in Core and Supporting Areas.

Es gibt natürlich vor allem im Core SPM viele Überschneidungen, das ISPMA Framework geht aber mit Delivery Model and Service Strategy und mit Legal and IPR Management auf zwei Aspekte des digitalen Produkts besonders ein, die man auf keinen Fall vernachlässigen sollte.

Das Framework zeigt unter Strategic Management auch, dass es gerade in größeren Organisationen noch andere Bereiche geben kann, in denen man als Produktmanager mitarbeitet.

In der Abgrenzung zum Development ist das Framework durch einen klassischen Entwicklungsprozess gekennzeichnet. Requirements Management – wenn man es noch so nennen will – ist in der agilen Welt immer Aufgabe des Product Owners. User Experience, sollte immer im Fokus vom Produktmanagement stehen – wenn das nicht Fall ist, kann man kein erfolgreiches digitales Produkt entwickeln.

In Summe geben beide Frameworks einen guten Überblick, der einem helfen sollte, keinen wichtigen Aspekte zu vergessen.

Roman`s Product Management Framework

 https://www.romanpichler.com/blog/romans-product-management-framework/

ISPMA Software Product Management Reference Framework

 https://ispma.org/wp-content/uploads/2014/12/ISPMA-SPM-FL-Syllabus-V.1.3.pdf