Marty Cagan kertoo meille, miten tehdä hieno tuote. Blogin ensimmäisen kirjatsekkauksen aika!




Olen ollut jo hetken innoissani tuoteomistajuudesta, joten päätin etsiä huvin ja hyödyn nimissä pari kirjaa aiheesta luettavaksi. Aiemmin luin jo kirjan Getting Real, joka päätyi vielä Ammattitavauksen puolelle. Nyt vuorossa oli hyvien arvosteluiden vuoksi luettavaksi valikoitunut Inspired: How to Create Products Customers Love.


Marty Cagan on pitkän linjan tuotekaveri ja tehnyt näyttävän uran esim. HP:lla, Ebaylla ja nyt konsulttina, mutta niinhän nämä kaikki, joten ei ehkä sen pidempiä esittelyitä aiheesta. Kirjassa näkökulma on vahvasti liiketoimintatasolla, josta erityisesti pidin. Tuotepäällikön (Product Manager) roolia käsitellään yrityksen/organisaation toiminnan kannalta keskeisenä ja mielenkiintoisena tekijänä ja keskitytään paljon siihen, miten onnistuneet tuotteet ovat liiketoiminnan kannalta erityisen tärkeitä. Kuitenkin mukana on erityisen paljon niksiä ja vinkkiä myös varsinaisen tuotteen rakentamista ja suunnittelua varten, eikä homma mene pelkäksi visioinniksi ja get a seat at the table -hehkutukseksi.

Caganin suhtautuminen ketteriin ohjelmistokehitysmenetelmiin oli jonkin verran epäilevä, joka on mielenkiintoista. Olen ehkä nyt viettänyt liikaa aikaa Scrum-kavereiden kanssa, kun suhtaudun nykyään vesiputoustyyppisiin työtapoihin lähinnä jonain vitsinä, jota vanhoita huonoista ajoista kerrotaan. Taidan kuitenkin elää tämänkin asian suhteen taas jossain ketteryyden lintukodossa, koska eri kehittäjien, tuotepäälliköiden yms. kanssa jutellessa kuulee meiningin muualla olevan usein sellaista "Me sanotaan tekevämme Scrumilla, mutta eihän se sitä oikeasti ole." -tasoa.

Kirjan ehkä vahvin ja voimakkaimmin esitetty suositus on tehdä tuotteista aina prototyyppi. Oikea prototyyppi, jolla pystyy näkemään miten tuote varsinaisesti toimisi. Pelkkä paperille piirrelty kuva tai yhdeksän mappia vaatimysmäärittelyjä ei kelpaa. Caganin mukaan prototyypin rakentamiseen käytetty aika maksaa itsensä käytännössä aina takaisin. Joko prototyypistä jo näkee, että tuote ei ole hyvä, eikä kiinnosta asiakkaita. Tämän jälkeen projekti on nopea kuopata, ennen kuin sitä on visioitu paperilla, päätetty idean olevan loistava ja elinkelvottomuus todetaan vasta kuukausien rakentamisen jälkeen. Toisaalta jos tuote on hyvä, prototyyppi on koodareille paras mahdollinen ohje tuotteen rakentamisesta. 100-sivuisen vaatimusmäärittelydokumentin laatiminen vie käytännössä yhtä paljon aikaa kuin prototyypin rakentaminen. Lisäksi 100-sivuinen pökäle on vieläpä kaikkien oikeasti tuotetta rakentavien näkökulmasta lähes täysin hyödytön tai vähintäänkin mielettömän raskas hyödynnettävä, verrattuna prototyyppiin, josta jo silmäyksellä näkee, mikä tuotteen idea on.

Tämä voisi olla se yksi innostava idea, jonka tästä kirjasta koittaa jättää takataskuun. Prototyypin lobbaaminen ja vaatiminen aina ensimmäisessä vaiheessa. Caganin perustelut vakuuttivat tämän suhteen ainakin minut. Kaikin puolin uskoisin prototyypin rakentamisen toteuttavan hyvää bisnesjärkeä, vaikka käytännön tilanteessa toki voi olla vaatia tiettyä suostuttelua tuoteomistajalta.

Caganin kirja muutenkin korostaa tuoteomistajan roolia vähän sellaisena suurena taiteilijana, jolla on vahva visio. Ideoiden ei mitenkään tarvitse olla omia, mutta näkemystä ja määrätietoisuutta on löydyttävä. Kirjassa onkin mukana ohjeita, miten esimerkiksi isossa organisaatiossa saa toteutettua hienoja ideoita byrokratiasta huolimatta.

Vakuuttava perusteos kokonaisuudessaan. Ei aivan yhtä inspiroiva kuin puhtaan inspiroivaksi pamfletiksi laadittu Getting Real. Tämän ansiosta kuitenkin myös syvällisempi esitys hyvän tuotteen tekemisestä. Vahva suositus.

Tärpit

NPS - Net Promoter Score

Hyvä tapa mitata tuottee elinkelpoisuutta. Käytännössä käyttäjiltä kysytään, kuinka valmiit he olisivat suosittelemaan tuotetta ystävilleen, yhteistyökumppaneilleen, yms. Hyvä mittari siinä, että NPS:n optimointi on kestävä tapa kehittää tuotetta. Pelkkä kävijämäärien tai lyhytaikaisen tuoton optimointi voi olla myrkkyä NPS:lle, joka kertoo paremmin siitä, miten tyytyväisiä tuotteen nykyiset käyttäjät ovat ja miten tuotteen käyttäjämäärä todennäköisesti kehittyy tulevaisuudessa.

Asiakkaat eivät tiedä mitä haluavat

Tuoteomistajana ei pidä erehtyä tekemään asiakkaille sitä, mitä he haluavat (vrt. Henry Ford ja nopeammat hevoset). Asiakkailla on mielenkiintoisia ongelmia, mutta he harvoin pystyvät suoraan kertomaan nerokkainta mahdollista tapaa ratkaista näitä ongelmia. Ratkaisut ovat tuotteen tekijöiden keksittävä.

Anna ihmisten ratkaista ongelmat

Vaikka asiakkaat eivät saa ratkaista ongelmia, ei sitä pidä tehdä myöskään tuoteomistajan. Tavoitteiden ja reunaehtojen asettaminen yleensä riittää. Koodari tai käyttöliittymäsuunnittelija tietää yleensä tavallista projaria paremmin, miten homma kannattaa toteuttaa tai minne se nappula laittaa. "Anna ihmisten tehdä hyvää työtä." pätee tuotteidenkin kehittämisessä.

Tuotteen perusperiaatteet / Product Principles

Tuotteen suunnittelussa perusarvojen kehittäminen ja muistaminen on tärkeätä. Kehittämistyöstä tulee nopeasti tempoilevaa ja satunnaista, jos taustalla oleva ajatus ei ole kirkas ja sanallistettu. Hyvin helppo asia jättää tekemättä, mutta näiden peruslähtökohtien kirjoittaminen näkyvästi johonkin selville ei varmasti olisi huono idea minkään tuotteen kohdalla.