Il y a 20 ans, j'étais, comme beaucoup, un passionné de Lego.
Mais le moment qui m'a toujours le plus enthousiasmé, c'est celui où je pouvais présenter à mon frère, mes parents, ou n'importe qui, ma dernière création.
Avec le recul, il y a 20 ans, j'étais une jeune pousse de Product Manager. Car le moment le plus enthousiasmant dans la vie d'un PM, c'est celui où il offre enfin à ses utilisateurs la possibilité de tester son produit.
Hmmm, mais c'est un peu facile avec la famille. Comment on montre sa dernière création à des utilisateurs finaux ?
Eh bien justement, on va en parler tout de suite.
Choisissez la bonne méthode de mise en production pour faire les présentations produit - utilisateurs
Présenter un produit à de vrais utilisateurs est le test final d'une phase de création de produit ou de fonctionnalité. En effet, quels que soient les tests que vous avez effectués au préalable, ce n'est qu'une fois qu'il sera utilisé dans des conditions réelles que vous saurez réellement si vous avez relevé le challenge ou non.
De ce fait, il y a de nombreuses manières de mettre un produit en production. Pour choisir entre elles, le Product Manager doit prendre plusieurs éléments en compte :
La criticité : la fonctionnalité a-t-elle beaucoup d'impact sur l'utilisateur ?
La proximité des utilisateurs : est-il facile de solliciter les utilisateurs finaux ?
Le coût du changement : est-il possible de maintenir la version précédente et la nouvelle version en parallèle ?
La testabilité : la fonctionnalité est-elle facilement testable sans utilisateurs finaux ?
Le volume d'utilisation : la fonctionnalité va-t-elle être confrontée à une utilisation massive à sa sortie?
Selon ces critères, il faudra choisir parmi quatre principales options de mises en production :
la version bêta interne
la version bêta externe
la mise en production progressive
la mise en production totale
La version bêta
Si vous avez l'habitude de jouer aux jeux vidéo, ou si vous utilisez les applications dédiées de certains services en ligne, tels que Deezer ou Netflix, vous êtes probablement déjà familier avec cette notion.
La version bêta d'un produit, ou d'une fonctionnalité, est une version qui est mise à disposition d'un nombre restreint d'utilisateurs finaux, en précisant bien qu'elle peut contenir quelques dysfonctionnements.
C'est d'ailleurs une des raisons d'être de cette option : mettre le produit en face de ses utilisateurs, et compter sur le volume d'utilisation pour détecter les derniers problèmes. Selon la proximité des utilisateurs et le volume nécessaire, on distingue deux types d'ouverture de version bêta : interne et externe.
1. La Beta interne
La Beta interne consiste à mettre en production une fonctionnalité ou un produit, en ne l'ouvrant qu'à des utilisateurs qui font partie de l'entreprise.
Criticité : la Beta interne est utile pour des fonctionnalités assez critiques, qui peuvent avoir un impact très négatif sur la valeur apportée par le produit. Les fonctionnalités qui changent la manière dont un des usages fréquents fonctionne ou qui sollicitent l'utilisateur. Par exemple : de nouvelles notifications ou une section d'ajout de commentaires.
Proximité des utilisateurs : évidemment, il faut que le produit soit utilisable en conditions réelles par des utilisateurs de l'entreprise. On peut donc assez facilement faire une beta interne chez Netflix et beaucoup moins chez la NASA.
Coût du changement : le coût du changement doit être assez faible, pour pouvoir se permettre de maintenir une version actuelle (si elle existe) et une version parallèle pour une certaine population. Cela ne se prête donc généralement pas aux changements très structurants, comme par exemple le changement du moteur de distribution des livreurs chez Chronopost.
Testabilité : il faut pouvoir tester la fonctionnalité ou le produit en un temps assez restreint, pour ne pas s'éterniser dans des mois de beta interne, forçant la maintenance de deux versions parallèles.
Volume d'utilisation : la fonctionnalité ne doit pas nécessiter un volume colossal pour être testé. En effet, selon la taille de l'entreprise, cette beta pour ne sera ouverte qu'à quelques dizaines ou quelques centaines d'utilisateurs. Les fonctionnalités nécessitant une forte utilisation, comme celles reposant sur le machine learning, en seront donc exclues.
2. La Beta externe
La Beta externe fonctionne comme la Beta interne, à ceci près que ce sont des utilisateurs externes à qui l'on ouvre la fonctionnalité ou le produit.
Criticité: la Beta externe est utile pour tester des fonctionnalités importantes et qui présentent une multitude de cas possibles. Par exemple, la possibilité de partager du contenu sur différents canaux.
Proximité des utilisateurs : cette option n'est utilisable qu'avec des utilisateurs très proches et fidèles. Les utilisateurs sont souvent choisis en fonction de leurs typologies, pour être représentatifs du marché.
Coût du changement : comme pour la Beta interne, le coût du changement doit être assez faible.
Testabilité : comme pour la Beta interne, il faut pouvoir tester la fonctionnalité assez rapidement.
Volume d'utilisation : la principale différence avec la Beta interne se trouve sur le volume, car la Beta externe va permettre de toucher un plus grand nombre d'utilisateurs beta, augmentant la probabilité de tester les cas à la marge.
3. La mise en production progressive
La mise en production progressive, très fréquemment appelée Canary Release, consiste à ouvrir la fonctionnalité en production à un pourcentage d'utilisateurs non choisis, puis d'augmenter le pourcentage progressivement, à mesure que les bugs sont corrigés et que l'utilisation est satisfaisante.
Criticité : la Canary Release est utilisée pour des fonctionnalités non critiques, mais qu'un dysfonctionnement peut rendre totalement inutilisables. Elle est aussi très pratique dans un contexte B2B pour limiter le risque d'entacher la réputation de l'entreprise auprès de clients qui payent très cher une licence ou un abonnement. La refonte du système de paiement de votre banque es très critique, alors que la fonctionnalité de notation de Netflix est peu critique par exemple ;
Proximité des utilisateurs : cette option ne nécessite pas de proximité particulière avec ses utilisateurs car le bug sera soit totalement intolérable, auquel cas il remontera immédiatement via n'importe quel utilisateur, soit peu gênant, auquel cas il n'engendra pas d'insatisfaction majeure des utilisateurs.
Coût du changement : comme pour la bêta interne, le coût du changement doit être relativement faible, mais peut être plus élevé que pour une bêta, car cette stratégie n'est pas vouée à durer plus de quelques jours ;
Testabilité : la Canary Release est utile pour des fonctionnalités qui, malgré les phases de tests, restent difficiles à tester en conditions réelles sans les ouvrir aux utilisateurs finaux, comme par exemple, l'utilisation d'un nouveau type de paiement ;
Volume d'utilisation : cette option se prête particulièrement à des fonctionnalités qui ne nécessitent pas un gros volume d'utilisation, puisque l'objectif est de commencer sur un panel très restreint d'utilisateurs.
4. La mise en production totale
La mise en production totale consiste, comme son nom l'indique, à ouvrir la fonctionnalité à tous les utilisateurs en même temps.
Criticité : cette option s'applique pour deux types de fonctionnalités totalement opposés : les fonctionnalités très structurantes, où le moindre bug est très important, et les fonctionnalités avec très peu d'impact, qui ne seront qu'une légère gêne en cas de dysfonctionnement ;
Proximité des utilisateurs : cette option ne nécessite pas de proximité avec ses utilisateurs, car le bug n'est pas tolérable de toute façon ;
Coût du changement : le coût du changement doit être soit minuscule, soit énorme, et l'idée est de ne pas maintenir deux versions en parallèle ;
Testabilité : la mise en production totale doit se faire sur des fonctionnalités que l'on peut tester en intégralité. Cependant, cette option est aussi la seule possible pour les fonctionnalités qui nécessitent une énorme quantité de données de production pour fonctionner, comme on peut retrouver en Data Science par exemple ;
Volume d'utilisation : le volume d'utilisation n'est déterminant que dans le cas où la fonctionnalité a besoin d'énormément de données pour fonctionner.
C'est donc en analysant ces critères que vous déterminerez la bonne méthode de mise en production pour votre produit.
Communiquez sur une mise en production au bon moment et de la bonne manière
Si la stratégie de mise en production joue un rôle très important dans la perception qu'ont les utilisateurs du produit ou de la fonctionnalité, elle ne fait pas tout. En effet, avant que les utilisateurs puissent avoir le moindre avis sur le produit ou la fonctionnalité, il faut qu'ils en aient connaissance.
La communication associée à votre mise en production va donc servir de véritable propulseur à votre produit ou fonctionnalité. Avant toute mise en production, le Product Manager doit donc veiller à :
mettre toutes les parties prenantes au courant du plan de mise en production, en organisant par exemple un kick off, une démo et en partageant les plannings ;
synchroniser les communications externes, comme les campagnes marketing ou les notifications in-app, et l'ouverture aux clients ;
communiquer largement au sein de l'entreprise, à force de messages groupés (Slack, mail, etc…) voire de démonstration générale, car les employés sont les premiers ambassadeurs du produit.
En bref
Les quatre principales stratégies de mise en production sont la bêta interne, la bêta externe, la canary release et la mise en production totale ;
Le choix de la stratégie doit prendre en compte la criticité, la proximité des utilisateurs, le coût du changement, la testabilité et le volume d'utilisation ;
La communication est le véritable propulseur de la mise en production.
Le produit a beau être dans les mains des utilisateurs, le travail n'est pas fini, car il va falloir faire en sorte qu'ils ne s'en lassent pas. C'est ce dont nous allons parler au prochain chapitre.
