Tuotteen ja prosessin välinen kuilu: näin estät tämän vuodon organisaatiosi budjetissa

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Hannah Clark: Yksi ketterien organisaatioiden hienoista puolista on se, että kokeilemme ja opimme jatkuvasti parantaaksemme organisaatioitamme ja tarjoamiamme tuotteita. Jokainen teknologian läpimurto on jonkinlaisen kokeilun tulos, mutta tässä on asian kääntöpuoli: kokeilut eivät aina johda myönteisiin lopputuloksiin. Itse asiassa monet kokeilut ovat erittäin puutteellisia – ja kun kokeilun lopputuloksesta riippuu satojatuhansia dollareita, viimeinen asia, jonka haluamme, on tehdä päätöksiä virheellisen tiedon perusteella. Pelottavaa on se, että useimmiten emme edes huomaa tiedon olevan virheellistä ennen kuin on liian myöhäistä.

Vieraanani tänään on Effective Experimentsin perustaja Manuel Da Costa. Kuten organisaation nimestä voi päätellä, Manuel keskittyy ennen kaikkea auttamaan organisaatioita toteuttamaan parempia kokeiluja, mikä johtaa parempiin tuotejohtopäätöksiin. Oikeat työkalut voivat toki auttaa meitä parantamaan kokeiluja ja data-analyysiä, mutta hän on myös tunnistanut organisaatiokaavion reuna-alueilta alkunsa saavan ilmiön, jota kutsutaan tuotteen ja prosessin väliseksi kuiluksi – ja joka maksaa teknologiayrityksille huomaamatta miljoonia. Aloitetaan.

Tervetuloa takaisin CPO Club -podcastiin. Tänään seurassani on Manuel Da Costa.

Manuel, kiitos paljon, että liityit seuraamme.

Manuel Da Costa: Hei kaikille! Hannah, kiitos kutsusta.

Hannah Clark: Voisitko kertoa hieman taustastasi ja siitä, miten päädyit nykyiseen tilanteeseesi?

Manuel Da Costa: Toki. Olen Effective Experimentsin perustaja. Olemme yritys, joka tarjoaa ohjelmistoja auttaakseen yrityksiä tekemään yhteistyötä paremmin ja tekemään parempia tuoteratkaisuja. Taustani alkoi jo kauan sitten ketterän startup-toiminnan parissa, jossa opin tästä testaamisen ja oppimisen lähestymistavasta validointiin. Siirryin vähitellen konversio-optimoinnin maailmaan ja lopulta omaan tuotteeseeni, jossa autamme tuote- ja asiakaskokemustiimejä työskentelemään paremmin yhdessä.

Se tuo minut tähän urani vaiheeseen, jossa minun on kerrottava tämä tarina – juuri sitä vartenhan olemme täällä tässä podcastissa.

Hannah Clark: Odotan innolla, että pääsemme perehtymään siihen.

Keskitymme tänään ilmiöön, jota kutsut tuotteen ja prosessin väliseksi kuiluksi. Voisitko aloittaa kertomalla, mihin tällä viitataan ja millaiset olosuhteet liittyvät siihen?

Manuel Da Costa: Kyllä. McKinsey on hiljattain tehnyt tutkimusta, jossa tarkasteltiin hyvän ja huonon tuotteenhallinnan käytäntöjen välistä eroa. Kaikki palautuu johtajien odotuksiin siitä, miten tuotetyötä pitäisi toteuttaa, ja siihen, mitä käytännössä tapahtuu tuotepäälliköiden toteuttaessa sitä. Olemme havainneet tässä katkoksen. Annoin sille nimen tuotteen ja prosessin välinen kuilu, mutta pohjimmiltaan kyse on odotusten ja todellisuuden välisestä erosta.

Tähän on monia syitä, joihin perehdymme, mutta lopulta johto haluaa paremman tuotteen, eivätkä tuotepäälliköt ja tuoteomistajat pysty toimittamaan sitä. Syitä tähän on kokonainen joukko.

Hannah Clark: Mennään hieman syvemmälle. Sanoit, että tähän voi olla monia syitä. Millainen matka tai alku tämän kuilun syntymisellä on, ja miten siihen päädytään?

Manuel Da Costa: Tarkastellaan sitä, mitä tuotetiimeiltä nykyään pyydetään: niiden pitäisi validoida jokainen tekemänsä tuoteratkaisu. Kokeilusta on tullut väline, jonka avulla tuotetiimit voivat olennaisesti validoida hypoteesejaan ja sen, ovatko ne tuomassa markkinoille oikean tuotteen.

Monilla kokeiluja toteuttamaan määrätyillä tuotetiimeillä ei ole kokemusta tai osaamista siihen. Vaikka tietoa olisikin, se on usein vain pintapuolista tietoa kokeilujen toteuttamisesta. Tämän seurauksena päätöksiä tehdään kokeilujen avulla, mutta itse kokeilu voi olla virheellinen. Se ei ehkä ole riittävän perusteellinen. Lisäksi siihen liittyy muitakin tekijöitä.

Puhumme tiimien välisestä yhteistyöstä, tietoisuudesta siitä, mitä pitäisi tehdä, ja myös siitä, miten priorisoida tehokkaasti. Tuotetyössä on niin paljon keskenään ristiriitaisia prioriteetteja – erityisesti sen suhteen, mitä pitäisi tehdä – ja nyt mukaan on tullut myös kokeilu. On osattava priorisoida työjono tehokkaasti parhaan mahdollisen tuloksen saavuttamiseksi.

Nämä ovat joitakin käytännössä näkemiämme oireita: tuotetiimejä pyydetään toteuttamaan asioita ja myös sisällyttämään kokeilu osaksi käytäntöjään, mutta niille ei anneta siihen tarvittavaa tukea.

Hannah Clark: Mitä tästä yhtälöstä puuttuu? Kuulostaa siltä, että tuotepäälliköiden käyttäjätutkimukseen liittyvä osaaminen on tässä tilanteessa alikehittynyttä. Se johtaa ainakin ketjureaktiona virheellisiin tuloksiin. Mitkä mielestäsi ovat tärkeimmät syyt siihen, että tuotepäälliköt ovat valmistautumattomia?

Manuel Da Costa: Katsotaan, mihin kokeiluja ollaan tuomassa. Monissa organisaatioissa kokeiluja toteutti alun perin ensisijaisesti markkinointitiimi tai konversio-optimoinnin tiimi.

Ehkä kyse oli muutamasta ihmisestä tai pienestä osaamiskeskustiimistä. Vähitellen niitä on pyydetty siirtämään taitonsa tuotetiimeille, jotta nämä voisivat toteuttaa omia kokeilujaan itsenäisesti. Ensimmäinen haaste on tiedon puute. Organisaatioissa saatetaan järjestää koulutustyöpajoja tai ohjattuja sessioita, joissa näytetään, miten tämä tehdään.

Mutta siihen se jää. Tiimeille on annettu pääsy työkaluihin ja pintapuolista koulutusta, mutta ei resursseja, joiden avulla ne todella ymmärtäisivät, kehittyvätkö ne vai eivät. Siksi ne tuijottavat lukuja. Ne sanovat vain, että olemme toteuttaneet tietyn määrän kokeiluja, ja pitävät sitä tuloksena. Kukaan ei kuitenkaan valvo tai arvioi, toteutettiinko kokeilu oikein, suunniteltiinko se oikein ja analysoitiinko se oikein.

Tämän osaamisen kehittäminen vie itsessään melko paljon aikaa. Ajattele sitä lihaksena: sitä ei voi vain käyttää kerran ja olla sitten hyvä siinä. On tuotepäälliköitä, jotka toteuttavat hyviä kokeiluja, mutta ne voivat olla liian yksinkertaisia. He voivat toteuttaa monimutkaisia kokeiluja, mutta ne on ehkä instrumentoitukin väärin. Kun he sitten välittävät johdolle tietoa ja sanovat, mitä pitäisi tehdä seuraavaksi, se perustuu virheelliseen tietoon – tai saattaa perustua siihen – mutta he eivät tiedä sitä, koska valvontaa ei ole.

Tämä tuo minut seuraavaan kohtaan: valvonta puuttuu. Näille tiimeille annetaan usein tietty määrä luottamusta: toteuttakaa kokeilut, niin uskomme kaiken, minkä välitätte meille. Resurssien puutteen vuoksi kukaan ei käytä aikaa tulosten tarkistamiseen nähdäkseen, ovatko ne todella tarkkoja.

Johtuivatko tulokset hyvistä vai huonoista käytännöistä? Se on yksi tekijä. Toinen tekijä on johtotason puuttuminen. Kun puhun johtotasosta, en tarkoita tuoteomistajaa vaan tuoteliiketoiminnan varajohtajaa tai tuotejohtajaa. Heidän on pidettävä tiimit vastuullisina.

Heidän ei pidä vain vaatia vastuunkantoa, vaan myös antaa tiimeille liikkumavaraa käyttää aikaa tämän taidon harjoitteluun, parempien kokeilujen tekemiseen, parempien päätösten tekoon ja parempaan priorisointiin. Näiden kahden tekijän vuoksi odotusten ja todellisuuden välille muodostuu kuilu. Tuotepäälliköt ja tuoteasiantuntijat kamppailevat, koska heillä ei ole mahdollisuutta hidastaa ja panna näitä asioita kuntoon.

Osa vastuusta on siis johdolla, koska sen täytyy antaa tiimeille sekä tehtävä että riittävästi aikaa kehittyä tässä.

Hannah Clark: Miltä tämä näyttää käytännössä johtamisen näkökulmasta? Millä toimilla johtajat voivat estää tuotteen ja prosessin välisen kuilun syntymisen?

Manuel Da Costa: Ensimmäinen asia on oikeiden suorituskykymittareiden asettaminen. Näemme usein vääristyneitä kannustimia. Tarkoitan tällä esimerkiksi sitä, että tiimille sanotaan: teidän on julkaistava tietty määrä ominaisuuksia tämän vuosineljänneksen tai vuoden aikana, ja määrä on saavutettava.

Silloin kyseestä tulee määräpeli, ei laadusta. Voit julkaista monimutkaisen ominaisuuden tai useita yksinkertaisia ominaisuuksia, kunhan saavutat luvun. Tiimeille on asetettava oikeat mittarit, jotta ne saavat oikeanlaiset kannustimet eivätkä voi tehdä mitä tahansa saavuttaakseen tavoitteen ja päästäkseen pälkähästä.

Toinen asia on antaa tiimeille ja niitä valvoville ihmisille jälleen riittävästi aikaa valmentaa, seurata ja kehittää tuotetiimejä parempien päätösten tekemiseksi. Kuten sanoin, kukaan ei aloita osaamalla kokeilla oikein. Se vie aikaa, eikä asia voi päättyä yhteen koulutustyöpajaan.

Tiimejä on valmennettava ja ohjattava ajan mittaan. Ajan puute johtuu siitä, että niiden on saavutettava tietyt luvut. Koska niillä ei ole aikaa, ne eivät kehity. Tämä on noidankehä, joka jatkuu. Kaikki alkaa siitä, että johto sanoo haluavansa organisaation kehittyvän ja parempia tuoteratkaisuja.

Miten teemme parempia tuoteratkaisuja? Kokeilemalla ja validoimalla oletuksemme. Se on ensimmäinen askel. Tätä varten meidän on annettava tuotetiimeille valmiudet muodostaa ja testata näitä oletuksia. Annamme niille aikaa, annamme niille kapasiteettia, annamme niille valtuudet, mutta annamme myös turvallisen tilan olla väärässä. Kokeilun ydin on se, että voimme olla väärässä. Jos mittareiksi asetetaan määrä tai vaaditaan kokeiluilta tiettyä onnistumisprosenttia, ihmiset alkavat pelata järjestelmää saavuttaakseen luvun.

Kokeilussa on kyse siitä, että meillä on ajatus jonkin toimivuudesta, mutta emme tiedä sitä ennen kuin asia testataan käytännössä. Kun laitamme sen markkinoille, saamme asiakkailta palautetta. Saamme markkinoilta palautetta siitä, toimiiko tämä juuri näin.

Sen jälkeen voimme päättää, jatkammeko tällä polulla vai emme. Turvallinen tila on tärkeä, koska jos tuoteomistajille ja tuotepäälliköille ei anneta sitä, he valitsevat turvallisimman tavan saavuttaa mittarinsa. Silloin syntyy turvallisia tuoteratkaisuja, mutta ei koskaan innovatiivisia ratkaisuja.

Hannah Clark: Voin kuvitella maailman, jossa tämä tuotteen ja prosessin välinen kuilu jää huomaamatta, vaikka mittarit täyttyvät, ihmiset ovat yleisesti tyytyväisiä ja liiketoiminta pysyy pinnalla. Jotakin kuitenkin puuttuu. Millaisia oireita organisaatiossa näkyy, jos se kärsii tästä kuilusta hiljaisesti ja jos virheellisiä kokeiluja johtaa merkittäviin parannusmahdollisuuksiin ja vääriin päätöksiin?

Manuel Da Costa: Jos kokeiluissa on virheitä, olemme jo nähneet tilanteita, joissa tuotejohtajat ja varajohtajat sanovat, etteivät he oikeastaan luota kokeilujen tuloksiin. Silloin päätöksiä tehdään vaiston perusteella. Vaikka dataa olisi saatavilla, siihen ei luoteta ja se sivuutetaan saman tien.

Jos yritys pärjää juuri nyt, korostetaan sanaa juuri, se ei kokeile eikä innovoi vaan pelaa varman päälle. Ennemmin tai myöhemmin markkinavoimat pakottavat sen joko työskentelemään kovemmin kehittyäkseen tai määräävät yrityksen kohtalon. Kokeilutuloksiin tai päätöksentekoon kohdistuvan luottamuksen puute on kuitenkin ensimmäinen asia, jota on parannettava.

Toinen asia on se, että yritykset voivat puhua dataohjautuvuudesta, tuotekeskeisyydestä ja asiakaskeskeisyydestä, mutta nämä ovat vain muotisanoja. Käytännöistä näkee, toteutuvatko ne, eikä siitä, mitä yritys puhuu julkisuudessa. Näkee ominaisuuksia ja tuotejulkaisuja, jotka eivät oikeastaan vastaa asiakkaiden tarpeita.

Lopulta kyse on ominaisuustehtaasta: asioita julkaistaan julkaisemisen vuoksi sen sijaan, että asiakkaalle tai koko liiketoiminnalle tuotettaisiin arvoa.

Hannah Clark: Onko sinulla viitekehyksiä, joita suosittelisit parempien kokeilujen toteuttamiseen tai käytännön toimiksi?

Kuulostaa siltä, että tämän kuilun aiheuttavaan hajoamiseen vaikuttaa moni asia. Mikä on mielestäsi ensimmäinen askel, jos tunnistamme tämän ilmiön organisaatiossamme?

Manuel Da Costa: Ehdottomasti. Ensimmäinen askel on asioiden standardointi. Kun tuotetiimeille annetaan työkalut kokeilujen toteuttamiseen, olemme huomanneet, että saman organisaation kaksi tiimiä alkaa yhtäkkiä toimia eri tavoin: ne toteuttavat kokeiluja eri tavalla, luokittelevat dataa eri tavalla ja keräävät dataa eri tavalla. Ensimmäinen askel on ymmärtää, millainen prosessin pitäisi olla.

Kun prosessi on tiedossa, se standardoidaan. Standardointi saa ihmiset hermostumaan, koska he ajattelevat, että kaiken pitäisi olla hyvin jäykkää eikä joustolle olisi tilaa. Liian joustavan lähestymistavan ongelma on kuitenkin se, että ajan myötä syntyy kaaos ja datasta tulee lähes hyödytöntä tuleville tarkastelijoille.

Standardointi tarkoittaa prosessin, datan luokittelun ja siinä käytettävän nimistön standardointia sekä käytäntöjen standardointia: miten asioita analysoidaan ja kuka hyväksyy ne. Käyttöön voidaan ottaa esimerkiksi RACI-malli: kuka on vastuussa, kuka on tilivelvollinen ja kenelle asiasta on viestittävä ja ketä on informoitava.

Nämä asiat voivat vaikuttaa jäykiltä, mutta pohjimmiltaan ne luovat ihmisille suojakaiteet. Ei ole väliä, jos tiimi muuttuu ajan myötä, uusia ihmisiä liittyy siihen tai joku siirtyy toiseen tiimiin tai lähtee yrityksestä. Käytäntö on silloin mukana jokaisessa toteutettavassa kokeilussa ja jokaisessa sen perusteella tehdyssä päätöksessä.

Toinen asia on päätösten ja liiketoimintatavoitteiden välisen yhteyden tarkka määrittely. Päätöksiä ei pidä tehdä sokkona kokeilemalla, vaan niiden tulee vastata mittareiden lisäksi liiketoimintatavoitteita. Kun nämä kaksi asiaa ovat kunnossa, perustamme on paljon parempi.

Aluksi eteneminen on hidasta, koska ihmisten on totuttava siihen, että heidän on harkittava tarkemmin työjononsa priorisointia, kokeiltavia asioita, kokeilujen käynnistämistä ja niiden arviointia. On ratkaistava, viedäänkö ominaisuus täyteen tuotantoon vai lopetetaanko sen kehittäminen. Nämä asiat muodostavat perustan.

Sen jälkeen on varmistettava selkeä valvonta. Se tarkoittaa, että kuka tahansa voi tarkastella tiimiä tai henkilöä ja arvioida, miten hyvin tämä toimii. Tarkoitus ei ole etsiä syyllisiä, vaan ymmärtää puutteita ja sitä, miten tiimiä voidaan valmentaa paremmin.

Voidaan esimerkiksi todeta, että olet käynnistänyt viisi kokeilua tämän vuosineljänneksen aikana, mutta joillakin ei ole vahvaa hypoteesia tai niitä arvioitaessa ei ole valittu oikeita mittareita. Näin voit kehittyä. Ihmiset kehittyvät vain saamalla palautetta ja seurannan avulla. Tarkoitus ei ole antaa kielteistä palautetta, vaan myönteistä palautetta, jonka pohjalta he voivat kehittyä.

Nämä kaksi asiaa yhdessä parantavat organisaation perustasoa ja auttavat sulkemaan kuilua.

Hannah Clark: Mielenkiintoista on se, että tähän tarvitaan selvästi tunnetaitoja myös johtotasolla, jotta tällä tavalla johtaminen olisi tehokasta. Paljon riippuu johtoryhmän ja tuotetiimin kyvystä muodostaa turvallinen suhde, jossa on psykologista turvallisuutta tehdä virheitä ja toteuttaa kokeiluja, jotka eivät tuota odotettua tulosta.

Millaisia vinkkejä suosittelisit tiimien välisten ja erityisesti organisaatiokaavion eri tasojen välisten suhteiden vahvistamiseen? Miten voimme oppia luottamaan toisiimme paremmin, kun työskentelemme tiiviisti uudenlaisen prosessin parissa?

Manuel Da Costa: Se on helpommin sanottu kuin tehty, koska mukana on ihmisiä ja egoja, ja ihmisten on oltava haavoittuvia. Se on vaikeinta. Johtajien on kuitenkin tarjottava psykologista turvallisuutta ja muutettava hieman myös kieltä, jota käytämme.

Emme sano, että testi onnistui tai epäonnistui. Keskitymme oppimiseen. Keskustelua siirretään voittojen ja tappioiden sijaan siihen, että kokeilun avulla validoimme tämän ominaisuuden tarpeen tai asiakkaan tarpeen ja autimme näin yritystä.

Voimme sanoa, että tämä on kokeilun potentiaali. Tai että kokeilun avulla itse asiassa kumosimme oletuksen: emme nähneet tarvetta rakentaa tätä ominaisuutta. Säästimme näin kehitystiimin kustannuksia ja opimme tämän, minkä pohjalta jatkamme oppimista. Ajattelutapaa on muutettava pois kokeilemisesta kokeilemisen vuoksi tai kokeilemisesta voiton saavuttamiseksi. Siksi mittarit ovat niin tärkeitä ja se, miten ne muotoillaan, on niin tärkeää.

Tuotepäälliköt, tuoteasiantuntijat ja tuoteomistajat saattavat kuunnella tätä ja sanoa, että haluaisimme tehdä näin, mutta emme voi, koska mittarimme ovat erilaiset. Siksi johdon on tärkeää kiinnittää tähän huomiota. Jos emme tee sitä, organisaatioista tulee ominaisuustehtaita. Saattaa näyttää siltä, että asiat vievät paljon aikaa ja saamme jotain ulos, mutta todella: missä määrin?

Hannah Clark: Hyvä huomio.

Olen myös utelias käytännön johtamisesta. Mittarit vaihtelevat luonnollisesti tiimeittäin, mutta myös tiimien koot vaihtelevat. Miten valvomme tuotetiimiä tehokkaasti skaalautuessamme, kun uudet työntekijät tulevat mukaan erilaisella tietämyksellä tai organisaation sisäisellä osaamisella kuin kokeneemmat työntekijät?

Miten standardoimme ja varmistamme valvonnan oikean tason, etenkin kun meitä johtajia on huomattavasti vähemmän kuin ohjauksessamme olevia tiimin jäseniä?

Manuel Da Costa: Meillä on kehitetty tällainen koordinaattorin rooli. Tiimien ja niiden jäsenten määrästä riippuen luodaan koordinaattorin tehtävä, jossa henkilö valvoo pienempää tiimimäärää tai tiettyä ihmisjoukkoa. Hän vastaa tiimien perehdyttämisestä, valmentamisesta ja ohjaamisesta sekä siitä, että hänen vastuualueellaan kaikki etenee niin kuin pitää. Sen jälkeen hän raportoi seuraavalle johtotasolle.

Sen sijaan että yksi johtaja valvoisi kaikkia, kannattaa nimetä henkilö, joka vastaa yhdestä tai useammasta tiimistä. Hänen tehtävänsä on perehdyttää, valmentaa ja ohjata, jotta hänen alaisuudessaan olevat ihmiset toteuttavat parempia kokeiluja ja tekevät oikeita tuoteratkaisuja.

Heidän on toimittava prosessiin ja rakenteisiin asetettujen suojakaiteiden puitteissa. Tämä on tärkeää organisaation rakennetta tarkasteltaessa. Koordinaattori voi valvoa useita tiimejä, mutta kaikki riippuu tiimien koosta.

Hannah Clark: Olen kanssasi samaa mieltä myös suojakaiteiden käsitteestä. Se kuulostaa helposti voimaannuttamisen vastaiselta, mutta olen käytännössä huomannut, että selkeät suojakaiteet vähentävät päätösväsymystä ja tekevät ihmisten työstä paljon selkeämpää. Ihmisten ei tarvitse jatkuvasti muokata prosessejaan rakentamiensa tuotteiden lisäksi. Näen tässä todella vahvat perusteet.

Olen kuitenkin utelias, koska puhumme nyt myös valvonnan standardoinnin tarpeesta. Se on mielestäni hieman abstraktimpi asia: miten standardoimme tiimin valvonnassa käytettävän prosessin, vaikka tiimi olisi pieni?

Millaisia suosituksia sinulla on valvontatavan standardointiin erityisesti silloin, jos johtajalla ei itsellään ole vahvaa kokemusta kokeiluista?

Manuel Da Costa: Kaikki alkaa hallintamallin luomisesta. Kun tarkastelet, mitä se sisältää, kyse on sääntöjen luomisesta kokeilun perustamista varten.

Kun puhun kokeilun perustamisesta, tarkoitan sitä, mitä keskeisiä asioita kokeilua luotaessa pitää kirjata. Osa niistä voi olla melko perustavanlaatuisia. Jotkin ovat pakollisia, kuten hypoteesi – hyvä hypoteesi. Hypoteesin ja todella vahvan hypoteesin välillä on ero.

Se on yksi näkökulma, mutta lisäksi on päätettävä, mitä muita tietoja kerätään. Tarkoitan tietoja, jotka ovat hyödyllisiä kokeilua luotaessa, kuten teknisiä tietoja, kohderyhmää ja vastaavia asioita. Lisäksi tarvitaan liiketoiminnan kannalta merkityksellisiä tietoja. Kun luomme hallintamallin, määrittelemme, että jokaisen organisaatiossa kokeilun luovan henkilön on kirjattava tietyt kentät tai tietopisteet.

Niistä ei neuvotella. Ne on kirjattava – se on vähimmäisvaatimus. Sen lisäksi on valinnaisia tietoja. Tämä voidaan tavallaan pakottaa, vaikka sana pakottaminen kuulostaa ikävältä. Suojakaiteet varmistavat, ettei organisaatio päädy hyödyttömän datan kasan päälle.

Jos joustavuutta on liikaa, eri tiimit tulkitsevat kokeilun eri tavoin. Hallintamalli määrittää, että kokeilua luotaessa on kerättävä liiketoiminnan kannalta olennaiset ja teknisesti merkitykselliset tiedot.

Sen jälkeen on prosessi, jota noudatetaan. Kokeilua ei voi suunnitella, toteuttaa ja analysoida ilman tiettyjen vaiheiden läpikäyntiä. Et esimerkiksi julkaisisi ominaisuutta tekemättä sille laadunvarmistusta. Sama koskee kokeilua. Kokeilua ei julkaista ilman laadunvarmistusta. Hallintamallissa on siis määriteltävä, ettei kokeilu voi edetä tiettyjen vaiheiden läpi ilman esimerkiksi laadunvarmistusta.

Tämä ei ole neuvoteltavissa. Jokaisen kokeilun on käytävä sen läpi. Näin jokainen kokeilu seuraa tiettyä polkua eikä voi poiketa siitä. Jos se poikkeaa, voidaan seurata tilannetta ja selvittää, miksi niin tapahtui. Tässä kohtaa mukaan tulee kehittämämme kokeilun terveystaulukko.

Terveystaulukko on tarkistuslista asioista, joiden perusteella kokeilu voidaan arvioida. Oliko hypoteesi laadittu? Kyllä vai ei? Toinen kysymys on, milloin se laadittiin. Laadittiinko se kokeilua suunniteltaessa vai vasta myöhemmin, kun kokeilua yritettiin perustella?

Näinkin tapahtuu. Olemme kohdanneet ilmiön, jota emme itse kehittäneet. Sitä kutsutaan tulosten jälkeiseksi hypoteesiksi eli HARKingiksi. Siinä tietoa painostetaan riittävän pitkään kertomaan se, mitä halutaan kuulla. Näin joskus käy kokeiluille, jotka eivät oikeastaan onnistu.

Ne eivät voita. Sitten mittareita voidaan muuttaa ja hypoteesia siirtää. Yhtäkkiä kokeilu onkin onnistunut. Hallintamallit ja suojakaiteet ovat tärkeitä, koska ne estävät tätä. En väitä, että ihmiset tekisivät tätä tarkoituksella. Asia palautuu kuitenkin mittareihin: niiden tavoitteena on saavuttaa tietty määrä tuoteominaisuuksia, toteuttaa tietty määrä kokeiluja tai saavuttaa tietty onnistumisprosentti.

Silloin kaikkea muokataan kyseisen luvun saavuttamiseksi. Hallintamallin ja terveystaulukon avulla näitä asioita voidaan seurata. Noudattiko kokeilu määrittämäämme prosessia? Muutettiinko kokeilun keskeisiä tietoja sen valmistumisen aikana?

Voimme alkaa seurata asiaa. Terveystaulukko antaa kuvan siitä, toteutettiinko kokeilu oikein. Sen jälkeen voimme sanoa, että luotamme tähän kokeiluun, sen tuloksiin ja siitä tekemiimme päätöksiin – tai ettemme luota kokeiluun. Voimme myös kertoa syyt, mutta kyse on jälleen mahdollisuudesta valmentaa.

Tavoitteena on saada organisaatio tekemään parempia tuoteratkaisuja ja toteuttamaan parempia kokeiluja niiden saavuttamiseksi.

Hannah Clark: Arvostan todella paljon tarjoamiasi viitekehyksiä. Tämä on ollut erittäin hyödyllistä.

Tuleeko mieleesi menestystarinoita organisaatiosta, joka onnistui muuttamaan tuloksiaan poistamalla tuotteen ja prosessin välisen kuilun?

Manuel Da Costa: En voi kertoa yrityksen nimeä, mutta teimme juuri näin yrityksen kanssa, joka siirtyi osaamiskeskustiimistä tuotetiimeihin ja markkinatiimeihin. Yritys oli maailmanlaajuinen verkkokauppayritys, jolla oli monenlaisia markkinatiimejä ja tuotetiimejä, jotka vasta tutustuivat testaamiseen.

Tärkeää oli, ettemme tuoneet jokaista tuote- ja markkinatiimiä kokeiluihin suoraan. Teimme jokaisesta tiimistä SWOT-analyysin ja arvioimme, kuinka hyvä niiden kokeiluosaaminen oli. Toinen tekijä oli se, kuinka innokkaita ja halukkaita ne olivat osallistumaan.

Aloitimme tiimeistä, jotka saivat näissä arvioissa korkeat pisteet, ja käytimme niitä vähitellen sosiaalisena todisteena. Kun muutama tiimi oli perehdytetty ja niiden työ sujui hyvin, käytimme niitä seuraavan ihmisryhmän mukaan saamiseen sekä tiimien välisen yhteisötuen tarjoamiseen.

Toteutimme tämän kolmen kuukauden jaksoissa. Jokaisessa jaksossa oli suunnitelma, jonka avulla tiimit valmennettiin ja perehdytettiin niin, että ne olivat ohjelman lopussa itsenäisiä.

Vakiinnutimme toiminnan kahden vuoden aikana. Se oli melko pitkä prosessi. Tämä ei tapahdu yhdessä yössä, varsinkaan suuressa yrityksessä.

Kulttuurinmuutos ei tapahdu yhdessä yössä. Kaksivuotisen jakson lopussa tuotetiimit osasivat toteuttaa kokeiluja huomattavasti paremmin. Vaikka henkilöstö vaihtui, yrityksestä lähti ihmisiä ja uusia tuli tilalle, uuden työntekijän perehtyminen prosessiin kesti alle kuukauden, koska kaikki viitekehykset olivat valmiina.

Järjestelmät olivat valmiina ja kaikki tiesivät täsmälleen, miten toimia. Kaikki oli niin hyvin paikoillaan, ettei voinut tehdä väärin – näin asian voi ilmaista – koska ihmisten oli paljon helpompi seurata valmista toimintatapaa kuin yrittää tuoda siihen omaa tulkintaansa.

Hannah Clark: Arvostan suuresti jakamiasi esimerkkejä, ja tämä on ollut todella informatiivista.

Kiitos paljon, Manuel, että liityit seuraamme. Mistä ihmiset voivat seurata sinua verkossa, jos he haluavat oppia lisää työstäsi ja Effective Experimentsista?

Manuel Da Costa: Minut löytää LinkedInistä. Olen siellä melko aktiivinen. Voit myös vierailla osoitteessa EffectiveExperiments.com ja lukea lisää toiminnastamme. Julkaisen myös paljon sisältöä blogissamme. Seuraa minua vapaasti näissä kahdessa kanavassa.

Hannah Clark: Hienoa. Kiitos paljon.

Kiitos kuuntelusta. Jos haluat lisää hyviä näkemyksiä, käytännön oppaita ja työkaluarvosteluja, tilaa uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla CPO Clubin sieltä, missä kuuntelet podcastisi.