50 leçons apprises en construisant des produits à succès [article traduit]

1. Une petite équipe (6 personnes ou moins) peut créer d’excellents produits, mais elle doit disposer d’une autonomie totale sur la définition des objectifs, la priorisation de la roadmap, le choix des métriques, la communication avec les utilisateurs et le déploiement rapide du code.

2. Le succès d’un produit dépend des personnes qui le construisent. Relever le niveau d’exigence au recrutement est essentiel, car la qualité des talents se cumule. Un mauvais recrutement ralentit davantage une équipe que n’importe quel autre facteur.

3. La confiance est indispensable pour créer de grands produits. Le manque de confiance est l’un des principaux goulets d’étranglement d’une équipe, et il résulte souvent soit d’un recrutement en dessous du niveau attendu, soit d’un défaut de feedback d’amélioration donné à la personne concernée.

4. La confiance se construit aussi par la transparence. Travaillez au grand jour, menez les discussions dans des espaces ouverts et documentez le travail effectué. Ainsi, tout le monde partage le contexte nécessaire et cela élimine les luttes politiques qu’on voit dans beaucoup d’entreprises.

5. Appuyez-vous sur la confiance et le feedback, pas sur les processus. C’est l’une de nos valeurs fondamentales. Construire et développer ce que veulent les gens est un problème subtil, donc nous faisons confiance au jugement des employés. Quand quelque chose ne va pas, nous donnons un feedback direct.

6. La direction partage les objectifs de l’entreprise, puis les équipes produit (les ingénieurs) déterminent quoi construire pour les atteindre ainsi que leurs propres objectifs. Les deux parties doivent examiner l’impact réel à l’aide des métriques et du feedback utilisateur.

7. Un produit est subordonné à son profil client idéal (ideal customer profile, ICP). C’est l’ICP qui définit ce qu’il faut construire, et c’est le facteur le plus important pour décider quoi créer. Un ICP précis ne définit pas seulement le client cible, mais aussi tous les aspects du produit et de la stratégie de go-to-market.

8. Pour trouver son ICP, commencez par formuler des hypothèses et testez-les. Posez des questions à l’inscription, comparez la rétention, identifiez les power users et lancez des enquêtes NPS. À mesure que l’information et la confiance augmentent, ajoutez plus de détails.

9. Définissez des principes produit. Les nôtres sont : « fournir tous les outils nécessaires pour mesurer le succès, occuper le terrain en premier, et servir de source de vérité pour les données client et produit ». Cela donne un langage commun pour discuter des idées et prendre des décisions.

10. Cartographiez tout ce que les utilisateurs pourraient vouloir. C’est nécessaire pour prioriser une roadmap. Cela évite de passer à côté d’excellentes idées situées au-delà de l’horizon immédiat.

11. Un produit, c’est plus qu’une simple liste de fonctionnalités. C’est aussi une marque et l’expérience produit qu’il procure aux autres. L’ampleur des investissements sur chaque fonctionnalité, les personnes recrutées, les choix de build, les fonctionnalités mises en avant, la communication client et la politique tarifaire contribuent tous à son originalité.

12. Le site web est la première impression du produit. Un site ennuyeux ou trop générique envoie le signal que le produit et l’équipe derrière sont faibles. Créer un site distinctif, adapté à votre ICP, évite cela et stimule l’acquisition d’utilisateurs.

13. Parfois, le problème n’est pas le produit, mais le marché. Par exemple, lorsque Tom Blomfield, fondateur de Monzo et partner chez YC, créait un service de partage de factures pour des amis d’université, on lui a conseillé d’arrêter de build et de se concentrer sur l’acquisition d’utilisateurs. Après 4 semaines de cold calling pour n’en obtenir qu’un seul, il a compris qu’il était temps de pivoter.

14. Si vous pivotez, faites-le radicalement. Stewart Butterfield a transformé deux sociétés de jeux en Flickr puis Slack. Le cofondateur de LinkedIn, Reid Hoffman, dit que pour pivoter de l’échec vers le succès, les fondateurs de startup doivent pratiquer le « slash and burn » sur le reste de l’activité. Si cela se ressemble encore, allez plus loin.

15. Comme le dit Jason Fried de 37signals : « On ne peut pas valider une idée. Puisqu’elle n’existe pas encore, il faut vraiment la construire. Le marché la validera. »

16. Les plans sont utiles, mais ils ne sont pas faits pour être suivis rigidement. Une bonne exécution ne consiste pas à respecter un plan précis, mais à répéter ce qui compte le plus. Évaluez les gens non pas sur leur “respect du plan”, mais sur ce qu’ils livrent, leur fréquence de déploiement et leur impact.

17. Repousser quelque chose d’« une semaine de plus » est presque toujours une mauvaise idée. Quand cette attitude s’accumule pendant des mois, l’élan s’effondre. Plus vite vous mettez quelque chose entre les mains des utilisateurs, plus vite vous pouvez en comprendre la valeur et l’améliorer.

18. Réduisez le travail en cours. Une PR doit être terminée en une journée, commencez la journée en répondant aux demandes de review des autres, mergez à tout moment, déployez derrière des feature flags et testez en production. Tout cela réduit la charge contextuelle du travail.

19. Les déploiements rapides sont au cœur de notre philosophie de développement produit, mais il y a des trade-offs. Les achats technologiques, les réunions de planification, les rituels agiles et les revues de métriques passent au second plan. Le travail asynchrone rend cela encore plus possible.

20. N’introduisez de nouvelles technologies dans le produit que face à des problèmes pressants comme des coûts excessifs, des problèmes de scalabilité ou des demandes clients. Pour trouver une solution, demandez comment votre équipe ou d’autres ont résolu ce type de problème directement.

21. Les deadlines artificielles ne rendent pas une équipe plus rapide. Elles déclenchent au contraire une boucle destructrice faite de dette technique accumulée et de burnout. Supprimez les processus qui ralentissent l’équipe et donnez aux petites équipes l’autonomie nécessaire pour déployer vite.

22. Une autre façon de déployer plus vite consiste à supprimer le design par défaut. Une fois le design system en place, laissez les ingénieurs builder. Si nécessaire, peaufinez ce qui a déjà été déployé via une design review.

23. Les feature flags permettent aux product engineers de déployer rapidement des changements, de les tester en production et d’obtenir du vrai feedback utilisateur. Ils réduisent aussi le risque en jouant le rôle de kill switch quand tout ne fonctionne pas comme prévu.

24. Chez PostHog, la meilleure forme de communication est la pull request. Contrairement aux messages ou aux issues, elle transforme immédiatement le feedback en impact. Cela correspond à une culture orientée action et crée une boucle de feedback plus serrée.

25. Rendez l’ownership explicite. Cela rend les décisions sur ce qu’il faut build beaucoup plus claires et rapides. Les équipes qui évitent l’ownership gaspillent leur temps en planification, brainstorming, réunions et gestion de projet au lieu de déployer.

26. Les ingénieurs sont capables de décider quoi construire. Ils comprennent les contraintes techniques, savent reconnaître des patterns de fonctionnalités et savent comment résoudre les problèmes. En revanche, il peut exister un goulot d’étranglement sur l’information concernant les besoins utilisateurs.

27. Au lieu de contrôler les ingénieurs, les product managers devraient fournir du contexte à l’équipe produit via la product analytics, la recherche utilisateur ou l’analyse de la concurrence.

28. La plupart des gens ne sont pas Steve Jobs. Ils n’ont ni une vision innée de ce qu’il faut construire dès le départ, ni la capacité de dessiner le grand tableau. À la place, il faut déployer, mettre entre les mains des utilisateurs, puis itérer sur le feedback. Plus ce cycle va vite, meilleur devient le produit.

29. Recrutez et appuyez-vous sur des product engineers. Ils réunissent les compétences full-stack nécessaires pour construire des produits et une obsession du client. Ils doivent parler aux utilisateurs, mener des entretiens, recruter des testeurs pour les nouvelles fonctionnalités, collecter du feedback, gérer le support et répondre aux incidents.

30. Lisez The Mom Test. Ce livre apprend à parler des problèmes avec des utilisateurs potentiels. Le cœur du sujet, ce sont deux types d’entretiens utilisateurs : l’exploration du problème et la validation de la solution. Le premier guide les décisions produit futures, le second aide à améliorer ce qui est en cours de construction.

31. Pour tirer le maximum des entretiens utilisateurs, identifiez à l’avance qui sont les utilisateurs (ICP), comment ils utilisent le produit et ce que vous envisagez de construire ensuite. Ainsi, l’entretien clarifie l’étape suivante au lieu d’ajouter de la confusion.

32. Parmi les choses potentielles à construire, les demandes de support sont les plus “réelles”. Un utilisateur précis rencontre un problème concret ; si vous le résolvez, le produit s’améliore immédiatement. Les autres changements ne sont pas aussi intuitifs.

33. Quand les ingénieurs gèrent le support, cela encourage une ownership de l’ensemble du cycle de vie du produit, de l’idéation à l’implémentation puis à la maintenance continue. Chaque étape s’alimente des vraies douleurs clients et du contexte code derrière chaque problème.

34. Le support assuré par les ingénieurs raccourcit la boucle entre un problème utilisateur et le correctif déployé. Ni l’équipe support, ni les product managers, ni les processus de planification ne viennent faire obstacle. Et en bonus, les utilisateurs adorent ça.

35. L’usage interne de son propre produit (dogfooding) aide à accélérer les déploiements, à bloquer les problèmes avant qu’ils n’atteignent les utilisateurs, à comprendre le produit en profondeur et à développer de l’empathie utilisateur. Mais cela ne remplace ni les échanges avec les utilisateurs, ni le vrai feedback, ni le suivi des métriques d’usage.

36. Comme lorsque notre équipe produit a résolu ses propres besoins avec un popup d’interview, résoudre ses besoins internes est un bon moyen de valider un use case. Si vous devriez utiliser votre propre produit mais que vous ne le faites pas, c’est un signal qu’il y a un problème à corriger.

37. Les grands builders de produit sont toujours en train de prototyper et d’expérimenter. Ils doivent être à l’aise avec la construction de MVP et de proof of concept, le déploiement de travaux inachevés, la prise en compte du feedback et le pivot en cas d’échec. Ils doivent aussi maîtriser toutes les compétences du zéro au build, de l’infrastructure au design.

38. Pour réussir un A/B test, il faut impérativement une bonne hypothèse expliquant ce que vous testez et pourquoi. Incluez le contexte du test, les changements, les métriques et le résultat attendu.

39. Quand vous faites des expérimentations produit, sachez qu’elles peuvent échouer et être supprimées. Configurez-les pour qu’elles soient faciles à retirer via des feature flags, et déployez une version “suffisamment bonne” plutôt qu’une version parfaite en matière de maintenance ou de scalabilité. Vous l’améliorerez après si elle fonctionne.

40. Les expérimentations produit peuvent être menées de manière bien plus “bête” qu’on ne l’imagine. Au lieu de construire toute la fonctionnalité, essayez un fake door test. Il suffit d’ajouter une option ou un bouton qui ne mène à rien, afin de voir si les gens cliquent dessus.

41. L’échec d’une expérimentation produit n’est pas la fin du monde. Chez Google, 80 à 90 % des expérimentations “échouent”. Cela peut sembler être une perte de temps, mais à grande échelle, les 10 % qui réussissent compensent largement tous les échecs — comme cet A/B test sur l’affichage des titres dans Bing qui a augmenté les revenus de 12 % (plus de 100 millions de dollars).

42. Si vous vous concentrez sur la croissance, réfléchissez et priorisez comme un growth engineer. Identifiez la zone cible, choisissez une métrique représentative, formulez une hypothèse d’amélioration et implémentez le plus petit test possible pour la vérifier.

43. Mettre en place de l’analytics n’est presque jamais trop tôt. Cela peut être vrai pour un produit avant son lancement, mais dire “c’est trop tôt” et lancer sans analytics est une fausse économie. Après le lancement, la priorité ne consiste plus à déployer le plus vite possible, mais à déployer le plus vite possible les bonnes choses.

44. Quand vous commencez avec l’analytics, partez petit. Choisissez un produit ou une fonctionnalité précise, suivez l’usage avec l’autocapture, visualisez-le avec des graphiques de tendances et de rétention, puis essayez de déployer des fonctionnalités qui améliorent ces courbes. Le “complexe industriel de la modern data stack” donne l’impression que c’est beaucoup plus compliqué que ça ne l’est vraiment.

45. Si vous ne savez pas par quelle métrique commencer, je recommande l’activation. Elle se situe en amont des autres métriques, les ingénieurs peuvent l’influencer directement et elle est utile à toute l’organisation.

46. En plus de l’activation, la rétention est une autre métrique clé pour comprendre l’impact de ce que vous construisez. Suivre ses variations hebdomadaires permet d’évaluer si les changements aident vraiment à retenir les utilisateurs.

47. Pour mesurer le product-market fit, vérifiez si l’engagement utilisateur augmente de façon exponentielle plus vite que la croissance des utilisateurs, et si la rétention se stabilise (au-dessus de 0 %). Ensuite, regardez si la rétention est forte chez les utilisateurs ICP et si les clients payants appartiennent bien à cet ICP.

48. Les growth reviews servent à vérifier si ce que l’équipe construit a un impact sur des métriques importantes comme les revenus, la product analytics ou le feedback utilisateur. Chez PostHog, c’est l’une des principales responsabilités des product managers.

49. Si vous construisez plusieurs produits, traitez chacun comme une mini-startup : avec ses propres décisions produit, son pricing, ses revenus, ses coûts et sa coordination avec les équipes en contact avec les clients.

50. Accrochez-vous à des produits qui vous passionnent. Comme l’a écrit James, cofondateur de PostHog, dans son guide sur le product-market fit : « Si ça ne vous intéresse pas, pivotez. C’est tout. On accomplit davantage quand on s’accroche à quelque chose qui nous ressemble vraiment. »