Mitä SaaS-MVP:n pitäisi — ja ei pitäisi — sisältää julkaisuhetkellä

Sana ”minimi” pienimmässä elinkelpoisessa tuotteessa on se osa, jonka kaikki sivuuttavat. Perustajat nyökkäilevät ajatukselle aloittaa pienestä, ja ojentavat sitten määrittelyn, jossa on neljäkymmentä näkymää, kolme käyttäjäroolia, laskutuskone, analytiikkanäkymä ja ”ai niin, ja sen pitäisi integroitua kaikkeen”. Se ei ole MVP. Se on täysi tuote, jossa optimismi on kierretty maksimiin. Ja se on yleisin yksittäinen syy siihen, miksi ensijulkaisut tulevat myöhässä, ylittävät budjetin ja jättävät silti jotenkin puuttumaan sen yhden asian, jota asiakkaat oikeasti halusivat.

Olen auttanut kohtuullisen monta pienyritystä ja yksinyrittäjää saamaan ensimmäisen ohjelmistotuotteensa ulos. Tekninen osuus harvoin kompastuttaa ihmisiä. Vaikein osa — joka ainoa kerta — on päättää, mitä ei vielä rakenneta. MVP ei ole pienempi versio unelmatuotteestasi, josta on satunnaisesti hiottu ominaisuuksia pois. Se on tietoinen veto: pienin asia, jonka voit laittaa oikeiden käyttäjien eteen ja joka todistaa, että ydinidea on arvoinen lisää rahaasi ja aikaasi.

Tämä on siis se opas, jonka toivoisin useamman perustajan lukevan ennen määrittelyn kirjoittamista. Ei ammattislangia, ei ”liiku nopeasti ja riko asioita” -teatteria. Vain käytännöllinen tapa vetää raja sen välille, mikä kuuluu ensimmäiseen julkaisuusi ja mikä voi — ja minkä pitäisi — odottaa.

Mikä MVP oikeasti on (ja mikä ei)

Selvitetään määritelmä, koska suurin osa sekaannuksesta alkaa tästä. MVP on tuotteesi pienin, yksinkertaisin versio, joka antaa oikean ihmisen tehdä sen yhden arvokkaan asian, jonka tuotteesi lupaa — ja antaa sinun oppia, palaako hän tekemään sen uudelleen. Siinä se. Se on oppimistyökalu, joka sattuu olemaan tehty toimivasta ohjelmistosta, ei valmiin tuotteen riisuttu julkaisu.

Ratkaiseva sana on elinkelpoinen. Yleinen virhe on lukea ”minimi” ja julkaista jotain niin paljasta, että se nolostuttaa käyttäjän — puolikas kulku, joka kaatuu, rekisteröityminen, joka johtaa tyhjään näyttöön. Se ei ole minimaalisen elinkelpoinen, se on minimaalisen rikki. Toinen epäonnistuminen on päinvastainen: tuote niin ”valmis”, että sen rakentaminen vei vuoden, johon mennessä olet polttanut kassasi todistaaksesi arvauksen, jonka olisit voinut testata kahdeksassa viikossa.

Tässä on ajatuskoe, jota käytän. Kysy jokaisen listan ominaisuuden kohdalla: jos poistaisimme tämän, saisiko käyttäjä silti sen yhden ydintuloksen, jota varten tuote on olemassa? Jos vastaus on kyllä, se ei lähes varmasti kuulu MVP:hen. Pelkkä tuo kysymys leikkaa useimmat määrittelyt puoliksi — ja se puolikas, jonka se leikkaa, on se joka olisi myöhästyttänyt sinut.

Löydä se yksi työ, jonka tuotteesi tekee

Ennen kuin voit päättää, mitä rakentaa, sinun on oltava julmasti selvillä siitä yhdestä työstä, jonka tuotteesi tekee jollekulle. Ei visio. Ei tiekartta. Se yksi toistettava toiminto, joka onnistuessaan tekee ihmisen päivästä paremman ja saa hänet valmiiksi maksamaan. Useimmat kompuroivat määrittelyt ovat epämääräisiä juuri tässä — ne kuvaavat alustaa, eivät työtä.

Yritä lopettaa tämä lause ääneen: ”Käyttäjä tulee tuotteelleni ______, ja lähtee ______.” Työvuorotyökalu: esihenkilö tulee julkaisemaan ensi viikon vuorolistan ja lähtee jokainen vuoro täytettynä ja tiimi tiedotettuna. Laskutussovellus: freelancer tulee laskuttamaan asiakasta ja lähtee lähetetyn, seurattavan laskun kanssa. Jos et osaa täyttää tuota lausetta puhtaasti, et ole valmis rajaamaan — olet vielä valmis ajattelemaan.

Mitä jokainen SaaS-MVP aidosti tarvitsee

Jotkin asiat eivät ole neuvoteltavissa edes kevyimmässä ensiversiossa — ei siksi, että ne olisivat jännittäviä, vaan koska ilman niitä tuotetta joko ei voi käyttää tai se ei voi opettaa sinulle mitään. Ajattele näitä lattiana, ei kattona. Rakenna ne yksinkertaisesti, mutta rakenna ne kunnolla.

• Tapa kirjautua sisään. Pelkkä sähköposti-ja-salasana-kirjautuminenkin riittää — mutta oikea, turvallinen, koska kaikki muu riippuu siitä, että tiedät kuka käyttäjä on.
• Ydinkulku alusta loppuun. Se yksi työ käyttäjän ensimmäisestä klikkauksesta hetkeen, jolloin hän saa arvokkaan tuloksen — ei umpikujia, ei ”tulossa pian” -nappeja kriittisellä polulla.
• Paikka, jossa data oikeasti elää. Aitoa tallennusta, ei kertakäyttöprototyyppiä, jotta käyttäjän työ selviää päivityksestä ja hän voi palata huomenna.
• Tapa nähdä, mitä tapahtuu. Perustason lokitus tai yksinkertainen ylläpitonäkymä, jotta kun jokin hajoaa — ja se hajoaa — voit selvittää miksi arvailematta.
• Tapa käyttäjille tavoittaa sinut. Vaikka pelkkä sähköpostilinkki. Varhaiset käyttäjät törmäävät reunoihin, joita et ennakoinut; haluat heidän kertovan sinulle, ei lähtevän hiljaa.
• Vähimmäisluottamus: tietosuojaseloste, järkevä datankäsittely eikä mitään holtitonta ihmisten tietojen kanssa.

Huomaa, mitä listalla ei ole: laskutus, hieno käyttöönotto, asetussivut, mobiilisovellukset, integraatiot. Pääsemme syyhyn hetken päästä. Lattian pointti on, että se on tarpeeksi pieni valmistuakseen ja tarpeeksi vakaa opettaakseen. Toimiva kirjautuminen, yksi kulku joka toimittaa, aitoa dataa sekä tapa tarkkailla ja puhua käyttäjille. Se on elinkelpoinen tuote.

Mitä jättää tarkoituksella pois versiosta 1

Tätä osaa perustajat vastustavat, joten sanon suoraan: useimmat asiat, jotka tuntuvat ensimmäisen julkaisusi kannalta olennaisilta, eivät ole. Ne tuntuvat olennaisilta, koska ”oikealla tuotteella” on ne — mutta et rakenna vielä oikeaa tuotetta, vaan rakennat kysymystä. Näiden poisjättäminen ei ole oikomista. Se on MVP:n koko kuri.

Automaattinen laskutus ja monimutkainen hinnoittelu

Et lähes varmasti tarvitse itsepalvelulaskutuskonetta, porrastettuja tasoja, suhteutusta ja maksumuistutuslogiikkaa ensimmäisessä versiossa. Jos varhaiset käyttäjät haluavat maksaa, voit ottaa heidän rahansa käsin — lasku, maksulinkki, nopea puhelu. Käsin laskutus ensimmäisille kymmenelle asiakkaalle kertoo sinulle jotain, mitä automaattinen ei voi: maksaako kukaan ylipäätään. Rakenna kone vasta, kun olet todistanut, että on rahaa kerättäväksi.

Monimutkaiset roolit ja käyttöoikeudet

Moniroolijärjestelmät — ylläpitäjät, esihenkilöt, katselijat, tarkat käyttöoikeussäännöt — ovat aito insinöörisuo, ja ne moninkertaistavat testauspinnan valtavasti. Ensimmäiseen julkaisuun yksi käyttäjätyyppi riittää lähes aina. Opit todelliset käyttöoikeustarpeet seuraamalla, miten oikeat tiimit käyttävät tuotetta, eivätkä ne tarpeet harvoin ole sitä, mitä olisit arvannut paperilla.

Integraatiot, natiivimobiilisovellukset ja näkymä

”Sen pitää integroitua kaikkeen” on lause, joka hiljaa tuplaa aikataulut. Valitse korkeintaan yksi integraatio, ja vain jos se on osa ydintyötä. Natiivit iOS- ja Android-sovellukset voivat lähes aina odottaa — responsiivinen verkkosovellus toimii puhelimessa jo tänään. Ja se analytiikkanäkymä, jota kaikki haluavat? Käyttäjät eivät voi analysoida dataa, jota he eivät ole vielä luoneet. Julkaise ensin se, mikä luo datan; visualisoi se, kun on jotain näytettävää.

Yksinkertainen tapa vetää raja

Periaatteen tunteminen on yksi asia; sen soveltaminen omaan määrittelyysi, jossa jokainen ominaisuus tuntuu omalta lapseltasi, on vaikeampaa. Tässä on menetelmä, joka toimii, koska se pakottaa päätöksen jokaisesta kohdasta sen sijaan, että antaisi kaiken ajautua ”olennaiseksi”.

1. 1
   Listaa jokainen kuvittelemasi ominaisuus

   Kaada kaikki ulos — ei suodatusta vielä. Saa koko toivelista pöydälle, jottei mikään väijy lausumattomana ja palaa kesken rakentamisen yllätyksenä.
2. 2
   Merkitse jokainen ydintyötä vasten

   Kysy jokaisen ominaisuuden kohdalla: tarvitseeko käyttäjä tämän suorittaakseen sen yhden ydintyön alusta loppuun? Merkitse se ”ydin”, ”hyödyllinen” tai ”joskus”. Ole rehellinen — useimmat osuvat kahteen jälkimmäiseen.
3. 3
   Pidä versiossa 1 vain ”ydin”

   MVP:si on ”ydin”-pino eikä mikään muu. ”Hyödyllinen”- ja ”joskus”-pinoja ei hylätty — ne ovat tiekarttasi, pysäköityinä sinne minne kuuluvat.
4. 4
   Tarkista leikkauksen järkevyys

   Katso, mitä jäi, ja kysy: saako oikea käyttäjä todellista arvoa pelkästään tästä? Jos kyllä, olet rajannut MVP:n. Jos jokin aidosti rikkoo ydinkulun, vedä takaisin vain se yksi kohta — eikä mitään muuta.

Kuri on vaiheessa neljä. On aina houkutus ”vetää takaisin vain yksi asia lisää”, ja sitten taas yksi, kunnes olet hiljaa rakentanut täyden tuotteen uudelleen. Salli itsesi pelastaa vain kohtia, jotka aidosti rikkovat ydinkulun — ei kohtia, jotka tekisivät siitä vain mukavamman. Mukavampi on sitä varten, mitä varten versio kaksi on.

Elinkelpoinen tarkoittaa silti, että sen on tunnuttava todelliselta

Rajan toisella puolella on epäonnistumismuoto, ja se kannattaa nimetä. Kiireessä julkaista pieni, jotkin perustajat julkaisevat rähjäisen — ja kutsuvat sitä MVP:ksi. Ydinkulku, joka kadottaa työsi, rekisteröityminen, joka antaa 404:n, paikkamerkkitekstillä täytetty sisältö. Se ei testaa ideaasi reilusti; se testaa, sietävätkö käyttäjät rikkinäistä kokemusta, ja vastaus on aina ei. Päättelet, että idea epäonnistui, vaikka oikeasti toteutus epäonnistui.

”Minimi” koskee laajuutta, ei koskaan säilyttämäsi osan laatua. Vähemmän ominaisuuksia, jokainen niistä vankka. Sen yhden kulun, jonka julkaiset, pitäisi tuntua valmiilta — nopealta, selkeältä ja luotettavalta — vaikka se olisi ainoa asia, jonka tuote tekee. Kapea, hyvin tehty tuote voittaa laajan, huonosti tehdyn joka kerta, erityisesti kun pyydät tuntemattomia luottamaan työnsä sinulle.

MVP ei ole maaliviiva — se on ensimmäinen lukema

Tässä on se osa, joka asettaa kaiken uuteen valoon: julkaisu ei ole tavoite. Tavoite on se, mitä opit sitä seuraavina viikkoina. MVP, joka julkaistaan ja kertoo sinulle ”käyttäjät rakastavat ydintä mutta pyytävät jatkuvasti X:ää”, on jyrisevä menestys — vaikka X tarkoittaisi kuukauden lisätyötä. MVP, joka julkaistaan hiljaisuuteen, kun kukaan ei palaa, on myös tehnyt työnsä: se pelasti sinut rakentamasta niitä muita kolmeakymmentä ominaisuutta perustalle, jota kukaan ei halunnut.

Suunnittele siis ensimmäiset viikot yhtä tarkoituksellisesti kuin rakentaminen. Tarkkaile, mitä ihmiset oikeasti tekevät, ei mitä he sanovat kyselyissä. Puhu niiden kanssa, jotka palasivat, ja niiden, jotka eivät. Anna todellisen käytön — ei alkuperäisen määrittelysi — päättää, mikä menee versioon kaksi. Aiemmin pysäköimäsi tiekartta ei ole lupaus; se on hypoteesi, ja käyttäjäsi ovat juuri arvostelemassa sitä.

Yleisiä kysymyksiä