Tuoteasiantuntija jakaa suunnittelun ja koodauksen työnkulun, joka korvaa insinööritiimille siirrot

Anton Ingachev on Mini Apps Builderin perustaja. Mini Apps Builder on kooditon alusta Telegram-sovellusten rakentamiseen, ja hän vastaa siellä tuotteesta. Tätä ennen hän toimi useissa CPO:n ja tuotejohtajan tehtävissä.

Keskustelimme Antonin kanssa siitä, kuinka hän karsii ohjelmistokehityksen siirtovaiheita koodaamalla pieniä ominaisuuksia itse. Näin hän kertoi meille.

AI:n pariin tarpeen pakottamana

Olen työskennellyt tuotetehtävissä yli kymmenen vuotta — finanssiteknologian, shakkialustojen, lohkoketjujen ja terveysteknologian parissa. Olen toiminut kahdesti CPO:na ja kerran tuotejohtajana.

AI-matkani alkoi käytännön tarpeesta, ei strategiasta. Noin puolitoista vuotta sitten olin perustamassa Mini Apps Builderia — B2B2C-mallista kooditonta alustaa Telegram-sovellusten rakentamiseen. Ei-teknisenä CPO:na tarvitsin mahdollisuuden julkaista ominaisuuksia nopeasti odottamatta koko kehityssykliä. Silloin aloin käyttää Claude Codea ja Cursor​ia päivittäin, en enää vain dokumentointiin tai prototypointiin, vaan myös tuotantotyöhön.

Osoittaakseni sen koko potentiaalin rakensin yksin tuotantovalmiin tuotteen — arkkitehtuurin, taustajärjestelmän, käyttöliittymän, kaiken — AI-työkaluja käyttäen ja ilman ohjelmistokehitystiimiä. Silloin ajatus muuttui muotoon ”käytän AI:ta työskentelyni nopeuttamiseen” ja siitä muotoon ”pystyn rakentamaan ja julkaisemaan oikeita tuotteita itse”.

Nyt sovellan samaa lähestymistapaa Mini Apps Builderissa — rakennan joitakin ominaisuuksia suoraan sen sijaan, että vain määrittelisin ne ohjelmistokehittäjille.

Polkuni ei siis ollut ”luin AI-muutoksesta ja päätin johtaa sitä”. Sen sijaan tarvitsin mahdollisuuden edetä nopeasti ilman suurta tiimiä; AI teki tämän mahdolliseksi, ja nyt ajattelen tuotestrategiaa eri tavalla sen ansiosta — jokaiseen tiekarttapäätökseen sisältyy nykyään kysymys: ”Pystyykö AI hoitamaan tämän vai ainoastaan tukemaan sitä?”

Miten AI korvaa vanhan siirtomallin tuotetyön työnkuluissa

Vuosien ajan uskoin, että tuotepäällikön työ päättyi määrittelyyn. Kirjoitat vaatimukset, mutta et koske koodiin — se kuuluu ohjelmistokehittäjälle. Tämän rajan ylittäminen tuntui toisten tontille astumiselta.

Se on suurin asia, jonka AI on muuttanut tuotemaailmassa. Nyt hoidan yksinkertaiset ominaisuudet itse. Rakennan ne Claude Coden avulla ja julkaisen ne suoraan odottamatta ohjelmistokehityksen kapasiteettia.

Tämä tarkoittaa, että voimme karsia kokonaisen siirtovaiheen. Sen sijaan että etenisimme määrittelystä → ohjelmistokehityksen tarkistukseen → rakentamiseen → laadunvarmistukseen, rakennan ja testaan usein suoraan itse.

Julkaisemme nyt kahden hengen tiimillä kaksi tai kolme ominaisuutta viikossa — verkkosivustolle, kauppiasnäkymään, itse Telegram Mini Appiin ja sisäiseen ylläpitopaneeliin. Tämä tahti ei olisi mahdollinen vanhalla siirtomallilla.

Se muutti myös tapaani ajatella tiimirakennetta. Rajoite ei enää ole ”Kuinka monta ohjelmistokehittäjää meillä on?” Sen sijaan kysymys kuuluu: ”Kuinka hyvin pystyn määrittelemään, mitä haluan?”

AI:n mahdollistama ominaisuuksien kehitystyönkulku

Tältä ominaisuuksien kehittäminen näyttää:

1. Kuvaan tehtävän huipputason mallille, kuten Claude Codelle. Kerron, mistä pidän, mistä en pidä, mitä ongelmaa ratkaisemme ja mitä ei saa unohtaa tai rikkoa. Annan viitteitä — joskus suoraan kilpailijoilta, mutta en aina.
2. Malli tuottaa yksityiskohtaisen suunnitelman. Luen sen. Tarvittaessa teen muokkauksia tai haastan suunnitelman.
3. Pyydän Claudea toteuttamaan suunnitelman koodina.
4. Luon PR:n, joka käy läpi automaattiset tarkistukset ennen kuin se osoitetaan CTO:lle.
5. Jos kaikki on kunnossa, CTO yhdistää sen kehitysympäristöön, ja testaan sen tuotteessa.
6. Jos jokin on pielessä, CTO jättää kommentteja, pyydän mallia korjaamaan ne ja prosessi toistuu.
7. Jos jokin on täysin pielessä, keskustelen CTO:n kanssa siitä, miten LLM:lle annettuja ohjeita voi parantaa, ja toistan prosessin.
8. Kehitysympäristössä testaamisen jälkeen viemme muutokset tuotantoon.

Antonin ajatuksia

Kerron, mistä pidän, mistä en pidä, mitä ongelmaa ratkaisemme ja mitä ei saa unohtaa tai rikkoa.

Missä AI:ta voidaan hyödyntää tuotetyön työnkuluissa

Tärkeimmät käyttämäni tekoälytyökalut ovat Claude Code, Codex, Cursor, Gamma, Midjourney ja Figma Agent. Tässä on muita tapoja, joilla käytän tekoälyä tuotetyönkuluissa, sekä joitakin sen hyötyjä:

1. Koko tuotteemme — käyttöliittymät, blogi, ohjekeskus ja tuotepäivitysartikkelit — käännetään 20 kielelle lähes reaaliajassa yhdellä napsautuksella.
2. Kielimallin kirjoittamat blogiartikkelit lähes kaksinkertaistivat hakuliikenteemme — ja artikkelien tekemiseen kuluu murto-osa aiemmasta ajasta.
3. Tuotepäällikkönä tekoäly helpottaa omien ajatusteni haastamista — voin pyytää sitä etsimään tietoa, joka joko tukee ajatuksiani tai osoittaa ne vääriksi.
4. Julkaisutietojen kirjoittaminen ei ole enää ongelma, koska tekoäly hoitaa sen lähes automaattisesti.

Rehellisesti sanottuna en osaa nimetä paikkaa, jossa tekoälystä ei olisi apua. Lähes kaikkialla sen käyttö tuo selkeää hyötyä. Ihmisten täytyy toki tarkistaa, säätää ja kouluttaa sitä, mutta aina kun tavoite on selkeä ja ymmärretään, miten se voidaan saavuttaa tekoälyn avulla, prosessi paranee.

Miksi tekoäly tarvitsee asianmukaisen kontekstin ennen työnkulkuihin integroimista

Tekoälyn kohdalla konteksti on kaikki kaikessa.

Aiemmin kirjoitin blogiartikkeleita hakukoneoptimoinnin asiantuntijan toimeksiannon perusteella. Siihen kului kahdesta kolmeen tuntia. Sitten latasin projektin kontekstin kielimalliin ja syötin toimeksiannon sille suoraan — nyt artikkelien tekemiseen kuluu 5–7 minuuttia. Ja kuten edellä totesin, niiden laatu on parempi, mikä on johtanut liikenteen kaksinkertaistumiseen.

Kun kuitenkin pyysin hakukoneoptimoinnin asiantuntijaa kirjoittamaan artikkelit tekoälyn avulla, yllätyin tulosten heikosta laadusta. Syy? Hänen kielimallillaan oli käytettävissään paljon vähemmän projektin kontekstia kuin omallani.

Työnkulusta riippumatta panosta kontekstin tarjoamiseen tekoälytyökaluillesi!

Miksi tuotejohtajien on uudistettava joitakin tuotetyönkulkuja, mutta ei välttämättä kaikkia

Neuvoni? Integroi tekoäly useimpiin prosesseihisi heti. Nyt ei enää eletä vuotta 2022; sen arvo on nykyään selvä. Tekoäly on välttämättömyys.

Tuotejohtajien tulisi arvioida uudelleen jokainen prosessi ja työkalu, joita on aiemmin pidetty optimaalisina. Se ei kuitenkaan välttämättä tarkoita, että kaikki pitäisi uudistaa tekoälyn avulla. Sinun on ymmärrettävä tekoälyn rajoitukset, omat vahvuutesi ja heikkoutesi, tuote, jonka parissa työskentelet, budjetit ja niin edelleen.

Ratkaisu näyttää erilaiselta jokaisessa projektissa. Kaikki on joustavaa. Vakiintuneita parhaita käytäntöjä ei ole. Se vaikeuttaa asioita.

Ainoa tapa selvittää asia oman tuotteesi kohdalla on käytännön kokeilu.

Antoniin ajatuksia

Neuvoni? Integroi tekoäly useimpiin prosesseihisi heti. Nyt ei enää eletä vuotta 2022; sen arvo on nykyään selvä. Tekoäly on välttämättömyys.

Pysy mukana

Voit seurata Anton Ingachevin työtä LinkedInissä ja GitHubissa. Tutustu myös Mini Apps Builderiin.

Lisää asiantuntijahaastatteluja on tulossa The CPO Clubiin!