CB Insights julkaisee vuosittain analyysin startup-yritysten epäonnistumisen syistä. Vuosikausia yleisin syy on ollut sama: ”ei markkinatarvetta”. Ei huono toteutus. Ei rahan loppuminen. Ei huono tiimi. Tuote yksinkertaisesti ei ratkaissut ongelmaa, josta ihmiset olisivat välittäneet tarpeeksi muuttaakseen käyttäytymistään.
Tuo tilasto on hätkähdyttävä, kun ottaa huomioon, kuinka paljon vaivaa tuotteiden rakentamiseen menee. Tiimit käyttävät kuukausia — joskus vuosia — järjestelmien suunnitteluun, koodin kirjoittamiseen, arkkitehtuurista väittelyyn ja työnkulkujen hiomiseen. Ja yleisin syy epäonnistumiseen on se, ettei kukaan kysynyt, ratkooko kaikki tämä oikeaa ongelmaa.
Sellaisten tuotteiden rakentaminen, joita ihmiset oikeasti haluavat, ei ole lahjakkuuden asia. Se on kurinalaisuutta. Sillä on menetelmä, ja menetelmä on opittavissa.
Yleisin tuotevirhe on rakastua ratkaisuun ennen kuin ymmärtää ongelman syvällisesti. Tämä on lähes universaali ilmiö ensikertalaisten perustajien keskuudessa ja yllättävän yleinen myös kokeneilla. Kaava on aina sama: jollakin on idea, se tuntuu houkuttelevalta ja he alkavat rakentaa. Asiakas on jälkiajatus — joku, joka pitää saada vakuuttuneeksi eikä ymmärtää.
Vastalääke ei ole monimutkainen, mutta se vaatii kurinalaisuutta: käytä enemmän aikaa ongelmaan kuin luulet tarpeelliseksi, ennen kuin harkitset ratkaisuja lainkaan. Puhu ihmisille, joilla ongelma on. Katso heidän työtään. Ymmärrä ne kiertotiet, joita he käyttävät tänään, ja miksi ne kiertotiet ovat epätäydellisiä. Vasta sitten sinulla on tarpeeksi kontekstia suunnitella jotain, joka todella sopii.
Hyvä tuotekehitys ei ole suora viiva — se on silmukka. Jokainen kierros silmukassa on mahdollisuus korvata olettamukset todisteilla. Tiimit, jotka rakentavat tuotteita, joita ihmiset haluavat, ovat niitä, jotka kiertävät tämän silmukan nopeasti ja usein.
Silmukka ei ole muodollisuus. Jokaisella vaiheella on tietty tuotos, joka muuttuu seuraavan vaiheen syötteeksi. Vaiheiden ohittaminen — useimmiten suoraan Ongelmasta Rakentamiseen — on se, mikä tuottaa tuotteita, jotka eivät osu maaliinsa.
Kaikki ongelmat eivät ole ratkaisemisen arvoisia. Hyvällä tuoteongelmalla on kolme ominaisuutta: se on toistuva (vaikuttaa ihmisiin usein eikä harvoin), se on intensiivinen (ihmiset kokevat sen niin voimakkaasti, että haluavat helpotusta) ja olemassa olevat ratkaisut ovat aidosti riittämättömiä (eivät vain hieman erilaisia kuin mitä rakentaisit).
Virhe on optimoida vain ensimmäistä ominaisuutta ja sivuuttaa kaksi muuta. ”Ihmiset tuhlaavat aikaa kokouksissa” on toistuva. Mutta jos kipu on vähäistä — jos ihmiset ovat löytäneet riittävän hyviä kiertoteitä — ongelma ei ehkä ole kaupallisesti ratkaisemisen arvoinen. Ja jos markkinoilla on jo kaksitoista työkalua, jotka tekevät sitä, mitä aiot tehdä, tarvitset hyvin täsmällisen syyn sille, miksi sinun tuotteesi valittaisiin.
Tutkimuksella on huono maine tuotepiireissä — se yhdistetään hitaisiin konsulttitaloihin, paksuihin raportteihin ja löydöksiin, joita kukaan ei lue. Se on toteutuksen epäonnistuminen, ei menetelmän. Hyvä tuotetutkimus on nopeaa, täsmällistä ja muuttaa sitä, mitä rakennat.
Tutkimuksen tavoite ei ole vahvistaa, että ongelma on todellinen. Sinun pitäisi jo uskoa siihen ennen kuin investoit voimakkaasti tutkimukseen. Tavoite on ymmärtää ongelma niin syvällisesti, että tiedät miltä hyvä ratkaisu näyttää: kenellä nimenomaan ongelma on, missä yhteydessä, mitä he ovat jo yrittäneet, mitä sanoja he käyttävät kuvaillessaan sitä, ja miltä ”ratkaistu” näyttäisi heille.
Hypoteesi on täsmällinen, falsifioitavissa oleva ennuste siitä, mitä uskot olevan totta. Se pakottaa selkeyteen. Jos et pysty kirjoittamaan selkeää hypoteesia, et vielä ymmärrä ongelmaa tarpeeksi hyvin rakentaaksesi ratkaisun.
Hyödyllisellä tuotehypoteesilla on kolme osaa:
Signaali on tärkein osa — ja useimmin jätetty pois. Ilman etukäteen sitoutunutta signaalia jokainen kokeilu ”onnistui jotenkin”. Tiimit löytävät tapoja tulkita epäselvää dataa myönteisesti. Hypoteesi ilman falsifikaatioehtoa on vain toive.
Rakennusvaihe on se, johon useimmat tiimit käyttävät liikaa aikaa. Tavoite ei ole rakentaa tuote — se on rakentaa minimi, joka antaa signaalin hypoteesistasi. Nämä ovat eri tavoitteita ja ne tuottavat hyvin erilaisia tuloksia.
Useimmille varhaisvaiheen hypoteeseille minimi on paljon vähemmän kuin tiimit ajattelevat. Voitko manuaalisesti tehdä sen, mitä ohjelmisto tekisi, kymmenelle ihmiselle, testataksesi arvostavatko he tulosta? Voitko yhdistellä olemassa olevia työkaluja ja testata työnkulkua ennen kuin rakennat uuden infrastruktuurin? Voitko luonnostella prototyypin ja käydä sen läpi viiden käyttäjän kanssa ennen koodin kirjoittamista?
Kurinalaisuus tässä on kysyä ennen minkään rakentamista: ”Mitä yritän oppia?” ja ”Mikä on minimi, joka antaisi minulle mahdollisuuden oppia se?” Vastaus on lähes aina pienempi kuin mitä tiimi haluaa rakentaa.
Lanseerauksen jälkeen — olipa se prototyyppi, manuaalinen pilotti tai julkaistu ominaisuus — mittausvaihe on se, jossa tiimit useimmiten pettävät itsensä. He kysyvät käyttäjiltä, pitivätkö he siitä. Käyttäjät sanovat kyllä. Tiimi merkitsee kokeilun validoiduksi.
Tunne ei ole signaali. Ainoa luotettava signaali on käyttäytyminen: tekivätkö ihmiset asian? Palasivatko he? Maksoivatko he? Kertoivatko he muille?
Kvantitatiivista mittausta varten ota mittarit käyttöön ennen lanseerausta. Tiedä, mitä tiettyjä toimintoja seuraat. Aseta kynnysarvo etukäteen — ”pidämme tätä validoituna, jos X % käyttäjistä suorittaa Y:n Z päivän sisällä.” Kvalitatiiviseen mittaukseen suorita strukturoituja jatkohaastatteluja, ei avoimia tyytyväisyyskyselyjä.
Oppimisvaiheen tarkoitus on päivittää mentaalinen mallisi käyttäjästä ja ongelmasta, ei vain päättää, mitä rakennetaan seuraavaksi. Tiimit, jotka ohittavat tämän vaiheen, keräävät dataa mutta eivät kartuta ymmärrystä. He toteuttavat nopeasti mutta eivät paranna harkintakykyään ajan myötä.
Hyvä oppimissessio kysyy: Mitä ennustimme? Mitä oikeasti tapahtui? Mitä aukko kertoo olettamuksistamme? Mikä on nyt tärkein asia, jota emme tiedä?
Oppimisvaiheen tuotos on tarkempi ongelmanmäärittely, tarkistettu hypoteesi tai — jos kokeilu selvästi epäonnistui — päätös seurata täysin erilaista suuntaa. Kaikki nämä tulokset ovat arvokkaita. Huonoin tulos on epäselvyys: ”opimme jotain mutta emme ole varmoja mitä tehdä seuraavaksi.” Se on merkki siitä, ettei kokeilu ollut tarpeeksi täsmällinen.
Tuotekehitys ei koskaan saavuta vaihetta, jossa lopetat tämän silmukan pyörittämisen. Kysymykset muuttuvat — varhaisvaiheessa validoit, onko ongelma todellinen; myöhemmin validoit, toimiiko tietty ratkaisuelementti — mutta rakenne on aina sama. Tarkkaile, muodosta hypoteesi, testaa, opi.
Tiimit, jotka rakentavat tuotteita, joita ihmiset haluavat, eivät ole niitä, joilla on älykkäin alkuperäinen oivallus. Ne ovat niitä, jotka kiertävät silmukan nopeimmin ja rehellisimmin. Oppimisen nopeus, ei julkaisun nopeus, on kilpailuetu.