Browse Category: Tuotekehitys

photo-1418225162054-0f773a996f9e

Tärkein päätös uuden liiketoiminnan tai tuotteen suunnittelussa

Olen perustanut useamman liiketoiminnan ja kehittänyt kymmeniä uusia tuotteita. Näiden kokemusten perusteella olen tullut siihen tulokseen, että yksi päätös on ylitse muiden kehitystyön alkuvaiheessa.

Mikä tämä päätös sitten on? Se on päätös siitä, kuka on tuotteen tai liiketoiminnan asiakas.

Kerron tässä kirjoituksessa ensin miksi asiakkaan valitseminen on mielestäni kaikkein tärkeintä ja sen jälkeen millä tavalla asiakkaan valinta kannattaa käytännössä tehdä. Tosin tämä asiakkaan valitsemisohje keskittyy yritysasiakkaisiin, joten kuluttajia palvelevaa liiketoimintaa suunnittelevat joutuvat tekemään soveltavaa ajatustyötä.

Miksi asiakasvalinta on A ja O?

Aina, kun kehitämme jotakin uutta, alkuperäinen idea muuttuu ajan myötä joksikin aivan muuksi, kuin mitä se alun perin oli. Siksi ideasta tai ratkaisusta lähteminen on tuhoon tuomittua. Ensimmäinen bisnesidea tai ajatus tietyn ongelman ratkaisusta ei kuitenkaan tule toimimaan.

Jos sen sijaan liiketoiminta alkaa asiakkaan valitsemisesta, voimme kehitellä erilaisia ratkaisuja asiakkaiden erilaisiin ongelmiin. Heti asiakkaan valinnan jälkeen näiden asiakkaiden kanssa täytyy keskustella, jotta opimme mitkä ovat valitsemallemme asiakasryhmälle isoja ja tärkeitä ongelmia. Sen jälkeen voimme kehitellä niihin erilaisia ratkaisuja ja katsoa mitkä ratkaisuista ovat asiakkaiden mielestä toimivia.

Tässä mallissa myönnämme siis heti kärkeen, että emme päivänä 1 tiedä mitä tulemme tekemään. Mutta valitsemamme asiakas voi pysyä valitsemanamme asiakkaana, vaikka liikeidea kehittyy mekaanisesta lapiosta sosiaaliseksi mediaksi.

Suurin ongelma asiakkaan valitsemisessa on, että asiakas määritellään hyvin ylimalkaisesti. Vaikkapa markkinointijohtaja, myyntitoiminto, perheenäiti tai autorakas. Näin yleismaallisesti määritellyllä asiakasryhmällä ei usein ole yhteisiä ongelmia, prioriteetteja ja arvostuksia. Se tekee myynnistä, markkinoinnista ja tuotekehityksestä vaikeaa ja tehotonta.

Mutta rajaaminenhan tarkoittaa mitättömän pientä bisnestä!

Monesti tiukkaa asiakasvalintaa vastustetaan, koska se näyttäisi rajaavan asiakaskunnan todella pieneksi. Oikeastaan tämä ei ole ongelma, koska asiakaskuntaa voi aina kasvattaa.

Hyvä esimerkki tästä on kyydinjakopalvelu Uber. He aloittivat välittämällä tyyriitä autokyytejä varakkaille ihmisille San Fransiscon alueella. Vaikka Piilaaksossa onkin paljon äveriästä porukkaa, niin piilaaksolaiset miljonäärit näyttäytyy todella pienenä kohderyhmänä, jos suunnittelee maailmanvalloitusta.

Uber aloitti siis hyvin pienestä kohderyhmästä. Kun he saivat siellä bisneksen pystyyn, he laajensivat. Ja laajensivat. Ja laajensivat.

Toinen esimerkki on sosiaalinen verkosto, joka aloitti yhden yhdysvaltalaisen yliopiston sisäisenä työkaluna. Kyseessä on tietysti Harvardista ponnistanut Facebook, johon kuuluu muistaakseni jokunen miljardi käyttäjää tänä päivänä. Aikamoinen kasvu verrattuna alkuperäiseen yleisöön. Joitakin lukuja tarjotakseni, niin Harvardiin otetaan n. 2 000 opiskelijaa vuodessa, joten käyttäjäkunta on alun perin rajattu arvioita noin 10 000 käyttäjään.

Eikö ongelman valitseminen ole yhtä hyvä tai parempi vaihtoehto?

Ongelman valitseminen yrityksen tai tuotteen ensisijaiseksi ohjaavaksi tekijäksi on monin tavoin hyvä vaihtoehto. Ongelma on ja pysyy, vaikka ratkaisutapa muuttuu.

Mikä sitten on ongelman ongelma? (Heh, heh.) Heti kun bisnekselle tai tuotteelle pitäisi löytää asiakkaita, ongelma paljastuu.

Tässä esimerkkidialogi:

Minä: Ketkä sitten ovat potentiaalisia ostajia?
Tuotekehittäjä: No kaikki, joiden mielestä leivänpaahdinten aukot ovat liian pienet.
M: Keitä he ovat?
T: No… Tuota… Siis… Ehkä… Jotkut ihmiset, jotka haluavat paahtaa paksuja leipiä, ehkä?
M: Mitä sitten tarjoatte heille?
T: Leivänpaahtimen, jossa on isot aukot.

Aika vaikeaa on tällä määritelmällä löytää asiakkaita. Entä, jos tarinan tuotekehittäjä olisikin lähtenyt liikkeelle asiakkaista? Keskustelu voisi mennä vaikka näin:

Minä: Ketkä sitten ovat potentiaalisia ostajia?
Tuotekehittäjä: Sinkkumiehet, joita ruoanlaitto ei kiinnosta.
M: Mistä heitä löytyy?
T: Kysyin Facebookissa ja löysimme heti kuusitoista henkilöä, jotka tunnistivat kuuluvansa kohderyhmään.
M: Mitä sitten tarjoatte heille?
T: Paremman leivänpaahtimen, mutta en tiedä vielä mikä se on. Siksi olemme menossa puhumaan asiakkaille. Hypoteesimme on, että isompien aukkojen avulla voisi paahtaa vaikka mitä, mutta jää nähtäväksi onko se kiinnostavaa vai ei.

Huomaatko eron? Kakkosvaihtoehdossa on helpompi löytää asiakkaita. Ja kun asiakkaita on helppo löytää, niin koko bisneksen pyörittäminen helpottuu. Jos leivänpaahdin ei olekaan oikea ratkaisu, niin sen voi kätevästi vaihtaa vaikka tehosekoittimeen tai kuukausimaksulliseen valmisruokapalveluun, jolloin kohderyhmä pysyy samana.

Päätöskehikko (yritys-)asiakkaan valintaan

Katsotaan seuraavaksi kuinka asiakkaan valitseminen käytännössä tapahtuisi yritysasiakaskentässä ja millaisia vaikutuksia sillä olisi. Lista huomioitavista muuttujista ei varmasti ole tyhjentävä, mutta keräsin siihen asioita, joiden olen itse nähnyt vaikuttavan paljon yrityksen luonteeseen ja sitä kautta sen ongelmiin.

Koko

Onko yritys iso, keskikokoinen vai pieni? Mietitään näiden vaikutuksia ohjelmistolisenssien hallintaa esimerkkitapauksena käyttäen.

Pienellä yrityksellä on kolme tietokonetta ja yrittäjä itse on ostanut jokaiseen tarvittavat lisenssit. Siten lisenssien hallinta ei ole mitenkään vaikeaa, eikä yrittäjälle tule mieleenkään maksaa lisenssien hallintaratkaisusta. Pörssiyhtiöllä taas voi olla kymmeniä tuhansia lisenssejä kymmenissä eri maissa. Siellä kukaan ei tiedä mitä lisenssejä on ostettu, miten monta ja missä kaikkialla ko. ohjelmistoja on käytössä. Siispä lisenssien hallinta on isossa yhtiössä oikea ongelma ja sen ratkaisemisesta ollaan valmiita maksamaan.

Yrityksen koko liittyy myös hinnoitteluun. Iso firma voi pitää 100 000 euron ratkaisua edullisena lisenssienhallintaratkaisuna. Keskikokoiselle sopiva summa samaan asiaan voisi olla vaikka 10 000. Pieni firma ei puolestaan välttämättä ole valmis maksamaan moisesta mitään.

Vaihe

Onko yritys nuori vai vanha? Yrityksen ikä voi vaikuttaa moneen asiaan. Otetaan esimerkiksi myynti. Nuorella yrityksellä pääpaino on todennäköisesti uusasiakashankinnassa. Pidempään toimineella yrityksellä iso osa liikevaihdosta tulee tyypillisesti nykyisiltä asiakkailta. Pitkään toimineen yrityksen haasteena voisi olla nykyisten asiakkaiden mielikuvan muuttaminen, jotta he ostaisivat firmalta muutakin kuin mitä se möi 10 vuotta sitten. Nuorella yrityksellä taas ei ole tällaista ongelmaa lainkaan.

Maantiede

Onko yritys alueellinen, kansallinen vai kansainvälinen? Onko sen markkina koko maailma vai esim. Eurooppa tai Kiina? Pelkästään helsinkiläisiä kahviloita palvelevan yrityksen bisnes on aika erilainen kuin jos liiketoiminta perustuu Kiinan vientiin.

Kansainvälistä bisnestä pyörittävälle ohjelmistotalolle on tärkeää, että käyttöliittymäsuunnittelija tuntee isoimpien markkinoiden kulttuurit. Se mikä toimii Suomessa ei välttämättä toimi USA:ssa. Puhtaasti Suomessa toimivalle ohjelmistotalolle kulttuurillinen tuntemus ja herkkyys ovat yhdentekeviä, kunhan tuntee tämän yhden kulttuurin ja mikä siellä toimii. Toisaalta pelkästään englantia taitavalle suunnittelijalle voi olla vähemmän kysyntää kotimarkkinayrityksissä, sillä paikallisen kielen taitaminen yleensä nopeuttaa suunnitelutyötä ja vähentää siihen liittyvän viestinnän (esim. käännösten) tarvetta.

Konserni

Palveletko pääkonttoria, liiketoiminta-aluetta vai maayhtiötä? Niillä on kaikilla omat, erilaiset ongelmat. Myös konserniin kuuluminen itsessään aiheuttaa liiketoiminnalle sellaisia haasteita, joita itsenäisellä yhtiöllä ei ole. Pääkonttorilla on ihan omat ongelmansa verrattuna maayhtiöön.

Otetaan esimerkiksi verkkosivut. Pääkonttori haluaa ostaa sellaiset verkkosivut, joihin maayhtiöt voivat itsenäisesti tuottaa sisältöä. Pääkonttori haluaa silti pitää ulkoasun, navigaation ym. omissa näpeissään. Siispä teknisen ratkaisun tulee olla edistyksellinen. Maayhtiö puolestaan tarvitsee apua nimenomaan sisällön kanssa, koska ulkoasu, tekniikka ja rakenne tulee valmiina, eikä niihin pääse vaikuttamaan. Itsenäinen yhtiö puolestaan haluaa tyypillisessä tapauksessa koko paketin.

Asiakaskunta

Palveleeko yritys kuluttajia vai yritysasiakkaita? Ovatko sen asiakkaat isoja, pieniä vai keskikokoisia yhtiöitä? 10 miljoonaa vaihtava yritys, jolla on 100 asiakasta on täysin erilainen organisaationa ja prioriteeteiltaan kuin 10 miljoonaa vaihtava yritys, jolla on 10 000 asiakasta.

Mitä pienempi liikevaihto per asiakas, sitä edullisemmin transaktio täytyy saada aikaiseksi. Tämä tarkoittaa usein markkinointivetoista ja/tai kumppanivetoista myyntitapaa.

Jakelukanava

Olen omakohtaisesti kokenut kuinka erilaista on myydä suoraan lopullisille asiakkaille tai toimia jälleenmyyjien kautta. Myynillisessä mielessä mallit ovat kuin yö ja päivä, kummassakin on omat hyvät ja huonot puolensa. Tämä meinaa, että mallit aiheuttavat yritykselle hyvin erilaisia päänsärkyjä.

Myyntitapa

Kuten jakelukanava, niin myös suoramyynnin myyntitapa vaikuttaa reilusti yrityksen toimintaperiaatteisiin ja prioriteetteihin. Myyntitapoja voivat olla esim. verkkomyynti, tuotemyynti ja ratkaisumyynti. Myyntitapa on vahvasti sidoksissa myös asiakaskuntaan ja siihen, onko kyseessä kulutuskama vai investointihyödyke.

Otetaan esimerkki. Jos yritys myy verkossa, sen myynnin kustannuksia ovat mainonta, optimointi, maksupalvelu ja verkkokauppa-alusta. Nämä ovat siis tärkeitä asioita. Ratkaisumyynnissä myynnin työkaluja ovat puolestaan kallispalkkaiset ratkaisumyyjät. Silloin heistä pitää saada täysi ilo irti, eikä esimerkiksi verkkomainonnan rooli edusta edes pyöristysvirhettä.

Fyysinen vs digitaalinen

Yrityksen myymä tuote on tyypillisesti joko fyysinen tuote, digitaalinen tuote tai yhdistelmä molempia. Fyysiseen tuotteeseen liittyy paljon sellaista, mikä ei ole lainkaan relevanttia digitaalisten tuotteiden osalta. Esimerkiksi komponenttien kulut, varastointi, kuljetuskulut jne. Digitaaliset tuotteet eivät puolestaan näy taseessa, mutta pysyäkseen kilpailukykyisenä, niitä täytyy yleensä kehittää jatkuvasti. Fyysisten tuotteiden osalta tuotantoprosessi usein rajoittaa uusien tuoteversioiden syntymistä, kun taas digitaalisessa maailmassa uusi versio voi olla asiakkaiden käsissä käytännössä tunnin välein.

Korkeaa vs matalaa teknologiaa

Korkean teknologian tuotteet ovat usein hintavampia kuin matalan teknologian tuotteet. Korkean teknologian tuotteiden ostajat arvostavat erilaisia asioita ja kehityskulujen osuus liikevaihdosta on todennäköisesti eri luokkaa. Matalan teknologian tuotteiden osalta palvelu, saatavuus, kokemus ja hinta ovat tyypillisesti tärkempiä ostopäätöksen ajureita kuin korkean teknologian tuotteissa.

Kulutuskamaa vs investointihyödyke

Tehdäänkö kauppaa paljon ja usein vai vähän ja harvoin? Tämä vaikuttaa yllättävän paljon koko bisneksen rakenteeseen. Kulutuskamaa myydään prosessimaisesti, investointihyödykkeitä projektimaisesti.

Kuka maksaa

Kuka maksaa kulut on myynnin kannalta yksi oleellisimmista kysymyksistä. A ja O on, että kuluille on selkeä maksaja. Jos ostopäätös vaatii, että esimerkiksi IT-johtaja ja markkinointijohtaja pystyvät sopimaan keskenään kumman budjetista kulut otetaan, ostopäätöksen teko on 10 kertaa vaikeampaa kuin jos kulu hyvin selkeästi kuuluu markkinointijohtajan budjettiin. Vastaus kysymykseen ”kuka maksaa” on usein joku rooli, esimerkiksi markkinointijohtaja, myyntijohtaja, toimitusjohtaja tai vaikka vastaanottoapulainen, jos uskomme voivamme myydä hänelle jotakin.

Lopuksi

Yllä olevia muuttujia käyttämällä kannustan uuden liiketoiminnan suunnittelijaa valitsemaan asiakkaan niin, että:

  • asiakas on sellainen, jonka kanssa haluat tehdä töitä ja
  • asiakkaan tilanne on sellainen, johon sinulla on annettavaa.

Kun asiakas on lyöty lukkoon, voi siirtyä miettimään millaisia ongelmia ko. asiakkailla voisi olla. Kun ensimmäisen ongelman on ratkaissut, voi siirtyä ratkomaan samojen asiakkaiden seuraavia ongelmia. Kuten tiedämme, olemassa oleville asiakkaille on helpompi ja edullisempi myydä myydä lisää kuin hankkia kokonaan uusia asiakkaita.

Asiakkaan valinta helpottaa uuden liiketoiminnan suunnittelua heti alusta alkaen. Esimerkiksi ison, vanhan organisaation myyntijohtajien ongelmat tuuppaavat olemaan kohtalaisen samankaltaisia. Samoin nettipohjaisten, kuluttajakeskeisten startupien toimitusjohtajien ongelmat.

Niinpä asiakkaan valinta mahdollistaa kohtalaisten arvausten tekemisen asiakkaiden isoimmista ongelmista jo ennen kuin niitä on päässyt validoimaan keskustelemalla ensimmäisten asiakkaiden kanssa.

Asiakkaan valinta on siitä tuskallinen päätös, ettei valinnassa ole olemassa oikeaa ja väärää. On vain erilaisia asiakkaita ja heillä on erilaisia ongelmia. Tärkeintä on uskaltaa tehdä päätös, ketä palvelee.

photo-1442849914809-0df6c377974f

Millainen suunnittelu on hyödyllistä? 

Myönnän heti, että minulla on viha-rakkaussuhde suunnitteluun. Tietynlaisesta suunnittelusta pidän kovasti tai toisentyyppistä suunnittelua en voi sietää. Tämän kirjoituksen tarkoituksena on tarkastella millainen suunnittelu on mielestäni hyödyllistä ja millainen ei.

Pitkä ja yksityiskohtainen suunnitelma

Aloitan ääripäistä. Yhdessä ääripäässä on kaksisataasivuinen suuunnitelma, johon on kirjattu yksityiskohtaisesti mitä suunnitelman tekijän mukaan tulee tapahtumaan kolmen vuoden päästä.

Konsultit pitävät usein tarkoista suunnitelmista. Samoin osa johtajista. Tarkka suunnitelma tuntuu turvalliselta. Se luo vaikutelman hallinnasta. Työn etenemistä on helppo verrata yksityiskohtaiseen suunnitelmaan.

Paha vaan, että suunnitteleminen on ennustamista ja ennustaminen on tunnetusti vaikeaa.

Kuten varmasti arvaat, en ole tarkan ja kauaskantoisen suunnittelun ystävä. Syy on selvä. Suunnitelma perustuu aina suureen määrään oletuksia tuntemattomasta. Ainakin osa oletuksista osoittautuu väistämättä vääräksi. Silloin suunnitelma vaatii muuttamista ja tarkentamista.

Mitä tarkempi ja pidempi suunnitelma, sitä useammin sitä pitää säätää, jotta se pysyy toteutuskelpoisena. Ja mitä tarkempi ja pidempi suunnitelma, sen enemmän työtä suunnitelman säätäminen teettää. Suunnitelman jatkuva säätäminen on yleensä pois sen toteuttamiselta ja toteuttaminen on se osa, joka oikeasti tuottaa tuloksia.

Kaikkein pahin tilanne syntyy silloin, kun yksi taho on tehnyt suunnitelman ja toinen taho toteuttaa sen niin, ettei alkuperäinen suunnittelija ole enää mukana säätämässä, muuttamassa ja tarkentamassa suunnitelmaa sitä mukaan, kun väärät oletukset työn edetessä selviävät.

Usein sanotaan, että hyvin suunniteltu on puoliksi tehty. Törmäsin joskus vaihtoehtoiseen sananlaskuun, joka kuvaa tilannetta todenmukaisemmin. Sen mukaan hyvin suunniteltu on vielä täysin tekemättä.

Katsotaan seuraavaksi miten käy, jos ei suunnittele yhtään.

Soitellen soitaan

Toinen ääripää on jättää suunnitteleminen tyystin tekemättä. Eli käydään sen kummempia miettimättä töihin. Tämä vaihtoehto on ihan yhtä huono kuin yliampuvan suunnitelman värkkääminenkin.

Nyt kuulen jo jonkun näsäviisaan huutelevan, että eikö tämä ole sitä kokeilukulttuuria ja ketterää tekemistä, että tehdään vaan. Ei se ole. Kokeileminen vaatii, että tietää mitä on kokeilemassa. Eli suunnittelua. Vaikka olen aiemmin väittänyt ettei kokeilu voi epäonnistua, sanon nyt, että se voi. Nimittäin silloin, kun kokeilusta ei opita mitään.

Visio ja ensiaskeleet

Oma lempparini kulkekoon nimellä visio ja ensiaskeleet. Tällä tarkoitan sitä, että vaikkapa projektin alussa miettii mitä noin suurin piirtein haluaa projektilla saavuttaa. Sen jälkeen suunnittelee mitkä ovat ensimmäiset askeleet kohti haluttua visiota.

Ensiaskelten aikana paljastuu yleensä kaikenlaista, mitä ei ollut osannut ottaa huomioon. Tämän uuden tiedon perusteella voikin sitten suunnitella seuraavat askeleet. Kun prosessia toistaa tarpeeksi monta kertaa, päätyy koko ajan vähän lähemmäksi visiota ilman, että on tehnyt suurta määrää turhaa suunnittelutyötä.

Mitä jos -suunnittelu

Yksi tärkeimmistä suunnitelumenetelmistä on mitä jos -suunnittelu. Sitä voinee kutsua myös skenaariosuunnitteluksi.

Ajatuksena on miettiä mitä kaikkea voi tapahtua ja suunnitella vaihtoehtoisia toimintatapoja näitä sattumuksia varten. Mitä teen, jos Pekka ei toimitakaan lupaamaansa sorakuormaa? Miten toimimme, jos emme saakaan kaikkia viittä kehittäjää mukaan tiimiin? Miten voin silti toimittaa jotakin, vaikka kukaan muu ei pystyisi toimittamaan mitään, mitä ovat luvanneet?

Otan tästä arkisen esimerkin. Kylpyhuonettamme remontoidaan. Suunnitelmat ja sopimukset tehtiin useita kuukausia ennnen remontin alkamista. Silti remontin aikana sain viestin, ettei haluttua kaakelia olekaan saatavilla. Urakoitsija oli siis olettanut, että saa toivottua kaakelia muutaman päivän toimitusajalla. Noh, todistetusti oletus oli väärä.

Jos urakoitsija olisi käynyt läpi mikä voi mennä pieleen, heidän hankevastaavansa olisi voinut tilata kaakelit hyvissä ajoin. Tai pyytää hyvissä ajoin valitsemaan varavaihtoehdot kaikelle mahdolliselle, jos ennakkotilaaminen tuntemattomasta syystä on mahdotonta.

Olen törmännyt samaan ongelmaan lukuisissa hankkeissa niin töissä kuin vapaalla. Tehdään yksi suunnitelma ja oletetaan, että se on toteutuskelpoinen. Oletetaan, että kaikki sujuu optimaalisesti ja kaikki pitävät lupauksensa. Sellaisia olettamalla kaivaa itselleen oikein mojovan kuopan.

Jokainen projektipäällikkö, johtaja ja tilaaja on varmasti törmännyt tilanteeseen, jossa joku käytännössä sanoo:

”En voi pitää lupaustani, koska tämä minusta riippumaton olosuhde on muuttunut.”

Mitä jos -suunnittelun tarkoituksena on minimoida todennäköisyys joutua käyttämään tätä puolustusta. Kannustamalla muita tekemään mitä jos -suunnittelua minimoi todennäköisyyden joutua itse kuulemaan tätä puolustusta muilta.

Yhteenveto ja Twitteristä sorsastettuja ajatuksia

Suunnitteleminen on tärkeää, mutta liian tarkka ja liian pitkälle ulottuva suunnittelu tuottavat toteutuskelvottomia suunnitelmia. Hyvä suunnitelma tarkentuu ja muuttuu sitä mukaan, kun tehdessä oppii.

Tärkeintä on mielestäni, että tietää mihin pyrkii ja tietää mistä lähtee liikkeelle. Töiden edetessä on tärkeää tehdä jatkuvaa mitä jos -suunnittelua, jotta pystyy toimittamaan tuloksia myös silloin, kun itsestä riippumattomat syyt vaikeuttavat tilannetta.

Juha Eteläniemi summasi hyvin missä vaiheessa kannattaa siirtyä suunnittelusta toteutukseen:

Ari-Pekka Lappi kiteytti missä vaiheessa prosessia/projektia kannattaa painottaa minkäkinlaista suunnittelua:

Kiitokset ajatuksia Twitterissä esittäneille ja muille, joiden kanssa olen asiaa viimepäivinä spekuloinut!

photo-1451732401917-66d80311800f

Kaksi yleisintä syytä miksi hyvät yritykset tekevät huonoja tuotteita

Olen monta kertaa ollut ihmeissäni kuinka isoista ja menestyvistä yrityksistä voi tulla niin huonoja tuotteita. Korporaatioissahan on usein tuhansia fiksuja ja kokeneita ihmisiä töissä. Eihän heillä pitäisi olla mitään motiivia tuottaa sekundakamaa.

Pohtiessani tätä dilemmaa olen tullut siihen tulokseen, että hyvän yrityksen huono tuote yleensä johtuu jommasta kummasta tai molemmista alla mainituista syistä.

1) Puutteellinen ymmärrys asiakkaan ongelmasta ja tilanteesta

Jos muotoilen kysymyksen hieman uusiksi voisin kysyä miksi fiksut ihmiset tekevät huonoja tuotteita. Vastaus on, että he yrittävät tuotteillaan joko a) ratkaista väärän ongelman tai b) ratkaista ongelman asiakkaan kannalta sopimattomalla tavalla.

Ratkaisu molempiin ongelmiin on, että tuotteiden suunnittelijat ja kehittäjät puhuvat enemmän asiakkaiden kanssa. Sen lisäksi heidän kannattaa testata tuotteitaan vaihe vaiheelta prototyypistä alkaen asiakkaillaan.

Varsinkin isoissa organisaatiossa on tavallista löytää tuotekehittäjiä, jotka eivät ole koskaan tavanneet ihka elävää asiakasta. Ja jos ovatkin, edelliskerrasta on aikaa, eikä seuraavaa kohtaamista ole tiedossa.

Puutteellinen ymmärrys asiakkaan ongelmasta tai tilanteesta ei kuitenkaan aina ole (ainoa) syy.

2) Väärin tehty tai täysin laiminlyöty sisäinen myynti

Käänsin yllä blogin otsikon muotoon: miksi fiksut ihmiset tekevät huonoja tuotteita. Jatkan samalla linjalla. Jos he ovat ymmärtäneet asiakkaan ongelman ja tilanteen oikein, syy löytyy yleensä korporaation poliittisesta luonteesta.

Asiakkaan tarpeen ja tilanteen puolustaminen on raakaa työtä. Kaikki organisaation työntekijät haluaisivat kehitettävän tuotteen ratkaisevan juuri heille päivänpolttavan ongelman. Kun sitten sisäisiä ristiriitoja ratkotaan tekemällä muutoksia hyvään tuotteeseen, on helppo arvata onko siitä asiakkaalle hyötyä vai ei. No ei tietenkään ole.

Usein tuotekehittäjät ovat laiminlyöneet sisäisen myyntityön ja sen takia joutuneet tekemään kompromisseja ja rakentamaan tuotteen, joka ei ole asiakkaan kannalta paras mahdollinen.

Sisäisessä myyntityössä asiakkaiden kanssa käydyt keskustelut ovat kovaa valuuttaa. Jos tuotekehittäjä osaa perustella kantansa ja päätöksensä asiakkaiden sanoihin nojaten, niitä on vaikeampi kumota ihan vain vastaväittäjän aseman tai argumentaatiokyvyn voimin.

Yhteenveto

Hyvä tuote ei synny niin, että fiksut ihmiset suunnittelevat parhaan ratkaisun ja toteuttavat sen. Hyvä tuote syntyy niin, että ymmärretään asiakkaan ongelma, ymmärretään asiakkaan tilanne ja suunnitellaan sen perusteella paras ratkaisu. Ratkaisua pitää lisäksi testata asiakkailla koko kehityskaaren läpi ja tehdä tarvittava työ puolustaakseen tuotetta ja asiakasta organisaation sisäiseltä paineelta.

photo-1457427062431-fbf106908649

Vauhtia tuotekehitykseen: näin muutat monimutkaiset toiveet yksinkertaisiksi tuoteominaisuuksiksi

Tekniset ja digitaaliset tuotteet ovat usein monimutkaisia vekottimia. Mitä fiksummat insinöörit niitä suunnittelevat, sitä monimutkaisempia ratkaisut ovat.

Monimutkaisuus johtaa tuotteeseen, joka on kallis rakentaa ja vaikea käyttää. Kumpikaan ei ole hyvä asia, sillä kalliit tuotteet jäävät helposti rakentamatta ja vaikeat tuotteet käyttämättä.

Jokainen tuotteiden kanssa työskennellyt on törmännyt monimutkaisuuden kiroon. Toivelista uusista ominaisuuksista on nälkävuoden mittainen, mutta mitään ei saada toteutettua, koska jokainen toive vaatisi niin järkyttävästi työtä. Niitä ei yksinkertaisesti kannata tai ehdi tekemään.

Tiedon kirous yhdistettynä perfektionismiin on lamauttava yhdistelmä

Tuotekehittäjän saappaissa ongelmana on tiedon kirous. Tiedämme tuotteesta ja asiakkaan ongelmasta liikaa. Fiksut ja kunnianhimoiset ihmiset haluavat tehdä parhaan mahdollisen ratkaisun. Siksi suunnitellaan kuinka homma voisi toimia optimaalisella tavalla myös poikkeuksellisissa oloissa.

Olenko nyt ehdottamassa, että meidän pitäisi tehdä huonoja ratkaisuja? En suinkaan.

Olen ehdottamassa, että meidän pitäisi tehdä sellaisia ratkaisuja, joilla tuotamme asiakkaillemme enemmän hyötyä kuin mitä he saavat nyt. Se onnistuu yleensä paremmin, jos teemme jotakin yksinkertaista (eli halpaa) sen sijaan, että teemme jotakin monimutkaista (eli kallista).

Kirjoitin aikaisemmin kuinka koodari mahdollisti myyntimiehelle hyvän kaupan mitoittamalla ratkaisunsa asiakkaan kokeman arvon mukaan. Tämä on yksi esimerkki kuinka saman ongelman voi ratkaista joko yksinkertaisesti (eli halvalla) tai monimutkaisesti (eli kalliilla).

Monimutkaisuus hiipii tuotteeseen vaivihkaa

Monimutkaisuuden pirullisuus piilee sen kyvyssä hivuttautua osaksi tuotteita vaivihkaa. Asiakas haluaa saada ohjelmistolla piirrettyä hieman erilaisen pallon, joten siihen lisätään uusi valinta pallonpiirtämistoimintoon. Sama toistuu vuosien varrella kahdeksan kertaa, jonka jälkeen nämä pienet tuunaukset ovat tuottaneet markkinoiden monimutkaisimman tavan piirtää palloja.

Monimutkaisuutta lisäävät ratkaisut ovat yleensä helppoja ja nopeita toteuttaa. Laitetaan tähän jotakin lisää ja ongelma ratkeaa sillä.

Yksinkertaiset ratkaisut ovat puolestaan vaikeita. Meidän pitää miettiä miten pallon piirtämiseen toimivaa ominaisuutta voi lähtökohtaisesti käyttää eriväristen, erimuotoisten ja eri logiikalla toimivien pallojen piirtämiseen ilman, että niitä joutuu erikseen ruksimaan käyttöön tai pois. Tällainen ajatustyö on raskasta ja turhauttavaa.

”Entä jos” auttaa löytämään yksinkertaisen ratkaisun

Yksi suosikkimenetelmistäni yksinkertaisempien ratkaisujen löytämiseen on ”entä jos” -ajattelu. Tarkastellaan sitä muutaman yksinkertaisen esimerkin avulla.

Koko arkkitehtuuri pitää uudistaa.
Entä jos meillä on vain kuukausi aikaa korjata kaikista isoin ongelma?

Nosturin pitää yltää metriä korkeammalle.
Entä jos emme saa koskea nosturiin, mutta voimme muokata ympäristöä?

Asiakkaan bisnekset ovat aivan sekaisin, mikäli tavaroiden lähetystä ei saada automatisoitua.
Entä jos automaatio koskee pelkkää verkkokauppaa?

Tämä vekotin pitää voida ladata nopeammin.
Entä jos ratkaisussa ei muuttaa laturia lainkaan?

Sait varmasti kiinni ajatuksesta.

Tämän keinon tarkoituksena on saada ihmiset tuottamaan vaihtoehtoisia ratkaisuja tilanteeseen keksimällä erilaisia teennäisiä rajoituksia. Rajoituksen pitää olla sellainen, että se estää alkuperäisen, monimutkaisen ratkaisutavan.

Toimivia rajoituksia ovat mm.

  • Käytössä oleva aika
  • Käytössä oleva porukka (tai raha)
  • Käyttötilanne
  • Ratkaistavan ongelman rajaaminen
  • Tietyn tuotteen osan eristäminen pois ratkaisun piiristä

Rajoitukset luovat turvallisen ympäristön käydä ajatusleikkiä vaihtoehtoisista ratkaisuista. Niiden vuoksi ratkaisun ei tarvitse olla täydellinen. Kaikki tietävät, että rajoitusten vallitsessa haetaan parasta mahdollista ratkaisua poislukien se kaikista hienostunein versio. Lopputuloksena saa yleensä helposti ja edukkaasti toteutettavan vaihtoehtoisversion

Kysy kysymyksiä

Kolme kysymystä, jotka tuoteasiantuntijan kannattaa kysyä asiakkaalta

Omasta erityisasiantuntemuksesta on kiva luennoida. Se on turvallista. Se on palkitsevaa. Varsinkin, kun briljeeraukset tekevät asiakkaaseen vaikutuksen. Silloin tuntee olevansa tutulla maaperällä. Sillä kuuluisalla mukavuusalueella.

Tämä on kuitenkin huono tapa. Tiedätkö miksi? Koska silloin kun sinä puhut, kyse on sinusta. Silloin kun asiakas puhuu, kyse on hänestä. Paras tapa kääntää keskustelu sinusta ja asiantuntemuksestasi asiakkaaseen ja hänen tavoitteisiinsa on kysymällä asiakkaalta kysymyksiä.

Ennen kuin voimme asiantuntijoina auttaa asiakkaita ratkomaan heille tärkeitä ongelmia, meidän täytyy kääntää keskustelu itsestämme asiakkaaseen ja ymmärtää mitä hän oikeastaan haluaa saavuttaa. Vasta sen jälkeen voimme valjastaa asiantuntemuksemme asiakkaan avuksi.

Tässä kirjoituksessa kerron mitkä ovat kokemukseni mukaan kolme voimakkainta kysymystä, jotka asiantuntija, tuotepäällikkö tai tuotekehittäjä voi asiakkaaltaan kysyä.

Kysymys 1: Mitä haluat saada aikaiseksi?

Meitä kaikkia ajaa eteenpäin kaksi voimaa. Halu saada jotakin, mitä meillä ei nyt ole tai halu poistaa joku ongelma, joka meillä nyt on. Herätyssaarnaaja puhuisi kiimasta ja pelosta.

Vielä tärkeämpää on, että meillä on yleensä yksi tai muutama tavoite, jotka pyörivät mielessämme merkittävästi muita enemmän. Se tavoite on meille prioriteetti ja olemme valmiita näkemään sen eteen vaivaa.

Kysymällä asiakkaalta mitä hän oikeastaan haluaa saada aikaiseksi varmistamme, että autamme asiakasta saavuttamaan jonkin tärkeän ja merkittävän tavoitteen.

Tottakai meillä kaikilla on työpöytä täynnä sellaisia asioita, jotka olisi ihan kiva saada hoidettua. Mutta niillä ei loppujen lopuksi ole suurta merkitystä. Jos meidän varsinainen tavoitteemme vaatii sitä, olemme valmiita luopumaan näistä ”ihan kiva” -kategorian jutuista hetkessä.

Sekä asiantuntijan että asiakkaan kannalta on siis paljon hedelmällisempää keskittyä johonkin oikeasti akuuttiin tavoitteeseen. Siihen voi käyttää aikaa, rahaa, hikeä, verta ja kyyneleitä. Sen saavuttaminen muuttaa asioita.

Oikean tavoitteen löytäminen on vasta keskustelunavaus. Seuraavaksi katsotaan sitä mielestäni kaikkein tärkeintä kysymystä.

Kysymys 2: Mikä on tämän asian suhteen sinulle tärkeää?

Keskustelimme kollegani kanssa tästä nimenomaisesta kysymyksestä. Ikään kuin demonstraationa valitsin ensimmäisenä silmään pistäneen esineen, eli kahvikupin.

”Mikä sinulle on tärkeää kahvikuppeja koskien?” kysyin kollegaltani. Enkä olisi koskaan arvannut vastausta. ”Todella hyvä, että kysyit” hän sanoi ja jatkoi ”olen nimittäin kovin vaativa mitä tulee kahvikuppeihin”. Sitten kollegani kertoi, miten kahvikupin hänen mielestään tulee ehdottomasti olla rakenteeltaan ohut ja malliltaan korkea. Perusteellisten perustelujen jälkeen hän summasi ”joten nyt tiedät miksi nämä firman kahvikupit ovat minun makuuni ihan vääränlaisia”.

Yhdellä yksinkertaisella kysymyksellä sain kuulla perinpohjaisen selonteon kollegani mieltymyksistä koskien niinkin banaalia ja arkipäiväistä esinettä kuin kahvikuppia. Voit varmasti kuvitella millaisen tietomäärän olisin kohdannut, jos keskustelun aiheena olisi ollut hänen pääasiallinen huolensa, jonka ratkaisemiseen hän käytti suurimman osan hereilläoloajastaan.

Olen itse asiakkaan roolissa monta kertaa toivonut, että asiantuntijat kysyisivät tämän kysymyksen minulta. Törmäsin esimerkiksi markkinointijohtajan roolissa useamman kerran oletuksiin, että markkinointijohtajat haluavat näkyvyyttä tai brändiarvoa. No minäpä halusin liidejä ja tilauksia.

Asiantuntijoiden tekemät oletukset minun arvoistani ja prioriteeteistani tekivät monista keskusteluista tuskallisia. Yritin kääntää keskusteluja parhaani mukaan oikeille raiteille, usein onnistumatta. Olen vakuuttunut, että asiantuntijat olivat yhtä lailla turhautuneita ja miettivät ”miksei tuo pässi nyt tajua”.

Jos asiantuntija olisi keskustelun lomassa kysynyt mitä minä pidän tärkeänä, hän olisi saanut käteensä avaimet auttaa minua sellaisella tavalla, jolla halusin. Olisimme päätyneet tilanteeseen, jossa minä olisin saanut kaipaamani apua ja asiantuntija olisi saanut ratkaistua ongelmani.

Otetaan toinen esimerkki. Keskustelin videontuotannon asiantuntijan kanssa. Minulla oli kiire saada video tehtyä, enkä ehtisi käyttää videon tekoon käytännössä lainkaan omaa aikaani. Silti asiantuntija kertoi minulle vuolaasti kuinka voin säästää rahaa käyttämällä omaa aikaani videon valmisteluun.

Kyseinen filminiekka varmasti tarkoitti hyvää. Hän itse olisi minun asemassani varmasti halunnut mieluummin käyttää hieman omaa aikaa ja säästää rahaa. Hänhän tiesi mistä on kyse ja osasi homman. Minä en, siksi etsin ulkopuolista apua ongelman ratkaisemiseen.

Mietitään esimerkkiä vielä kerran. Jos minä olen valmis käyttämään rahaa, jotta saan jotakin täysin valmista nopeasti, niin hyötyykö kukaan siitä, että asiantuntija kertoo minulle kuinka voin säästää jotakin mitä minulla jo on, jos käytän jotakin, mitä minulla ei ole? Ei varmasti.

Kysymys 3: Mitkä ovat vaihtoehtosi?

Haluan itse tietää millaisia vaihtoehtoja asiakas on omillaan tunnistanut ongelmansa ratkaisemiseksi tai tavoitteensa täyttämiseksi. Hänen muut vaihtoehtonsa kertovat minulle yleensä miten paljon aikaa ja vaivaa asiakas on käyttänyt ongelmansa pähkimiseen ja mihin suuntaan tämä ajatustyö on häntä vienyt.

Vaihtoehtojen avulla asiantuntija voi:

  • Kertoa asiakkaalle millaisen vaihtoehdon hän on mahdollisesti jättänyt huomioimatta
  • Auttaa asiakasta hahmottamaan miten vaihtoehdot toimivat suhteessa siihen, mitä asiakas on kertonut pitävänsä tärkeänä (kysymys 2)
  • Kertoa miten hänen oma asiantuntemuksensa suhteutuu asiakkaan muihin vaihtoehtoihin

Palataan aikaisempaan esimerkkiini videoista. Jos olisin kertonut asiantuntijalle, että minulle on tärkeää saada video nopeasti ja pienellä omalla aikapanostuksella, hän osaisi kertoa minulle, että olen epärealistinen, jos olisin sanonut pitäväni itse tehtyä klippiä vaihtoehtona.

Usein yhtenä vaihtoehtona on olla tekemättä mitään. Eli tyytyä nykytilaan ja elää ongelman kanssa. Ihan hyvinhän se on tähänkin mennessä onnistunut.

Vaihtoehtojen puimisen lopputuloksena asiantuntija osaa yleensä arvioida tuleeko koko hommasta mitään. Eli onko asiakas oikeasti sitoutunut ongelman ratkaisemiseen ja jos on, niin mikä hänen vaihtoehdoistaan on hänelle lopulta paras.

Mitä seuraavaksi? Kokeile!

Suosittelen seuraavaksi kokeilemaan näiden kolmen kysymyksen voimia. Testaamiseen tarvitset asiakkaan. Ellei sellaista ole käden ulottuvilla, voit kuivaharjoitella työkaverin kanssa.

Muista, että ihmiset ovat hurjan herkkiä aistimaan kuinka suhtaudut heihin. Jos siis kysyt kysymyksiä mekaanisesti olematta oikeasti kiinnostunut asiakkaan vastauksista, tulevat vastaukset olemaan kuivia ja hyödyttömiä.

Ota lähtöoletukseksi, että juuri tällä asiakkaalla on ratkaistavanaan aivan hurjan kiinnostava ja tärkeä ongelma. Mutta se ei ole ilmeinen, vaan sinun tehtäväsi on tunnistaa ongelman kiinnostavuus ja tärkeys. Kaivaa se esiin ja innostua siitä.

Kokeile nopeasti, epäonnistu nopeasti: case tavanmuodostuspalvelu

Saarnaan töissä päivät pääksytysten kuinka kehittämisessä pitää pystyä kokeilemaan uusia ideoita nopeasti ja oppimaan näistä kokeiluista. Nyt päätin maistaa töiden ulkopuolella omaa lääkettäni.

Tässä on case-esimerkki minun tavastani tehdä nopea prototyyppi, jonka tarkoituksena on oppia ja validoida toimiiko innostusta herättänyt idea todellisuudessa. Ensimmäisen kokeilun pohjalta päädyin siihen, että idea toimi paremmin kuin sen käytännön toteutus.

Pidemmittä puheitta, itse tarinaan.

***

Case: toiveesta tavaksi tieteellisin menetelmin

Minulla on tapana kuunnella autossa äänikirjoja. Kuuntelin taannoin Baumeisterin ja Tierneyn kirjaa Willpower, jossa herrat kertoivat kuinka ihmiset onnistuvat tahdonvoimaa vaativissa tehtävissä. Monet heidän vinkeistään olivat lopulta hyvin yksinkertaisia. Hankalaa asiaa vauhdittivat mm. muistuttaminen siitä miksi alun perin lähti koko leikkiin, sosiaalinen edesvastuu, menettämisen pelko jne.

Kurvatessani työpaikan autotalliin kysyn itseltäni, voisiko nämä periaatteessa melko yksinkertaiset keinot paketoida helpoksi palvelupaketiksi. Vastaus oli yksinkertainen: se selviää vain kokeilemalla.

Askel 1: Validoi onko idealle lainkaan kysyntää

Ensimmäinen askel idean kuin idean validoimiselle on varmistaa, että ihmisiä kiinnostaa. Jos kukaan ei välitä ideastani, säästän paljon turhaa työtä, kun en rakenna palvelua nollalle käyttäjälle. Siispä rustaamaan myyntipuhetta.

Kokeilijoiden rekrytointi oli tällä kertaa helpompaa verrattuna edelliseen (hieman pitkäaikaisempaan ja kaupallisempaan) kokeiluuni kuukausimaksullisesta kahvipalvelusta nimeltä Paahteinen Papu. Kun käynnistelin kahvipalvelua, tein valmiiksi nettisivut tilauslomakkeineen päivineen. Sitten jaoin linkkiä Facebookissa ja odotin ihmeissäni, kun tilauksia ei tullutkaan, ennen kuin aloin käymään kahdenvälisiä keskusteluja tunnettujen kahvinystävien kanssa. Nettisivut ja tilauslomake osoittautuivat siis alkuvaiheessa täysin turhiksi.

Tällä kertaa ratkaisevat erot olivat mielestäni seuraavat:

  • En kuvannut liian tarkkaan Facebook-julkaisussa mistä on kyse. Keskityin enemmän siihen, mitä palvelulla voi tehdä ja kehotin kertomaan (sitoumuksetta) mielenkiinnosta.
  • Kun joku ilmoitti kiinnostuksestaan, ilmoitin heille kuinka palvelu tarkalleen ottaen toimii ja pyysin sen jälkeen vahvistuksen pilottiin liittymisestä.
  • Tapa vaati aiempaan verrattuna paljon vähemmän ajattelemista ja paljon pienempää sitoutumista. Sen kun kirjoittaa yhden FB-kommentin, niin on mukana ”myyntiputkessa”. Loput hoitui keskustelun kautta.

Kuvakaappaus koekäyttäjien rekryilmoituksesta näkyy alla.

Koekäyttäjien rekrytointi-ilmoitus
Koekäyttäjien rekrytointi-ilmoitus

Kymmenen koekäyttäjän rekrytointi kesti pari tuntia. Useampikin olisi ollut tarjolla, mutta päätin aloittaa kymmenellä. Lisätietoja saaneista kaksi tippui matkan varrella pois, koska he eivät kokeneet kuuluvansa kohderyhmään. Lisätietoviestini löytyy alta.

Lisätietoviesti kiinnostuneille
Lisätietoviesti kiinnostuneille

Illan pimetessä tajusin, että nythän itse palvelua pitää ryhtyä kasaamaan, jotta koekäyttäjillä on jotakin, jota koekäyttää.

Askel 2: Validoi voiko palvelun edes toteuttaa

Kun mielenkiinto oli validoitu, piti seuraavaksi validoida voiko palvelun edes toteuttaa. Totesin, että sitä varten oli helpointa tehdä palvelusta minimaalinen versio. Toteutuksen aikataulutin näin:

  • Liittymislomake ja tietokanta piti saada pystytettyä käytännössä heti, jotta koekäyttäjät eivät ehdi unohtaa mistä on kyse ja kaikota. Se piti siis saada pystyyn samana päivänä.
  • Ensimmäisen muistutusmailin tarvitsi lähteä vasta liittymistä seuraavana päivänä. Tämän toiminnon toteuttaminen sai siis suosiolla jäädä seuraavaan päivään. Kukaan ei kaipaisi sitä heti kuitenkaan.
  • Muistutusmailien lähettämisen jälkeen piti varmistaa, että soittajilla oli soittolista. Eli piti pystyttää jotakin, josta call center näkee kenelle pitäisi soittaa ja millaisen tavoitteen kyseinen henkilö on jättänyt tekemättä. Onneksi ensimmäinen stiplu tuli vasta toisena päivänä, joten sain ylimääräisen päivän viimeisen osan rakentamiseen.

Näillä toimenpiteillä sain minimaalisen version palvelusta pyörimään. Koodi ei ollut kaunista ja bugeja löytyi toivottua enemmän. Samalla sain herätyksen siihen, kuinka oma ohjelmointityylini on jäänyt ajasta jälkeen. Mutta tarpeeksi paljon softaa syntyi, jotta palvelu pyöri. Sain siis validoitua, että palvelun pystyy rakentamaan. Ja testi eteni toiseen vaiheeseen.

Koekäyttöhalukkaiksi ilmoittautuneista vain yksi jätti aloituksen tekemättä, eli 9/10 sai palvelun itsenäisesti käyntiin.

Askel 3: Validoi  ajaako palvelu asiansa periaatteellisella tasolla

Sain heti tuoreeltaan pari palautetta ja muutaman bugiraportin koekäytön käynnistyttyä. Niiden jälkeen en jututtanut käyttäjiä hetkeen, vaan annoin pilotin rullata sellaisenaan.

Pilotin lähestyessä loppuaan aloin viestitellä ja soitella koekäyttäjille. Ensimmäinen palaute oli todella positiivinen ja ilahduin siitä. Sen jälkeen alkoi alamäki, eli palautteet kääntyivät reilusti skeptisemmäksi.

Olin tietysti pettynyt heikkoihin tuloksiin, koska olin tyypilliseen tapaan rakastunut omaan ideaani. Ensimmäisten kriittisten palautteiden jälkeen keskustelut tuntuivat jo helpommilta, koska olin saanut jalat takaisin maan kamaralle. Palautekeskusteluissa tuli paljon ideoita ja ajatuksia. Yksi käyttäjä kaipasi todistamisen pakkoa (esim. lataa kuva itsestäsi lenkillä), toinen positiivisempaa sävyä koko palveluun (”nyt meni negatiivisen kautta”) ja kolmas kannustavia tilastoja. Myös puhelujen osalta odotukset olivat olleet valmentavammassa otteessa.

Pilotin lopputulos oli, ettei idea ollut sellaisenaan riittävä. Siitä puuttuu jotakin. Nyt mietin millainen testi numero kaksi tulee olemaan. Toivottavasti kohta pääsen pohtimaan versiota kolme. Sitä odotellessa käteen on jo jäänyt aimo annos uutta tietoa ja hauska kokeilu.

Lopuksi

Halusin jakaa tämän tarinan esimerkkinä siitä, että tuote- tai palveluidean pilotointi voi olla hyvinkin helppoa ja nopeaa. Ensin testataan kiinnostus esim. Facebookissa. Sitten yksinkertainen versio pyörimään. Ja lopuksi analysoidaan palautteet.

Jos nyt pudistelet päätäsi ja mietit, että ”helppohan sinun on sanoa, kun itse pystyit koodaamaan tuon kasaan”, niin haluan esittää protestiäänen. Suunnittelin myös vaihtoehtoisen version toteutuksesta, jossa koko homma olisi pyörinyt Google Sheetsin ja Mailchimpin avulla. Silloin aikaa olisi mennyt suurin piirtein saman verran, mutta koodaamisen sijaan aika olisi kulunut tietojen manuaaliseen copy-pasteen. Mutta aikaa ja rahaa olisi kulunut juuri yhtä vähän.

Toimikoon tämä siis haastena sinulle, rakas blogini lukija. Kun seuraavan kerran saat idean mainiosta palvelusta, niin älä tyydy raapustelemaan paperille, vaan rakenna siitä jonkinlainen minimaalinen testi. Joko päädyt siihen, ettei idea ollutkaan ihan niin mahtava kuin miltä tuntui. Tai sitten päädyt siihen, että palvelu on pakko rakentaa loppuun asti, kun kerran käyttäjät ovat niin innoissaan jo hyvin ra’asta versiosta. Kävi kuinka vain, olet varmasti tyytyväinen siihen, että tuli kokeiltua.

  • 1
  • 2