Miten tekoälytuotteiden rakentaminen eroaa muusta – ja miksi tuotetiimien on kehityttävä

Galen Low: Onko tekoälyn natiivitoiminnallisuutta sisältävän tuotteen kehittämisprosessissa todella jotain niin erilaista verrattuna muihin tuotteisiin, jotka vain sattuvat hyödyntämään olemassa olevaa tekoälyteknologiaa?

Jyothi Nookula: Kyllä. Kun rakennat tekoälyn natiivituotetta, käsittelet kolmea asiaa, jotka ovat erilaisia. Ensinnäkin tekoäly on pohjimmiltaan ennalta arvaamatonta.

Galen Low: Mikä on ensimmäinen asia, jonka teet johtajana, kun huomaat, etteivät kaikki tiimin jäsenet ehkä ole samalla tasolla ymmärtäessään, hyödyntäessään tai edes hyväksyessään tekoälyn kaltaisia uusia teknologioita?

Jyothi Nookula: Jaan ongelman kahdeksi erilliseksi asiaksi. Ensimmäinen on osaaminen. Toinen on suhtautuminen. Jos käsittelet suhtautumisongelmaa osaamisongelmana, pahennat tilannetta vain entisestään.

Galen Low: Mitkä ovat tärkeimmät asiat, jotka tekoälytuotteiden kehittämisestä kiinnostuneen tuotepäällikön pitäisi tuoda esiin ansioluettelossaan tai portfoliossaan erottuakseen joukosta?

Jyothi Nookula: Yksi asia on näyttö tekoälyä hyödyntävän tuotteen rakentamisesta, ei vain siitä puhumisesta. Toinen asia on...

Galen Low: Tervetuloa The Digital Project Manager -podcastiin – ohjelmaan, joka auttaa toimitusjohtajia työskentelemään fiksummin, toimittamaan nopeammin ja johtamaan paremmin tekoälyn aikakaudella. Olen Galen, ja joka viikko perehdymme käytännön strategioihin, uusiin työkaluihin, hyväksi havaittuihin viitekehyksiin ja toisinaan myös projektirintaman tositarinoihin. Johdatpa sitten valtavia muutoshankkeita, hallitset tekoälytyönkulkuja tai yrität vain pitää kaaoksen kurissa, olet oikeassa paikassa. Aloitetaan.

Tänään puhumme tuotepäällikön tulevaisuudesta, siitä mitä tekoälytuotteiden kehittäminen vaatii, miten tekoälyä käytetään tuotekehitys- ja julkaisuprosessin tehostamiseen sekä siitä, mitä tiiminvetäjät voivat tehdä, kun heidän tuotetiimeissään on epätasainen osaaminen ja suhtautuminen tekoälyn kaltaisiin uusiin teknologioihin.

Studiossa kanssani on tänään Jyothi Nookula. Jyothilla on yli 13 vuoden kokemus tekoälytuotteiden ja -alustojen innovaatioiden edistämisestä Netflixin, Metan, Amazon AWS:n ja Etsyn kaltaisissa yrityksissä. Hänellä on myös 12 koneoppimiseen liittyvää patenttia, ja koulutusyrityksensä Next Gen Product Managerin kautta hän on mentoroinut yli 1 500:aa tuotepäällikköä heidän siirtyessään tekoälyrooleihin.

Jyothi, kiitos paljon, että olet kanssani tänään.

Jyothi Nookula: Hei kaikille. On todella hienoa olla täällä tänään.

Galen Low: Olen aivan yhtä innoissani, ja olen odottanut tätä jo viikkoja. Kun keskustelimme ensimmäisen kerran ja tutustuin profiiliisi, ajattelin: vau, Jyothi on todellinen voimanpesä. Profiilissasi on paljon brändejä ja teknologioita, joita voi vain ihailla.

Olen myös aina niiden ihmisten kannattaja, jotka yrittävät auttaa minkä tahansa alan seuraavaa sukupolvea kehittymään yhä teknologisemmaksi ja nyt myös tekoälyyn suuntautuvassa maailmassa. Kun keskustelimme, ajattelin, että meillä on niin paljon yhteistä. Minä työskentelen projektien parissa, sinä enemmän tuotteiden parissa. Olen todella innostunut sukeltamaan siihen, miten asiat muuttuvat ja mitä olet oppinut tekoäly- ja koneoppimistuotteiden parissa.

Tiedän, että saatamme ajautua keskustelun aikana sivupoluille, jotka ovat erittäin kiinnostavia ja arvokkaita, ja toivon, että niin käy. Projektipäällikkö minussa laati meille kuitenkin tämän päivän etenemissuunnitelman. Halusin aloittaa yhdestä suuresta ja polttavasta kysymyksestä, siitä hieman epämukavasta mutta kiireellisestä kysymyksestä, johon uskon kaikkien haluavan vastauksen.

Sen jälkeen haluaisin tarkastella kolmea asiaa. Ensinnäkin haluaisin puhua tuotetiimien osaamisvajeiden tunnistamisesta ja paikkaamisesta. Kun käsitellään tuotteita, joissa hyödynnetään tekoäly- ja koneoppimisominaisuuksia, haluaisin tarkastella esimerkkejä tavoista, joilla tiimisi ovat käyttäneet tekoälytyökaluja tuotekehitysprosessissa – tutkimuksessa, data-analyysissä, suunnittelussa, ohjelmistokehityksessä, käyttäjätestauksessa tai jossain aivan muussa.

Lopuksi haluaisin pohtia, miltä tuotepäällikön roolin tulevaisuus näyttää. Mitä ansioluettelossa tai portfoliossa täytyy olla, jotta henkilöä edes harkitaan Metan, AWS:n, Netflixin, Etsyn ja muiden merkittävien tekoälyyn suuntautuneiden brändien tehtäviin?

Jyothi Nookula: Pidän siitä. Olen mukana. Tämä on tällä hetkellä kuuma aihe. Rakastan sitä.

Galen Low: Hienoa. Aloitetaan tuosta suuresta kysymyksestä. Kysymykseni, jolla haluan kehystää tämän kaiken, liittyy tekoälyyn. Sinulla on paljon kokemusta työskentelystä tuotetiimien kanssa tekoälyyn ja koneoppimiseen perustuvien ratkaisujen kehittämisessä Metan, Amazonin, Etsyn ja Netflixin kaltaisille jättiläisille. Onko tekoälyn natiivitoiminnallisuutta sisältävän tuotteen kehittämisprosessissa todella jotain niin erilaista verrattuna muihin tuotteisiin, jotka vain sattuvat hyödyntämään olemassa olevaa tekoälyteknologiaa?

Jyothi Nookula: Se on erinomainen kysymys, koska se osuu suoraan siihen, mikä tuotekehityksessä todella muuttuu juuri nyt. Rehellinen vastaus on pohjimmiltaan kyllä, mutta ei sillä tavalla kuin ihmiset yleensä ajattelevat. Kun rakennat tekoälyn natiivituotetta, kohtaat kolme asiaa, jotka eroavat perinteisestä ohjelmistosta tai tuotteista, jotka vain yhdistyvät tekoälyyn rajapinnan kautta.

Ensimmäinen asia on se, että tekoäly on pohjimmiltaan ennalta arvaamatonta. Perinteisessä tuotekehityksessä kirjoitat determinististä koodia: jos tämä tapahtuu, tee tuo. Tai jos napsautan tätä painiketta, siirry seuraavaan näkymään. Joka kerta, kun napsautan painiketta, tapahtuu sama asia. Tekoälyn natiivituotteissa työskentelet kuitenkin todennäköisyysperusteisten järjestelmien kanssa, joten tekoälyominaisuus saattaa toimia eri tavalla joka kerta, kun se suoritetaan.

Tämä tarkoittaa, että koko laadunvarmistusprosessisi, poikkeustilanteiden käsittelysi ja luotettavuustakuusi on ajateltava kokonaan uudelleen. Et testaa vain sitä, toimiiko jokin, vaan sitä, toimiiko se riittävän hyvin ja johdonmukaisesti joka kerta erilaisten lopputulosten joukossa.

Se on ensimmäinen perustavanlaatuinen ero: ennalta arvaamattomuus sekä deterministisen ja todennäköisyysperusteisen toiminnan välinen ero. Toinen asia on se, että rakennat tuotteita jatkuvasti muuttuvalla perustalla, koska taustalla olevat mallit kehittyvät tavoilla, joita et voi hallita. Uusi malli saattaa esimerkiksi muuttaa toimintaa.

Muutos ei välttämättä riko mitään, mutta se voi muuttaa käyttäytymistä hieman, laajentaa ominaisuuksia tai tuoda mukanaan uusia virhetilanteita. Näitä muutoksia tapahtuu yön yli nykyisellä kehitysvauhdilla. Toisin kuin perinteisissä riippuvuuksissa, joissa voit hallita rikkovia muutoksia versionhallinnalla ja dokumentoida päivitykset, mallipäivitykset muuttuvat nopeammin kuin ehdimme pysyä niiden perässä.

Kolmas, ja tämä on merkittävä asia, on se, että onnistumisen mittareiden on oltava erilaisia. Et voi enää mitata vain sitä, suoritettiinko ominaisuus onnistuneesti. Sinun on mitattava esimerkiksi sitä, oliko tulos hyödyllinen. Ei vain sitä, suoritettiinko toiminto, vaan oliko siitä hyötyä.

Vastasiko tulos käyttäjän tarkoitusta? Käyttäjän esittämään kysymykseen? Ja miten edes määrittelet hyvän lopputuloksen omassa käyttötapauksessasi? Siksi tarvitset paljon tiiviimmän palautesilmukan käyttäjiesi kanssa ja sinun on rakennettava nämä arviointimekanismit suoraan osaksi tuotekehitystä. Se eroaa suuresti perinteisestä tuotekehityksestä.

Nämä ovat siis kolme merkittävää eroa. Jos tuotteeseen vain liitetään olemassa oleva tekoäly, esimerkiksi ChatGPT, integraatio voi silti olla perinteisen kaltainen. Sinulla on edelleen onnistumisen mittareita ja arviointeja, joita on seurattava.

Tällöin sinulla on kuitenkin ainakin sopimus. Kun taas rakennat tuotteen alusta alkaen tekoälyn natiivituotteeksi, tilanne on täysin erilainen. Silloin nämä kolme asiaa vaikuttavat tuotekehitykseesi vielä enemmän.

Galen Low: Onpa hauskaa, koska ennen tätä kysymystä ajattelin, että vastaan tulee ehkä vastaus: kyllä, se on suurin piirtein sama asia muutamaa pientä eroa lukuun ottamatta. Mutta tämä muuttaa pelin täysin.

Pidin erityisesti siitä, mitä sanoit tarkoituksen ja mittaamisen mittaamisesta. Minä tulen projektimaailmasta, jossa meillä on vaatimusten määrittely. Se on binäärinen: kyllä tai ei. Tekikö järjestelmä sen, mitä toiminnallisessa määrittelyssä sanottiin? Mutta mukana on valtavasti epäselvyyttä. Ensinnäkin siksi, että kyse on todennäköisyysperusteisesta toiminnasta eikä lopputulos ole aina sama.

Toiseksi taustalla oleva arkkitehtuuri on tavallaan musta laatikko, joka kehittyy itsenäisesti joka päivä nopeammin kuin ihmiset pystyvät ymmärtämään. Se on oikeastaan hyvin erilaista verrattuna siihen, miten useimmat digitaaliset tuotteet on lähihistoriassa rakennettu.

Sinulla on yli vuosikymmenen kokemus koneoppimisesta ja tekoälystä. Monet ovat aloittaneet vasta viimeisten kahden vuoden aikana. ChatGPT raotti ovea siihen, miten tekoälyä voidaan käyttää, mutta sitä on ollut ohjelmistoissa ja digitaalisissa tuotteissamme jo jonkin aikaa.

Netflixissä näkemäni suositukset näyttävät hyvin yksinkertaisilta, mutta ne eivät varmasti ole sitä. Taustalla oleva algoritmi, koneoppiminen ja datankäsittely eivät perustu vain siihen, että kaikki Netflixin sisältö on luokiteltu tietyn taksonomian mukaan. Kyse ei ole verkkosivuston liittyvistä linkeistä.

Kyse on käyttäytymisestä ja tarkoituksesta, ja ne on helppo tulkita väärin. Voi olla, ettet edes huomaa, kuinka väärässä järjestelmä on, ennen kuin joku julkaisee viestin: ”Voi luoja, Netflixini ei koskaan ymmärrä minua, koska katsoin tämän, ja nyt se suosittelee minulle 18 tuotantokautta Barneya.”

Jyothi Nookula: Sama tapahtuu koko ajan Instagram Reelsissä ja TikTokissa. Katson yhden hiihtovideon ja sen jälkeen saan valtavan määrän hiihtovideoita.

Galen Low: Pidämme tätä helposti itsestäänselvyytenä. Voisi olla helppoa ajatella, että kyse on melko yksinkertaisesta asiasta ja samasta osaamisesta kuin ennenkin. Kun sen kuitenkin purkaa tällä tavalla, asia ei olekaan niin yksinkertainen.

Voisimmeko hieman loitontaa näkökulmaa? Amazonin, Metan, Netflixin ja Etsyn kaltaisten brändien digitaalisten tuotteiden johtamisen lisäksi olet Next Gen Product Managerin perustaja. Sen tarjontaan kuuluu muun muassa noin viiden viikon koulutus, jossa siirrytään perinteisestä tuotepäällikön työstä tekoälytuotepäälliköksi.

Se, että tällainen kurssi on olemassa, kertoo minulle, etteivät kaikki perinteiset tuotepäällikön taidot enää riitä. Tarvitaan uuden sukupolven tai tulevaisuuteen suuntautuvaa ajattelutapaa ja osaamista. Vaikka olisit saanut urasi aikana valita tiimisi itse, on perusteltua olettaa, etteivät kaikki tiimisi jäsenet ole olleet tekoälyn ja muiden uusien teknologioiden suhteen täsmälleen samalla osaamisen ja asenteen tasolla.

Mikä on ensimmäinen asia, jonka teet johtajana, kun huomaat, etteivät kaikki tiimin jäsenet ehkä ole samalla tasolla ymmärtäessään, hyödyntäessään tai edes hyväksyessään tekoälyn kaltaisia uusia teknologioita?

Jyothi Nookula: Tämä on hyvin käytännöllinen ja todellinen haaste, jota olen kohdannut paljon ja kohtaan jatkuvasti. Olen johtanut ihmisiä ja erikokoisia tiimejä kolmesta viiteen, kymmeneen ja kahteentoista henkilöön. Olen nähnyt koko kirjon. Tekoälyyn liittyvä osaamis- ja mukavuuskuilu on suurin, jonka olen urani aikana kohdannut minkään teknologian tai muutoksen yhteydessä.

Kun kohtaan tämän ongelman, jaan sen ensin kahdeksi erilliseksi asiaksi. Ensimmäinen on osaaminen: ihmiset eivät tiedä, miten tekoälyn kanssa työskennellään tehokkaasti. Toinen on suhtautuminen: ihmiset ovat epäileviä, vastahakoisia tai jopa ahdistuneita.

On selvitettävä, kummasta näistä on kyse. Ehkä kyse on molemmista. On kuitenkin tärkeää tunnistaa, mitä ongelmaa yrität ratkaista, koska jos käsittelet suhtautumisongelmaa osaamisongelmana, pahennat sitä vain.

Osaamisvajeiden kohdalla ensimmäinen liikkeeni on luoda yhteinen ymmärrys tekemisen, ei opiskelun, kautta. Tämä on sama periaate, jota opetan myös viiden viikon tekoälytuotehallinnan kurssillani: oppiminen tapahtuu tekemällä.

En lähetä ihmisiä koulutukseen tai pyydä heitä katsomaan opetusvideoita. Sen sijaan upotan tekoälyn välittömästi todellisiin työnkulkuihimme. Integroimme Clauden tai GPT:n esimerkiksi sprintin retrospektiivien kirjoittamiseen, teemojen kokoamiseen, syvälliseen tutkimukseen tai käyttäjätutkimuksen yhteenvetojen laatimiseen.

Tärkeää on, että ihmiset näkevät työkalun tekevän heille oikeaa työtä, eivätkä koe sen korvaavan heitä. Parin viikon kuluttua kysyn kokouksessa: ”Kertokaa jokin asia, jonka tekoäly auttoi teitä tekemään nopeammin” tai ”Kertokaa jokin oivallus, jota ette olisi huomanneet ilman tekoälyä.” Näistä yhteisistä kokemuksista tulee perusta osaamisen rakentamiselle yhdessä.

Suhtautumisongelmissa, jotka liittyvät vastustukseen tai pelkoon, paras tapa on mielestäni johtaa uteliaisuudella, ei julistamisella. Kahdenkeskisissä keskusteluissa kysyn yleensä: ”Mikä sinua tässä oikeasti huolestuttaa?” Sitten olen hiljaa ja kuuntelen.

Keskusteluissa esiin tulevat huolet ovat yleensä perusteltuja. Ihmiset sanovat esimerkiksi: ”Minusta tuntuu, että tämä vähättelee ammattitaitoani”, ”En luota tuloksiin, koska en pysty tarkistamaan niitä täysin” tai ”Minusta tuntuu, että jään jälkeen ja tämä on ylivoimaista.” Nämä ovat todellisia huolia.

Olen oppinut, ettei ketään voi järkeillä ulos pelosta. Sen sijaan pelko on tunnustettava, normalisoitava ja ihmiselle on näytettävä tie eteenpäin.

Jos joku pelkää työnsä arvon vähenevän, näytän, miten tekoäly voi hoitaa rakenteen ja valmistelun, jolloin ihminen voi keskittyä vivahteikkaaseen ja paljon harkintaa vaativaan työhön, johon hänellä ei aiemmin ollut aikaa. Jos joku on huolissaan tulosten tarkistamisesta, sanon: ”Hyvä on, rakennetaan arviointikehykset yhdessä.” Näin hänestä tulee tekoälyn laadunvarmistuksen asiantuntija.

Toinen erittäin tehokas keino on tunnistaa välittäjähenkilöt. Jokaisessa tiimissä on ihmisiä, jotka ovat luonnostaan uteliaita tekoälyn suhteen, kokeilevat sitä jatkuvasti, ovat käytännöllisiä ja saavat tuloksia aikaan.

Annan näille ihmisille luvan kertoa avoimesti, mikä toimii. Stand-up-kokouksissa voidaan järjestää lyhyitä tiedonjakotuokioita. Tämä luo vertaisten välistä oppimista. Kun ihmiset näkevät kollegansa ottavan työkalun käyttöön ja saavan sillä tuloksia, he ovat avoimempia kokeilemaan sitä kuin silloin, jos johtaja vain käskee heitä tekemään niin ylhäältä alaspäin.

Viimeinen asia saattaa olla hieman kiistanalainen: siirryn nopeasti siihen, että tekoälyn käyttötaito on perustason odotus. Olen empaattinen oppimiskäyrää kohtaan ja kärsivällinen prosessin suhteen, mutta olen selkeä suunnasta. Tämä ei ole vapaaehtoista. Aivan kuten meidän kaikkien piti oppia ketteristä prosesseista, analytiikasta ja suunnittelusta, tekoäly kuuluu nyt työhön.

Olen huomannut, että vahvan tuen yhdistäminen korkeisiin vaatimuksiin vähentää ahdistusta. Eniten vaikeuksia kohtaavat tiimit, joiden johtajat ovat epäselviä odotusten suhteen eivätkä tarjoa todellista tukea. Silloin syntyy katkeruutta ja avuttomuutta.

Tavoitteena ei ole saada kaikkia heti samalle tasolle, vaan saada kaikki etenemään samaan suuntaan psykologisesti turvallisessa ympäristössä ja käytännöllisten työkalujen avulla.

Galen Low: Pidän tuosta todella paljon. Erityisesti erottelusta osaamisen ja suhtautumisen välillä. Tätä kuunnellessani ajattelin, että kyse on lähes muutosjohtamisen ja tiiminrakentamisen yhdistelmästä reaaliajassa.

Meillä on taipumus ajatella muutosjohtamista asiana, jota tehdään kerran suuren muutoksen käyttöönoton yhteydessä. Tämä on pikemminkin päivittäistä, jatkuvaa muutosjohtamista tiimin kanssa. Kun tiimiä tuetaan eikä vain käsketä opiskelemaan asiaa itsenäisesti, rakennetaan samanaikaisesti tiimin yhteistä osaamista ja suhtautumista.

Tiedon ja kokemusten jakaminen tekee lähestymistavasta hieman tasaisemman ja ruohonjuuritason. En halua sanoa vertaispainetta, vaan vertaistukea. Ja pidän siitä, mitä sanoit tekoälyyn liittyvistä oikeutetuista huolista: jälkeen jäämisen tunteesta, ajan puutteesta ja siitä, että oma ammattitaito menettää arvoaan.

On vaikea löytää parempaa tietä eteenpäin kuin nähdä vertaisten käsittelevän näitä huolia käytännössä omassa päivittäisessä työssään. Ei vain teoriassa, vaan tekemällä yhdessä. Olen itse suuri tekemällä oppimisen kannattaja, joten olen iloinen, että se on myös osa opetustapaasi.

Jyothi Nookula: Niin.

Galen Low: Mainitsit pienet kokeilut ja pilottihankkeet, joiden avulla ihmiset pääsevät käytännössä käyttämään tekoälyä ja rakentamaan osaamistaan sekä itseluottamustaan. Ymmärrän, että tekoälyn käyttömahdollisuudet ovat hyvin laajat myös sellaisten tuotteiden kehittämisessä, jotka ovat itsessään tekoälytuotteita.

Voisitko antaa esimerkkejä muista tavoista, joilla tiimisi ovat käyttäneet tekoälyä tuotteiden suunnittelussa ja kehittämisessä?

Jyothi Nookula: Voin antaa konkreettisia esimerkkejä koko tuotteen kehityskaarelta.

Galen Low: Hienoa.

Jyothi Nookula: Aloitetaan löytämisestä ja tutkimuksesta. Tekoälyä voidaan käyttää oivallusten tuottamisen nopeuttamiseen merkittävästi. Teemme normaalisti paljon käyttäjätutkimusta, esimerkiksi 15–20 haastattelua. Sen sijaan, että käyttäisimme viikon teemojen tunnistamiseen, syötämme litteroinnit Claudeen ja pyydämme sitä tunnistamaan malleja, ristiriitoja ja poikkeustapauksia.

Tärkeää on, ettei tulosta hyväksytä sellaisenaan. Tutkija tarkistaa sen, haastaa sen ja täsmentää sitä. Ihminen prosessissa on erittäin tärkeä. Tekoäly tarjoaa vahvan ensimmäisen luonnoksen tunnissa viikon sijaan. Tutkija voi käyttää aikansa vaativaan harkintaan: mitkä havainnot todella merkitsevät, mikä haastaa oletuksemme ja mitä meidän pitäisi tutkia seuraavaksi.

Sama pätee tukipyyntöihin. Jos tuote on jo markkinoilla, tukipyyntöjen määrä on aina valtava. Sen sijaan, että tarkastelisimme niitä manuaalisesti löytääksemme toistuvia aiheita, voimme analysoida tuhansia asiakastukikeskusteluja ja tunnistaa kipukohdat, niiden laajuuden ja vaikutuksen.

Tekoäly nostaa esiin malleja tavalla, johon emme pystyisi manuaalisesti pelkän aineiston määrän vuoksi. Tuotepäällikkönä näet käyttäjätutkimuksen ja tukipyyntöjen määrälliset mallit, joten pystyt paremmin päättämään, mitä pitää korjata ja mitkä ominaisuudet pitäisi priorisoida tiekartalla.

Tekoäly vähentää myös dokumentoinnin ja viestinnän rutiinityötä. Olemme nähneet ihmisten käyttävän tekoälyä tuotevaatimusdokumenttien kirjoittamiseen, suunnittelukatselmusten yhteenvetojen laatimiseen ja sidosryhmäpäivitysten luomiseen.

Tekoäly voi tuottaa vahvoja ensimmäisiä luonnoksia. Eräs tuotepäälliköistäni sanoi: ”Käytin ennen 30 prosenttia ajastani dokumentoinnin kirjoittamiseen. Nyt käytän 30 prosenttia ajastani dokumentoinnin muokkaamiseen ja viimeistelyyn.” Se on paljon arvokkaampaa, koska käytössä on hyvä lähtökohta.

Käytämme tekoälyä myös dokumentoinnin saavutettavuuden parantamiseen. Joku voi kysyä: ”Mitä päätimme tästä maksuprosessin uudistamisesta?” ja saada vastauksen, joka on koottu kolmesta eri keskusteluketjusta, kahdesta kokouksesta ja tuotevaatimusdokumentista.

Tuotekehityksen koko elinkaaren ajan – kokeiluista dokumentointiin ja yhteistyöhön ohjelmistokehityksen kanssa – tekoäly muuttaa työtapaa. Tuotepäälliköt omistavat ja kirjoittavat edelleen tuotevaatimusdokumentteja, eivätkä ne ole katoamassa. Niihin tulee kuitenkin uusi prototyyppien osa.

Miksi antaa vain lista käyttäjätarinoita, kun voit kokeilla ideaa ja tehdä siitä prototyypin? Voit saada alustavan käsityksen tuotteen sopivuudesta markkinoille ja antaa prototyypin ideana ohjelmistokehitystiimille.

Uudenlainen tuotevaatimusdokumentti kuvaa vision, arvioinnit, toiminnan, ajoituksen sekä sen, miltä hyvä ja huono lopputulos näyttävät. Prototyyppi taas kuvaa vuorovaikutuksen, käytettävyyden ja sen, miten tuote pitäisi kuvitella.

Galen Low: Pidän siitä, että toit keskustelun tähän. Keskustelin juuri hiljattain joidenkin tuotetyön ammattilaisten kanssa siitä, ovatko tuotevaatimusdokumentit kuolleet.

Eräs keskustelukumppanini sanoi, etteivät ne ole, koska ajatusten täytyy edelleen olla olemassa ja niiden täytyy olla hyviä. Hän oli rakentanut pienen sovelluksen, joka auttaa muodostamaan hyviä ajatuksia, perustelemaan tuotteen sopivuutta markkinoille sekä määrittämään ominaisuudet ja prioriteetit.

Sen jälkeen ajatus yhdistetään prototyyppiin. Vision täytyy edelleen olla olemassa. Tekoäly ei keksi kaikkia luovia vastauksia itsestään, eikä se yksin riitä. Tuotteen tarkoituksesta, käyttäjien tarpeiden palvelemisesta ja markkinoille viennistä tarvitaan edelleen strateginen näkemys.

Pidän myös ajatuksesta, että jonkun työ muuttuu. Monet tuotepäälliköt ovat tehneet dokumentointipainotteista työtä, ja siitä tulee nyt eräänlainen supervoima, koska suurin osa ajasta voidaan käyttää muokkaamiseen. Dokumentointi oli kuitenkin jo ennestään osa prosessia, joten tekoäly voidaan kouluttaa sen avulla.

Ihmiset, jotka eivät aiemmin kirjoittaneet mitään muistiin, joutuvat nyt dokumentoimaan voidakseen hyötyä tekoälystä. Tavallaan tuotepäälliköt ovat etulyöntiasemassa. Pidän ajatuksesta, että tekoäly toimii ensimmäisten luonnosten koneena.

Onko tiimisi tapana käyttää ensimmäistä luonnosta ja siirtyä sitten ketjun muihin vaiheisiin, vai syöttävätkö he muokkauksensa takaisin järjestelmään, jotta ensimmäiset luonnokset paranevat jatkuvasti?

Jyothi Nookula: Kutsumme tätä yhden kierroksen toimintatavaksi. Ihmiset olettavat, että tekoälyn käyttö on kertaluonteista: annat sille aineiston, saat raportin ja toimit sen perusteella. Näin käy harvoin.

Yleensä saat vahvan ensimmäisen luonnoksen, jonka jälkeen lisäät omat ajatuksesi ja pyydät tekoälyä kritisoimaan näkemyksiäsi tai osoittamaan alueita, joita voisi parantaa. Sitten arvioit tulosta ja sanot: ”Tämä osa on järkevä, mutta tästä toisesta kohdasta olen eri mieltä.” Se on kuin työskentelisit kumppanin kanssa, jota voit jatkuvasti ohjata, kunnes lopputulos tuntuu hyvältä.

Jos käsittelet tekoälyjärjestelmiä niin, että annat niille jotain, saat yhden vastauksen ja toimit sen mukaan, se toimii harvoin. Arvo paranee iteratiivisen työskentelyn myötä. Siksi sanomme, että tekemistä on helppo opettaa, mutta makua on vaikea opettaa. Tuotepäällikön on edelleen omistettava arviointikyky.

Galen Low: Pidän tuosta ajatuksesta. Tuntuuko monista siltä, että 30 prosenttia heidän työstään ei enää ole vain dokumentoinnin muokkaamista vaan myös robotin kanssa keskustelemista?

Tuotepäällikön työssä on paljon inhimillistä: käyttäjähaastatteluja ja tutkimusta. Käytössä voi olla valtava määrä dataa, jota ihminen ei pysty yksin käsittelemään, ja tekoäly voi auttaa siinä. Tuntuuko sinusta, että tuotepäällikön työstä katoaa inhimillisyys?

Ehkä yksi huoli on se, että suurin osa ajasta kuluu robotin kanssa keskustelemiseen ja sen opettamiseen, eikä se tunnu samalta kuin ihmisen kanssa puhuminen.

Jyothi Nookula: En tiedä, onko kyse niinkään robotin kanssa puhumisesta. Jos vain sinä ja tekoälyjärjestelmä keskustelette, tilanne on erilainen.

Sinun on edelleen vakuutettava sidosryhmät, keskusteltava ohjelmistokehitystiimin kanssa ja yhdistettävä eri tiimit. Tuotepäällikkö on keskiössä ja yhdistää erilaisia ryhmiä. Tekoäly on enemmänkin hyödyllinen avustaja, jonka kanssa voi ideoida.

Olen nähnyt tuotepäälliköideni, johtajieni ja kollegoideni käyttävän sitä juuri näin. He puhuvat sen kanssa ideoidakseen. Kyse ei ole niinkään robottimaisesta toiminnasta, vaan siitä, että tekoäly auttaa alkuun ja asioiden selvittämisessä. Käytettävissä on jatkuvasti kumppani, jonka kanssa voi keskustella.

Galen Low: Leikitään hetki paholaisen asianajajaa. Olet työskennellyt paikoissa, joissa joku on varmasti tullut luoksesi ja kysynyt: ”Jyothi, miksemme voisi vain automatisoida tätä prosessia?”

Miksi prosessissa täytyy olla ihminen? Emmekö voisi kerätä kaikki tukipyynnöt, ajaa ne tekoälyagentin läpi, antaa sen priorisoida uudet ominaisuudet, kehittää ominaisuudet ja julkaista ne ilman, että kukaan osallistuu?

Miten vastustat teknologia ensin -lähestymistapaa ihmislähtöisen tai käyttäjälähtöisen lähestymistavan sijaan, erityisesti suurissa teknologiayrityksissä, joissa on paine käyttää teknologiaa ensin ja miettiä sen käyttötarkoitusta myöhemmin?

Jyothi Nookula: Tämä on asia, johon törmään usein myös konsultoidessani yrityksiä ja opiskelijoiden kanssa. Tällä hetkellä vallitsee eräänlainen sairaus: kaikki haluavat aloittaa tekoälystä. Hyvässä tai pahassa unohdamme käyttäjät ja heidän ongelmansa ja aloitamme teknologiasta, mikä on hyvin epäintuitiivista.

Vastustaminen on vaikeaa, koska organisaation kannustimet osoittavat väärään suuntaan. Johtajat ovat lukeneet samat artikkelit tekoälyn mullistavuudesta, sijoittajat kysyvät jokaisessa tulospuhelussa tekoälystrategiasta ja ohjelmistokehittäjät ovat aidosti innostuneita.

Sanon aina, että on palattava tuoteajattelun perusperiaatteisiin ja aloitettava käyttäjästä sekä ongelmasta algoritmin sijaan. Opetan tätä myös kursseillani: käyttäjät ennen algoritmeja.

Kun joku tulee innostuneena kertomaan uudesta tekoälyominaisuudesta, en sano suoraan ei. Muotoilen asian uudelleen: ”Tuo on kiinnostava teknologia. Minkä ongelman yritämme ratkaista sen avulla?” Pyydän heitä kuvaamaan ongelman, en ansaitakseen heille ansaa, vaan jotta he todella tarkastelisivat käyttäjän päivää.

Missä tämä sopii käyttäjän elämään? Mitä käyttäjä yrittää tällä hetkellä tehdä? Mikä on vaihtoehto, jos tätä ei ole?

Yleensä tapahtuu yksi kolmesta asiasta. Ensinnäkin he ymmärtävät, että kyseessä on ratkaisu, joka etsii ongelmaa. Innostus hiipuu luonnostaan, koska vakuuttavaa käyttäjätarvetta ei pystytä kuvaamaan.

Toiseksi he saattavat huomata, että ongelma on todellinen, mutta tekoäly ei ole siihen paras ratkaisu. Ongelma voidaan ratkaista paremman käyttökokemuksen, perehdytyksen, prosessin korjaamisen tai yksinkertaisemman deterministisen teknologian avulla.

Kolmas vaihtoehto on paras: he löytävät todellisen ongelman, jossa tekoäly mahdollistaa jotain uutta. Silloin syntyy todellista innovaatiota.

Amazonissa käytämme tunnetusti takaperin työskentelyn prosessia, jossa kirjoitetaan lehdistötiedote. Pyydän tuotepäälliköitä tai kollegoita kirjoittamaan tuotteesta lehdistötiedotteen, jossa kuvataan tuotteen vaikutus ja lisätään mahdollisesti käyttäjän lausunto. On vaikeaa teeskennellä jotain hämmästyttäväksi, kun asiaa tarkastellaan tämän harjoituksen kautta.

Jos päätös tulee ylhäältä, esimerkiksi teknologiajohtajalta, sitä vastaan on vaikea taistella. Silloin muotoilen asian uudelleen: ”Hyvä on, jos aiomme tehdä tämän, tehdään se ainakin hyödyllisellä tavalla.” Etsitään todellinen ongelma, jonka voimme ratkaista, sen sijaan että taistelisimme tietystä käyttötapauksesta.

Olen urani alussa ajatellut, että tehtäväni oli suojella tuotteen visiota häiriötekijöiltä. Nyt ymmärrän, että tehtäväni on suunnata energiaa: ottaa uusiin teknologioihin liittyvä innostus ja ohjata se kohti käyttäjille merkityksellisiä lopputuloksia.

Galen Low: Missä Clippy on silloin, kun tarvitsemme häntä? Tämä oli todellinen mestarikurssi tuotepolitiikan navigointiin. Pidän erityisesti näkemyksestäsi roolin suhteen.

Monet tuotetyön ammattilaiset kokevat olevansa portinvartijoita ja puolustajia, joiden tehtävänä on estää huonot ideat ja pitää kiinni alkuperäisestä tavoitteesta. Pidän kuitenkin ajatuksesta, että energiaa suunnataan, koska siitä voi seurata hyviä asioita.

Ajatus ”jos teemme tämän, tehdään se ainakin hyödyllisesti” on raikas. Kaikissa tilanteissa ei anneta valinnanvaraa, eikä aina tarvitse vain odottaa kirjallista päätöstä voidakseen myöhemmin sanoa ”minähän sanoin”. Toimintatavasta voi tehdä rakentavan.

Ihmiskeskeisen suunnittelun taustani vuoksi on hienoa kuulla keskustelua, jossa asia tuodaan aina takaisin käyttäjään ja käyttäjähyötyyn. Kysymys ”Minkä ongelman yritämme ratkaista?” on lempeä mutta tehokas tapa saada ihmiset ajattelemaan yhdessä.

Ja se lehdistötiedoteidea – aion ehdottomasti ottaa sen käyttöön. Takaperin työskentelyä tehdään usein, mutta harvoin viedään lehdistötiedotteen tasolle. Se on erinomainen tapa kuvata, mitä tehtiin, miksi se tehtiin ja mikä vaikutus sillä on. Se auttaa ajattelemaan lopputulosta pelkän julkaisun sijaan.

Jyothi Nookula: Pidän todella paljon lehdistötiedotteen ideasta. Olen käyttänyt sitä aina, myös lähdettyäni AWS:stä vuosia sitten. Käytän sitä edelleen työssäni, koska se tuo keskusteluun tärkeän näkökulman.

Galen Low: Se on erittäin hyödyllinen.

Voisimmeko lopuksi puhua hieman tulevaisuudesta? Tämän keskustelun aikana on käynyt selväksi, että tuotepäällikön työ muuttuu nopeasti. Tuotteet, työkalut ja menetelmät muuttuvat, samoin teknisen ymmärryksen, liiketoimintaymmärryksen ja toimitusstrategian odotukset.

Mitkä ovat kolme tai neljä tärkeintä asiaa, jotka tekoälytuotteiden kehittämisestä kiinnostuneen tuotepäällikön pitäisi tuoda esiin ansioluettelossaan tai portfoliossaan erottuakseen?

Jyothi Nookula: Kiitos, että kysyit tämän kysymyksen. Se on hyvin käytännöllinen, ja rehellisesti sanottuna se, mitä etsin ansioluettelosta, on muuttunut huomattavasti kahden viime vuoden aikana.

Ensimmäinen asia on näyttö tekoälyä hyödyntävän tuotteen rakentamisesta, ei vain siitä puhumisesta. Rekrytoivana johtajana haluan nähdä, että olet todella julkaissut tekoälyn natiivin ominaisuuden tai tuotteen.

En halua nähdä vain väitettä, että olet työskennellyt tekoälyä käyttävässä tiimissä tai osallistunut strategiaan. Haluan tietää, minkä ongelman ratkaisit, mitä tekoäly oikeasti teki, miten arvioit sitä ja mitkä havainnot yllättivät sinut.

Jos et ole vielä julkaissut tekoälytuotetta, rakenna sellainen itse. Opetan tätä myös kursseillani, joissa tehdään paljon käytännön projekteja ja rakennetaan kokonainen portfolio.

Älä kuitenkaan jätä tuotetta pelkäksi projektiksi. Älä sulje tietokonetta työn valmistuttua ja siirry eteenpäin. Muuta projekti tuotteeksi: jaa se ystävillesi ja yhteisöllesi, anna heidän käyttää sitä, pyydä palautetta ja kehitä tuotetta palautteen perusteella.

Voit jopa lisätä Stripe-maksutavan ja veloittaa dollarin tai 50 senttiä. Tee siitä tulosta tuottava tuote, jos se sopii tuotteeseesi. Mitä lähemmäksi oikeaa tuotetta pääset, sitä enemmän se vaikuttaa ansioluetteloosi verrattuna siihen, että vain kerrot työskennelleesi tekoälyprojektissa.

Toinen tärkeä asia on teknisen sujuvuuden osoittaminen. Sinun ei tarvitse olla koneoppimisinsinööri, eikä sinun tarvitse osata ohjelmoida. Haluan kuitenkin nähdä, että pystyt keskustelemaan uskottavasti ohjelmistokehittäjien kanssa siitä, miten nämä järjestelmät toimivat.

Ansioluettelossa tämä voi näkyä esimerkiksi käyttäminäsi arviointikehyksinä, laajempana testaamisena ja navigoimiesi kompromissien kuvaamisena: viiveen ja laadun, kustannusten ja kyvykkyyden tai eri mallityyppien ja arkkitehtuurien välillä.

Käyttämäsi kieli on tärkeää. Jos ansioluettelossasi lukee ”hyödynsin tekoälyä käyttäjäkokemuksen parantamiseen”, se ei kerro minulle juuri mitään. Jos taas kirjoitat rakentaneesi RAG-arkkitehtuurin vähentämään asiakastukivastausten hallusinaatioita ja parantaneesi tarkkuutta luvusta X lukuun Y, ymmärrän, mitä olet rakentanut.

Kysyn yleensä, pystytkö selittämään ohjelmistokehittäjälle, miksi tekniikkaa A pitäisi käyttää tekniikan B sijaan tietyssä käyttötapauksessa. Pystytkö samalla selittämään liiketoiminnan sidosryhmälle, miksi tekninen päätös on tärkeä ja miten se vaikuttaa liiketoiminnan lopputuloksiin?

Tuotepäällikkö toimii näiden asioiden risteyksessä. Hänen tärkein tehtävänsä on muuttaa tekniset mahdollisuudet liiketoiminnan tuloksiksi ja arvoksi sekä kääntää liiketoimintatarpeet takaisin teknisiksi viitekehyksiksi.

Viimeinen asia on kyky navigoida epäselvyyttä ja nopeaa iteraatiota. Tekoälytuotteet ovat erilaisia. Mallit päivittyvät ja kyvykkyydet kehittyvät, joten epäselvyyden kanssa on oltava sinut. Sen pitäisi näkyä ansioluettelossasi.

Jos kerrot julkaisseesi nollasta yhteen -tuotteita tai työskennelleesi nopeasti muuttuvissa ympäristöissä, se kertoo, että olet joutunut käsittelemään epäselvyyttä. Myös kokeileva ajattelutapa, nopea prototypointi, testaaminen ja oppiminen ovat tärkeitä.

En etsi muotisana-soppaa. En tarvitse ihmistä, joka kirjoittaa ”hyödynsin koneoppimista synergioiden edistämiseen ja optimointiin”. Se ei kerro mitään. Kuusi Coursera-sertifikaattia tai väite siitä, että olet intohimoinen tekoälyn suhteen, eivät myöskään erotu.

Jos minun pitäisi nimetä yksi yhdistävä tekijä, se olisi oppimisnopeus. Kuinka nopeasti pystyt etenemään? Kuinka syvälle teknisiin asioihin menet? Ymmärrätkö, miten järjestelmät toimivat yhdessä?

Jos yrität siirtyä tekoälytuotehallintaan ilman suoraa kokemusta, voit luoda kokemusta itse. Voit rakentaa jotain. Kukaan ei estä sinua rakentamasta.

Voit myös kirjoittaa oppimisestasi osana rakentamista. Rakentamisen aikana kohtaat monia haasteita. Voit luoda ihailemiesi tekoälytuotteiden tapaustutkimuksia, purkaa niiden toimintaa ja pohtia, miten kehittäisit niitä.

Kynnys aloittamiseen on nyt hyvin matala. Sinun ei tarvitse olla asiantuntija rakentaaksesi ideasi. Alalla ei myöskään ole paljon ihmisiä, joilla olisi kymmenen vuoden kokemus tekoälystä. Kaikki selvittävät asioita yhdessä.

Ero syntyy niiden välillä, jotka todella tekevät työtä asian selvittämiseksi, ja niiden, jotka odottavat lupaa.

Galen Low: Tämä oli erinomainen kuvaus tuosta ristiriidasta. Kuulet varmasti usein: ”Olen tuotepäällikkö, joten minulta ei pitäisi odottaa ohjelmointia.”

Välissä on kuitenkin kerros, jonka kuvasit hyvin. Ohjelmointia ei ehkä tarvitse osata, mutta on tunnettava sanasto, jolla liiketoiminnan ja käyttäjän tarpeet voidaan yhdistää teknisiin vaikutuksiin.

Tarvitaan myös rakentajan ajattelutapa: teknologia on ymmärrettävä riittävän hyvin, jotta tietää, missä on kitkaa ja mikä voi mennä pieleen. Ei riitä, että kertoo tehneensä, mitä käskettiin suuressa teknologiayrityksessä.

Rekrytoivana johtajana et tiedä, pystyykö henkilö käsittelemään epäselvyyttä, ymmärtääkö hän käyttäjää tai osaako hän puhua eri toimintojen kanssa. Tiedät vain, että hän työskenteli suuressa yrityksessä tietyssä tehtävässä. Hän on voinut vain seurata jonkun muun johdatusta eikä välttämättä ole ollut rohkea, nopea oppija tai valmis kehittämään ammattitaitoaan.

Jyothi Nookula: Siksi sanon: älä odota lupaa, vaan tee se. Kynnys kokeilemiseen on nyt hyvin matala.

Galen Low: Jyothi, kiitos paljon ajastasi tänään. Tämä on ollut todella hauskaa. Ennen kuin päästän sinut lähtemään, mistä ihmiset voivat oppia lisää sinusta?

Jyothi Nookula: Minut löytää LinkedInistä nimellä Jyothi Nookula. Voit myös vierailla osoitteessa nextgenproductmanager.com, jossa kerrotaan lisää tarjoamistani tekoälytuotehallinnan, agenttipohjaisen tekoälyn ja tuotepäälliköiden kiihdyttämöohjelman kursseista.

Galen Low: Hienoa. Lisään linkit myös ohjelman muistiinpanoihin kuuntelijoille ja kuvauksen yhteyteen katsojille. Jyothi, kiitos vielä kerran.

Jyothi Nookula: Kiitos paljon. Minulla oli todella hauskaa.

Galen Low: Hyvä kuulijat, siinä oli tämänkertainen The Digital Project Manager -podcastin jakso. Jos pidit keskustelusta, tilaa ohjelma käyttämässäsi kuuntelupalvelussa. Jos haluat lisää käytännön näkemyksiä, tapaustutkimuksia ja toimintamalleja, siirry osoitteeseen thedigitalprojectmanager.com. Ensi kertaan asti, kiitos kuuntelusta.