La confiance perdue (Lost confidence)

• Les frameworks de priorisation fondés sur la confiance, comme RICE, sont pour la plupart du bruit ; il faut une façon de décider sans faire semblant de connaître un avenir inconnaissable
• Les scores de confiance étant élevés pour les (petits) projets de ce type et faibles pour les grands (large) projets, ils écartent systématiquement les projets à forte valeur et biaisent les priorités
• Les scores de confiance sont peu fiables : leur définition est floue, les données de validation manquent, les projets prennent toujours du retard et leur impact est inférieur aux attentes
• La solution consiste à se placer non pas dans le domaine des probabilités (probability), mais dans celui de l’incertitude (uncertainty), en se demandant : « quelle action est judicieuse quelle que soit la distribution de probabilités ? »
• Au lieu de la confiance, il est important de prioriser avec des techniques comme ce qui est toujours vrai, l’impact client, la préservation d’options et les paris asymétriques

---

Les jeux de confiance (Confidence games)

• Beaucoup de frameworks de priorisation intègrent dans leur score la confiance dans le fait de produire l’impact prévu avec l’effort prévu
  • Entre deux projets de même valeur et de même effort, choisir celui dont l’exécution inspire le plus confiance est en soi rationnel
  • Mais, en pratique, ce n’est pas ainsi qu’ils sont utilisés : « 1) attribuer un score → 2) exécuter le vainqueur clair → 3) en cas d’égalité, choisir celui qui inspire le plus confiance »
• RICE multiplie directement la confiance dans la formule de calcul du score dès la première étape
  • Formule RICE : Score = (Reach × Impact × Confidence) / Effort
  • Formule RPS : Score = Reach × Potential × Solution Confidence
• Cette approche traite deux scénarios différents comme équivalents et crée une fausse équivalence
  • Une petite fonctionnalité incrémentale, certes réalisable
  • Une grande fonctionnalité à fort impact, mais comportant des risques
• Comme la confiance est généralement élevée pour les petits projets et faible pour les grands, la multiplier revient à s’éloigner systématiquement de la maximisation de la valeur livrée
  • L’une des motivations centrales du mouvement Agile était précisément l’intuition selon laquelle « la réussite des grands projets doit toujours être associée à une faible confiance »
• Raisons de ne pas croire aux scores de confiance
  • Définition floue : on ne sait pas clairement ce que signifie « 30 % ». En principe, il faudrait enregistrer les scores de confiance de tous les projets et les comparer aux résultats réels pour en calculer l’exactitude, mais ce n’est pas ce qui se fait en pratique
  • Si l’on ne lance chaque année qu’un petit nombre de fonctionnalités majeures, il manque même, a posteriori, les données nécessaires pour les vérifier
  • Les projets sont presque toujours en retard, et leur impact est plus faible et plus lent que prévu. Même un projet de 9 mois mobilisant 6 équipes a été lancé parce qu’il inspirait « un certain niveau de confiance »
• Citation de la loi de Hofstadter : « Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter »
• Demandez à un PM expérimenté de citer une fonctionnalité dont il était « certain qu’elle serait bien accueillie » et qui ne l’a pas été : chacun aura plusieurs exemples
  • Même avec des éléments comme des discussions clients, des demandes explicites ou des promesses d’achat, une fois la fonctionnalité construite, même les personnes qui avaient promis l’utilisent rarement
  • Technique pour améliorer les prévisions : demander au client d’expliquer étape par étape comment il l’utiliserait dans son workflow réel. En déroulant les étapes, il finit parfois par réaliser lui-même : « cela m’obligerait à réécrire du code, donc je ne le ferai pas »
• Il en va de même pour les créateurs de contenu : un texte publié à la hâte sans grandes attentes peut obtenir les meilleures vues et réactions de l’année, tandis qu’une pièce maîtresse travaillée pendant des dizaines d’heures peut être ignorée
  • Les quatre cases du tableau 2×2 « confiance ou non × résultat (adoré/indifférence) » regorgent toutes d’exemples

Que faut-il utiliser à la place de la confiance et du risque ? (What to use in place of confidence and risk)

• La réponse se trouve dans le domaine de l’incertitude (uncertainty), pas des probabilités
  • La probabilité suppose que l’on connaît la distribution. Pour 100 lancers d’une pièce équilibrée, on peut prédire qu’il est très probable d’obtenir entre 40 et 60 faces
  • Presque tout dans une startup est différent. La réussite, la stratégie et les fonctionnalités sont sans précédent, trop complexes ou dépourvues de variables d’entrée assez précises pour qu’on puisse leur attribuer une probabilité significative
  • Le concept d’« incertitude knightienne (Knightian Uncertainty) » vient de l’ouvrage de 1921 de l’économiste Frank Knight
  • Les méthodes bayésiennes nécessitent aussi des probabilités a priori numériques et des probabilités conditionnelles ; or les deux sont inconnues et impossibles à définir
• La question dans le domaine de l’incertitude est : « Quelle action est judicieuse indépendamment de la distribution de probabilités ? »

• Ce qui est toujours vrai (True always)

  • Se concentrer sur ce qui reste vrai dans toutes les situations — le principe des constantes de long terme (long-term constants) de Bezos
    • Les utilisateurs préfèrent universellement les logiciels rapides et réactifs. Ils accordent de la valeur à la synchronisation en arrière-plan, aux interactions instantanées et au fonctionnement sur tous les appareils
    • Dans le pire des cas (s’ils sont indifférents à la vitesse), ils ne la verront pas négativement. Dans le meilleur des cas, comme pour Notion, Figma, Miro, Gmail ou Google Docs, la performance devient un facteur clé de différenciation
  • Toutes les fonctionnalités n’ont pas un attrait universel. Plutôt que de décomposer des chiffres avec précision, il faut identifier les fonctionnalités que pratiquement tous les clients jugeront utiles, ou au minimum apprécieront
    • Parfois, la certitude vient du fait qu’il s’agit d’une obligation. Les exigences enterprise comme la conformité SOC 2 ne sont pas passionnantes, mais elles ont assurément de la valeur pour vendre aux grandes entreprises
    • Ce type de certitude compense l’absence de différenciation
  • Cependant, les idées les plus innovantes et différenciantes appartiennent rarement à la catégorie de ce qui est « absolument certain »
    • Ce qui est certain a de la valeur, mais devient difficilement un élément de différenciation stratégique
    • Un excellent produit a besoin à la fois d’améliorations fiables et de sauts innovants

• Découverte rapide, récupération rapide (Quick discovery, quick recovery)

  • L’auteur défend depuis longtemps l’idée d’interviewer systématiquement des clients potentiels avant de construire, afin de valider une idée ; mais cela aussi tombe dans le « piège de la confiance »
    • On ne peut jamais savoir avec certitude avant d’avoir construit
    • En revanche, avant de construire, il est possible d’invalider une idée, ce qui peut éviter des mois ou des années de gaspillage ; cela reste donc le bon point de départ
  • La solution typique consiste à construire un SLC (un concept qui améliore le MVP) — un produit simple mais complet permettant d’obtenir de vrais retours, fondés sur l’expérience plutôt que sur la prédiction
    • Un produit existant maintient un portefeuille équilibré entre victoires certaines et paris innovants, en appliquant à chacun des méthodes de validation différentes
  • Exemple de « fonctionnalités factices (dummy features) » : un bouton qui, lorsqu’on clique dessus, affiche « cette fonctionnalité n’existe pas encore. Dites-nous comment vous l’utiliseriez »
    • Cela fournit un signal réel, fondé sur le comportement, sur le nombre d’utilisateurs intéressés et les personnes à interviewer
    • C’est un signal 100 fois meilleur qu’un sondage. Il est facile de répondre « oui » dans un sondage, mais une action comme cliquer sur un bouton exige un intérêt réel. Le comportement observé l’emporte sur l’intention déclarée

• Se concentrer sur l’impact client plutôt que sur la confiance (Focus instead on customer impact)

  • Remplacer la confiance par l’impact. L’impact se définit de deux façons
    • Règle de la majorité (Majority rule) : une fonctionnalité utilisée régulièrement par une majorité d’utilisateurs est clairement importante et constitue probablement une raison clé d’adoption et de rétention
    • Défenseurs passionnés (Passionate advocates) : une fonctionnalité qui crée des fans passionnés chez une minorité. Des personnes qui disent : « je l’ai acheté uniquement pour ça ». Elle n’est pas universelle, mais suscite une fidélité profonde dans un segment donné (« magnificent delighters »)
  • Lorsqu’un utilisateur aime sincèrement une partie précise du produit, il tolère d’autres défauts
    • Grâce à l’attrait de l’iPod, des milliards de personnes ont supporté iTunes, le pire des logiciels
    • Un logiciel magnifiquement conçu peut être accepté malgré des fonctionnalités manquantes ou des limitations de plateforme, uniquement grâce à l’expérience de design
  • Définition quantitative d’une fonctionnalité à fort impact
    • (1) au moins 51 % des clients l’utilisent régulièrement, ou
    • (2) au moins 15 % des clients la citent parmi les 3 principales raisons de leur choix ou de leur fidélité
    • Le seuil est élevé, mais les fonctionnalités innovantes et risquées méritent un seuil élevé : l’ampleur de la récompense doit justifier le risque

• Investir dans le levier (Invest in leverage)

  • Il existe des domaines où de petits changements incrémentaux produisent de grands résultats
  • Il existe des domaines de levier qui se vérifient presque toujours mathématiquement et structurellement
    • (partie promotionnelle liée à un livre exclue comme publicité)

• Maximiser l’optionalité (Maximize optionality)

  • Si l’on ne peut pas connaître l’avenir, on fait le choix qui maximise le nombre d’options disponibles une fois arrivé à destination
    • Au-delà de la simple flexibilité ou de l’évitement du lock-in, il s’agit de concevoir de façon à pouvoir gérer ce qui émergera
  • Exemples
    • Maintenir des coûts bas → préserver la rentabilité tout en permettant diverses expérimentations de prix et de packaging, ainsi qu’une résilience future
    • Choisir une bibliothèque UI ou un framework multiplateforme bien validé et activement développé → s’adapter à l’évolution des plateformes et des appareils
    • Architecture de plugins → permettre à soi-même et à la communauté de construire des choses qu’on n’imagine pas encore aujourd’hui
    • Architecture API-first → isoler les équipes et relier front-end, back-end et intégrations clients
    • Wrapper autour de services fournisseurs → pouvoir remplacer un fournisseur instable, coûteux ou dépassé
  • Préserver des options futures exige du travail supplémentaire aujourd’hui
    • Une API qui encapsule un fournisseur n’apporte pas de valeur immédiate aujourd’hui
    • C’est judicieux pour une entreprise mature, où stabilité et prévisibilité comptent, mais cela peut être un mauvais choix au stade initial, quand il faut battre les acteurs établis par la vitesse
  • La manière de maximiser les options de l’entreprise dans son ensemble consiste à construire une excellente entreprise
    • Une croissance saine et durable, des marges brutes importantes et en expansion, l’amour des clients prouvé par la rétention, les upgrades et le bouche-à-oreille, l’amour des employés prouvé par l’ancienneté et l’évolution de carrière
    • Une excellente entreprise dispose de nombreuses options : acquisition, indépendance, financement, IPO, succession, etc.

• Portefeuille de paris (Portfolio of bets)

  • Un portefeuille réduit la volatilité, mais réduit aussi le potentiel maximal à la hausse
    • La probabilité de n’avoir aucune victoire est faible, donc le downside n’est pas trop mauvais ; mais comme les victoires doivent compenser les pertes, même les rares gros succès ne sont pas aussi importants que dans un pari unique
    • Analogie : acheter Amazon lors de son IPO et le conserver pour toujours aurait été idéal, mais appliquer la même stratégie à d’autres IPO de la même année aurait pu finir à 0 $. Un portefeuille ne tombe pas à zéro, mais sa croissance maximale est bien inférieure à celle de la meilleure action
  • Encadré mathématique : si les portefeuilles fonctionnent indépendamment de la distribution, c’est grâce au théorème central limite (Central Limit Theorem)
    • Si l’on tire à plusieurs reprises N échantillons dans une population à distribution stable mais inconnue et que l’on trace l’histogramme de la moyenne des échantillons, cette distribution converge vers une gaussienne (distribution normale), avec pour moyenne la moyenne de la population et pour variance la variance de la population divisée par n
    • Le TCL de Lindeberg–Lévy montre que cela reste vrai même si chaque échantillon provient d’une distribution différente, sous réserve d’indépendance, de variance finie et d’absence de domination par une seule variable
    • Toutefois, dans les distributions fréquentes en environnement startup, ces conditions peuvent être violées (certaines lois de puissance ont une variance infinie)
  • Les portefeuilles fonctionnent quand on veut des résultats prévisibles mais ordinaires, pas quand on cherche des outliers
    • Exemple des portefeuilles de venture capital et d’angel investing : 65 % perdent de l’argent, et environ 10 % seulement génèrent un rendement justifiant le risque et l’illiquidité
    • Lorsqu’on vise des outliers, il faut non pas un portefeuille, mais un investissement all-in (car la distribution des rendements des startups suit une power law qui viole les critères de Lindeberg)
  • Conclusion : si l’objectif de priorisation est de trouver une différenciation de marché et un moteur de croissance, le portefeuille est le mauvais outil. Il convient aux petits résultats incrémentaux et fiables, auquel cas il n’y a pas besoin de débattre de la confiance

• Paris asymétriques (Asymmetric bets)

  • Le pendant naturel du portefeuille. Si le portefeuille vise la fiabilité, les paris asymétriques visent les outliers
    • Il ne s’agit pas de prédire si le pari réussira ou échouera, mais de prendre des paris dont le downside est limité et quantifié, tandis que l’upside est important
  • Si le pire scénario est « 2 mois perdus » et le meilleur « une différenciation totale », alors les probabilités ont très peu d’importance
    • Il suffit que le downside soit supportable et que l’upside soit suffisamment important pour qu’une seule victoire compense dix pertes
    • On ne peut pas connaître les probabilités exactes, mais on peut connaître la forme (shape) de chaque pari
  • Les paris asymétriques au niveau stratégique ont généralement une forme déjà déterminée (un nouveau marché où les recommandations composées s’accumulent, un moat qui se renforce à mesure que l’on vend)
    • Au niveau des fonctionnalités, il faut construire soi-même l’asymétrie. La forme par défaut d’un projet logiciel a tendance à dériver de « 2 semaines » à « 2 mois » puis à « cela a pris trop longtemps, il faut bien terminer »
    • Le mécanisme consiste à écrire le budget avant de commencer : « 2 ingénieurs, 3 semaines, puis on s’arrête et on réévalue ». Le timebox est le downside limité
  • Une autre approche consiste à remplacer la confiance par « à quel point ce pari est-il asymétrique ? »
    • RICE demande d’estimer une probabilité dont on reconnaît qu’elle est inconnaissable
    • L’asymétrie pose deux questions réellement estimables : le pire scénario en temps et en coût, et le meilleur scénario en valeur client. Les deux sont concrets, et si l’on limite tous les chiffres à des puissances de 10, on peut converger en réunion vers des nombres acceptables

Conclusion

• Arrêter de faire comme si l’on pouvait quantifier ou définir la confiance
• Utiliser plutôt des techniques qui fonctionnent chaque fois que l’avenir est imprévisible — car l’avenir est toujours imprévisible

[hmmhmmhm]

« Utiliser plutôt des techniques qui fonctionnent chaque fois que l’avenir est imprévisible, car l’avenir est toujours imprévisible » — c’est excellent.

[spilist2]

C’est un excellent article.