Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.
Hannah Clark: Kerro nopeasti, laskematta: kuinka monta kirjautumistunnusta käytät tällä hetkellä työssäsi viikoittain? Jos et tiedä, paina taukoa ja yritä laskea. Veikkaan, että luku on järkyttävä. CloudZeron vuoden 2024 raportin mukaan keskivertotyöntekijä käyttää tällä hetkellä 36 pilvipohjaista palvelua päivässä, ja insinööritiimit käyttävät niitä kaksi kertaa enemmän.
Aika hurjaa, eikö? Tässä on vielä toinen hurja asia, joka ei luultavasti yllätä sinua. CloudZeron vuoden 2023 tutkimuksen mukaan yli 53 prosenttia SaaS-lisensseistä jää käyttämättä. Toisin sanoen, vaikka organisaatiomme tarvitsevat jatkuvasti työkaluja ainutlaatuisten toimintojensa tueksi, tuhlaamme valtavasti rahaa työkaluihin, jotka eivät jostain syystä vain sovi tarpeisiimme.
Tämän päivän vieraani on Moshe Mikanovsky, Products for Goodin perustaja ja johtava tuotevalmentaja sekä Product for Product -podcastin toinen juontaja. Moshe on työskennellyt tuote- ja ohjelmistokehityksen parissa vuodesta 1989 lähtien, ja viime vuosina hänen tärkeänä tavoitteenaan on ollut auttaa tuotetiimejä tekemään parempia päätöksiä käyttöön otettavista työkaluista.
Moshe on kehittänyt kattavan viitekehyksen, joka auttaa organisaatioita valitsemaan tarpeisiinsa sopivat työkalut. Näin voidaan lisätä käyttöönottoa ja tuottavuutta sekä vähentää tuhlailevaa kulutusta. Keskustelemme viitekehyksen tärkeimmistä kohdista, joiden avulla voit valita parempia työkaluja jo tänään. Aloitetaan.
Tervetuloa takaisin CPO Club -podcastiin. Tänään seurassani on Moshe Mikanovsky. Hän on Products for Goodin perustaja ja johtava tuotevalmentaja.
Moshe, kiitos paljon, että liityit seuraamme tänään.
Moshe Mikanovsky: Kiitos kutsusta, Hannah.
Hannah Clark: Aloitetaan samalla tavalla kuin aina. Voisitko kertoa hieman taustastasi ja siitä, miten päädyit nykyiseen tilanteeseesi?
Moshe Mikanovsky: Aloitin ohjelmistokehittäjänä monta vuotta sitten. Urani ensimmäiset 20 vuotta työskentelin insinööritehtävissä. Olin onnekas saadessani työskennellä pienissä organisaatioissa ja käytännössä suoraan asiakkaiden ja käyttäjien kanssa. Uskon, että näin kehitin osan empatiastani käyttäjiä ja heidän tarpeitaan kohtaan.
Sitten 20 vuoden jälkeen päätin siirtyä tuotepäälliköksi. Olen tehnyt sitä nyt 14–15 vuoden ajan. Pidän siitä todella paljon. Rakastan puhua tuotehallinnasta ja auttaa muita ihmisiä rakentamaan tuotteita. Haluan nähdä, mitä ympärillä tapahtuu, mikä toimii ja mikä ei, sekä oppia uusia menetelmiä.
Kaikki tuotteisiin liittyvä on siis osa sitä, mikä saa minut nousemaan aamuisin.
Hannah Clark: Olet hyvässä seurassa.
Tänään puhumme aiheesta, joka kiinnostaa mielestäni kaikkia: työkaluista. Siitä, miten tuotetiimit voivat tehdä parempia päätöksiä valitessaan työkaluja organisaatioilleen. Kyseessä on jatkuva haaste, ja se on myös yksi tärkeimmistä asiantuntemusalueistasi. Mikä alun perin sai sinut luomaan tuotteenvalintaa koskevan viitekehyksesi, josta puhumme kohta?
Moshe Mikanovsky: Minulla on ystäväni Matt Greenin kanssa podcast, jota olemme juontaneet yhdessä jo neljän vuoden ajan. Sen nimi on Product for Product.
Podcastissa käsittelemme työkaluja, joita tuotealan ihmiset käyttävät. Se on aina kiinnostanut meitä molempia, joskin eri näkökulmista. Matt kiinnostui niistä siirtyessään tuotehallintaan, kun taas minä olen kokeillut erilaisia tuotteita ja joutunut valitsemaan niitä itse, koska kukaan muu ei tehnyt valintoja puolestani.
On aina kiinnostavaa nähdä, mitä kaikkea on saatavilla. Sitä teemme podcastissa. Eri aiheisiin ja erilaisten tuotteiden ympärille keskittyneitä jaksoja nauhoittaessani tajusin, että siinä, miksi ihmiset käyttävät tiettyjä tuotteita, mitä he niissä pitävät ja mistä eivät pidä, on paljon yhteisiä piirteitä.
Haastattelemme aina tuotteiden käyttäjiä, ellei kyseessä ole startup-yritys. Silloin käyttäjiä ei välttämättä ole paljon, joten kutsumme mukaan perustajan. Useimmiten haastattelemme kuitenkin käyttäjiä. Heillä on jo kokemusta ja tietoa siitä, miten tuotetta käytetään, mikä toimii ja mikä ei.
Näin kokosin paljon perusteluja ja asioita, joita kannattaa etsiä. Lopulta päätin koota kaiken yhteen viitekehykseen, jota jaan mielelläni ihmisille.
Hannah Clark: Puhutaan kokemuksesi pohjalta joistakin virheistä, joita ihmiset tekevät, ennen kuin siirrymme oikeanlaiseen toimintatapaan tai parhaaseen organisaatiolle sopivaan viitekehykseen. Mitkä ovat yleisimpiä virheitä, joita tuoteyritykset tekevät valitessaan uusia työkaluja, ja millaisiin seurauksiin ne yleensä johtavat?
Moshe Mikanovsky: Luulen, että kyse on pääasiassa siitä, miten työkalut valitaan, eikä niinkään siitä, että yritettäisiin löytää työkalulle parempi sopivuus oman organisaation kanssa. Se on ensimmäinen asia. Viitekehys käsittelee tätä melko pitkälti. Toinen yleinen virhe on se, ettei työkaluja ymmärretä kunnolla ennen niiden valitsemista.
Uusi työkalu innostaa aina. Etsimme sitä ja tutustumme erilaisiin ominaisuuksiin. Ajattelemme, että se sopii tarpeisiimme, mutta käyttöönottovaiheessa saatamme huomata, ettei se olekaan aivan sellainen kuin kuvittelimme. Ehkä katsoimme vain toimittajan verkkosivuston markkinointitietoja, jotka eivät kerro koko totuutta.
Esittelyt eivät ehkä myöskään kerro koko totuutta, tai käyttöönottovaiheen aikana vastaan tulee erilaisia yllätyksiä. Siksi näen usein, ettei työkalu sovi organisaatiolle parhaalla mahdollisella tavalla eikä tuotteen todellista toimintaa heidän tarpeisiinsa nähden ymmärretä riittävästi.
Hannah Clark: Kuulostaa järkevältä.
Käydään sitten läpi valintaprosessisi. Viitekehyksesi alkaa ongelmien tunnistamisesta, minkä jälkeen ongelmat priorisoidaan ja vaihtoehdoista tehdään lyhyt lista, ja lopuksi työkaluja vertaillaan. Ennen varsinaista vertailua tehdään siis melko paljon esityötä.
Miksi tämä alustava työ on niin tärkeää ennen ominaisuuksien vertailuun siirtymistä?
Moshe Mikanovsky: Lähestyn lähes kaikkea tuotteen tavoin, koska olen työskennellyt tuotealalla niin pitkään. Tein samoin tämän kanssa. On todella tärkeää ymmärtää, mikä on todellinen ongelma, jota yritämme ratkaista.
Emme halua rakentaa ominaisuuksia ratkaisulle, jota kukaan ei käytä. Samalla tavalla emme oikeastaan tarvitse tiettyjä ominaisuuksia, jos meillä ei ole ratkaistavaa ongelmaa. Se, että kaikki muut tekevät jotakin, ei tarkoita, että sinun täytyy tehdä samoin tai että heidän tapansa sopii organisaatiosi toimintaan.
Siksi alustavan työn tarkoitus, ennen kuin edes tarkastelemme kaikkia ominaisuuksia, on ymmärtää todelliset ongelmat, joita yritämme ratkaista. On ymmärrettävä myös tuotetiimin työ eli se, mitä sen pitäisi saada aikaan ja mihin työkalut valitaan. Sen jälkeen voidaan määrittää eri asioiden tärkeysjärjestys.
Emme aina voi ostaa kaikkia tuotteita heti. Joskus edes yhden tuotteen budjetin saaminen on vaikeaa. Siksi on priorisoitava suurin tämänhetkinen ongelma. Kyse ei välttämättä aina ole ongelmasta, vaan jostakin, jonka tekeminen vie paljon aikaa, aiheuttaa paljon epäjärjestystä tai vaatii muuten selvittämistä.
Tämän suurimman ongelman perusteella voidaan määrittää prioriteetti ja sanoa: tämä on ensimmäinen asia, jota meidän täytyy etsiä. Sen jälkeen voidaan luoda lähes tiekartta tuotteiden valintaa ja myöhempää käyttöönottoa varten.
Hannah Clark: Haluaisin puhua hieman eräästä kiinnostavasta osasta työkalujen vertailuprosessiasi: tuoteajattelusta, joka on ensimmäinen kriteeri.
Mitä tarkoitat tuoteajattelulla ja miksi sillä on merkitystä? Millaisia erot tuoteajattelussa ovat käytännössä, ja miten ne vaikuttavat työkalujen sopivuuteen organisaatiolle?
Moshe Mikanovsky: Olen keskustellut ihmisten kanssa ja huomannut omasta sekä juontajakumppanini Mattin kokemuksesta, etteivät kaikki pidä samanlaisesta työskentelystä tai viestinnästä. Emme myöskään painota samoja asioita.
Sitä tarkoitan tuoteajattelulla. Jotkut meistä haluavat yhden tuotteen, joka ratkaisee kaiken. Kaikkien tarvitsemiemme ominaisuuksien pitäisi löytyä samasta paikasta, eikä mitään muuta tarvitsisi ottaa käyttöön. Tiedämme kuitenkin, etteivät tällaiset tuotteet yleensä mene kovin syvälle yksittäisissä ominaisuuksissa, vaan ne kattavat laajasti monia asioita.
Toiset taas ajattelevat, että jokaiseen yksittäiseen ongelmaan halutaan paras mahdollinen ratkaisu. Tuotteet halutaan integroida, jotta ne keskustelevat keskenään, mutta se lisää ratkaisun monimutkaisuutta. Tämä on yksi esimerkki siitä, millainen organisaatio todella on.
Jos et tunne organisaatiosi toimintatapaa tai tiedä, kuka päätökset tekee, asiaa voi olla vaikea määrittää. Tieto on kuitenkin tärkeää, koska sen avulla voidaan rajata valinta tiettyyn tuotteeseen tai tehdä parempi lyhyt lista vaihtoehdoista.
Toinen tuoteajatteluun liittyvä kysymys on se, halutaanko tuotteen olevan joustava vai ennalta määritelty. Jotkin tuotteet antavat luoda haluamasi työnkulun ja määrittää haluamasi kentät. Ne ovat hyvin yleiskäyttöisiä ja joustavia, joten jokainen organisaatio ottaa ne käyttöön hieman eri tavalla.
Jotkin saman kategorian tuotteet taas ovat hyvin ennalta määriteltyjä ja kertovat, miten asiat on tehtävä. En sano, että toinen olisi parempi kuin toinen. Joskus kyse on organisaation kypsyysasteesta, ei niinkään siitä, kuinka nuori organisaatio on.
Jos organisaatio ei esimerkiksi tunne tiettyä tapaa toteuttaa sprinttejä, ylläpitää työjonoa tai hoitaa muita vastaavia asioita ja se käyttää ennalta määriteltyä tuotetta, tuote opettaa sille prosessin. Se opettaa kuitenkin vain yhden tavan, vaikka muitakin vaihtoehtoja olisi.
Kun organisaatio kypsyy, se saattaa tuntea olonsa mukavammaksi sellaisen tuotteen kanssa, joka on paljon joustavampi. Nämä ovat asioita, joita tarkastelen osana viitekehystä jo ennen kuin tutustutaan ominaisuuksiin: millainen kulttuuri teillä on ja millaiset tuotteet sopivat teille parhaiten.
Hannah Clark: Joustavuudesta puheen ollen haluan kysyä toisesta kriteeristä: jatkuvasti tarvittavasta insinöörityöstä. Miten tiimien pitäisi arvioida eri työkalujen integrointiin tarvittavia insinöörityön resursseja, ja miten se voi vaikuttaa tuotteen pitkäaikaiseen menestykseen?
Moshe Mikanovsky: Tämä liittyy myös tietynlaiseen filosofiaan, jota sovellan tuotteiden rakentamiseen omassa yrityksessäni ja konsultoidessani muita yrityksiä. Insinöörien pitäisi keskittyä tuottamaamme lisäarvoon eikä keksiä uudelleen asioita, jotka miljoonat muut kehittäjät ovat jo toteuttaneet.
Kun lisään tuotteeseeni esimerkiksi sovelluksen sisäistä viestintää tai tuoteanalytiikkaa, jotka ovat nykyään saatavilla tällaisissa työkaluissa, en halua kehittäjieni huolehtivan niistä. Haluan mieluummin, että he tekevät kerran yksinkertaisen integraation ja unohtavat asian.
Sen jälkeen minun, tuotepäällikön, tai muiden insinööritiimin ulkopuolisten ihmisten pitäisi voida määrittää kaikki tarvittava, jotta tuotteesta saadaan mahdollisimman paljon arvoa. Jotkin saman kategorian työkalut kuitenkin vaativat jatkuvasti insinöörien työtä, koska niissä on määritettävä tapahtumia tai sovelluksen sisäisen viestinnän ulkoasua.
Minusta se on kehittäjien ajan tuhlaamista. Haluan heidän työskentelevän organisaatiollemme ainutlaatuisen arvon parissa.
Hannah Clark: Yrityksen arvoista ja ainutlaatuisista asioista puheen ollen: mainitsit myös, että kulttuuriset tekijät, kuten yrityksen arvot ja viestintätyylit, voivat vaikuttaa työkalujen valintaan.
Haluaisin kuulla esimerkin siitä, miten tämä toimii käytännössä ja miten nämä vaikeammin havaittavat tekijät voivat vaikuttaa siihen, mitkä työkalut menestyvät organisaatiossa.
Moshe Mikanovsky: Voin antaa esimerkin paikasta, jossa työskentelin ja jossa asynkronisen viestinnän kanssa oli todella vaikeaa. Se ärsytti minua, koska työskentelimme etänä. Voisi ajatella, että etätyössä asynkroninen viestintä auttaa yhteistyössä eikä jatkuvia kokouksia tarvita.
Meidän oli kuitenkin oltava jatkuvasti säännöllisissä kokouksissa, jotta asiat etenivät. Käytimme myös työjonojärjestelmää, taisi olla Jira. Tällaisissa järjestelmissä määritellään esimerkiksi epicit Confluence-asiakirjaan ja käyttäjätarinat hyväksymiskriteereineen.
Odotat, että ihmiset lukevat ne ja tekevät yhteistyötä kommenttien avulla. Se ei kuitenkaan toiminut. Aina kun joku sanoi, ettei ollut nähnyt jotakin, tai asia nostettiin esiin kokouksessa, ajattelin, että kaikkihan oli jo kirjoitettu sinne.
Kyse oli kulttuurisesta ongelmasta, joka vaikutti siihen, kuinka hyödyllistä tuotteiden käyttömme oli. Tunsin välillä uivani vastavirtaan. Minun täytyi pitää kokonainen istunto selittääkseni asynkronista viestintää ja sen tärkeyttä. En muista, auttoiko se lopulta.
Tätä tarkoitan organisaation toimintatavalla. Työkalu ei välttämättä korjaa ongelmaa. Se voi auttaa parantamaan viestintää, jos sen käyttöön todella panostetaan. Se voi auttaa parantamaan prosesseja, jos se sopii organisaation työskentelytapaan.
Yleensä asia ei toimi toisinpäin, vaikka työkalu voikin auttaa muuttamaan yrityksen toimintatapoja. Tarkastelisin ensin kulttuurisia rajoitteita ja sovittaisin työkalun niiden mukaan.
Hannah Clark: Nyt ymmärrän paremmin.
Palataan ominaisuuksien vertailuun, kun olemme käsitelleet esityön ja tekijät, jotka täytyy ottaa huomioon ennen työkalun yksityiskohtaista tarkastelua.
Monet tiimit siirtyvät työkaluja arvioidessaan suoraan ominaisuuksien ja hinnan vertailuun. Mainitsit tämän aiemmin. Miksi nämä tekijät ovat arviointikehyksessäsi vasta niin myöhään?
Moshe Mikanovsky: En halua ihmisten tarkastelevan ensin sitä, mitä he voivat tuotteella tehdä, vaan sitä, mitä lopputuloksia he yrittävät saavuttaa.
Ominaisuuksia on luultavasti helpompi vertailla. Organisaatiot kertovat, että niillä on tietty ominaisuus ja toinen ominaisuus. Yksityiskohtia tarkasteltaessa, jos ne on julkaistu, tai niitä itse etsiessä selviää, vastaavatko ominaisuudet todella odotuksia.
Joskus käytetään erilaista terminologiaa. Joskus eri ominaisuuksilla on hyvin erilaiset hinnat. Se on täysin hyväksyttävää, mutta yleensä meidän kuluttajien täytyy käydä kaikki yksityiskohdat läpi löytääksemme meille sopivan tuotteen.
Tärkeintä on kuitenkin se, että työkalujen valinnan ja käyttöönoton pitäisi perustua tavoiteltuihin lopputuloksiin, ei vain tuotoksiin. Pelkkä se, että työkalu pystyy johonkin, ei tee siitä parempaa kuin toisesta työkalusta.
Hannah Clark: Siirrytään ehkä uuden työkalun käyttöönoton turhauttavimpaan osaan: kaikkien saaminen käyttämään sitä ja toimimaan samalla tavalla.
Varsinkin kun oikean työkalun löytämiseen, mukauttamiseen ja kaikkien näiden asioiden huomioimiseen on käytetty paljon aikaa, ihmisten pitää silti saada käyttämään työkalua samalla tavalla. Mitkä ovat keskeisiä strategioita onnistuneen käyttöönoton varmistamiseksi koko organisaatiossa?
Moshe Mikanovsky: Ensimmäinen on oikean työkalun valitseminen tai ainakin mahdollisimman vähän sopimattoman työkalun löytäminen, koska ongelmia tulee aina olemaan. Toinen asia on valintaprosessi. Se on haastava ja riippuu siitä, kuka prosessista vastaa ja millainen omistajuuden ja valinnan hallintamalli on.
Jo tässä vaiheessa voi olla vastustajia. Minulla ei ole tällä hetkellä tarkkaa suositusta, mutta pohdin asiaa ja laajennan viitekehystä todennäköisesti myöhemmin, kun saan lisää tietoa muilta ihmisiltä.
Jos valintaprosessissa on paljon ihmisiä, valinta voi kestää hyvin kauan. Lisäksi pitää kysyä, haetaanko hyväksyntää vai yksimielisyyttä. Se on toinen organisaation kulttuuriin liittyvä asia. Sitten on vielä tuotteen omistajuus: ei pelkästään valinnan tai käyttöönoton näkökulmasta, vaan myös sen kannalta, kuka on historiassa vastannut tuotteista.
Aiemmin IT-osasto omisti organisaatioissa tuotteet, koska kyse oli ohjelmistosta, joka piti asentaa tietokoneelle. Silloin IT omisti sen. Se ei kuitenkaan välttämättä välittänyt siitä, oliko käyttöönotto onnistunut. Siksi tarvittiin toinen henkilö edistämään käyttöönottoa. Myös omistajuus on siis tärkeää.
Nykyään tuoteoperaatiot voivat helpottaa työtä, jos organisaatiossa on tällainen toiminto. Näen työkalujen valinnan sopivan hyvin tuoteoperaatioihin, erityisesti silloin, kun käytännöt halutaan yhdenmukaistaa koko organisaatiossa.
Tuoteoperaatiot voivat ymmärtää eri tiimien tarpeita ja niiden välisiä eroja sekä käyttöönoton ja käytön vaikeuksia. Kyse voi olla persoonallisuuksiin liittyvistä ongelmista, projektin rajoitteista tai monista muista tekijöistä.
Kuten minkä tahansa tuotteen kohdalla, meidän täytyy joskus tehdä kovasti töitä, jotta tuotteemme otetaan asiakkaidemme organisaatioissa kunnolla käyttöön. Tässä puhutaan yrityksille suunnatuista tuotteista, joten kaikki mainitsemamme tuotteet ovat B2B-tuotteita. Jos kehität B2B-tuotetta, tiedät todennäköisesti, mistä puhun, ja tunnet enemmän empatiaa tätä kohtaan.
Jos et rakenna B2B-tuotteita, et ehkä täysin ymmärrä asiaa. Se ei ole aina helppoa. Kaikki riippuu organisaation koosta, projektien ja tuotteiden määrästä sekä monista muista tekijöistä.
Sanoisin kokonaisuutena, että on tärkeää tietää, kuka tekee päätöksen, kuka omistaa asian, millainen hallintamalli on käytössä ja miten ihmiset todella hyväksyvät päätökset ja vievät niitä eteenpäin. Myös iteraatioita kannattaa tehdä, eikä kaikkea tarvitse ottaa käyttöön heti.
Voitte kokeilla erilaisia asioita ja kehittää niitä iteratiivisesti aivan kuten mitä tahansa muutakin tuotetta.
Hannah Clark: Kuulostaa järkevältä. Perehdytysprosessi voi olla hieman vaiheistetumpi. Tässä tilanteessa käyttäjiin on ainakin parempi yhteys, joten se on etu.
Moshe, kiitos paljon, että liityit seuraamme tänään. Tämä oli todella informatiivista. Se on ollut hyödyllistä, koska jokainen joutuu jossain vaiheessa valitsemaan uusia työkaluja ja niiden käyttöönotto voi olla melkoinen matka. Arvostamme suuresti neuvojasi. Mistä ihmiset voivat lukea lisää kehittämästäsi tuotteenvalinnan viitekehyksestä ja ottaa sinuun yhteyttä verkossa?
Moshe Mikanovsky: Kiitos itsellesi ja kutsusta. Minuun voi ottaa yhteyttä LinkedInissä. Löydät minut sukunimelläni Mikanovsky. Verkkosivustoni on productsforgood.co.
Viitekehys on julkaistu Miroverse-tauluna. Sivustoni resurssiosiossa on siihen linkki. Jaan sen myös kanssasi, jotta voit lisätä sen jaksojen kuvaukseen. Saat jakaa sen mielelläsi kaikille. Sen voi kopioida ja ottaa heti käyttöön. Siellä on selityksiä ja paljon resursseja, kuten Airtable-taulukko sekä luettelo tuotteista luokitteluineen.
Se on edelleen työn alla, sillä löydän jatkuvasti uusia tuotteita. Jos jotakin puuttuu, ota ehdottomasti yhteyttä LinkedInissä. Kuulisin mielelläni kaikilta.
Hannah Clark: Olisimme todella innoissamme voidessamme jakaa sen. Kiitos paljon kaikista resursseista ja ajastasi.
Moshe Mikanovsky: Ilo oli minun puolellani. Kiitos paljon, Hannah.
Hannah Clark: Kiitos kuuntelusta. Lisää hyviä näkemyksiä, oppaita ja työkaluarvosteluja saat tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla CPO Clubin siellä, missä kuuntelet podcasteja.




