La dette produit

Une citation en anglais parce que c’est stylé, ça rend professionnel et c’est plus percutant !

Il existe très peu de ressources francophones sur le sujet que nous allons aborder aujourd’hui. Pourtant, il touche toutes les entreprises dont l’activité implique le cycle de vie d’un ou plusieurs produits numériques. C’est à dire un nombre assez conséquent d’entreprises. Cela est d’autant plus vrai si on un jette un rapide coup d’oeil à la conjecture e-commerce économique actuelle. Et si on se parlait de dette produit ?

« Dark corners and junk drawers accumulate over time.
The more mature the product the darker the corners and the messier the drawers¹« 

JASON FRIED

Traduites en français, ces phrases signifient : ❝Les coins sombres et les tiroirs à déchets s’accumulent avec le temps. Plus le produit est mature, plus les coins sont sombres et plus les tiroirs sont en désordre❞.

Cela ne vous évoque toujours rien ?

Comme une sensation de déjà vu

Vous vous êtes peut-être déjà retrouvés dans une situation similaire ou adjacente : la roadmap est pleine à craquer, le produit n’est plus conduit par une vision claire et définie mais par des initiatives en silos ayant pour seul objectif la conversion (vendre). Urgent est le maître mot, l’argument d’autorité qui tue la notion de priorisation, le début d’un cercle peu vertueux. Vous accumulez les fonctionnalités lourdes à maintenir, réduisant par la même occasion votre capacité de build. La complexité du code s’accroît. La moindre évolution ou mise en production apporte son lot de régressions. Le run et la correction de bugs occupent toute la bande passante au détriment du discovery. Ce dernier étant pourtant essentiel à la bonne évolution d’un produit dont l’expérience client est déjà entamée par le constat dressé un peu plus haut. De manière concrète cela se traduit souvent par les demandes suivantes. Ou bien des demandes similaires.

« J’ai vu telle fonctionnalité sur le site d’un tel !
Pourrait-t-on avoir la même chose sur notre site avant de prendre trop de retard sur la concurrence ? »

« Le tableau de suivi des commandes personnalisées a encore planté.
Je n’ai pas accès aux données que je dois présenter demain à 14h30 au COPROJ avec le partenaire ! Peux-tu m’aider ? « 

« Nous devons rapidement évaluer l’appétence des nos utilisateurs pour un nouveau service que notre partenaire envisage de lancer. Est-il possible de rajouter un bouton sur la home page ? Un lien sur une page produit ?
Un filtre dans le moteur de recherche ? »

Intrinsèquement ces demandes n’ont rien d’extraordinaires ou de déplacées. Bien au contraire, elles traduisent une intention de mouvement. La volonté de bien faire, et de faire vite. C’est malheureusement là que le bas blesse.
En voulant gagner du temps nous allons prendre des décisions court-termistes motivées par un résultat économique. Ces décisions ne prendront en compte ni l’impact sur le produit en termes de parcours ou d’expérience utilisateur, ni le coût engendré sur le long terme générant ainsi ce qu’on qualifiera de dette produit.

La dette produit, qu’est-ce que c’est exactement ?

Pour répondre à cette question, il faut commencer par expliquer dans un premier temps comment on contracte de la dette produit. Les ressources sur le sujet sont toutes unanimes. La dette produit est contractée par un produit lorsque l’UX de ce dernier commence à devenir mauvaise et cesse en quelque sorte d’être utile alors que c’était le cas auparavant ². Les termes « user experience debt » or « product design debt » ont déjà également été utilisés pour qualifier la dette produit.

Il existe deux types de dette produit :

• Le « trop plein » de fonctionnalités
  • Le produit cumule les nouvelles fonctionnalités sans réelle vision (produit) d’ensemble pour les articuler entre elles. L’impact positif sur l’expérience utilisateur et la satisfaction client ne sont pas démontrés. Il peut même s’avérer négatif sur le long terme en complexifiant l’usage du produit.
    
• Les fonctionnalités personnalisées ou « hacks » d’interface, de données ou de parcours
  • Pour répondre à un besoin ponctuel où une opportunité, le plus souvent émis par les fonctions marketing ou commerciales, on développe une fonctionnalité personnalisée. On modifie le parcours utilisateur ou bien on crée un modèle de données spécifique pour l’occasion. Ou encore le grand classique : on crée un bouton, un lien peu en adéquation avec le tout car pensé à posteriori, qui ne s’intègre pas avec l’ensemble.

Les deux types de dettes précitées vont perturber le travail des développeurs en amont, des effets négatifs en termes de charge supplémentaire qui sera difficile à maintenir dans le temps sont à prévoir. Le risque de répercussion non négligeable sur l’expérience utilisateur dans ces cas là n’est pas à prendre à la légère.

Vers une nouvelle définition de la dette produit ?

Dette produit vs dette technique

Une fois le problème identifié et défini, comment le résolvons nous ? Les recherches que j’ai pu effectuer afin de savoir comment réagir m’ont souvent mené à la dette technique. En effet il y a des similitudes, notamment si on se penche sur les causes (manque de vision produit, décisions court-termistes) et les impacts (difficultés pour faire évoluer le produit ou onboarder de nouvelles ressources).

Quelles sont les différences entre la dette produit et la dette technique me direz-vous alors ?

La dette technique est un compromis sur la qualité en interne, elle va toucher notre capacité à faire, le code. La dette produit est un compromis sur la qualité visible en externe, le plus souvent sur l’interface, par les utilisateurs de notre produit. Par ailleurs elle va plutôt toucher notre raison d’être, l’objectif que l’on souhaite atteindre. S’il s’agit de deux concepts bien distincts, en poussant la réflexion, on finit par s’apercevoir que la dette technique fait partie de la dette produit. Il n’y a pas de raison de les opposer. Rembourser votre dette produit aura certainement un effet bénéfique sur votre dette technique et vice-versa.

En poussant mes recherches plus en avant j’ai fini par tomber sur cette vidéo de Rémi Guyot³ que je vous recommande chaudement. Elle ne parle pas tout à fait de moyens pour lutter contre la dette produit. En réalité elle traitre du combat contre la complexité. Pardonnez moi l’expression en anglais mais « here’s the kicker » ! Qu’elle ne fut pas ma surprise lorsque j’ai réalisé que les corps anti-complexité* que Rémi évoque lors de son talk SONT une partie de la réponse à ma problématique de dette produit.

La dette produit serait donc aussi la complexité inhérente liée à la croissance et la maturation d’un produit. Selon le framework Cynefin la réponse à la complexité se situe dans les méthodes agiles. Or comme j’ai pu le mentionné au début de cette article la dette produit ne touche pas que les organisations produits ou dites « agiles ». C’est à ce cas de figure (situation) en particulier que je m’intéresse ici. Comment traiter la dette produit lorsque je n’évolue pas dans un cadre permettant de faire appel aux méthodes agiles ?

Comment appréhender la dette produit ?

Déconstruire les idées reçues.

La dette produit n’impacte pas que les starts up, les entreprises ayant opté pour une organisation produit ou encore celles utilisant des méthodes dites agiles (Lean Startup, Kanban, Scrum etc.). Même si c’est là en effet que cette problématique sera le plus susceptible d’être évoquée. La dette produit touche toutes les entreprises qui proposent un produit numérique. Et ce indépendamment de leur mode de fonctionnement.

Sensibiliser

Comme nous l’avons vu en amont au sein même cet article si la situation est vécue, ressentie, expérimentée, le plus souvent elle n’est pas verbalisée. Aussi il faut s’assurer que les difficultés rencontrées soient qualifiées, quantifiables, tangibles. C’est uniquement sous ces conditions que l’on pourra aborder une démarche de résolution. L’absence totale de dette produit n’est pas souhaitable, puisqu’elle traduit avant tout cette volonté de mouvement bien que maladroitement exécutée. Pour être complètement honnête elle est surtout inévitable puisque la réalité du terrain ne permet pas de « décorréler » le business du produit et donc ce dernier d’évoluer. Néanmoins avoir conscience de son existence est primordiale et cela reste encore plus facile à dire qu’à faire. Et il n’y a rien de plus ardu que d’agir sur un problème dont toutes les parties prenantes n’ont pas conscience.

Mesurer sa dette produit en se posant les bonnes questions : l’inventaire des fonctionnalités

1. Quelles sont les fonctionnalités indispensables (quel(s) besoin(s) utilisateur adressons-nous, et pour quelle valeur ajoutée) ?
2. Quelles sont les fonctionnalités critiques (quelle quantité de dette produit concédons-nous et pour quelle(s) raison(s)) ?

Les questions listées ne sont pas exhaustives. L’information à retenir est que dresser l’inventaire des fonctionnalités en posant les bonnes questions doit vous permettre de vérifier que votre produit, et donc l’ensemble de ces fonctionnalités, sont toujours en adéquation avec le ou les objectifs que vous souhaitez atteindre. Et c’est là qu’interviennent les fameuses méthodes pour combattre la complexité de Rémi Guyot, comme éléments concret de réponses à ces questions. En effet, définir et prioriser vos objectifs grâce au focus fanatique⁴, ou revoir votre interface à l’aide d’une revue de simplification⁵ ou d’un test d’absence⁶ équivaut ni plus ni moins à vous assurer que notre produit adresse avec l’expérience idoine le besoin de nos utilisateurs / consommateurs.

Casser les silos

Redonner du sens à la collaboration avec vos parties-prenantes en questionnant leurs motivations, leurs besoins, leurs contraintes. Formaliser l’expression et le recueil des besoins de vos parties-prenantes. Les aider à structurer l’expression de leurs besoins sera très utile pour faire le tri entre ce qui est essentiel et ce qui peut-être reporter ou abandonner.

N’hésitez pas à les accompagner autant que faire se peut sur l’expression de leur besoin. C’est à vous et vos équipes techniques de proposer la solution la plus adaptée ou pas s’il n’y en a pas. Cela peut arriver. N’hésitez pas à échanger sur les contraintes que vous rencontrez afin que chacune des parties prenantes puissent jouer son rôle tout en conservant de l’empathie et de la justesse devant les écueils, les retards éventuels ou certaines requêtes prioritaires orientées business.

Penser Holisme

La bonne communication reste toujours une composante clé de la résolution d’un problème quel qu’il soit. La transparence induite par la bonne communication permettra ici d’avoir un regard transverse, une vue d’ensemble, et de comprendre que nous évoluons tous au sein de la même organisation. Conséquemment les problèmes et les frustrations que nous pouvons rencontrer chacun à notre niveau de l’organisation sont très probablement liés. M’aider à garder un produit performant et orienté satisfaction utilisateur t’aidera à développer tes opportunités de business. Accepter la complexité croissante du produit, et y faire face, nous aidera par exemple à rester performant dans notre capacité à tester rapidement la faisabilité technique d’une opportunité business. Il est néanmoins nécessaire de prendre le temps de se mettre d’accord sur comment nous devons procéder. Mieux collaborer permettra de faciliter la résolution des problèmes, voire même d’endiguer leur apparition.

Conclusion

Les produits numériques, prenons les sites de e-commerce par exemple, vont donc générer de la complexité et contracter de la dette produit. Gérer le cycle de vie et l’évolution de ces produits reviendra à anticiper et reconnaître la complexité lorsqu’elle est inévitable. Puis mettre en place des stratagèmes, avec les moyens dont vous disposez, pour l’affronter.

Et vous dans tout ça ?

Bien entendu, les contre-mesures proposées ne sont pas argument d’autorité. Je ne fais que partager ce que j’ai pu tenté afin de résoudre un problème pour lequel l’état de l’art n’était ni exhaustif ni pourvoyeur de solutions concrètes.
Si vous expérimentez une situation ou des difficultés similaires, je serai ravi d’échanger avec vous sur vos expériences.

1 : En anglais dans le texte, citation tirée de cet article de Jason Fried sur la prise de décision en design
2 : En français dans le texte, définition tirée d’une interview sur la dette produit de Leslie Yang par Poornima Vijayashanker
3 : Rémi Guyot, CPO chez BlaBlaCar.
4 : Two lists or 2 lists priorization method en anglais. Méthode de définition et priorisation d’objectifs par Warren Buffet et expliquée au sein de cet article.
5 : Méthodes de revue d’une interface utilisateur très bien expliquée au sein de cet article.
6 : Méthodes de test d’une interface utilisateur très bien expliquée au sein de cet article.