Nous parlons beaucoup des lancements. Peu des arbitrages.
Les articles produit racontent volontiers les lancements, les pivots stratégiques, les nouvelles fonctionnalités. Ils passent sous silence les centaines de micro-décisions qui façonnent l’expérience quotidienne.
Je suis Product Manager de Curebot et cet article est une tentative de rendre visible ce qui se passe quand il faut trancher entre deux options défendables, quand une contrainte technique bouscule une intuition design, quand simplifier risque de casser ce qui comptait.
Livrer maintenant, pas “quand on aura le temps”
Pour beaucoup d’organisations, la newsletter est le dernier kilomètre de la veille. C’est le moment où l’information collectée, triée, enrichie atteint enfin son destinataire. Un dirigeant qui ouvre sa newsletter à 7h. Une équipe projet qui reçoit sa synthèse hebdomadaire. Un analyste qui diffuse ses alertes aux décideurs.
Cette intensité d’usage impose une exigence particulière. Chaque irritant, même mineur, se répète des centaines de fois par jour à l’échelle de nos utilisateurs. Ce sont des milliers de clics perdus à l’échelle d’un mois pour un bouton mal placé.
Nous aurions pu attendre une refonte majeure pour regrouper les optimisations dans un chantier plus ambitieux. C’est le réflexe naturel des équipes produit. C’est aussi un piège.
J’ai vu trop de roadmaps où les « améliorations d’expérience » attendent indéfiniment une « V2 » qui ne vient jamais parce qu’il y a toujours un sujet plus urgent, plus visible, plus valorisant à traiter. Pendant ce temps, l’écart se creuse entre ce que l’outil fait et ce qu’il pourrait faire.
La dette d’expérience fonctionne comme la dette technique. Elle s’accumule silencieusement et se paie avec intérêts. Mais là où la dette technique se mesure en temps de développement, la dette d’expérience se mesure en attention gaspillée et en frustration générée.
Nous avons choisi de livrer maintenant des améliorations tangibles. Ce choix a un coût car il nous engage sur une trajectoire et contraint les évolutions futures à s’inscrire dans l’existant. Mais les utilisateurs qui passent des heures chaque semaine dans l’éditeur de newsletter voient leur quotidien s’améliorer aujourd’hui, pas dans six mois, pas « quand nous aurons le temps ».
Arbitrage n°01 : Soustraire plutôt qu’ajouter. Quand deux champs deviennent un seul.
L’ancienne version de l’éditeur de newsletter proposait deux champs pour enrichir une ressource : un champ “titre” et un champ “contenu”. En analysant les sessions d’utilisation, nous avons constaté que le champ “titre” restait vide dans la majorité des cas. Les utilisateurs ne savaient pas quoi y mettre ou ne percevaient pas la distinction avec le champ “contenu”.
La demande explicite que nous recevions était “plus de possibilité pour structurer le contenu”. La réponse évidente aurait été d’ajouter de nouvelles options de formatage, des boutons de mise en forme ou de proposer un éditeur encore plus riche. C’est ce que font la plupart des outils quand les utilisateurs demandent « plus ».
Nous avons fait l’inverse. Nous avons supprimé un champ.
Les deux champs sont devenus un seul. Les utilisateurs structurent leur texte avec la syntaxe Markdown et peuvent utiliser les croisillons (#) pour ajouter les titres. Ceux qui veulent juste écrire un paragraphe écrivent un paragraphe. Ceux qui veulent structurer leur contenu disposent de toute la puissance du Markdown sans leur imposer des boutons qu’ils n’utiliseront pas.
Pour cause, chaque élément d’interface a trois coûts invisibles :
- Un coût cognitif pour l’utilisateur (une option de plus à comprendre, une décision de plus à prendre)
- Un coût technique pour l’équipe (un comportement de plus à maintenir, à tester, à documenter)
- Un coût stratégique pour les évolutions futures (une contrainte de plus dans chaque évolution ultérieure)
Un bouton ajouté aujourd’hui, c’est un bouton à maintenir demain, à expliquer dans la documentation, à justifier dans chaque audit d’interface.
Cette décision va à contre-courant d’une intuition répandue dans le produit. Nous avons tendance à penser qu’un logiciel progresse en ajoutant des fonctionnalités, que la valeur se mesure au nombre d’options disponibles, que simplifier c’est régresser. Saint-Exupéry écrivait que la perfection est atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher. C’est exactement la logique qui a guidé cet arbitrage : en supprimant un champ, nous n’avons rien retiré aux utilisateurs. Nous avons retiré ce qui se mettait entre eux et leur contenu.
En réalité, moins de surface d’interface, c’est plus de puissance d’expression et plus d’adoption.
Arbitrage n°02 : Peu utilisé ne veut pas dire peu important.
Unifier les deux champs posait un problème que je n’avais pas anticipé.
L’ancien champ « titre » permettait d’appliquer une couleur personnalisée. En le supprimant, l’option disparaissait. Ma première réaction a été de considérer cette régression comme acceptable. Après tout, c’était un détail cosmétique utilisé par une minorité.
Le retour terrain :
“Quand je diffuse à des dirigeants qui passent 30 secondes sur ma newsletter, les repères visuels sont indispensables.”
Il avait raison. Les utilisateurs chartent leurs livrables aux couleurs de leur organisation ou de leur projet. La couleur des titres distingue le contenu éditorialisé du contenu brut, créée des repères visuels pour les destinataires et renforce l’identité de la newsletter. Pour un utilisateur qui passe du temps à concevoir sa newsletter, ce n’est pas cosmétique, c’est fonctionnel.
Ce retour illustre un biais fréquent en product management : confondre « peu utilisé » et « peu important ». Une fonctionnalité peut concerner 15% des utilisateurs et être décisive pour eux. La bonne question n’est pas combien l’utilisent, mais ce qui se passe pour eux si elle disparaît.
La solution retenue préserve la personnalisation et étend ses possibilités. Chaque niveau de titre Markdown (titre principal, sous-titre, titre de niveau trois) dispose désormais de son propre sélecteur de couleur dans les paramètres de design. L’utilisateur structure son contenu normalement et le rendu respecte automatiquement la charte définie.
Cet arbitrage rappelle qu’une simplification réussie réorganise les capacités sans les supprimer. Le nouveau système expose moins de surface (un seul champ au lieu de deux) et amplifie la puissance d’expression pour celles et ceux qui en ont besoin.
Arbitrage n°03 : “Aller vers” plutôt que “Revenir à”
Ce cas mérite que l’on s’y attarde parce qu’il montre comment une question technique peut invalider une intuition design et produire une solution meilleure.
Certaines newsletters Curebot ont plusieurs années d’existence et des centaines d’éditions publiées. Nous devions repenser la navigation entre l’édition en cours, l’historique et les statistiques. Chaque vue dispose désormais de sa propre page.
Je me suis demandé comment permettre à l’utilisateur de circuler entre ces pages et notamment de remonter la hiérarchie. Ma première spécification prévoyait un bouton « Retour ». C’est le pattern universel que tout le monde comprend.
L’équipe technique m’a posé une question qui semblait triviale : “Retour vers où ?”
Un bouton « Retour » suppose de connaître l’origine. D’où vient l’utilisateur ? De l’historique ? Des statistiques ? D’un lien partagé par un collègue ? Pour que « Retour » ait un sens, le système doit tracer le parcours. Cela implique de maintenir un état de navigation côté client, de gérer les cas où l’historique est vide et multiplie les cas limites à gérer.
Ma spécification avait l’air simple côté interface mais exportait toute la difficulté vers le code.
Une discussion a fait émerger une règle plus robuste : Un bouton doit « Aller vers » plutôt que « Revenir à ».
La différence est fondamentale.
- « Aller vers » est déterministe. Quelle que soit l’origine, la destination est connue.
- « Revenir à » est contextuel. La destination dépend du chemin parcouru, et le chemin, on ne le maîtrise pas toujours.
Plutôt qu’un bouton “Retour” générique, la solution retenue expose des actions explicites vers les destinations possibles. Depuis la page de l’édition en cours → bouton « Historique ». Depuis la page de l’historique → bouton « Prochaine édition ».
Nous retrouvons cette logique dans les autres pages. Il n’y a pas d’ambiguïté, pas de comportement conditionnel, pas de mauvaise surprise. L’utilisateur sait toujours où il va. Le système n’a pas besoin de savoir d’où il vient.
Un Product Manager qui a toujours raison dans ses spécifications est un PM qui ne laisse pas assez d’espace à l’équipe. Les meilleures décisions produit émergent quand le problème est posé clairement et que la solution reste ouverte. Ce jour-là, nous avons démontré la valeur du dialogue entre Product et Engineering en co-construisant une solution meilleure que ce que j’avais imaginé seul.
Arbitrage n°04 : Afficher ce qui compte, masquer la mécanique interne.
Une newsletter traverse de nombreux états avant d’atteindre ses destinataires : en construction, verrouillée après un test, programmée, en cours d’envoi, envoyée…
L’ancienne interface reflétait fidèlement cette complexité. Les informations étaient dispersées dans trois blocs distincts. Pour savoir si une newsletter partirait bien le lendemain à 7h, l’utilisateur devait inspecter chaque zone et reconstituer le puzzle mentalement. Une newsletter programmée mais non verrouillée peut encore être modifiée par erreur. Une newsletter verrouillée mais non programmée ne sera pas expédiée.
Nous aurions pu réduire les combinaisons possibles ou forcer un parcours linéaire. Nous avons écarté ces pistes parce qu’elles supprimaient des usages légitimes. Certains utilisateurs verrouillent leur contenu des jours avant l’envoi. D’autres testent plusieurs fois sans jamais programmer. D’autres encore programment d’abord et ajustent ensuite.
La solution retenue est l’utilisation d’un composant unique affiche l’état consolidé de la newsletter et un badge coloré indique la situation en un coup d’œil. Une description répond aux deux questions que se pose l’utilisateur : qu’est-ce qui va se passer ? et qu’est-ce que je peux encore changer ?
La complexité interne du système n’a pas diminué mais elle n’est plus le problème de l’utilisateur.
Calibrer le ratio entre gains immédiats et gains structurels.
Toute refonte produit n’est pas une liste d’améliorations. C’est une allocation de ressources rares (temps de développement, attention de l’équipe, capacité d’absorption du changement côté utilisateurs) vers des gains qui ne se manifestent pas au même horizon.
Chaque décision est un arbitrage d’investissement.
- Les gains immédiats répondent à : “Qu’est-ce qui a changé pour moi ?” Une navigation explicite, des zones de clic plus claires, des statuts lisibles d’un coup d’œil… Ces gains se perçoivent dès la première session. Ils construisent la confiance que le produit évolue, que l’équipe écoute, que l’outil s’améliore.
- Les gains structurels répondent à une question que des utilisateurs ne posent jamais : “Qu’est-ce qui sera possible demain que vous ne pouviez pas faire hier ?” Pour ne citer qu’un seul exemple, l’unification décrite précédemment pose les fondations pour mettre en capacité chaque utilisateur d’expliciter pourquoi une information est importante, pas seulement de la relayer. Ces gains ne se voient pas. Ils se mesurent en vélocité retrouvée, en fonctionnalités rendues possibles, en options ouvertes pour les arbitrages futurs.
Sur cette refonte, nous avons alloué environ 60% de l’effort aux gains immédiats et 40% aux gains structurels. Ce ratio n’est pas une formule. Un autre contexte aurait produit un autre ratio. Un produit en reconstruction profonde peut justifier 20/80 en faveur du structurel. Un produit en phase de conquête commerciale peut exiger 80/20 en faveur de l’immédiat.
Ce qui compte, ce n’est pas le chiffre. C’est de prendre cette décision explicitement, comme un choix stratégique, pas comme un compromis subi.
L’équipe qui ne pose pas cette question subit le ratio, généralement déséquilibré vers l’immédiat parce que c’est ce qui se voit. Elle accumule une dette structurelle invisible jusqu’au jour où une évolution « simple » prend trois mois et personne ne comprend pourquoi.
Ce que ces arbitrages révèlent de notre façon de construire.
Ce travail ne fera pas de bruit. C’est un travail invisible dans une démonstration commerciale, impossible à mettre en avant dans un comparatif de fonctionnalités et ne déclenchera pas d’articles dans la presse spécialisée. Mais c’est ce travail qui évite à un utilisateur, un vendredi soir, de se demander si sa newsletter du lundi est vraiment prête à partir.
C’est précisément ce qui le rend précieux.
Chaque friction éliminée aujourd’hui, c’est une question que l’utilisateur ne posera pas demain. Chaque dette technique remboursée, c’est une fonctionnalité future qui prendra deux semaines au lieu de deux mois. Chaque pattern clarifié (comme « Aller vers » plutôt que « Revenir à »), c’est une règle de conception qui accélère toutes les décisions suivantes.
Notre roadmap contient désormais des chantiers que nous n’aurions pas pu envisager avec l’ancienne architecture. Dans un an, nous aurons oublié que ces frictions existaient. C’est le paradoxe du travail bien fait : il disparaît sous l’évidence de ce qu’il permet.
Le métier de Product Manager, au fond, c’est décider aujourd’hui de ce que l’équipe pourra construire dans dix-huit mois. Ce travail était un investissement sur notre capacité future. Ce n’est pas une promesse, c’est un pari et les prochains cycles de développement diront si nous avions raison.
En attendant, les évolutions décrites ici sont disponibles. Le cycle suivant attend vos retours.
