Miten tekoäly vie tuotepäälliköt roolinsa ulkopuolelle

Matka tuotejohtamisen pariin

Olen työskennellyt tuotejohtajana nyt yli 15 vuoden ajan. Urani alkuvaiheessa tein kaikkea muutakin, mitä pystyin, mukaan lukien suunnittelua, myyntiä, konsultointia, markkinointia ja jopa koodausta PHP-aikoina — hyi.

Päädyin tuotejohtamisen pariin, koska pidin todella paljon eri aiheiden välillä liikkumisesta ja käyttäjien, kehittäjien, johtajien ja muiden kanssa työskentelystä. Minulla oli myös melko hyvä silmä suunnittelulle ja hyvä tuotetaju. Tutkittuani asiaa paljon löysin roolin, joka sopi tähän todella hyvin — tuotejohtamisen. Niinpä hain ensimmäistä tuotejohtajan paikkaani, ja sitä kautta päädyin tänne.

Olen työskennellyt kaikenlaisilla toimialoilla: B2B-, B2B2C- ja vähittäiskaupan parissa sekä kuluttajaohjelmistojen parissa. Aloitin tuotejohtamisen opettamisen General Assemblyssä yli vuosikymmen sitten, minkä jälkeen julkaisin itsenäisesti omia verkkokurssejani Udemyssä ja myöhemmin LinkedIn Learningissä. Nykyään minulla on molemmilla alustoilla yhteensä yli 1,6 miljoonaa opiskelijaa. Olen myös puhunut monissa tuote- ja projektijohtamista käsittelevissä konferensseissa, muun muassa työskennellyt Googlen kanssa ja opettanut tuotekurssia Kiovassa Ukrainassa.

Tällä hetkellä työskentelen Probably.dev-yrityksessä, joka on a16z:n rahoittama deterministinen data-agenttisovellus. Olemme pieni tiimi, joten en ole vain tuotejohtaja, vaan myös insinööri, myyntiedustaja, suunnittelija ja paljon muuta.

Sovelluksemme on natiivi työpöytäsovellus, joka tuottaa determinististä, tohtoritason datatiedettä tukevaa visualisointia vastatakseen suoraan mihin tahansa luonnollisella kielellä esitettyyn kyselyyn ilman, että arkaluonteiset tiedot poistuvat koneeltasi. Sitä voi ajatella "data-apurina". Työskentelemme suoraan data-alustojen skeemojen (esimerkiksi BigQuery, Snowflake, ClickHouse ja niin edelleen) päällä sekä paikallisten tiedostojen, kuten CSV-, JSON- ja Parquet-tiedostojen, kanssa. Kaikki agenttimme tarjoamat vastaukset ovat ihmisen tarkistettavissa ja toistettavissa, joten tyypilliset LLM-hallusinaatiot eivät ole ongelma. Kyseessä ei ole vain yksi SQL-koodia tuottava agentti, vaan pystymme käsittelemään miljardeja rivejä ja sarakkeita sekä monimutkaisia skeemoja, joissa on kymmeniätuhansia tauluja.

You should also read

• 12 parasta projektinhallintapodcastia, joita kannattaa kuunnella vuonna 2026

• Kuinka käyttää Confluencea projektinhallintaan vuonna 2026

• 4 strategiaa epärealististen projektin määräaikojen käsittelyyn

Miten tekoäly auttaa tiimejä saamaan enemmän aikaan henkilöä kohden

Tekoäly on vaikuttanut suuresti työhöni. Ennen olin "vain tuotejohtaja". Se kuulostaa hassulta, koska tuotejohtajat tekevät niin paljon, mutta nyt pystyn osallistumaan myös kaikkeen muuhun, kuten suunnitteluun ja myyntiin. Se auttaa tiimiä etenemään nopeammin. Kun tekoäly muuttaa projektijohtamista, perinteiset roolirajat muuttuvat joustavammiksi.

Aikaa vievät tehtävät, kuten tutkimus ja analysointi, ovat paljon nopeampia, ja ajansäästö mahdollistaa huomattavasti enemmän aikaa kasvokkain tapahtuvaan vuorovaikutukseen ja viestintään sidosryhmien kanssa. Se mahdollistaa myös nopeamman päätöksenteon.

Suuri osa tuotejohtajan työstä on varmistaa, että kaikki muut pystyvät tekemään työnsä tehokkaasti. Kun pystyn tekemään itse vielä enemmän, saamme yhdessä paljon enemmän aikaan henkilöä kohden. Tästä ihmisen ja tekoälyn yhdistelmästä on tulossa nykyaikaisten toimitustiimien kannalta välttämätön.

Miksi tekoälyn syvällinen ymmärtäminen antaa tuotejohtajille mahdollisuuden tehdä lähes mitä tahansa

Mitä enemmän perehdyn asiaan, sitä enemmän ymmärrän, kuinka jyrkkä oppimiskäyrä tehokkaalle ja tuottavalle AI/LLM:n käytölle todellisuudessa on. Lisäksi on opittava sovittamaan se ympärilläsi olevien tai tiimiesi suosimiin työnkulkuihin. Tämä vahvistaa entisestään uskoani siihen, että jokaisen yrityksessä työskentelevän on tunnettava läheisesti paitsi LLM:t yleisesti ja saatavilla olevat mallit, myös niiden ympärillä olevan ekosysteemin moninaiset työkalut, kuten MCP:t, käyttöliittymämuodot, kuten CLI ja GUI, ja ennen kaikkea muuntaja-arkkitehtuuri. Niille, jotka haluavat syventää ymmärrystään, tekoälyä projektijohtamisessa käsitteleviin kirjoihin tutustuminen voi tarjota arvokkaita näkemyksiä näiden teknologioiden tehokkaasta käyttöönotosta.

Tehokas työskentely tekoälyn kanssa nykyisessä tekoälyhötön valtavassa meressä, olipa kyse sisällöstä tai työkaluista, on taito, jota on hiottava ja joka kehittyy vain kokemuksen myötä. On ymmärrettävä, miten LLM:t toimivat ja mihin ne pystyvät tai eivät pysty, jotta niistä saa parhaan hyödyn ja niitä voi käyttää optimaalisesti.

Monet siellä olevat “mullistavat” SaaS-tuotteet ja työkalut vaikuttavat hyviltä ratkaisuilta — esimerkiksi PRD-dokumenttien laatimiseen — mutta olen huomannut, että 99 % kaikesta, mitä tarvitset tehdä, voidaan tehdä itse halvemmalla, nopeammin, räätälöidymmin ja huomattavasti paremmin. Tämä pätee, kunhan ymmärrät edellä mainitut käsitteet ja osaat käyttää LLM:iä tehokkaasti.

Se on kuin mainosohjelmissa, joissa joku tekee jotain yksinkertaista, minkä jälkeen näytetään, kuinka "vaikeaa" se on, ja yritetään myydä sinulle kokonainen laite ratkaisemaan tämä pieni käyttötapaus. Sen sijaan että banaani leikattaisiin normaalin ihmisen tavoin veitsellä paloiksi, sinulle halutaan myydä banaanin muotoinen leikkuri, joka leikkaa kaikki palat yhdellä liikkeellä...

Veitsi on LLM ja banaanileikkuri on surkea kapean alan sovellus. Opettele käyttämään hemmetin veistä. Osta laadukas veitsi, käytä sitä, opettele tuntemaan se ja lopeta typerien asioiden ostaminen vain siksi, että teknologia-aiheinen Twitter kertoo jonkin satunnaisen SaaS-sovelluksen juuri ”tehneen suunnittelijoista tarpeettomia” tai ”lopettaneen koodaamisen”.

CLI:ssä, verkkoselaimessa ja silloin tällöin avoimen, tehtävästä riippumattoman automaatiotyökalun, kuten n8n:n, avulla ei käytännössä ole juuri mitään, mitä et voisi tehdä LLM:n avulla.

Säästä rahasi ja opettele rakentamaan asioita, jotka heijastavat opituista kokemuksistasi kertynyttä viisautta, sen sijaan että hyväksyisit yön yli ilmestyneen SaaS-ponnahdustyökalun tuottaman tuloksen.

Ainoa tilanne, jossa tämä ei päde, ovat yhden tarkoituksen työkalut, jotka keskittyvät erityisesti sellaisten ongelmien ratkaisemiseen, joissa muuntaja-LLM-arkkitehtuuri on perustavanlaatuisesti puutteellinen perusmuotoisissa huippumalleissa eli malleissa, joita ei ole hienosäädetty. Tällaisia ovat esimerkiksi laajamittainen datatiede tai matematiikka.

Kuinka tuotepäällikkö voi aloittaa oppimisen tekoälyn avulla

LLM:ien parasta on se, että voit kysyä niiltä, kuinka niistä opitaan. Jos olet kaltaiseni visuaalinen oppija, YouTube kruunaa kokonaisuuden: siellä on valtavasti hyviä tekoälyä ja LLM:iä käsitteleviä resursseja.

Jos aloittaisin alusta, lähestyisin oppimista näin: Kerro LLM:lle, että haluat oppia kaiken tekoälyn ja LLM:ien alueelta teknisen ymmärryksesi tasolle sovitettuna. Voit jopa ohjeistaa sitä esittämään sinulle asteittain teknisempiä kysymyksiä ymmärtääkseen nykyisen osaamistasosi missä tahansa tekoälyyn ja LLM:iin liittyvässä aiheessa, aloittaen perusteista. Kun sitten saavutat kohdan, jossa tietosi eivät enää riitä, voit pyytää sitä suosittelemaan opiskeltavia aiheita aina muuntaja-arkkitehtuurin perusteista siihen, kuinka ChatGPT:n kaltainen sovellus toimii.

Tavoitteena on saada luettelo opiskeltavista aiheista ja etsiä sitten jokaista niistä YouTubesta löytääksesi videon, jonka avulla voit ymmärtää aiheen.

Tässä on esimerkkikehote:

Toimi tekoälyä ja LLM:iä koskevan ”lähtötasoni” arvioijana.

Esitä minulle enintään 12 kysymystä (helppojen ja teknisten kysymysten sekoitus) arvioidaksesi:

• yleistä teknistä valmiuttani (koodaus, data, API:t)
• ymmärrystäni LLM:ien toiminnasta (mallien käyttömuodot, kuten CLI ja graafiset käyttöliittymät, sekä tokenit, konteksti, hallusinaatiot jne.)
• tuntemustani nykyaikaisista LLM-sovellusten toimintamalleista (RAG/vektoriesitykset, agentit ja työkalujen käyttö)
• kykyäni arvioida laatua (arvioinnit, varmennus)
• tietoisuuttani riskeistä (yksityisyys, kehotteinjektio jne.)
• tietoisuuttani tekoälyn rajoituksista (LLM:ien hyvät ja huonot käyttötapaukset, tarkkuus, LLM:ien tuottamien tulosten hallitsematon luonne jne.)

Kun olen vastannut, tuota VAIN:

• 5–10 tärkeintä YouTube-aihetta, jotka minun tulisi opiskella seuraavaksi, tärkeysjärjestyksessä. Jokaisen kohdan on oltava YouTube-hakulauseke (ei lause) + 5–10 sanan ”miksi tämä on tärkeää” -perustelu.

Aloita kysymysten esittäminen nyt.

Mitä tekoälytaitoja tuotepäälliköiden tulisi opetella ensin

Mielestäni on tärkeää ymmärtää, missä ja miten LLM:iä voi käyttää. Tarkoitan tällä sitä, että ymmärtää niiden voivan toimia sovelluksessa, tietokoneen päätteessä tai automaatiossa toimivassa koodissa MCP:iden tai API:en kautta.

Toissijaisesti on välttämätöntä ymmärtää, että ne ovat:

1. epädeterministisiä, hallitsemattomia ja alttiita virheille
2. sellaisia, joihin ei koskaan pidä luottaa tarkan tiedon lähteenä, etenkään kriittisissä päätöksissä
3. luovasti automatisoitavissa siten, että kahden edellisen kohdan vaikutuksia voidaan vähentää käyttötapauksesta riippuen

Klassinen esimerkkini on, ettei LLM:ää pidä koskaan käyttää kirjoittamaan esseetä kokonaan puolestasi, mutta siltä on täysin sopivaa pyytää luetteloa mahdollisista etenemissuunnista, jos et keksi, mitä kirjoittaa seuraavaksi. Toisin sanoen LLM:t täydentävät erinomaisesti ihmismieltä, mutta niiden käyttäminen kaiken ajattelun tekemiseen ihmismielen sijasta johtaa synkälle tielle.

Viimeinen asia, jonka mainitsen, on se, että kun opiskelet edellä mainittuja käsitteitä, sinun täytyy kokeilla niitä itse. Jos esimerkiksi opiskelet kehotetekniikan toimintaa, sinun kannattaa esittää sama kysymys LLM:lle kahdella eri tavalla muotoiltuna nähdäksesi tuloksen eron. Älä koskaan opiskele harjoittelematta samalla oppimaasi käytännössä.

Miksi arvokkaita asiakasvuorovaikutuksia ei pitäisi automatisoida tekoälyn avulla

Kun opit kaiken tarvittavan, voit tehdä lähes mitä tahansa. Se ei kuitenkaan tarkoita, että pitäisi.

Varhaisvaiheen yrityksessä, jolla on premium-tuote, asiakasvuorovaikutus ja myynti vaikuttavat ”näennäisesti” olevan tekoälyn ja automaation otollisimpia käyttökohteita. Käytännössä olen kuitenkin huomannut, että inhimillinen ote on ehdottoman välttämätön. Itse koen vuorovaikutuksen käyttäjien tai potentiaalisten asiakkaiden kanssa merkittäväksi lisäarvoksi molemmille osapuolille, enkä edes halua yrittää automatisoida sitä.

Tuotepäällikkönä tekisit itsellesi karhunpalveluksen, jos et lainkaan keskustelisi käyttäjien kanssa. Mitä enemmän keskustelet heidän kanssaan henkilökohtaisesti ja omalla äänelläsi, sitä enemmän tietoa saat ja sitä enemmän luottamusta herätät.

Miksi tuotepäälliköiden on vaikeaa – mutta mahdollista – osallistua koodin tekemiseen

Suhtaudun siis varovaisesti siihen, mihin käytän tekoälyä, mutta käytän sitä paljon.

Esimerkiksi juuri ennen tuotantoon julkaisemista on aina meneillään virheenkorjausrumba. Yleensä suuremmassa yrityksessä insinöörit ja laadunvarmistustiimi hoitaisivat tällaiset viimeistelyt. Tietysti kokenut tuotepäällikkö olisi mukana, mutta hän myös suunnittelisi seuraavia vaiheita ja strategioita julkaisun seurantaan, keräisi käyttäjäpalautetta, valmistelisi useita tulevia kehityssyklejä tai keräisi mittareita ominaisuuden tai tuotteen julkaisun jälkeen.

Koska työskentelen tällä hetkellä pienemmässä yrityksessä, minulle mullistavaa on ollut mahdollisuus auttaa virheiden korjaamisessa yhdessä insinöörien kanssa, ja olen pystynyt saavuttamaan sen ainoastaan tekoälyn ja suurten kielimallien avulla.

Olen urani aikana aina osallistunut tuotteiden ja ominaisuuksien laadunvarmistukseen, mutta harvoin olen pystynyt todella tarttumaan toimeen ja korjaamaan virhettä, joka edellyttää koodimuutoksia koko teknologiapinossa.

Teknologia-alan veteraanit ymmärtävät, että insinöörit suhtautuvat koodikantoihinsa ja koodausstandardeihinsa hyvin tarkasti. Vaikka siis tietäisit teknisesti, miten tietty virhe korjataan, sinun on myös tunnettava koodausstandardien taustat ja insinööritiimin persoonat sekä ymmärrettävä insinöörejä, jotka ovat työskennelleet koodin kunkin osan parissa. Joidenkin virheiden korjaaminen on siis kaukana helposta, vaikka tietäisitkin, miten se tehdään, ja useimmat insinöörit suhtautuisivat korjausta koskevaan pull-pyyntöösi pilkallisesti.

Tekoälyn ansiosta olen kuitenkin pystynyt paitsi osallistumaan koodin tekemiseen viemällä muutokset suoraan päähaaraan, myös ratkaisemaan tähän liittyvät toissijaiset kulttuuriset haasteet.

Kuinka rakentaa tekoälyagentti, joka voi osallistua koodikantaasi turvallisesti

Ensimmäinen lähestymistapani oli luoda koodausstandardien Markdown-dokumentti siten, että Claude Codessa toimiva agenttien parvi tutki koko repositorion edeltävien kuuden kuukauden ajalta ja omaksui käytetyn koodaustyylin, repositorion Claude.md-tiedoston ja ennen kaikkea kaikki GitHubissa olevat kommentit diff-näkymistä, ristiriitojen ratkaisuista, commit-viesteistä ja pull-pyyntöihin tehdyistä muokkauksista.

Tämän jälkeen minulla oli melko vankka koodausstandardien dokumentti, jota täydensin muuttamalla sen Claude Codessa joukoksi taitoja ja komentoja. Niiden avulla kaikki virheenkorjausta varten tuottamani koodi voitiin sovittaa tiimin koodikannassa jo noudatettuihin koodausstandardeihin. Sitten loin toisen aliagentin, joka käyttäisi GitHubin kanssa toimivia koukkuja ja jonka saatoin myös käynnistää manuaalisesti tarkastelemaan kirjoittamaani koodia sekä kommentteja tai korjauksia ja sisällyttämään kaiken tämän koodausstandardien dokumentin täydennykseksi.

Lopulta jo muutaman pull-pyynnön jälkeen tiettyä korjausta varten tuottamani koodi voitiin hyvin helposti muuntaa sellaiseksi koodiksi, jota haluamme nähdä koodikannassa. Tämä tapahtui yksinkertaisen Markdown-dokumentin avulla. Dokumentti toimi jatkuvasti kehittyvänä ja itseoppivana koodaustyylioppaana, jota käynnistettiin useiden cron-ajojen ja Claude Coden automaatioiden kautta.

Agentti on nyt niin hyvä, että pystyn yhdistämään muutokset suoraan päähaaraan.

Miten pienet tuotetiimit voivat lisätä ketteryyttä

Tämä on hyvä esimerkki siitä, miten ylitän perinteisen tuotepäällikön roolin. Perinteisten roolien ylittäminen edellyttää kuitenkin hyviä prosesseja.

Meillä on Linearissa hyvin valmisteltu ja merkitty työjono, ja pidämme pakolliset kokoukset maanantai-, keskiviikko- ja perjantaiaamuisin. Päivinä, jolloin meillä ei ole synkronointikokousta, pidämme itsemme ajan tasalla Slackissa tehtävällä päivittäisellä tilannekierroksella. Kaikki muu priorisointi ja keskustelu tapahtuu reaaliajassa Slackissa.

Tämä ei ehkä ole paras ratkaisu suuremmille yrityksille, mutta yllättyisit siitä, kuinka hyvin se toimii tässä käyttötapauksessa ja kuinka ketteränä se pitää meidät. Aiemmin käytin Google Drivea, laskentataulukoita, asiakirjoja, esityksiä ja miljoonaa muuta sovellusta. Nyt pienenä tiiminä pärjäämme GSuitella, Slackilla, Linearilla ja GitHubilla.

Kevyet tuotepäällikkömenetelmät ovat tärkeitä jatkuvasti kehittyvässä tekoälyn ja suurten kielimallien ympäristössä. Käyttäjäpalautteessa tai mahdollisten kilpailijoiden julkaisuissa voi tapahtua mitä tahansa viikonpäivänä, ja meidän on pysyttävä tilanteen tasalla sekä priorisoitava asioita nopeasti niiden ympärille.

Miten tekoäly pakottaa tuotetiimit ajattelemaan käytäntöjään uudelleen

Käytännöissä suurin uudelleenarvioinnin aihe on se, että kyseessä on nyt todella kehämäinen, loputon käytäntö eikä jotakin, johon liittyisi pysähtyneitä dokumentteja, joita joudut jatkuvasti luomaan ja käyttämään lähteinä.

Työn laajuus alkaa tiiviinä Linear-tehtävänä, jossa on vaihteleva määrä yksityiskohtia. Sen jälkeen käytän tekoälyä testaamaan sitä epäselvyyksien, poikkeustapausten ja eri järjestysvaihtoehtojen varalta ja tiivistän sitä, kunnes se on julkaistavissa pienimpänä mahdollisena kokonaisuutena.

Pienessä etätiimissämme yhteensovittaminen tapahtuu pääasiassa asynkronisesti – lyhyenä Slack-ketjuna, joka päättyy selkeään päätökseen ja seuraaviin toimiin, ja kevyistä päivittäisistä tilannekierroksista huolehtii Geekbot. Viikoittaisilla kolmella tai neljällä tiimikokouksella on kuitenkin edelleen valtava arvo, sillä niiden aikana voimme ideoida yhdessä ja vahvistaa yhteishenkeä.

Validoinnista olen tehnyt tiukempaa, en löysempää. Suuret kielimallit tuottavat yleensä vakuuttavaa roskaa, jos et osaa käyttää niitä oikein, joten jokainen ominaisuuden tai sovelluksen muutos saa pienen arviointikehyksen – realistiset syötteet, odotetut tulosteet ja vastakkainasetteluun perustuvat tapaukset – jonka tekoäly voi auttaa luonnostelemaan, mutta jonka minä kuratoin ja testaan.

Toteutus on sitten vain Linear + Claude Code + itse ylläpidetty Posthog-analytiikka. Julkaise, havainnoi, säädä ja pidä kierros nopeana, koska teknologiamarkkinat muuttuvat nykyään vauhdilla, joka tuntuu tuntikohtaiselta.

Miksi minimalistinen, tekoäly ensin -työkalupino on paras

Tässä on siis perus-PM-työkalupinoni:

• GSuite
• Slack
• Geekbotin Slack-botti (päivittäisiä tilannekatsauksia varten)
• Linear
• VSCode
• CLI-pohjainen LLM (meidän tapauksessamme Claude Code)

Miksi Linear? Siinä on vain olennaiset ominaisuudet. Se on riittävän tehokas täyttämään lähes kaikki projektitiimin tarpeet, mutta samalla riittävän yksinkertainen lähestyttäväksi. Se on JIRA:n vastakohta. Ja mikä tärkeintä, se integroituu helposti GitHubiin ja Slackiin, joissa insinöörit muutenkin työskentelevät. Se on yksinkertainen ja kevyt, ja se lisää vain vähän ylimääräistä kitkaa siihen, että insinöörit pysyvät tehtävien tasalla tai päivittävät niitä. Se on myös erittäin laajennettava, joten voit tehdä hienoja asioita, kuten antaa komentorivillä toimivan LLM:n yrittää automaattisesti korjata bugin, kun se ilmoitetaan luonnos-PR:ssä – ennen kuin ihminen edes alkaa tarkastella sitä.

Mitään muuta ei tarvita. Kaiken tämän ulkopuolisen työn voi tehdä avoimen lähdekoodin työkaluilla päätelaitteessa.

Colen suosikkitekoälytyökalu henkilökohtaiseen tuottavuuteen

Henkilökohtaisen tuottavuuden ja tiimityön ulkopuolisella tasolla olen täysin koukussa Raycastiin. Se on äärimmäisen nopeasti käytettävä, täysin mukautettava ja ultrakevyt sovellus, joka korvaa Macin surkean ”Spotlight”-sovelluksen tai Windowsin ”Windows”-näppäimen. Hiiren käyttösi vähenee useimmissa asioissa 75 prosentilla. Voit integroida lähes minkä tahansa sovelluksen niiden valmiiden integraatioiden avulla tai luoda helposti omia mukautettuja integraatioita — pyydä vain Claude Codea tekemään sinulle laajennus!

Jos haluan saada näkemäni kuvan tekstin leikepöydälle, painan Raycastin pikanäppäimiä, kirjoitan ”OCR” ja painan Enter-näppäintä. Se käynnistää CleanShotX:n OCR-kuvakaappaustyökalun, ja saan minkä tahansa kuvan tekstin alle viidessä sekunnissa. Vastaavasti voin painaa pikanäppäintä, kirjoittaa ”Ask Spotify” ja sitten kirjoittaa luonnollisen kielen lauseen, kuten ”anna minulle energistä musiikkia koodaamiseen”. Se tulkitsee lauseeni LLM:n avulla, hakee musiikkitunnisteita ja ominaisuuksia Spotifyn API:sta ja käynnistää Spotifyssa välittömästi soittolistan pyytämäni kaltaisesta musiikista.

Käyttötapauksia on loputtomasti. Lataa se vain, aktivoi tekoäly joko omilla API-avaimillasi tai heidän tilauksellaan ja tutustu heidän verkkosivustonsa suosituimpiin laajennuksiin löytääksesi asioita, joista voisi olla sinulle hyötyä. Täydellinen pelinmuuttaja.

Miksi tuotehallinta ja ohjelmistokehitys alkavat limittyä

Pian useimmat ominaisuuksien parissa työskentelevät insinöörit joutuvat ajattelemaan ja tekemään päätöksiä kuten tuotepäälliköt, ja tuotepäälliköiden on opittava riittävästi koneoppimisesta, neuroverkoista, LLM:istä ja erilaisista arkkitehtuureista päästäkseen mahdollisimman lähelle LLM:iä käyttävää insinööriä ilman, että heistä kuitenkaan tulee sellaisia. Tämä muutos heijastaa rohkeita lähestymistapoja tekoälyn integrointiin, jotka muovaavat perinteisiä rooleja uudelleen.

On selvää, että tähän liittyy monia poikkeuksia ja alueita, joilla tämä ei päde, mutta yleisesti ottaen yrityksen kaikkien aiempien roolien – myynnistä markkinointiin, tuotteisiin ja ohjelmistokehitykseen – Venn-diagrammi sulkeutuu väistämättä toistensa ympärille, ja vain hyvin harvat taidot ovat yksinomaan tietyn roolin käytössä.

Kuinka välttää väistämätön eksistentiaalinen kriisi tekoälyn muokatessa tuotetyötä

Tässä on neuvoni: Yritä välttää väistämätön eksistentiaalinen kriisi, jonka kokemiseen saatat tuntea houkutusta teknologian aikakauden jatkaessa kehittymistään.

Keskity sen sijaan taitoihin, jotka mielesi hallitsee ja joita olet kehittänyt kokemuksen kautta. LLM:t voivat tuottaa sisältöä, mutta ne ovat todella surkeita hyvän maun suhteen.

Vastauksia saa nykyään pilkkahintaan, joten ainutlaatuisten ja kokemukseen perustuvien kysymysten esittäminen tekoälylle on nykyään taito. Lisäksi oikean kysymyksen keksiminen omassa mielessäsi on todellista älyllistä työtä.

Seuraa mukana

Voit seurata Colea X:ssä ja hänen henkilökohtaisella verkkosivustollaan, kun hän jatkaa PM-roolien mahdollisuuksien haastamista. Tutustu myös Probably.deviin!

Lisää asiantuntijahaastatteluja on luvassa The Digital Project Managerissa!