Construire ce dont les clients ont besoin : la recette ultime

Selon Clayton Christensen, professeur à la Harvard Business School, près de 30 000 nouveaux produits sont lancés chaque année et 95 % échouent. Bien que ce nombre soit davantage lié aux produits physiques, il suffit d'un petit effort pour réaliser que cela est vrai pour les produits numériques. Et c'est une pensée terrifiante et dérangeante car les startups et les entrepreneurs investissent des tonnes d'argent pour construire ces produits. Cela nous amène à une question importante que chaque chef de produit et les équipes techniques associées se posent chaque fois qu'ils plongent les pieds dans la rivière de la construction de produits numériques. Pourquoi les produits échouent-ils et que peuvent faire les équipes pour créer les produits dont les clients ont besoin ?

Il y a quelques jours, je discutais avec un chef de produit dans l'une des plus grandes sociétés de logiciels de notre époque. Il dirige plusieurs équipes depuis plus de deux ans maintenant. La partie la plus excitante de son expérience est qu'il a mené plus de 50 expériences au cours de ces deux années. Et ceux-ci ont aidé son équipe à comprendre ce qu'il faut construire et, plus important encore, ce qu'il ne faut pas construire pour les clients. En discutant avec lui, j'ai compris que ces expériences étaient coûteuses en capital et en temps. Ainsi, même décider quelles expériences effectuer était délicat puisque l'équipe devait justifier le capital dont elle avait besoin pour effectuer les expériences.

Malheureusement, seules quelques entreprises ont autant de bande passante et de capital à expérimenter. Il est donc extrêmement important de comprendre les besoins des clients et de créer les produits en conséquence. Mais avant de nous plonger dans la conception des produits dont les clients ont besoin, il est essentiel de comprendre pourquoi les entreprises ne le font pas.

Raisons pour lesquelles les entreprises ne parviennent pas à créer les produits dont les clients ont besoin

• Résoudre le mauvais problème

Après enquête, il s'est avéré que l'automatisation était possible simplement en ajustant les systèmes. Et le problème n'était pas d'utiliser le « ML » pour automatiser certaines tâches, mais c'était d'automatiser certaines tâches principalement parce qu'elles étaient chronophages. En fait, après des recherches plus approfondies, il s'est avéré que cette automatisation n'était pas du tout nécessaire. Cela a été possible parce que le chef de produit a investi du temps pour comprendre et définir le problème. Et c'est pourquoi il est impératif de comprendre le problème à des niveaux plus profonds afin que l'équipe/l'entreprise puisse trouver le bon problème à résoudre. C'est la première et la plus importante étape, et la plupart des produits échouent à cette étape elle-même.

• Viser la solution parfaite

Quelque chose de similaire s'est produit avec le chef de produit avec qui j'ai eu une conversation. Il a participé à la création d'un produit qui remplacerait complètement le système de gestion de contenu actuel pour environ 600 utilisateurs internes. La période initiale pour construire ce système était de 12 mois. Mais au fur et à mesure que l'équipe d'ingénierie a commencé à travailler sur la solution, elle a rencontré plusieurs cas particuliers. Cela a augmenté le délai de 12 mois à 18 mois. Lorsque les utilisateurs ont appris cela, ils ont commencé à remettre en question l'ensemble du système de gestion de contenu. Leur point était que s'il fallait autant de temps pour construire l'ensemble du système, il faudrait des périodes similaires et plus longues pour créer de nouvelles fonctionnalités à l'avenir. Ainsi, ils ont continué à faire pression pour que davantage de fonctionnalités soient ajoutées à la portée.

Tout cela s'est produit parce que les équipes techniques attendaient de construire et de lancer la meilleure solution. Le chef de produit a partagé qu'au lieu de cela, ils auraient dû diviser le système de gestion de contenu en fonctionnalités mineures plus prioritaires et les publier de manière itérative au lieu d'une version système big bang. Heureusement, le risque de publier de cette manière était plus faible puisque le système était destiné aux utilisateurs internes, mais cela aurait pu être un problème plus important si les utilisateurs étaient externes.

• Ne pas obtenir de commentaires précoces

Le 30 juin 1970, AT&T a dévoilé son service commercial Picturephone dans la ville de Pittsburgh, en Pennsylvanie. Aveuglés par leur propre vision, les dirigeants de l'entreprise ont ignoré les commentaires négatifs que l'entreprise a reçus lors de la phase de test. Ils pensaient qu'un million d'unités seraient utilisées dans les dix ans suivant le lancement. À leur grande surprise, ils l'ont retiré du marché en seulement trois ans en raison d'un manque d'intérêt des consommateurs. Pourquoi?

Pendant la phase d'essai, les utilisateurs ont partagé leurs commentaires. Ils ont trouvé l'équipement trop encombrant, l'écran trop petit et cher. Mais tout cela a été ignoré, ce qui a conduit à l'échec complet du produit.

Obtenir des commentaires dès le début et y travailler vous aidera à trouver la bonne solution aux problèmes de vos clients.

Produits de construction dont les clients ont besoin

• Travailler en arrière

• Titre - Idéalement, cela devrait être le nom du produit et indiquer essentiellement de quoi il s'agit
• Sous -titre — L'avantage principal du produit
• Résumé - Résumez ce que fait le produit ainsi que son principal avantage
• Problème — Problème spécifique que ce produit résout
• Solution — De quelle manière le produit résout le problème
• Citation de votre part - Créez un porte-parole fictif et demandez un one-liner expliquant pourquoi ce produit est un incontournable.
• Comment démarrer — Expliquez comment utiliser le produit de la manière la plus simple possible.
• Clôture et appel à l'action — Terminez le communiqué de presse en indiquant au lecteur comment en savoir plus ou commencer à utiliser le produit.

• Sprint de conception

L'un des exemples partagés par le chef de produit était la façon dont un sprint de conception a aidé son équipe à choisir entre la construction et l'achat. Son équipe a été chargée de modifier le flux de production de contenu qui prenait en charge 400 utilisateurs internes. Les tâches de ces utilisateurs consistaient à créer quotidiennement du contenu (images, vidéos, gifs, etc.) qui s'affichait sur le site Web pour 50 millions d'utilisateurs actifs quotidiens. Le nouveau flux de production de contenu devait permettre d'économiser 2 millions d'euros par an en 2020. Le chef de produit a réuni une équipe de sprint composée de quelques utilisateurs, de leur responsable, d'un responsable de l'ingénierie et d'un responsable de la conception. Le sprint a duré une semaine. À la fin du sprint, l'équipe technique a non seulement compris le problème à résoudre, mais a également proposé une solution à faible coût qu'elle a convertie en un produit à part entière en l'espace de 2 mois.

• Commentaires quantitatifs et qualitatifs

• Les commentaires quantitatifs comprennent des expériences telles que des tests A/B, des enquêtes avec des questions fermées et des analyses de produits. Cela nécessite une aptitude analytique car les données sont volumineuses et exprimées sous forme de graphiques et de chiffres.
• Les commentaires qualitatifs comprennent des recherches utilisant des questionnaires avec des questions ouvertes, des entretiens individuels, une observation directe, une enquête contextuelle, des groupes de discussion et une collecte de données personnalisée. Par rapport à la rétroaction quantitative, celle-ci est exprimée en mots.

En tant que tel, il existe plusieurs façons de comprendre les besoins des clients et de créer des solutions en conséquence, et cela dépend uniquement de l'entreprise et de l'équipe pour utiliser l'une des méthodes. Mais, ce qui est plus important, c'est de ne pas fabriquer des produits dont les clients n'ont pas besoin. L'histoire dit que plus les commentaires des clients sont recueillis tôt, plus il est facile de créer les bonnes solutions et d'économiser les ressources.

Quelle méthode utilisez-vous dans votre équipe/entreprise pour construire le bon produit/solution ? Quels problèmes rencontrez-vous lors de l'utilisation de cette méthode ? Commentaires ci-dessous; J'aimerais bien savoir.