FAQ |
Kalender |
2014-08-05, 19:22 | #1 | ||
|
|||
Supermoderator
|
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?
__________________
Full-stack developer, free for smaller assignments |
||
Svara med citat |
2014-08-06, 00:45 | #2 | ||
|
|||
Flitig postare
|
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. |
||
Svara med citat |
2014-08-06, 07:53 | #3 | ||
|
|||
Medlem
|
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. |
||
Svara med citat |
2014-08-06, 10:37 | #4 | |||
|
||||
Bara ett inlägg till!
|
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. |
|||
Svara med citat |
2014-08-06, 18:38 | #5 | |||
|
||||
Supermoderator
|
Citat:
Citat:
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? Citat:
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?
__________________
Full-stack developer, free for smaller assignments |
|||
Svara med citat |
2014-08-06, 20:19 | #6 | ||
|
|||
Har WN som tidsfördriv
|
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.
|
||
Svara med citat |
2014-08-07, 08:53 | #7 | ||
|
|||
Medlem
|
Citat:
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. |
||
Svara med citat |
2014-08-07, 23:04 | #8 | ||
|
|||
Supermoderator
|
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.
__________________
Full-stack developer, free for smaller assignments |
||
Svara med citat |
Svara |
|
|