Achat d’un nouveau Mac ce week-end, j’avais besoin d’un nouvel ordinateur avec mon départ de L’Oréal qui approche 😃
Aujourd’hui c’est une édition un peu différente des autres. Plutôt que de creuser un sujet théorique comme dans les précédentes, j’aimerais faire plus court et plus efficace. Avec un sujet qui me tient à coeur : des principes mobilisables pour aider sa prise de décision.
Merci de me lire 🙏 Inscris-toi pour ne pas rater les prochaines éditions 💪
Quel intérêt à ces principes ?
Pour une raison assez simple : la prise de décision est cruciale dans la vie professionnelle. En particulier quand on travaille dans la tech. Je pense que le succès d’un produit découle toujours de la somme d’un immense nombre de décisions prises par les personnes qui l’ont construites.
→ Pour certaines, on sait sur le moment qu’elles vont compter et qu’il faut les prendre avec soin. → Pour d’autres, on ne s’en rend compte qu’après coup. Longtemps après, lorsque leurs effets se manifestent on comprend que “c’est là que ça s’est joué”.
Pourtant, ce qui est difficile, c’est que quand il s’agit de prises de décision, chaque situation est différente. Tel élément dans un contexte sera une force. Tel autre te tirera vers le bas. Aussi, il n’y a pas de solution facile pour “prendre toujours les meilleures décisions”. Même dans un domaine comme la tech, où on dispose d’une documentation hyper riche. Il n’y a pas 1 manière unique, efficace de toujours bien s’en sortir.
Alors pour moi, la meilleure solution est d’investir sur des principes structurants → Afin d’avoir des clés de lecture pour analyser chaque situation. → Afin également de pouvoir guider la décision quelque soit le contexte.
Ce n’est pas une solution absolue. Mais les 5 principes que je vais présenter, m’ont aidé à plusieurs reprises à m’orienter vers la bonne décision. Plus qu’une grille à appliquer, ce sont des inspirations qui m’imprègnent au quotidien. C’est d’ailleurs d’autant plus important parce que comme on l’a vu. Une bonne partie des décisions importantes ne sont pas identifiées comme telles sur le moment.
Principe 1 : résoudre un problème > construire quelque chose
Pourquoi ce principe
C’est probablement un des principes les plus forts. Il dépasse largement à la fois le champ de la tech. Mais aussi la discipline du Product Management pour s’étendre aux sales, à l’UX Design, au Growth, au marketing…
C’est un mantra qu’on répète souvent mais qui se révèle parfois difficile à appliquer de manière continue et répétée dans le temps. Tout créateur a un côté artiste. Il aime créer pour le plaisir de créer. Et une fois son oeuvre finie. il se satisfera toujours de la simple contemplation de son oeuvre.
Toutefois il faut être lucide : quand on travaille dans la tech, le fruit de notre travail doit servir à quelque chose, apporter de la valeur à quelqu’un. C’est une obligation pour deux principales raisons : → D’abord parce que c’est le mandat qui nous est donné. Personne ne nous paye pour construire des solutions inutilisables ou inutilisées. Le temps qui nous est alloué, doit être investi pour générer de la valeur. → Ensuite parce que l’impact de la tech est énorme sur notre monde. Il y a des enjeux significatifs à ce que nous faisons. Refuser de vouloir s’attaquer à ces enjeux et refuser de rechercher cet impact serait pour moi une faute éthique.
D’où cette obsession pour les problèmes. Là où il y a un problème douloureux, il y a potentiellement un produit exceptionnel à créer. Un produit qui sera beau, agréable à construire évidemment. Mais avant tout, un produit qui rendre meilleure l’existence de ses utilisateurs.
Cela veut aussi dire que la forme que prend cette résolution au problème importe moins que le fait même de le résoudre. La solution n’a même pas forcément vocation à être technologique tant qu’elle arrive à apporter cette valeur.
💡 Par exemple, les nudges sont une solution innovante et non technologique au problème de la saleté des lieux publics
Vous avez peut-être déjà vu des petites mouches comme celle ci-dessus dans un urinoir. C’est ce qu’on appelle un “nudge” (ou coup de pouce). L’idée est de sensibiliser les visiteurs de ces toilettes à l’importance de les garder propre. La fausse mouche réussit très bien à pousser cette idée. En la voyant, on arrive à se projeter dans des toilettes sales - dans lesquelles il y aurait des mouches. En comprenant que ça serait désagréable, on est plus vigilant en termes d’hygiène.
Cela montre bien qu’on peut trouver des solutions pas forcément high tech ou poussées au niveau techniques. Le tout est de garder un esprit ouvert.
Si vous voulez creuser le sujet, j’ai trouvé cet article intéressant.
En pratique
Pour renforcer cette “éthique du problème”.
Être curieux, s’ouvrir au monde en particulier auprès de son utilisateur cible. S’embarquer dans une construction sans fin de son produit sans plus penser au problème qu’il résout est souvent lié à un isolement du constructeur. Isolement à la fois mental, puisqu’il n’a plus cette préoccupation pour le “bénéficiaire” du produit. Isolement aussi physique - géographique, parce que le simple fait de se déplacer et de voir cet utilisateur, permet justement de sortir de ce cycle sans fin.
Connaître les interlocuteurs qui vont nous emmener plutôt côté problème ou plutôt côté solution. De mon expérience, les profils UX Designer ou architectes ont très souvent une posture orientée problème. Cela peut les faire passer pour des “rabats-joies” qui veulent éviter de lancer des développements ! Bien au contraire, ils veulent juste lancer les bons développements. De l’autre côté du spectre, les développeurs et les sponsors ont en général un biais très fort orienté vers la construction de la solution. Les développeurs par déformation professionnelle. Les sponsors parce qu’une solution est tangible, montrable. Ce qui leur permet de mieux répondre à leurs enjeux de visibilité. Plus que l’identification ou la compréhension d’un problème.
Enfin une dernière précision : cela ne veut pas dire que construire la solution n’est pas importante. À vrai dire, construire cette solution est tout l’objectif. Justement, tout l’enjeu c’est de s’assurer que ça soit la bonne solution. Et pour cela, pas de secret. Il faut d’abord saisir le problème qu’on veut résoudre.
Principe 2 : créer un produit exceptionnel = le distribuer exceptionnellement
Pourquoi ce principe
Ce deuxième principe est relié au premier. En tout cas, ils partagent la même cause, à savoir le biais du constructeur ou de l’artiste. Quand ce dernier privilégie la construction pour elle-même et non pas pour ce qu’elle apporte aux autres et en particulier à l’utilisateur cible.
Pour autant, la manifestation n’est pas la même ici. En l’occurence, le souci ne va pas être au niveau du fait que le produit répond bien à un problème clair, dur et douloureux. Faisons l’hypothèse que c’est le cas. Le deuxième principe nous sensibilise sur le fait que même si ton produit est exceptionnel… il te faut aussi le distribuer de manière exceptionnelle.
Qu’entend-on par distribuer ? Tout ce qui va avoir vocation à aider à “vendre” le produit au sens large : → Les actions pour augmenter la visibilité du produit → Les actions pour aider les prospects à passer à l’achat → Les actions pour renforcer l’usage du produit par les prospects
Lorsqu’on construit un produit, notamment pour des profils “ingénieurs”, on a tendance à sous-estimer la partie vente. Pour deux raisons : → 1️⃣ d’abord parce qu’on n’a pas cette compétence ! Donc lancer des actions pour lesquelles on n’a pas la compétence est difficile, nous fait sortir de notre zone de confort etc… → 2️⃣ ensuite parce qu’on fantasme sur le fait que notre produit est tellement exceptionnel qu’il va se répandre comme une traînée de poudre et que tout le monde va vouloir l’utiliser spontanément.
En fait, évidemment, cela ne se passe jamais comme ça. On sous-estime souvent trop l’importance de parler de notre produit et d’en vanter ses qualités parce qu’on sur-estime sa qualité.
C’est important de se poser des questions de distribution du produit de manière précoce dans la vie du produit. En fait dès qu’on commence à travailler dessus pour deux raisons : → Premièrement, ce genre de questions va nous aider pour la construction du produit également. En me demandant comment trouver mes clients, j’identifie également comment recruter des utilisateurs potentiels dont le feedback sera précieux pour construire mon produit. → Deuxièmement, un produit moyen superbement distribué fonctionnera mieux qu’un produit exceptionnel mal distribué. C’est toute la force du marketing et les effets d’une très forte visibilité. Attention donc. Ça serait trop dommage que tous les efforts consentis à faire un produit exceptionnel ne soient pas récompensés.
En pratique
Pour ne pas négliger la distribution :
Dès le démarrage du produit, se poser des questions liées à la manière de le vendre et d’atteindre sa cible. Où est-elle présente ? Comment puis-je lui parler efficacement ? Avec quel canal ? Ces questions ne doivent pas uniquement être l’apanage des profils dits business (marketing, sales, CEO…) Tout le monde doit y contribuer et y réfléchir. Même les développeurs, mêmes les UX designers, surtout les Product Managers.
Lancer une offre payante le plus vite possible. C’est ce qui va rendre le plus concret la question de la distribution. C’est aussi pour ça qu’on sous-estime “la vente”. Parce que ça reste un concept abstrait au démarrage de la construction du produit. Mais, le jour où on doit trouver 10 clients pour la fin de la semaine, on se pose les vraies bonnes questions. C’est au pied du mur qu’on voit le maçon. Cette offre payante n’a pas besoin d’être hors de prix. Il faut trouver des personnes prêtes à payer un montant > 0€ pour ce qu’on a construit.
Principe 3 : écouter son intuition pour avoir des idées mais pas pour les valider
Pourquoi ce principe
C’est un principe auquel je fais particulièrement attention. Un de mes défauts mais sûrement aussi une de mes qualités c’est que j’adore avoir raison. C’est souvent positif lorsque ça se manifeste de la manière suivante : → Le fait que j’aime creuser et aller au fond des choses, → Le fait que je me documente pour aller trouver les sources et références d’experts.
Mais attention car à force d’apprendre sur le sujet et de travailler, on développe de l’intuition. On a raison plus souvent, forcément.
Or c’est là que c’est autant un atout qu’un danger. En matière de construction d’un produit, je dois être vigilant. Lorsque j’ai une idée pour mon produit, je ne dois pas me mettre dans une posture où je veux avoir raison. Mon intuition doit m’aider à avoir des idées. C’est tout. Pas à avoir raison ou tort dessus. C’est un autre sujet.
Si je veux trop avoir raison, je risque de subir un biais de confirmation par lequel je vais donner plus d’importance aux éléments qui valident mon idée initiale.
D’ailleurs le terme même de “valider une idée” ou de “avoir raison” au sujet d’une expérience ou d’une innovation me semble inadapté. Il vaut mieux adopter une posture de scientifique : → Je réalise une expérience pour valider ou infirmer une hypothèse → L’enjeu est de réussir à aboutir à une conclusion sur cette hypothèse. → On n’attend pas un résultat en particulier, juste de savoir si elle est valide ou invalide.
La posture scientifique reflète un autre enjeu. On est sur un raisonnement, donc au niveau de la raison, pas de l’intuition. C’est aussi le sens de ce principe. Je valide l’idée au moyen d’une expérience, pas parce que j’ai le sentiment que c’est bon. Je ne dois pas me faire piéger.
En pratique
Pour trouver le bon équilibre entre intuition et raison :
Pour trouver les idées, il faut stimuler au maximum sa créativité en matière d’idées. Il faut donc d’abord identifier ses moments où notre intuition est maximale. En marchant dans la rue. En allant courir. En discutant avec un proche. Ensuite, il faut tout noter, toutes ces idées qui nous viennent. Sans jugement. Sans se demander si elles sont pertinentes ou non. L’objectif à ce stade, c’est juste d’avoir plein d’idées.
Pour tester les idées, il faut mettre en place des cadres clairs, définis et précis. La créativité est capricieuse donc il faut essayer de ne pas la cadrer ou la normer. En revanche s’agissant de l’évaluation de ces idées issues de l’intuition, il faut réduire au maximum la marge de manoeuvre pour plus d’efficacité. Par exemple j’aime beaucoup les experiment cards comme ci-dessous. Elles vont permettre de se focaliser sur les bonnes questions et les bons sujets.
Principe 4 : plus c’est petit, mieux c’est
Pourquoi ce principe
Dans la tech, le fait d’attendre entre deux actions a des effets non linéaires. Comme c’est représenté sur le graphe ci-dessus, la difficulté ne croît pas de manière linéaire entre deux actions données :
Si j’attends 4 jours entre 2 actions, plutôt que 2 jours, la difficulté ne va pas être 2 fois plus élevée mais 3, 4 voire 10 fois plus élevée en fonction du coefficient !
Inversement, si j’attends 1 jour entre 2 actions, plutôt que 2 jours, la difficulté ne va pas juste se réduire de moitié, mais encore plus.
Cela est dû à trois facteurs mis en avant par Martin Fowler dans cet article. → Premièrement, certaines tâches sont beaucoup plus faciles à effectuer lorsqu’on les découpe en petites sous-tâches. Imaginons par exemple que je doive déplacer une masse de 100 kilos entre deux points éloignés de 50 mètres. Je pourrais facilement porter 100 fois 1 kilo sur 50 mètres. Pourquoi pas 10 trajets de 10 kilos mais ça serait fatiguant. 2 trajets à porter 50 kilos devraient être possibles mais très difficile. En revanche, je serai bien incapable de porter 100 kilos d’un coup sur cette distance. La difficulté en fonction de la masse transportée par trajet n’augmente pas de manière linéaire ! → Deuxièmement, des petites tâches et des petites actions permettent de générer plus de feedback, ce qui me permet d’ajuster petit à petit. En 100 trajets de 50 mètres, je vais sûrement me rendre compte d’une technique qui marche mieux qu’une autre. Ça va me permettre d’optimiser et d’être encore plus efficace. Si je ne fais qu’un seul trajet, je n’aurai pas ce recul. → Troisièmement, ce feedback et cette pratique répétée fait que je vais m’améliorer dans la tâche que je réalise. À force de passer du temps à porter un poids sur une distance de 50 mètres, je vais devenir “expert” de cette action. Ça rejoint une théorie connue qui dit qu’il faut passer 10.000 heures à faire quelque chose pour en devenir expert (quelques explications ici).
Cet exemple est aussi intéressant parce qu’il montre également qu’il y a une limite au fait de faire des choses plus petites. Évidemment, ça ne serait pas optimal de porter 1 gramme 100.000 fois sur 50 mètres (1 kilogramme = 1000 grammes donc 100 kilos = 100.000 grammes). Comme on le voit sur le graphe ci-dessous, il y a une taille optimale. Et à partir d’un seuil, faire plus petit devient contre-productif.
Ceci étant dit, j’ai quasiment toujours observé empiriquement qu’on n’arrivait quasiment jamais à ce niveau dans la tech. En tout cas, on on a toujours beaucoup plus tendance à faire des choses trop grosses que trop petites. C’est pour ça que je garde le principe formulé ainsi.
En pratique
Pour réussir à faire plus petit en toutes situations, il faut décliner cet objectif à différents niveaux :
Au préalable, cela passe par garantir des conditions pour pouvoir délivrer de manière la plus itérative et incrémentale possible. Cela veut dire avoir une architecture qui permette de faire évoluer très vite des fonctionnalités. Et également disposer de tests automatiques pour valider rapidement les fonctionnalités construites. Souvent j’ai observé qu’il y avait globalement un consensus autour du fait de construire par de plus petits morceaux avec de plus petits déploiements. Mais en pratique, un legacy nous empêchait de réaliser de telles actions. Ainsi il faut commencer par s’attaquer à ce legacy en priorité.
Au niveau fonctionnel, réduire le plus possible la taille des morceaux de fonctionnalités qu’on construit. Petits dévs, petits tests, petits déploiements et on récupère le feedback de l’utilisateur. Puis on recommence, et ainsi de suite. Plus la durée pour faire ces cycles dévs, tests, déploiements est réduite, mieux c’est. Idéalement il faudrait réaliser 2 à 3 cycles de ce type par développeur et par jour. Que faire si l’utilisateur n’est pas disponible pour donner son feedback ? Il faut tout mettre en oeuvre pour qu’il le soit. Mais même en cas d’indisponibilité de sa part, ça ne doit pas nous empêcher de viser cet objectif de réduction au maximum de ces cycles.
Principe 5 : rien ne se passe jamais comme prévu
Pourquoi ce principe
En début de carrière, je me faisais beaucoup avoir à cause de ça. Quand je définissais un planning, j’avais beaucoup de mal à m’imaginer que ce planning ne se réalise pas. Quand j’essayais d’anticiper un peu ce qui allait arriver, je m’imaginais toujours que les événements allaient tourner à mon avantage. On me disait que j’étais optimiste. En fait je ne suis pas sûr que ça ait quelque chose à voir avec de l’optimisme. Je pense plutôt que j’avais beaucoup de difficultés à intégrer l’imprévisibilité dans mes raisonnements.
Or dans la tech, cette imprévisibilité est constante. Elle nous environne. Elle résulte de la combinaison de deux complexités : → La complexité de l’humain et en particulier la difficulté à comprendre et prévoir son comportement. → La complexité de l’ordinateur, qui est un système complexe, dans lequel les mêmes causes ne produisent pas toujours les mêmes effets.
Même si aujourd’hui je suis vacciné. Et bien plus efficace pour intégrer cette imprévisibilité, ça me fascine à quel point, cette complexité me surprend toujours quand j’y suis confronté. Il n’y a pas un produit sur lequel : → Des hypothèses que je faisais sur l’interaction entre mon produit et l’utilisateur, se révèlent fausses en pratique. → Des bugs ou mini anomalies viennent retarder notre capacité à délivrer des fonctionnalités.
💡 Il y a d’ailleurs une loi, appelée la loi de Hofstadter, qui est une application de ce principe aux estimations des projets.
En pratique
Pour ne pas se faire surprendre :
Faire très attention au niveau des engagements. Limiter toute forme de “contrat” où quelque chose doit être réalisé sous une certaine échéance. Rien ne se passe comme prévu, ce qui veut dire que 1️⃣ ce “quelque chose” va évoluer en cours de route ; 2️⃣ vous risquez de ne pas pouvoir tenir l’échéance. Ceci dit, il est parfois nécessaire d’avoir une forme d’engagement. Dans ce cas il faut inclure de la marge pour traiter cette imprévisibilité. Cette marge n’est pas uniquement au niveau du planning (des jours en plus pour finaliser). Il faut aussi de la marge au niveau financier (plus d’argent) et au niveau des attentes (capacité à revoir à la baisse les ambitions de ses sponsors).
Accepter cette incertitude inhérente et en faire une force. C’est très déstabilisant de se dire qu’on va probablement avoir tort lorsqu’on essaye de prévoir ce qu’il va se passer. Notamment parce que l’école nous pousse à développer ce genre de capacités. On finit par assimiler inconsciemment cette capacité d’anticipation à l’intelligence ou à la performance. Pourtant en matière de tech, notre force résidera plutôt dans le fait de savoir s’adapter vite à une situation imprévisible plutôt qu’à essayer d’anticiper ces événements imprévisibles. Puisque par définition, ces événements imprévisibles ne peuvent pas être anticipés.
Merci de m’avoir lu, inscris-toi pour ne pas rater les prochaines éditions 💪
Conclusion
Merci de m’avoir suivi dans cette présentation de ces principes structurants. J’espère que ça t’a été utile. On se retrouve la semaine prochaine 🙏
Si tu es trop impatient pour attendre, tu peux :
Me contacter pour échanger sur le sujet par mail ou par message LinkedIn 💪
