Maintenant que vous avez compris les besoins du marché et que vous avez décidé de la population à laquelle vous comptez adresser votre produit, vous allez devoir réfléchir à la manière dont vous allez répondre à ses attentes.
Pour ce faire, vous allez appliquer une stratégie similaire à celle que vous utilisez naturellement lorsque vous cuisinez pour quelqu'un ou que vous faites un cadeau : vous allez faire des hypothèses et essayer de les valider, le plus tôt possible.
Émettez les bonnes hypothèses
Au cours de la création d'un produit, ou d'une fonctionnalité, le Product Manager fait de nombreuses hypothèses, améliorant progressivement leur précision.
Les premières hypothèses interviennent avant même l'analyse du marché : en effet, lorsque l'on décide de s'intéresser à un marché particulier, on émet toutes sortes d'hypothèses.
il y a des besoins non assouvis sur le marché ;
la concurrence sur ce marché ne l'a pas saturé ;
ce marché a de l'avenir ; etc.
C'est grâce à cette analyse que le PM valide ces premières hypothèses. Si l'une d'elles n'est pas validée, il changera probablement son fusil d'épaule pour se tourner vers un autre marché, plus prometteur.
Une fois les hypothèses de lancement validées, de nombreuses autres vont être nécessaires pour décider de ce que qui doit être fait. Le Product Manager commence généralement par des hypothèses sur l'idée générale de sa réponse au besoin.
Prenons un exemple. Rappelez-vous de cette époque où aller sur un site de rencontres, même gratuit comme AdopteUnMec, était vu comme une activité réservée aux désespérés. La raison principale de cette perception venait essentiellement du fait que chercher un(e) partenaire sur ces sites était très long. Il fallait parcourir des pages et des pages de profils, donnant l'impression que seules les personnes n'ayant plus que cette option y investiraient autant de temps.
Et puis, en 2009, une entreprise américaine émet l'hypothèse que, si un système proposait exactement le même service, mais sans avoir à y passer beaucoup de temps, cette perception volerait en éclats. Et elle avait raison.
C'est ainsi que le produit Grindr, focalisé sur les rencontres homosexuelles, a vu le jour. Il a ensuite très fortement inspiré un produit dont nous connaissons tous des utilisateurs : Tinder.
Faire la bonne hypothèse va donc conditionner la réussite du produit et la mauvaise hypothèse peut engendrer son échec ! C'est un élément très important de la vie d'un Product Manager. Parfois, on se trompe, on développe son produit, on l'ouvre au marché et... c'est un échec.
Mais on ne voit pas tellement de produits ratés sur le marché... si ?
En fait, si. Et il y a en a énormément ! La seule raison pour laquelle on ne les croise pas, c'est que les Product Managers qui sont derrière prennent alors une décision difficile, mais pertinente : celle de les enterrer.
Pour illustrer ce propos, voici une petite compilation de produits ratés par les plus grandes entreprises d'aujourd'hui.
Apple : Macintosh TV
L'hypothèse initiale était que les utilisateurs voudraient utiliser le même appareil pour regarder la TV et utiliser l'ordinateur. Sauf que les utilisateurs voulaient le faire en même temps, pas séparément ;Microsoft : la Zune
Devant le succès incontesté de l'iPod, Microsoft a émit l'hypothèse qu'un baladeur avec un disque dur et un écosystème musical était souhaité par les utilisateurs. C'était presque vrai, mais la force du produit d'Apple venait en grande partie de son design, qui avait totalement été laissé pour compte sur la Zune ;Google : Google Wave
Les emails, la discussion instantanée et la documentation, Google sait faire. Le réseau social, beaucoup moins. Mais si on mettait tout ça dans un même produit, au même endroit, les utilisateurs y passeraient tout leur temps. En tout cas, c'était l'hypothèse de Google en 2009. Le produit était tellement complexe qu'il en était incompréhensible pour la majorité des utilisateurs.
Espérons que vous n'aurez jamais à enterrer un produit, mais c'est une éventualité qu'il ne faut pas oublier !
À mesure que l'idée va s'éclaircir et que la confiance dans les hypothèses générales va grandir, le Product Manager va émettre des hypothèses plus spécifiques, servant à valider un aspect particulier. Cela pourra, par exemple, aider à estimer le gain ou l'impact de la fonctionnalité sur un KPI.
Validez les hypothèses
Une fois les hypothèses posées, le Product Manager doit les valider, pour minimiser le risque d'échec du produit ou de la fonctionnalité. Il y a de nombreuses manières de valider vos hypothèses, mais toutes ne sont pas applicables selon le contexte.
Tests utilisateurs en amont de la release
La première possibilité, qui s'applique assez facilement sur les produits Business to Consumer (B2C), est le test utilisateur. Elle consiste à faire tester, de manière bénévole ou légèrement rémunérée, des utilisateurs sur des scénarios d'utilisation prédéfinis.
Tout en utilisant le produit, le testeur doit donner ses impressions, ses frustrations et les raisons pour lesquelles il effectue chaque action. Cela permet de valider que le produit répond aux attentes, mais aussi qu'il est articulé de manière claire et compréhensible par un utilisateur non averti. Le test utilisateur peut toutefois s'avérer très difficile à mettre en oeuvre sur des produits Business to Business (B2B), car les entreprises ne sont jamais très emballées à l'idée d'envoyer un de leurs employés, sur une journée de travail, tester le produit d'une autre entreprise.
Bien que cette possibilité permette de tester le produit en conditions d'utilisation réelles, elle a ses limites : en effet, le nombre de testeurs représentatif de la population est souvent difficile à atteindre, et les profils de ceux-ci peuvent grandement influencer les résultats (par exemple, des développeurs comprendront probablement un produit technique plus facilement que des boulangers).
A/B Testing
La seconde possibilité, qui s'applique encore une fois très bien en B2C, est l'A/B Testing. Cette méthode consiste à mettre en production deux versions d'une même fonctionnalité, et de comparer les KPI suite à une utilisation réelle, pour en déterminer la meilleure déclinaison.
Si cette option est la plus fiable, elle demande quelques éléments qui rendent sa mise en place compliquée au début d'un projet :
une version utilisable des deux versions d'une fonctionnalité ;
une répartition représentative de l'apparition des deux versions : en effet, si la fonctionnalité A apparaît dans 99 % des cas, contre seulement 1 % pour la fonctionnalité B, la comparaison n'aura aucun sens ;
Un produit B2C : en effet, en B2B, l'usage du produit sert généralement un besoin professionnel, ce qui rend l'impact d'une fonctionnalité insatisfaisante bien plus gênant.
Une mise en production totale ou partielle
Dans la majeure partie des cas, c'est en mettant le produit dans les mains de ses clients, ou de ses collègues qui en sont les plus proches, que le PM pourra valider ses hypothèses. La manière dont le produit sera mis en production pourra l'aider à minimiser l'impact d'une fonctionnalité insatisfaisante, comme nous l'aborderons dans un chapitre ultérieur de cette partie, entièrement dédiée à ce sujet.
En bref
Construire un produit ou une fonctionnalité demande de faire des hypothèses de plus en plus avancées et de les valider ;
si le produit ou la fonctionnalité est un échec, l'arrêter peut être l'action la plus pertinente ;
des hypothèses précises peuvent aider à estimer le gain et à justifier le coût d'un produit ou d'une fonctionnalité ;
les tests utilisateurs et l'A/B Testing sont les deux méthodes de validation les plus fréquentes en B2C ;
la validation des hypothèses est une phase complexe en B2B et peut passer par une méthode de mise en production particulière.
Une fois le cycle de définition du produit terminé, le Product Manager doit partager sa vision avec toutes les parties prenantes, comme nous le verrons dans le chapitre suivant.
