Comme je vous le disais précédemment, le rôle du Product Manager au sein d'une organisation s'apparente à celui d'un chef d'orchestre. Il est donc chargé de veiller à ce que tous les intervenants effectuent au mieux leur part du travail et de les synchroniser pour que l'oeuvre générale soit cohérente et satisfaisante.
Toutefois, de la même manière que tous les musiciens doivent connaître la symphonie qu'ils jouent, les intervenants doivent connaître la stratégie du produit qu'ils contribuent à créer ou à améliorer. Dans le monde du Product Management, on appelle cette stratégie la vision produit.
Formalisez et communiquez une vision
La vision est la pierre angulaire d'une organisation produit. Elle sert à aligner tout le monde dans la même direction, en donnant un objectif clair et compréhensible à tous les intervenants. Généralement, cette vision se traduit par une ou deux phrases permettant de décrire ce que l'on attend du produit.
Voyons comment quelques Product Managers interrogés dans le cadre de ce cours présentent leur vision produit.
La vision produit découle principalement de la stratégie de l'entreprise, et le Product Manager devra donc s'évertuer à comprendre et intégrer cette stratégie, avant de communiquer dessus.
Prenons un exemple !
La vision produit d'une banque en ligne n'est pas :
Mettre à disposition tous les comptes, gérer les virements, traiter les demandes de 3D Secure sur l'application et s'identifier avec le Touch ID.
Mais plutôt quelque chose comme :
Rendre la banque accessible sur n'importe quel appareil, de n'importe où et à n'importe quelle heure.
Si la vision produit peut parfois ressembler à un slogan marketing, c'est essentiellement car l'un de ses objectifs est de stimuler la prise d'initiatives dans les équipes. En effet, si vous confiez une liste de projets à une équipe, elle ne fera que la dérouler, quelles que soient ses idées. À l'inverse, si vous donnez un objectif distant à cette même équipe, elle cherchera les moyens les plus adaptés pour avancer dans cette direction.
Une fois formalisée, la vision produit doit donc être communiquée et comprise par l'ensemble des équipes, pour fluidifier les réflexions autour du produit. De fait, si tout le monde est aligné sur la direction à suivre, les projets n'étant pas en accord avec la vision sont très vite évincés. La vision produit est donc l'un des éléments-clés de la priorisation, qui servira de base pour construire la roadmap et le backlog.
Appuyez-vous sur une Roadmap et un Backlog
La Roadmap et le Backlog sont les deux outils les plus présents dans la vie d'une équipe Produit, car ils permettent tous deux de définir le planning.
S'ils servent à la même chose, pourquoi utiliser les deux ?
S'ils servent effectivement tous deux à définir le planning, ils le font à des granularités différentes. En effet, la roadmap sert à définir l'ordonnancement des projets, tandis que le backlog décrit l'ordonnancement des tâches que l'équipe de développement doit réaliser pour compléter ces projets. Ainsi, comme je l'expliquais dans la première partie de ce cours, la roadmap est la responsabilité du Product Manager, tandis que le backlog est la responsabilité du Product Owner. Toutefois, le Product Manager étant fréquemment en charge du rôle de Product Owner, il peut avoir à gérer ces deux outils au quotidien.
Si l'on reprend notre exemple de la banque en ligne, on pourrait retrouver une roadmap avec les éléments suivants :
Visualisation des comptes ;
Gestion des virements ;
...
Tandis que le backlog contiendra les tâches se référant à ces projets, comme par exemple :
Implémenter le web service de récupération des données d'un compte ;
Créer l'interface de visualisation d'un compte ;
Développer le menu de sélection du compte ;
...
Ces deux outils doivent donc refléter la vision produit, car ils en sont la déclinaison concrète. Les projets choisis doivent faire avancer l'entreprise vers son objectif et les tâches à accomplir doivent elles aussi servir à porter ces projets vers la réussite.
Et du coup, c'est le PM qui décide de ce qu'on met dans la roadmap et le backlog ?
Oui et non. Bien qu'il soit le "manager" du produit, le PM n'est pas le seul décisionnaire des projets qui vont entrer dans la roadmap, car ils vont concerner de nombreuses équipes, qui ont des connaissances qu'il n'a pas toujours.
La Roadmap
Le Product Manager organise donc périodiquement des points sur la roadmap, avec des représentants des différentes parties prenantes, pour décider, avec le plus d'éléments possibles en main, des projets les plus pertinents à réaliser dans un futur proche. Il est fréquent qu'une étude préalable des projets soit réalisée, notamment grâce aux hypothèses que je mentionnais au chapitre précédent, pour pouvoir donner une "note" à chacun d'entre eux, permettant de les comparer efficacement.
Nous avons posé plusieurs questions à des Product Managers sur la manière dont ils conçoivent, partagent et tiennent à jour leurs roadmaps. Je vous propose de découvrir leurs réponses dans la vidéo suivante.
Le Backlog
En ce qui concerne le backlog, un élément supplémentaire doit être pris en compte dans sa composition : les bugs. En effet, le backlog étant le planning opérationnel d'une équipe de développement, c'est à sa granularité que les anomalies de production sont prises en compte. Il faut donc prioriser à la fois des éléments qui vont apporter une valeur nouvelle à l'utilisateur, ainsi que des éléments qui vont corriger des problèmes qui détériorent la valeur actuelle.
J'ai compris les différences de granularité, mais par contre pour la priorisation... Comment savoir si le projet va dans la direction de la stratégie ?
Généralement, en plus de la vision produit, on définit des Key Performance Indicators (KPI), qui sont des statistiques que l'on veut suivre pour déterminer si le produit s'améliore ou non. On essaye donc de mesurer les changements qu'apportera chaque projet par rapport aux KPI, ce qui permettra d'estimer quel projet est le plus bénéfique. Ces indicateurs vous donneront aussi un argument supplémentaire pour pouvoir dire non aux demandes qui ne sont pas en accord avec la vision.
Apprenez à dire "non"
S'il devait exister un proverbe qui résume le principe de la priorisation, il dirait probablement quelque chose comme :
Mieux vaut un collègue vexé qu'un produit raté.
Vous l'aurez compris, le Product Manager et le Génie d'Aladin sont deux personnes très différentes. En effet, même avec toute la bonne volonté du monde, lorsque l'avenir d'un produit est dans la balance, un bon PM risque de vexer quelques collègues, en dépriorisant, voire refusant certaines de leurs idées.
Il existe de nombreuses manières de dire "non", ou de déplacer un projet de la colonne "demain" à la colonne "un jour", et après un ou deux ans de product management, vous en aurez sûrement expérimenté des dizaines. Pour autant, quel que soit votre tact, il n'y a rien de plus persuasif qu'un élément concret pour soutenir votre décision. Ainsi, si votre vision produit a été comprise par tout le monde et que vous avez un indicateur pour appuyer votre décision, l'explication devrait être plutôt simple.
Pour que vous intégriez bien cette notion, imaginez-vous à Koh Lanta.
La stratégie de votre équipe au débarquement est claire : faire du feu et construire un abri pour la nuit, pour être au sec et sécuriser le feu.
Vous êtes le seul à savoir construire un abri, donc vous vous attelez à la tâche. Il est 10 h du matin.
Puis, vers 11 h 30, un coéquipier vient vous demander de l'aider à fabriquer un harpon pour pêcher. Ça a l'air important, alors vous allez l'aider pendant une heure.
Vers 13 h, une de vos coéquipières veut aller chercher du manioc, mais préférerait ne pas s'aventurer dans la forêt toute seule pour le moment. Vous décidez donc de l'accompagner, pour la rassurer. Vous revenez deux heures après, avec deux belles racines.
Vous n'êtes pas vraiment affamés, mais après cette réussite, vous et votre coéquipière décidez de partager le manioc avec le reste de l'équipe. Cela vous prend encore une demi-heure.
La digestion vous endort un peu, mais vous arrivez tout de même à terminer les murs de votre abri dans les deux heures qui suivent. Il ne reste plus que le toit !
Vos coéquipiers en charge du feu ont obtenu des braises et travaillent activement à enflammer des herbes sèches. Vous sentez la satisfaction monter en anticipation, car le toit ne vous prendra qu'une demi-heure à construire.
Et là, il pleut. Des cordes. Sur leur feu. Qui aurait dû être protégé par votre toit.
Si vous aviez priorisé votre tâche, vous auriez terminé en quatre heures et votre stratégie aurait fonctionné. Dommage, la prochaine fois, vous choisirez le mécontentement d'un coéquipier plutôt que l'échec de votre projet.
En bref
La vision permet de communiquer simplement la stratégie ;
avoir un objectif commun stimule la proactivité des équipes ;
la roadmap et le backlog permettent d'orchestrer le travail des équipes ;
savoir dire "non" permet de se concentrer sur les tâches les plus déterminantes pour le produit ;
le mécontentement d'un collègue est largement préférable à l'échec du produit.
Un marché compris, une cible définie, des hypothèses posées et validées, des équipes alignées autour d'une vision commune, on a de quoi faire un produit. Il serait temps de présenter le produit à ses futurs utilisateurs !
