Bleiben Sie beweglich: Agiles Produktmanagement als Innovationsmotor

Schritt für Schritt zum erfolgreichen Produkt

Dort wo Kund:innen, Technologie und Unternehmen aufeinander treffen, geht es um agiles Produktmanagement, wie wir es hier beschreiben. Um in diesem Dreieck eine Balance zu halten, sollten Sie ein Rahmenwerk definieren, das Sie hierbei unterstützt:

1. SELBSTANALYSE: Befassen Sie sich eingehend mit Ihrem spezifischen Marktsegment, lernen Sie die Konkurrenz kennen und definieren Sie Ihre Nische.
2. KUND:INNENANALYSE: Lernen Sie Ihre Kund:innen kennen. Welche Herausforderungen und Probleme treten ihnen entgegen und welche Lösungen würden diese sich wünschen?
3. PROBLEMANALYSE: Hier geht es darum, die Herausforderungen der Kund:innen genauer zu betrachten und sie zu validieren. Dazu lassen sich verschiedene Kriterien evaluieren:
   • Ursachenforschung: Stellen Sie Fragen, beispielsweise orientieren Sie sich anhand der 5-Warum Fragentechnik, um an die Quelle eines Problems zu kommen, so dass Sie mehr machen können als reine Symptombekämpfung.
   • Häufigkeit: Finden Sie heraus, mit welcher Frequenz Ihre Kund:innen die untersuchte Problematik erleben.
   • Ausmaße: Bestimmen Sie das den Anteil Ihres Zielmarkts, der das Problem regelmäßig erlebt und dadurch eingeschränkt ist.
   • Messbarkeit: Stellen Sie eine Beispielrechnung auf, um Kosten & Nutzen für Kund:innen quantifizierbar zu machen.
   • Aktualität: Prüfen Sie Ihr spezifisches Marktsegment auf neue Entwicklungen und prognostizierte Trends.
4. LÖSUNGSFINDUNG: Dafür entwickeln Sie Ihren Umsetzungsplan und gehen anhand messbarer Kriterien vor.
   • Rangordnung: Priorisieren Sie, welches Problem am dringlichsten zu beheben ist und dessen Lösung daher den größten Nutzen hat. Die Entscheidung fällen Sie durch die Evaluation des Kund:innennutzens, des Implementierungsaufwands, der Gewinnchancen sowie des benötigten Arbeitsaufwands/-fähigkeiten, etc.
   • Zeiteinteilung: Definieren Sie Meilensteine, einen Zieltermin und erstellen Sie einen detaillierten Plan inklusive geschätzter Dauer der verschiedenen Schritte für die Durchführung – dies hilft gleichzeitig dabei, die Vorstellungen nochmals zu qualifizieren und unter Umständen den Scope anzupassen.
   • Kommunikation: Kreieren Sie eine Story für Ihre Kund:innen und visualisieren Sie diese. Dazu definieren Sie die Endverbraucher:innen, stellen sein Problem heraus, beschreiben die Vorteile bei der Nutzung Ihres Produkts und kennen die Voraussetzungen für eine hohe Akzeptanz am Markt.
5. DURCHFÜHRUNG: Halten Sie sich an Ihren Zeitplan und werden Sie aktiv.
   • Most Viable Product: Erstellen Sie das MVP und validieren Sie dessen Schlüsselfunktionen. Sammeln Sie auch Nutzer:innen-Feedback, um die Prognosegenauigkeit und die Auswirkungen zu bemessen. Dauer etwa 1 – 2 Monate gemäß des Think Big – Start Small Ansatzes.
   • Marketing: Planung und Set-Up der verschiedenen Tools für die Interaktion mit Kund:innen (Verkauf, Support, Kund:innenorientierung). Dauer etwa 2 – 4 Monate.
   • Wiedereinführung: Verfassen Sie Ankündigungen, ermitteln Sie Schlüsselkund:innen erkennen Sie Support-Engpässe. Wie gestaltet sich die Nutzung Ihres Produkts?
   • Statistiken: Bereits mit der ersten Stufe der Markteinführung gilt es, Daten zu sammeln. Welche Rückmeldung kommt von Ihren Kund:innen? Stellen Sie Kriterien zusammen für Key Performance Indicators (KPIs), um Funktionsanforderungen anpassen, Verbesserungen durchführen und flexibel auf potentielle Veränderungen des Marktes reagieren zu können.
6. REVISION: Prüfen Sie die Fortschritte regelmäßig anhand messbarer Daten, um Verbesserungen vorzunehmen.
   • Kontrolle: Verfolgen Sie die KPIs, um zuvor festgelegte messbare Indikatoren datenbasiert zu überprüfen. Die Ergebnisse werden festgehalten und visualisiert.
   • Defizite: Planen Sie Verbesserungen anhand von Prognosegenauigkeit, Daten über die Nutzer:innenbindung und deren Feedback sowie die Zahl der kritischen Defekte.

Agiles Produktmanagement in der Praxis

In großen Unternehmen ist es immer eine Herausforderung, agiles Produktmanagement zu gestalten, besonders wenn sich die Planungs- und Kostengesichtspunkte hauptsächlich an einem Standardvorgehen orientieren. Beispielsweise wenn Mittelwert-, Portfolio- und Projektauswertungen etwa einmal im Jahr evaluiert und den jeweiligen Clustern zugeordnet werden.

Bei einem Produkt, das lediglich einem spezifischen Bereich oder einer einzelnen Funktion dient, gestaltet sich agiles Produktmanagement etwas einfacher als bei solchen, welche die Organisation auf globalem Level bestimmen und hier die Produkt Ownership nicht im Business sondern auf Seiten der IT liegt. Dies macht Sinn, da diese Services als sogenannte Plattformen und Infrastruktur bezeichnet werden und so Synergien cross-divisionaler Natur schaffen sollen. Das macht eine Planung mit einem divisionalen Top-Down Planungsprozess nicht unbedingt einfacher.

Wenn hingegen die Auswirkungen so bedeutend sind, dass mehr oder weniger Ihr komplettes Team involviert sein muss, so sind Änderungen, die sich auf tatsächliche Endanwender:innen auswirken, schwer mit der Anpassung Ihrer Plattform in Einklang zu bringen. Der Aufwand umfasst eine herausfordernde Abstimmung zwischen Ihren Stakeholder:innen, die bereits Ihre Plattform nutzen, deren neue Anforderungen und obendrein potentiellen neuen Kund:innen, die gleichzeitig versorgt werden wollen.

1. Beispiel: Agiles Produktmanagement für unternehmensweite Services

Abhängig vom Service Design kann agiles Produktmanagement von verschiedenen Faktoren beeinflusst werden, welche für die Planung beachtet werden müssen. In der Regel vereinen Services eine Vielzahl von Produkten und Technologien, die alle ihrem eigenen Lifecycle unterliegen. Wenn es dann zusätzlich zu einem generellen Architekturwechsel bei einer der Kernkomponenten kommt, stellt sich die Frage nach Aufwand und Nutzen, da dies unter Umständen auch massive Migrationsaufwände nach sich ziehen kann.

Hier macht es Sinn für Sie, sich darüber Gedanken zu machen, ob ein genereller Plattformwechsel möglicherweise kostengünstiger und zudem innovativer sein kann. In diesem Fall müssen Sie eine frühzeitige Information des Anbieters über diese großen Auswirkungen und eine gute Zusammenarbeit veranlassen, um das notwendige Budget zu allokieren und dessen Auswirkungen auf die gesamte Projekt- und Portfolioplanung proaktiv anzugehen. Nehmen Sie sich diese Zeit, um Stakeholder-Awareness zu generieren. Nach der Zuweisung des Budgets an den Service Eigentümer kann das Projekt für diese Veränderung beginnen.

Big Bang Ansätze sind hier möglicherweise nicht zielführend; ein agiles Produktmanagement bei der Einführung der neuen Architektur sollte in diesem Fall den Ansatz verfolgen, Prozess für Prozess voranzugehen, wenn der Service mit mehreren E2E-Prozessen verbunden ist, welche Auswirkungen auf die B2C-Zufriedenheit haben. Die Plattform selbst und die Vorbereitung des Backends folgen dann eher einem klassischen Einführungskonzept. Daraus ergibt sich ein “agiler Wasserfall-Ansatz” – hybride Ansätze sind für das Lifecycle Management von kritischen Unternehmensservices oft die besseren Konzepte.

2. Beispiel: Agiles Produktmanagement E2E für einen externen IT-Provider mit übergreifender Cloud-Philosophie

Agiles Produktmanagement aus Sicht der Entwickler:innen sollte einige Voraussetzungen erfüllen:

• Verfolgen Sie eine „DevOps“-Philosophie, oder sorgen Sie dafür, dass zumindest einige selbstverwaltete Services aus der Sicht des Product Owners vorhanden sind.
• In der Infrastruktur sollten genügend freie Ressourcen zur Verfügung stehen und horizontal skaliert werden, um nicht von Anfang Innovationen durch Mangel auszubremsen.
• Eine nutzenbasierte Verrechnung auf Applikationsebene bringt System Owner in die Kostenverantwortung um gewissenhaft mit den zur Verfügung gestellten Ressourcen zu handeln.
• Mittlere Ressourcenpools sollten mit etablierten Housekeeping-Services zur Verfügung stehen.

Sind diese Grundpfeiler etabliert, so ist die Basis für eine agile Entwicklung in einem ersten Schritt geschaffen. Ein weiterer Punkt ist das Bewusstsein über die Verantwortung und Akzeptanz, dass Fehler möglich sind und eine interne Servicekultur mit Serviceverantwortung etabliert werden sollte. Reviews durch interne Auditoren und Security sollten einen Mehrwert darstellen und keine Ängste erzeugen, wenn ein Problem gefunden wird. Ein Service-Katalog innerhalb der Organisation kann helfen. Es ist lohnenswert, wenn sich ein zentrales Architektur-Team um die Strategie kümmert, das beim Produktportfoliomanagement durch entsprechende Prozesse unterstützt. Vermeiden Sie eine Heldenhaltung der (Full-Stack) Entwickler:innen, denn in komplexen Organisationen kann niemand alles wissen und zudem ist es unserer Ansicht nach äußerst schädlich für den Teamgeist.

Sorgen Sie dafür, dass Kommunikations- und Kollaborationsplattformen eingerichtet sind, um das agiles Vorgehen zu unterstützen. Dies gibt Kund:innen die Möglichkeit, Anforderungen zu stellen und das Produktmanagement ist in der Lage, zu kommunizieren und über die neuen Features zu sprechen. Die gesamte Organisation sollte als Team mit klar definierten Verantwortlichkeiten agieren. Hier ist es vielleicht auch möglich, dass Sie sich einmal Gedanken über den Lean-Ansatz machen, da bei diesem auch das Lernen von Bedeutung ist. Um diesen Lean-Ansatz geht es auch in einem unserer anderen Artikel: So feiern Sie Erfolge in der VUCA World.

3. Beispiel: Agiles Produktmanagement in einem IT-Beratungsunternehmen für tech-affine Startups (1. Schritt in eine Produktverantwortung)

IT-Berater:innen in eine Product-Owner Haltung zu begleiten, ist eine herausfordernde Aufgabe. Oft kennen diese zwar die Philosophie der agilen Produktentwicklung, aber sie verstehen das Projektmanagement (das Vorgehen, was bis wann zu tun ist) nicht zu 100%. Das liegt daran, dass die Mehrheit der IT-Consultants es gewohnt sind, Anweisungen von außen zu bekommen. Sie werden beauftragt, die Implementierung nach möglicherweise bereits festgelegten Standards der Auftraggeber:innen durchzuführen. Bei der Testung und Freigabe des Produkts sind sie meist schon nicht mehr involviert und werden auch hier letztendlich nicht mit den Kund:innen in Kontakt kommen.

Diese Problematik hat nichts mit ihrer persönlichen Einstellung zu tun, sondern liegt eher in der Natur der Sache. Consultants suchen nach der für sie am besten scheinenden Lösung, womöglich ohne sich Gedanken über Wartungs- und Kosteneffekte sowie Skill- und Wissenstransfer zu machen. Daher könnte das essentielle Mindset der vollen Verantwortungsübernahme aus Sicht des Product Owners noch nicht voll vorhanden sein. Dass dies nicht von heute auf morgen kommt, ist völlig logisch. Es ist daher gut möglich, dass das Management eine Entscheidung treffen muss. Solche Themen sind normalerweise jedoch nicht Teil des Ansatzes der agilen Produktentwicklung, auch wenn das ein Parameter ist, um ein Produkt aus einer 360-Grad-Perspektive zu managen.

Somit kann es auch hier sinnvoll sein, den Lean-Ansatz zu verfolgen, bei dem Scheitern erlaubt ist und eher als Lernmöglichkeit denn als Misserfolg verstanden wird. Die gesamte Organisation inklusive Management und Führungsstil sollte darauf angepasst werden und Unterstützung suchen, wenn der Wechsel von einem reinen IT-Beratungsunternehmen zu einem Unternehmen mit Product Ownership vollzogen werden soll.