Découverte Produit

Connaissez-vous cette situation ? Dans votre entreprise, tout le monde est enthousiaste à propos d'une idée de produit et on vous demande, en tant que product manager, de définir ce produit. On vous dit que les développeurs auront terminé leur projet actuel dans quatre semaines. Cela signifie que vous pouvez prendre tout le temps que vous voulez, tant que vous êtes prêt dans quatre semaines…

Vous dites que ce n'est pas un problème (après tout, parfois vous n'avez que quelques jours, alors quatre semaines semblent idéales). Vous allez même utiliser toutes ces super méthodes dont je parle toujours. Vous commencerez par évaluer les opportunités pour comprendre le problème à résoudre. Ensuite, vous mènerez des interviews avec de vrais utilisateurs et créerez une liste préliminaire d'exigences. Au début de la deuxième semaine, vous devriez donc pouvoir travailler avec un Interaction Designer sur un prototype. La troisième semaine, vous pourrez tester ce prototype et la quatrième semaine, vous élaborerez les détails des cas d'utilisation et réviserez le prototype et les spécifications avec les développeurs.

La réalité de la Product Discovery

Ça a l'air vraiment génial – mais ce qui se passe en réalité n'est généralement pas si génial que ça : pendant les premières discussions avec les clients, il s'avère que ceux-ci ne sont pas aussi enthousiastes à propos du produit que ne l'était le management, et/ou tu as du mal à concevoir un prototype avec lequel les clients s'en sortent, et/ou les clients ne trouvent pas vraiment géniales les idées mises en œuvre dans le prototype. Mais maintenant le temps est écoulé et les développeurs sont prêts. Pendant les trois à six mois suivants, on développe donc le même produit inutile et ennuyeux qu'on avait déjà vu sous forme de prototype. Quand le produit est enfin livré, le management est à juste titre déçu du résultat.

Quel est le problème ?

Le problème ne vient pas de la fiabilité du logiciel. Les développeurs n'y sont donc pour rien – après tout, ils n'ont fait que construire ce que vous leur avez demandé. Tout le monde sait donc que c'est votre erreur en tant que product manager.

Car il ne sert à rien de parler avec les utilisateurs, de développer des prototypes et de les tester avec eux, si on ne met pas en œuvre ce qu'on en apprend.

L'idée de considérer les exigences et le design comme une phase séquentielle, prévisible et planifiée dans le processus de développement produit est si profondément ancrée dans notre secteur qu'il est souvent très difficile pour les organisations produit de se défaire de cette habitude.

Pourtant, elles doivent le faire. Dans les organisations produit, il faut comprendre que l'invention de nouveaux produits est fondamentalement un processus créatif. C'est davantage un art qu'une science. C'est pourquoi je préfère appeler cette phase "Product Discovery" plutôt que "exigences et design".

Le terme "Product Discovery" souligne deux points particulièrement importants :

• Premièrement, il faut découvrir s'il existe vraiment des clients qui veulent ce produit. Cela signifie qu'il faut définir le marché et faire valider l'opportunité du produit par ses clients.

• Deuxièmement, il faut trouver une solution à ce problème qui soit utilisable, utile et réalisable. Et cela signifie qu'il faut concevoir le produit puis le valider conjointement avec les clients et l'équipe de développement.

Product Discovery dans l'industrie pharmaceutique

L'industrie pharmaceutique est un exemple extrême. Trouver un marché n'est pas particulièrement difficile – il y a toujours suffisamment de problèmes qui valent la peine d'être résolus (par exemple sauver des vies, prolonger la vie ou améliorer la qualité de vie). Trouver la solution, c'est la partie difficile. Quand les entreprises pharmaceutiques entament la « phase de découverte », elles sont parfaitement conscientes qu'il n'y a aucune garantie de trouver une solution ni de savoir combien de temps le processus prendra. Dans cette industrie, il faut donc composer avec cette incertitude (et le risque se reflète dans les prix des produits).

Raisons des difficultés avec la Product Discovery

Et bien que nous sachions tous que c'est difficile et que la majorité des releases logicielles sont des échecs parce qu'elles n'atteignent pas les objectifs souhaités, nous insistons toujours, lors du développement de logiciels, pour planifier la phase de Discovery exactement comme la construction d'un bâtiment.

Le management en particulier a du mal avec le concept de Product Discovery. Et je pense qu'il y a deux raisons à cela :

• Premièrement, le processus de Discovery n'est pas prévisible. Le management craint de travailler pendant des mois sur quelque chose sans obtenir de résultats. Si on se lance directement et qu'on développe n'importe quoi, on peut au moins prétendre avoir livré quelque chose. C'est probablement la même raison pour laquelle tant de managers ont du mal avec Scrum, car ils veulent savoir exactement combien de Sprints de 30 jours seront nécessaires avant d'avoir terminé.

• Deuxièmement, dans une organisation produit orientée software, les développeurs sont toujours considérés comme une ressource rare. L'idée qu'une équipe de développeurs reste assise à ne rien faire, à part jouer au baby-foot, rend le management fou.

Ironiquement, c'est précisément ce raisonnement qui conduit à gaspiller les développeurs en tant que ressource.

Presque toutes les entreprises utilisent le processus de Discovery que nous venons de décrire. Au lieu de consacrer plusieurs semaines à un prototype, elles font réaliser des cycles de release complets à toute l'équipe de développement pour créer le logiciel, qui passe ensuite par l'assurance qualité avant d'être déployé en production. C'est pourquoi tant d'entreprises ont besoin de trois releases ou plus, et d'un à deux ans, avant d'obtenir quelque chose d'utile et d'utilisable. Elles utilisent l'organisation de développement pour construire un prototype extrêmement coûteux, et transforment leurs clients en cobayes involontaires.

C'est aussi la raison pour laquelle tant de start-ups échouent. Elles n'ont tout simplement pas le capital nécessaire pour attendre deux ans avant de pouvoir décoller. Alors, elles mobilisent leurs développeurs, les laissent donner le meilleur d'eux-mêmes et attendent de voir ce qui se passe.

Conclusion

Je conseille donc aux start-ups ainsi qu'aux grandes entreprises de concentrer leurs forces sur ce processus de Discovery beaucoup plus rapide. Une fois qu'elles ont trouvé une solution qui fonctionne (qui est utilisable, utile et réalisable), tout tourne autour du travail de développement. Jusqu'à ce point, elles n'ont pas encore besoin d'autant de développeurs. Les développeurs qu'elles ont peuvent et devraient participer activement au processus de Discovery. Jusqu'à un certain point, les développeurs peuvent aussi préparer l'infrastructure pendant le processus de Discovery.

Vous pouvez aider votre management à comprendre le processus de Product Discovery. Si vous soulignez systématiquement qu'il est de votre devoir de veiller à ce que les développeurs créent quelque chose d'utile et d'utilisable, et que vous participez aux efforts pour trouver une solution prometteuse, vous pourrez attirer l'attention du management sur cette phase extrêmement importante du processus de développement produit.

Ce texte provient du blog de Marty Cagan et a été traduit par nos soins en français. 

Créer des produits exceptionnels

=> Discovery vs Delivery pour les produits.

Concevoir une stratégie produit

Découvre comment ta stratégie d'entreprise vs. stratégie produit se distingue.