La plupart des roadmaps sont des calendriers de livraison déguisés : trois colonnes de fonctionnalités avec des dates, qui deviennent fausses au bout de trois semaines. Une roadmap utile répond à une autre question — quel problème décide-t-on d'attaquer, et sur quelle conviction.
Les cinq colonnes
- 01
Le problème
Formulé du point de vue de l'utilisateur, jamais de la solution. « Le comptable ressaisit trois fois la même facture » et non « développer un import automatique ». Si vous ne savez pas l'écrire ainsi, vous n'avez pas encore compris le problème.
- 02
L'hypothèse
Ce que vous croyez vrai et qui justifie d'y consacrer un trimestre. Elle doit pouvoir être fausse. « Nous pensons que la ressaisie coûte deux heures par semaine et que la supprimer réduira les erreurs de facturation. »
- 03
La métrique de succès
Un seul chiffre, avec sa valeur de départ et sa cible. Sans valeur de départ, vous ne saurez jamais si vous avez réussi.
- 04
La contre-métrique
Ce que vous surveillez pour savoir que vous êtes en train de casser autre chose. Un import automatique peut supprimer la ressaisie et multiplier les doublons.
- 05
Ce qu'on ne fera pas
La colonne la plus importante, et la seule que personne ne remplit. Listez explicitement les demandes écartées ce trimestre, avec la raison. C'est ce document qu'on ressort quand la question revient six semaines plus tard.
Le format
| Problème | Hypothèse | Métrique | Contre-métrique | Écarté |
|---|---|---|---|---|
| Ce que l'utilisateur n'arrive pas à faire | Ce que nous croyons vrai | De X à Y | Ce qu'on surveille | Ce qu'on repousse, et pourquoi |
La règle de relecture
Une décision produit sans alternative rejetée n'est pas une décision, c'est une préférence.
En fin de trimestre, reprenez la trame et confrontez chaque hypothèse au résultat. Celles qui se sont révélées fausses valent plus cher que les autres : elles vous disent où votre compréhension du produit était erronée, et c'est la seule information qui améliore les arbitrages suivants.