Katri Lietsala // Tehdään pari asiaa heti selväksi. Start up ei ole kääpiökokoinen jättiyritys ja useimmat aloittavat yritykset epäonnistuvat. Eric Riesin mukaan käytännöt, jotka toimivat isoissa yrityksissä, helposti jopa tappavat aloittelevan yrityksen, jossa eletään kaooksessa.

- Start-up on ihmisiin perustuva instituutio, joka on suunniteltu toimittamaan uusi tuote tai palvelu äärimmäisessä epävarmuudessa.

Ries arvioi, että start-up-yrittäjä on kuin koripallon pelaaja, joka vaihtaa suuntaa tuki toisella jalalla etsien oikeaa paikkaa syöttää pallo eteenpäin.

- Miten tiedät, että olet todella menossa, minne haluat mennä? Sitähän saattaa kiertää täyden ympyrän ja palata takaisin alkupisteeseen. - Eric Ries -

Jotta alkava yrittäjä pärjää, yrittäjän tulisi pystyä lyhentämään aikaa, joka kuluu reagointiin. Ikävä kyllä menestymistä hidastavat silti aina muutamat olettamukset, jotka eivät usein olekaan totta, vaan harhaluuloja, joiden varassa bisnestä ei pitäisi tehdä.

- "Tiedämme, mitä asiakkaat haluavat." Itse asiassa pitäisi tietää, mitä asiakkaat tulevat haluamaan.

- "Pystymme arvioimaan tarkasti tulevaisuuden." USA:ssa kaikilla nousee käsi ylös, jos kysyy, onko liiketoimintasuunnitelmassa liitteenä laskelma, jossa arvioidaan palvelun saavan miljoonia asiakkaita ja vähintään 100 miljoonaa dollaria.

- "Suunnitelman eteneminen on edistymistä." Not. Katsomme saavutimmeko tavoitteet, jotka asetettiin suunnitelmaan, koska ne asiat me näemme. Kun menen nukkumaan mietin, että olin tänään hyvä pitämään ihmiset kiireisinä, sijoittajat motivoituneina, asiakkaat innostuneina, tuhlasin rahaa, mutta kehittyikö mikään?

Kuuntele käyttäjää

Eric Ries puhui myös IMVU-hankkeestaan, joka toimii freemium-ansaintamallilla. Täysi versio palvelusta meni markkinoille kuudessa kuukaudessa, jolloin palvelu oli yhä täynnä ohjelmointivirheitä. Se kaatoi koneet sen sijaan, että olisi antanut sulavan avatar-kokemuksen. Silti palvelusta laskutettiin heti ensimmäisestä päivästä alkaen.

- Vietimme tuntikausia riidellen, mitä ominaisuuksia palvelussa pitäisi olla. Pelkäsimme, että asiakkaat kertovat toisilleen, miten palvelu ei toimi tai toimittaja löytää palvelun ja huomaa, ettei se toimikaan. Pelko oli turha. Kukaan ei käyttänyt palvelua. Vielä tyhmempää on ottaa rahaa, jos ohjelma ei toimi kunnolla..

- Oli kuitenkin pieni, sitoutunut ryhmä, joka käytti palvelua ja jopa maksoi siitä. Joku voisi kysyä, mikä niitä ihmisiä vaivaa? Visionääriset asiakkaat olivat valmiita elämään ongelmien kanssa, varhaisvaiheen omaksujien kanssa käytiin dialogia ja saimme jatkuvaa palautetta, jonka ansiosta menestyimme ja aloimme luottaa, että olimme oikeasti keksineet jotain. Emme järjestäneet launchia, emme miettineet PR:ää.

IMVU:n kohdeyleisönä olivat teini-ikäiset. Ries kertoi, että he olivat pyytäneet nuoria asiakkaita kutsumaan palveluun myös ystäviään. Palaute oli nuiva.

- Teini vastasi, ettei tiedä, haluaako kutsua, koska palvelu saattaa olla ihan laimea ja silloin olisi itsekin samanlainen. Kun kaikki kolme asiakasta kieltäytyi käyttämästä palvelua ja maksamasta, tietysti ajattelin, että pitäisiköhän tämä asiakas erottaa, haluan uuden. Kun kymmenen asiakasta kieltäytyy, se on selkeä viesti markkinoilta. - Eric Ries -

Jossain kohtaa on vedettävä raja, miten paljon yritys vastaa asiakkaiden toiveisiin.

- Asiakkailta saa kymmenen eri mielipidettä, jotka vievät tuotetta kaikki eri suuntiin. Moni ei lähde yrittäjäksi, koska tuleehan siitä päänsärky, että pitää olla samanaikaisesti kaksi vastakkaista ajatusta päässä.

Riesin mukaan yksi tapa on testata ominaisuuksia usein ja vaikka yhtä ominaisuutta vain yhdellä asiakkaalla. Silloinkin huomaa, mihin asiat ovat menossa, vaikka menetelmä tai laajuus ei tilastollisesti niin pätevä olisikaan.

Tuota tulosta rahassa, ei vain ominaisuuksissa

Kaiken pystyy kyllä toteuttamaan teknisesti. Oikea kysymys kuuluukin, kannattaako toteuttaa, onko sille markkinoita kuin kysyä, pystyykö jotain rakentamaan. Tavoitteena on ymmärtää ero, mikä ominaisuus tarvitaan oikeasti ja mikä on vain turhake, jonka tiimi jostain syystä eksyi toteuttamaan, vaikka kukaan asiakkaista ei kaivannut sitä.

Toisaalta Ries oli huolissaan, että monissa yrityksissä käytetään enemmän aikaa kinasteluun, tarvitaanko jotain ominaisuutta kuin mitä ominaisuuden rakentaminen vaatisi.

Vesiputous putoaa niskaan

Ries näytti perinteisen tuotekehityksen vesiputous-mallin, jossa ongelma tiedetään samoin kuin ratkaisu: ensin vaatimukset, sen jälkeen määrittely, suunnittelu, toteutus, testaus, ylläpito.

- Ketterässä tuotekehityksessä vain ongelma tiedetään, mutta ratkaisua ei. Jos insinöörillä on kysyttävää, hän voi kysyä suoraan asiakkaalta, miten jonkin asian pitäisi toimia ja saada siihen välitöntä palautetta. Näin ei vain viedä suunnitelmaa eteenpäin. - Eric Ries, Lean Startup Event Helsinki 10.11.2009 -

Ketterässä kehityksessa on myös niin vähän kokouksia kuin mahdollista ja niin hyvää koodia kuin ikinä, ettei tarvitse palata korjaamaan bugeja.

Ota opiksi, niin se oli hyödyksi

Eric Ries kuittaa, ettei aloittavassa yrityksessä tiedetä ongelmaa eikä ratkaisua. Tiimi saattaa piirtää taululle kuvioita ja ohjelmiston kehittäjä kirjoittelee kymmeniä tuhansia rivejä, ja lopulta saatetaan olla tilanteessa, jossa heitetään kuuden kuukauden hyvä ja huono koodi hukkaan, koska  kukaan ei haluakaan tuotetta.

Ries kertoi omista kokemuksistaan: miten oli hankala hyväksyä, että oma koodi menisi hukkaan. Olisiko sittenkin pitänyt vain lekotella rannalla, tulos olisi ollut yrityksen kannalta sama?

- Jos ei olisi tehty tuota kaikkea, ei olisi opittu mitään. Tosin aika korkein kustannuksin. Kaikki yritykset, jotka laskevat ominaisuuksia, ovat tiellä kohti tuhoa. Vain sillä on merkitystä, mistä asiakkaat ovat valmiita maksamaan.

- Yrittäjän ykkössääntö on ymmärtää, mikä toiminta lisää arvoa ja mikä menee vain hukkaan.

Ketterästi liikkeellä

Ketterissä stat-upeissa ideoimme tuotteen, rakennamme sen, keräämme tietoa, miten tuote toimii ja opimme siitä uusia ideoita varten. Jotta kaiken tämän voisi tehdä tehokkaasti, tulee muistaa Riesin selkeä suositus.

- Minimoi kokonaisaika, joka tuohon kaikkeen kuluu ja pidä vain kahta tiimiä, toinen keskittyy selvittämään, mitä ongelmaa yritämme ratkaista ja toinen tiimi rakentaa ratkaisua löydettyyn ongelmaan.

Eric Ries puhui Helsingissä Vera Venturen tiloissa (ps. hommatkaa sinne WiFi ja pistokkeita koneille). Riesin ajatuksia voi lukea blogista Lessons Learned.