5 go-to-market-lektioner jag lärde mig av att driva en utvecklarledd tillväxtprodukt

Logto är en öppen källkods-, utvecklarfokuserad produkt. Här är vår go-to-market-tidslinje:

1. Vi släppte den öppna källkodsversionen i juli 2022.
2. I januari 2023 lanserade vi molnförhandsvisningen (beta cloud).
3. I juli 2023 var den produktionsklar med fullständig prissättning.

Med bakgrund i produktledd tillväxt för produktivitetstjänster provade teamen och jag olika go-to-market-strategier för Logto. Efter två år har jag reflekterat över de insatserna och de steg vi tog. Jag vill dela med mig av en del av den resan och förklara varför vissa saker inte fungerade då. Dessa är inte "misstag", utan värdefulla lärdomar från vår erfarenhet. Jag hoppas att dessa insikter kan hjälpa andra som arbetar med liknande projekt eller startups.

Traditionella onboarding-strategier kanske inte fungerar#

När du först lanserar din produkt, särskilt med ett produktväxt-mentalitet eller viss erfarenhet, är det lätt att tänka på alla typer av spännande idéer: coola onboarding-flöden, en fantastisk demo på webbplatsen, häftiga sätt att framhäva värde för användare och få dem till "ah-ha"-ögonblicket snabbt. För att få vår produkt att se polerad ut och redo för kommersialisering implementerade jag två aktiveringsstrategier:

1. Job-to-be-done-onboarding, så att användare kan lösa sina problem direkt.
2. Under onboarding, inkludera alternativ som "boka ett samtal" eller "maila oss" för mänsklig kontakt för att öka konverteringsfrekvensen — något som fungerar bra med större företag.

Dessa strategier hade varit mycket framgångsrika i min tidigare erfarenhet. Så när Logto lanserade sin molnvärdade version, tillämpade jag dem omedelbart. Men jag stötte på viss förvirring och utmaningar:

1. Vad är exakt Logtos "job-to-be-done"? Till skillnad från enkla produkter som produktivitetsverktyg (t.ex. skriva dokument eller skapa konstverk), handlar Logto om att bygga autentiseringssystem eller hantera användaridentiteter. Men hur kan användare åstadkomma detta på bara en dag?
2. Visst, vi lade till en Calendly-länk för att boka samtal, men vi fick inte många bokningar, och det ökade inte vår konverteringsgrad som förväntat.

Varför #1 inte fungerar#

För utvecklarprodukter är det svårt att lösa ett problem på kort tid, även om det verkligen kan vara självbetjänande. Även för en enskild utvecklare innebär processen flera stadier: integrera med rätt teknikstack, skapa ett proof of concept, testa i en utvecklingsmiljö, och sedan gå till produktion. När som helst under denna resa kan användarna avbryta. "Job-to-be-done" är inte en enkel, enstegsuppgift. Utvecklarbehov är ofta komplexa och kräver en rad funktioner eller tekniska scenarier som behöver genomtänkt design med hjälp av våra befintliga funktioner. Att lösa sådana problem tar tid och kan inte forceras.

Varför #2 inte fungerar#

I efterhand är det tydligt varför detta tillvägagångssätt inte lyckades. När vi först lanserade var våra dagliga registreringar och organiska trafik ganska låg. Det mesta av vår trafik kom från open-source-communityn, som naturligtvis inte tog in större kunder. Det är inte förvånande att vi inte såg större kunder boka samtal i detta skede. Den låga trafiken och användarnas källa gjorde det orealistiskt att förvänta sig betydande samtalsbokningar tidigt.

Freemium eller gratis provperiod? Innan du kämpar, förstå din produkt först#

Välj den modell som passar din produkt baserat på den tid som behövs för användaraktivering. Låt inte branschnormer begränsa dig.

När man bygger en SaaS-produkt är en av de viktigaste go-to-market (GTM) frågorna om man ska välja freemium eller en gratis provperiod. Gemensam visdom föreslår:

1. Gratis provperiod: Användare får full tillgång under en begränsad tid, sedan måste de betala för att fortsätta.
   • Bäst för: Komplexa eller premiumprodukter där användare behöver uppleva alla funktioner för att se värdet.
2. Freemium: Användare får tillgång till en grundversion gratis, med betalda uppgraderingar för avancerade funktioner.
   • Bäst för: Produkter med ett brett utbud av funktioner, där gratisanvändare kan uppgradera när deras behov växer.

Vi valde initialt en freemium-modell för en snabb lansering, med en hård betalvägg mellan gratis- och betalda planer. Utvecklare kunde dock inte få åtkomst till avancerade funktioner som SSO eller Organisation i gratisnivån.

Även om det finns mycket debatt online om vilken modell som är bättre, är det avgörande att ta ett steg tillbaka och överväga produktens aktiveringstidslinje. För Logto har vi observerat att testfasen i verkligheten kan pågå upp till 6 månader. Detta beror inte på Logtos komplexitet utan snarare ingenjörens arbetsschema, projektplanering, teamarbetsflöden och andra faktorer vi inte hade förutsett.

Med denna långa aktiveringstid är det viktigt att ge utvecklare full tillgång till alla funktioner för testning. Därför använder vi utvecklingstennanten fullt ut för att låsa upp produktens fulla kapacitet. Detta är en vanlig praxis för utvecklarverktyg men värt att notera eftersom det förklarar varför traditionella freemium- eller gratis provperiodsstrategier kanske inte fungerar för oss.

Valet bör ligga i linje med din produkts natur och antagandetidslinje. Förstå din produkts unika egenskaper och välj en modell som passar—inte en som trycker användare för snabbt genom din konverteringstratt.

Om du inte förstår dina kunder kommer ditt innehåll att framstå som självcetrerat#

Att genomföra en GTM med en nedifrån och upp-strategi innebär ofta SEO, produktmarknadsföring och innehållsmarknadsföring. Vi vet alla att det är viktigt att starta tidigt, så vi började skapa innehåll direkt efter lansering av open-source-versionen. Men när vi först bestämde oss för att skriva artiklar hade jag en stor fråga: Vad ska jag skriva?

Som produktdesigner var min instinkt att skriva om varför vi designade vissa funktioner, förklara tankegången och filosofin bakom dem.

"I den här artikeln kommer vi gå över historien om inloggningsupplevelse, inklusive dess konception, designbeslut och produktavvägningar. Du kommer också att få en bättre förståelse för hur man konstruerar en framgångsrik och sömlös inloggnings- eller registreringsupplevelse." - Vårt blogginlägg för 2 år sedan Designöverväganden för en sömlös inloggningsupplevelse (Första kapitlet)

Jag var ivrig att dela mina tankar om våra funktioner och design eftersom jag lagt ner så mycket ansträngning på dem. Men i efterhand inser jag att detta är vad du skulle kalla "självupptaget" innehåll. Det är vanligt i väletablerade företag med en stark EPD (Engineering, Product, Design) kultur.

Om du gör produktledd tillväxt (PLG), särskilt när din produkt ännu inte nått stadiet där "folk pratar om dig", är det nödvändigt att se till att ditt innehåll har tydligt värde och ett mål för din publik. Undvik att vara för självfokuserad.

Till exempel, istället för att fokusera på varför en funktion designades, skapa utbildande artiklar som förklarar specifika termer, eller handledningar som visar hur man integrerar en cool teknik eller verktyg för att lösa ett vanligt tekniskt problem.

När du lär dig mer om din produkt och kunder kommer du naturligtvis att utveckla starka åsikter om vad som verkligen betyder något för din publik. Att hålla ett “kundcentriert” tillvägagångssätt kommer att hjälpa dig att förbättra innehållskvaliteten. Med tiden kommer du att kunna skriva innehåll som resonera med din publik. Annars riskerar ditt innehåll att kännas självupptaget.

Funktioner eller bästa praxis#

Traditionell marknadsföring betonar ofta "bästa praxis" eller "lösningar" när man säljer till företag eller individer, baserat på idén att SaaS-produkter främst driver effektivitet och produktivitet. Många strategier fokuserar på siffror och visar finansiella besparingar för att lyfta fram fördelarna. Även om detta kan fungera bra för mogna företag med en bred kundbas kan det vara störande för utvecklare.

För två år sedan fokuserade jag mycket på att bygga värdeerbjudanden och skapa en stor bild-narrativ för vår produkt. Men detta tillvägagångssätt kopplade inte alltid med utvecklarpubliken.

Titta på webbsidan vi hade för 2 år sedan—"Forma framtiden"… Wow!

När det gäller att tillfredsställa utvecklare och lösa deras problem måste du vara mycket praktisk och jordnära. Utvecklare påverkas inte av högtflygande fördelar; de bryr sig om funktions tillgänglighet och flexibilitet — specifikt, hur enkelt din produkt kan integreras i deras befintliga teknikstack. Om den inte kan det, försök inte sälja den.

Nu är vår innehållsstrategi mycket mer fokuserad. Vi framhäver de specifika funktionerna vi erbjuder, vilket möjliggör för användare att snabbt förstå vad vi erbjuder från första skärmen utan att förlita sig på modeord eller hög-nivå-meddelanden.

Är den öppna källkodsversionen ett hot mot den kommersiella versionen?#

När vi först lanserade vår värdade kommersiella version fanns det alltid en het diskussion inom teamet: Skulle öppen källkod skada vår värdade version eftersom den är gratis, och vår målgrupp är utvecklare? Vi diskuterade också om vi skulle begränsa några av våra avancerade funktioner i den öppna källkodsversionen.

Hittills har vi behållit kärnfunktionerna i både den öppna källkod och värdade versionen nästan samma. Tillväxten av vårt open-source community har byggt stort förtroende med företagsledningar, och fler större företag kommer ombord. Intressant nog började några av dessa företag som utvecklare i vårt community. Detta har gett oss mycket förtroende. Så länge vi fortsätter att bygga bra produkter, tillhandahålla utmärkta tjänster och hjälpa utvecklar att lösa deras problem, oavsett om det är genom självbetjänings tillväxt eller direkt företagsförsäljning, kommer framgången naturligt.

I slutändan handlar det om att lösa utvecklarens problem, antingen genom produkt eller tjänst. Var tålmodig och fokuserad, så kommer allt att falla på plats naturligt.

Tack för att du läste, och dela gärna dina erfarenheter och tankar om du arbetar med något liknande!