Lansering av ny tjänst - framtida funktionalitet
 

När ni lanserar en ny tjänst, brukar ni då lansera allting som är färdigt vid lanseringstillfället eller håller ni hellre inne på en del färdiga funktioner för att kunna lansera ny funktionalitet snabbare allteftersom? Varför har ni valt att göra på det ena eller andra sättet?

Jag gör alltid en s.k. MVP, minimum viable product, dvs det minsta som krävs för att målgruppen ska få ut någonting av tjänsten. Finns ingen intresse för denna produkt så lägger jag ner redan där.

Den senaste tjänsten jag jobbar med tog drygt 2 veckor för mig att bygga en MVP.

Någon "produkt" var en "kommer snart"-sida med ett formulär för att samla in e-postadresser. Fick aldrig tillräckligt många för att motivera att jobba med den tjänsten, så jag la ner den.

Jag ser ingen anledning att hålla inne på funktionalitet om den är klar, ut med koden och kolla om användarna använder tjänsten som förväntat.

Boken "The Lean Startup" pratar om Build - Measure - Learn i en cirkel och det är precis så jag tror man ska bygga webbtjänster.

Jag tror verkligen inte på att bygga och finpolera i ett halvår innan man släpper någonting som man inte vet om användarna vill ha, släpp det du har och lyssna på användarna, ta betalt när din tjänst tillför värde.

Jag har iofs bara 1 värdig produkt som jag säljer och den är komplett i sitt originalutförande så syftet med produkten uppfylls (en SaaS). Men man kan köpa till tjänster, och där så vet jag att det jag idag har kan bli mycket mer. Men det är tillräckligt med extra tjänster för att locka till sig intresse (hoppas jag).

Ska du bygga något halvfärdigt så kan du väl lansera det som "Beta", det i sig är ju ibland ett PR-trick att kalla något redan väl fungerande som Beta.

37 Signals (skapare av flera lyckade webbappar) skrev för några år sedan en bok "Getting Real" som alla nätentreprenörer bör ha läst. Den finns publicerad här: https://gettingreal.37signals.com/toc.php

Den beskriver processen från idé via utveckling och lansering till förvaltning. Läs den! :-)

Men för att svara på dina frågor så brukar jag köra efter konceptet "release early, release often". Det brukar jag dock krydda med någon form av lanseringsplan för att öka exponering och intresse för produkten.

Det fungerar bra med enklare och mer experimentella tjänster men handlar det om större projekt så är det omöjligt att lansera något annat än skräp om man sätter en väldigt kort tidsgräns och då kommer man att misslyckas oavsett om idén i sig faktiskt är bra. Har man flera stora konkurrenter så krävs också en helt annan approach än om man är ny inom ett område.

Det där är en strategi jag tror mycket på själv också. Att man levererar ett hyfsat komplett paket från start men att det sedan finns ett antal planerade tilläggstjänster / produkter som ger mervärde.

Hur länge arbetade du med din produkt innan du lanserade? Var anledningen till att du väntade att du inte var nöjd med produkten eller fanns det andra orsaker?

Den har jag läst och håller med om den är läsvärd men det är oftast mer intressant att lyssna till flera röster än en :)

Kör du en öppen och publik lanseringsplan menar du eller menade du bara att du har en sådan för dig själv redan från början?

Min erfarenhet är att "mer" funktioner inte generellt är nyckel för att lyckas. Jag tycker utmaningen ligger i att hitta vad målgruppen verkligen vill ha, och sen förfina det i rätt riktning. Det jag försöker säga är att om man har en färdig tjänst med så många icke-core funktioner färdiga liggades som är oprövade, att man kan vänta med att släppa dem. Så tror jag att man hade haft mer ut av att släppa tjänsten tidigare med bara core klart, för att komma ut tidigare är mkt värt. Sen kan man prova en ny sak i taget.

Det viktiga är ju att det som är "gratis" eller som ingår i ett standardpris fortfarande är en bra grund och start för det kunden söker. Så man får inte vara för snål. Utan extrafunktionerna får ju vara specifika, spetsfunktioner. I mitt fall integration med bokföringssystem, bokföringsunderlag, nyhetsbrevsfunktion (kostar ju att skicka), men även SMS.
Det är ett bokningssystem.

Det är dock fortfarande i Beta, från tidigare Alpha där endast nära vänner och kontakter fått testa det. Det har pågått i 2 år nu och först nu börjar jag göra det färdigt nog för att låta vem som helst använda. Och det i sig kräver ju ett admin GUI så man kan hantera alla potentiella klienter. Det ska vara självadministration genom att hantera sitt "abonnemang" via sitt login osv.

Det jag insett är ju att ju fler funktioner man skapar, ju mer underhåll måste man göra. Så jag har börjat bli lite försiktig och ska nu istället jobba så att allting är 100% "perfekt" och så lite buggar som möjligt. Samt arbeta på att allt är användarvänligt, så pass så man begränsar antalet support-förfrågans som kommer in. För ett dåligt system, generar väldigt mycket administration. Så det vill jag bort ifrån genom att garantera en väl fungerande produkt.

Håller med dig helt och hållet. Att minimera supporttid är extremt viktigt i ett litet företag, det avhjälper man bäst genom att snabbt fixa eventuella buggar och ett användarvänligt gränssnitt.

Vissa produkter kräver precis som du säger ett par års utveckling och då kan man omöjligen slänga ut ett test efter bara några veckor. Då ska man nog också känna sig bekväm och säker på sin produkt så att det är värt att investera så pass mycket tid/pengar.