Comment faire cohabiter roadmap et gestion de projet (2)

Dans le précédent article, nous avons évoqué la dimension stratégique de la roadmap et comment elle se positionnait dans la stratégie de l’entreprise.

Nous aborderons ici la liaison entre la roadmap et la gestion de projet.

Comme nous l’avons vu, le Product Manager se situe à la croisée des chemin, Stratégie/Ressources/Produit, Après avoir bien clarifier la vision de l’entreprise, l’avoir traduite en objectifs, il lui faut maintenant générer la dynamique de transformation de la vision vers le produit.

Photo by John Gibbons on Unsplash

Démarrer la gestion projet

Le défi est d’impliquer ses équipes pour traduire les objectifs et indicateurs en fonctionnalités et commencer à les prioriser. Plus il y aura d’idées sur le produit, meilleur se sera pour la suite du développement.

Comment générer ces idées pourrait probablement faire l’objet d’un article complet sur ce sujet. Ce qui est important dans cette phase, c’est de pouvoir rapprocher les idées du besoin client. Et ce n’est pas le plus simple. Tout le monde pense connaître les besoins des clients. 

Tout ce que vous pouvez affirmer sur les besoins des clients ne sont en fait que des suppositions.

Ce que dit Steve Blank, c’est qu’une idée doit être validée. Pour la valider, il faut émettre des hypothèses et déterminer les indicateurs qui permettent de mesurer les résultats. Puis analyser les résultats.

Dans cette phase, tout est bon : data, études, interviews …

Une fois ces idées validées et rapprochées des besoins des clients, on peut alors commencer à construire un plan de développement produit. Les idées sont alors transformées en objectifs mesurables que l’on peut hiérarchiser dans un plan qui conserve le cadre temporel de la roadmap.

Crédits : David WANG

Passer au mode projet

Il est temps maintenant de décomposer le produit en fonctionnalités qui pourront alors être intégrés dans un outil de suivi de projet. Cette décomposition sera fonction de la méthode utilisée : Agile, Cascade ou un mix des deux.

L’approche qui consiste à suivre le parcours client a ma préférence. Elle permet de dérouler les tâches qui composent la démarche du client qui veut satisfaire un besoin. Et elle permet également de commencer à bâtir ce que pourra être un MVP.

Il suffit alors de développer chacune des fonctionnalités en sous-tâches de développement pour votre équipe technique.

Dans le cas d’une méthodologie Agile, la répartition en sprint se fera selon vos ressources.

Gérer l'incertitude

Comme rien ne se passe jamais comme prévu, voici quelques idées :

  • En développement logiciel, ne pas fixer de date mais plutôt un créneau de livraison au cours d’une semaine (ou d’un mois si la fonctionnalité est complexe)
  • Revoir systématiquement la roadmap à chaque livraison d’une fonctionnalité
  • Diffuser largement la roadmap pour que tout le monde soit partie prenante de l’avancement du produit (de ses aléas)
  • Faire des réunions régulières (une fois par mois par exemple) de revue de la roadmap (des points vous ont peut-être échappés)
  • A chaque évolution demandée, faire une analyse avec des critères objectifs et mesurables pour déterminer l’impact sur le produit (par exemple : intérêt pour le client, monétisation, difficulté de réalisation, augmentation du nombre de clients, …)
  • Prioriser systématiquement, ne jamais laisser planer le doute

Conclusion

Le rôle du Product Manager est très variable d’une entreprise à l’autre. Cela peut causer une certaine ambiguïté dans sa position au sein d’une organisation.

Pour moi, un PM est un centre de communication, un prioriseur, un chercheur créatif, un leader qui donne motivation et dynamisme à son équipe, et surtout, la personne qui a la responsabilité du succès du produit sur le marché.

Plus d'articles

Ce site Web utilise des cookies pour vous garantir la meilleure expérience sur notre site Web.