Produktmanagement Crashkurs

Was glaubst du haben Kodak Film, das iPhone, Spotify, oder iTunes gemeinsam? Alles sind Produkte. Manche von ihnen mehr, und manche von ihnen weniger erfolgreich. Wenn wir daran denken was diese Produkte erfolgreich macht, fallen uns meist Dinge wie Werbung, oder Technologie ein. Werbung und Technologie ändern sich ständig, aber wieso sind Produkte wie das iPhone und Spotify immer noch erfolgreich, während Kodak und iTunes verschwunden sind. Erfolgreiche Produkte schaffen es sich ständig mit dem Markt und mit den Erwartungen der Nutzer zu ändern - und das nennt man Produktmanagement.

Dieser Kurs ist für jeden der daran interessiert ist, bessere Produkte zu erschaffen. Produktmanagemet ist keine Jobbeschreibung, sondern eine Disziplin. Ob du Entwickler bist oder Project Manager und einfach mehr über Produktentwicklung erfahren willst, oder Product Owner, Start-Up Gründer bist, oder sogar bereits als Produktmanager arbeitest - mein Ziel ist, dass du in diesem Kurs die Basics über Produktmanagement lernst und wie man diese anwendet um bessere Produkte zu erstellen, die mehr Wert liefern.

In diesem Kurs werden wir anfangs über die Basics in Produktmanagement gehen. Anschließend lernt ihr über den Produktmanagement Lifecycle und wie ihr ein Produkt von null konzipieren könnt und wie man dieses agil entwickelt und auf den Markt bringt. In jedem Video werden wir auch konkrete Methoden besprechen wie Produktmanager die unterschliedlichen Aufgaben angehen.

Ich habe diesen Kurs erstellt um euch die Disziplin Produktmanagement näher zu bringen und konkrete Ansätze beizubringen . Produktmanagement ist in Deutschland nicht weit verbreitet, aber in internationalen Start-Ups kommt man ohne Produktmanager nicht mehr aus.

In vielen Firmen in Deutschland gibt es den Product Owner, aber der Unterschied zum Produkt Manager ist nicht immer klar. Die Resourcen die es online verfügbar sind, sind alle nur auf Englisch verfügbar und sind auf das typische amerikanische Silicon Valley Startup ausgerichtet. Damit will ich aufräumen.

Ich habe über 5 Jahre Erfahrung als Produktmanager und habe an unterschiedlichen digitalen Produkten mitgearbeitet. Momentan lebe und arbeite ich in Kuala Lumpur, Malaysia, bei einem dort ansässigen Start-up im Fintech Bereich undentwickle mit meinem Team kunden- und nutzerorientierte Apps, die es klein und mittelständischen Unternehmen erlaubt Rabat und Treueaktionen für ihre Kunden auf unserer Platform anzubieten.

Außerdem unterstütze ich andere Produktmanager, und Startups als Mentor und lehre aktiv Product Management bei verschiedenen digitalen Akademien, wie zum Beispiel PM School, Scaler, oder General Assembly Malaysia.

Es ist ziemlich einfach bekannte oder erfolgreiche Produkte aufzuzählen. Wenn man mich fragen würde wer der Produktmanager dahinter ist, hätte ich aber keine Ahnung. Man kommt vielleicht auf ein paar bekannte Persönlichkeiten, wie Jeff Bezos, Steve Jobs, oder  Bill Gates. Sie haben zwar nicht den Titel Produktmanager, was sie aber erfolgreich gemacht hat ist dass sie Produktmanagement anwenden.

Es ist wichtig zu unterscheiden, dass Produktmanagement nicht das gleiche ist wie ein Produktmanager.

Das eine ist die Rolle, das sind Leute deren Job es ist, Produktmanagement in ihrer Firma auszuführen. Produktmanagement selbst ist eine Disziplin - diese Unterscheidung ist wichtig, weil es gibt natürlich auch Firmen, die keine formalen Produktmanager in ihrer Organisationshierarchie haben, aber trotzdem Produktmanagement anwenden.

Für mich lautet die Definition von Produktmanagement so:

"Produktmanagement beinhaltet die strategische Entwicklung, Einführung und kontinuierliche Weiterentwicklung von Produkten einer Firma."

In manchen Firmen wird die Verantwortung für Produktmanagement von einem bestimmten Team getragen, zum Beispiel dem Produkt oder dem Engineering Team, manchmal wird die Rolle von einer bestimmten Person eingenommen. Es gibt einige Rollen die von Produktmanagement profitieren, wie zum Beispiel:

• Produkt Manager, natürlich

• Product Owners.

• Project Managers

• Geschäftsführer, oder Gründer

• CTOs oder technischer Vorstand

• Business Owner oder Geschäftsinhaber

Und viele weitere Rollen.

Produktmanagement wird gerne mit diesem Venn Diagram dargestellt. Wenn es um die Entwicklung von Produkten geht, kann man die unterschiedlichen Bereiche grob in UX: User Experience, Technologie, und Business einteilen.

User Experience bedeutet hier wie die Nutzeroberfläche des Produktes gestaltet ist, aber auch wie komplex der User Journey ist. User ist der Nutzer, der User Journey ist also der Weg den die Nutzer durchlaufen wenn sie das Produkt benutzen.

Bei Technologie geht es darum wie fortgeschritten die technologische Implementierung ist oder wie skalierbar das Produkt gebaut wird, also ob es für 1 Million Nutzer genauso gut funktioniert, wie für die ersten 1000.

Business, also Geschäftsfragen sind solche wie zum Beispiel das Produkt vermarket wird, oder das Geschäftsmodell, also wie die Firma Geld mit dem Produkt macht. Business kann aber auch rechtliche oder Compliance technische Fragen beinhalten.

Jeder der drei Bereiche kann einen großen Einfluss auf das Endprodukt haben und oft müssen Produktmanager zwischen diesen Bereichen priorisieren.

Stellen wir uns mal den Fall vor, dass ein konzipiertes Produkt von den Anforderungen her wunderschön designt ist und die Entwickler schon viel Arbeit kosten wird die User Experience Anforderungen zu implementieren. Gleichzeitig ist das Produkt aber auch technisch Anspruchsvoll. Der Zeitplan lässt aber nicht beides zu - und es muss priorisiert werden. Der Vertreter für die UX Seite will natürlich dass User Experience priorisiert wird, und der Vertreter für die Tech Seite, will dass Tech priorisiert wird. Produktmanager sind diejenigen die am Ende die Entscheidung tätigen müssen.

Ihr merkt schon dass es quasi unmöglich ist über Produktmanagement zu reden ohne englische Begriffe zu benutzen. Ich versuche immer so gut es geht den deutschen Begriff zu finden, oder den englischen Begriff zu erklären. Es ist aber nützlich die englischen Begriffe zu kennen, weil ihr damit dann selbstständig weiter recherchieren und lernen könnt.

• Der Geschäftsführer hatte eine Idee und gab sie dem Head of Design um die Idee zu implementieren.

• Basierend auf der Beschreibung des CEOs hat das Design Team einen Prototype angefertigt. Als das Design Team nach Feedback fragte, war der CEO zu beschäftigt mit anderen Dingen.

• Dear Head of Design gab den Prototyp weiter an das Entwicklerteam, die basierend darauf die technische Planung durchführen.

• Während des Entwicklungsprozesses merken die Entwickler, dass sie den Zeitplan nicht einhalten werden können, außer sie nehmen einige der Features aus dem Produkt.

• Das Marketing Team aber erhielt die selbe Produktbeschreibung vom CEO wie das Designteam und basierte ihren Marketing Plan darauf.

• Als das Produkt auf den Markt kommt sind Kunden verwirrt und verstehen das Produkt nicht, der CEO ist verärgert weil sein Lieblingsfeature nicht implementiert wurde. Das Produkt schafft es nicht die gesetzten Ziele zu erreichen, es werden keine weiteren Ressourcen investiert und wird 3 Monate später wieder abgeschaltet.

Ich habe Geschichten wie diese oder ähnliche erlebt immer wenn ein Produkt nicht von einem Produktmanager begleitet wurde, oder wenn der Produktmanager seinen Job nicht gut machte. Wie kann es also besser laufen?

Schauen wir uns dazu mal den Produktentwicklungsprozess genauer an. Ich stelle ihn gerne in 6 Phasen dar.

Product Discovery kann hier gleichgesetzt werden mit Erkundung. Jedes Produkt beginnt idealerweise an dieser Stelle und beinhaltet dass man sich Klarheit verschafft was genau das Problem ist, das man lösen möchte. Problem kann für vieles stehen, zum Beispiel Feedback von Nutzern, oder dass ein Konkurrent ein neues Produkteingeführt hat. Aus irgendeinem Grund hat sich die Firma entschieden, dass es ein Problem gibt, dass es Wert ist gelöst zu werden.

Dies kann ein ganz neues Produkt sein, ein kleines Feature oder sogar etwas so minimales wie ein Bug. Im Idealfall durchläuft alles, woran du und mit Team arbeitest, jede der 6 Phasen. Wenn du jedoch einen Bug behebst, der sehr einfach ist und bisher auch niemand bemerkt hat, dass dieser Bug da ist, macht es wahrscheinlich wenig Sinn den Prozess streng nach den Regeln zu befolgen. Dann kannst du auch einfach direkt ohne den Discovery und Design Prozess zu durchlaufen, direkt zu deinem Team gehen und ihnen sagen dass sie den Bug fixen sollen. Der Prozess den ich hier Beschreibe bildet alle Schritte ab, die man im Zweifelsfall durchlaufen sollte, aber es liegt natürlich immer in der Diskretion des Produktmanagers und wie sicher man sich seiner Lösung ist.

In der Discovery Phase arbeitet man eng mit anderen Teams zusammen, wie zum Beispiel den Sales oder Vertrieb Teams, Marketing, Designern, und allen anderen die mitzureden haben. Das Ziel dieser Phase eine geeignete Lösung für das richtige Problem zu finden. Wie man geeignete Probleme findet werden wir in späteren Videos klären.

Anschließend ist es in der Verantwortung des Design Teams aus den Anforderungen die geeignete User Journey und einen Designprototypen zu erstellen. Der Designprototyp sieht genauso aus wie die App, oder Website, das Produkt halt, am Ende aussehen soll - ein 1:1 Abbild. Nur dass der Prototyp aus Bildern entsteht und keine funktionale App ist. Das Ziel ist aber dass der Prototyp täuschend echt aussieht. Das erlaubt es den Entwicklern und anderen Teams genau zu verstehen, wie das Produkt am Ende auszusehen hat.

Je nachdem, wie groß das Feature ist wird das Engineering Team die Arbeit, basierend auf dem Prototyp, in einzelne Meilensteine aufteilen und mit der Entwicklung beginnen. Daher erfordert der Entwicklungsprozess normalerweise viel technische Planung. Je nachdem, wie deine Firma strukturiert ist, wirst du dich mehr, oder weniger an dem Prozess beteiligen. In meinem Job bei Fave arbeite ich sehr eng mit den Ingenieuren zusammen und nehme normalerweise an den technischen Planungsmeetings teil, um die Produktanforderungen zu klären, während die Ingenieure versuchen, die Features zu verstehen. In anderen Firmen kann diese Verantwortung auch auf einen Scrum Masters oder einen Projektmanager fallen. In jedem Fall wird das Team oft während der technischen Planung feststellen, dass etwas, das du geplant und für super einfach und super sinnvoll gehalten hast, so einfach nicht funktionieren kann - und dann musst du dir nochmal deine Anforderungen und Änderungen vornehmen. Manchmal stellt sich auch raus, dass der Design-Prototyp nicht alle Produktanforderungen abdeckt und der Designer nochmal ran muss. Das Hauptziel dieser Phase ist es, funktionierende Software zu produzieren.

Erst wenn das Team die Software so fertiggestellt hat, dass sie getestet werden kann, wird sie an die nächste Phase weitergegeben. Abhängig von der Struktur deiner Firma gibt es vielleicht ein QA - Quality Assurance oder Qualitätssicherungs-Team - manchmal liegt das Testen in der Verantwortung der Entwickler selbst, und manchmal muss sogar der Produktmanager sich beim Testen die Hände schmutzig machen. Ziel dieser Phase ist es sicherzustellen, dass Ihre neue Funktion oder Ihr neues Produkt keine Fehler enthält. Abhängig von der Komplexität des Produktes können sich durch neue Features auch Fehler in anderen Teilen des Systems einschleichen. Bevor neue Funktionen released - also veröffentlicht werden können muss das Team normalerweise einen End-to-End-Test des gesamten Systems durch.

Um das Produkt zu releasen, arbeitet der Product Manager eng mit dem Marketing-Team zusammenarbeiten und stellt sicher, dass es einen Markteinführungsplan oder einen Produkteinführungsplan erstellt. Das Marketing Team benötigt die Hilfe vom Product Manager damit sie die Funktionsweise des Produkts und richtig verstehen und den Mehrwert den das Produkt liefert an den Endnutzer erfolgreich kommunizieren können. Dadurch wird sichergestellt, dass die unterschiedlichen Nachrichten die das Marketingteam veröffentlicht, wie z.B. Emails, oder auf der Website, alle mit dem übereinstimmt, was das Produkt auch liefern kann.

Nach dem Launch des Produkts ist es auch Aufgabe des Produktmanagers, die wichtigsten Messdaten zu überwachen und festzustellen, ob alles wie erwartet funktioniert. Normalerweise legen Sie vor dem Start eine Erfolgshypothese fest, anhand derer du weisst, ob dein Produktlaunch erfolgreich war. Wenn Sie Ihre Messdaten nicht erreichen, kannst du tiefer gehen und verstehen, warum Ihr Produkt nicht wie erwartet funktioniert, und Lösungen finden, um es besser zu machen.

Ich hoffe es wurde klar, dass an diesem 6 teiligen Prozess viele verschiedene Teams und Stakeholder beteiligt sind. Produktmanager stehen jedoch im Mittelpunkt, weil deren einzigartige Aufgabe es ist sicherzustellen, dass die Arbeit, die das Engineering-Team leistet, den größtmöglichen Wert für das Unternehmen erbringt, dass das Produkt sinnvoll ist, und am Ende erfolgreich im Markt platziert wird.

Wenn man den Titel Produktmanager liest ist es einfach eine falsche Vorstellung von der Rolle zu bekommen. Produktmanager sind nicht unbedingt derjenigen, die alle Ideen generiereren, oder diejenigen die anderen sagen was sie zu entwickeln haben.

Alleine kannst du deinen Job nicht machen. Deine Aufgabe ist es alle relevanten Stakeholder - Mitglieder von Teams, die an dem Produkt beteiligt sind, zusammenzubringen um die beste Lösung für ein bestehendes Problem zu finden. Als Produktmanager ist man also für das Problem verantwortlich, und dafür dass man das richtige Problem löst, und jeder das gleiche Verständnis von dem Problem hat.

Es passiert oft, dass jemand Produkte erstellt, die niemand will. Ein Gründer, oder eine Firma stellt ein Team zusammen, und erstellen ein Produkt aus einer Idee, die in einem Brainstorming entstand. Nach unzähligen Stunden Arbeit stellt das Team das Produkt fertig, zu einem hohen Preis für die Firma.Das Produkt ist super, gut programmiert, super designed, aber trotzdem... ist es ein Fehlschlag. Es macht keinen Unterschied wie gut deine Entwickler sind, wenn man ihnen Projekte gibt die keinen Sinn ergeben.

Natürlich löst man dieses Problem nicht, in dem man einfach einen Produktmanager in das Team setzt. Produktmanagement, ebenso wie jede andere Disziplin , ist extrem schwierig. Das Problem ist eher, dass es wenig Möglichkeiten gibt gescheites Training für die Rolle zu bekommen. Oft wird man einfach in die Rolle reingeworfen. Das führt dann dazu, dass Leute diese Aufgabe erfüllen, die nicht dazu geeignet sind, und diejenigen die mit diesen unerfahrenen Produktmanagern arbeiten bekommen die falsche Vorstellung, was ein Produktmanager eigentlich sein sollte, wie zB:

• Ideengeber

• Mini-CEO - formale Autorität

• "People Pleaser" - macht nur was man ihm / ihr sagt

• Projektmanager

• Arbeitet nur am Produkt

Mein Ziel ist es euch die wichtigsten Bereiche in Produktmanagement aufzuzeigen, damit ihr alle Facetten der Rolle gut ausüben könnt.

Wenn ich mit anderen Leuten in diesem Bereich rede, bemerke ich oft, dass es viel Unsicherheit gibt, was genau ein Produktmanager und ein Product Owner tut, und was der Unterschied zwischen ihnen ist. Was ich dir sagen kann ist ganz einfach: Unabhängig davon, welche Definition du im Internet findest, sie ist auf den Fall falsch - und sie ist falsch, weil es keine einzigartige Definition gibt. Jedes Mal, wenn ich mit einem Produktmanager oder einem Product Owner spreche, erfahre ich etwas Neues darüber, was bei denen in ihrer Firma unter ihre Verantwortung fällt und was nicht.

Um ein besseres Verständnis zu erhalten, schauen wir uns die verschiedenen Dinge an, die in den Bereich des Produktmanagements fallen - und dafür werden wir das Venn-Diagramm von vorher verwenden:

Diese Bereiche können dann auf die 6 Phasen des Produktentwicklungsprozess abgebildet werden.

Wenn wir uns die erste Phase, Discovery, anschauen, versuchen wir zu verstehen, was der Business Case ist, das Problem, das wir zu lösen versuchen. Wir schauen uns an, was die Konkurrenz macht. Gleichzeitig setzen wir uns mit unseren Usern auseinander und versuchen rauszufinden wie diese momentan das Problem lösen. Wir arbeiten an Personas - das sind die repräsentativen Eigenschaften unserer Nutzer, und versuchen die bestmögliche Lösung für sie zu finden.

Bei der eigentlichen Entwicklung des Produktes, also wenn die Developer anfangen zu programmieren, beschäftigen wir uns mit dem technischen Teil und stellen unsere Produktanforderungen so bereit, dass das technische Team sie implementieren kann. Wir stellen sicher, dass alle User Stories - die individuellen Anforderungen - bereit sind entwickelt zu werden. Gleichzeitig arbeiten wir ständig an den nächsten Anforderungen, so dass wir immer ganz genau wissen, was das nächste ist, woran die Programmier arbeiten werden - diese Liste von Anforderungen nennen wir den Backlog. Wir kümmern uns auch darum, dass alles für den nächsten Release - das ist wenn eine Ansammlung von User Stories zusammen veröffentlicht werden - rechtzeitig fertiggestellt wird.

Eine Definition die ich oft gehört habe für Produktmanager gegenüber Product Ownern, ist, dass sich der PO viel mehr auf die technische Seite konzentriert, also die Entwicklungsphase, während sich die PM mehr mit den Anfangsphasen wie zB Discovery und Design befasst. Es gibt also auch Firmen, wo der Produktmanager die grobe Richtung vorgibt und die Vision für das Produkt entwickelt, die Fertigstellung und Implementierung dann aber an den Product Owner weitergibt. Aber wie gesagt, das ist nur eine Definition.

Ich möchte mehr darauf eingehen, wie das alles bei Fave funktioniert. Wir haben ein Produktdesign-Team welches sich sehr stark einbringt. Dieses Team ist nicht nur gut darin Designprototypen zu entwicklen, sie können auch ganz eigenständig Problemstellungen angehen und Ideen soweit zu bringen, dass der Produktmanager diese direkt an das Development Team weitergeben kann. Das erlaubt es mir, mich weniger auf den UX-Teil konzentrieren und wir können mehrere Produkte gleichzeitig angehen. Für die meisten Produkte an denen wir arbeiten gibt es einen sogenannten Business Owner - das ist normalerweise jemand aus dem Marketing- oder Sales Team, der uns hilft mehr über die Business Seite des Produktes zu verstehen - vorallem wenn wir Produkte für unsere Geschäftskunden entwickeln haben diese Teams viel mehr Erfahrung was diese Nutzer eigentlich wollen. Sie haben aber auch viel Einfluss auf das Geschäftsmodell, wie wir den Preis für das Produkt festlegen. Was wir bei Fave aber nicht haben, ist ein Scrum Master oder Projektmanager - daher arbeiten wir sehr eng mit unserem Engineering-Team zusammen. Trotzdem lautet meine Stellenbeschreibung Product Manager, nicht Product Owner.

In Projektmanagement geht man jedes Projekt so an, dass man jede Phase des Projekts, also die Planung, die Durchführung und Implementieren, vollständig abschließt bevor man mit der jeweiligen nächsten beginnt. Dieser Ansatz wird Waterfallprozess genannt. In der Softwareentwicklung durchläuft Waterfall weiterhin dieselben Schritte wie im vorherigen Video, von Discovery, Design, Development bis hin zu Testing und Launching. Bei Waterfall bedeutet das aber, dass alle Produktanforderungen zu 100% erfüllt sein müssen, da du nach der Übergabe an Design keine Möglichkeit mehr haben wirst, Änderungen anzufordern. Gleiches gilt für die Entwicklung. Die Designerin kann ihre Meinung nicht ändern und eine Änderung anfordern. Dies wird in der modernen Produktentwicklung problematisch. Meistens wissen wir nicht, was die Nutzer wollen, und wir müssen das Produkt oder Feature erst veröffentlichen, um zu sehen, ob die Nutzer es gut finden. Es kann Monate oder sogar Jahre dauern, den Wasserfallprozess vollständig zu durchlaufen und Zeit und Geld zu verschwenden bevor wir etwas über das Produkt oder unsere Nutzer lernen können. Produkte sind in den meisten Fällen nicht erfolgreich wenn sie das erste mal auf den Markt kommen.

Aus diesem Grund unterscheiden wir im Allgemeinen die Hauptverantwortlichkeiten von Produktmanagern und Produktmanagerinnen gegenüber Projektmanagern und Projektmananagerinnen.

Der Hauptunterschied zwischen den Verantwortungsbereichen besteht darin, dass sich der Projektmanager die meiste Zeit darauf konzentriert, sicherzustellen, dass das Engineering-Team das Produkt pünktlich, im Umfang und innerhalb des Budgets abliefert. Der Fokus des Produktmanagers liegt jedoch darauf, sicherzustellen, dass das Team an den richtigen Dingen, also den wertvollsten, den besten Ideen arbeitet. Dies wird nicht unbedingt dadurch erreicht, dass man immer einem strengen Plan folgt sondern erfordert auch mal Flexibilität. Wenn wir einen 6 Monatsplan haben, wir aber nach einem Monat merken, dass es bessere Dinge gibt die wir entwickeln könnten, sollten wir das auch zulassen.

Schauen wir uns also an, wie Projektmanager traditionell im Vergleich zu Produktmanagern arbeiten. Ich habe das Wasserfallmodell bereits erwähnt. Mike Tyson hat mal gesagt: „Jeder hat einen Plan, bis er eine ins Gesicht bekommt“ - und wenn wir mit Produkten arbeiten, auf einem Markt mit Wettbewerb und Kundenbedürfnissen, und einer externen Umgebung, dann werden wir auch manchmal ins Gesicht geschlagen.

Um in einem sich beständig ändernden Umfeld aufzuhalten, hat die moderne Softwareentwicklung den Begriff der agilen Softwareentwicklung hervorgebracht. Agile Softwareentwicklung folgt dem agilen Manifest.

1. Individuen und Interaktionen statt Prozesse und Tools

2. Funktionierende statt umfassende Dokumentation

3. Zusammenarbeit mit den Kunden statt Vertragsverhandlungen

4. Reaktion auf Änderungen statt einen Plan befolgen

Um diese Prinzipien zu erreichen, teilt agile das gesamte Projekt in kleine Zyklen auf, die zwischen 1 und 4 Wochen dauern können. Wir nennen diese Zyklen Sprints. Jeder Sprint durchläuft die selben 6 Phasen, die wir bereits benannt haben. Das Entwicklerteam bekommt also immer ein begrenztes Pentium an Arbeit, dass diese auch in einem Sprint erledigen können. Sobald das Team dann ein Feature implementiert und veröffentlicht hat, kannst du schauen, was mit dem Verhalten deiner Nutzer und Nutzerinnen passiert und wie die Produktmetriken sich verändern. Du kannst direkt Nutzerfeedback erhalten und sofort den Plan für den nächsten Sprint anpassen. Da der Sprint mit 1-4 Wochen relativ kurz ist, kannst du auf diese Weise sicher sein, dass du, falls es eine neue Idee oder ein neues Problem aufkommt, dein Team sich darum relativ zügig kümmern kann, ohne den aktuellen Sprint abzubrechen.

Viele denken, dass das Ziel von Agil ist, dass deine Entwicklerinnen zügiger arbeiten können. Das stimmt so nicht. Das Ziel von Agil ist, dass das Produkt i kürzerer Zeit sein volles Potential erfüllen kann - dadurch, dass man es früher auf den Markt bringt und Fehler ausmerzen kann.

Frag jede Produktmanagerin, wie ihr Tag aussieht, und sie wird sagen: "Meeeeetiiiiiiings". Während dies für die meisten meiner Tage zutrifft, ist es wichtig zu verstehen, dass wir nicht Meetings durchführen, einfach weil wir Meetings mögen - wenn du merkst, dass du ständig in Meetings bist, an denen du eigentlich gar nicht teilnehmen willst, oder wo du nichts beizutragen hast, dann machst du etwas falsch.

Die meiste Zeit verwendet man als Produktmanagerin für die Verwaltung des Produktentwicklungsprozesses aufgewendet, wie ich in den vorherigen Videos beschrieben habe. Abhängig von dem Unternehmen in dem du arbeitest, kollaborierst du möglicherweise sehr eng mit Entwicklern und arbeitest täglich mit ihnen zusammen. Andererseits könnte es auch den Projektmanager oder die Scrum Masterin geben, die diesen Teil für dich erledigen. In jedem Fall besteht deine Aufgabe immer darin, den Wert zu maximieren, den das Engineering-Team realisieren kann. Du solltest also ständig deine Zeit damit verbringen, dein Produkt sozusagen aus der Vogelperspektive zu betrachten. Das heißt, dass du ständig über deine Nutzer und Nutzerinnen nachforschst, dich mit ihnen triffst um sie zu interviewen, Marktforschung betreibst, oder mit dem Produktdesign Team an der nächsten Produktidee arbeitest. Wenn du die Arbeit für dein Team für den nächsten Sprint geplant hast, beginnst du direkt von vorne. Der Start des nächsten Sprints ist nur wenige Tage entfernt - während des Sprints ist immer vor dem Sprint.

Was heißt das konkret... Wenn dein Team anfängt, an den Features oder Produkten zu arbeiten, die du für den aktuellen Sprint priorisierst hast, musst du bereits über den Nächsten nachdenken. Eine Faustregel, die ich mit den Produktmanagerinnnen in meinem Team praktiziere ist dass jeder von uns versucht zu jedem Zeitpunkt drei Produkte, Projekte oder Features zu haben, an denen jeder von uns gleichzeitig arbeitet. Diese sind:

1. Das Produkt, das sich derzeit in der Entwicklung befindet: Deine Entwickler werden wahrscheinlich Fragen zu den Anforderungen haben, oder es gibt Probleme oder Unklarheiten, das du nicht vorhergesehen hast und behoben werden müssen. Das könnte zum Beispiel sein, dass eine Lösung nicht so wie das Design sie vorgesehen hat implementiert werden kann.

2. Das Produkt, das du zuletzt auf den Markt gebracht hast: Ein Produkt ist nie fertig. Nachdem man ein neues Produkt launcht, beobachtet man die Metriken, schaut ob alles so läuft wie vorgesehen, und findet Wege, um dieses Produkt weiter zu verbessern.

3. Die nächste Gelegenheit: Was ist das Feature oder das Produkt woran dein Team als nächstes arbeiten wird wird.

Dazu wirst du ständig den Kontext wechseln müssen und ständig mit all deinen Stakeholdern zusammenarbeiten müssen- und natürlich sind viele Meetings erforderlich. Als PM wirst du dich nie langweilen.

Es ist nicht immer offensichtlich, was du als nächstes für dein Produkt priorisieren solltest. Damit du das weißt, musst du dir über deine Produktstrategie im Klaren sein. Die Produktstrategie beantwortet zumeist die folgenden drei Fragen:

1. Das Warum: Warum gibt es unser Produkt und für wen lösen wir ein Problem und wer ist unsere Zielgruppe? Das ist deine Produktvision.

2. Das Wie: Wie misst du den Erfolg deines Produktes - und wie weisst du ob du der Erfüllung deiner Produktvision näher kommst.

3. Das Was. Was ist das einzigartige Unterscheidungsmerkmal unseres Produkts und welchen Wert können wir unserem Produkt bieten, den sonst niemand bieten kann? Was tun wir momentan um näher an unsere Produktvision zu kommen?

In den meisten Fällen hat diese Fragen schon jemand beantwortet und du wirst an einer bestehenden Produktstrategie arbeiten. Wenn du aber ein neues Produkt auf den Markt bringst, musst du aber eine Strategie formulieren und Produkt definieren, das im Endeffekt die Antwort auf die Produktstrategie ist. Viele Unternehmen oder Produktmanager machen den Fehler, alle 100 Features zu definieren, die das Produkt benötigt, um erfolgreich zu sein, und sie können sich nicht vorstellen, ihr Produkt mit auch nur einer einzigen fehlenden Funktion auf den Markt zu bringen. Das widerspricht jedoch dem, was ich vorher beschrieben habe - die Idee der Agilen Entwicklung. Deshalb versuchen Produktmanagerinnen neue Produkte in der Regel immer mit einem sogenannten Minimum Viable Produkt, oder MVP auf den Markt. Direkt übersetzt heißt das das minimal lebensfähige Produkt.

Was damit gemeint ist, ist ein Produkt das die kleinste Anzahl an Features besitzt um in der Lage zu sein den Endnutzern und Nutzerinnen den Wert zu liefern für das es entwickelt wurde. Jeder erkennt an, dass das Produkt besser sein könnte. Mit dem MVP versuchen wir zu validieren, dass die Produktidee überhaupt einen Mehrwert liefern kann und auf dem Markt bestehen kann. Stellen Sie sich mal vor unser Produkt wäre ein Donut. Wenn wir einen Donut haben, wo der Teig schon beschissen ist, kann man soviel Streußel oder Schokladenglasur draufmachen wie man will, man macht ihn damit nicht zu einem besseren Produkt.

Machen wir uns das mal Anschaulicher an Spotify. Heute nutzen wir alle Spotify mit der mobilen App, wir die Möglichkeit, Musik runterzuladen und später offline zu hören. Es gibt Podcasts - so viele Podcasts... Als Spotify aber zum ersten Mal verfügbar wurde, gab es nur eine Desktop version - und man konnte nur aus einem sehr begrenzten Musikangebot streamen. Zu diesem Zeitpunkt gab es aber keinen solchen Streaming-Services - das Team von Spotify hatte also keine Ahnung ob ihr Produkt überhaupt ankommen würde. Obwohl sich das Team wahrscheinlich schon diese ganzen Features ausgedacht hatte, wollte Spotify keine Zeit verschwenden all das zu entwickeln. Sie wollten testen ob der Markt für die Grundidee bereit ist - und bauten ihren Spotify MVP.

Wenn wir neue Produkte entwickeln, MVPs definieren oder uns Features ausdenken ist es immer wichtig zu wissen, was eigentlich entwickelt werden muss. Du willst nicht in der Situation sein, dass du ein Brainstorming führst, indem deine Stakeholder ungetestete Ideen einbringen, die nicht mit irgendeiner Form von Nachweis hinterlegt sind. Dann wird einfach nur die Idee gewählt die sich am coolsten Anhört - aber am Ende am Markt scheitert. Versteh mich nicht falsch - einige der besten Produktideen sind in Brainstormings entstanden. Du musst aber in der Lage sein, die richtig guten Ideen unter dem Schrott zu finden und bewerten zu können. Es gibt einige Methoden, mit denen Produktmanagerinnen nach neuen Ideen für ihr Produkt suchen.

1. Wettbewerbsanalyse: Der einfachste Weg, neue Ideen für ein bestehendes Produkt zu finden, besteht darin, sich umzusehen, was die Konkurrenz tut. Du kannst schnell erkennen was der Grund ist warum manche deiner Nutzer zur Konkurrenz gehen - und oft ist es der beste Weg die Konkurrenz einfach nachzuahmen. Steve Jobs, der Gründer von Apple hat mal gesagt: "Kopieren ist die aufrichtigste Form der Schmeichelei". Du solltest aber nicht einfach alles nur blind kopieren, denn dadurch wirst du genau so wie deine Konkurrenz - und du darfst nie vergessen: es gibt auch Gründe warum deine aktuellen Kunden dein Produkt nutzen. Wen du zu viel kopierst, verlierst du eventuell was dich Einzigartig macht - deinen Differenzierungsfaktor.

2. Alternativen: Ähnlich wie bei deiner direkten Konkurrenz, kannst du dich auch bei deinen indirekten Konkurrenten oder auch in ganz anderen Bereichen umschauen. Manchmal gibt es Produkte, die komplett verschieden von deinem sind, ein bestimmtes Problem auf eine Weise, die auch bei deinem Produkt funktionieren könnte. Manche Dinge funktionieren in allen Produkten auf die selbe Weise. Jeder benötigt einen Anmeldebildschirm, jeder Onlineshop hat einen Produktkatalog. Slack und E-Mail sind sehr unterschiedliche Produkte, aber sie lösen das gleiche Problem und können auch voneinander lernen.

3. Nutzerforschug bedeutet, sich mit seien Benutzerinnen persönlich auseinander zu setzen. Für viele ist das eine unangenehme Aufgabe weshalb es auch einer der am wenigsten genutzten Möglichkeiten ist um neue Produktideen zu entwickeln. Deine Nutzer wissen oft mehr über das Produkt als du selbst und einige von ihnen haben ausgeprägte Meinungen darüber, wie dein Produkt besser sein könnte. Lerne von ihnen, indem du entweder Kundeninterviews durchführst oder Umfragen startest.

Wenn ein Produkt bereits aktiv benutzt wird, kann man auch Produktanalysen durchführe. Beim Erstellen von Features und Produkten können deine Entwicklerinnen dafür sorgen, dass Daten gesammelt werden, wie Nutzer mit dem Produkt interagieren. Auf diese Weise kannst du Verbesserungsmöglichkeiten entdecken. Zum Beispiel könntest du merken, dass manche Leute ihr Profil nicht schnell genug erstellen oder gar nicht vollständig ausfüllen. In dem Fall könntest du dir die Daten ansehen und zu verstehen versuchen, an welchem Punkt genau die Nutzer aufhören ihr Profil zu vervollständigen - um dadurch eventuell ein Problem zu identifizieren. Auch wenn es kein Problem gibt, können dir die Daten häufig Einblicke geben, wie die Nutzer das Produkt verwenden, oder auch welche Funktionen sie nicht verwenden.

Und natürlich kommunizierst du viel mit Stakeholdern. Stellen dir die Situation vor, dass du Produktmanagerin für Microsoft Teams bist und dein Konkurrent Slack hat letztlich eine mega gute neue Funktion released. Die Führungsetage will von uns dass wir die Funktion für unser Produkt nachbauen - was würdest du also machen? Als Produktmanagerin ist es deine Aufgabe die Kommunikation mit den Stakeholdern zu bewältigen damit dein Team nicht von deren momentanem Fokus abgelenkt wird. Also, was ist zu tun?

1. Was ist die Motivation deines Stakeholders: Warum möchten sie, dass du dieses Feature entwickelst, und was ist die Angst was passiere wird, wenn wir es nicht tun? Je nachdem solltest du deine Antwort anpassen

2. Priorisiere die Anfrage: Es liegt in deiner Verantwortung, Erwartungen festzulegen und klar zu kommunizieren. Wenn du diesem "Feature Request" - wie wir so eine Anfrage nennen, nicht nachkommen kannst, solltest du mittteilen warum nicht. Ein Grund könnte sein, dass es nicht in die Produktstrategie passt, oder dass das Team gerade mit etwas wichtigerem beschäftigt ist. Wenn dein Team sich darum zu einem späteren Zeitpunkt kümmern wird. In jeden Fall solltest du Klarheit schaffen, was deine Stakeholder von dir erwarten können. Entscheidest du dich dafür der Anfrage nachzugehen, solltest du auch dafür sorgen, dass du die Anfrage komplett verstehst und alle Produktanforderungen sammelst bevor du das Produkt mit deinem Entwicklerteam besprichst.

3. Kommunikation über Systeme: Als Produktmanagerin wirst du dich sehr häufig wie ein kaputter Kasettenrekorder fühlen, der ständig das gleiche wiederholt. Wenn du also ein Feature Request ablehnst, kannst du dir Sicher sein, dass diese Anfrage immer wieder kommen wird, von anderen, aber auch von der selben Person wieder - und du musst also auch immer wieder erklären warum du dieses Feature nicht entwickeln wirst. Um das zu vermeiden, kannst du öffentliche Dokumente wie Roadmaps, oder Strategiedokumente verwenden, um die Strategie und momentanen Prioritäten deines Produktes ständig und proaktiv immer wieder zu kommunizieren.

Es ist Teil der Jobbeschreibung der Produktmanagerin oft nein zu sagen, und das macht Stakeholder Management schwierig. Man möchte natürlich niemanden Enttäuschen, und auch nicht rüberkommen dass man nicht Lösungsorientiert ist. Es ist aber letztendlich Aufgabe der Produktmanagerin dafür zu Sorgen, dass alles an dem das Entwicklerteam arbeitet am Ende auch Sinn ergibt - und wenn es eins gibt von dem Stakeholder nie genug haben, ist es Feedback oder Feature Requests an dich. Du musst also entscheiden, was davon Sinn ergibt und was nicht.

Hiermit befinden wir uns am Ende dieses gratis Einstiegskurses. Ich gehe bewusst nur kurz auf die wichtigsten Themen im Leben von Produktmanagern und Produktmanagerinnen ein um euch das nötigste zu geben um selbständig weiter zu recherchieren. Ich arbeite momentan aber auch an einem längeren Kurs in dem ich auf alle Themen die ich hier angesprochen habe näher und mit praktischen Beispielen eingehen will.

Icons im Vorschaubild designed und bereitgestellt von macrovector / Freepik