Tuotekehitys, tuotteistus, tuotanto, tuotemarkkinointi, mitänäitänyton

Osma Ahvenlampi
Jun 15 · 3 min read

Pieni linjan vaihdos tässä hiljaiseloa viettäneessä blogissa. Olen aiemmin kirjoittanut tänne vain englanniksi, mutta tämän päivän aiheesta on parempi kirjoittaa suomeksi, sillä siihen liittyy myös suomenkielinen terminologia.

On nimittäin niin, että valitettavan harva suomalaisessa liike-elämässä vieläkään ymmärtää, mitä tarkoittavat termit, missä esiintyvät sanat “tuote” ja “kehitys”, joko yhdessä tai erikseen. Noin vuosi sitten aktiivinen keskustelu kollegoiden parissa aiheesta johti myös tähän haastatteluun, missä pääsimme hieman avaamaan taustoja siitä, miksi tuotejohtaminen on ollut hieman lapsipuolen asemassa suomalaisissa yrityksissä. Kehitystä on tapahtunut — mutta se ei tarkoita, että olisimme läheskään valmiita. Lienee siis paikallaan aloittaa ihan perusasioista, joista tässä kirjoituksessa muutamia.

Itse tunnen lähinnä ohjelmistoalan tuotekehityksen, sillä sen parissa olen urani tehnyt, vaikkakin monella eri liiketoimintasektorilla online-peleistä liikenteeseen ja terveysteknologiaan, energiasta retail-pankkitoimintaan ja sijoittajaviestintään. Tuotteissa on alasta riippumatta paljon yhteistä, mutta silläkin on merkitystä, valmistuuko tuote tehtaassa, tietokoneen sisällä vai ihmisten tekemänä käsityönä. Siksi käsittelenkin nyt vain ohjelmistopohjaisia tuotteita (ja palveluita), yhteismitallisuus muille alueille jääköön myöhempään käsittelyyn.

Yksi usein itselleni vastaan tuleva ajatus on, että tuote syntyy raapaisemalla firman kehittämästä hienosta teknologiasta kasaan appi. Sitähän ohjelmistotuotteet ovat, puhelimeen asennettuja appeja? Tuotekehittäjät tekevät appeja ja tuotesuunnittelu on sitä, että keksitään miten appiin sijoitetaan jonkinlainen sosiaalisen verkoston keskustelupalsta tai viraalisuositus-nappi. No ei ihan.

Toinen syvälle juurtunut mielikuva on, että tuotekehittäjät tekevät kaikki samoja asioita. Tai ainakin, että on olemassa vain koodaajia ja tuotepäälliköitä, ja siinä on ne roolit, mitä ohjelmistotuotteet tarvitsevat. Hutiin menee tämäkin. Mutta miten asiaa sitten kannattaisi tarkastella?

Lähdetään liikkeelle siitä teknologian ja tuotteen erosta. Stereotyypissä “suomalaisesta softafirmasta” joku propellipääjoukko on kehittänyt jonkun digitaalisen hilavitkuttimen, millä on jotain ehkä joskus ratkaistukin, mutta kukaan ei oikeastaan osaa sanoa, mihin ongelmaan se on soveltuva. Sama joukkue sitten väsää yhä monimutkaistuvia projekteja joissa tätä hilavitkutinta käännellään uusiin kulmiin asiakkaan ihmetellessä, mitä lopputuloksella tehdään. Tätä nyt ei kuitenkaan voi tuotteeksi kutsua.

Tuotteen määritelmähän on varsin yksinkertaisesti kuvattu: tuote on tarkoitettu

  1. jollekin kohderyhmälle
  2. jolla on ongelma tai tavoite
  3. mihin tuote tarjoaa ratkaisun
  4. selkeään hintaan

Projektit eivät ole tuotteita. Palvelut sen sijaan voivat hyvinkin olla — olkoon ne sitten ohjelmisto-automatisoituja, tai käsin tehtyjä, kunhan täyttävät edellä mainitsemani kriteerit.

Tuotteistus on sitä, että määritellään tuote tavalla, missä sen oletettu asiakaskuntakin ymmärtää, mistä tuotteessa on kysymys ja että se on heille tarkoitettu. Tuotteistus on erittäin tärkeätä. Usein sen olennaisin anti yritykselle itselleen on nimenomaan asiakaskunnan määrittely. Samassa yhteydessä toivottavasti tulee määriteltyä myös, ketkä eivät ole tuotteen asiakkaita, koska mikään tuote ei voi olla kaikkea kaikille. Tuotteistus siis tapahtuu tuotekehitysprosessin alussa, ei sen lopussa. Se tarjoaa myös pohjan tuotemarkkinoinnin toteutukselle, ja siksi myös tuotemarkkinoinnin suunnittelun ja toteutuksen voi aloittaa jo kauan ennen tuotteen myyntikuntoon valmistumista. Mutta siitä joskus myöhemmin.

Mutta mitä sitten on tuotekehitys? Se ei ole ohjelmistokehitystä. Eikä sen tuloksena ole “appi”. No, voi sellainenkin syntyä, mutta se on tyypillisesti väline tuotteen jakeluun tai osatuotos koko palvelupolussa. Tuotekehitys on jatkumoa tuotteistukselle. Olemme määritelleet asiakaskuntamme. Tiedämmekö vamasti, mikä heidän tarpeensa on? Muuttuuko tarve ajan myötä? Vastaako tarjontamme asiakkaidemme tarpeeseen? Millä muilla tavoin voisimme heille tuottaa hyötyä, tai asiakaskuntaamme laajentaa? Onko muita läheisiä asiakasryhmiä, joille voisimme kehittää tuotteen pohjautuen siihen osaamiseen, teknologiaan ja välineisiin, joita meille on kertynyt? Syntyykö usean tuotteen välille synergiahyötyjä vai syövätkö ne toistensa potentiaalia esimerkiksi liiallisesti fokustamme hajauttamalla? Miten saamme tunnistetut tarpeen parhaiten täytettyä ja miten hankimme siihen tarvittavan uuden osaamisen, teknologian ja välineet? Kannattaako kaikki tehdä sisäisesti vai yhteistyössä kumppaneiden kanssa? Lyhyesti, tuotekehitys on monialaista johtamista.

Tuotekehitys siis ei ole koodaamista — ohjelmistuotteiden kehitykseen toki liittyy koodaamistakin, mutta koodaamisen lisäksi pitää tehdä monia muitakin asioita, joista vain osan tuossa kysymyksissä esitin. Tänään monet alustaratkaisut ovat jo niin kehittyneitä, että ohjelmistotuotteitakin voi saada aikaan jopa koodaamatta lainkaan — vain jo valmiiksi tehtyjä palasia oikealla tavalla yhteen liittäen. Mikä on oikea kokonaisuus ja miten ne kannattaa yhteen liittää — siinä se “salaisuus” piilee.

Kolmas kohdalleni usein osunut virhepäätelmä on ollut, että (ohjelmisto) tuotekehitys olisi yhtäläistä (ohjelmisto) tuotannon kanssa. Varsinkaan tämä ei pidä paikkaansa. Toki näillä kahdella asialla on paljon keskinäisriippuvuuksia, koska huonosti suunniteltu tai toteutettu teknologia on myös vaikeasti tuotettavaa, mutta samasta asiasta ei silti ole kysymys. Ei autosuunnittelija ole kokoonpanolinjalla kuin tutustumassa käytäntöihin ja oppimassa, miten suunnittelulla voi kokoonpanoa tehostaa, eikä ohjelmistokehittäjistä valtaosa viihdy kovinkaan hyvin valvonta-, hälytys-, vikaselvitys- tai tukitehtävissä. Tutustumassa hänen kannattaa käydä, että ymmärtäisi, miten tuotantotyötä voi helpottaa ja laatua parantaa, mutta on aivan eri asiantuntemusta osata pitää järjestelmät häiriöttömästi käynnissä. Lisäksi sen vikatilanteen sattuessa, ja kaikille se joskus sattuu, voi unohtaa voivansa samanaikaisesti jatkaa uuden kehittämistä. Jos haluat sekä kehitysaikataulujen pysyvyyttä, että häiriötöntä tuotantoa, vähimmäislähtökohta on antaa asiantuntijoiden keskittyä omaan vahvaan alueeseensa ja ristiriidattomiin tavoitteisiinsa.

Tästä tuli jo pitkähkö kirjoitus. Jatketaan siitä tuotemarkkinoinnin erilaisuudesta, ja sen suhteesta tuotekehitykseen toisessa kirjoituksessa. Laitapa kommentteja joko täällä, Twitterissä tai LinkedInissä!

Metrify

Building products with data

Metrify

Every business should be transforming its data to information. Yours, too.

Osma Ahvenlampi

Written by

Agile business leader, growth and product lead for number of startups, founder at @Metrify.

Metrify

Every business should be transforming its data to information. Yours, too.