Lezioni e pratiche apprese nel guidare la crescita di Logto con gli sviluppatori.
Logto è un prodotto open-source incentrato sugli sviluppatori. Ecco la nostra timeline di go-to-market:
Venendo da un background nella crescita guidata dai prodotti per strumenti di produttività, io e i team abbiamo provato diverse strategie di go-to-market per Logto. Dopo due anni, ho riflettuto su quegli sforzi e sui passi che abbiamo intrapreso. Voglio condividere parte di quel viaggio e spiegare perché alcune cose non hanno funzionato all'epoca. Questi non sono "errori", ma preziose lezioni dalla nostra esperienza. Spero che queste intuizioni aiutino altri che lavorano a progetti simili o startup.
Quando lanci il tuo prodotto per la prima volta, specialmente con una mentalità di crescita del prodotto o una certa esperienza, è facile pensare a tutti i tipi di idee eccitanti: flussi di onboarding fantasiosi, una grande demo sul sito web, modi originali di evidenziare il valore per gli utenti e portarli rapidamente al momento "ah-ha". Per far sembrare il nostro prodotto raffinato e pronto per la commercializzazione, ho implementato due strategie di attivazione:
Queste strategie erano state molto efficaci nella mia esperienza passata. Quindi, quando Logto ha lanciato la sua versione cloud-hosted, le ho applicate immediatamente. Tuttavia, ho incontrato alcune confusioni e sfide:
Per i prodotti per sviluppatori, è difficile risolvere un problema in breve tempo anche se può essere veramente autonomo. Anche per un singolo sviluppatore, il processo coinvolge diverse fasi: integrazione con lo stack tecnologico giusto, creazione di una prova di concetto, test in un ambiente di sviluppo e poi passaggio alla produzione. In qualsiasi punto di questo viaggio, gli utenti possono abbandonare. Il "job-to-be-done" non è un compito semplice e univoco. Le esigenze degli sviluppatori sono spesso complesse, richiedendo una gamma di funzionalità o scenari tecnici che necessitano di un design ponderato sfruttando le nostre capacità esistenti. Risolvere tali problemi richiede tempo e non può essere affrettato.
Riguardando indietro, è chiaro perché questo approccio non ha avuto successo. Quando abbiamo lanciato per la prima volta, le nostre iscrizioni giornaliere e il traffico organico erano piuttosto bassi. La maggior parte del nostro traffico proveniva dalla comunità open-source, che naturalmente non portava grandi clienti. Non sorprende che non abbiamo visto grandi clienti prenotare chiamate durante questa fase. Il basso traffico e la fonte dei nostri utenti rendevano irrealistico aspettarsi prenotazioni di chiamate significative all'inizio.
Scegli il modello che si adatta al tuo prodotto, in base al tempo necessario per l'attivazione dell'utente. Non lasciare che le norme del settore ti limitino.
Quando si costruisce un prodotto SaaS, una delle domande chiave di go-to-market (GTM) è se scegliere freemium o una prova gratuita. La saggezza comune suggerisce:
Inizialmente abbiamo scelto un modello freemium per un lancio rapido, posizionando un paywall rigido tra i piani gratuiti e quelli a pagamento. Tuttavia, gli sviluppatori non potevano accedere a funzionalità avanzate come SSO o Organization nel livello gratuito.
Anche se c'è un ampio dibattito online su quale modello sia migliore, è fondamentale fare un passo indietro e considerare la timeline di attivazione del tuo prodotto. Per Logto, abbiamo osservato che nel mondo reale, la fase di test può durare fino a 6 mesi. Questo non è dovuto alla complessità di Logto, ma piuttosto al programma di lavoro dell'ingegnere, alla pianificazione del progetto, ai flussi di lavoro del team e ad altri fattori che non avevamo previsto.
Dato questo lungo periodo di attivazione, è importante fornire agli sviluppatori pieno accesso a tutte le funzionalità per i test. Ecco perché utilizziamo completamente il tenant di sviluppo per sbloccare le capacità complete del prodotto. Questa è una pratica comune per gli strumenti per sviluppatori, ma vale la pena notare che spiega perché le strategie tradizionali di freemium o prova gratuita potrebbero non funzionare per noi.
La scelta dovrebbe allinearsi alla natura del tuo prodotto e alla sua timeline di adozione. Comprendi le caratteristiche uniche del tuo prodotto e scegli un modello che si adatti, non uno che spinga gli utenti troppo velocemente attraverso il tuo funnel di conversione.
Eseguire un GTM con una strategia dal basso verso l'alto spesso coinvolge SEO, marketing di prodotto e content marketing. Sappiamo tutti che è importante iniziare presto, quindi abbiamo iniziato a creare contenuti subito dopo il lancio della versione open-source. Ma quando abbiamo deciso per la prima volta di scrivere articoli, avevo una grande domanda: Cosa dovrei scrivere?
Come product designer, il mio istinto era di scrivere sul perché abbiamo progettato certe funzionalità, spiegando il processo di pensiero e la filosofia dietro di esse.
"In questo articolo, esamineremo la storia dell'Esperienza di Accesso, inclusa la sua concezione, le decisioni di design e i compromessi del prodotto. Acquisirete anche una migliore comprensione di come costruire un'esperienza di accesso o registrazione di successo e senza attriti." - Il nostro post sul blog 2 anni fa Le considerazioni di design per un'esperienza di accesso senza interruzioni (Primo Capitolo)
Ero ansioso di condividere i miei pensieri sulle nostre funzionalità e design perché avevo messo così tanto impegno in esse. Ma guardando indietro, mi rendo conto che questo è ciò che chiameresti contenuto "egocentrico". È comune in aziende ben affermate con una forte cultura EPD (Engineering, Product, Design).
Se stai facendo crescita guidata dai prodotti (PLG), specialmente quando il tuo prodotto non ha ancora raggiunto la fase in cui "la gente parla di te", è necessario assicurarsi che il tuo contenuto abbia un chiaro valore e un obiettivo per il tuo pubblico. Evita di essere troppo auto-focalizzato.
Ad esempio, invece di concentrarti sul perché una funzionalità è stata progettata, crea articoli educativi che spieghino termini specifici, o tutorial che mostrino come integrare una tecnologia o uno strumento interessante per risolvere un problema tecnico comune.
Man mano che impari di più sul tuo prodotto e sui clienti, svilupperai naturalmente opinioni forti su ciò che conta davvero per il tuo pubblico. Mantenere un approccio "centrato sul cliente" ti aiuterà a migliorare la qualità del contenuto. Nel tempo, sarai in grado di scrivere contenuti che risuonano con il tuo pubblico. Altrimenti, il tuo contenuto rischia di sembrare egocentrico.
Il marketing tradizionale spesso enfatizza "migliori pratiche" o "soluzioni" quando si vendono a aziende o individui, basato sull'idea che i prodotti SaaS guidino principalmente l'efficienza e la produttività. Molte strategie si concentrano sui numeri, mostrando risparmi economici per evidenziare i benefici. Anche se questo può funzionare bene per aziende mature con una vasta base di clienti, può essere scoraggiante per gli sviluppatori.
Due anni fa, mi sono concentrato molto sulla costruzione di proposte di valore e sulla creazione di una narrativa generale per il nostro prodotto. Tuttavia, questo approccio non sempre collegava con il pubblico degli sviluppatori.
Guarda la pagina web che avevamo 2 anni fa—"Plasmando il futuro"… Wow!
Quando si tratta di soddisfare gli sviluppatori e risolvere i loro problemi, è necessario essere molto pratici e con i piedi per terra. Gli sviluppatori non sono influenzati dai benefici elevati; si preoccupano della disponibilità e della flessibilità delle funzionalità—specificamente, quanto facilmente il tuo prodotto può integrarsi nel loro stack tecnologico esistente. Se non può, non cercare di venderlo.
Ora, la nostra strategia di contenuto è molto più focalizzata. Sottolineiamo le caratteristiche specifiche che forniamo, permettendo agli utenti di capire velocemente cosa offriamo dal primo schermo, senza fare affidamento su parole d'ordine o messaggi di alto livello.
Quando abbiamo lanciato per la prima volta la nostra versione commerciale ospitata, c'era sempre una discussione accesa all'interno del team: l'open-source danneggerà la nostra versione ospitata siccome è gratuita e il nostro target di riferimento sono gli sviluppatori? Abbiamo anche discusso se limitare alcune delle nostre funzionalità avanzate nella versione open-source.
Finora, abbiamo mantenuto le funzionalità core di entrambe le versioni open-source e ospitate quasi le stesse. La crescita della nostra comunità open-source ha costruito una fiducia significativa con i lead aziendali, e sempre più grandi aziende stanno salendo a bordo. Curiosamente, alcune di queste aziende hanno iniziato come sviluppatori nella nostra comunità. Questo ci ha dato molta fiducia. Finché continuiamo a costruire grandi prodotti, fornire servizi eccellenti e aiutare gli sviluppatori a risolvere i loro problemi, che sia attraverso la crescita autosufficiente o le vendite dirette alle imprese, il successo verrà naturalmente.
Alla fine, si tratta di risolvere i problemi degli sviluppatori, sia attraverso il prodotto che il servizio. Resta paziente e concentrato, e tutto andrà al suo posto naturalmente.
Grazie per aver letto e sentiti libero di condividere le tue esperienze e i tuoi pensieri se stai lavorando su qualcosa di simile!