- Beaucoup d’entreprises voient leur rythme de développement ralentir par des processus complexes ou des exigences interminables, alors qu’en réalité l’essentiel est de créer rapidement le « bon produit »
- En supprimant les éléments inutiles du processus de développement produit, la vitesse de développement augmente fortement. Concevoir le bon produit est en soi un processus intrinsèquement rapide
- Ce qui ralentit les équipes produit, ce sont les éléments inutiles comme les processus, la distance entre les décideurs et les exécutants, ou les spécifications excessives
[Principes pour la Product Velocity]
1. Il faut « en faire moins »
- En général, il existe un compromis entre vitesse et qualité
- La plupart des entreprises définissent des exigences et des échéances, puis traitent la qualité comme un résultat, mais nous faisons l’inverse : nous fixons un niveau de qualité puis nous réfléchissons à ce qu’il est possible de lancer en 60 jours
- L’important n’est pas de chercher à satisfaire toutes les exigences, mais d’achever rapidement ce qui compte vraiment
- En supprimant des exigences et en ne faisant que le nécessaire, on peut améliorer à la fois la vitesse et la qualité
- Elon Musk propose une approche similaire en disant : « commencez par rendre les exigences moins stupides »
2. Le « mode idiot » est souvent efficace
- Si l’on prend l’exemple du « midwit meme », les personnes très intelligentes et les idiots s’accordent sur des solutions simples, tandis que les personnes moyennes créent des problèmes inutilement complexes.
- Nous abordons souvent les problèmes en « mode idiot » : au lieu de trop compliquer la réflexion, nous essayons de trouver une solution simple.
- Quand nous nous trompons, c’est en général parce que nous avons trop réfléchi ; les méthodes simples fonctionnent plus souvent
- Se demander « si j’étais idiot, qu’est-ce que je ferais ? » permet souvent d’aboutir à une solution exécutable
3. Tous les problèmes ne sont pas importants
- Seule une petite partie des problèmes est vraiment importante. Les problèmes critiques comme la sécurité doivent absolument être résolus, mais il n’est pas nécessaire de tout corriger.
- Par exemple, l’interface mobile n’est pas bonne, mais comme les clients utilisent très peu le mobile, nous ne l’améliorons pas.
- De la même façon, les problèmes auxquels les clients accordent peu d’importance peuvent être ignorés.
4. Construisez, c’est tout
- Nous n’avons pas de processus pour développer le produit. Nous ne faisons ni mockups Figma, ni PRD, ni design system, ni agile, ni OKR, ni roadmap produit bien définie, ni A/B testing, ni growth hacking
- Comme nos clients sont des ingénieurs, nous partons du principe que nos ingénieurs peuvent aussi gérer le produit, le design, etc.
- Nous préférons construire rapidement un produit puis observer la réaction des clients
5. Les réécritures se font quand c’est nécessaire
- Les entreprises pensent souvent que plus elles repoussent la dette technique, plus elles peuvent avancer vite, mais cela ne nous dérange pas de faire une réécriture majeure quand c’est nécessaire
- Parfois, le chemin le plus rapide pour construire la bonne chose consiste à construire la mauvaise, réaliser qu’elle est mauvaise, puis la remplacer par la bonne
- Si supprimer la dette technique semble utile, nous le ferons
6. Externalisez quand c’est possible
- Quand c’est possible, nous achetons une solution à un fournisseur externe au lieu de la construire en interne. Par exemple, nous générons les SDK via un prestataire appelé Fern
- Bien sûr, faire appel à des fournisseurs implique un coût initial important et limite la liberté, mais c’est généralement le bon choix
- Nos ressources d’ingénierie sont très limitées et coûteuses : une semaine de temps d’ingénieur coûte environ 5 000 dollars. En tenant compte du coût d’opportunité, cette valeur est bien plus élevée
- Il y a en réalité relativement peu de choses qui valent vraiment la peine d’être construites
7. Ne pas recruter
- Nous ne nous attendons pas à ce qu’augmenter les effectifs fasse croître la production de l’équipe. Recruter est lent et difficile, et l’onboarding comme la gestion des personnes prennent du temps
- Il est particulièrement difficile de faire venir des personnes compétentes capables de contribuer avec peu d’accompagnement
- C’est pourquoi, même si nous avons les ressources pour bâtir une grande équipe d’ingénierie, nous faisons de notre mieux pour rester petits. Cela rend la vie beaucoup plus simple
Réflexions de conclusion
- Nous avons compris, à un degré que nous n’avions pas réalisé auparavant, que le développement produit ne devrait pas prendre autant de temps
- Si vous savez ce dont les clients ont besoin, disposez d’une équipe solide et écartez les distractions inutiles, vous pouvez développer un produit à grande vitesse
10 commentaires
Je suis revenu le voir aussi. À la prochaine.
Même après l’avoir relu plusieurs fois, c’est toujours aussi bien.
?? C'est vraiment très idéaliste.
Les coûts de gestion de la sous-traitance et les ressources qu’il faut y consacrer ne doivent pas être négligeables... Mais dans l’ensemble, ce sont d’excellents conseils.
On dit toujours qu’il faut externaliser. Mais on voit rarement comment il faut s’y prendre quand on fait appel à la sous-traitance.
Si on se contente de transmettre une simple ébauche, sans vision claire du service, on ne se rend pas compte qu’on risque de recevoir quelque chose d’encore pire que ce qu’on imaginait....
???: Rendez-le rapide, mais pas agile.
Je pense que c’est possible quand le produit est clair
Quand ce qu’il faut faire est évident, ce niveau de conception supplémentaire est inutile, c’est un peu l’idée.
"Commencez par rendre les exigences moins stupides"
Si le prestataire externe disparaît un jour... et ne répond plus au téléphone :(
Même pour du développement interne, si tout le monde finit par démissionner un jour, la situation n’est-elle pas similaire.. ?