#1 - Liiga rumal, et hinnata oma rumalust

Startupi edu tõenäosus väheneb kaasatud raha hulgaga. Kui on raha, siis minnakse õhinapõhiselt galoppides tegelema tootearendusega. Kuid seda raha võiks selle asemel kasutada probleemi leidmiseks ja hüpoteesi testimiseks.

Näpud kõrvas, klapid silmas - ignorantsusest oli minul endal jäänud küsimata küsimused - millise töö tegemiseks kasutaja meid palkab? Kes on kasutaja, mida ta teeb, mida ta vajab, kuidas ta mõtleb? Ma ei osanud neid küsimusi päris õigesti küsida endaltki, rääkimata teistest. "Job to be done" selles osas muutis täielikult mõttemalli.

Tulemus oli keskpärane või alla selle. Pidasin end põhjendamatult targaks, kuniks kumm enam ei veninud ja see lõi täie hooga kuklasse.

Kuidas olla tark kapitalist? Eelda, et sa ei tea mitte midagi! Sest enamasti nii ongi. Mine välja ja küsi küsimusi.

Mida küsida?
Sinu klient tahab saada A-st B-sse. Sinu lahendus on sild seal vahel.

• Milline on status quo? Mis sinu elus toimus, kui hakkasid
• Mis on

#2 – Probleeme ei testinud

Oled seda kuulnud: "kõigepealt leia probleem, siis tee toode"? Nagu piksega pähe löödud, tegin ikka vastupidi. Muidugi mitte sihipäraselt, vaid kogemata!

Miks on meil kombeks enne teha toode, ja siis otsida sellele probleem?

#1 - me peame iseend targemaks

#2 - me ei ole oma tarkust testinud

Kuidas leida hea probleem? 

• Selle probleemi ilmnemisel on suur tagajärg 
• See probleem on vältimatu 
• See probleem on olnud ajas püsiv ja korduv
• See probleem on lahendamata 

Toon näitena Syda kasutajate enamlevinud probleemi

• Arvete koostamine võtab tohutult palju aega, ja selle tegemata jätmisel on suur tagajärg 
• Arvete koostamist ei saa vältida 
• See probleem kordub kuust kuusse 
• See probleem on lahendamata, sest andmete kogumiseks ei ole sobivat tööriista 

Probleemi ja sõnumi valideerimiseks mine küsi kasutajalt, kust tema king pigistab. Pea meeles, et

• mida rohkem räägid sina, seda vähem räägib kasutaja
• inimene on sotsiaalne loom ning ta tahab sulle meeldida rohkem, kui ta ise sellest aru saab. Tema väited on rafineeritud läbi meeldimise prisma
• küsi küsimusi nii detailselt, et sa oskad kasutajateekonna probleemist lahenduseni panna kirja, seda joonistada, ja ise järgi teha

#3 - Hüpoteeside testimiseks puudus protseduur

Püstita hüpotees ning testi - kiiresti ja odavalt. Selleks on protseduur:

• Püstita hüpotees
• Hüpoteesi põhjal ehita MVP
• Mõõda MVP tulemusi
• Tee järeldusi ning alusta otsast, kuniks hüpotees, MVP ja tulemused on kooskõlas

Protseduuri eesmärk on teada saada, kas sinu kasutaja palkaks sinu toote, et see teeks ära soovitud töö? Vihjeid selleks leiad hääletoonist, näoilmest, aga mitte küsides, "kas maksaksid selle eest". Kirjeldan eeltoodud nelja sammu detailsemalt

Hüpotees ise

Ära tegutse poolumbes, vaid sihipäraselt. Kasutaja eesmärk on saada punktist A  punkti B. Hüpotees väidab, et valitud toode on sillaks A ja B vahel ning teeb seda X omaduse tõttu paremini, kui kliendile hetkel harjumuspärane lahendus.

"Job To Be Done" küsib - mille jaoks klient sinu teenust palkab? Kas sinu teenus teeb töö ära paremini, kui see, mida ta seni on kasutanud?

MVP

Ehita see sild, mis viib punktist A punkti B, väikeselt, odavalt ja kitsilt. Sinu eesmärk on teada saada, kas keegi seda silda kasutab. Sinu toote tuumik ilma lisavidinateta peab olema nii atraktiivne, et selle eest makstaks. Kui sul juba on kasutajad, siis selle puudumine võiks häirida vähemalt 50% kasutajatest.

Mõõda tulemusi

Mõõda tulemusi. Sõltuvalt hüpoteesist tasub kõigil tuua rõhku kvalitatiivsele mõõtmisele. Kvalitatiivne analüüs on raske - peab  inimestega rääkima, ja peab seisma vastu enese “ma juba tean kõike” suhtumisele. Tegelikult kipume inimestena üle hindama enda teadmisi. Ma ei näe mitte ühtegi aspekti, kuidas digitaalne kvantitatiivne analüütika oleks parem, kui personaalne ja kvalitatiivne.

Siinkohal hoiatus - inimesed sageli ütlevad, et nad vajavad “veel ühte” asja, et nad toote eest maksaksid. Enamasti tähendab see, et probleemi püstitus on vale, toote tuumik ei vasta nende ootustele, ja et sinu hüpotees ei pea paika.

Tee järeldusi 

Tee järeldusi. Mida on vaja muuta, et valitud teekond toimiks paremini? Kas muuta hüpoteesi? Kas muuta toodet? Muuta funktsionaalsust? Ülesehitust, struktuuri? Millise probleemi lahendamiseks on nad senised tooted/teenused endale palganud?

Toon näite Syda püstitatud hüpoteesist 

• Kasutaja tugevaim probleem on arvete koostamiseks vajalike andmete kokku kogumine. Syda teeb tellimuste digitaliseerimise, andmete kogumise ja toote implementeerimise nii lihtsaks ja arusaadavaks, et see on atraktiivne isegi siis, kus integratsioone muude tarkvaradega veel ei ole loodud.
• Syda prototüübi valmistasin Canvas PPTX põhjale.
• Teadsin probleemi: andmete kogumine. Prototüüpi testisin kvalitatiivsel meetodil 7 erineva valdkonna ettevõtte peal. Küsisin mida ta näeb, kuidas ta sellest aru saab, kui kiiresti aitab see tal andmeid koguda.
• Tegin vajalikke järeldusi nii probleemipüstituse, hüpoteesi sõnastamise kui ka MVP ehituse jaoks. Leidsin ühisosad erinevate valdkondade ettevõtete vahel, sõna otseses mõttes neid välja joonistades, ja asusin neid lahendama. Seejärel kordasin kogu protsessi.

Kokkuvõtteks

Selleks, et toote- ja äriarendus oleksid kooskõlas, tuleb saada aru, mida kasutaja tegelikult tahab (mitte, mida ta väidab, et ta tahab, ja mida sina arvad, et ta võiks tahta).

On muidugi erinevaid koolkondi, kes ütlevad, et oluline on kõigepealt leida kasutaja, teised, et ärimudel. Mina väidan, et lõpuks ostetakse ikkagi toodet, mistõttu peaks just tootearendus olema ka ärilise tegevuse fookuses - kuidas teha nii, et tootearenduse tsükkel oleks võimalikult lühike, et võimalikult kiiresti jõuda tulemuseni, mis kasutajaid kõnetaks.

Kliendid leiad endale väljatöötatud tsüklit korduvalt läbi käies, sest olgem ausad - inimestele meeldib, kui neilt küsitakse nõu. See tekitab neis olulise ja tähtsa tunde. Kui nad on saanud rääkida, tekib neis tunne, et neid on kuulatud. Kui neid on kuulatud, on nad avatud sinu pakkumisele. Selliselt toimides leida endale esimesed 1-10 klienti ei saa olla probleem.