Pourquoi il faut construire un produit en public [traduction]

1. Pourquoi est-ce si effrayant de construire en public ?

• Construire en public oblige à exposer tels quels un produit et des idées encore inachevés, ce qui donne l’impression que son « inachèvement, ses erreurs et son ignorance » sont mis à nu.
• Les gens craignent surtout les choses suivantes :
  • le jugement ou les moqueries des autres, qui pourraient penser que « c’est nul »
  • le fait que des décisions erronées ou une mauvaise direction restent consignées
  • le risque pour la réputation, du type « cette personne n’a pas le niveau, pourquoi partage-t-elle comme ça ? »

2. Les raisons essentielles de le faire malgré tout

• Construire en public montre non pas « un résultat final impressionnant déjà achevé », mais « le processus », ce qui accélère de façon écrasante la vitesse du feedback et de l’apprentissage.
• Au lieu de rester enfermé dans les hypothèses que l’on a en tête, on obtient en temps réel les réactions de vrais utilisateurs et de ses pairs, ce qui permet de corriger la trajectoire bien plus vite.
• En même temps, cela permet de se connecter naturellement à des personnes qui suivent un chemin similaire, et de former « un groupe de pairs qui avancent ensemble (community) ».

3. Le point que beaucoup de gens comprennent mal

• On croit souvent à tort que « construire en public = publier chaque jour des résultats spectaculaires », alors qu’en réalité il est plus important de « partager honnêtement les petites avancées, et même les blocages ».
• On pense aussi que c’est réservé « aux gens déjà très compétents, aux experts », mais l’article explique au contraire que « les personnes qui partagent leur processus d’apprentissage lui-même » suscitent davantage de résonance.
• Beaucoup repoussent le moment de s’y mettre en pensant qu’il faut d’abord préparer un storytelling et un branding parfaits, mais le texte souligne que l’essence du build in public, c’est « continuer à se montrer malgré l’imperfection (showing up) ».

4. Que rendre public, concrètement, et comment ?

• Les exemples d’éléments à partager proposés dans l’article ressemblent globalement à ceci (résumé basé sur les formulations de l’original) :[3][2]
  1. Le problème que l’on cherche à résoudre (Problem statement)
  2. Les hypothèses actuelles et le plan d’expérimentation (Hypotheses, Experiments)
  3. Les avancées hebdomadaires/mensuelles, les indicateurs et les apprentissages (Progress, Metrics, Learnings)
  4. Les mauvaises décisions, les échecs et les rétrospectives aux moments de pivot (Failures, Pivots)
• Les formats peuvent varier, mais le modèle recommandé est le suivant : sur Twitter, LinkedIn, un blog, etc., « partager souvent et brièvement → observer les réactions puis ajuster progressivement le format ».

5. L’état d’esprit et les conseils d’exécution pour réduire la peur

• Si l’on déplace sa perspective de « comment les autres vont-ils me voir ? » vers « qu’est-ce qui peut être utile à la personne qui lit ceci ? », la peur de s’exposer diminue et l’on peut se concentrer sur un partage plus utile.
• Si l’on résume le message de l’article :
  • Ne pas attendre d’être prêt (Don’t wait to be ready).
  • Écrire en pensant, même s’ils sont peu nombreux, à des gens à qui cela peut réellement servir.
  • Se rappeler que les moqueries et l’indifférence ne sont qu’un filtre, et que ceux qui restent sont au final « des pairs qui parlent la même langue ».