Construisez votre roadmap produit

Des besoins d’utilisateurs vous seront aussi régulièrement remontés. Comme pour des besoins de vos collègues, la très grande majorité des retours de vos utilisateurs ne seront pas actionnables immédiatement. Vous devrez toujours questionner chaque retour ou idée pour mieux comprendre le problème que tente de résoudre votre utilisateur.

En tant que product manager, vous aurez accès à de très nombreuses sources pour collecter ces besoins, dont voici quelques exemples :

• les emails clients (via le service client) ;

• les réseaux sociaux ;

• les notes et commentaires sur les stores (pour les applis mobiles).

Pour autant, la très grande majorité des retours que vous y lirez ne seront pas actionnables immédiatement. Vous devrez toujours questionner chaque retour ou idée pour mieux comprendre le problème que tente de résoudre votre utilisateur.

Ne laissez pas les demandes utilisateurs occulter les besoins

Vous recevrez de très nombreuses demandes de nouvelles fonctionnalités de la part de vos utilisateurs. La plupart seront très intéressantes, mais pour autant vous ne devriez jamais vous contenter de les consigner sans en questionner le fondement. Sans vous demander "Pourquoi l'utilisateur a-t-il besoin de ça ?" En vous posant ces questions, vous serez plus à même de dénicher le problème que l'utilisateur tente de résoudre, de comprendre son besoin.

Si Uber se contentait d'écouter les demandes déclarées de ses utilisateurs, il y a fort à parier que le service ne s'intéresserait qu'à l'optimisation du produit existant. Ses millions d'utilisateurs ne tiennent pourtant pas absolument à monter à l'arrière d'une berline commandée via une application. Ils ont avant tout besoin de se déplacer efficacement d'un point A à un point B. 

Et c'est bien parce que l'entreprise continue à questionner ce besoin premier de ses utilisateurs qu'elle essaye d'offrir de nouvelles solutions aux problèmes de mobilité de ses utilisateurs, telles que UberPool (les courses partagées), les vélos en libre-service, les trottinettes électriques...

Intéressez-vous aux plaintes de vos utilisateurs

Ne vous intéressez pas uniquement à ce qui semble être des demandes produit évidentes, comme l'ajout d'une fonctionnalité sur la plateforme par exemple. De nombreux messages sous forme de plaintes font simplement état d'un problème ou d'une réclamation, et ces cas sont des mines d'or pour trouver des axes d'amélioration pour votre produit. Ils vous indiqueront un besoin que l'utilisateur n'arrive aujourd'hui pas, ou mal, à remplir avec votre produit.

Dans le cas de HappyDay, nous pourrions par exemple constater que de nombreux utilisateurs se plaignent du manque de réactivité des propriétaires des lieux d'évènements. Ces derniers répondent souvent plusieurs jours après une demande d'informations, voire jamais. 

Les utilisateurs auraient du mal à imaginer des solutions pour ce problème, mais en tant que product manager vous pouvez déjà en imaginer de nombreuses :

• ajouter des notifications mobiles ;

• favoriser les propriétaires avec un bon taux de réponse dans la recherche ;

• désactiver les annonces des propriétaires qui ne répondent jamais, etc.

Ici, il y a fort à parier qu'en vous intéressant de plus près aux problèmes de vos utilisateurs, vous avez débusqué un bel axe d'amélioration pour votre produit. 

Utilisez la méthode Jobs-to-be-done

La méthode Jobs-to-be-done peut vous faire gagner beaucoup de temps pour débusquer les besoins de vos utilisateurs. En effet, tout comme pour vos collègues, vous devez questionner vos utilisateurs pour découvrir les besoins derrière leurs retours. Si vous le pouvez, décrochez votre téléphone ou envoyez-leur un email. Cela demande cependant beaucoup de temps pour une réponse incertaine. Pour en gagner, vous pouvez essayer de formuler le besoin de vos utilisateurs par vous-même.  C'est l'objectif du mantra "Jobs-to-be-done" (la tâche à effectuer).

La méthode Jobs-to-be-done propose de prendre du recul quant à une action qu'essaie d'entreprendre un utilisateur, pour la formuler de la façon la plus claire possible, et d'envisager ensuite plusieurs solutions.  Pour cela cette méthode propose de disséquer le besoin exprimé en se posant la question “pourquoi” sous trois axes différents :

• L’aspect fonctionnel : quel résultat concret l’utilisateur veut-il atteindre ?

• L'aspect personnel : quel intérêt personnel a-t-il à effectuer cette action ?

• L'aspect interpersonnel : quel intérêt auprès des autres l’utilisateur a-t-il à effectuer cette action ? 

Reprenons notre exemple de HappyDay, avec un utilisateur qui souhaite rentrer en contact avec un propriétaire de lieu pour le réserver.

Tâche de l'utilisateur : envoyer un message au propriétaire

• l'aspect fonctionnel : l'utilisateur veut vérifier la disponibilité du lieu pour le réserver ;

• l'aspect personnel : l'utilisateur veut se rassurer pour ne pas être pris de court le jour de son anniversaire ;

• l'aspect interpersonnel (perception des autres) : l'utilisateur ne veut pas passer pour quelqu'un qui ne saurait pas s'organiser auprès de ses amis. 

En nous intéressant de plus près à ce besoin, nous découvrons qu'une myriade de solutions peuvent y répondre : 

• encourager plus fortement les propriétaires à mettre à jour leurs disponibilités sur la plateforme ;

• laisser l'utilisateur réserver le lieu sans contacter au préalable le propriétaire ;

• rassurer l'utilisateur sur le délai de réponse...

Maintenant que nous savons partir d’une demande client pour en extraire un besoin, puis des pistes de solutions, voyons comment prendre en compte les données pour nourrir la roadmap.

En bref

• Vous disposerez très vite de nombreuses sources de besoins, retours et demandes de vos utilisateurs ;

• questionnez chaque retour ou idée pour mieux comprendre le problème que tente de résoudre votre utilisateur ;

• une plainte être très précieuse : elle met en exergue un problème concret que votre utilisateur n'arrive pas à régler avec votre produit ;

• pour mieux formuler un besoin en peu de temps, vous pouvez utiliser la méthode "Jobs-to-be-done".