Pierre est Product Owner. Il sort de 3 jours de formation dédiés aux méthodes agiles. Il a obtenu haut la main la certification PS-PO après avoir répété inlassablement les tests à blanc sur scrum.org. Il a hâte de remplir son backlog produit et d'alimenter l'équipe de dev en User Story. Ses cartes Dixit reposent fièrement sur son bureau, à côté de son mug à café, prêtes pour les prochaines rétrospectives. Fini le cycle en V, la hype c'est l'agilité. Il est prêt.
Syndrome de la feuille blanche
Il est là, sur son bureau. Le cahier des charges du projet, pour le compte d'un gros client dans le domaine bancaire. Une équipe tech a été montée et le chef de projet tiendra le rôle du Scrum Master. Le client a donné son feu vert, le projet peut démarrer et Pierre va endosser son rôle de PO pour la 1ère fois.
En bon PO, il ne perd pas de temps et le 1er sprint planning est programmé dès lundi prochain, ce qui lui laisse une semaine pour remplir son product backlog. Une marge confortable. Prêt à démarrer, il ouvre un nouveau document Word pour rédiger ses User Stories... Et là c'est le drame. Syndrome de la feuille blanche, il ne sait absolument pas par ou démarrer. Comment amorcer un backlog produit ? Jamais ce point n'a été abordé en formation. On lui a bien dit comment prioriser, mais comment les US arrivent elle dans le backlog ?
Les Stakeholders ont la réponse à tout
Après un court moment de panique, Pierre a la solution : Les Stakeholders ! Il faut aller les rencontrer! C'est grâce à eux qu'il va comprendre le besoin et prioriser son backlog. Sans attendre, il programme une réunion avec les différentes parties prenantes : Métiers, commerciaux, marketing, techniques. Il n'oublie pas ses posts-it, son tableau blanc. C'est parti.
Après 4h de réunion et d'échanges intense, Pierre est satisfait. Il a un mur entier de post-it face à lui. Il va pour voir construire son backlog produit et organiser ses 1er sprints selon la priorité qui lui a été donné.
Après la livraison, la désillusion
Après 4 sprints de dev intense, le produit est prêt à être déployé en production. Le budget initial a été dépassé de plus de 20%, mais toutes les features demandées par le client ont été livrées. Pierre est satisfait, il a livré le produit demandé. C'est un succès.
Puis les semaine passent. Les 1ers retours des utilisateurs ne sont pas très bon. Ils sont perdus dans l'outil, ne comprennent pas comment l'utiliser. Certains ont même ressorti leurs feuille Excel, "pour aller plus vite". Le client n'est pas très content, il a investi 100k dans un produit censé simplifier la tâches de ses collaborateurs. Et c'est tout l'inverse qui se produit.
Pierre ne comprend pas, il a pourtant fait exactement ce qu'on lui a appris en formation. Il a développé le produit par itérations, fait des sprints review, rétro, il a recueilli le feedback du client...Il est en plein doute. Sa collègue avait peut être raison : L'agilité c'est juste une méthode à la mode.
L'histoire de Pierre, c'est aussi celle de beaucoup d'autres PO. Des produits "usine à gaz", qui finalement ne répondent pas ou trop peu aux besoins réels des utilisateurs, il en existe des centaines qui sont livrés chaque jour en France. Sans compter tout ceux qui ne vont pas au bout et ne sont jamais déployés en prod. Alors qu'est ce qui n'a pas marché ? Pourquoi Pierre n'a pas livré le bon produit ?
Delivery vs Discovery
Le problème n'est pas l'agilité. Le problème c'est de croire que l'agilité est LA solution. En faisant cela, on se cantonne à un agile "by the book" et on se concentre uniquement sur une seule chose : le Delivery. Il faut alimenter les devs en story et ne surtout pas perdre de temps pour respecter le budget prévu. On s'intéresse au comment, mais on en oublie une chose essentielle : Pour qui ?
Cette phase essentielle de compréhension de l'utilisateur dans le cycle de vie d'un produit à un nom : La Discovery. Cette étape cruciale s'inspire des méthodes UX et plus particulièrement de la recherche utilisateur : Personas, Experience Map, User Journey, interview, sondage, etc... Autant d'outils indispensables pour connaitre les utilisateurs, comprendre leurs activités et commencer à identifier les points de blocage.
Et ce n'est pas tout. Depuis de nombreuses années, le design d'interface a pris une importance énorme dans le succès des applications web & mobile. Il faut un parcours utilisateur qui soit simple, fluide, avec un OnBoarding travaillé pour embarquer immédiatement l'utilisateur. Il doit prendre du plaisir à utiliser l'application et se sentir productif.
Le rôle du PO s'élargit. Il n'est plus uniquement responsable du Delivery. Il devient le véritable manager de son produit. Il devient Product Manager.
Product Manager, un rôle stratégique
Le Product Manager (ou PM) est un touche à tout : En plus du Delivery, il doit avoir des connaissances en UX, en organisation produit, comprendre la tech, mais aussi s'intéresser au marketing pour gérer la croissance de son produit.
Son rôle et ses différents domaines de spécialisation sont très bien décrit dans l'excellent article de Thiga sur les carrières en Produit. Ils décrivent ainsi le rôle de PO (Et donc le Delivery) comme le coeur des compétences d'un PM :
S'ajoute ensuite 9 domaines de compétences qu'un PM doit développer pour atteindre le niveau 1 :
Un PM a ainsi toutes les cartes en main pour réaliser le "bon "produit. Et peu importe votre organisation. Peu importe la taille de votre projet. Peu importe si vous travaillez sur un projet B2C ou B2B, en startup ou dans une ESN. Je pense qu'aujourd'hui, pour en finir avec ces produits à la qualité et à l'intérêt discutable, il est temps pour les PO de prendre un peu de hauteur et de tendre vers ce métier de PM. Les utilisateurs n'en seront que plus heureux.