Agiles Produktmanagement: Leitfaden zu Prozessen & Rollen

Es gibt eine große Menge an Inhalten, Leitfäden, Lehrbüchern, Kursen und Zertifizierungen zum agilen Produktmanagement. Ehrlich gesagt brauchen Sie das alles nicht.

Im Kern basiert agiles Produktmanagement auf einer einfachen, menschenorientierten Philosophie. Viele der Prozesse, in denen Agile Gestalt annimmt, sind einfach und leicht zu verstehen. Die Komplexität entsteht jedoch durch missverstandene Erwartungen, Rollen und Prozesse.

In diesem Leitfaden werden wir:

• Agiles Produktmanagement, seine Philosophie und die Prozesse erkunden, in denen es Gestalt annimmt.
• Die Rollen betrachten, aus denen ein typisches agiles Produktentwicklungsteam besteht, sowie ihre Aufgaben und ihre Zusammenarbeit.

Das Verständnis dieser zentralen Bereiche ist wichtig. Es wird Ihnen die Werkzeuge zur Einführung oder Verbesserung des agilen Produktmanagements in Ihrem Team oder Ihrer Organisation an die Hand geben.

Was ist agiles Produktmanagement?

Agile ist eine Philosophie darüber, wie Teams effektiv zusammenarbeiten können, um ein Ziel zu erreichen. Das ursprüngliche Agile-Manifest aus dem Jahr 2001 bringt die agilen Prinzipien am besten zum Ausdruck:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das ist die Seele des agilen Produktmanagements. Es gibt keine Erwähnung von Story-Punkten oder Schwimmbahnen. Keine täglichen Kurzbesprechungen oder Sprints.

Obwohl das Agile-Manifest die Verwendung von Prozessen und Werkzeugen nicht vorschreibt, stellt es deren Bedeutung zugunsten einer menschenorientierten, anpassungsfähigen Zusammenarbeit in den Hintergrund. Wenn man sich zum ersten Mal mit agiler Produktentwicklung beschäftigt (oder auch zur Auffrischung), kann es aufschlussreich sein, mit dem Manifest bei den Grundlagen zu beginnen.

Wenn wir uns mit den praktischen Aspekten von Agile befassen, ist es wichtig, das Manifest weiterhin im Hinterkopf zu behalten. Prozesse, Dokumentation und Planung sind allesamt großartig. Wenn Sie sich jedoch in einer Situation wiederfinden, in der Sie oder Ihr Team ihnen Vorrang vor den Menschen in Ihrem Team oder einem funktionierenden Produkt einräumen, sollten Sie darauf achten.

Werfen wir einen Blick auf einige der feineren Punkte der Denkweise der agilen Produktentwicklung.

Menschenorientiert

Agile Softwareentwicklung konzentriert sich darauf, die Menschen zu befähigen, aus denen Ihr Produktteam besteht. Um sie gut zu praktizieren, müssen Sie den Menschen, mit denen Sie arbeiten, wirklich vertrauen. Ohne Vertrauen ist die psychologische Sicherheit Ihres Teams gefährdet, und eine produktive Zusammenarbeit kann ins Stocken geraten.

Benutzerorientiert

Ein unermüdlicher Fokus auf Ihre Benutzer ist unverzichtbar. Schließlich entwickeln wir für sie, nicht wahr?

Ein effektives agiles Team befragt kontinuierlich Benutzer, um Feedback zu seinen Produkten zu erhalten. Es verschickt und verarbeitet Umfragen, um die Priorisierung der Entwicklung neuer Funktionen voranzutreiben. Agile Produktmanager suchen stets nach Möglichkeiten, die Arbeit in kleine, veröffentlichungsfähige Aufgabenpakete aufzuteilen, die unterwegs mit Benutzern validiert werden können, und achten dabei darauf, eine schleichende Ausweitung des Funktionsumfangs zu vermeiden.

Wenn wir die Benutzer nicht regelmäßig an den Tisch einladen, kann das, was wir heute planen, morgen bereits ungültig sein.

Herausfordernd

Agiles Produktmanagement ist unglaublich anspruchsvoll – und zwar nicht aus den Gründen, die Sie vielleicht erwarten.

Effektive agile Teams haben im Allgemeinen weniger Prozesse und weniger formelle Berichterstattung als ihre nicht agilen Pendants. Das liegt daran, dass Agile den Fokus auf einen kontinuierlichen Arbeitsfluss und Transparenz legt, um die Zusammenarbeit anstelle einmaliger Meilensteine zu priorisieren.

Mit dem Mangel an Prozessen geht für viele Produktmanager auch das Gefühl eines Kontrollverlusts einher. Dennoch tragen sie weiterhin ein hohes Maß an Verantwortung, das mit der Rolle verbunden ist. Das richtige Maß zu finden, sich zurückzuhalten und den Fokus des Teams nicht zu beeinträchtigen, ist eine Kunst und kann je nach Team unterschiedlich sein, abhängig von der jeweiligen Dynamik.

Wenn ein Produktmanager jedoch den Ansatz einer dienenden Führungskraft verfolgt, kann dies langfristig mehr Vorteile – und ironischerweise mehr Kontrolle –  mit sich bringen als sonst. Das liegt an den positiven Effekten, die durch das Vertrauen in agile Prozesse entstehen können.

Ideal ist auch eine Arbeitskultur, die Agilität unterstützt. Es ist möglich, ohne Unterstützung für Agilität damit zu beginnen, aber das wird schwieriger sein und Sie werden feststellen, dass Sie gegen den Strom schwimmen. Eine Organisation, die Agilität unterstützt, kommt mit bewusst vagen Plänen zurecht, da sie versteht, dass Pläne im Laufe der Zeit klarer werden.

Lean

Lean in der Praxis umzusetzen ist entscheidend. Eine kompromisslose Fokussierung auf die Ergebnisse hält agile Teams mit wenigen Ablenkungen auf das Ziel ausgerichtet. Wenn man sich auf die geringstmögliche Menge an Arbeit konzentriert, die zur Erreichung des Ziels erforderlich ist, kann das Team weiterhin vorankommen und so schnell wie möglich Markterfolge erzielen.

Agiler Ablauf

Bevor wir uns mit einigen spezifischen Prozessen befassen, die Sie zur Einführung eines agilen Produktmanagements nutzen können, sprechen wir zunächst über den allgemeinen Prozessablauf und die Schritte der agilen Methodik, denen die meisten Prozesse folgen werden. 

Verwandte Lektüre: So implementieren Sie die Prinzipien eines agilen Produktportfoliomanagements

Strategie

Eine großartige agile Entwicklung beginnt mit einer guten Strategie und Abstimmung. Alle Teammitglieder in einem Raum (oder einer Zoom-Besprechung) zusammenzubringen, kann Wunder bewirken, um eine gemeinsame Produktvision und -richtung zu entwickeln. Erwägen Sie den Einsatz ansprechender Software für visuelle Zusammenarbeit, um sicherzustellen, dass die Aufmerksamkeit der Beteiligten nicht nachlässt.

Dies kann dem Team die Gelegenheit geben, sich auf den Geschäftsplan, die visuelle Ausrichtung, die Zielnutzer und vieles mehr abzustimmen. Es dient als wichtiger gemeinsamer Ausgangspunkt, auf den sich das Team konzentrieren kann.

Es ist wichtig zu beachten, dass die in dieser Phase erstellten Pläne und Dokumentationen als Annahmen behandelt werden. Sie sind darauf ausgelegt, im Laufe der Zeit regelmäßig überprüft und weiterentwickelt zu werden.

Experiment

Alles ist ein Experiment. Direkt zu Beginn sollte der erste fokussierte Arbeitsabschnitt, den Sie durchführen, zeitlich begrenzt und anschließend mit Nutzern getestet werden. Diese Arbeit kann äußerst rudimentär sein, sogar so einfach wie grobe Skizzen, die Sie jemandem erläutern.

Der entscheidende Punkt ist, die Arbeit mit der Denkweise der wissenschaftlichen Methode anzugehen. Wir sind Wissensarbeiter, und als solche liegt unser Fokus nicht ausschließlich auf der Umsetzung. Es geht auch um die Schaffung und Entdeckung von Wissen.

Testen

Jedes Experiment sollte qualitativ und quantitativ getestet werden. Durch eine regelmäßige Überprüfung der Ergebnisse verfügen Sie über die nötigen Instrumente, um zu bestätigen, dass das, was Ihr Team entwickelt, einen Wert bietet und am Markt angenommen wird.

Validieren

Nachdem Sie eine neue Funktion veröffentlicht haben, sollten Sie ihre Nutzung im Blick behalten. Wird sie verwendet? Finden die Nutzer sie? Wurden andere Bereiche Ihres Produkts durch die Einführung dieser Funktion positiv oder negativ beeinflusst?

Wenn Sie regelmäßig überprüfen und nachverfolgen, was Sie nach seiner Fertigstellung veröffentlichen, erhalten Sie weitere Instrumente und Orientierungshilfen, um noch bessere Entscheidungen zu treffen.

Wiederholen

Dies ist der wichtigste Schritt. Durchlaufen Sie den agilen Prozessablauf immer wieder, wie ein Motor. Dieser Ablauf ist bewusst zyklisch und nicht linear angelegt, um das Lernen zu fördern. Lernen Sie daraus. Passen Sie sich daran an. Feiern Sie ihn. Nehmen Sie den Wandel an.

2 gängige agile Ansätze

Agilität ist eine befähigende Philosophie, die Teams auf kollaborative Weise auf ein gemeinsames Ziel ausrichtet – auf eine Art, die mit übermäßig strukturierten Prozessen und Berichtswesen nicht möglich wäre.

Dennoch sind einige Prozesse sinnvoll. Wenn sie ordnungsgemäß umgesetzt und unter Berücksichtigung der einzigartigen Kultur eines Teams eingesetzt werden, können Prozesse als Leitplanken dienen, die ein Team auf die Erreichung seiner Ziele fokussieren und gleichzeitig kreative Freiheit unterstützen.

Wir sehen uns einige der beliebtesten Prozesse an, die die agile Philosophie in die Praxis umsetzen.

Scrum

Scrum ist wohl der beliebteste agile Prozess, und das aus gutem Grund: Er unterteilt Verpflichtungen und Lernprozesse in festgelegte Zeitblöcke, sogenannte „Sprints“. Dies fördert ein gesundes Maß an Lernen und mehr Möglichkeiten, sich an diese Erkenntnisse anzupassen.

Im Zentrum dieser Sprints steht das Scrum-Team selbst. Bei Scrum gibt es keine Titel: Jeder Entwickler im Team hat die Rolle eines „Entwicklers“. Dies fördert eine intensive Konzentration des Teams auf die Zusammenarbeit und das Erreichen des Ziels jedes Sprints. 

In der Praxis bedeutet das, dass ein Testingenieur, der auf eine zu testende Funktion wartet, diese Zeit nutzen kann, um mit der Programmierung einer neuen Funktion zu beginnen. Diese funktionsübergreifende Denkweise ist unglaublich wirkungsvoll, wenn sie funktioniert, denn sie ermöglicht es einem Team, hervorragende Ergebnisse zu erzielen.

Scrum zielt darauf ab, Besprechungen zu minimieren, um konzentrierte Entwicklungszeit zu fördern. Zu diesem Zweck gibt es eine Reihe wiederkehrender Besprechungen oder Zeremonien:

• Sprint-Planung: Dient dazu, die Arbeit zu planen, zu der sich das Team für den Sprint verpflichten möchte.
• Sprint-Review (Demo): Eine Gelegenheit, sich gegenseitig und den Stakeholdern Fortschritte zu zeigen und Erkenntnisse zu besprechen.
• Sprint-Retrospektive: Eine offene Gelegenheit für das Team, auf den vorherigen Sprint zurückzublicken und zu besprechen, was gut gelaufen ist, was nicht funktioniert hat und wo es Möglichkeiten zur Weiterentwicklung gibt.
• Backlog-Pflege und Aufwandsschätzung: Dabei handelt es sich um einen wiederkehrenden Zeitraum zur Überprüfung und Priorisierung des sich ständig verändernden Produkt-Backlogs auf Grundlage geschäftlicher und technischer Erkenntnisse. Sobald Einigkeit über die Elemente im Backlog besteht, werden sie zu Planungszwecken geschätzt.
• Tägliche Kurzbesprechungen: Ein regelmäßiger Zeitpunkt jeden Tag, an dem das Team mitteilt, was es gestern abgeschlossen hat, woran es heute arbeitet und ob es durch etwas blockiert wird.

Um die sprintorientierte Arbeit mit dem großen Ganzen zu verbinden, empfiehlt Scrum die Verwendung von „Aufwandspunkten“ zur Schätzung in strukturierten Sprint-Planungssitzungen. Dabei handelt es sich um einen willkürlichen Aufwandswert, den das Team jedem Backlog-Element zuweist.

Besonders wirkungsvoll ist, dass dadurch die Erfassung der Geschwindigkeit unterstützt wird. Damit ist die durchschnittliche Anzahl an Aufwandspunkten gemeint, die das Team in jedem Sprint abschließt. Nach einigen ersten Sprints sollte sich dieser Wert eingependelt haben und für eine gezielte Prognose und Planung von Veröffentlichungen verwendet werden können.

Wenn diese Werkzeuge gemeinsam mit dem Team gewissenhaft eingesetzt und von einem erfahrenen Scrum Master angeleitet werden, kann Scrum ein wirkungsvoller Prozess sein, der eine fokussierte agile Entwicklung unterstützt und umfangreiche Möglichkeiten für effektive Iterationen bietet.

Kanban

Kanban übernimmt vieles von Scrum und umfasst zahlreiche bekannte Elemente wie die Backlog-Pflege, ein an ein Sprint-Board erinnerndes Aufgabenboard und mehr.

Während Scrum jedoch den Fokus auf eine kleine Menge an Arbeit legt, betont Kanban den kontinuierlichen Arbeitsfluss.

Im Mittelpunkt dieses Prozesses steht das Kanban-Board. Die Elemente werden auf der linken Seite fortlaufend priorisiert und durch den individuellen Prozess des Teams nach rechts bewegt, bis sie mit „erledigt“ enden. Um die Arbeitslast auszugleichen, kann jede Spalte häufig eine Begrenzung der gleichzeitig laufenden Arbeit (WIP) enthalten, die festlegt, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen.

Kanban eignet sich hervorragend für Support-Arbeiten oder Teams, die nur unregelmäßig Kapazitäten zusagen können.

SAFe, XP und andere Methoden

Es gibt viele weitere Varianten agiler Prozesse, die jeweils auf bestimmte organisatorische Anforderungen und kulturelle Normen zugeschnitten sind.

SAFe ist ein umfassendes agiles System zur Umsetzung von Agilität im großen Maßstab innerhalb einer Organisation, typischerweise eines Großunternehmens. Es besteht aus mehreren „agilen Release-Zügen“, bei denen es sich im Wesentlichen um einzelne Scrum-Teams handelt. Es sind mehrere Rollen und Zeremonien beteiligt, um sicherzustellen, dass alle Teams auf gemeinsame Organisationsziele und Veröffentlichungspläne hinarbeiten.

Extremprogrammierung (XP), DevOps, Modern Agile und andere Methoden existieren, um agile Anwendungsfälle für bestimmte Rollen oder Kulturen abzudecken.

Das Experimentieren mit verschiedenen agilen Praktiken ist sinnvoll. Es kann zu einem wirksamen Verständnis dafür führen, was für die eigene Organisation funktioniert.

Zertifizierungen im agilen Produktmanagement

Wahrscheinlich sind Ihnen die zahlreichen Zertifizierungen aufgefallen, die Sie für jeden beliebigen agilen Prozess erwerben können. Sie werden so vermarktet, dass Sie den Eindruck gewinnen, ihr Prozess sei der einzig richtige Weg und dass Sie ohne eine kostspielige Zertifizierung nicht wirklich in der Lage sein werden, den Prozess anzuwenden.

Ignorieren Sie das.

Im Idealfall liefert Ihnen dieser Leitfaden genug Anstoß, um Ihren eigenen Lernweg einzuschlagen. Agile Methoden sind ein Werkzeugkasten für Praktiker und nichts, worüber Sie geprüft werden. Vertrautheit mit dem Prozess, den Zeremonien und der für jeden Prozess spezifischen Dokumentation ist zwar wertvoll, doch wenn man zum Manifest zurückgeht, ist es wichtiger, Ihr Team in die Umsetzung des von Ihnen gewählten agilen Prozesses einzubeziehen. Es gibt Organisationen, die sich der Erstellung und Pflege von Zertifizierungen widmen; naturgemäß liegt es in ihrem eigenen Interesse, den Prozess über die Menschen zu stellen.

Ist das wirklich agil?

Alles das soll sagen, dass dies lediglich eine warnende Geschichte ist, während Sie Ihre eigene agile Lernreise gestalten. Zertifizierungen können wertvoll sein. Wenn Sie an einem Workshop teilnehmen, kann dies eine gezielte Möglichkeit sein, schnell alle Einzelheiten eines bestimmten Prozesses zu erlernen. Manche Organisationen schätzen es, wenn Sie zertifiziert sind, da sich dadurch schnell Vertrauen aufbauen lässt.

Wenn das Anstreben einer Zertifizierung Ihnen hilft, Ihr gewünschtes Ergebnis zu erreichen, und dafür nur ein minimaler Aufwand erforderlich ist, dann tun Sie es. Wenn Sie jedoch keine Zertifizierung benötigen, sind Experimentieren und kontinuierliches Lernen bei der Umsetzung agiler Methoden der effektivste Weg auf Ihrer agilen Reise.

Verwandt: Die 4 besten Online-Zertifizierungen für agiles Produktmanagement

Welche Rollen gibt es in der agilen Produktentwicklung?

Bei der Betrachtung agiler Prozesse haben wir begonnen, eine Reihe von Kernrollen zu benennen, aus denen ein agiles Produktentwicklungsteam besteht. Zu diesen Rollen gehören:

• Produktmanager
• Produktverantwortlicher
• Entwickler
• Designer
• Testingenieur / QA

Im Allgemeinen verfolgt jede Organisation ihren eigenen Ansatz hinsichtlich der Ausgestaltung dieser Rollen. Beispielsweise können die Verantwortlichkeiten eines Produktmanagers in einem Unternehmen eher den Aufgaben eines Produktverantwortlichen in einem anderen Unternehmen entsprechen. Unter Berücksichtigung dieser Flexibilität wollen wir uns nun einige der umfassenderen Definitionen ansehen, die die Rollen in einem Produktteam veranschaulichen.

Oft gibt es Überschneidungen zwischen Produktverantwortlichen, Produktmanagern und Projektmanagern, und Teams können eine, zwei oder alle drei dieser Rollen besetzen. Produktmanager oder Produktverantwortliche übernehmen häufig Projektmanagementaufgaben, wenn es im Team keinen Projektmanager gibt.

Produktmanager

Also, was macht ein Produktmanager? Der Produktmanager ist nun ja, für die Verwaltung des Produkts verantwortlich.  Die zentrale Verantwortung der Rolle im Produktmanagement besteht darin, sicherzustellen, dass alles auf die Erreichung wichtiger Ergebnisse ausgerichtet ist, die auf Nutzertests, dem Input des Teams und strategischer Planung basieren.

Effektives Produktmanagement dreht sich jedoch um die Befähigung des Produktteams. Deshalb ist der Produktmanager eine generalistische Rolle. Das bedeutet, dass er über ein breites Kompetenzspektrum verfügen muss, um effektiv zu sein, aber nicht unbedingt ein versierter Entwickler oder Designer sein muss (obwohl es üblich ist, dass Mitarbeiter aus Produktionsrollen ins Produktmanagement wechseln).

Ein generalistisches Kompetenzprofil ermöglicht es dem Produktmanager, als empathische, dienende Führungskraft für sein Team zu agieren. Mit gerade genug Verständnis dafür, was die Entwicklung erfordert, kann der Produktmanager das Team bei einer effektiven Produktdefinition und -planung unterstützen, ohne dabei die Kompetenzen des Teams zu beeinträchtigen.

Verwandter Artikel: Warum Produktmanagement wichtig ist

Verantwortlichkeiten des Produktmanagers

• Produktergebnisse
• Backlog-Verwaltung
• Stakeholder-Management
• Nutzertests
• Verfassen von Nutzergeschichten
• Moderation eines funktionsübergreifenden Teams
• Verwaltung der Produkt-Roadmap
• Produktanalysen

Produktverantwortlicher

Während der Produktmanager für den taktischen Erfolg des Produkts verantwortlich ist, trägt der agile Produktverantwortliche die Verantwortung für den geschäftlichen und marktbezogenen Erfolg.

Im Allgemeinen ist der Produktverantwortliche eine zentrale Geschäftsrolle, die manchmal auch ein zentraler Stakeholder für das Produktteam sein kann. Sein Marktverständnis und sein auf das Geschäft fokussierter Blick aus 50.000 Fuß Höhe machen ihn zu einer wichtigen, sachkundigen Ressource, die dabei hilft, das Produktteam auf Erfolg auszurichten. 

Verantwortlichkeiten des Produktverantwortlichen

• Produkterfolg 
• Marktforschung und -kenntnisse
• Geschäftsentwicklung
• Finanzierung
• Entscheidung bei Stimmengleichheit

Eine häufige Herausforderung ist die Überschneidung und die Unterschiede zwischen der Rolle des Produktverantwortlichen und der des Produktmanagers. Manchmal ist diese Rolle Teil der Rolle des Produktmanagers und umgekehrt. Wenn die beiden Rollen getrennt sind, überschneiden sie sich häufig. Einige Organisationen verteilen die Verantwortlichkeiten des Produktmanagers und des Produktverantwortlichen sogar um.

Das ist jedoch in Ordnung!

Trotz der Herausforderungen, die entstehen können, können diese Rollen unglaubliche Ergebnisse erzielen, wenn sie zusammenarbeiten, um ein gesundes Gleichgewicht sich ergänzender Zusammenarbeit zu finden. Beispielsweise kann sich eine Rolle unermüdlich auf das Produkt konzentrieren, während die andere den Fokus auf das Geschäft richtet. Eine Rolle kann sich auf die Details und die technische Umsetzung des Produkts konzentrieren, während die andere den Fokus auf die übergeordnete Marktpositionierung legt.

Wenn diese beiden Rollen anschließend zur Zusammenarbeit verbunden werden, können sich wie durch Zufall wegweisende strategische Erkenntnisse ergeben, die sich positiv auf den Erfolg des Produkts und des Teams auswirken. Schließlich sind zwei Köpfe besser als einer!

Entwickler

In einem effektiven Produktteam besteht die Rolle des Entwicklers nicht nur darin, Code zu schreiben: Entwickler arbeiten mit allen Rollen an strategischer und technischer Planung sowie an Empfehlungen zusammen.

Entwickler, die über fundierte Kenntnisse von Tools für die Produktentwicklung, den Bedürfnissen der Benutzer und den Zielen der Produkt-Markt-Passung verfügen, können einen technischen Plan erstellen, der wie angegossen zum Produkt passt. Wenn Mitglieder des Entwicklungsteams mit diesem Wissen und der Fähigkeit ausgestattet werden, wichtige technische Entscheidungen zu treffen, kann dies den Unterschied zwischen einer einmonatigen Entwicklungszeit und einem Vielfachen davon ausmachen, da diese Entscheidungen technische Kompromisse mit sich bringen.

Wenn Ihre Entwickler in den Produktbereich Ihres Entwicklungsteams integriert sind, können sie den Erfolg des Teams vervielfachen.

Verantwortlichkeiten des Entwicklers

• Produktentwicklung
• Technische Planung und Forschung
• Beratung zum Technologie-Stack
• Funktionales Prototyping
• Unit-Tests
• DevOps (manchmal eine separate Rolle)
  • Erstellung und Verwaltung der Bereitstellungspipeline

Designer

So wie Entwickler nicht auf das Schreiben von Code beschränkt sein sollten, sollte der Einfluss von Designern in einem Produktteam über die Erstellung eines Designs hinausgehen. Tatsächlich entstehen einige der besten Kooperationen in einem Produktteam durch die Zusammenarbeit zwischen dieser Rolle und der des Produktmanagers.

Designer in Produktteams betrachten zunächst strategisch die Produktstrategie und das Geschäft. Sie sind häufig die stärksten Fürsprecher der Benutzer im Team. Diese Erkenntnisse ermöglichen es ihnen, anschließend zu designen, wenn auch mit einem gezielten Fokus.

Die Schaffung von Effizienz bei der Entwicklung und beim Lernen ist ein zentraler Schwerpunkt von Designrollen. Die Erstellung von Designsystemen befähigt Entwickler, durch Workflows für kontinuierliche Integration schnell neue Funktionen zu entwickeln. Durch die Erstellung interaktiver, visueller Prototypen werden Benutzertests ermöglicht, bevor eine einzige Codezeile geschrieben wurde, um weitere Investitionen zu validieren.

Verantwortlichkeiten des Designers

• Produktdesign
• Entwürfe
• Prototyping
• Erstellung eines Styleguides
• Erstellung und Pflege eines Designsystems
• Benutzertests in Zusammenarbeit mit dem Produktmanager
• Laufende Benutzerforschung

Testingenieur / QA

Ein Testingenieur (manchmal auch als Qualitätssicherung oder QA bezeichnet) kann eine der wirkungsvollsten Rollen in einem Produktteam sein. Während der Schwerpunkt dieser Rolle auf dem Testen der Produktfunktionen liegt, bevor diese für die Benutzer veröffentlicht werden, kann der scharfe Blick des Testingenieurs dabei helfen, den Fokus des Teams vor der Entwicklung einer neuen Funktion zu schärfen.

Testingenieure sollten bereits in den frühesten Phasen der Produktentwicklung einbezogen werden. Dadurch kann die Rolle Abnahmekriterien für die Nutzeranforderungen des Produkts definieren, die dem restlichen Team als Leitfaden für die Fertigstellung der Arbeit dienen.

Mit einer benutzerorientierten Denkweise können Testingenieure vor möglichen Folgen einer bevorstehenden Veröffentlichung warnen. Wenn diese Rolle den Produktverantwortlichen strategisch beraten kann, kann sie einen spürbaren Einfluss auf den geschäftlichen Erfolg oder Misserfolg einer neuen Veröffentlichung für Benutzer haben.

Verantwortlichkeiten des Testingenieurs/der Qualitätssicherung

• Funktionstests
• Regressionstests
• Erkundungstests
• Definition von Abnahmekriterien
• Fortlaufende Risikobewertungen und -analysen

Weitere Rollen

Während die zuvor genannten Rollen ein Produktteam bilden, gibt es viele Rollen außerhalb des Teams, die den ergebnisorientierten Fokus des Teams unterstützen.

Zu diesen Rollen gehören Marketing, Vertrieb, Kundensupport und weitere. In der Regel werden diese Rollen in die Organisation eingebunden, um das Produkt zu unterstützen, sobald sich der Erfolg auf dem Markt abzeichnet. Typischerweise sind sie nicht Teil des Produktteams. Eine starke und kooperative Beziehung zu diesen Rollen trägt jedoch zusätzlich zum geschäftlichen Erfolg bei.

Zusammenarbeit

Während jede Rolle in einem Produktteam ihren eigenen Fachbereich hat, wird davon ausgegangen, dass alle zusammenarbeiten. Wenn jede Rolle eine „T-förmige“ Denkweise in das Team einbringt, können alle ihre besondere Fachkompetenz beitragen und gleichzeitig den Fokus auf das Produkt als Teil der jeweiligen Rollendefinition annehmen. Jeder geht in seinem eigenen Fachgebiet in die Tiefe und erweitert gleichzeitig den Blick in die Breite auf alle anderen Kompetenzbereiche, um gemeinsam als Einheit erfolgreich zu sein.

Zusammenarbeit in einem Produktteam bedeutet, dass ein unerbittlicher Fokus auf den Produktergebnissen und der Nutzererfahrung liegt. Alle werden in die Verwirklichung dieser Vision eingebunden und gehen als geschlossenes Team gemeinsam voran.

Fazit

Wichtigste Erkenntnisse

• Agiles Produktmanagement ist eine menschen- und nutzerorientierte Philosophie, um schneller die richtigen Ergebnisse zu liefern.
• Obwohl Agilität im Kern einfach ist, entstehen durch Prozesse, die Organisationskultur und weitere Faktoren Komplexität und Herausforderungen.
• Agile Prozesse und Rollen können durch Methoden wie Scrum, Kanban, SAFe und weitere gesteuert werden.
• Zu den Rollen eines agilen Produktteams gehören Entwickler, Designer, Testingenieure, ein Produktmanager und ein Produktverantwortlicher.

Agiles Produktmanagement ist unglaublich und bewusst einfach. Es ist eine leistungsstarke Philosophie, die den Wert vervielfachen kann, den dein Team schaffen kann. Je tiefer du jedoch in die Prozesse und Rollen eintauchst, die es unterstützen, desto komplexer droht es zu werden.

In dieser Komplexität verbergen sich Möglichkeiten, dein Produktteam und deine Organisation zu stärken. Es ist ein Balanceakt, diese Methoden mit deinem Team einzusetzen und gleichzeitig sicherzustellen, dass sie während der normalen Zusammenarbeit nicht unbeabsichtigt zu organisatorischen Reibungsverlusten führen.

Wenn Agilität jedoch gut und mit einer experimentierfreudigen Haltung umgesetzt wird, kann sie den zukünftigen Erfolg deines Produktteams vorantreiben.

Hast du erlebt, wie Agilität umgesetzt wurde, oder eigene Erfahrungen damit? War es ähnlich oder anders als in diesem Leitfaden beschrieben? Lass es uns in den Kommentaren wissen! Vergiss nicht, unseren Newsletter für Produktmanager zu abonnieren, um weitere Einblicke und Leitfäden zu erhalten.

Oder lerne weiter, indem du dir diesen Podcast ansiehst, den du ganz bequem lesen, ansehen oder anhören kannst: Abstimmung durch Produkt-Roadmaps (mit Brandon Blackman von Crema)

Verwandte Beiträge:

• Was ist eine agile Großanforderung? Bewährte Verfahren, Vorlage & Beispiel
• So erstellst du eine agile Roadmap
• Lebenszyklus einer Softwareveröffentlichung (SRLC): Die 6 wichtigsten Phasen verstehen

Das solltest du dir ebenfalls ansehen:

• So verwenden Sie monday.com für Produktmanagement
• So erstellen Sie eine effektive Stellenbeschreibung für einen agilen Produktmanager (+Beispiel)
• Die 15 besten Frameworks zur Priorisierung von Produktfunktionen: Welches ist das beste?
• 8 bewährte Verfahren für Funktions-Flags, die Sie kennen sollten
• Kostenlose Vorlagen für Produkt-Roadmaps, mit denen Sie Ihre Stakeholder beeindrucken
• So verfassen Sie effektive Software-Versionshinweise, die Benutzer begeistern
• Visuelle Berichtstools für Produktdaten
• Kanban-Tools für Produktmanagement