La décision produit la plus importante : ce que tu ne construis pas

Ce que dit la source

L'auteur, qui travaille sur des applications financières grand public, affirme que le choix le plus important n'est pas ce qu'on construit, mais ce qu'on refuse de construire. Il illustre cela par deux pièges classiques : le « document hub » (une sorte de Google Drive interne pour archiver lettres et relevés) et le « centre de notifications » (une boîte de réception de notifications). Ces deux fonctionnalités semblent simples au départ, mais chaque stakeholder ajoute « juste une petite chose de plus », ce qui transforme un prototype rustique en système complexe à maintenir année après année. L'auteur observe qu'il est très difficile de faire renoncer les gens à une idée validée par des focus groups, même quand c'est un piège. Son levier pour convaincre : montrer non pas le coût de construction, mais le coût de maintenance sur plusieurs années. Ce qui tend à ramener les gens à la raison.

• >Le document hub semblait simple (une liste de fichiers à télécharger), mais chaque requête ajoute du tagging, de l'archivage, du partage, de l'impression, chacun avec ses propres règles, plus les enjeux de sécurité et d'authentification pour que le bon utilisateur voie les bons documents.
• >Chaque mise à jour iOS, Android ou web retire discrètement des fonctionnalités utilisées : cela crée une dette de maintenance invisible mais réelle, mois après mois, année après année.
• >Le centre de notifications suit le même chemin : une demande innocente d'une « petite cloche avec un point rouge » devient progressivement un mauvais clone de Gmail avec réglages complexes.
• >L'auteur applique un test unique : « ça fait avancer le bateau ? » Si la réponse est non, il utilise quelque chose de simple ou qui existe déjà, même imparfait, plutôt que de construire une plateforme sur mesure.
• >Les recherches de Gerry McGovern montrent que supprimer 80 à 90 % du contenu d'un site augmente les ventes, réduit les appels support et aide les utilisateurs à trouver ce qu'ils cherchent plus vite.
• >Une étude de Klotz et collègues (Nature) : les gens sous-estiment systématiquement l'utilité des changements soustractifs, même quand c'est objectivement mieux ; les idées additives arrivent vite et bon marché, les soustractives demandent un vrai effort cognitif.

• >Plusieurs commentateurs rapportent que l'enjeu n'est pas technique mais organisationnel : celui qui construit est promu, celui qui supprime est vu comme un tue-la-joie ; une ingénieure note avoir « convaincu des équipes produit et des boards d'abandonner des projets » mais reconnaît que l'équipe IT finit par être le « buzzkill ».
• >Un débat sur l'ambiguïté elle-même : mmonaghan fait remarquer que « qui sait vraiment si une feature « fait avancer le bateau » ? Rarement les ingénieurs seuls. Le produit a son propre jugement, le leadership aussi », ce qui relativise l'autorité de ce test très simple.
• >jongjong ajoute que « l'absence de décision de construire » n'est que la deuxième plus importante ; la première est d'identifier et d'accepter les vraies contraintes du système, souvent invisibles au départ (limitations de données, de traitement, de sécurité), ce qui complique le calcul.
• >Un paradoxe relevé par plusieurs : les LLM accélèrent la construction au point que refuser devient un défi inverse ; bob1029 suggère plutôt de « construire le truc pourri en 90 minutes pour prouver qu'il ne faut pas le construire vraiment ».
• >ungreased0675 pose la question pratique : une fois que tu as dit non, comment garder non ? L'idée revient toujours : lors de réunions de brainstorming, lors d'appels de vente, elle se glisse dans le sprint pendant les vacances du PM.
• >pedalpete souligne que les utilisateurs ont des attentes installées (hypnogrammes et score de sommeil, même si peu utiles) ; changer ça n'est pas facile : c'est ce qu'on attendrait d'un produit.