CB Insights julkaisee vuosittain analyysin startup-yritysten epäonnistumisen syistä. Vuosikausia yleisin syy on ollut sama: "ei markkinalähtöistä tarvetta." Ei huono toteutus. Ei rahan loppuminen. Ei huono tiimi. Tuote yksinkertaisesti ei ratkaissut ongelmaa, josta ihmisillä olisi ollut tarpeeksi syytä muuttaa 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 lahjakkuutta. 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 universaalia ensikertalaisilla perustajilla ja yllättävän yleistä myös kokeneilla. Kaava on aina sama: jollakin on idea, se tuntuu houkuttelevalta ja he alkavat rakentaa. Asiakas on jälkiajatus — joku, joka täytyy vakuuttaa 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 ensimmäistä ominaisuutta ja jättää muut kaksi huomiotta. "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 jo on kaksitoista työkalua, jotka tekevät mitä haluat tehdä, tarvitset hyvin erityisen syyn sille, miksi omasi valittaisiin.
Tutkimuksella on huono maine tuotepiireissä — se liitetään hitaisiin konsultteihin, paksuihin raportteihin ja löydöksiin, joita kukaan ei lue. Se on toteutuksen epäonnistumista, ei käytännö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 "toimii jollain tavalla." 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.
Julkistuksen 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 instrumentoi ennen julkistusta. Tiedä, mitä tiettyjä toimintoja seuraat. Aseta kynnysarvo etukäteen — "pidämme tätä validoituna, jos X% käyttäjistä suorittaa Y 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 kerry 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, tee 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 toimituksen nopeus, on kilpailuetu.