>Az AI nem a munkámat veszi el, hanem a szakmai biztonságérzetemet

Van az a pillanat, amikor az ember nem azért ijed meg az AI-tól, mert valami lenyűgözően okosat csinál. Hanem azért, mert valami egészen hétköznapit csinál elég jól.

Nem világmegváltó választ ad. Nem talál ki egy új üzleti modellt. Nem érti meg helyettünk az ügyfelet, a szervezetet, a fejlesztői kompromisszumokat vagy a régi döntésekből hátramaradt technikai adósságot. Csak megír egy elfogadható első verziót: egy specifikációt, egy összefoglalót, egy stakeholder-emailt, egy backlog-tétel bontását, egy kutatási jegyzet kivonatát.

A kellemetlen rész nem az, hogy tökéletes. Hanem az, hogy nem az. Pont elég közepes ahhoz, hogy az embernek rossz érzése legyen tőle.

Korábban az ilyen első verziók előállítása idő volt. Le kellett ülni, össze kellett szedni a gondolatokat, meg kellett keresni a megfelelő szavakat, majd valamilyen szerkezetbe kellett rendezni a dolgot. Ettől persze nem lett automatikusan jó. Sok első verzió régen is gyenge volt, csak jobban látszott rajta az emberi erőfeszítés. Volt benne egyfajta szakmai súly, mert időbe került.

Most ez a súly kezd eltűnni. Az AI nem minden munkát vesz el, hanem bizonyos munkarészek árát viszi le nagyon gyorsan. Főleg az első verzióét.

A product managementben ez különösen furcsa érzés. Nem azért, mert a product manager munkája kizárólag szöveggyártás lenne. Szerencsére nem az. De a munkánk nagy része mégis nyelven keresztül történik. Megértünk, lefordítunk, pontosítunk, szűrünk, összefoglalunk, keretezünk. Üzleti igényből fejlesztési feladatot csinálunk. Felhasználói zavarból döntési helyzetet. Félmondatos stakeholder-elvárásból valamilyen vállalható termékirányt.

Sokáig ebben volt egy kényelmes szakmai önkép. A product manager az, aki átlát. Aki kapcsolatot teremt. Aki ért annyira az üzlethez, hogy ne csak ticketeket gyártson, és ért annyira a fejlesztéshez, hogy ne csak vágyakat fogalmazzon meg. Aki leül a sok zavaros input közé, és valami használhatót rak össze belőle.

Aztán megjelenik egy eszköz, amelyik a zavaros inputból szintén valami használhatót rak össze. Nem véglegeset. Nem igazán felelőset. Nem feltétlenül jót. De használhatót. És ez az a pont, ahol a kérdés már nem technológiai, hanem személyes.

A jelenlegi kutatásokból sem az látszik, hogy lenne egy tiszta válasz. Nem az történik, hogy az AI mindenhol látványosan gyorsít, és nem is az, hogy mindenhol kárt okoz. Inkább az látszik, hogy nagyon sok múlik a munka természetén, a tapasztalati szinten, a kódbázis állapotán, a szervezeti környezeten és azon, hogy az AI-t mire használják.

Van olyan kutatás, ahol a generatív AI mérhető produktivitásnövekedést hozott. Ügyfélszolgálati környezetben például kimutatták, hogy a támogatott munkatársak több ügyet tudtak megoldani óránként. Ez érthető is: ha a munka sok ismétlődő mintából, nyelvi válaszadásból és ismert problémák kezeléséből áll, az AI tényleg gyorsíthat.

A szoftverfejlesztésnél viszont vegyesebb a kép. Vannak elemzések, amelyek nagy potenciált látnak a fejlesztési ciklus gyorsításában, a minőség javításában, a fejlesztői flow erősítésében. Közben vannak olyan kontrollált vizsgálatok is, ahol tapasztalt fejlesztők érett, komplex open-source projektekben lassabban végeztek AI-eszközökkel, mint nélkülük. A résztvevők azt hitték, gyorsultak. A mérés viszont mást mutatott.

Ez a kettősség fontos, mert a legtöbb szakmai beszélgetésben az AI hatását még mindig túl egyszerűen kezeljük. Vagy azt mondjuk, hogy minden gyorsabb lesz, vagy azt, hogy ez csak hype. Egyik sem elég pontos. Sokkal valószínűbb, hogy az AI bizonyos feladatokat olcsóbbá tesz, másokat összezavar, néhány munkafolyamatot radikálisan átrendez, és közben új hibaforrásokat hoz be.

Az IT-ban ez azért különösen erős, mert itt a munka jelentős része már eleve absztrakciókkal történik. Kód, specifikáció, API, adatmodell, felhasználói történet, döntési logika, architektúra. Ezek mind olyan dolgok, amelyek nyelvben és struktúrában is léteznek. Márpedig a generatív AI pont ott erős, ahol nyelvi és strukturális mintákból kell elfogadható következő lépést előállítani.

De az elfogadható következő lépés nem ugyanaz, mint a jó döntés. Ez product managerként talán a legfontosabb mondat.

A product management sok helyen eleve furcsa szerep. Nem teljesen üzleti, nem teljesen technikai, nem teljesen design, nem teljesen menedzsment. Pont ez benne a szép, és pont ez benne a veszélyes.

A jó product manager összeköt. A rossz product manager közvetít.

A kettő között kívülről néha alig látszik a különbség. Mindkettő meetingeken ül. Mindkettő dokumentumokat ír. Mindkettő roadmapről beszél. Mindkettő Jira-t néz, ügyfelekkel beszél, fejlesztőkkel egyeztet, demót tart, scope-ot magyaráz.

Csakhogy az egyik szerep valódi termékgondolkodást végez. Megérti, mi a probléma. Képes kimondani, mi nem az. Látja, hol csúszik szét az üzleti vágy és a technikai realitás. Észreveszi, amikor egy feature valójában csak egy rosszul megfogalmazott szervezeti feszültség. Képes nem csak megírni a következő ticketet, hanem megkérdőjelezni, hogy kell-e egyáltalán.

A másik szerep főleg forgalomirányítás. Jön egy igény, lesz belőle feladat. Jön egy kérdés, lesz belőle válasz. Jön egy meeting, lesz belőle jegyzet. Jön egy konfliktus, lesz belőle kompromisszumos mondat egy dokumentumban.

Az AI az utóbbiba nagyon gyorsan bele tud harapni. Nem azért, mert érti a szervezetet. Hanem azért, mert a közvetítői munka nagy része nyelvi formaadás. És a nyelvi formaadás első verziója ma már olcsó. Ezzel nem azt mondom, hogy felesleges lett. Csak azt, hogy már nem elég önmagában szakmai védőfalnak.

Ez a felismerés lassan érkezik. Egy-egy feladatnál. Egy-egy dokumentumnál. Egy-egy prompt után. Megíratod vele azt, amit tegnap még te írtál volna meg. Aztán átolvasod. És van benne valami. Nem elég jó. De van benne valami. Ez a valami kezdi ki a biztonságérzetet.

A legtöbb félelem rosszul van megfogalmazva. Nem attól tartok, hogy az AI holnap product manager lesz helyettem. Legalábbis nem így. Nem fog beülni a nehéz stakeholder-meetingre, nem fogja vállalni a döntés következményét, nem fogja megérezni, hogy a csend a megbeszélés végén valójában ellenállás, nem fogja tudni, melyik régi ígéret miatt érzékeny most mindenki egy látszólag apró scope-vágásra.

Az AI-nak nincs szervezeti emlékezete, csak kontextusa. És a kettő nem ugyanaz.

A szervezeti emlékezet nem csak adat. Hanem tapasztalat arról, hogy itt miért nem működött valami korábban. Ki miben csalódott. Melyik döntést nem zárták le rendesen. Hol van kimondatlan félelem. Melyik stakeholder mond igent úgy, hogy közben valójában nemet gondol. Ezeket nem lehet egyszerűen beönteni egy promptba, még akkor sem, ha egyre több dokumentumot tudunk feltölteni.

Mégsem nyugtat meg teljesen, hogy vannak dolgok, amiket az AI nem tud. Mert közben nagyon sok dolgot tud elég jól.

A munkahelyeken nem mindig a tökéletes megoldás nyer. Sokszor az olcsóbb, gyorsabb, most erre elég lesz típusú megoldás nyer. A legtöbb szervezet nem filozófiai igényességgel optimalizál. Hanem határidőre, költségre, kapacitásra, belső nyomásra. Ha valami korábban fél nap volt, most pedig húsz perc, akkor azt a különbséget valaki előbb-utóbb észreveszi.

Nem az a kérdés, hogy az AI jobb-e nálam. Hanem hogy a szervezet mikor mondja azt: erre a munkarészre ez most elég.

Az IT-ban különösen érzékeny kérdés, hogy mi történik a belépő szintű munkákkal. Sok szakmában a kezdők régen pont azokon a feladatokon tanultak, amelyeket ma az AI a legkönnyebben megtámogat vagy kivált. Egyszerűbb implementációk. Tesztírás. Dokumentáció. Elemzések első verziója. Supportból jövő problémák rendezése. Piackutatási anyagok összefoglalása.

Ezek nem voltak mindig izgalmas feladatok, de tanulási feladatok voltak. A szakmai fejlődés sokszor nem nagy stratégiai döntésekkel kezdődik, hanem apró, ismétlődő, részben unalmas munkákkal. Az ember megtanulja, hogyan néz ki egy rossz ticket. Hogyan csúszik félre egy látszólag egyértelmű igény. Hogyan lesz egy csak egy kis módosításból két sprintnyi munka. Hogyan kell kérdezni, amikor valaki túl magabiztosan állít valamit.

Ha ezekből a feladatokból túl sokat vesz át az AI, akkor nemcsak kapacitást szabadít fel. Tanulási útvonalakat is eltüntethet.

Ez product oldalon is igaz. Egy kezdő productos nem úgy lesz jó, hogy rögtön nagy termékstratégiát ír. Hanem úgy, hogy végigmegy sok apró munkán. Jegyzetel. Ticketet ír. Ügyfélmondatokat rendez. Összeveti, hogy amit az üzlet kért, abból mit értett a fejlesztő. Megtanulja, melyik mondat veszélyes, melyik túl homályos, melyik túl konkrét, melyik takar valójában döntéshiányt.

A tapasztaltabbaknak az AI még előny lehet. Van mihez mérniük a gépet. Észreveszik a hiányt, a hamis magabiztosságot, a rossz absztrakciót. De aki még nem építette fel a saját belső mércéjét, annak az AI nemcsak gyorsító, hanem torzító is lehet.

A válasz kényelmetlenebb, mint szeretném.

Nem azért, mert úgy gondolom, hogy a product managementnek vége. És nem is azért, mert hirtelen fejlesztő akarok lenni a szó klasszikus értelmében. Inkább azért, mert egyre kevésbé érzem elégnek azt a szerepet, amely csak beszél a technológiáról, de nem tud elég közel menni hozzá.

Régen sok helyzetben elég volt érteni a fejlesztőket. Tudni, hogy mi a különbség egy frontend és backend feladat között. Érezni, hogy miért nem mindegy az adatmodell. Megérteni, hogy egy integráció miért csúszhat. Nem kellett mindent megépíteni, de kellett elég technikai empátia ahhoz, hogy a product döntés ne legyen légből kapott.

Most ennél több kellhet. Nem azért, mert minden product managernek senior engineerré kell válnia. Hanem azért, mert az AI-al a prototipizálás, a belső eszközépítés, az adatlekérdezés, a workflow-automatizálás és a gyors kísérletezés sokkal közelebb jött a product munkához. Amit korábban csak kérni tudtunk, abból ma bizonyos szinten már próbálni is tudunk.

Ez megváltoztatja a szerepet. Ha van egy ötlet egy belső adminfolyamatra, nem biztos, hogy az első lépés egy hosszú specifikáció. Lehet, hogy az első lépés egy működő prototípus. Ha van egy termékhipotézis, nem biztos, hogy először prezentációt kell írni róla. Lehet, hogy össze kell rakni egy tesztelhető változatot.

Fejlesztettem saját termékeket, ezért ez a rész nem teljesen idegen terep. Építettem rendszereket, raktam össze működő dolgokat, és mindig is érdekelt, hogyan lesz egy gondolatból használható szoftver. Az AI miatt ez nem kevésbé, hanem sokkal fontosabb lett. Ha a prototípus olcsóbb, ha a kód közelebb jön, ha egy product manager már nemcsak specifikálni tud, hanem bizonyos szinten építeni is, akkor természetes, hogy az ember ebbe az irányba mozdul.

De nálam ezzel párhuzamosan elindult egy másik, elsőre kevésbé logikus irány is.

Elindultam az épületvillamosság felé.

Ez kívülről talán furcsának tűnik. Mi köze van egy product managernek a védővezetőhöz, a kiselosztóhoz, a PEN szétválasztáshoz, a konnektorokhoz, a kötődobozokhoz, a szabványokhoz vagy ahhoz, hogy egy falban merre megy egy vezeték? Látszólag semmi. Valójában viszont nagyon is sok.

Mert az épületvillamosságban nincs undo gomb.

Ha egy digitális termékben rosszul nevezünk el egy mezőt, átírjuk. Ha egy képernyő rossz helyre tesz egy gombot, javítjuk. Ha egy prototípus nem működik, kidobjuk. Persze ezeknek is van ára, de a legtöbb szoftveres hibában még ott van az a kényelmes gondolat, hogy majd iterálunk.

A villanynál ez másképp van. Ott az anyag ellenáll. A fal nem absztrakció. A vezeték keresztmetszete nem vélemény. A kötés vagy jó, vagy veszélyes. A szabvány nem stakeholder-preferencia. És ha valamit rosszul értesz, annak nem csak esztétikai vagy üzleti következménye lehet, hanem nagyon konkrét fizikai kockázata.

Ez a fajta világ furcsán megnyugtató lett. Nem azért, mert egyszerűbb. Sok szempontból sokkal szigorúbb. Hanem mert nem engedi meg azt a lebegést, ami a digitális munkában néha túl könnyen természetessé válik. A product munkában sokszor szavakkal dolgozunk. Keretezünk, pontosítunk, döntést készítünk elő, verziókat gyártunk. Az AI pedig pont ebbe a nyelvi térbe lépett be nagyon erősen. Ettől néha minden kicsit puhábbnak, cserélhetőbbnek, gyorsabban előállíthatónak érződik.

Az épületvillamosság ezzel szemben visszaránt a valóságba. Ott nem elég, hogy valami jól hangzik. Nem elég, hogy logikusnak tűnik egy rajzon. Nem elég, hogy valaki magabiztosan megfogalmazza. Meg kell érteni, hogyan működik. Mi van előtte, mi van utána, hol záródik az áramkör, mi történik hiba esetén, mit véd a kismegszakító, mit véd az áram-védőkapcsoló, és mit nem véd egyik sem.

Ez nem prompt kérdése. Ez rendszerértés.

Miközben az AI egyre több szöveges, digitális, első verziós munkát tesz olcsóbbá, egyre nagyobb értéke lesz annak, ha az ember olyan rendszereket is megért, amelyek nem engedik magukat pusztán nyelvben kezelni. Ahol a tudás nem csak abban látszik, hogy mit tudsz leírni, hanem abban is, hogy mit mersz vagy nem mersz bekötni. Mit ellenőrzöl kétszer. Hol állsz meg. Mikor mondod azt, hogy ezt már nem szabad találgatásból csinálni.

A fejlesztés tanulása közelebb visz ahhoz, hogy digitális rendszereket tudjak építeni. Az épületvillamosság tanulása pedig közelebb visz ahhoz, hogy ne felejtsem el: a világ nem csak szoftverből áll. Vannak benne anyagok, szabályok, kockázatok, következmények és olyan hibák, amelyeket nem lehet egy új release-ben csendben javítani.

Lehet, hogy ez a két irány kívülről ellentétesnek látszik. Nekem egyre inkább ugyanarról szól. Arról, hogy nem akarok csak közvetítő lenni. Nem akarok kizárólag olyan ember lenni, aki mások munkáját megfogalmazza, rendszerezi és priorizálja. Építeni akarok. Digitális rendszereket is, és legalább érteni akarom a fizikai rendszereket is. Nem feltétlenül ugyanazon a szakmai mélységen, nem ugyanazzal a szereppel, de ugyanazzal az igénnyel: közelebb menni ahhoz, aminek következménye van.

Sok AI-ról szóló szakmai beszélgetésből hiányzik a félelem normális kezelése. Vagy túl nagyra van fújva, vagy le van nézve. Mintha aki fél, az nem értené a technológiát. Mintha a jó szakember csak kíváncsi lehetne, szorongó nem.

Szerintem ez nem igaz. A félelem itt nem irracionális. Legalábbis nem teljesen. Ha valaki évekig épített egy szakmai identitást bizonyos munkamódokra, és ezek a munkamódok hirtelen megváltoznak, akkor teljesen érthető, hogy meginog. Nem azért, mert gyenge. Hanem mert figyel.

Aki ma productban, fejlesztésben, designban, kutatásban vagy bármilyen tudásmunkában nem érez semmilyen feszültséget, az lehet, hogy nagyon stabil. De az is lehet, hogy nem nézett még rá elég őszintén arra, mi történik.

A félelem persze önmagában nem stratégia. Nem lehet belőle karriert építeni, és nem lehet rá termékdöntéseket alapozni. De jelzésnek jó. Megmutatja, hol van valami, amit eddig adottnak vettünk. Hol van olyan szakmai komfort, amely talán már nem lesz sokáig komfort.

Nálam ez valahol ott van, hogy nem akarok pusztán olyan ember lenni, aki jól megfogalmazza mások munkáját. Ez kemény mondat, mert a jó megfogalmazás továbbra is érték. A pontos nyelv nagyon fontos. A termékfejlesztésben rengeteg kár származik abból, amikor rosszul nevezünk meg dolgokat. De a megfogalmazás mögött egyre erősebben kell lennie saját gondolkodásnak, technikai közelségnek, döntési bátorságnak és felelősségnek.

Az AI-al nem az történik, hogy a szöveg eltűnik. Hanem az, hogy a szöveg önmagában kevésbé bizonyítja, hogy mögötte gondolkodás van.

Nem hiszem, hogy egyetlen nagy törés jön. Inkább sok kicsi.

Bizonyos feladatok eltűnnek a munkanapból. Mások megmaradnak, de kevesebb időt kapnak. Néhány szerep látványosan átalakul. Sok szervezet pedig egy ideig úgy fog tenni, mintha csak új eszközöket vezetett volna be, miközben valójában a munkamegosztás változik meg.

Az IT-ban a fejlesztés egy része gyorsabb lesz, de nem feltétlenül egyszerűbb. Ha gyorsabban lehet kódot írni, gyorsabban lehet rossz kódot is írni. Ha könnyebb prototípust építeni, több félkész ötlet fog termékszerűnek látszani. Ha olcsóbb az első verzió, nagyobb lesz a kísértés, hogy kevesebbet gondolkodjunk előtte.

A product managementben ugyanez történhet. Több anyag készül majd. Több változat, több opció, több szintetizált insight, több automatikus összefoglaló. Ettől nem biztos, hogy több jó döntés születik. Sőt, az egyik legnagyobb veszély éppen az lehet, hogy a döntés-előkészítés látványosan javul, miközben maga a döntési minőség nem.

Szebb dokumentumokból is lehet rossz terméket építeni.

Ezért érzem azt, hogy a product manager jövője nem a promptoknál dől el. A promptolás fontos készség, de túl kicsi keret. A valódi kérdés az, hogy ki tud AI-al úgy dolgozni, hogy közben nem veszíti el a saját szakmai mércéjét. Ki tudja használni a gyorsaságot anélkül, hogy átadná az ítéletet. Ki tud több változatot kérni, de kevesebb dolgot engedni a rendszerbe. Ki tudja megkülönböztetni a jól hangzó választ a használható döntéstől.

Mert az AI nemcsak segítség. Kísértés is. Kísértés arra, hogy hamarabb érezzük késznek, ami még nincs végiggondolva. Kísértés arra, hogy a formát összekeverjük a tartalommal. Kísértés arra, hogy a van rá válasz érzését összekeverjük azzal, hogy értjük is a problémát.

A saját tanulságom egyelőre nem valami nagy karrierstratégia. Inkább egy irány: közelebb kell menni.

Közelebb a technológiához. Közelebb a kódhoz, még ha nem is fejlesztői identitással. Közelebb az adathoz, hogy ne csak riportokat nézzek, hanem értsem, hogyan jöttek létre. Közelebb a prototípusokhoz, hogy ne csak leírjam az ötletet, hanem kipróbáljam. Közelebb az AI-eszközökhöz, de nem játékos kíváncsiságból, hanem munkamódszerként.

És közben közelebb az anyaghoz is. Olyan rendszerekhez, ahol a valóság nem engedi, hogy egy jól hangzó mondattal megússzuk a pontatlanságot. Ahol a hiba nem csak rossz metrika, hanem rossz kötés, rossz védelem, rossz következmény. Ez nem romantikus menekülés a digitálisból, hanem ellenpont. Egy emlékeztető arra, hogy a gondolkodásnak végül mindig valamilyen valóságban kell megállnia.

Talán ez a pontosabb szó a félelemnél: feszengés. Az az érzés, amikor még nincs tragédia, de a régi testtartás már kényelmetlen. Amikor még működik, amit csinálsz, de már érzed, hogy nem lehet sokáig ugyanúgy csinálni. Amikor nem akarsz pánikolni, de nem akarsz lemaradni sem. Amikor egyszerre vagy kíváncsi, motivált, sértett és bizonytalan.

Szerintem sokan vannak most így az IT-ban. Nem mindenki fogja kimondani. A szakmai kultúránkban nem mindig elegáns bizonytalannak lenni. Könnyebb magabiztosan beszélni agentekről, workflow-król, productivity gainről, új toolingról. Könnyebb úgy tenni, mintha ez csak egy újabb technológiai hullám lenne, amit majd szépen beépítünk a stackbe.

De ez most többnek tűnik egy új eszköznél. Nem azért, mert mindent tud. Hanem mert pont elég sok mindent tud ahhoz, hogy újra kelljen gondolnunk, mihez adunk emberi értéket.

Néhány év múlva valószínűleg mindenki használni fogja valamilyen formában, ahogy ma már senki nem tartja különlegesnek, hogy keresőt, chatet, dokumentummegosztót vagy projektmenedzsment eszközt használ. A különbség inkább abban lesz, hogy ki mire használja.

Lesz, aki arra, hogy gyorsabban termeljen közepes anyagokat. Lesz, aki arra, hogy elfedje a gondolkodás hiányát. Lesz, aki arra, hogy több látszatmunkát csináljon kevesebb idő alatt. És lesz, aki arra, hogy hamarabb eljusson a valódi kérdéshez.

Product managerként engem ez érdekel. Nem az, hogy tud-e az AI PRD-t írni. Tud. Nem az, hogy tud-e user storyt bontani. Tud. Nem az, hogy tud-e research insightokat csoportosítani. Tud. A kérdés az, hogy én tudok-e ezek után jobb döntést hozni. Tudok-e élesebben kérdezni. Tudok-e gyorsabban kidobni rossz ötleteket. Tudok-e közelebb menni a megoldáshoz. Tudok-e kevésbé ragaszkodni ahhoz a munkához, amelyről kiderült, hogy nem is abban volt az igazi értékem.

Ez fájdalmas tanulás lesz. Mert a szakmai identitásunk egy része mindig olyan dolgokra épül, amelyeket sokszor csináltunk, amelyekért megdicsértek, amelyekben ügyesnek éreztük magunkat. Ha ezek egy része hirtelen automatizálhatóvá vagy legalábbis olcsóbban előállíthatóvá válik, akkor nem elég új eszközöket tanulni. Kicsit újra kell tanulni saját magunkat is.

Az AI nem a munkámat veszi el. Legalábbis nem így érzem. Inkább azt a kényelmes szakmai történetet veszi el, amelyben pontosan tudtam, mitől vagyok hasznos. És talán ez a nehezebb.