Oppitunteja ja käytäntöjä, jotka on opittu Logton kasvattamisessa kehittäjien kanssa.
Logto on avoimen lähdekoodin, kehittäjille suunnattu tuote. Tässä on meidän markkinoille tulo -aikataulumme:
Kokemukseni pohjalta tuotettä johtavasta kasvusta tuottavuustyökaluille, tiimit ja minä kokeilimme erilaisia markkinoille tulo -strategioita Logton osalta. Kahden vuoden jälkeen olen pohtinut näitä ponnisteluja ja ottamiamme askeleita. Haluan jakaa osan tuosta matkasta ja selittää, miksi jotkin asiat eivät toimineet tuolloin. Nämä eivät ole "virheitä", vaan arvokkaita oppitunteja kokemuksestamme. Toivon, että nämä näkemykset auttavat muita, jotka työskentelevät samanlaisten projektien tai startup-yritysten parissa.
Kun julkaiset tuotteesi ensimmäistä kertaa, etenkin kasvuhenkisellä ajattelutavalla tai kokemuksella, on helppoa miettiä kaikenlaisia jännittäviä ideoita: hienoja perehdytysvirtoja, mahtava demo verkkosivustolla, hienoja tapoja korostaa arvoa käyttäjille ja saada heidät nopeasti "ah-ha"-hetkeen. Jotta tuotteemme näyttäisi viimeistellyltä ja valmiilta kaupallistamiseen, toteutin kaksi aktivointistrategiaa:
Nämä strategiat olivat olleet erittäin menestyksekkäitä aiemmassa kokemuksessani. Joten kun Logto julkaisi pilvitoteutuksensa, sovelsin niitä heti. Kuitenkin kohtasin jonkin verran hämmennystä ja haasteita:
Kehittäjätuotteiden kohdalla on vaikeaa ratkaista ongelmaa lyhyessä ajassa, vaikka se olisi todella omatoiminen. Jopa yksittäiselle kehittäjälle prosessi sisältää useita vaiheita: oikean teknologiapinon integroinnista, konseptiprototyypin luomisesta, testaamisesta kehitysympäristössä ja sitten tuotantoon siirtymiseen. Missä tahansa tässä matkan vaiheessa käyttäjät voivat keskeyttää. "Job-to-be-done" ei ole yksinkertainen, yhden askeleen tehtävä. Kehittäjien tarpeet ovat usein monimutkaisia, ja ne vaativat joukon ominaisuuksia tai teknisiä skenaarioita, jotka edellyttävät harkittua suunnittelua olemassa olevien kykyjemme hyödyntämiseksi. Tällaisten ongelmien ratkaiseminen vie aikaa eikä sitä voi kiirehtiä.
Kun katsomme taaksepäin, on selvää, miksi tämä lähestymistapa ei onnistunut. Kun julkaisimme ensimmäistä kertaa, päivittäiset rekisteröintimme ja orgaaninen liikenteemme olivat melko alhaisia. Suurin osa liikenteestämme tuli avoimen lähdekoodin yhteisöstä, mikä ei luonnollisesti tuonut mukaan suurempia asiakkaita. Ei ole yllätys, että emme nähneet suuremmissa asiakkaissa soittoajanvarauksia tässä vaiheessa. Alhainen liikenne ja käyttäjien lähdelähteemme tekivät epärealistiseksi odottaa merkittävämpiä puheluajavarauksia alussa.
Valitse malli, joka sopii tuotteeseesi, perustuen käyttäjäaktivoinnin vaatimaasi aikaan. Älä anna teollisuuden normien rajoittaa itseäsi.
Kun rakennat SaaS-tuotetta, yksi keskeisistä markkinoille tulo -kysymyksistä on, valitako freemium- vai ilmainen kokeiluversio. Yleinen viisaus ehdottaa:
Aluksi valitsimme freemium-mallin nopeaa julkaisua varten, asettaen kovan maksuseinän ilmaisten ja maksettujen suunnitelmien välille. Kehittäjät eivät kuitenkaan voineet käyttää edistyneitä ominaisuuksia, kuten SSO:ta tai Organisaatiota ilmaisessa tasossa.
Vaikka verkossa on paljon keskustelua siitä, kumpi malli on parempi, on tärkeää astua taaksepäin ja harkita tuotteesi aktivointiaikataulua. Logton tapauksessa olemme huomanneet, että testausvaihe voi kestää jopa 6 kuukautta. Tämä ei johdu Logton monimutkaisuudesta, vaan pikemminkin insinöörin työaikataulusta, projektin suunnittelusta, tiimin työnkulusta ja muista tekijöistä, joita emme olleet ennakoineet.
Kun otetaan huomioon tämä pitkä aktivointijakso, on tärkeää tarjota kehittäjille täysi pääsy kaikkiin ominaisuuksiin testaukselle. Siksi käytämme täysin kehitysvuokraajaa tuotteen täydellisten kykyjen avaamiseksi. Tämä on yleinen käytäntö kehittäjätyökaluille, mutta huomionarvoista, koska se selittää, miksi perinteiset freemium- tai ilmainen kokeiluversio -strategiat eivät välttämättä toimi meille.
Valinnan tulisi olla linjassa tuotteesi luonteen ja sen käyttöönottotavoitteen kanssa. Ymmärrä tuotteesi ainutlaatuiset ominaisuudet ja valitse malli, joka sopii - ei sellainen, joka työntää käyttäjiä liian nopeasti konversioputkesi läpi.
Alhaalta ylöspäin strategian toteuttaminen GTM:ssä sisältää usein SEO:ta, tuote- ja sisältömarkkinointia. Me kaikki tiedämme, että on tärkeää aloittaa aikaisin, joten aloitimme sisällön luomisen heti avoimen lähdekoodin version julkaisun jälkeen. Mutta kun ensin päätimme kirjoittaa artikkeleita, minulla oli iso kysymys: Mitä minun pitäisi kirjoittaa?
Tuotesuunnittelijana intuitiivinen ajatukseni oli kirjoittaa siitä, miksi suunnittelimme tietyt ominaisuudet, selittäen ajatukset ja filosofia niiden takana.
"Tässä artikkelissa käymme läpi kirjautumiskokemuksen historiaa, mukaan lukien sen käsitteen, suunnittelupäätökset ja tuotekompromissit. Saat myös paremman käsityksen siitä, kuinka rakentaa onnistunut ja kitkaton kirjautumis- tai rekisteröitymiskokemus." - Blogipostauksemme 2 vuotta sitten Sujuvan kirjautumiskokemuksen suunnittelua koskevat näkökohdat (Ensimmäinen luku)
Olin innokas jakamaan ajatuksiani ominaisuuksistamme ja suunnittelustamme, koska panostin niihin niin paljon. Mutta kun katson taaksepäin, tajuan, että tämä on mitä kutsuisit "itsekeskeiseksi" sisällöksi. Se on yleistä vakiintuneissa yrityksissä, joissa on vahva EPD (Engineering, Product, Design) -kulttuuri.
Jos teet tuotettä johtavaa kasvua (PLG), etenkin kun tuotteesi ei ole vielä saavuttanut sitä vaihetta, jossa "ihmiset puhuvat sinusta", on välttämätöntä varmistaa, että sisällölläsi on selkeä arvo ja tavoite yleisöllesi. Vältä olemasta liian itsekeskeinen.
Esimerkiksi keskittymällä siihen, miksi ominaisuus suunniteltiin, luo opettavaisia artikkeleita, jotka selittävät tiettyjä termejä, tai tutoriaaleja, jotka osoittavat, kuinka integroida hieno teknologia tai työkalu yleisen teknisen ongelman ratkaisemiseksi.
Kun opit enemmän tuotteestasi ja asiakkaistasi, luonnostaan kehität vahvoja mielipiteitä siitä, mikä todella on tärkeää yleisöllesi. Asiakaslähtöinen lähestymistapa auttaa parantamaan sisältösi laatua. Ajan myötä pystyt kirjoittamaan sisältöä, joka resonoi yleisösi kanssa. Muutoin sisältösi uhkaa tuntua itsekeskeiseltä.
Perinteinen markkinointi korostaa usein "parhaita käytäntöjä" tai "ratkaisuja", kun myydään yrityksille tai yksityishenkilöille, perustuen ajatukseen, että SaaS-tuotteet ajavat ensisijaisesti tehokkuutta ja tuottavuutta. Monet strategiat keskittyvät numeroihin ja osoittavat taloudellisia säästöjä korostaakseen etuja. Vaikka tämä voi toimia hyvin vakiintuneille yrityksille, joilla on laaja asiakaskunta, se voi olla kehittäjille karkottavaa.
Kaksi vuotta sitten keskityin voimakkaasti arvolupausten rakentamiseen ja suuren kuvan narratiivin luomiseen tuotteellemme. Tämä lähestymistapa ei kuitenkaan aina yhdistänyt kehittäjäyleisöä.
Katso, millainen web-sivustomme oli 2 vuotta sitten - "Muovaamassa tulevaisuutta"… Vaau!
Kun kyse on kehittäjien tyydyttämisestä ja heidän ongelmiensa ratkaisemisesta, sinun täytyy olla erittäin käytännöllinen ja jalat maassa. Kehittäjät eivät ole kiinnostuneita korkeista hyödyistä; he välittävät ominaisuuksien saatavuudesta ja joustavuudesta - erityisesti siitä, kuinka helposti tuotteesi voi integroitua heidän olemassa olevaan teknologiaansa. Jos se ei voi, älä yritä myydä sitä.
Nyt sisältöstrategiamme on paljon keskittyneempi. Korostamme tarjoamamme erityiset ominaisuudet, jotta käyttäjät voivat nopeasti ymmärtää, mitä tarjoamme ensimmäisestä näytöstä alkaen, luottamatta iskusanoihin tai korkeatasoisiin viesteihin.
Kun lanseerasimme ensimmäisen kerran isännöityä kaupallista versiota, tiimissä käytiin aina kiivasta keskustelua: Haittaisiko avoin lähdekoodi isännöityä versiotamme, koska se on ilmainen, ja kohderyhmämme on kehittäjiä? Keskustelimme myös, pitäisikö meidän rajoittaa jotkin edistyneistä ominaisuuksistamme avoimen lähdekoodin versiossa.
Toistaiseksi olemme pitäneet ydintoiminnot lähes samoina sekä avoimen lähdekoodin että isännöidyssä versiossa. Avoimen lähdekoodin yhteisömme kasvu on rakentanut merkittävää luottamusta yritysjohteiden keskuudessa, ja yhä suuremmat yritykset tulevat mukaan. Mielenkiintoista on, että jotkut näistä yrityksistä alkoivat kehittäjinä yhteisössämme. Tämä on antanut meille paljon luottamusta. Niin kauan kuin jatkamme suurenmoisten tuotteiden rakentamista, tarjoamme erinomaista palvelua ja autamme kehittäjiä ratkaisemaan ongelmansa, riippumatta siitä, onko kyse omatoimisesta kasvusta tai suorasta yritysmyynnistä, menestys tulee luonnollisesti.
Lopulta on kyse kehittäjien ongelmien ratkaisemisesta, riippumatta siitä, tekeekö sen tuote tai palvelu. Pysy kärsivällisenä ja keskittyneenä, ja kaikki loksahtaa luonnollisesti paikoilleen.
Kiitos lukemisesta, ja jaa vapaasti kokemuksesi ja ajatuksesi, jos työskentelet jonkin vastaavan parissa!