Choisissez des solutions ennuyeuses

L'un de mes articles préférés de tous les temps est Choose Boring Technology de Dan McKinley. Dans cet article, Dan explique pourquoi il est important de limiter le nombre d'inconnues qu'une équipe doit gérer à un moment donné.

Il introduit le concept de jetons d'innovation comme un moyen simple de suivre et de limiter l'introduction de technologies ou d'architectures peu familières. Un jeton d'innovation est consommé chaque fois que vous utilisez une nouvelle technologie ou un nouveau concept qui nécessite un apprentissage important, et vous ne disposez que de 3 jetons d'innovation au début de votre parcours.

L'objectif est de créer une stack où la plupart des éléments sont ennuyeux – ce qui signifie que l'équipe peut facilement les comprendre et les mettre en œuvre. L'idée n'est pas de choisir une mauvaise technologie, mais plutôt de minimiser le temps consacré à comprendre comment les choses fonctionnent, et de maximiser le temps consacré à comprendre ce que veulent les utilisateurs.

Par exemple, une nouvelle startup n'a pas besoin de commencer avec Kubernetes, surtout si elle n'a pas encore trouvé son product-market fit. Et même une entreprise établie n'a pas besoin de réécrire son service de facturation critique en Rust si c'est la première fois que l'équipe est exposée à ce langage.

Il existe de nombreuses excellentes technologies. Mais la plupart des entreprises n'en ont pas besoin pour satisfaire leurs utilisateurs et développer leur activité.

L'innovation doit avoir lieu, oui, mais seulement 3 jetons à la fois.

L'ennui s'applique aussi à la stratégie

L'article de Dan portait surtout sur l'ingénierie, mais il s'applique très bien à la stratégie. Vous définissez vos OKRs, puis vous déterminez la meilleure feuille de route et les meilleures tactiques pour atteindre les objectifs nouvellement établis.

Mais le problème avec la stratégie, c'est qu'il est vraiment difficile de prédire ce qui va fonctionner. La plupart des expériences échouent, et il est fort probable que 25 % (voire plus !) de vos projets ne produiront pas les résultats attendus. C'est pourquoi vous devriez traiter les projets comme des paris. Certains paris fonctionneront, et vous pourrez y investir davantage. Mais d'autres paris manqueront leur cible, et il devrait être facile de les abandonner.

La question est donc :

Quel est le moyen le plus rapide de découvrir ce qui fonctionne et ce qui ne fonctionne pas ?"

Comme pour le problème technologique, votre objectif devrait être de minimiser le temps passé à mettre en œuvre les paris et de maximiser le temps passé à apprendre de vos clients.

Et une façon de faciliter cela est de choisir des solutions ennuyeuses.

Encore une fois, ennuyeux ne signifie pas mauvais. Cela signifie simplement que nous devrions choisir des approches que nous connaissons ou qui sont faciles à apprendre, afin de pouvoir rapidement arriver au point où nous testons nos idées. Cela signifie aussi faire des choses qui ne sont pas évolutives avant de construire la version automatisée. Plus nous rendons nos solutions complexes, aussi innovantes soient-elles, plus il faut de temps avant d'obtenir un retour et des données réels.

Je me souviens clairement de l'exemple d'une entreprise de vente au détail en ligne qui a testé une nouvelle approche des retours en faisant imprimer manuellement des codes QR par les développeurs pour un lot d'utilisateurs. Ils ont rapidement appris que leur solution proposée ne fonctionnerait pas, même une fois automatisée. Ils ont économisé 3 mois de travail en choisissant une façon ennuyeuse de tester leur pari, puis ont rapidement réorienté leur attention vers d'autres opportunités une fois qu'ils ont réalisé que ce n'était pas une bonne idée.

Chez Tability, nous avons récemment ajouté une liste de statuts de tâches pour offrir plus de flexibilité qu'un simple "ouvert"/"fermé" (ex : planifié, en cours, en relecture, terminé...). Nous savons que la meilleure solution serait de permettre de personnaliser cette liste, mais nous avons décidé de livrer une liste statique plus simple en guise de MVP. L'utilisation des tâches a augmenté de 20 % grâce à cela, et nous pouvons désormais travailler sur une solution plus sophistiquée.

Quelques autres exemples :

• Acheter une solution d'email marketing éprouvée plutôt que de développer votre propre service de newsletter.
• Utiliser Qwilr ou Canva pour tester rapidement une présentation commerciale plutôt que d'attendre plusieurs semaines pour obtenir un design personnalisé.

Validez avec de l'ennuyeux, passez à l'échelle quand la confiance augmente

Notre cerveau adore la nouveauté. Il y a quelque chose d'assez excitant à explorer de nouvelles technologies, et il est difficile de résister à la tentation d'appliquer des solutions innovantes à des problèmes complexes.

Mais nous devrions toujours optimiser le temps jusqu'au retour d'information. C'est-à-dire le temps qui s'écoule avant d'obtenir un véritable retour du marché. Plus nous acceptons de pouvoir nous tromper, plus il est facile de commencer petit.

Vous pouvez ensuite itérer à mesure que votre confiance augmente.

• Commencez par un MVP ennuyeux : il s'agit de l'approche non évolutive que vous devriez pouvoir livrer en l'espace de quelques semaines. Elle ne gère peut-être pas tous les cas d'usage, et l'approche sous-jacente n'est peut-être pas élégante. Mais c'est un moyen simple de valider votre pari et de confirmer que vous êtes sur la bonne voie.
• Passez ensuite à une solution ennuyeuse : la solution ennuyeuse est toujours construite avec des outils et des méthodes simples. Mais vous comblez désormais certains cas particuliers et automatisez les tâches manuelles.
• Enfin, optimisez avec de l'innovation : une fois que vous êtes à peu près certain d'avoir trouvé la bonne approche, et que vous ressentez aussi le besoin de passer à l'échelle, vous pouvez alors envisager des approches innovantes pour votre problème. Mais cela devrait rester rare. Une solution ennuyeuse suffira dans la plupart des cas.

Une dernière réflexion avant de terminer. Une solution ennuyeuse ne doit pas déboucher sur une expérience utilisateur m*rdique (pardon my French).

Le seuil minimum pour l'UX est "Bon". Il y a une grande différence entre trouver un moyen simple de livrer quelque chose de bon et baisser ses standards pour livrer un projet plus vite.

Vous pouvez réduire le périmètre de vos projets, mais vous ne pouvez pas diminuer la qualité de vos livrables.

--

Vous utilisez des OKRs ? Nous avons une façon "ennuyeuse" de simplifier le suivi plutôt que de concevoir votre propre tableur → Découvrez Tability.