Teknologiayrittäjä ja entinen tuotejohtaja sanoo tekoälyn tekevän tuotetiimeistä huonompia – ei parempia

Adam Root on toiminut tuotejohtajana useissa teknologiayrityksissä. Tällä hetkellä hän on Root Venturesin perustaja, jossa hän rakentaa työnkulkuohjautuvia SaaS-tuotteita.

Haastattelimme Adamia ymmärtääksemme, miten tekoäly muuttaa tuotteen elinkaarta — ja miten se itse asiassa tekee joistakin tiimeistä matkan varrella huonompia. Tässä, mitä hän kertoi meille.

Tekoäly tekee tuotetiimeistä huonompia

Tekoäly tekee useimmista tuotetiimeistä huonompia, ei parempia — koska se poistaa kitkan, joka aiemmin suojasi tiimejä huonoilta päätöksiltä.

Viimeisten yli 17 vuoden aikana olen skaalannut SaaS-alustoja, johtanut tekoälyyn perustuvia hankkeita ja saavuttanut mitattavia tuloksia, kuten kasvattanut kuukausittaisen toistuvan liikevaihdon 20 000 dollarista 400 000 dollariin ja saanut aikaan yritystason vaikutuksia. Urani aiemmassa vaiheessa uskoin, että vaikeinta oli rakentaminen, ominaisuuksien julkaiseminen, tiimien skaalaaminen ja etenemissuunnitelman toteuttaminen. Olen oppinut, erityisesti viime vuosina, että todellinen haaste on epäselvyyden muuttaminen vakaaksi näkemykseksi. Tekoäly on tehnyt tästä erosta mahdotonta olla välittämättä. 

Tänä päivänä kuka tahansa voi luoda prototyypin tai julkaista nopeasti tekoälytyökalujen avulla, mutta useimmilla tiimeillä on edelleen vaikeuksia muuttaa tämä todelliseksi vetovoimaksi. Näen jatkuvasti vahvojen teknisten tiimien rakentavan nopeammin, mutta ilman selkeää tuoteajattelua. Ne lisäävät tekoälyn työnkulkuihin, joita ei koskaan suunniteltu menestymään. Tuloksena on enemmän tuotoksia, mutta ei suurempaa vaikutusta.

Tämä oivallus muutti perustavanlaatuisesti tapaani lähestyä tuotejohtamista. Nyt käsittelen jokaista tuotetta totuusjärjestelmänä enkä ominaisuuksien kokoelmana. Kaikki alkaa ongelman syvällisestä ymmärtämisestä, sen vahvistamisesta todisteilla ja päätösten järjestämisestä tavalla, joka luo vipuvaikutusta. Vasta sen jälkeen tekoälystä tulee todellinen tehostaja. Ilman tätä perustaa se vain kiihdyttää kohinaa.

Siksi keskityn nykyään vähemmän työkaluihin ja enemmän selkeyden luomiseen sekä tiimien yhdistämiseen sen ympärille, mikä on tärkeää, miksi se on tärkeää ja miten se tuottaa tuloksia. Kun järjestelmä on kunnossa, toteutus kumuloituu.

Tekoälyn ympärille rakennetun tuoteportfolion rakentaminen

Rakennan parhaillani pientä portfoliota tekoälylähtöisistä ja työnkulkuohjautuvista SaaS-tuotteista eri toimialoille. Jokainen niistä on suunniteltu sijoittumaan todellisen käyttäjätoiminnan keskiöön eikä vain lisäämään ominaisuuksia olemassa olevan päälle.

Sotia on käyttäytymisdatan ympärille rakennettu älykkyysjärjestelmä, joka aloittaa Slackista ja auttaa johtoa ymmärtämään toteutuksen tilaa reaaliajassa. Se muuttaa viestintämallit yhdenmukaisuutta, päätöksenteon nopeutta ja riskejä koskeviksi signaaleiksi ja luo käytännössä uuden kerroksen raakadatan ja johdon näkemyksen välille.

Samanaikaisesti rakennan VowVistaa, hääpaikkojen markkinapaikka-alustaa, joka keskittyy auttamaan Z-sukupolveen kuuluvia ostajia tekemään päätöksiä varmemmin. Se ratkaisee pirstaleisen ja tunteikkaan ostopäätöksen yhdistämällä läpinäkyvyyden, jäsennellyn datan ja ohjatut työnkulut, jotta käyttäjät voivat siirtyä vaihtoehtojen kartoittamisesta sitoutumiseen.

Niiden ohella jatkan tekoälylähtöisten alustojen kehittämistä rakennusalalle ja kenttätoimintoihin. Niissä keräämme kentältä monimuotoisia syötteitä, kuten puhetta, valokuvia ja videoita, ja muutamme ne jäsennellyksi, toimivaksi tiedoksi työntekijöille ja johtajille.

Kaikkia näitä yhdistää tuotteiden rakentaminen järjestelminä, jotka toimivat tietolähteinä ja älykkyyden lähteinä. Ne on suunniteltu todellisia työnkulkuja varten, ja niiden toimitusmallissa yhdistyvät nopea iterointi ja tuotantotason luotettavuus.

Miksi tuotejohtajien tulisi keskittyä järjestelmään eikä tekoälyyn

Tekoäly ei ole tuote. Sen ympärillä oleva järjestelmä on.

Useimmat tiimit aloittavat keskittymällä malliin, ominaisuuteen tai kyvykkyyteen. Käytännössä malli on kuitenkin vähiten erottuva ja usein helpoin osa. Todellinen työ on kaikessa sen ympärillä: datassa, työnkulkujen integroinnissa, käyttökokemuksessa, luottamusmallissa sekä siinä, miten tulos ohjaa todellista päätöstä tai toimenpidettä.

Jos teet tämän väärin, tekoäly saa tuotteesi näyttämään vaikuttavalta tekemättä siitä hyödyllistä. Julkaiset ominaisuuksia, jotka toimivat hyvin esittelyssä mutta joita ei oteta käyttöön, koska niitä ei ole upotettu siihen, miten käyttäjät todellisuudessa työskentelevät tai tekevät päätöksiä.

Jos teet tämän oikein, tekoälystä tulee tehostaja. Se muuttaa sekavat syötteet jäsennellyksi näkemykseksi, vähentää kitkaa todellisissa työnkuluissa ja luo vipuvaikutusta koko järjestelmään.

Jos olisin tiennyt sen aiemmin, olisin välttänyt liiallista panostamista ”älykkyyteen” ennen työnkulun validointia. Muutamissa tapauksissa rakensimme vaikuttavia ominaisuuksia, jotka toimivat teknisesti, mutta eivät muuttaneet käyttäjien toimintaa, koska niitä ei ollut sisällytetty siihen, miten työ tosiasiassa tehtiin. Meidän oli palattava suunnitteluun ja keskityttävä työnkulkuun mallin sijaan.

Miten näyttöön perustuvat järjestelmät voivat parantaa toteutusta

Olen siirtynyt ominaisuuksien rakentamisesta näyttöön perustuvien järjestelmien rakentamiseen ennen koodin kirjoittamista – käyttämällä tekoälyä prosessin alkuvaiheessa synteesin ja validoinnin kerroksena.

Aiemmin vahvatkin tiimit siirtyivät löydöksistä suhteellisen nopeasti määrittelyihin. Tämä malli ei toimi tekoälyn tukemassa maailmassa, koska rakentamisen kustannukset ovat laskeneet niin paljon. Ratkaisuja voi luoda ja julkaista nopeammin kuin voidaan validoida, pitäisikö niiden olla olemassa. Tästä syntyy uusi epäonnistumisen muoto: tiimit skaalaavat vääriä ideoita uskomattomalla nopeudella.

Löytämisestä on nyt tultava jatkuva, järjestelmälähtöinen toiminto, ei vaihe. Tämä tarkoittaa seuraavaa:

• Todellisten signaalien kokoaminen laajassa mittakaavassa, mukaan lukien käyttäjien toiminta, tukitiedot, voitot ja tappiot sekä laadulliset havainnot
• Tekoälyn käyttäminen näiden syötteiden välisten kaavojen syntetisointiin, ei vain niiden tiivistämiseen
• Ongelmiin liittyvien työnkulkujen kartoittaminen nimenomaisesti ja sen mittaaminen, ratkaiseeko tuote ne tosiasiassa
• Oletusten jatkuva uudelleenvalidointi uuden tiedon tullessa saataville

Esimerkiksi käytän jäsenneltyjä kehotteita useiden tietolähteiden kanssa toistuvien ongelmien esiin tuomiseen, niiden yhdistämiseen työnkulkuihin ja sen testaamiseen nimenomaisesti, ratkaiseeko tuote ne tosiasiassa. Tämä prosessi mitätöi usein alkuperäiset ideat tai muokkaa niitä merkittävästi ennen kuin ne päätyvät suunnitteluun tai tuotekehitykseen.

Seurauksena muuttui varmuuden laatu. Rakennamme vähemmän asioita, mutta rakentamamme asiat vastaavat paljon tiiviimmin todellisiin ongelmiin. Se muuttaa myös tiimien toimintatapaa. Mielipiteiden väittelyn sijaan reagoimme syntetisoituun näyttöön. Minulle tekoälyssä onkin vähemmän kyse toteutuksen nopeuttamisesta ja enemmän sen tarkkuuden lisäämisestä, mitä päätämme toteuttaa.

Miten tekoäly tiivistää koko signaalista julkaistuksi tuotteeksi etenevän työnkulun

Tässä on tekoälypohjainen päästä päähän -työnkulku, jota käytän siirtyäkseni raakamuotoisista käyttäjähavainnoista julkaistuun ja validoituun tuotteen kehityssykliin.

Se alkaa signaalien kokoamisesta. Kokoan laadullista ja käyttäytymisdataa, kuten pariskuntien haastatteluja, Reddit-keskusteluja, tapahtumapaikkojen arvosteluja, suppilon poistumiskohtia ja saapuvia kysymyksiä. Sen sijaan, että tarkastelisin näitä yksi kerrallaan, käytän tekoälyä syntetisoimaan kaikki lähteet ja tunnistamaan toistuvat ongelmat, niiden esiintymistiheyden sekä kohdat, joissa käyttäjät juuttuvat päätöksentekoprosessissa.

Sen jälkeen siirryn ongelmien jäsentämiseen. Tekoäly auttaa ryhmittelemään nämä signaalit selkeiksi ongelmakuvauksiksi, jotka liittyvät työnkulun tiettyihin hetkiin. Sitten koettelen näitä ongelmia perusteellisesti kysymällä: ”Onko tämä yleinen, tuskallinen ja tuotteen ratkaistavissa?”

Seuraavaksi muotoillaan ratkaisu. Käytän tekoälyä tutkiakseni nopeasti erilaisia tapoja ratkaista ongelma – en vain ominaisuuksia, vaan myös työnkulun muutoksia. Olennaista on tuottaa nopeasti useita lähestymistapoja ja rajata niitä sitten sen perusteella, mikä sopii parhaiten käyttäjien toimintaan.

Sitten siirrymme rakentamiseen ja mittarointiin. Tekoälyavusteisten kehitystyökalujen avulla siirrymme konseptista nopeasti toimivaan versioon, mutta rakennamme mittaroinnin mukaan alusta lähtien. Seuraamme, sitoutuvatko käyttäjät uuteen työnkulkuun, missä kohdissa he poistuvat ja parantaako se päätöksenteon varmuutta tai etenemistä.

Sen jälkeen prosessista tulee oppimissykli. Tekoäly analysoi käyttökuvioita, laadullista palautetta ja poikkeustapauksia tunnistaakseen, mikä toimii ja mikä ei. Tarkastelemme sitä, muuttiko muutos todella käyttäjien toimintaa, emmekä vain sitä, olivatko käyttäjät vuorovaikutuksessa sen kanssa.

Lopuksi tulokset ohjaavat seuraavaa iteraatiota tai poistamista. Jos työnkulku parantaa tuloksia, laajennamme sitä. Jos ei, hiomme sitä tai poistamme sen nopeasti.

Claude, joka on yhdistetty tuotetietoihini ja käyttäjähavaintoihini, hoitaa suurimman osan tästä työnkulusta.

Miten tekoäly voi luoda väärää varmuutta

Paras tekoälyn aikaansaama tulos, jonka olen nähnyt, on selkeyden saavuttamisen nopeuden merkittävä kasvu. Tekoäly on tiivistänyt päiviä vaatineen työn tunneiksi, erityisesti löytämisessä, synteesissä ja tuotteen määrittelyn alkuvaiheessa. Voin tarkastella huomattavasti useampia syötteitä, havaita kaavoja nopeammin ja koetella ideoita perusteellisesti ennen kuin tiimi sitoutuu resursseihin. Laadullisesti tämä on johtanut parempaan alustavaan jäsentämiseen, siihen, että harvemmat heikot ideat päätyvät tuotesuunnitelmaa koskeviin keskusteluihin, sekä tuotteen, suunnittelun ja tuotekehityksen parempaan yhteensovittamiseen.

Se on parantanut myös itse tuotteiden luomisen läpimenoa. Viime vuoden aikana olen käyttänyt tekoälyavusteisia työnkulkuja siirtyäkseni konseptista toimivaan tuotteeseen huomattavasti nopeammin kuin perinteiset syklit mahdollistaisivat. Tämä sisältää siirtymisen ongelman jäsentämisestä arkkitehtuuriin, PRD:hin ja käyttökelpoiseen ohjelmistoon murto-osassa tavanomaisesti tarvittavasta ajasta. Hyöty ei ole pelkästään nopeus. Se on kyky testata todellisia työnkulkuja aiemmin, mikä nopeuttaa oppimista.

Kaikki ei kuitenkaan ole hyvin. Tekoäly voi luoda väärää itsevarmuutta. Tiimit voivat erehtyä pitämään viimeistellyn tuotoksen laatua tuotteen laatuna. Prototyyppi näyttää vakuuttavalta, määrittely kuulostaa kattavalta ja kaikista tuntuu siltä, että edistystä tapahtuu, vaikka taustalla oleva työnkulku, luottamusmalli tai käyttäjän tarve olisi edelleen ratkaisematta. Olen myös nähnyt tekoälyn lisäävän hälyä, kun sitä käytetään ilman vahvaa tuotteen perusajatusta. Se voi tuottaa enemmän ideoita, tekstiä, tehtäviä ja muita tuotoksia kuin tiimi pystyy realistisesti arvioimaan, mikä voi itse asiassa vaikeuttaa priorisointia.

Adam Shares

Tekoälyn paras tulos, jonka tällä hetkellä näen, on selkeyden saavuttamiseen kuluvan ajan merkittävä lyheneminen. Tekoäly on tiivistänyt päiviä vaatineen työn tunneiksi, erityisesti tutkimuksessa, synteesissä ja tuotteen määrittelyn alkuvaiheissa.

Missä tekoäly jää tuotteissa puutteelliseksi

Tekoäly ei ole selkeimmin lunastanut odotuksiani siellä, missä odotin sen tuovan merkittäviä harppauksia tuotearviointiin ja jatkuvaan tuotevaikutukseen.

Aluksi ajattelin, että tekoäly parantaisi merkittävästi priorisointia ja etenemissuunnitelmien laatua tekemällä malleista ilmeisiä. Se auttaakin tuomaan malleja esiin, mutta se ei ratkaise sitä, millä todella on merkitystä. Vaikeinta on edelleen tulkita kompromisseja, ymmärtää toisen asteen vaikutuksia ja sitoutua tiettyyn suuntaan epävarmuuden vallitessa. Tekoäly tukee tätä prosessia, mutta ei korvaa sitä. En ole nähnyt sen tuottavan johdonmukaisesti parempia tuoteratkaisuja itsenäisesti.

Se on jäänyt puutteelliseksi myös todellisen käyttöönoton edistämisessä. Tekoälyominaisuudet toimivat usein esittelyissä erittäin hyvin, mutta se ei muutu toistuvaksi käytöksi, ellei niitä ole syvällisesti integroitu todellisiin työnkulkuihin. Olen nähnyt tiimien julkaisevan vaikuttavia tekoälyominaisuuksia, joita käyttäjät kokeilevat kerran mutta eivät palaa käyttämään, koska tuote ei muuttanut toimintatapoja eikä siitä tullut osa työn tekemisen tapaa.

Toinen puute liittyy monimutkaisuuden vähentämiseen. Odotin tekoälyn yksinkertaistavan tuotteiden rakentamista ja ylläpitoa, mutta monissa tapauksissa se tuo uusia kerroksia, kuten kehotelogiikkaa, poikkeustapauksia, arviointihaasteita ja luottamukseen liittyviä näkökohtia. Työn poistamisen sijaan se siirtää sitä uusille alueille, jotka edellyttävät edelleen vahvaa tuote- ja suunnittelukuria.

Miksi vastuun on säilyttävä ihmisillä

Käytän tekoälyä paljon aina, kun mittakaava ja hahmontunnistus ovat tärkeitä, ja pidän ihmiset mukana aina, kun lopputulos riippuu harkinnasta, riskeistä tai mausta.

Tekoälyn osalta hyödynnän sitä eniten tutkimuksessa ja synteesissä. Syötän sille haastattelulitterointeja, tukipyyntöjä, voitto–tappio-tietoja ja käyttäytymissignaaleja toistuvien ongelmien tunnistamiseksi, niiden yleisyyden määrittämiseksi ja ongelmien yhdistämiseksi työnkulkuihin. Se on hyödyllinen myös priorisoinnin alkuvaiheessa – ei päätösten tekemiseen, vaan oletusten testaamiseen näyttämällä kompromisseja, toisen asteen vaikutuksia ja vaihtoehtoisia näkökulmia, joita en ehkä olisi itse tullut ajatelleeksi. Kokeiluissa tekoäly auttaa luomaan hypoteeseja, luonnostelemaan vaihtoehtoja ja analysoimaan tuloksia nopeasti, erityisesti silloin, kun käsiteltävänä on suuria määriä laadullista palautetta.

Asiat, jotka pidän tietoisesti ihmisten vastuulla, liittyvät vakaumukseen ja sitoutumiseen. Lopulliset priorisointipäätökset, etenemissuunnitelman vaiheistus ja se, mitä päätämme olla rakentamatta, ovat edelleen johtoryhmän ja minun vastuullani. Sama koskee käyttäjäkokemusratkaisuja, jotka edellyttävät makua, luottamusta ja emotionaalista kontekstia. Myös tekniset kompromissit johdetaan ihmisten toimesta, koska niihin liittyy pitkän aikavälin järjestelmäajattelua, riskinsietokykyä ja organisatorisia rajoitteita, joita tekoäly ei pysty täysin sisäistämään.

Syy on yksinkertainen: tekoäly on erinomainen tiedon tiivistämisessä ja ratkaisujen avaruuden laajentamisessa, mutta se ei kanna seurausten vastuuta. Tuotejohtajuus kiteytyy lopulta peruuttamattomien tai kalliiden päätösten tekemiseen epävarmuuden vallitessa. Tämän vastuun on säilyttävä ihmisillä.

Miksi tuotejohtajien on varottava väärää luottamusta suuressa mittakaavassa

Tuotejohtajat aliarvioivat usein suuressa mittakaavassa syntyvän väärän luottamuksen riskin.

Tekoälyjärjestelmät tuottavat erittäin hyvin tuloksia, jotka vaikuttavat oikeilta, vaikka ne eivät sitä olisi. Vaara ei piile ilmeisessä epäonnistumisessa, vaan uskottavassa paikkansapitävyydessä. Jokin näyttää oikealta, kuulostaa varmalta ja on väärin tavoilla, joita ei heti pysty havaitsemaan.

Pienessä mittakaavassa käyttäjä saattaa huomata virheen. Tuotteen mittakaavassa sama virhe toistuu tuhansissa vuorovaikutustilanteissa ja muokkaa hiljalleen päätöksiä, työnkulkuja ja lopputuloksia.

Olen nähnyt tämän ilmenevän esimerkiksi asiakirjojen tulkinnassa, suosituksissa ja työnkulkujen automatisoinnissa. Järjestelmä toimii suurimman osan ajasta riittävän hyvin, jotta käyttäjät alkavat luottaa siihen, mutta todellinen riski piilee poikkeustapauksissa. Ja juuri näillä poikkeustapauksilla on usein vakavimmat seuraukset.

Erityisen vaarallista tästä tekee se, etteivät perinteiset tuotekehityksen vaistot havaitse sitä. Et näe käytön vähenemistä tai kaatumista. Näet sitoutumista. Tuote ”toimii”. Kunnes se ei enää toimi.

Ratkaisu ei ole vain paremmat mallit. On suunniteltava luottamusta ja varmennusta varten:

Adamin jakama

Tuotejohtajat aliarvioivat usein perusteettoman luottamuksen riskin laajassa mittakaavassa…Erityisen vaarallista tästä tekee se, etteivät perinteiset tuotekehityksen vaistot havaitse sitä. Et näe käytön vähenemistä tai kaatumista. Näet sitoutumista. Tuote ”toimii.” Kunnes se ei enää toimi.

• Todisteiden näyttäminen pelkkien vastausten sijaan
• Luottamuksen ja epävarmuuden tuominen näkyviin
• Selkeiden ihmisen osallistumista edellyttävien tarkistuspisteiden luominen
• Sen seuraaminen, milloin järjestelmä on väärässä, ei vain sitä, milloin sitä käytetään

Riskinä on olettaa, että tarkkuus kasvaa käytön mukana lineaarisesti. Todellisuudessa riski kasvaa nopeammin kuin tarkkuus.

Miten tekoälyn harkintakyky voi heikentyä

Tekoälyllä on ollut eniten vaikeuksia tilanteissa, joissa tuotteen on ymmärrettävä ihmisten panokset, moniselitteisyys ja väärän vastauksen hinta — ei vain tuotettava uskottavalta kuulostavaa vastausta.

Hyvä esimerkki ovat vaatimustenmukaisuuteen liittyvät tai suurta luottamusta edellyttävät työnkulut. Olen työskennellyt tuotekonseptien parissa, joissa tekoäly voi poimia asiakirjoista tietoja, ilmoittaa ongelmista ja suositella seuraavia toimenpiteitä. Paperilla tämä näyttää täydelliseltä tekoälyn käyttötapaukselta. Käytännössä haasteena on se, että malli voi tuottaa erittäin itsevarmalta kuulostavan vastauksen samalla, kun se jättää huomiotta tärkeän asiayhteyden, tulkitsee jonkin kohdan väärin tai ei ymmärrä, miksi yksi poikkeus on toista tärkeämpi.

Tämä aiheuttaa välittömästi luottamusongelman. Käyttäjä ei kysy: ”Oliko tämä tulos vaikuttava?” Hän kysyy: ”Voinko luottaa tähän ilman, että aiheutan myöhempiä riskejä?”

Olen oppinut, että tekoälyn harkintakyky on usein heikko silloin, kun:

• Asiayhteys on puutteellinen
• Virheen seuraukset ovat epäsymmetrisiä
• Käyttäjä tarvitsee selityksen, ei vain tulosta

Miten tekoäly muokkaa tiimien rakennetta

Tekoäly on muuttanut tuotetiimieni rakennetta rooliperusteisista siiloista pienemmiksi, integroidummiksi ja järjestelmälähtöisemmiksi tiimeiksi.

Aiemmin tiimit rakennettiin selkeiden työvaiheiden ympärille: tuotehallinta määrittelee, suunnittelu suunnittelee, ohjelmistokehitys rakentaa ja data-analytiikka analysoi. Tämä malli hajoaa, kun tekoäly tiivistää toteutusta ja tuo mukanaan todennäköisyyspohjaisia järjestelmiä, jotka edellyttävät tiiviitä palautesilmukoita.

Nykyään suosin pienempiä tiimejä, joiden jäsenet pystyvät toimimaan rajojen yli. Tuotepäälliköiden odotetaan perehtyvän syvemmälle dataan, kehotteiden suunnitteluun ja työnkulun logiikkaan. Insinöörit ovat lähempänä ongelmaa ja käyttäjän asiayhteyttä, eivät vain toteutusta. Suunnittelussa on aiempaa vähemmän kyse staattisista näkymistä ja enemmän vuorovaikutusmalleista, luottamuksesta sekä siitä, miten järjestelmä toimii ollessaan epävarma tai väärässä.

Olen myös nähnyt uusien vastuualueiden syntyvän täysin uusien roolien sijaan. Tällaisia ovat esimerkiksi:

• ”Järjestelmän toiminnan” hallinta poikkeustapauksissa, ei vain ihannetilanteessa
• Luottamuskynnysten ja ihmisen osallistumista edellyttävien vaiheiden määrittäminen
• Datan laadun ja palautesilmukoiden käsitteleminen keskeisinä tuotteenhallinnan kysymyksinä

Miten tuotejohtajien tulisi käyttää tekoälyä

Neuvoni on yksinkertainen: Älä käytä tekoälyä nopeampaan etenemiseen. Käytä sitä tehdäksesi useampia asioita oikein.

Tällä hetkellä useimmat tiimit keskittyvät nopeuteen, useampiin ominaisuuksiin, nopeampiin sykleihin ja nopeampiin tuloksiin. Se on ilmeinen hyöty. Mutta nopeus ilman selkeyttä vain moninkertaistaa virheet.

Adamin neuvo

Neuvoni on yksinkertainen: Älä käytä tekoälyä nopeampaan etenemiseen. Käytä sitä tehdäksesi useampia asioita oikein…Todellinen muutos on tämä: rakentaminen ei enää ole rajoite. Harkintakyky on.

Todellinen muutos on tämä: rakentaminen ei enää ole rajoite. Harkintakyky on.

Tuotejohtajana roolisi liittyy siis vähemmän toteutuksen edistämiseen ja enemmän seuraaviin asioihin:

• Oikeiden ongelmien määrittäminen
• Päätösten ajoittaminen
• Sen varmistaminen, että rakennettu todella muuttaa käyttäjien toimintaa

Hyödynnä AI:ta ajattelusi laajentamiseen, olennaisen tiedon kokoamiseen ja ideoiden perusteelliseen koettelemiseen. Älä kuitenkaan ulkoista vaikeita päätöksiä. Siinä piilee arvo.

Suunnittele myös tiimisi työskentelytavat uudelleen:

• Käsittele selvitystyötä jatkuvana toimintana, älä yhtenä vaiheena.
• Suunnittele luottamusta, älä pelkästään toiminnallisuutta varten.
• Rakenna järjestelmiä, älä ominaisuuksia.

Ja mikä tärkeintä, vastusta houkutusta ohittaa vaikea ajattelutyö.

Seuraa mukana

Voit seurata Adam Rootia LinkedInissä, kun hän jatkaa Sotian, VowVistan ja muiden portfoliossaan olevien SaaS-tuotteiden rakentamista.

CPO-klubilla on luvassa lisää asiantuntijahaastatteluja!