Lärdomar av att lansera webbtjänster med ”invite only beta”

På suveräna Hacker News hittade jag en artikel av ett startup som berättade att de fått 18 000 betaanvändare på fyra veckor genom att ha en strategi som gick ut på att maila bloggare och erbjuda de invites att dela ut på sin blogg. Även om artikeln i sig inte tyder på någon vidare form av duktigt strategitänk när det kommer till att bygga användarbas eller att kommunicera med bloggare från det här startupföretaget, så är den ändå beviset på att konceptet ”invite only beta” återigen visat sig fungera.

Jag har varit med om två stora betalanseringar med invite only beta. Första gången var förra våren, då vi lanserade vårt bloggsök på Twingly.com. Andra gången var nu bara för en månad sedan, då vi lanserade Twingly Channels.

Båda gångerna har vi bestämt oss för att ha invite only beta ganska sent, samt av ungefär samma skäl. Dels har vi båda gångerna börjat jobba med förhållandevis tunga tekniker som vi inte hunnit testa ordentligt, som vi inte riktigt vet hur de ska fungera när vi börjar släppa på användare.

En annan relaterad aspekt har även varit att vi båda gångerna lanserat i ett ganska tidigt stadie, vi har haft tusentals fler features och saker att fixa men valt att lansera en så nedskalad version som möjligt för att få ut tjänsten fortare. Tredje anledningen var en ren kommunikationsfördel, och det är väl egentligen den vi har gemensamt med artikeln jag länkar till ovan, det är mer intressant för stora teknikbloggar etc att skriva om oss om de kan dela ut invites.

Så vad är lärdomarna av detta?

Även om vi inte har haft någon Spotify-succé med våra invites, med ett trånande efter invites fortfarande 2,5 år efter att de började bjuda in folk till tjänsten, så har invite only-strategin ändå varit värdefull för Twingly.

Om man kikar på första lanseringen: Dels gav det vårt devteam lite lugn och ro att arbeta utan att vara oroliga för att tjänsten inte skulle klara av pressen första tiden, dels är betaanvändare som är inbjudna mer villiga att dela med sig av feedback än ”vanliga” användare när tjänsten väl är öppen. Dessutom fick vi hjälp med prestandatester. PR-mässigt var det också en succé, coverage på Techcrunch och en rad andra bloggar. Jag och Martin var på The Next Web under lanseringen och delade bland annat ut invites, vilket helt klart var en bra grej. Att inte bara pitcha, vare sig det handlar om personer man träffar på en konferens eller journalister, utan även ”ge” något (i det här fallet invites) är helt klart en fördel som är svårslagen. Kort och gott: trots att det låter helt  idiotiskt att behöva logga in för att komma åt en sökmotor, så är vi idag glada för att vi gjorde som vi gjorde.

Nu när vi lanserade Channels valde vi att ha stängd invite only beta av ungefär samma anledningar. Nu tillåter vi inte heller alla att skapa kanaler, utan man får ansöka om att starta en kanal, trots att man så att säga har invite till själva tjänsten. Vilket dels är för att vi inte hunnit skala upp inhämtningen av rss-feeds men även för att skapa den sociala gemenskapskänslan. Vi bestämde att alla inte skulle få starta kanaler långt före vi bestämde oss för att ha invite only beta. Det beslutet blev ganska naturligt när tekniken krånglade mer än vi förutspådde och när alla satte upp varsin kanal baserat på sitt opml feed i första interna pre-alphan och tyckte sin egen var bäst, och hängde bara där. Det var då vi insåg att en strategi där vi tvingar användare att hänga tillsammans i de kanaler som redan finns, kanske krävs för att ge den upplevelse vi önskar tillhandahålla.

I Channels är dock den viktigaste aspekten när det gäller invites ur ett kommunikations- och användarbasskapande perspektiv att varje kanalägare bjuder in nya användare till sin kanal. Alla de som får starta en kanal, får invites att dela ut så deras bloggläsare, vänner eller kontaknät inom det ämnet/intresset som kanalen handlar om också kan vara med och interagera i kanalen. Desto fler som får skapa en kanal, desto fler användare får vi. Detta är dock inte en strategi ur intet, vi vill inte att våra kanalägare ska lita på oss att vi skaffar subscribers och användare med samma intresse att diskutera med till deras kanal.

Antagligen är kanalägaren betydligt duktigare på att bjuda in folk med samma intresse baserat på bloggläsare, kontaktnät, twitterfollowers etc och det är det beteendet vi vill skapa – att de bjuder in folk. Det är ett beteende vi vill behålla även när vi inte kräver invite för att komma åt tjänsten. Och förhoppningsvis kommer det även kännas än mer relevant när kanalägaren kan lägga kanalen som en undersida på sin blogg, får större rättigheter att styra i kanalen och helt enkelt får ut ”mer” av att vara kanalägare. Fler incitament att bjuda in nya användare.

Så, för att sammanfatta. Jag tycker inte man ska ha stängd beta enbart som marknadsföringsmetod. Har man som vi och Spotify dock skalbarhets- och teknikfunderingar, samt en strategi som går ut på att släppa ut tjänster i ett tidigt stadium för att få feedback och respons, är det helt klart något att rekommendera. Och då är det väldigt effektivt att använda det som marknadsföringsmetod, PR-strategi mot bloggar, sociala medier och early adopters. Dessutom, som vi nu försöker göra med Channels, för att skapa ett användarbeteende. Där är det för tidigt att säga om vi lyckas eller inte.

Fördelar:

  • Enklare att få PR, speciellt i bloggvärlden
  • Mer och bättre feedback
  • PR-mässigt två lanseringar, en betalansering och en publik lansering
  • Lättare att få en tjänst att bli viral, eftersom man hellre delar något ”av värde” (inbjudan) än en vanlig nyhet
  • Trygghet i att kunna släppa på användare i samma takt som man skalar upp tekniken
  • Tacksamhet, varje gång någon blir inbjuden känner de tacksamhet istället för skeptisk nyfikenhet, vilket gör användare väldigt förlåtande och snälla i sin bedömning
  • Gillas av early adopters
  • Förlänger hypen
  • Är effektivt för att kunna släppa på användare så tidigt som möjligt, innan tjänsten egentligen kanske är en riktigt bra produkt

Nackdelar:

  • Traditionell press inte lika villiga att skriva om tjänsten inte är publik än
  • Det går inte att jobba med ”traditionella” marknadsföringsmetoder som SEO, Adwords, bannerannonsering, tv-reklam etc förrän man är publika (eller har en premiumversion som man vill nya användare ska registrera sig på som hos Spotify)
  • Man riskerar att tappa många potentiella användare genom att inte låta alla bli medlemmar direkt
  • På samma ämne men mer konkret, PR konverterar inte lika bra
  • Gillas inte av icke-early adopters
Annonser

5 thoughts on “Lärdomar av att lansera webbtjänster med ”invite only beta”

  1. Pingback: Smurftips
  2. Intressant läsning! För mig personligen var Twinglys val av invite-strategi lite tråkigt. Channels lanserades vid ett tillfälle då jag på grund av ett pågående projekt verkligen var nyfiken på tjänsten, men jag fick ingen möjlighet att utforska channels just då eftersom den invite jag lite snällt bad om uteblev. När funktionen väl öppnades upp för allmänheten var den inte längre lika intressant – och faktum är att jag ännu inte har utforskat channels på det sätt jag borde ha gjort inför framtida projekt.

    Det är ingen feedback av värde, det vet jag. Och för att citera en av mina favoritkomiker: Jag är inte bitter. 🙂 Jag tror dock inte att den eventuella förlusten av användare (framför allt just early adopters) är någon större nackdel totalt sett. Den som har nytta av en tjänst, kommer att använda den när den väl blir tillgänglig. Vinsten av att kunna skala upp tjänsten långsamt borde vara mycket större, generellt sett.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s