Näin validoit SaaS-idean ennen kuin kirjoitat riviäkään koodia

Kallein tapa selvittää, haluavatko ihmiset ohjelmistoasi, on rakentaa se. Silti juuri näin useimmat ensikertalaiset perustajat tekevät — he käyttävät puoli vuotta ja säästönsä muuttaakseen idean koodiksi, julkaisevat sen hiljaisuuteen ja vasta sitten alkavat kysyä, tarvitsiko sitä kukaan. Validointi on tämän opetuksen halpa versio. Sen avulla ostat vastauksen muutamalla viikolla keskusteluja vuoden elämäsi sijaan.

Olen nähnyt monen fiksun ihmisen lankeavan samaan ansaan. Heillä on aidosti hyvä havainto — todellinen ärsytys alalla, jonka he tuntevat — ja he olettavat, että havainnon ja tuotteen välinen kuilu on pelkkää insinöörityötä. Ei se ole. Kuilu on täynnä vastaamattomia kysymyksiä: tunteeko kukaan muu tätä kipua tarpeeksi maksaakseen siitä? Vaihtavatko he siitä, mitä nyt tekevät? Tavoitatko heidät polttamatta rahaa? Näihin kysymyksiin ei vastata koodaamalla. Niihin vastataan puhumalla ihmisten kanssa ja katsomalla, mitä he oikeasti tekevät.

Tämä on siis opas, jonka annan perustajille ennen kuin he palkkaavat ketään rakentamaan mitään. Kyse ei ole lean-startup-teatterista tai canvas-pohjan täyttämisestä. Kyse on kourallisesta rehellisiä, edullisia kokeita, jotka kertovat, onko ideallasi pulssi — ja kurinalaisuudesta uskoa tuloksiin, vaikka ne kirpaisisivat.

Miksi ensin rakentaminen tuntuu tuottavalta — eikä yleensä ole

Rakentaminen on houkuttelevaa, koska se tuntuu näkyvältä edistykseltä. Koodaussession lopussa on ruutu, joka toimii, painike, joka tekee jotain, jokin, jonka voit näyttää kumppanillesi. Tuntemattomille puhuminen ongelmasta ei tuota mitään artefaktia. Se on epämukavaa, se on hidasta, ja lopussa sinulla ei ole muuta kuin muistiinpanoja. Niinpä perustajat tarttuvat näppäimistöön, koska näppäimistö palkitsee heidät nopeammin.

Ongelma on, että toimiva ruutu ei kerro juuri mitään siitä, onko idea oikea. Voit rakentaa kauniin, virheettömän tuotteen ongelmaan, jota kenelläkään ei ole, ja se on yhtä kuollut kuin rumakin. Koodi on vastaus kysymykseen ”miten toimitamme tämän?” — ei kysymykseen ”haluaako kukaan tätä?” Kuukausien käyttäminen ensimmäiseen kysymykseen ennen kuin olet vastannut jälkimmäiseen on tapa, jolla hyvät insinöörit rakentavat tyylikkäitä ratkaisuja kuvitteellisiin ongelmiin.

Validointi kääntää järjestyksen. Käytät muutaman viikon ja hyvin vähän rahaa todistaaksesi — tai kumotaksesi — ideasi riskialttiimman oletuksen ennen kuin sitoudut rakentamiseen. Jos idea on vahva, kävelet kehitykseen näyttöjen kanssa, selkeämmällä määrittelyllä ja ensimmäiset käyttäjäsi jo odottamassa. Jos se on heikko, saat sen selville muutaman kahvin ja laskeutumissivun hinnalla, et koko tuotteen hinnalla.

Löydä se yksi oletus, joka voi kaataa koko hankkeen

Jokainen SaaS-idea nojaa uskomusten pinoon, eivätkä ne ole yhtä vaarallisia. Jotkut ovat turvallisia — ”ihmiset käyttävät sähköpostia”, ”pienyritykset eivät pidä paperitöistä”. Toiset ovat vetoja, joista koko hankkeesi riippuu, ja jos ne ovat väärin, millään muulla ei ole väliä. Validoinnin tehtävä ei ole testata kaikkea. Se on löytää riskialttiin oletus ja käydä ensin sen kimppuun.

Löytääksesi sen kirjoita ideasi yhtenä lauseena: ”[nämä ihmiset] kärsivät [tästä ongelmasta] tarpeeksi pahasti maksaakseen [tästä ratkaisusta] sen sijaan, mitä [he tekevät nyt].” Kysy sitten itseltäsi armottomasti: mikä sana tuossa lauseessa, jos se osoittautuisi vääräksi, upottaisi idean? Yleensä se ei ole ratkaisu. Kyse on siitä, onko ongelma tarpeeksi tuskallinen, jotta siitä maksetaan, tai siitä, tavoitatko nuo ihmiset edullisesti.

Tämä järjestys on tärkeä, koska testaamisen hinta nousee joka askeleella. Ongelmahaastattelu on ilmainen. Maksuhalukkuustesti maksaa laskeutumissivun. Ratkaisutesti saattaa vaatia klikattavan prototyypin. Rakentaminen on kaikista kallein testi. Haluat epäonnistua edullisesti ja aikaisin, et kalliisti ja myöhään — siksi laitat halvimmat, tappavimmat testit eteen.

Puhu ihmisten kanssa — mutta tee se oikein

Hyödyllisin yksittäinen asia, jonka voit tehdä, on puhua niiden ihmisten kanssa, joilla uskot ongelman olevan. Ei ystäviesi, ei muiden perustajien — vaan niiden oikeiden ihmisten, jotka käyttäisivät tätä. Ja tässä on koukku, joka pilaa useimmat yritykset: ihmiset ovat kohteliaita. Kysy ”käyttäisitkö työkalua, joka tekee X?” ja lähes jokainen sanoo kyllä, koska kyllä-sanominen on ilmaista ja ystävällistä. Tuo kyllä on arvoton. Se on upottanut enemmän startupeja kuin yksikään tekninen epäonnistuminen.

Korjaus on lakata kysymästä tulevaisuudesta ja alkaa kysyä menneisyydestä. Tulevaisuus on paikka, jossa ihmiset valehtelevat ollakseen ystävällisiä; menneisyys on paikka, jossa totuus asuu. Kysymyksen ”käyttäisitkö tätä?” sijaan kysy ”kerro viimeisestä kerrasta, kun käsittelit tätä ongelmaa.” Mitä he tekivät? Kauanko se kesti? Mitä se maksoi heille? Etsivätkö he ratkaisua? Maksoivatko he siitä? Todellinen käyttäytyminen voittaa hypoteettisen innostuksen joka kerta.

Kysymykset, jotka saavat rehelliset vastaukset

• ”Käy läpi viimeisin kerta, kun tämä tapahtui.” — tuo esiin todellisen työnkulun, ei idealisoitua.
• ”Mitä teit asialle?” — paljastaa, välittävätkö he oikeasti vai kohauttavatko vain olkapäitään.
• ”Paljonko se maksoi sinulle aikaa tai rahaa?” — muuttaa epämääräisen kivun luvuksi.
• ”Oletko yrittänyt korjata tätä aiemmin? Mitä tapahtui?” — kertoo, onko budjettia ja aikomusta.
• ”Mikä muu on juuri nyt ärsyttävämpää kuin tämä?” — tarkistaa, mahtuuko ongelmasi edes heidän viiden kärkeensä.

Montako keskustelua? Vähemmän kuin luulisit. Kun olet käynyt kymmenen rehellistä, hyvin hoidettua haastattelua oikeiden ihmisten kanssa, kuvio on yleensä ilmeinen. Joko kolme tai neljä heistä syttyy ja alkaa kuvailla kipua elävin yksityiskohdin — tai he ovat kaikki kohteliaan haaleita, eikä mikään näppärä rakentaminen korjaa sitä. Kaksitoista tai viisitoista riittää aivan hyvin päätökseen, johon voit luottaa.

Edullisia tapoja testata todellista kysyntää

Keskustelut kertovat, onko ongelma todellinen. Seuraava kysymys on, toimivatko ihmiset — ja ainoa tapa tietää on pyytää pieni sitoumus ennen kuin tuote on olemassa. Tässä kohtaa validointi muuttuu hieman epämukavaksi ja myös rehelliseksi. Puhe on halpaa; klikkaus, sähköpostiosoite tai käsiraha eivät ole.

Sinun ei tarvitse rakentaa mitään näiden testien suorittamiseksi. Tarvitset yhden sivun, joka kuvaa lupauksen selkeästi ja pyytää yhtä tiettyä toimintoa. Toiminto on data. Jos ihmiset lukevat pitsisi eivätkä tee mitään, se on vastauksesi, ja se on paljon halvempi vastaus kuin julkaista tyhjyyteen puolen vuoden päästä.

1. 1
   Pystytä yhden sivun pitsi

   Kuvaa ongelma ja ratkaisusi selkeällä kielellä, yhdellä selvällä toimintakehotuksella. Yksinkertainen laskeutumissivu riittää — ei vielä tuotetta sen takana.
2. 2
   Pyydä todellinen signaali

   Ei ”tykkäystä”. Pyydä ihmisiä liittymään jonotuslistalle sähköpostillaan, ennakkotilaamaan tai varaamaan puhelu. Mitä enemmän kyllä maksaa heille, sitä enemmän kyllä merkitsee.
3. 3
   Ohjaa hieman rehellistä liikennettä

   Jaa se siellä, missä todellinen yleisösi jo on — sopivassa yhteisössä, pienellä mainoksella, muutamalla suoraviestillä. Haluat tuntemattomia, et kannustavaa verkostoasi.
4. 4
   Lue konversio, älä kohteliaisuuksia

   Kaikista, jotka aidosti ymmärsivät tarjouksen, kuinka moni teki toiminnon? Kourallinen oikeita rekisteröitymisiä oikeilta ihmisiltä voittaa tuhat epämääräistä hyvää toivotusta.

Kaikista vahvin kysyntätesti on rahan pyytäminen etukäteen. Ennakkomyynti, maksullinen pilotti, käsiraha varhaisesta pääsystä — mitä tahansa, missä lompakko avautuu. Se tuntuu aggressiiviselta, ja se on rehellisin asia, jonka voit tehdä itsesi hyväksi. Kun joku luovuttaa pienenkin summan tuotteesta, jota ei vielä ole olemassa, hän kertoo sinulle jotain, mitä mikään kysely ei koskaan voisi. Jos löydät kolme tai neljä tällaista ihmistä, sinulla ei ole enää ideaa. Sinulla on liiketoiminta, joka odottaa rakentamista.

Myy se ennen kuin rakennat sen

Vaiheiden ”ihmiset ovat kiinnostuneita” ja ”ihmiset maksavat joka kuukausi” välissä on askel, joka ansaitsee oman huomionsa: arvon toimittaminen käsin ennen sen automatisointia. Jos ideasi on työkalu, joka vaikkapa muuttaa sekavat toimittajien sähköpostit siistiksi viikkoraportiksi, tee se käsin kolmelle tai neljälle asiakkaalle ensin. Sinusta tulee se ohjelmisto. Se on hidasta eikä se skaalaudu, ja juuri se on pointti — sen avulla opit, mitä tuotteen oikeasti pitää tehdä, ennen kuin olet lukinnut sen koodiin.

Tämä tekee kaksi asiaa yhtä aikaa. Se todistaa, että ihmiset maksavat lopputuloksesta, eivät vain sen ideasta. Ja se opettaa sinulle todellisen työnkulun — reunatapaukset, poikkeukset, ne osat, joista asiakkaat välittävät ja joita et olisi ikinä arvannut haastattelusta. Kun lopulta rakennat, et arvaa määrittelyä. Koodaat prosessia, jonka olet jo ajanut käsin ja josta sinulle on maksettu.

Signaalien lukeminen rehellisesti

Kaikki tämä toimii vain, jos olet valmis uskomaan tuloksiin — ja se on vaikeampaa kuin miltä kuulostaa, koska tähän mennessä olet kiintynyt ideaan. Vaara ei ole huono data; vaan perustaja, joka tulkitsee jokaisen signaalin rohkaisuksi. Haalea kiinnostus muistetaan innostuksena. Kohtelias jonotuslistalle liittyminen muuttuu ”vahvaksi kysynnäksi”. Sinun on taisteltava omaa optimismiasi vastaan tässä.

On hyödyllistä päättää etukäteen, miltä läpäisy näyttää. Ennen testin tekemistä kirjoita ylös tulos, joka saisi sinut jatkamaan, ja tulos, joka saisi sinut lopettamaan. ”Jos alle X haastattelustani kuvaa tätä todelliseksi, toistuvaksi ongelmaksi, luovun siitä.” Riman päättäminen ennen datan näkemistä on ainoa luotettava puolustus sitä vastaan, että puhut itsesi rakennusprojektiin, jota ei pitäisi tehdä.

Ja joskus rehellinen vastaus on ei. Se ei ole epäonnistuminen — se on järjestelmä toiminnassa. Validointiprosessi, joka ei voi koskaan palauttaa ”älä rakenna tätä”, ei ole validointia, vaan luvan kerjäämistä. Perustajat, jotka voittavat uran aikana, eivät ole niitä, joilla ei ole koskaan huonoja ideoita. He ovat niitä, jotka tappavat huonot ideat kolmessa viikossa muutamalla sadalla eurolla sen sijaan, että hoivaisivat niitä vuoden.

Kun olet aidosti valmis rakentamaan

Sanotaan, että signaalit ovat hyvät. Ongelma on todellinen, ihmiset kuvasivat sitä tunteella, muutama laittoi rahaa likoon. Nyt — ja vasta nyt — rakentaminen on järkevää. Mutta tässäkin pidättyväisyys kannattaa. Ensimmäisen versiosi tavoite ei ole olla se tuote, jonka kuvittelet. Vaan toimittaa se yksi ydintulos, josta validoidut asiakkaasi maksavat, eikä mitään muuta vielä.

Tässä validointi ojentaa sinulle hiljaa lahjan: terävän, näyttöihin perustuvan määrittelyn. Tiedät kenelle se on, mikä on ydintehtävä, mistä ihmiset maksavat ja mitkä ominaisuudet nousivat esiin kerta toisensa jälkeen niihin verrattuna, joista vain sinä välitit. Tuo selkeys on enemmän arvoinen kuin mikään määrä etukäteissuunnittelua. Se on ero oikean pienen asian rakentamisen ja kalliin kaiken rakentamisen välillä.

Yleisiä kysymyksiä