Des roadmaps produits efficaces

Auteure : Melissa Perri
Source : Effective Product Roadmaps
Date : 15/02/2017

---

Traducteur : Fabrice Aimetti
Date : 23/11/2022

---

Traduction :

Les roadmaps produits, en général, prêtent à confusion. La vérité ? Même les chefs produits les plus expérimentés ne les maîtrisent pas encore parfaitement. Il y a trois ans, j'ai écrit un article de blog sur le thème "Repenser la roadmap produit", dans lequel je préconisais de se concentrer sur la résolution des problèmes des clients plutôt que de dresser une liste de fonctionnalités avec des échéances. J'ai reçu de nombreux commentaires sur cet article, souvent élogieux, mais aussi des critiques. Le commentaire le plus important pour moi a été le suivant : "C'est très bien pour les nouveaux produits en phase de découverte, mais qu'en est-il de la prise en compte des produits que nous avons déjà lancés et que nous devons construire ?"

Depuis, j'ai travaillé avec des clients pour trouver ce qui fonctionne le mieux dans des situations réelles. Je souhaite partager avec vous le cadre de travail que j'ai trouvé, qui permet de trouver un équilibre entre la découverte et la livraison et qui nous évite d'avoir à dresser une liste interminable de fonctionnalités. Mais tout d'abord, parlons des roadmaps en général, et de la façon dont elles nous ont mis sur la mauvaise voie au départ.

Rappelez-vous, avant Google Maps, ce qu'était une vraie carte routière - ces choses avec des noms de villes minuscules et des milliers de lignes sinueuses. Celles qui faisaient que vous ne pouviez jamais conduire seul parce que vous aviez besoin d'un copilote, de quelqu'un pour manipuler cette carte immense et vous dicter comment aller du point A au point B. Oui, CES choses-là.

C'est de là que vient le terme "Roadmap". Lorsqu'on utilise une carte routière, on sait toujours où l'on est et où l'on veut aller, et on a le choix entre plusieurs itinéraires. Certains itinéraires étaient plus courts, d'autres plus longs mais plus touristiques. En fin de compte, c'était à vous de choisir votre chemin optimal. Les roadmaps produits devraient fonctionner exactement comme leur homonyme, mais leur objectif a été perdu quelque part en cours de route. Aujourd'hui, les roadmaps fonctionnent davantage comme des diagrammes de Gantt.

Les diagrammes de Gantt sont un outil de gestion de projet utilisé pour assurer le suivi des planifications et des échéances. Si les diagrammes de Gantt conviennent parfaitement aux grands projets de fabrication, ils ne sont pas adaptés à la plupart des logiciels en raison de l'incertitude qui entoure le développement.

Lorsque nous décidons pour la première fois du produit logiciel à explorer, nous ne savons pas ce que veulent nos utilisateurs, et nous ne savons donc pas exactement à quoi ressemblera le produit fini. Il est donc pratiquement impossible d'estimer le temps que prendra la construction du produit. Pourtant, nous utilisons toujours ce modèle de diagramme de Gantt pour planifier notre travail, ce qui nous contraint à livrer des solutions à certaines dates. Les équipes sont frustrées par l'absence de flexibilité apparente dans ces planifications, et le management s'énerve lorsque les équipes ne livrent pas à temps. Le résultat est un tas de releases de fonctionnalités qui ne font pas de différence pour nos utilisateurs.

Au lieu de cela, nous avons besoin d'un modèle qui nous aide à gérer l'incertitude et nous donne la flexibilité nécessaire pour la découverte et la livraison. Pour ce faire, nous nous concentrons sur les roadmaps produits qui se composent de résultats (outcomes), d'un thème et d'hypothèses, et nous écartons toute solution ou fonctionnalité non validée.

Examinons un exemple que j'ai créé à partir d'une roadmap produit réalisée pour une équipe. J'utilise le site web du New York Health Exchange comme exemple de produit car je peux facilement identifier les choses qui doivent être corrigées - à savoir, beaucoup de choses. Je n'ai jamais travaillé avec eux et je ne prétends pas savoir comment ils fonctionnent en interne, mais je suis un client du site Web. C'est ainsi que j'aborderais l'amélioration du produit si je travaillais avec eux.