Der Agile Produktmanager

Agile Produktmanager stehen vor besonderen Herausforderungen.
Hier sind einige Tipps für den Wechsel von klassisch zu agil.

Habe eine Vision

Veränderung ist in der agilen Produktentwicklung immer willkommen. Ergeben sich im Laufe des Projektes neue Erkenntnisse, so ist es durchaus sinnvoll, diese in die Produktentwicklung einfließen zu lassen, auch wenn dies bedeutet, dass Änderungen an bestehenden Teilen des Produktes vorgenommen werden müssen oder sogar ganze Teile weggeworfen werden. Das bedeutet aber nicht, dass man nur auf Sicht fahren und nur an den nächsten Sprint denken sollte. Versuchen Sie mit dem Team, eine gemeinsame Vision für das geplante Produkt zu entwickeln. Durch eine gemeinsame Vision wird dem Team klarer, in welche Richtung das Produkt gehen soll. Ein besseres Verständnis der geplanten Lösung hilft, Entscheidungen über das Produktdesign zu erleichtern.

Treffe Entscheidungen

Entscheidungen zu treffen ist eine der anstrengendsten Aufgaben, die ein Mensch hat. Leider bringt die Entwicklung eines Produktes viele wichtige Entscheidungen mit sich, damit später ein erfolgreiches Produkt entsteht. Sei es die Priorisierung der Merkmale oder die endgültige Zielgruppe. Der Produktmanager muss so schnell wie möglich die richtigen Entscheidungen treffen.

Hier sind ein paar Tipps, um bessere Entscheidungen zu treffen:

  • Versuchen Sie, alle Entscheidungen auf der Grundlage einer zuvor definierten Produktvision zu treffen. Die Entscheidungen müssen auch im Einklang mit den Unternehmenszielen stehen.
  • Nutzen Sie alle Informationen, die Sie erhalten können, insbesondere die Meinung Ihres Teams. Aber treffen Sie keine Entscheidungen, von denen Sie nicht überzeugt sind. Sie müssen Ihr Produkt lieben.
  • Wenn möglich, validieren Sie Optionen auf der Grundlage von Fakten und Daten anstelle eines Bauchgefühls.
  • Wenn es keine offensichtliche perfekte Alternative für die Entscheidung gibt, verschwenden Sie nicht zu viel Zeit auf den Entscheidungsprozess. Done is better than perfect!

Focus!

Dieser Teil geht eigentlich an Ihren Chef. Produktmanager ist kein Teilzeitjob. Hohe Energie, Verfügbarkeit für das Team, die Entwicklung von Anwendergeschichten und das Treffen von Entscheidungen erfordern volle Aufmerksamkeit.

Versuchen Sie, alle unnötigen Ablenkungen von Ihnen fernzuhalten. Minimieren Sie die unnötige Vorbereitung von Berichten und Interessengruppen. Sorgen Sie vielmehr dafür, dass die Beteiligten an den Scrum-Ritualen wie Demos teilnehmen, um sich ein Bild vom Entwicklungsstand zu machen, und nutzen Sie vorhandene Artefakte wie das Sprint Backlog und Epics, um die Roadmap zu kommunizieren.

Deadlines sind für Dich, nicht für das Team

Das neue Produkt ist noch nicht einmal in der Planungsphase, und es gibt bereits sehr starke Erwartungen im Unternehmen, wann das Ganze fertiggestellt werden muss. Ob es nun der Beginn einer Messe ist, auf der das neue Produkt gezeigt werden soll, oder eine andere Veranstaltung, die das Rollout-Datum als starre Linie im Zeitplan vor jeder Planung festlegt. Auch wenn Ihnen diese Erwartung sehr auf den Schultern wehtut und Sie diese Last ins Team tragen wollen. Dieser Termin gilt nur für Sie, den Produktmanager, nicht für das Team. Durch den Scrum-Prozess, die Priorisierung des Backlogs, die inkrementelle Entwicklung mit einem “versandfähigen” Produkt alle zwei Wochen, hat der Produktmanager alle Werkzeuge in der Hand, um die Erwartungen an den Umfang des Produkts zu managen und theoretisch jederzeit, je nach Reifegrad des Produkts, produktiv gehen zu können. Nur der Product Owner hat diese Kontrolle. Das Team hingegen ist die Maschine, die nur innerhalb des Sprints die Benutzergeschichten bestmöglich verarbeiten kann. Jegliche Deadlines, insbesondere solche, die direkt mit der Erwartung eines bestimmten Feature-Sets verbunden sind, lenken das Team ab und führen eher zu Frustration als zu einem “Hey, wir schaffen das” Momentum.

Hier sind einige Ratschläge:

  • Vermeiden Sie es, Fristen zu kommunizieren und implizite Erwartungen zu wecken.
  • Ein vollständiger, nach Prioritäten geordneter und geschätztes Backlog ist eine bessere Möglichkeit, eine Aussage über einen Rollout zu treffen, als eine Powerpoint-Zeitleiste mit hypothetischen Meilensteinen.
  • Betreiben Sie ein realistisches Erwartungsmanagement in alle Richtungen.
  • Sichern Sie sich ab und nehmen Sie das Team mit ins Boot, wenn es um die Planung geht.
  • Beginnen Sie immer mit den Kernfunktionen eines Produkts und lassen Sie die unwichtigen Teile am Ende entstehen.

Das M steht für Minimal

Als Eric Ries darüber schrieb, definierte er MVP wie folgt: “Ein Minimum Viable Product ist die Version eines neuen Produkts, die es einem Team ermöglicht, mit dem geringsten Aufwand ein Maximum an validierten Erkenntnissen über Kunden zu sammeln.” In vielen Unternehmen wird der Begriff hier falsch verwendet, weil viele sich einfach auf eine erste Version eines Produkts beziehen, die nicht einmal dafür gedacht ist, in die Hände von Kunden zu fallen. Viele Unternehmen haben nicht den Mut, sich darauf einzulassen, den Kunden ein sehr reduziertes Produkt anzubieten. Aber hier verschenken Sie die Chance, Informationen über die Nutzung des Produkts und die Sinnhaftigkeit weiterer Features direkt beim Kunden zu sammeln. Vielleicht würde man zu der Erkenntnis kommen, dass viele der geplanten Features gar nicht notwendig sind und stattdessen eine Verbesserung der Kernfunktionen einen viel höheren Kundennutzen bringen.

Le chef de produit agile

Les chefs de produit agiles sont confrontés à des défis particuliers.
Voici quelques conseils pour passer du classique à l’agile.

Avoir une vision

Le changement est toujours le bienvenu dans le développement agile de produits. Si de nouvelles connaissances apparaissent au cours du projet, il est tout à fait judicieux de les intégrer dans le développement du produit, même si cela implique de modifier des parties existantes du produit, voire de jeter des pièces entières. Cela ne signifie pas pour autant qu’il ne faut conduire qu’à vue et ne penser qu’au prochain sprint. Essayez de développer avec l’équipe une vision commune pour le produit prévu. Une vision commune permet à l’équipe de savoir plus clairement dans quelle direction le produit doit aller. Une meilleure compréhension de la solution envisagée permet de faciliter les décisions relatives à la conception du produit.

Prendre des décisions

Prendre des décisions est l’une des tâches les plus épuisantes pour un être humain. Malheureusement, le développement d’un produit implique de nombreuses décisions importantes afin d’obtenir plus tard un produit réussi. Qu’il s’agisse de la hiérarchisation des caractéristiques ou du groupe cible final. Le chef de produit doit prendre les bonnes décisions le plus rapidement possible.

Voici quelques conseils pour prendre de meilleures décisions :

  • Essayez de prendre toutes les décisions sur la base d’une vision du produit préalablement définie. Les décisions doivent également être en accord avec les objectifs de l’entreprise.
  • Utilisez toutes les informations que vous pouvez obtenir, en particulier l’avis de votre équipe. Mais ne prenez pas de décisions dont vous n’êtes pas convaincu. Vous devez aimer votre produit.
  • Si possible, validez les options sur la base de faits et de données plutôt que d’une intuition.
  • S’il n’y a pas d’alternative parfaite évidente pour la décision, ne perdez pas trop de temps sur le processus de décision. Done is better than perfect !

Focus !

Cette partie est en fait destinée à votre chef. Chef de produit n’est pas un travail à temps partiel. Une grande énergie, une disponibilité pour l’équipe, le développement d’histoires d’utilisateurs et la prise de décisions demandent une attention totale.

Essayez d’éloigner de vous toutes les distractions inutiles. Minimiser les préparations inutiles de rapports et de parties prenantes. Veillez plutôt à ce que les parties prenantes participent aux rituels Scrum, comme les démos, afin de se faire une idée de l’état d’avancement du développement, et utilisez les artefacts existants, comme le Sprint Backlog et les Epics, pour communiquer la feuille de route.

Les délais sont pour toi, pas pour l’équipe

Le nouveau produit n’en est même pas encore au stade de la planification et il existe déjà des attentes très fortes au sein de l’entreprise quant au moment où tout doit être terminé. Qu’il s’agisse du début d’un salon où le nouveau produit doit être présenté ou d’un autre événement qui fixe la date de déploiement comme une ligne rigide dans le calendrier avant toute planification. Même si cette attente vous fait très mal aux épaules et que vous voulez porter ce fardeau dans l’équipe. Ce rendez-vous ne concerne que vous, le chef de produit, et non l’équipe. Grâce au processus Scrum, à la priorisation du backlog, au développement incrémental avec un produit “prêt à l’envoi” toutes les deux semaines, le chef de produit a tous les outils en main pour gérer les attentes concernant la portée du produit et, en théorie, être en mesure d’être productif à tout moment, en fonction du degré de maturité du produit. Seul le Product Owner a ce contrôle. L’équipe, en revanche, est la machine qui ne peut traiter au mieux les histoires des utilisateurs que dans le cadre du sprint. Toute date limite, en particulier celles qui sont directement liées à l’attente d’un ensemble de fonctionnalités spécifiques, distrait l’équipe et conduit à la frustration plutôt qu’à un momentum du type “Hé, on va y arriver”.

Voici quelques conseils :

  • Évitez de communiquer des délais et de susciter des attentes implicites.
  • Un backlog complet, classé par priorités et estimé, est une meilleure façon de se prononcer sur un déploiement qu’une chronologie Powerpoint avec des jalons hypothétiques.
  • Adoptez une gestion réaliste des attentes dans toutes les directions.
  • Assurez-vous et faites participer l’équipe lorsqu’il s’agit de planifier.
  • Commencez toujours par les fonctions principales d’un produit et laissez les parties non essentielles se développer à la fin.

Le M signifie Minimal

Lorsqu’Eric Ries a écrit sur le sujet, il a défini le MVP comme suit : “Un Minimum Viable Product est la version d’un nouveau produit qui permet à une équipe de recueillir un maximum d’informations validées sur les clients avec le moins d’efforts possible”. Dans de nombreuses entreprises, le terme est ici mal utilisé, car beaucoup se réfèrent simplement à une première version d’un produit qui n’est même pas destinée à tomber entre les mains des clients. Beaucoup d’entreprises n’ont pas le courage de se lancer et de proposer aux clients un produit très réduit. Mais ici, vous perdez l’occasion de recueillir directement auprès du client des informations sur l’utilisation du produit et sur la pertinence de fonctionnalités supplémentaires. Peut-être arriverait-on à la conclusion que de nombreuses fonctionnalités prévues ne sont pas du tout nécessaires et qu’une amélioration des fonctions de base apporterait plutôt un avantage bien plus important pour le client.