Pourquoi la priorisation prime
Une petite équipe lance peut-être deux ou trois expériences par semaine. Les équipes en phase précoce démarrent souvent là, et seules les équipes à haute vélocité atteignent dix à vingt par semaine — et c'est déjà beaucoup quand le trafic est mince. Avec si peu de créneaux, le vrai coût d'un test médiocre n'est pas le test lui-même ; c'est l'idée plus forte que vous avez écartée pour le lancer. Une feuille de route existe pour que chaque créneau aille à l'idée à plus forte valeur attendue, pas à la voix la plus forte en réunion. Détenir cette file classée représente une grande partie de ce que fait un growth PM.
Construire le backlog à partir du funnel et du moment aha
Ne partez pas d'une liste de souhaits. Partez des fuites du funnel. Parcourez chaque étape — visite, inscription, activation, rétention, revenu — et notez les plus grosses pertes ; chacune est une hypothèse testable. Pondérez fortement les étapes proches de votre moment aha d'activation, car un utilisateur qui n'active jamais reste rarement. Traitez tout aha que vous nommez comme une corrélation à valider, pas une cause prouvée : un signal d'activation prédit la rétention, il ne prouve pas que vous l'avez causée. Chaque fuite devient une ligne du backlog — l'hypothèse, l'indicateur qu'elle doit bouger, et une estimation grossière de l'ampleur.
Noter les idées avec ICE
ICE, popularisé par Sean Ellis, note chaque idée sur trois axes de 1 à 10 : l'Impact, combien elle pourrait bouger la métrique ; la Confiance, à quel point vous croyez qu'elle marchera ; et la Facilité, le peu d'effort qu'elle demande. Multipliez les trois, triez par ordre décroissant, et travaillez de haut en bas. C'est rapide parce que ce sont trois estimations honnêtes. Cette rapidité est aussi le piège : le score est une estimation, pas un fait. Lisez un 512 et un 480 comme à peu près égaux, pas comme un jugement. Le nombre ordonne la liste ; il ne décide pas à votre place.
Quand la portée varie, passez à RICE
ICE flanche quand deux idées diffèrent énormément par le nombre d'utilisateurs touchés. RICE, d'Intercom, corrige cela en ajoutant la portée (Reach) et en divisant par l'effort : (Portée x Impact x Confiance) / Effort. Une infobulle vue par chaque visiteur et un réglage enfoui dans une page de paramètres sont notés sur le même pied. Le compromis échange la vitesse contre une estimation de portée qu'il faut sourcer. Le même avertissement tient : multiplier quatre nombres inventés peut produire une fausse précision, alors gardez les entrées grossières et révisez-les à mesure que vous apprenez.
| Facteur | ICE | RICE |
|---|---|---|
| Formule | Impact x Confiance x Facilité | (Portée x Impact x Confiance) / Effort |
| Vitesse | Rapide — trois estimations de 1 à 10 | Plus lent — exige un chiffre de portée |
| Idéal pour | Trier vite un grand backlog | Idées dont la portée diffère beaucoup |
| Piège principal | La facilité masque l'effort réel | Fausse précision à partir d'entrées molles |
Passer en revue à cadence fixe, et couper les perdants
Fixez un rythme régulier — une revue hebdomadaire ou bimensuelle où vous lisez les résultats, promouvez les gagnants et retirez le reste. Couper dans les délais est la discipline qui garde la file en mouvement ; un test laissé en cours est un créneau resté occupé. Soyez honnête : la plupart des tests reviennent à plat, et à faible trafic beaucoup sont sous-dimensionnés avant même de commencer — souvent le bon choix n'est pas de faire un test A/B, mais de livrer et de surveiller, comme l'explique le test à faible trafic. Quand vous mesurez, une lecture propre exige d'ordinaire un groupe témoin, qu'une plateforme comme customer.io ou une stack d'engagement auto-hébergée peut mettre de côté pour vous.