Produits échoués

Remarque : Cet article est la version écrite d'une conférence que j'ai donnée pour les développeurs à la Craft Conference et pour les product managers et designers à Mind The Product.

Dans cet article, je souhaite parler des causes qui font échouer tant de produits.

Pourquoi les produits et les lancements de produits échouent-ils ?

Dans la plupart des entreprises, je constate la même approche fondamentale du travail, et elle n'est en rien comparable à la façon de travailler des entreprises vraiment performantes.

Permettez-moi d'ajouter un petit avertissement, car cette discussion peut être déprimante, surtout si vous êtes directement concerné par ce sujet. Si c'est le cas, je vous demande simplement un peu de persévérance.

Le processus de développement de produit

Commençons par examiner le processus que la plupart des entreprises utilisent encore pour développer leurs produits. Je vais essayer de ne pas porter de jugement pour l'instant, mais simplement de décrire le processus :

Tout commence par des idées. Dans la majorité des entreprises, ces idées viennent de la direction, des principaux stakeholders, des propriétaires de l'entreprise ou des gros clients (ou clients potentiels). Dans tous les cas, il y a toute une série de choses que nous devons faire pour les différents départements d'une entreprise.

Ensuite, dans la plupart des entreprises, les idées sont priorisées dans une roadmap et cela pour deux raisons : premièrement, on veut que les choses les plus précieuses soient traitées en premier, et deuxièmement, on veut pouvoir estimer quand ces choses seront terminées.

Pour cela, il y a presque toujours une réunion de planification trimestrielle ou annuelle où les dirigeants passent en revue les idées et négocient une roadmap produit. Cependant, pour pouvoir tout prioriser, ils ont d'abord besoin d'une sorte de business case pour chaque élément.

Certaines entreprises élaborent des business cases formels, d'autres plutôt informels, mais dans les deux cas, il s'agit de déterminer les deux choses suivantes :

1) Combien d'argent pouvons-nous gagner avec ça ?

2) Combien d'argent ou de temps cela va-t-il coûter ? À partir de ces informations, la roadmap est ensuite créée, généralement pour le trimestre suivant, mais parfois même pour une année entière.

À ce stade, l'ordre de marche est donné pour le produit et la technologie, et normalement les travaux sont ensuite réalisés par ordre de priorité.

Quand une idée a atteint le sommet de la liste des priorités, le product manager parle d'abord avec les stakeholders pour développer l'idée et formuler des « exigences ».

Cela peut être des User Stories ou une sorte de spécification fonctionnelle ; l'objectif devrait cependant dans tous les cas être la communication avec les designers et les développeurs qui doivent construire le produit.

Une fois qu'on a toutes les exigences, l'équipe User Experience Design (à condition qu'une telle équipe existe dans l'entreprise) est invitée à s'occuper du design d'interaction, du design visuel et, dans le cas du matériel, du design produit.

Finalement, les exigences et les spécifications de design arrivent aux développeurs. C'est généralement le moment où Agile entre en jeu.

Le rôle des développeurs dans le processus de développement

Les développeurs divisent ensuite le travail en itérations, appelées « Sprints » en Scrum. Il faut généralement 1 à 3 Sprints pour mettre en œuvre l'idée.

Dans le meilleur des cas, les tests QA sont intégrés au Sprint. Sinon, l'équipe QA effectuera quelques tests supplémentaires pour vérifier si l'idée fonctionne comme prévu et si aucun autre problème n'apparaît (ce qu'on appelle aussi la régression).

Une fois le feu vert obtenu de l'équipe QA, l'idée est enfin déployée et atteint l'utilisateur.

Presque toutes les entreprises que je visite, qu'elles soient grandes ou petites, travaillent de cette manière depuis de nombreuses années. Et pourtant, toutes ces entreprises se plaignent systématiquement du manque d'innovation et du long délai avant qu'une idée n'arrive enfin entre les mains des clients.

Agile vs. Cascade

Vous avez peut-être remarqué que, bien que j'aie mentionné Agile et que de nos jours presque tout le monde prétende travailler de manière agile, le processus que je viens de décrire est en réalité un processus en cascade. Pour être honnête, je dois dire que les développeurs tirent souvent le maximum d'Agile dans les limites de ce processus en cascade.

D'accord, c'est peut-être l'approche de la plupart des équipes, mais pourquoi est-ce nécessairement la cause de tant de problèmes ?

Pourquoi tant de produits échouent-ils pour cette raison ?

Je vais essayer de te montrer le lien qui explique pourquoi cette méthode de travail répandue est en réalité le plus souvent responsable de l'échec des produits.

Je pourrais parler une éternité des problèmes liés à ce processus, mais je vais simplement lister le Top 10 des problèmes les plus graves de cette méthode de travail. Même si chacun de ces dix problèmes est vraiment sérieux et pourrait faire échouer une équipe, la plupart des entreprises cumulent plusieurs, voire tous ces problèmes en même temps.

1) Commençons par le haut – la source des idées. Ce modèle conduit à des offres spéciales orientées chiffre d'affaires et à des produits orientés parties prenantes. Il y a beaucoup à dire sur ce sujet, mais pour l'instant, je veux simplement souligner que ce ne sont pas les meilleures sources d'idées produit. Une autre conséquence de cette approche est le manque d'autonomisation de l'équipe, car dans ce modèle, elle n'est responsable que de l'exécution – des mercenaires.

2) Parlons de la faiblesse des Business Cases. Pour que tu ne me comprennes pas mal, je trouve les business cases fondamentalement bons, du moins pour les idées représentant un investissement important. Mais la façon dont la plupart des entreprises les élaborent à ce stade pour obtenir une roadmap priorisée est vraiment ridicule. Tu te souviens des deux éléments qui sous-tendent chaque business case ? Combien on va gagner et combien ça va coûter ? À ce stade, on ne peut tout simplement pas le savoir, car on n'a aucune idée de ces deux facteurs.

On ne peut tout simplement pas savoir combien on va gagner, car cela dépend principalement de la qualité de nos solutions. Si l'équipe fait un travail extraordinaire et connaît un succès exceptionnel, cela peut changer complètement la trajectoire de l'entreprise. D'un autre côté, la triste vérité est que la plupart des idées produit ne rapportent absolument rien. Et ce n'est pas exagéré. Je veux vraiment dire rien. Quoi qu'il en soit, l'une des leçons les plus importantes du développement produit est de savoir ce qu'on ne peut pas savoir. Et à ce stade, on ne peut tout simplement pas savoir combien d'argent on va gagner.

De même, on n'a aucune idée de ce que le développement du produit va nous coûter. Sans solution concrète, c'est assez difficile à estimer. Beaucoup de développeurs expérimentés refuseront de donner une estimation si tôt, bien que certains acceptent le bon vieux compromis « T-shirt » : dites au moins si c'est « Small, Medium, Large ou Extra Large » !

Les entreprises veulent des roadmaps priorisées et pour cela, elles ont besoin d'un système pour évaluer les idées. Alors les gens jouent le jeu du business case.

3) Ensuite vient un problème encore plus grand. Les entreprises adorent les Roadmaps. J'ai vu beaucoup de roadmaps et la plupart ne sont en fait que des listes de fonctionnalités priorisées. Le marketing a besoin de cette fonctionnalité pour une campagne. Les ventes ont besoin de cette fonctionnalité pour un nouveau client. Quelqu'un veut intégrer PayPal. Je pense que tu vois ce que je veux dire.

Cependant, il y a un problème et c'est peut-être le plus grand de tous. Je l'appelle les « deux vérités inconfortables sur les produits ».

La première vérité est qu'au moins la moitié de nos idées ne fonctionneront tout simplement pas. Il y a tellement de raisons pour lesquelles une idée ne fonctionne pas. Le plus souvent, les clients ne sont tout simplement pas aussi enthousiastes par l'idée que nous. Alors ils n'utilisent pas le produit. Parfois ils veulent l'utiliser, mais c'est tellement compliqué que ça apporte plus de frustration que de valeur. Le résultat est donc le même : les clients ne l'utilisent pas. Parfois les clients adoreraient le produit, mais il s'avère qu'il y a beaucoup plus de travail que prévu et qu'on n'a tout simplement pas l'argent ni le temps de le développer.

Je t'assure qu'au moins la moitié des idées sur ta roadmap ne livreront pas ce que tu espérais. Et au passage, les vraies bonnes équipes partent du principe qu'au moins les trois quarts des idées ne fonctionneront pas comme prévu.

Comme si ce n'était pas assez grave, la deuxième vérité est que même pour les idées qui ont vraiment du potentiel, il faut généralement plusieurs itérations pour les implémenter de manière à ce qu'elles apportent réellement la valeur business attendue. On appelle ça le « Time To Money ».

La chose la plus importante que j'ai apprise concernant le développement produit, c'est qu'on ne peut tout simplement pas échapper à ces deux vérités – peu importe à quel point on est intelligent. J'ai eu la chance de travailler avec des équipes produit vraiment exceptionnelles. La différence réside dans la façon dont on gère ces vérités.

4) Le rôle du produit dans ce modèle : en fait, je ne parlerais même pas du produit comme d'un rôle. Au fond, c'est plutôt une forme de gestion de projet. Dans ce modèle, il s'agit davantage de collecter les exigences et de les documenter pour les développeurs. Crois-moi, cela n'a rien à voir avec le product management moderne.

5) C'est similaire avec le rôle du design. À ce stade, il est déjà bien trop tard pour créer une vraie valeur par le design. On se rabat alors volontiers sur ce qu'on appelle le modèle « Lipstick on the pig ». Le mal est déjà fait et on essaie simplement de le masquer. Les UX Designers savent que ce n'est pas bien, mais ils essaient de rendre le tout aussi beau et cohérent que possible.

6) Ce qui fait perdre le plus d'opportunités avec ce modèle, c'est probablement le fait que le développement n'est impliqué que tardivement dans le processus. On dit que si tes développeurs ne servent qu'à écrire du code, tu passes à côté de la moitié de la valeur qu'ils pourraient t'apporter. Les développeurs sont généralement la meilleure source d'innovation et pourtant, ils ne sont même pas impliqués dans le processus.

7) Ce ne sont pas seulement les développeurs, mais aussi les principes et avantages majeurs de l'Agile qui arrivent bien trop tard ici. Les équipes qui utilisent l'Agile de cette façon n'obtiennent qu'environ 20% de la valeur et du potentiel des méthodes agiles. Ici, l'Agile ne concerne que la livraison, mais le reste de l'organisation et du contexte reste tout sauf agile.

8) L'ensemble du processus est très orienté projet. Une entreprise finance des projets, recrute du personnel pour les projets, fait avancer les projets et les met en œuvre. Malheureusement, les projets ne sont que de l'Output, alors que le développement produit concerne l'Outcome. Ce processus conduit inévitablement à des projets orphelins. D'accord, quelque chose a été livré à la fin, mais ça ne remplit pas l'objectif réel. À quoi bon alors ? C'est un gros problème et cela se rapproche beaucoup de la façon dont nous construisons nos produits.

9) La plus grande faiblesse de l'ancien processus en cascade a toujours été que tout le risque n'apparaît qu'à la fin. La validation par le client arrive tout simplement beaucoup trop tard.

Tu as sûrement entendu parler des méthodes Lean Startup, qui représentent à peu près l'exact opposé. Le principe fondamental est de minimiser le gaspillage et le plus grand gaspillage est de concevoir, construire, tester et déployer une fonctionnalité ou un produit, pour découvrir ensuite qu'il n'est pas nécessaire. Ironiquement, beaucoup d'équipes pensent appliquer les principes du Lean, mais ne font que suivre le processus décrit ci-dessus. Et là je leur explique qu'elles testent leurs idées de la manière la plus coûteuse et la plus lente que nous connaissions.

10) Et pour finir, pendant que nous sommes occupés avec ce processus et gaspillons notre temps et notre argent, les coûts d'opportunité pour les choses qu'une organisation aurait pu et dû faire à la place représentent la plus grande perte. Ce temps et tout cet argent, nous ne les récupérerons jamais.

Je ne suis pas très surpris que tant d'entreprises investissent autant d'argent et de temps pour obtenir si peu en retour. Je t'avais prévenu que ça pourrait devenir déprimant.

La bonne nouvelle, c'est que je peux t'assurer que les meilleures équipes ne travaillent pas du tout de la façon que je viens de décrire.

Résumé

J'ai déjà écrit de nombreux articles sur les différents aspects des meilleures équipes. La Product Discovery consiste à trouver des solutions efficaces à nos problèmes. C'est une forme de collaboration active et continue entre les domaines Produit, User Experience Design et Développement. [Continuous Discovery et Continuous Delivery](/fr/product-owner/discovery-vs-delivery/ "Discovery vs. Delivery) fonctionnent en parallèle. Les features sur les roadmaps (Output) sont remplacées par des problèmes business à résoudre (Outcome). L'objectif est que le produit corresponde le mieux possible à la demande du marché (Product/Market Fit).

Si ton entreprise s'accroche encore à cet ancien processus dépassé, tu peux maintenant, je l'espère, y voir plus clair et prendre un nouveau départ vers l'avenir. Et j'espère que tu y parviendras avant d'être dépassé par une startup ou un concurrent bien plus rapide et efficace que ton entreprise.

Ce texte est tiré du blog de Marty Cagan et a été traduit par nos soins en allemand.

Tableau modèle pour le Product Backlog

=> Voici comment tu peux représenter les User Stories dans le Product Backlog sous forme de tableau.

Le Product Goal Canvas

=> Définis ton objectif produit avec le Product Goal Canvas.