Les 4 Plus Gros Mythes du Développement de Produit & Comment Les Éviter

Mais le défi est de rassembler tout le monde autour de la même vision avant que les dégâts ne soient faits. La dernière chose que vous souhaitez, c’est une lutte de pouvoir permanente à votre lieu de travail. Si cela reste incontrôlé, ce sera encore un problème qui ne disparaîtra pas de sitôt.

Si vous travaillez dans le développement produit et que vous vous demandez où ça coince, jetez un œil à ces mythes courants du développement produit. Cela vous aidera à rester maître de votre domaine. 

• Plus de ressources signifie de meilleures performances
• Travailler en grands lots améliore le processus de développement
• Gaver le produit de fonctionnalités, et les clients l’adoreront.
• S’en tenir au plan, coûte que coûte

Passons à la démystification professionnelle

Mettons une chose au clair : le développement produit est un tout autre jeu que la fabrication. Dans l’industrie, on peut maîtriser les coûts et augmenter l’efficacité de manière classique. Mais si vous appliquez ces méthodes au développement produit, vous finirez par faire plus de mal que de bien. 

Pourquoi ? Parce que la production est prévisible. Les tâches se répètent, comme des rouages dans une machine. En revanche, le développement produit est dynamique et en constante évolution. Il n’existe pas une seule bonne façon de faire : on apprend en avançant. Cela nous amène à notre premier mythe sur le développement produit.

Unlock the Product Vault

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Company

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Mythe 1 : Plus de ressources signifie de meilleures performances

Rajouter des moyens égale plus de résultats semble totalement logique, mais cette logique est dangereuse et trompeuse dans le développement produit. 

Selon des enquêtes, la majorité des responsables du développement produit maintiennent l’utilisation de la capacité au-dessus de 98 pour cent. Il paraît naturel que plus une équipe travaille, plus elle sera productive.

En pratique, cela ne fonctionne pas ainsi. Une utilisation trop élevée des ressources aboutit à de moins bons résultats et à une baisse de performance de l’équipe. Peu importe la qualité de votre gestion, vous ne pouvez pas contourner ce phénomène. Pourtant, beaucoup de responsables ferment les yeux là-dessus pour deux raisons principales :

1. Ils sous-estiment l’imprévisibilité du développement produit. Un projet peut arriver sur votre bureau à n’importe quel moment. Impossible de prévoir de quoi il s’agit, quelles compétences il faudra, ni combien de temps cela prendra.

Le développement produit est tout sauf linéaire. Introduire une utilisation intensive des ressources rend le processus encore plus sujet aux retards, aux blocages et à l’attente. En effet, si une équipe est constamment à 100 % de sa capacité, tout nouveau projet devra attendre car il n’existe aucune marge de manœuvre.

2. Une chose que les responsables produit sous-estiment régulièrement, c’est l’impact négatif des files d’attente sur la performance. Lorsqu’une équipe de développement produit travaille à pleine capacité et gère plusieurs projets simultanément, elle finit par mettre de côté les projets qui restent bloqués sur des validations ou des approbations.

Imaginons que vous concevez un produit et, en cours de route, vous ne puissiez pas avancer sans le feu vert du service ingénierie. Supposons que cette validation prenne trois semaines. Que faites-vous ? Attendre trois semaines ou démarrer un nouveau projet en attendant ? La plupart des créateurs de produits optent pour la seconde solution, sans réaliser qu’ils s’exposent à de nouveaux problèmes.

Lorsque vous obtenez l’approbation, vous êtes lancé sur un autre projet et vous n’avez plus la capacité de reprendre le premier. Résultat, le projet initial reste en attente à moins que vous ne libériez des ressources pour le poursuivre. Cette inactivité expose le projet au risque de devenir obsolète si le marché évolue.

Encore une fois, cela provient d’une utilisation excessive des ressources. Travailler à pleine charge génère de longues files d’attente. Ce cercle vicieux se répète jusqu’à ce que vous dissipiez le backlog ou que vous augmentiez la capacité de travail en constituant une nouvelle équipe. En résumé, les files d’attente :

• Augmentent les coûts de délai, les coûts de processus et les cycles de production.
• Met en attente des projets. Plus un projet reste en attente, plus il devient vulnérable aux évolutions du marché.
• Rendent le développement produit encore plus instable.

Voici comment résoudre ce casse-tête en matière d’allocation des ressources :

1. Limitez le nombre de projets en cours. Cela réduira votre taux d'utilisation, libérera de la capacité et entraînera moins de files d’attente. En outre, l’équipe sera davantage concentrée sur les tâches à réaliser.
2. Rendez l’inventaire des travaux en cours (WIP) plus visible. Dans le développement de produit, le travail en cours est invisible, c’est pourquoi il est si difficile d’allouer les ressources efficacement. J’ai toujours trouvé les tableaux de contrôle visuels dans les logiciels de développement de produit très utiles pour rester à jour. Vous pouvez organiser des réunions de 10 minutes tous les jours ou utiliser beaucoup de post-it. L’objectif est que chacun communique autant que possible sur ses étapes clés.
3. Alignez les objectifs des départements. Reprenez par exemple le cas où vous devez attendre trois semaines pour obtenir une validation. Que se passerait-il si cela ne prenait que quelques heures ? Pour cela, il faut synchroniser les objectifs des départements en modifiant les systèmes de contrôle de gestion. La plupart des managers souhaitent augmenter la capacité, sans se rendre compte qu’ils peuvent en dégager beaucoup en optimisant et en rendant les opérations plus efficaces.

Mythe 2 : Travailler avec de gros lots améliore le processus de développement

Travailler avec de gros lots fonctionne bien dans l’industrie manufacturière, mais pas dans le développement de produit. Les gros lots impliquent plus de files d’attente, donc davantage de travaux en cours et des temps de cycle plus longs.

Supposons qu’une équipe doive fabriquer 300 composants d’une machine. Elle peut construire toutes les pièces en même temps ou travailler par lots de 20. Si elle décide de tout fabriquer en une seule fois :

• Les files d’attente seront plus longues
• Les temps de cycle seront plus importants 
• Les retours seront minimes

Un plan de développement de produit ne se déroule pas toujours comme prévu. Vous devrez ajuster les spécifications techniques ou une autre caractéristique du produit. La seule façon de progresser dans cette courbe d’apprentissage est d’obtenir des retours.

Le retour est l’information que l’on apprend en testant le produit et en observant ses performances. Il est essentiel pour déterminer si le processus de développement nécessite des modifications en fonction des facteurs techniques. Un faible niveau de retour implique un allongement des délais de cycle. Un temps de cycle est la période qui s’écoule entre la finalisation de la conception et la production. On peut le mesurer grâce à la loi de Little.

Dans le second cas, la taille du lot est réduite de 90 % :

• Il y a peu ou pas de travaux en cours 
• Pas de files d’attente 
• Des retours rapides
• Meilleure qualité, meilleure efficacité et réduction des délais de cycle

Beaucoup de développeurs de produit prennent la première option, pensant que le travail en gros lots permet des économies d’échelle. Mais c’est loin d’être vrai. Déterminer une taille de lot optimale consiste à trouver l’équilibre entre les coûts de transaction et les coûts de stockage. 

Si vous achetez aujourd’hui une année d’œufs d’un coup, leur prix unitaire sera peut-être intéressant, mais la plupart finiront par se gâter. Autrement dit, vous avez un faible coût de transaction, mais un coût de stockage élevé. L’astuce pour tirer le meilleur des deux mondes consiste à trouver le juste équilibre.

Déterminer la bonne taille de lot n’est pas une mince affaire. Elle varie selon l’activité. Par exemple, si vous avez une épicerie, vos coûts de stockage seront bien plus élevés que ceux d’un fabricant d’acier. En résumé, choisissez une taille de lot qui ne crée pas de nouveaux goulets d’étranglement et minimise le coût total.

À lire aussi : Comment créer une boucle de retour client efficace pour les équipes produit ?

Mythe 3 : Inonder le produit de fonctionnalités, et les clients l’adoreront.

Les développeurs de produit supposent souvent que plus ils intègrent de fonctionnalités à un produit, plus les clients l’apprécieront. C’est tout l’inverse, et cela mène généralement à la dérive des fonctionnalités. Combien de fois avez-vous acheté un produit que vous avez trouvé trop compliqué à utiliser ?

Cela arrive tout le temps. Les casques audio ont souvent trop de boutons, les télécommandes de téléviseur sont difficiles à utiliser, les systèmes d’affichage LCD sont pénibles à configurer, et la recharge sans fil reste un rêve. Pourtant, il est difficile de convaincre un développeur de produit de faire simple, et cela pour deux raisons principales :

1. Les développeurs de produit ont tendance à générer beaucoup d’idées sans les filtrer. J’ai remarqué qu’il manque souvent cet élément filtrant. C’est comme pour un forcené du travail qui ne supporte pas qu’il y ait un créneau vide dans sa journée. Il doit forcément le remplir d’une tâche productive.

De la même manière, les développeurs produits voient une opportunité dès qu’ils trouvent un espace vide où ils peuvent ajouter des fonctionnalités à un produit, et ce même si le consommateur ne les utilisera jamais.

Apple Inc. est un excellent exemple du contraire. L’entreprise privilégie toujours la simplicité et l’élégance. Le développement produit commence à partir de l’utilisateur final et remonte ensuite vers la technologie. Autrement dit, c’est le consommateur qui guide la technologie, et non l’inverse. En réalité, c’est l’équipe de design d’Apple qui a le dernier mot avant la mise sur le marché d’un produit.

Accumuler des fonctionnalités inutiles dans un produit n’apporte aucune valeur supplémentaire au client. Selon McKinsey, la majorité des entreprises « surveillent la satisfaction des clients quant aux performances du produit [et] seulement 44 % d’entre elles mesurent la satisfaction des clients quant au prix payé pour la valeur reçue ».

Les entreprises qui se basent davantage sur cette dernière mesure s’en sortent mieux en termes de croissance et de stabilité du profit à court comme à long terme. À l’inverse, celles qui se concentrent uniquement sur la performance du produit passent à côté de la croissance à long terme.

2. Les développeurs produits aiment exhiber leur expertise. À tel point qu’ils en oublient parfois que ce qui compte, c’est avant tout l’expérience client et non l’aspect technique. Tout ce que veulent les consommateurs, c’est une expérience utilisateur fluide, une solution qui fonctionne sans effort.

Pour cela, les développeurs produits doivent savoir ce qu’il faut éliminer. Mettez-vous à la place des consommateurs. Achèteriez-vous un réfrigérateur doté d’un système audio intégré ? Au départ, cela semble impressionnant, mais il est peu pratique d’écouter de la musique sur un réfrigérateur.

Réduisez votre liste. Les fonctionnalités retenues doivent être essentielles ou permettre au produit de se démarquer. Souvenez-vous qu’un produit n’est pas achevé lorsqu’on ne peut plus rien ajouter, il est achevé lorsque retirer une fonctionnalité le rendrait moins bon plutôt que meilleur. 

Voici un exemple du processus que j’ai utilisé en travaillant avec des designers UX/UI pour créer une application simple et facile d’utilisation à destination des commerçants.

1. Lancer une phase d’idéation, ce qui veut dire poser les bonnes questions et répondre au « comment ». C’est l’occasion d’aller au-delà de l’évident et de chercher des solutions innovantes en échangeant des idées au sein de l’équipe. Nous fixons aussi une limite de temps pour ne pas nous éparpiller. Il ne faut pas sacrifier la créativité sur l’autel du temps et de l’efficacité.
   
2. Après avoir ciblé clairement votre vision du produit final, l’étape la plus importante à mon sens — et que la plupart des développeurs omettent — est de partir de la fin et de remonter à reculons. Cela permet de définir toutes les étapes nécessaires pour arriver à votre produit final. La plupart des développeurs partent de zéro et finissent par perdre de vue leur objectif initial.
   
3. Comme mentionné précédemment, le plan de développement produit peut évoluer, et il évolue. Au fil du processus, le brainstorming continue, mais il s’oriente désormais sur la technique. Il s’agit d’affiner l’idée de départ et de la porter à un niveau supérieur.

Mythe 4 : S’en tenir au plan, coûte que coûte

Comme le dit le proverbe, « les plans les mieux conçus des souris et des hommes tournent souvent mal ». Rien n’est plus vrai. Du début à la fin, le développement de produit repose sur l’essai et l’erreur. L’expérimentation permet de repérer les failles que vous n’aviez pas vues auparavant.

Une étude du MIT illustre la nature dynamique du développement de produit. Des ingénieurs aéronautiques travaillant sur un sous-système ont examiné plusieurs conceptions avant de sélectionner la meilleure. Pourtant, tout au long du processus d’ingénierie, leurs préférences ont évolué en fonction des résultats des tests.

Le développement produit repose sur l’innovation. On part d’une idée initiale, que l’on ajuste au fur et à mesure. Peut-être que l’arrière en verre du téléphone chauffe trop, ou que les bords incurvés empêchent d’intégrer l’antenne GPS. Ces constats n’apparaissent qu’au moment des essais et des tests.

Comme évoqué plus tôt, le développement produit commence par le client, pas la technologie. Mais comment évaluer les besoins du client ? La plupart des clients mécontents ne se plaignent pas, ils partent tout simplement. Pire encore, et si les préférences des clients évoluent pendant le développement, sous l’effet de tendances du marché changeantes ?

La réponse à toutes ces questions, c’est d’adapter votre plan de développement. Cela ne signifie pas que la planification est inutile ; mais elle doit être méticuleuse jusque dans les moindres détails. Considérez votre plan comme une hypothèse, et non comme une loi, car au final, vous ne voulez pas d’un plan parfait, vous voulez un produit parfait.

Voici quelques éléments pour rendre votre plan de développement produit plus flexible :

1. Élaborez un plan global. Considérez-le comme un squelette, une structure de base qui guidera votre processus de développement. Ne vous attardez pas sur les détails : ils s’ajouteront d’eux-mêmes avec le temps. Vous devrez peut-être même ajuster la structure de base pour intégrer certains détails indispensables à votre produit.
   
2. Attendez-vous à des imperfections dans votre plan. Il est impossible de tout anticiper. C’est pourquoi votre plan doit prévoir une marge de manœuvre suffisante pour pouvoir rebondir si besoin. Prévoyez des alternatives à la structure de base que vous avez déjà conçue.

Lecture associée : Meilleurs logiciels de planification de produit

Quelques mots de conclusion

Sans aucun doute, les développeurs de produits accomplissent certains des travaux les plus complexes au monde. L’innovation demande du temps et requiert de nombreux essais. On ne peut pas la traiter comme un processus industriel classique tel que la fabrication ou la production. En tant que développeur de produit moi-même, je peux affirmer que la plupart des managers ne le comprennent pas. Ils vivent dans ces mythes, et il faut bien que quelqu’un fasse éclater leur bulle.

Aussi passionnant que puisse être le développement de produit, il peut s’avérer tout aussi frustrant et épuisant, que vous ayez une personne dédiée à chaque tâche ou que vous gériez des produits sans équipe complète. Le secret pour rester performant, c’est de faire tomber les mythes ci-dessus. Si vous débutez en tant que chef de produit, nous venons de vous épargner d’innombrables maux de tête et réunions inutiles. Si vous êtes un professionnel chevronné, n’hésitez pas à partager d’autres mythes sur la gestion de produit dans les commentaires ci-dessous.

Pour encore plus d’articles pratiques sur la gestion de produit et des conseils d’experts du secteur pour garder une longueur d’avance, abonnez-vous à la newsletter du CPO Club.

Ou bien, écoutez certains de nos podcasts comme celui-ci : Cultiver la dynamique (avec Paul Ortchanian de Bain Public)