Ideasta SaaS-MVP:hen: perustajan vaiheittainen opas

Lähes jokainen artikkeli SaaS:n rakentamisesta on salaa kirjoitettu jollekulle, joka on jo kerännyt rahoituksen. Se olettaa tiimin, taloudellisen pelivaran, etenemissuunnitelman ja sen rauhan, että tietää voivansa olla väärässä vuoden ajan. Jos olet perustaja, jolla on aito idea, päivätyö ja säästöt, joita oikeasti tarvitset, tuo neuvo on hiljaa vaarallinen. Se kehottaa rakentamaan isosti ja nopeasti — juuri näin useimmat ensituotteet kuolevat ennen kuin kukaan maksaa senttiäkään.

Olen yli vuosikymmenen ajan auttanut ihmisiä muuttamaan ideoita toimivaksi ohjelmistoksi, ja parhaiten muistamani perustajat eivät ole niitä, joilla on rohkeimmat suunnitelmat. He ovat niitä, jotka aloittivat pienestä ja pysyivät rehellisinä. Fysioterapeutti, joka rakensi ajanvaraustyökalun omalle klinikalleen ja päätyi myymään sen neljällekymmenelle muulle. Logistiikkadispatcher, joka automatisoi oman paperityönsä ja tajusi, että puolella alaa oli sama ongelma. Kukaan heistä ei aloittanut suurenmoisesta alustasta. He aloittivat yhdestä kivuliaasta tehtävästä ja halusta veloittaa sen ratkaisemisesta.

Joten tämä on opas, jonka olisin toivonut jonkun ojentaneen noille ihmisille ensimmäisenä päivänä. Ei varainhankintateatteria, ei muodikasta arkkitehtuuria, ei teeskentelyä, että ensimmäisen version pitäisi olla vaikuttava. Vain rauhallinen polku pään sisäisestä aavistuksesta ensimmäiseen maksavaan asiakkaaseen — ja arvostelukyky tietää, mitä jättää matkalla väliin.

Mitä MVP oikeasti on (ja mitä se ei ole)

Termiä minimum viable product on venytetty niin pitkälle, että se tuskin enää tarkoittaa mitään. Jotkut perustajat kuulevat "minimi" ja julkaisevat jotain noloa, jota kukaan ei voi käyttää. Toiset kuulevat "tuote" ja viettävät kahdeksan kuukautta rakentaen hiottua alustaa hintaportaineen, hallintapaneeleineen ja tummine tiloineen, ennen kuin yksikään ihminen on vahvistanut maksavansa siitä. Molemmat ovat virheitä, ja kyseessä on sama virhe eri vaatteissa: rakentaminen ennen kuin on oppinut mitään.

Hyödyllinen MVP on pienin asia, jonka voit asettaa aidon käyttäjän eteen ja joka todistaa, että ydinideastasi kannattaa maksaa. Ei pienin asia, jonka voit rakentaa — pienin asia, joka opettaa sinulle jotain todellista. Jos ideasi on "työkalu, jolla hammaslääkärit voivat lähettää muistutuksia automaattisesti", MVP on muistutusmoottori eikä mitään muuta. Ei potilasportaalia, ei analytiikkanäkymää, ei tiimitilejä. Ne ovat vastauksia kysymyksiin, joita et ole vielä ansainnut.

Syy, miksi tällä on niin paljon merkitystä, on kustannus. Jokainen ominaisuus, jonka rakennat ennen validointia, on sokkona tehty veto. Karsi MVP ytimeensä, niin olet tehnyt yhden pienen, palautettavissa olevan vedon. Rakenna koko visio, niin olet pannut säästöt likoon — arvauksen varaan. "Minimin" kuri ei ole halpuudesta. Se on hengissä pysymisestä riittävän kauan, jotta voit olla oikeassa.

Validoi idea ennen kuin kirjoitat riviäkään koodia

Tässä epämukava totuus, jota kukaan kehitystä sinulle myyvä ei halua sanoa: useimmat SaaS-ideat ovat jollain tärkeällä tavalla väärässä, ja voit saada sen selville lähes ilmaiseksi. Vaisto on rakentaa ensin ja kysyä myöhemmin. Käännä se päinvastoin. Tuotteesi halvin versio on keskustelu, ja toiseksi halvin on laskeutumissivu.

Ennen kuin mitään rakennetaan, haluat näyttöä kahdesta asiasta. Ensinnäkin, että ongelma on aito ja riittävän kivulias, jotta ihmiset jo käyttävät siihen aikaa tai rahaa — kömpelösti, taulukoilla, tarralapuilla ja työkalulla, jota he vihaavat. Toiseksi, että he aidosti maksaisivat saadakseen sen pois. "Tuo on mukava idea" ei ole näyttöä. "Käyttäisin tuota" ei ole näyttöä. "Paljonko se maksaa ja voinko aloittaa maanantaina?" on näyttöä.

Laskeutumissivu, jossa on selkeä lupaus ja "liity jonotuslistalle"- tai "varaa demo" -painike, on seuraava askel. Jos et saa kourallista tuntemattomia jättämään sähköpostiaan kuvaamastasi asiasta, se ei ole myöhemmin korjattava markkinointiongelma — se on signaali nyt, kun sen kuuleminen on vielä halpaa. Validointi ei ole vaihe, jonka läpi kiirehdit päästäksesi hauskaan osaan. Omia rahojaan käyttävälle perustajalle se on hauska osa: siinä vältät kalliin virheen.

Löydä se yksi ominaisuus, jota ilman tuotteesi ei voi elää

Jokainen SaaS-idea tulee, kun sen ensimmäisen kerran kuvailet, kääritynä tusinaan ominaisuuteen. On se, mitä se tekee, ja sitten on kiva-jos-olisi-asioiden tähdistö, jonka aivosi ovat jo liittäneet siihen: raportit, integraatiot, mobiilisovellukset, roolit ja oikeudet, julkinen API. Arvokkain taito ideasta MVP:hen pääsemisessä on oppia riisumaan kaikki tuo pois ja löytämään se yksi ominaisuus, joka, jos se katoaisi, tekisi koko asiasta merkityksettömän.

Tuo ydinominaisuus on MVP:si. Kaikki muu on hypoteesi, jota testaat myöhemmin, kun ihmiset käyttävät ydintä ja kertovat sinulle, mitä he oikeasti kaipaavat. Perustajat tekevät tämän johdonmukaisesti väärinpäin — he rakentavat tukinäyttelijät ensin, koska se tuntuu turvallisemmalta, ja aika ja rahat loppuvat ennen kuin se yksi tärkeä asia koskaan julkaistaan.

Yhden lauseen testi

Yritä kuvailla, mitä tuotteesi tekee yhdessä lauseessa ilman "ja"-sanaa. "Sen avulla klinikat voivat lähettää automaattisia ajanvarausmuistutuksia." "Se muuttaa valokuvan kuitista kirjanpitomerkinnäksi." "Se seuraa, mitkä tarjoukset ammattilainen lähetti, ja muistuttaa häntä ottamaan yhteyttä uudelleen." Jos tarvitset "ja"-sanan arvon kuvailemiseen, sinulla on luultavasti kaksi tuotetta tappelemassa yhden MVP:n sisällä — ja sinun pitäisi julkaista kivuliaampi puolikas ensin.

• Kirjoita ylös kaikki, mitä kuvittelet tuotteen tekevän — saa se kaikki ulos, älä suodata.
• Kysy jokaisesta kohdasta: jos tätä ei olisi, maksaisiko kukaan silti? Yliviivaa jokainen "kyllä".
• Mitä yliviivauksen jälkeen jää, on ytimesi. Se on MVP.
• Ota vahvimmat yliviivatut kohdat ja laita ne "myöhemmin"-listalle — ei poissa, vain ei nyt.
• Vastusta niiden lisäämistä takaisin. "Myöhemmin"-lista on paikka, jossa hyvät ideat odottavat ansaitsemistaan, ei paikka, jonne MVP:t menevät kuolemaan.

Rakenna se, osta se tai feikkaa se: miten tehdä MVP

Kun tiedät sen yhden ydinominaisuutesi, sinulla on valinta, jonka perustajat tekevät harvoin tietoisesti: kuinka paljon tästä sinun oikeasti tarvitsee rakentaa alusta asti? Rehellinen vastaus ensimmäiselle versiolle on yleensä "vähemmän kuin luulet". On kolme laajaa polkua, ja fiksu liike on usein yhdistelmä.

No-code- / liimapolku

Joissakin MVP:issä voit kytkeä yhteen olemassa olevia työkaluja — lomakkeen, tietokannan, automaatiokerroksen, sähköpostipalvelun — ja validoida idean kirjoittamatta lainkaan räätälöityä koodia. Tämä on loistavaa sen testaamiseen, käyttävätkö ja maksavatko ihmiset työnkulusta. Se on nopeaa ja halpaa. Sen rajat näkyvät myöhemmin: kun tarvitset aitoa tuotekokemusta, oman tietomallisi tai jotain todella ainutlaatuista, liima alkaa rasittua. Se on hyvä ongelma — se tarkoittaa, että on aika rakentaa kunnolla, maksavat käyttäjät jo kädessä.

Räätälöidyn rakentamisen polku

Kun ydinominaisuutesi on erottava tekijä — varsinainen syy, miksi asiakkaat valitsevat sinut — tuo osa ansaitsee aitoa, räätälöityä ohjelmistoa. Virhe on räätälöidä kaikki sen ympäriltä. Sinun ei tarvitse kirjoittaa omaa todennusta, maksunkäsittelyä tai sähköposti-infrastruktuuria; ne ovat ratkaistuja ongelmia, jotka sinun pitäisi vuokrata. Rakenna se osa, joka on ainutkertaisesti sinun, vuokraa loput, niin pidät sekä kustannukset että aikataulun rehellisinä.

Useimmat menestyneet MVP:t, joita olen nähnyt, ovat tarkoituksellinen sekoitus: vuokrattuja rakennuspalikoita tylsään-mutta-tarpeelliseen putkityöhön ja keskittynyttä räätälöityä kehitystä siihen yhteen asiaan, joka tekee tuotteesta maksamisen arvoisen. Tieto siitä, kumpi on kumpi — mitä rakentaa vastaan mitä ostaa — on juuri sellainen päätös, josta kannattaa hankkia toinen mielipide ennen kuin käytät mitään.

Mitä voit turvallisesti jättää väliin ensimmäisessä versiossa

Sen tietäminen, mitä jättää pois, on yhtä tärkeää kuin sen tietäminen, mitä rakentaa, ja juuri siinä perustajat tarvitsevat eniten lupaa. Joten tässä se on: sinulla on lupa jättää väliin lähes kaikki. Ensimmäinen versio on olemassa oppimista varten, ei vaikuttamista, eivätkä juuri mitkään asioista, jotka saavat tuotteen tuntumaan "valmiilta", oikeasti auta sinua oppimaan.

• Useat hintaportaat — valitse yksi hinta tai jopa veloita aluksi manuaalisesti laskulla.
• Itsepalvelurekisteröitymisvirta — ensimmäisten kymmenen asiakkaan käyttöönotto käsin opettaa enemmän kuin mikään automatisoitu suppilo.
• Hallintapaneeli kaavioineen — voit lukea tietokantaa suoraan, kun käyttäjiä on kymmenen.
• Mobiilisovellukset, jos verkko toimii toistaiseksi hyvin puhelimessa.
• Roolit, oikeudet ja tiimitilit — kunnes aito asiakas jää jumiin ilman niitä.
• Hiotut asetukset, teemoitus ja jokainen reunatapaus — käsittele tavallinen polku ensin, loput kun joku siihen törmää.

Realistinen polku ideasta ensimmäiseen asiakkaaseen

Tässä järjestys, jonka kävisin läpi lähes minkä tahansa perustajan kanssa. Se on tarkoituksella hidas alussa ja nopea kun kerran rakennat, koska kalliit virheet asuvat kaikki varhaisissa vaiheissa — niissä, jotka perustajia eniten houkuttaa jättää väliin.

1. 1
   Kirjoita ongelma yhteen lauseeseen

   Ei ratkaisua — ongelma. "Klinikat menettävät rahaa peruuttamatta jättämisistä, koska muistutukset ovat manuaalisia." Jos et osaa muotoilla ongelmaa selkeästi, et ole valmis ratkaisemaan sitä.
2. 2
   Käy kymmenen aitoa keskustelua

   Puhu ihmisten kanssa, joilla on ongelma. Kuuntele kipua ja jo käytettäviä rahoja. Säädä tai hylkää idea sen perusteella, mitä kuulet, ei sen, mitä toivoit.
3. 3
   Pystytä laskeutumissivu ja hinta

   Kuvaile lupaus selkeästi, nimeä hinta ja pyydä sähköpostia tai demovarausta. Katso, nojautuvatko tuntemattomat eteenpäin. Tämä on validointia, johon voit luottaa.
4. 4
   Määrittele se yksi ydinominaisuus

   Riisu idea siihen yhteen asiaan, joka puuttuessaan tekee siitä merkityksettömän. Kirjoita yhden lauseen kuvaus ilman "ja"-sanaa. Se on rakennuslaajuutesi.
5. 5
   Päätä rakentaa vai ostaa jokaiselle palaselle

   Räätälöi vain erottava tekijä. Vuokraa kirjautuminen, maksut, sähköposti ja palvelintila. Saa tämä kartta oikein ennen kuin kukaan kirjoittaa koodia — se määrittää koko budjettisi.
6. 6
   Rakenna pienin toimiva versio

   Tähtää viikkoihin, ei kuukausiin. Jos pelkkä ydinominaisuus vie kauemmin kuin pari kuukautta, laajuus on yhä liian suuri — karsi uudelleen.
7. 7
   Ota ensimmäiset asiakkaasi käyttöön käsin

   Käy se läpi heidän kanssaan henkilökohtaisesti. Katso, missä he kompastelevat. Ensimmäiset kymmenen käyttäjää ovat paras tuotetiimisi — ja ensimmäinen liikevaihtosi.
8. 8
   Paranna käytön, ei mielipiteen perusteella

   Muuta sitä, mitä aito käyttö kehottaa muuttamaan. Vasta nyt alat poimia kohtia "myöhemmin"-listalta — ansaittu kysynnästä, ei lisätty arvauksella.

Mitä se oikeasti maksaa — rahassa ja ajassa

Perustajat kysyvät aina kustannuskysymyksen ensin, ja rehellinen vastaus on "riippuu, ja sinä hallitset siitä suurimman osan". Yksittäinen suurin kustannusten ajuri on laajuus — kuinka paljon päätit rakentaa ennen kuin päätit oppia. Tiukka MVP yhdellä ydinominaisuudella, putkityö vuokraten, on vaatimaton, määritelty projekti. Sama idea rakennettuna täytenä alustana kaikki päällä on eri kustannusten universumi ja paljon suurempi riski epäonnistua ennen julkaisua.

Kustannus, jonka useimmat unohtavat, on aika — sinun. Jokainen kuukausi, jonka käytät rakentaen jotain, jonka ostamista kukaan ei ole vahvistanut, on kuukausi elämästäsi ja säästöistäsi käytettynä arvaukseen. Se on todellinen argumentti pienestä aloittamiselle: ei se, että pieni on halpaa, vaan se, että pieni on nopeaa, ja nopea tarkoittaa, että opit oletko oikeassa samalla kun veto on vielä palautettavissa. Perustaja, joka tavoittaa maksavan asiakkaan kolmessa kuukaudessa kapealla työkalulla, on huomattavasti vahvemmassa asemassa kuin se, joka yhä hioo suurenmoista alustaa vuosi myöhemmin.

On myös hiljaisempi kustannus: jokainen julkaisemasi ominaisuus on jotain, jota sinun pitää nyt ylläpitää, tukea ja selittää. Pieni tuote, joka tekee yhden asian luotettavasti, on halvempi pyörittää, helpompi myydä ja yksinkertaisempi parantaa kuin rönsyilevä, joka tekee kymmenen asiaa puolittain hyvin. Pidättyväisyys ei ole vain se, miten selviät rakentamisesta — se on se, miten pidät liiketoiminnan elettävänä jälkeenpäin.

Yleisiä kysymyksiä