5 leçons pour aller sur le marché que j'ai apprises en développant un produit axé sur la croissance des développeurs

Logto est un produit open source axé sur les développeurs. Voici notre chronologie pour aller sur le marché :

1. Nous avons publié la version open source en juillet 2022.
2. En janvier 2023, nous avons lancé l'aperçu cloud (bêta cloud).
3. En juillet 2023, il était prêt pour la production avec une tarification complète.

Venant d'un background dans la croissance axée sur le produit pour les outils de productivité, les équipes et moi avons essayé différentes stratégies pour Logto. Après deux ans, j'ai réfléchi à ces efforts et aux étapes que nous avons suivies. Je veux partager une partie de ce parcours et expliquer pourquoi certaines choses n'ont pas fonctionné à l'époque. Ce ne sont pas des «erreurs», mais des leçons précieuses tirées de notre expérience. J'espère que ces idées aideront d'autres personnes travaillant sur des projets ou startups similaires.

Les stratégies traditionnelles d'intégration peuvent ne pas fonctionner#

Lorsque vous lancez votre produit pour la première fois, surtout avec un état d'esprit de croissance produit ou une certaine expérience, il est facile de penser à toutes sortes d'idées excitantes : des parcours d'intégration sophistiqués, une superbe démo sur le site Web, des moyens géniaux de mettre en valeur la valeur pour les utilisateurs et de les amener rapidement au moment «ah-ha». Pour que notre produit semble soigné et prêt pour la commercialisation, j'ai mis en œuvre deux stratégies d'activation :

1. Intégration centrée sur la mission à accomplir, pour que les utilisateurs puissent résoudre leurs problèmes immédiatement.
2. Pendant l'intégration, inclure des options comme «réserver un appel» ou «envoyez-nous un e-mail» pour un contact humain afin d'augmenter les taux de conversion—une chose qui fonctionne bien avec les grandes entreprises.

Ces stratégies avaient très bien réussi dans mon expérience passée. Donc, lorsque Logto a lancé sa version cloud hébergée, je les ai appliquées immédiatement. Cependant, j'ai rencontré quelques confusions et défis :

1. Quel est exactement le «job-to-be-done» de Logto ? Contrairement aux produits simples comme les outils de productivité (par exemple, la rédaction de documents ou la création d'œuvres d'art), Logto s'occupe de la construction de systèmes d'authentification ou de la gestion des identités d'utilisateurs. Mais comment les utilisateurs peuvent-ils y parvenir en une journée ?
2. Bien sûr, nous avons ajouté un lien Calendly pour planifier des appels, mais nous n'avons pas reçu beaucoup de réservations et cela n'a pas augmenté notre taux de conversion comme prévu.

Pourquoi le point #1 ne fonctionne pas#

Pour les produits destinés aux développeurs, il est difficile de résoudre un problème en peu de temps même s'il peut être véritablement self-service. Même pour un développeur individuel, le processus implique plusieurs étapes : s'intégrer au bon stack technologique, créer une preuve de concept, tester dans un environnement de développement puis passer en production. À tout moment de ce parcours, les utilisateurs peuvent abandonner. La «mission à accomplir» n'est pas une tâche simple ou monotâche. Les besoins des développeurs sont souvent complexes, nécessitant une gamme de fonctionnalités ou de scénarios techniques qu'il faut concevoir attentivement en utilisant nos capacités existantes. Résoudre de tels problèmes prend du temps et ne peut pas être précipité.

Pourquoi le point #2 ne fonctionne pas#

En y repensant, il est clair pourquoi cette approche n'a pas réussi. Lorsque nous avons lancé pour la première fois, nos inscriptions quotidiennes et notre trafic organique étaient assez bas. La majorité de notre trafic provenait de la communauté open source, ce qui n'a naturellement pas amené de clients plus importants. Il n'est pas surprenant que nous n'ayons pas vu de plus gros clients réserver des appels à ce stade. Le faible trafic et la source de nos utilisateurs ont rendu irréaliste d'attendre des réservations d'appels significatives en début.

Freemium ou essai gratuit ? Avant de se battre, comprenez d'abord votre produit#

Choisissez le modèle qui convient à votre produit, en fonction du temps nécessaire pour l'activation de l'utilisateur. Ne laissez pas les normes de l'industrie vous restreindre.

Lors de la création d'un produit SaaS, l'une des principales questions pour aller sur le marché est de choisir le freemium ou un essai gratuit. La sagesse commune suggère :

1. Essai gratuit : Les utilisateurs ont un accès complet pour un temps limité, puis doivent payer pour continuer.
   • Idéal pour : Produits complexes ou premium où les utilisateurs doivent expérimenter les fonctionnalités complètes pour en voir la valeur.
2. Freemium : Les utilisateurs accèdent à une version de base gratuitement, avec des mises à niveau payantes pour des fonctionnalités avancées.
   • Idéal pour : Produits avec une large gamme de fonctionnalités, où les utilisateurs gratuits pourraient s'upgrader à mesure que leurs besoins augmentent.

Nous avons initialement choisi un modèle freemium pour un lancement rapide, plaçant un mur payant dur entre les plans gratuits et payants. Cependant, les développeurs ne pouvaient pas accéder à des fonctionnalités avancées comme le SSO ou l'Organisation dans le niveau gratuit.

Bien qu'il y ait beaucoup de débats en ligne sur le modèle le meilleur, il est crucial de prendre du recul et considérer le calendrier d'activation de votre produit. Pour Logto, nous avons observé qu'en réalité, la phase de test peut durer jusqu'à 6 mois. Ce n'est pas dû à la complexité de Logto mais plutôt à l'emploi du temps de travail de l'ingénieur, la planification de projet, les workflows d'équipe, et d'autres facteurs que nous n'avions pas anticipés.

Compte tenu de cette longue période d'activation, il est important de fournir aux développeurs un accès complet à toutes les fonctionnalités pour les tests. C'est pourquoi nous utilisons pleinement l'entité de développement pour débloquer toutes les capacités du produit. C'est une pratique courante pour les outils destinés aux développeurs mais cela vaut la peine d'être noté car cela explique pourquoi les stratégies freemium ou d'essai gratuit traditionnelles peuvent ne pas fonctionner pour nous.

Le choix doit être aligné avec la nature de votre produit et son calendrier d'adoption. Comprenez les caractéristiques uniques de votre produit, et choisissez un modèle qui convient, pas un qui pousse les utilisateurs trop rapidement à travers votre entonnoir de conversion.

Si vous ne comprenez pas vos clients, votre contenu paraîtra égoïste#

Mettre en œuvre une stratégie de passage au marché avec une approche ascendante implique souvent du SEO, du marketing produit, et du marketing de contenu. Nous savons tous qu'il est important de commencer tôt, donc nous avons commencé à créer du contenu juste après avoir lancé la version open source. Mais lorsque nous avons décidé d'écrire des articles pour la première fois, j'ai eu une grande question : Qu'est-ce que je devrais écrire ?

En tant que designer produit, mon instinct était d'écrire sur pourquoi nous avons conçu certaines fonctionnalités, expliquant le processus de réflexion et la philosophie derrière elles.

"Dans cet article, nous parcourrons l'historique de l'expérience de connexion, y compris sa conception, ses décisions de conception, et ses compromis de produit. Vous aurez également une meilleure compréhension de comment construire une expérience de connexion ou d'inscription réussie et sans friction." - Notre article de blog il y a 2 ans Les considérations de conception pour une expérience de connexion sans couture (Premier Chapitre)

J'étais impatient de partager mes réflexions sur nos fonctionnalités et notre conception parce que j'y avais mis tellement d'effort. Mais avec le recul, je réalise que c'est ce qu'on appellerait du contenu « égocentrique ». C'est courant dans les entreprises bien établies avec une forte culture EPD (Ingénierie, Produit, Design).

Si vous faites de la croissance axée produit (PLG), surtout lorsque votre produit n'a pas encore atteint le stade où "les gens parlent de vous", il est nécessaire de s'assurer que votre contenu a une valeur claire et un objectif pour votre audience. Évitez d'être trop centré sur vous-même.

Par exemple, au lieu de se concentrer sur pourquoi une fonctionnalité a été conçue, créez des articles éducatifs qui expliquent des termes spécifiques, ou des tutoriels qui montrent comment intégrer une technologie ou un outil cool pour résoudre un problème technique courant.

Au fur et à mesure que vous en apprenez davantage sur votre produit et vos clients, vous développerez naturellement des opinions fortes sur ce qui importe vraiment à votre audience. Adopter une approche « centrée sur le client » vous aidera à améliorer la qualité de votre contenu. Avec le temps, vous serez en mesure d'écrire du contenu qui résonne avec votre audience. Sinon, votre contenu risque de sembler égoïste.

Fonctionnalités ou meilleure pratique#

Le marketing traditionnel met souvent l'accent sur les « meilleures pratiques » ou les « solutions » lorsqu'il vend à des entreprises ou des individus, sur l'idée que les produits SaaS augmentent principalement l'efficacité et la productivité. De nombreuses stratégies se concentrent sur les chiffres, montrant des économies financières pour mettre en avant les avantages. Bien que cela puisse bien fonctionner pour les entreprises mûres avec une large base de clients, cela peut être rebutant pour les développeurs.

Il y a deux ans, je me concentrais fortement sur la construction de propositions de valeur et la création d'un récit global pour notre produit. Cependant, cette approche ne connectait pas toujours avec l'audience des développeurs.

Regardez la page Web que nous avions il y a 2 ans—"Façonner l'avenir"… Wow !

Pour satisfaire les développeurs et résoudre leurs problèmes, vous devez être très pratique et concret. Les développeurs ne sont pas influencés par de grands avantages ; ils s'intéressent à la disponibilité et à la flexibilité des fonctionnalités—spécifiquement, à quel point votre produit peut facilement s'intégrer dans leur stack technologique existant. Si ce n'est pas le cas, n'essayez pas de le vendre.

Désormais, notre stratégie de contenu est beaucoup plus concentrée. Nous mettons en avant les fonctionnalités spécifiques que nous proposons, permettant aux utilisateurs de comprendre rapidement ce que nous offrons dès le premier écran, sans compter sur les mots à la mode ou les messages de haut niveau.

La version open source est-elle une menace pour la version commerciale ?#

Lorsque nous avons lancé notre version commerciale hébergée, il y avait toujours un débat animé au sein de l'équipe : Est-ce que l'open source nuirait à notre version hébergée puisqu'elle est gratuite et que notre public cible est constitué de développeurs ? Nous avons également débattu de la possibilité de limiter certaines de nos fonctionnalités avancées dans la version open source.

Jusqu'à présent, nous avons gardé les fonctionnalités de base des versions open source et hébergée presque les mêmes. La croissance de notre communauté open source a permis de bâtir une confiance significative avec les prospects en entreprise, et davantage de grandes entreprises rejoignent. Fait intéressant, certaines de ces entreprises ont commencé comme développeurs dans notre communauté. Cela nous a donné beaucoup de confiance. Tant que nous continuons à créer de superbes produits, fournir d'excellents services et aider les développeurs à résoudre leurs problèmes, que ce soit par la croissance auto-service ou la vente directe aux entreprises, le succès viendra naturellement.

En fin de compte, tout est question de résoudre les problèmes des développeurs, que ce soit par le produit ou le service. Restez patient et concentré, et tout se mettra en place naturellement.

Merci d'avoir lu, et n'hésitez pas à partager vos expériences et vos réflexions si vous travaillez sur quelque chose de similaire !