Des roadmaps produits efficaces

De Wiki Agile
Aller à : navigation, rechercher

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à.

Real-roadmap.gif

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.

Example Product Roadmap - Google Sheets.jpg

La section supérieure de notre roadmap décrit notre vision, notre défi et notre état cible, qui reflètent les objectifs décrits dans mon article sur la Stratégie Produit. La roadmap produit doit s'aligner sur ces mêmes objectifs et contribuer à communiquer la tactique pour les atteindre.

Selon cette roadmap, l'équipe X travaille pour atteindre l'objectif global (ou défi) qui consiste à faire en sorte que 99 % des personnes qui créent un compte sur NYS of Health souscrivent une assurance.

Maintenant que nous avons défini notre défi, l'équipe analyse les problèmes des clients qui les empêchent d'atteindre cet objectif. Il s'agit du même processus que nous avons décrit dans le post original sur la Roadmap. Supposons qu'après une recherche utilisateurs, nous découvrons que le plus gros problème des utilisateurs du site Web de NYS of Health est qu'il faut beaucoup de temps pour chercher et trouver le régime d'assurance maladie idéal. C'est un processus qui prête à confusion et qui est incroyablement frustrant. Cela incite les gens à abandonner au lieu de s'inscrire.

L'équipe X décide donc de s'attaquer à ce problème et fixe une condition cible qui lui permettra de savoir quand elle aura atteint un résultat concluant. "Diminuer le temps moyen pour trouver et souscrire une assurance maladie en passant de 3 semaines à 2 jours au deuxième trimestre". Bien que les utilisateurs ne puissent s'inscrire qu'une fois par an à une assurance maladie, de nombreux changements pourraient être mis en œuvre pour faciliter les choses une fois la période d'inscription ouverte.

À partir de là, l'équipe X déterminera les principaux domaines qu'elle souhaite explorer ou sur lesquels elle souhaite travailler au deuxième trimestre pour atteindre la condition cible. Nous appelons cela des thèmes. Par exemple, le thème "Amélioration de la recherche" comprendra tout le travail d'interface utilisateur nécessaire pour simplifier la recherche des différents régimes d'assurance maladie.

Afin de répondre à la question "Pourquoi explorons-nous ce thème ?", nous rédigeons une hypothèse ou un énoncé de problème. Lorsque les produits sont encore dans la phase de découverte, nous sommes encore en train de valider le problème et la solution, donc nous voulons préciser ce que nous savons et ce que nous ne savons pas. Notre hypothèse doit montrer que nous pensons que notre solution résoudra le problème le plus important.

Ainsi, avec notre thème d'amélioration de la recherche, nous en sommes à la phase de livraison et notre hypothèse est la suivante : "Nous pensons qu'en améliorant les choix de filtre pour refléter les principaux facteurs de décision des acheteurs lorsqu'ils choisissent une assurance maladie, nous leur permettrons de restreindre plus facilement leurs choix et de trouver le bon régime d'assurance maladie". Nous avons déjà validé le fait que les gens ont des difficultés à restreindre leurs choix pour trouver la bonne assurance santé, et nous pensons que le fait d'offrir quelques améliorations aux choix de filtres peut résoudre ce problème.

Notre dernier thème, la Communication sur les Subventions, est un exemple de problème qui en est encore au tout début de la phase de découverte. Nous avons constaté que le taux de conversion des personnes qui remplissent les conditions requises pour bénéficier de subventions est très faible, et nous voulons en étudier les raisons. Nous avons quelques idées mais nous ne les avons pas encore validées. Nous devons donc communiquer clairement notre hypothèse, en soulignant ce que nous savons ("les personnes qui obtiendraient une assurance santé presque gratuitement ont un taux de conversion très faible") et ce que nous ne savons pas ("nous ne sommes pas sûrs que les gens partent avant de savoir s'ils ont droit ou non à des subventions, ou s'ils ne comprennent tout simplement pas notre explication des subventions").

Après la rubrique "Hypothèse" vient la rubrique "Résultats" - la partie la plus importante de notre roadmap. Ici, nous indiquons ce que nous espérons obtenir en résolvant ce problème ou en prouvant cette hypothèse. Chaque résultat doit se rapporter d'une manière ou d'une autre à la condition cible. Tout notre travail va nous aider à atteindre la condition cible, donc la roadmap serait plutôt ennuyeuse si chaque résultat pour chaque thème n'était qu'une répétition de cet objectif. Réfléchissez plutôt à la manière dont chacun de ces changements ou améliorations constitue une avancée vers votre objectif.

Par exemple, dans le cas des améliorations de la recherche, nous pouvons savoir si nous facilitons la recherche en mesurant les composantes qualitatives de la frustration et les composantes quantitatives de la réduction du temps d'identification d'une option. Vous devez vous assurer que vous vous concentrez sur une bonne combinaison de résultats commerciaux et de résultats pour l'utilisateur dans ces rubriques, et les rendre mesurables.

Les deux dernières rubriques concernent le statut et la priorité. Le statut doit indiquer où vous vous trouvez dans la phase de découverte ou de réalisation. Si vous êtes dans la phase de découverte, vous livrez pour apprendre, donc vous vous concentrez sur l'expérimentation plutôt que sur la livraison de fonctionnalités. Dans la phase de réalisation, vous livrerez des fonctionnalités et des solutions utiles aux utilisateurs. Définissez avec votre équipe ce que cela signifie au sein de votre entreprise, puis partagez ces définitions avec le reste de l'entreprise afin de parvenir à une compréhension partagée.

Notez que notre roadmap ne contient pas de détails sur la façon dont nous prévoyons de résoudre ces problèmes. Cela s'explique par le fait que nous sommes toujours en train d'expérimenter des options - nous n'avons pas établi de plan pour mettre en œuvre un ensemble de fonctionnalités ou de composants de solution.

L'exemple ci-dessus ne représente que la roadmap d'une équipe. Il pourrait y avoir beaucoup d'autres équipes travaillant sur ce même défi, mais elles auraient toutes des conditions cibles différentes. Ces roadmaps pourraient ensuite être combinées en une roadmap de portefeuille qui pourrait être communiquée à différents niveaux de l'entreprise, comme suit :

Good-Roadmap-FDS-portfolio.007.jpeg

Il est important de se rappeler qu'une roadmap est avant tout un outil de communication. Elle est destinée à aligner les équipes sur des horizons temporels et des objectifs. La direction doit fixer des objectifs et une vision sur une période allant de 6 mois à quelques années, tandis que les équipes doivent envisager une période plus courte, de quelques trimestres à 6 mois. Il devrait y avoir un document stratégique d'accompagnement qui explique comment ces objectifs aident l'entreprise à atteindre sa vision, mais la roadmap elle-même ne sert pas à cela.

Les roadmaps sont des documents vivants. Si vous ne validez pas un thème, mettez-le à jour. Si vous avez modifié un objectif, mettez-le à jour. Il n'y a aucune raison que vous deviez vous battre pour contourner une roadmap qui ne vous convient pas. Lorsque vous communiquez avec vos clients, concentrez-vous sur la façon dont vous allez résoudre leurs problèmes, et non sur la façon dont vous allez leur fournir des fonctionnalités. Vos clients se soucient avant tout de la valeur qu'ils reçoivent.