La roadmap d’un produit peut être un véritable casse-tête pour les développeurs et les Product Managers. L’un développe une méthode pour trouver un market fit le plus rapidement possible, tandis que l’autre attend de découvrir le travail qu’il devra fournir lors des prochains sprints. Le Product Manager sait que sa méthode est itérative, le développeur veut éviter d’alourdir sa « code base » en développant des choses qui seront abandonnées.
Quiconque travaille avec des développeurs connait cette tension. Les développeurs ont souvent une opinion très tranchée sur ce qu’il faut faire (ou ne pas faire). Dans beaucoup d’organisations, ils réagissent avec un certain fatalisme : « Cette demande n’a aucun sens, mais si c’est ça qu’ils veulent… de toutes façons dans 6 mois on me demandera de l’enlever ». Et ils ont souvent raison !
En tant que Product Manager, j’ai pu identifier plusieurs facteurs qui peuvent causer ces frictions, mais aussi comment les éviter.
Une chose à garder en tête, c’est que personne n’aime être exécutant d’une simple liste de tâches. Les développeurs, c’est pareil : ils doivent être consultés dès la conception de la roadmap. Pourquoi ? Cela permet de récolter des feedbacks importants avant de mettre en oeuvre la roadmap dans un contexte clair. Vos équipes seront plus autonomes, et vous obtiendrez un meilleur résultat.
Voici les éléments à prendre en compte quand vous impliquez vos équipes dans la réalisation de votre roadmap.
1. Ayez une bonne connaissance des fondamentaux
En tant que Product Manager, votre rôle est de trouver le market fit de votre produit. La meilleure façon d’atteindre cet objectif est de travailler de façon itérative en raisonnant selon la méthode du Principe Premier.
Avec le principe premier, vous commencez avec les fondements de votre produit : les règles primaires qui régissent tout. De là, vous pouvez reconstruire l’ensemble de vos besoins, étape par étape. Au cours de ce processus, la plupart des conclusions auxquelles vous parviendrez seront – pour beaucoup – les mêmes que celles habituellement admises : par exemple il n’est à priori pas nécessaire de remettre en question la méthode agile, même si c’est toujours bien de se souvenir de pourquoi elle existe.
En Product Management, ce qui est la norme dans une startup ne l’est peut-être pas dans une autre. Une méthode appliquée avec un produit ne produira pas les mêmes effets avec une autre. Pourquoi ? Parce que chaque startup est différente, chaque produit est différent, chaque marché est différent.
En travaillant avec vos équipes, il est extrêmement important de garder en tête les fondamentaux, et poser les bonnes questions :
- A quoi ressemble la roadmap de vos hypothèses ?
- Quelles sont les fonctionnalités qui constitueront votre MVP ?
- Pour chaque élément de la roadmap des hypothèses, quelles sont les fonctionnalités à développer ?
- Y a-t-il des choses que nous ne savons pas, des découvertes que nous devons faire pour avancer vers le market fit ? Est-ce que l’équipe de dev peut contribuer ?
2. Préférez la substance aux formules toutes faites
Les formules à la mode tels que « analyse des big data », « Machine learning » ou « les objets connectés (IoT) » peuvent – certes – être utiles pour assurer le « buy-in » du management ou les investisseurs. Par contre ils ne sont ni utiles, ni exploitables par les équipes techniques.
Votre équipe de développement doit savoir exactement:
- Ce qu’elle construit
- Comment cela se rapporte aux produits actuels
- Comment le produit doit être livré
- Qui l’utilisera au final
- Dans quel but
La définition de thèmes de haut niveau est excellente pour structurer la roadmap et le contexte. Assurez-vous de ne pas vous arrêter là et d’avoir de bonnes réponses sur ce qui se cache derrière chaque élément de haut niveau.
3. Définissez le contexte de votre roadmap
Les équipes techniques ont besoin comprendre pourquoi les éléments se trouvent sur une roadmap. Pour cela, la roadmap des hypothèses est très utile : votre équipe entière peut savoir exactement les hypothèses que vous validez et les objectifs derrière chaque feature, aussi petite soit-elle. Les ingénieurs ont besoin de connaître la raison pour laquelle demandez une fonctionnalité, et idéalement, d’être consultés sur la solution à apporter. Les sessions de « backlog grooming », et « sprint planning » sont de bonnes opportunités pour cela.
Pour présentez votre roadmap des hypothèses (et concevoir votre roadmap produit), laissez parler les données, mais racontez aussi une histoire forte du point de vue de vos utilisateurs. Utilisez des personas et parlez de certaines alternatives que vous avez exclues, et pourquoi.
Pour l’ensemble de l’équipe, le « pourquoi » compte autant que le « quoi » pour déterminer le « comment ».
4. Bien réfléchir aux engagements
Si une fonctionnalité ne trouve pas du tout sa place dans la roadmap des hypothèses, et n’a aucune raison d’exister à part faire plaisir à quelqu’un, il faut tirer la sonette d’alarme. Votre équipe de développement va prendre des engagements en vous faisant confiance pour prioriser les éléments de la roadmap. Si vous commencez à accepter des features requests arbitraires, où dont l’explication est très superficielle, votre équipe risque de se désengager du processus itératif auquel vous les avez associés.
Règle empirique: le coût réel d’une feature est de 30% à la réalisation, et 70% de maintenance future. En d’autres termes, certaines « petites choses rapides pour faire plaisir » deviennent souvent très coûteuses à long terme.
5. Établissez des plans réalistes
Une vision, c’est bien, mais c’est encore mieux si tout le monde est convaincu qu’elle peut être réalisée, et pour cela, il faut que le plan soit en phase avec les capacités et la bande passante de l’équipe. Engagez vos équipes sur la construction du plan, sur les timelines, assurez vous que le travail est équilibré entre les différents membres.
Assurez-vous de parler en amont avec l’équipe et jouez avec la roadmap des hypothèses (et surtout, anticipez aussi les cas où les hypothèses sont invalidées). Une fois que vous aurez des réponses et un plan d’action clair, vous ça sera plus facile pour tout le monde de s’engager.
6. Voyez grand, commencez petit
Vous devez être conscient de l’état actuel des compétences d’une équipe par rapport à vos objectifs. Ne vous contentez pas d’écrire des rêves sur une roadmap à un an. Réfléchissez plutôt à la manière de concrétiser vos objectifs de façon réaliste.
La motivation de votre équipe ne tiendra dans le temps que si elle atteint régulièrement ses objectifs. Soyez réalistes sur les objectifs de sprints, et faites monter tout le monde en compétence au fur et à mesure. Le meilleur moyen d’avoir un impact significatif, est de commencer petit, avec des objectifs modestes, en validant les premières hypothèses de votre roadmap des hypothèses.
Chaque petite chose compte, le plus important est la continuité de votre travail, et votre focus permanent sur les fondamentaux de votre produit. Pour cela, planifiez, planifiez, planifiez ! Mais aussi ajustez votre roadmap au fur et à mesure que vos hypothèses sont validées ou invalidées.
7. Etablissez le business case de votre roadmap
Une fois votre market fit trouvé, votre rôle de product manager changera de focus et vous serez dans une démarche d’optimisation du produit. Optimisation des taux de conversion, optimisation de la rentabilité, optimisation de chaque KPI qui a un impact positif sur votre entreprise.
Pendant cette phase, il faudra continuer à impliquer vos équipes dans les hypothèses que vous ferez pour optimiser votre produit. Les équipes techniques s’intéressent aussi aux KPI. Peut-être pas dans la même mesure que la direction, mais votre équipe appréciera de connaître l’impact de son travail. Exploitez le sens des affaires de votre équipe, elle sera une source précieuse d’idées.
8. Roadmap : il n’y a pas de feature banale
Tout le monde veut contribuer à la construction de produits uniques et innovants dont ils peuvent être fiers. Pour cela, il faut que tout le monde ait conscience que chaque feature request est un building block d’un ensemble. Aussi petit ce building block soit-il, il a une raison d’être.
9. Votre roadmap au-delà du MVP et de la V1
Créer un minimum viable product, puis une version 1, c’est une chose. N’oubliez pas tout ce qui se passe après le lancement : vous entrez dans la phase d’optimisation du produit, et de scale up. Vous devrez aussi repositionner votre produit pour qu’il soit attractif aux yeux du mainstream market.
Si la démarche reste la même (en travaillant sur base d’hypothèses), l’optimisation et le scale up de votre produit est un peu plus complexe, car vous avancez avec l’héritage et les fondations que vous avez développées pendant la phase précédente (celle où vous avez trouvé le market fit de votre produit).
Une réflexion rapide sur les défis et les obstacles qui pourraient se présenter après un lancement est toujours utile. Les ingénieurs vous seront reconnaissants de continuer ce travail de réflexion avec eux, et de tenir compte de la réalité.
10. Confrontez les hypothèses à la réalité
En startup, les produits sont développés sur base d’hypothèses. La mission du Product Manager est de confronter ces hypothèses à la réalité, et pivoter si nécessaire. Ayez une roadmap de vos hypothèses ! La gestion de ces pivots avec les équipes de développement est capitale. Bien souvent, les hypothèses seront fausses, ou incomplète, il faudra encaisser les coups, et faire les ajustements. Pour mieux les encaisser, il faut gérer les attentes des équipes, expliquer le contexte de la démarche itérative, et surtout se rappeler que tant que la startup n’aura pas trouvé son market fit, des pivots seront peut-être nécessaires.
11. Soyez ouvert et honnête
Une roadmap est là pour donner une direction générale. Ce n’est pas un plan détaillé d’exécution, tout le monde le sait. Ne la vendez pas comme quelque chose de différent de ce qu’elle est. Si vous n’avez pas encore tous les éléments sur un sujet, ou que des hypothèses doivent encore être validées, mentionnez le !
Partagez ce que vous avez, l’intention, les questions ouvertes et les risques que l’équipe devra aborder. Indiquez les domaines qui nécessitent une expérimentation et une recherche plus poussée. Ce sont des choses pour lesquelles vos équipes pourront certainement contribuer pour trouver des solutions efficacement.
En conclusion
Votre équipe mérite une roadmap qui donne une vue d’ensemble claire, et qui ne néglige pas la réalité. Donnez à votre équipe de la visibilité sur les prochains sprints, en étant transparent sur leur impact (roadmap des hypothèses, KPI, autres). Mais surtout, expliquez toujours le contexte dans lequel vos équipes travaillent. Cela leur apportera d’avantage d’autonomie, tout en réduisant votre charge de travail (dites adieu au micromanagement !). N’oubliez pas qu’en assurant des sprints réguliers, avec une charge de travail réaliste, vous sécurisez la motivation de votre équipe sur le long terme, et c’est le facteur le plus important pour votre succès !