Lessen en technieken geleerd bij het stimuleren van de groei van Logto met ontwikkelaars.
Logto is een open-source, ontwikkelaars-gerichte product. Hier is onze go-to-market tijdlijn:
Met een achtergrond in product-geleide groei voor productiviteitstools, hebben de teams en ik verschillende go-to-market strategieën geprobeerd voor Logto. Na twee jaar heb ik die inspanningen en de stappen die we namen, geëvalueerd. Ik wil een deel van die reis delen en uitleggen waarom sommige dingen destijds niet werkten. Dit zijn geen ‘fouten’, maar waardevolle lessen uit onze ervaring. Ik hoop dat deze inzichten anderen helpen die aan soortgelijke projecten of startups werken.
Wanneer je je product voor het eerst lanceert, vooral met een productgroei mentaliteit of enige ervaring, is het gemakkelijk om allerlei spannende ideeën te bedenken: fancy onboarding flows, een geweldige demo op de website, coole manieren om waarde aan gebruikers te laten zien en ze snel naar het “ah-ha” moment te brengen. Om ons product er gepolijst en klaar voor commercialisatie uit te laten zien, heb ik twee activatiestrategieën geïmplementeerd:
Deze strategieën waren zeer succesvol geweest in mijn eerdere ervaring. Dus toen Logto zijn cloud-gehoste versie lanceerde, paste ik ze onmiddellijk toe. Echter, ik ondervond enige verwarring en uitdagingen:
Voor ontwikkelaarsproducten is het moeilijk om een probleem in korte tijd op te lossen, zelfs als het echt self-service kan zijn. Zelfs voor een enkele ontwikkelaar omvat het proces verschillende fasen: integratie met de juiste tech stack, een proof of concept creëren, testen in een ontwikkelomgeving en vervolgens naar productie gaan. Op elk punt in deze reis kunnen gebruikers afhaken. Het “job-to-be-done” is geen eenvoudige, eenstapstaak. De behoeften van ontwikkelaars zijn vaak complex en vereisen een reeks functies of technische scenario's die een doordacht ontwerp vereisen dat gebruik maakt van onze bestaande mogelijkheden. Het oplossen van dergelijke problemen kost tijd en kan niet worden gehaast.
Terugkijkend is het duidelijk waarom deze aanpak niet is geslaagd. Toen we voor het eerst lanceerden, waren onze dagelijkse aanmeldingen en organische verkeer vrij laag. Het grootste deel van ons verkeer kwam uit de open-source gemeenschap, wat van nature niet grotere klanten meebracht. Het is geen verrassing dat we geen grotere klanten zagen die in deze fase afspraken boekten. Het lage verkeer en de bron van onze gebruikers maakten het onrealistisch om te verwachten dat er vroegtijdig significante boeking van afspraken zou zijn.
Kies het model dat bij je product past, op basis van de tijd die nodig is voor gebruikersactivatie. Laat je niet beperken door industrienormen.
Bij het bouwen van een SaaS-product is een van de belangrijkste go-to-market (GTM) vragen of je moet kiezen voor freemium of een gratis proefperiode. Algemene wijsheid suggereert:
We kozen aanvankelijk voor een freemium model voor een snelle lancering, waarbij een harde betaalmuur stond tussen de gratis en betaalde plannen. Echter, ontwikkelaars konden geen toegang krijgen tot geavanceerde functies zoals SSO of Organisatie in het gratis plan.
Hoewel er genoeg discussie online is over welk model beter is, is het cruciaal om een stap terug te doen en de activatietijdlijn van je product in overweging te nemen. Voor Logto hebben we geobserveerd dat in de echte wereld de testfase tot 6 maanden kan duren. Dit komt niet door de complexiteit van Logto, maar eerder door het werkrooster van engineers, projectplanning, teamwerkstromen en andere factoren die we niet hadden voorzien.
Gezien deze lange activatieperiode is het belangrijk om ontwikkelaars volledige toegang tot alle functies te geven voor testen. Daarom maken we volledig gebruik van de ontwikkelomgeving om de volledige mogelijkheden van het product te ontgrendelen. Dit is een gangbare praktijk voor ontwikkelaarstools, maar het is de moeite waard om op te merken omdat het uitlegt waarom traditionele freemium of gratis proefstrategieën mogelijk niet voor ons werken.
De keuze moet in lijn zijn met de aard van je product en de adoptietijdlijn ervan. Begrijp de unieke kenmerken van je product en kies een model dat past—niet een die gebruikers te snel door je conversietrechter duwt.
Een GTM uitvoeren met een bottom-up strategie betreft vaak SEO, productmarketing en contentmarketing. We weten allemaal dat het belangrijk is om vroeg te beginnen, dus we begonnen met het creëren van inhoud direct nadat we de open-source versie hadden gelanceerd. Maar toen we voor het eerst besloten om artikelen te schrijven, had ik een grote vraag: Waarover moet ik schrijven?
Als productontwerper was mijn instinct om te schrijven over waarom we bepaalde functies hebben ontworpen, om het gedachteproces en de filosofie erachter uit te leggen.
"In dit artikel bespreken we de geschiedenis van Sign-in Experience, inclusief de conceptie, ontwerpovertuigingen en productafwegingen. Je krijgt ook een beter begrip van hoe je een succesvolle en wrijvingsloze aanmeld- of registratie-ervaring kunt construeren." - Onze blogpost 2 jaar geleden De ontwerpoverwegingen voor een naadloze aanmeld-ervaring (Eerste Hoofdstuk)
Ik was enthousiast om mijn gedachten over onze functies en het ontwerp te delen omdat ik er zoveel moeite in had gestoken. Maar terugkijkend, realiseer ik me dat dit is wat je "zelfingenomen" inhoud zou noemen. Het is gebruikelijk in goed gevestigde bedrijven met een sterke EPD (Engineering, Product, Design) cultuur.
Als je product-geleide groei (PLG) uitvoert, vooral wanneer je product nog niet het stadium heeft bereikt waarin "mensen over je praten," is het noodzakelijk om ervoor te zorgen dat je inhoud duidelijke waarde en een doel heeft voor je publiek. Vermijd te veel focus op jezelf.
Bijvoorbeeld, in plaats van te focussen op waarom een functie is ontworpen, maak educatieve artikelen die specifieke termen uitleggen, of tutorials die laten zien hoe je een coole technologie of tool kunt integreren om een veelvoorkomend technisch probleem op te lossen.
Naarmate je meer leert over je product en klanten, ontwikkel je van nature sterke meningen over wat echt belangrijk is voor je publiek. Het behouden van een “klantgerichte” benadering zal je helpen de inhoudskwaliteit te verbeteren. Na verloop van tijd zul je in staat zijn inhoud te schrijven die resoneert met je publiek. Anders riskeert je inhoud zelfingenomen over te komen.
Traditionele marketing benadrukt vaak "beste praktijken" of "oplossingen" bij het verkopen aan bedrijven of individuen, gebaseerd op het idee dat SaaS-producten primair efficiëntie en productiviteit sturen. Veel strategieën richten zich op cijfers, waarbij financiële besparingen worden getoond om voordelen te benadrukken. Terwijl dit goed kan werken voor volwassen bedrijven met een brede klantenkring, kan het ontwikkelaars afschrikken.
Twee jaar geleden richtte ik me sterk op het bouwen van waardeproposities en het creëren van een groot verhaal voor ons product. Echter, deze aanpak resoneerde niet altijd met het ontwikkelaars publiek.
Kijk naar de webpagina die we 2 jaar geleden hadden—"Shaping the future"… Wauw!
Als het gaat om het tevreden stellen van ontwikkelaars en het oplossen van hun problemen, moet je zeer praktisch en geaard zijn. Ontwikkelaars laten zich niet beïnvloeden door verheven voordelen; ze geven om de beschikbaarheid en flexibiliteit van functies—specifiek, hoe gemakkelijk je product kan integreren in hun bestaande tech stack. Als dat niet het geval is, probeer het dan niet te verkopen.
Nu is onze contentstrategie veel meer gericht. We benadrukken de specifieke functies die we leveren, zodat gebruikers snel begrijpen wat we aanbieden vanaf het eerste scherm, zonder afhankelijk te zijn van modewoorden of gelaagde boodschappen.
Toen we voor het eerst onze gehoste commerciële versie lanceerden, was er altijd een verhitte discussie binnen het team: Zou open-source onze gehoste versie schaden omdat het gratis is en onze doelgroep ontwikkelaars zijn? We hebben ook gedebatteerd of we sommige van onze geavanceerde functies in de open-source versie moesten beperken.
Tot nu toe hebben we de kernfuncties van zowel de open-source als gehoste versies bijna hetzelfde gehouden. De groei van onze open-source gemeenschap heeft aanzienlijke vertrouwen opgebouwd bij zakelijke leads en meer grotere bedrijven stappen aan boord. Interessant genoeg begonnen enkele van deze ondernemingen als ontwikkelaars in onze gemeenschap. Dit heeft ons veel vertrouwen gegeven. Zolang we geweldige producten blijven bouwen, uitstekende diensten bieden en ontwikkelaars helpen hun problemen op te lossen, of het nu via self-service groei of directe zakelijke verkoop is, zal succes op natuurlijke wijze komen.
Uiteindelijk draait het allemaal om het oplossen van ontwikkelaarsproblemen, of het nu via product of dienst is. Blijf geduldig en gefocust, en alles zal van nature op zijn plaats vallen.
Bedankt voor het lezen en voel je vrij om je ervaringen en gedachten te delen als je aan iets soortgelijks werkt!