>A kód még nem termék

01Az AI gyorsabban épít — de nem ad piacot

Az AI látványosan levitte a szoftverépítés határköltségét. Több kód készül, gyorsabban, kevesebb emberrel. A demók sűrűbbek lettek, a release-ek gyakoribbak, a fejlesztési ciklusok rövidebbek. Ezért sok vezetői beszélgetésben ma már nem az a kérdés, hogy „hogyan szállítsunk gyorsabban”. Hanem az, hogy „mit kezdjünk azzal, hogy szállítunk”.

A különbség nem retorikai. A termékfejlesztés középső része — az implementáció, a kódírás, a release — valóban sok helyen gyorsul. A boardok elégedettek. A tulajdonosok egy része abban a hitben él, hogy ha a szoftver gyorsabban készül, akkor a növekedési probléma is megoldódik.

„Csakhogy a vevő figyelme nem nőtt százszorosára."

A vevő költségvetése nem lett nagyobb. A bizalma nem lett olcsóbb. A bevezetési kockázata nem tűnt el. A belső jóváhagyási folyamata nem rövidült le csak azért, mert mi gyorsabban tudunk buildelni.

Egy mondatban: a kínálati oldal AI-skálát kapott, a keresleti oldal ugyanazt a heti tizenkét emailt olvassa el, mint tavaly.

Nem az a lényeg, hogy a gyorsulás pontosan 10x, 30x vagy 100x. Hanem az, hogy a vezetői percepció megváltozott: a kód már nem feltétlenül a legdrágább és leglassabb része annak, hogy valamiből valódi termék legyen.

És ha ez igaz, akkor a szűk keresztmetszet máshová költözött.

02A szűk keresztmetszet átköltözött

Tíz éven át a termékfejlesztés szűk keresztmetszete nagyrészt középen volt: a kódírásnál, az implementációnál, a release-vonalnál. Erre épült az elmúlt évtized sok szervezési divatja: agilis transzformációk, fejlesztői hatékonysági programok, platform engineering, belső toolchain-optimalizálás.

Ha a középen lévő munka AI használatával látványosan gyorsul, akkor a szűk keresztmetszet definíció szerint elmozdul. Két irányba.

Az egyik a ciklus eleje: mit érdemes egyáltalán megépíteni. Melyik problémára van valós fizetési hajlandóság. Melyik szegmens írja le a saját helyzetét úgy, ahogyan arra a mi megoldásunk tényleg választ ad. Mi az a probléma, amit nem mi találtunk ki a whiteboardon, hanem az ügyfél mondott ki a saját nyelvén.

A másik a ciklus vége: hogyan jut el a kész termék odáig, hogy az ügyfél megértse, kipróbálja, bevezesse, megmérje és kifizesse. Hogyan különbözteti meg magát egy olyan piacon, ahol minden héten új AI-termékek tucatjai kérnek bemutatkozási időpontot.

A baj az, hogy ez a két új szűk keresztmetszet drágább, lassabb és nehezebben kiszervezhető, mint a régi.

Egy fejlesztői munkaóra relatív költsége AI-asszisztens mellett sok helyen látványosan csökken. Egy stratégiai beszélgetés ára egy potenciális ügyféllel nem. Egy jó discovery interjú nem lesz százszor gyorsabb. Egy vállalati beszerzési folyamat nem lesz százszor rövidebb. Egy új kategória megértése nem történik meg százszor kevesebb figyelemből.

A kód olcsóbb lett. A piac nem.

03A pozicionálás nem marketingdísz

„A pozicionálás eddig is fontos volt. Mostantól túlélési minimum."

Egy sűrűbb piacon az a tíz–tizenöt szó, amiből az ügyfél két másodperc alatt megérti, hogy érdemes-e ránéznie a kínálatra, többet érhet, mint a következő féléves fejlesztési ütemterv nagy része.

Nem azért, mert a marketing hirtelen fontosabb lett a terméknél. Hanem azért, mert a termék addig nem is létezik üzletileg, amíg a vevő nem tudja elhelyezni a saját fejében.

A rossz pozicionálás régen azt jelentette, hogy lassabban nősz. Egy AI-al túltelített piacon azt jelenti, hogy a vevő nem tudja, hogy létezel. Nem tudja, milyen polcra tegyen. Nem tudja, mihez hasonlítsa. Nem tudja, milyen költségsorból fizesse. Nem tudja, kinek kellene a cégen belül foglalkoznia vele.

És itt jön az a rész, amit sok csapat kihagy.

A működő pozicionálás nem abból a nyelvből épül, ahogyan a fejlesztő elmondja a megoldást. Hanem abból, ahogyan a vevő megfogalmazza a saját problémáját. A kettő szinte sosem azonos.

A fejlesztő funkciókat lát, architektúrát, edge case-eket, modellképességeket, integrációkat. A vevő viszont kockázatot lát, időveszteséget, belső súrlódást, elszálló költséget, auditproblémát, rossz kézi folyamatot, elvesző bevételt vagy olyan munkát, amit senki nem akar tovább csinálni.

A kettő közötti fordítást nem lehet teljesen belső workshopból, AI-personából vagy szintetikus interjúból előállítani. Ezek segíthetnek gondolkodni, de nem helyettesítik a valódi, élő ügyfél-beszélgetéseket.

Aki ezt a munkát a release után akarja elvégezni, az gyakran már elkésett.

Nem azért, mert a termék rossz. Hanem mert a termék már megépült egy olyan feltételezésrendszerre, amit senki nem ütköztetett elég korán a piaccal.

04Amikor a termék valójában szolgáltatás

Most sok AI-cég hirdeti büszkén, hogy forward-deployed engineereket küld az ügyfelekhez: szenior mérnököket, akik a helyszínen segítenek bevezetni a terméket, integrálni a környezetbe, mérni az értéket és átvezetni a szervezetet az első használati eseteken.

Ez önmagában nem baj.

Enterprise környezetben a bevezetés, integráció és változáskezelés mindig munka. Egy komoly vállalati szoftver ritkán úgy terjed, mint egy böngészőbővítmény. Vannak rendszerek, jogosultságok, adatok, folyamatok, ellenállások, mérőszámok és belső döntéshozók.

A forward-deployed modell tehát lehet nagyon racionális go-to-market stratégia.

A baj ott kezdődik, amikor az ügyfélérték nem a termékből, hanem tartósan a mellé rendelt szenior emberből jön létre. Ha az ügyfélnek főállású, szenior mérnökre van szüksége ahhoz, hogy megértse, mit vett, hogyan illeszti a környezetébe, milyen mérőszámon nézze az értékét, és hogyan működtesse a mindennapokban, akkor érdemes feltenni a kérdést: valóban terméket adtunk el?

Vagy inkább eszközkészletet, platformot, keretrendszert és szakértői szolgáltatást csomagoltunk össze termékcímkével?

Ennek három üzleti kockázata van.

Az első: a bruttó árrés könnyen elbújik a szolgáltatási költségben. Egy szoftvercég klasszikus SaaS-margint ígérhet, miközben a működése tartósan szakértői óradíjas tanácsadócéggé alakul.

A második: a skálázódás plafonja a hiring lesz. Forward-deployed engineerből kevés van, drága, hosszú a betanítása, és minden új ügyfél egy emberre vetített maximum kapacitást ró a szervezetre.

A harmadik: az ügyfélnél maradó tudás nem a termékhez, hanem a szolgáltató emberéhez kötődik. Ha az emberi szolgáltatás megáll, a termék nem feltétlenül áll meg helyette.

Egy stratégiai befektető ezt könnyen nem klasszikus szoftvertermékként, hanem magas szolgáltatási komponensű üzletként fogja árazni. A multiplikátor más.

05A solo founder modell határai

A másik divatos történet az egyetlen ember, aki AI-eszközökkel egyszerre tervez, fejleszt, marketingel, ad el és deployol. Ez nem mítosz. Sokszor tényleg működik. Egy jó solo founder AI-eszközökkel ma gyorsabb lehet, mint egy klasszikus, lassú, sokszereplős szervezet. A demók lélegzetelállítóak. A példák ott vannak Twitteren, LinkedInen, indie hacker fórumokon.

„De ebből nem következik, hogy a modell univerzális."

A solo founder stratégia akkor működik kiemelkedően, ha az alapító nagyon közel van a célpiacához. Ideális esetben ő maga is célfelhasználó. Érti a nyelvet, a fájdalmat, a vásárlási logikát, a közösségi csatornákat, a „miért most?” érzését.

Fejlesztőeszközök, AI-rajongóknak szóló produktivitási termékek, kreatív tooling, niche B2C eszközök esetén ez erős minta lehet. A saját ízlés iránytű. A visszacsatolás gyors. A vásárlási folyamat rövid. A felhasználó és az építő világa közel van egymáshoz.

De vidd át ugyanezt a logikát a kórházi adminisztrációra, az építőipari beszerzésre, a tananyagfejlesztésre, az önkormányzati ügymenetre vagy a regulált pénzügyi szolgáltatásokra, és a modell már sokkal törékenyebb.

Nem azért, mert a kód rosszabb lesz. Azért, mert a vevő nem a fejlesztő.

Minél nagyobb a távolság az építő és a vevő világa között, annál többet nyom a latba minden olyan munka, amit a solo modell nehezen tud elvégezni: értékesítés, beszerzés-támogatás, megfelelőség, oktatás, ügyfélkapcsolat, változáskezelés, belső bajnokok építése.

A solo founder modell tehát nem rossz. Csak nem általános üzleti minta. Egyes piacokon kiváló stratégia. Más piacokon veszélyes leegyszerűsítés.

Aki termékkategória-szinten erre fogad, az könnyen két év múlva fogja megkérdezni, hova tűnt a piac.

06Mi fog látszani a következő negyedévekben?

A következő két-négy negyedévben több olyan következmény is láthatóvá válhat, amelyet ma még elfed a fejlesztési sebesség öröme.

Először: sok látványosan szállító AI-termék fog elakadni a piacon, és nem azért, mert a kód rossz volt. Hanem azért, mert kihagyták a vásárlói felfedezést, félrepozicionálták magukat, alulárazták a deployment-akadályokat, és nem olyan felhasználóknak építettek, amilyennek az építők elképzelték őket.

Ezek nem új hibatípusok. Csak az AI sokkal gyorsabban juttatja őket célba.

Másodszor: a board-szintű elvárás továbbra is az lesz, hogy „még gyorsabban szállítsunk”. A release-szám rövid távon fantasztikusan néz ki. Aki most azt mondja, hogy a release nem azonos a bevétellel, azt egy-két negyedéven át könnyen Kasszandrának fogják nézni. Aztán hirtelen nem.

Harmadszor: két képesség fog újra felértékelődni.

A ciklus elején a stratégiai termékgondolkodás: annak az értése, hogy mit érdemes egyáltalán megépíteni, kinek, milyen helyzetben, milyen alternatívához képest. A ciklus végén az igazán erős product marketing: annak az értése, hogyan válik a kódból érthető ajánlat, kipróbálható termék, belsőleg eladható döntés és végül bevétel.

Egyik sem költséghely. Mindkettő azt határozza meg, hogy a felépített termékből pénz lesz-e.

07Mit jelent ez egy vezetőnek?

Nem azt, hogy lassabban kell építeni. A gyorsaság továbbra is előny. Csak önmagában már nem stratégia. A fejlesztési sebesség mellé ugyanolyan fegyelmet kell tenni a piacoldalon is: discoveryt, pozicionálást, bevezetési gondolkodást, pricingot, értékkommunikációt, sales enablementet, ügyfélérték-mérést. Három kérdést érdemes minden új AI-termék előtt feltenni.

Ki mondta ezt a problémát a saját szavaival, nem a mi szavainkkal?

Ha csak belső megfogalmazásunk van a problémára, akkor még nem tudjuk, hogyan fog róla beszélni a piac.

Milyen meglévő költséghez, kockázathoz vagy bevételi lehetőséghez kötődik?

Ha a termék nem kapcsolódik egy már érzett üzleti fájdalomhoz, akkor az ügyfélnek előbb problématudatot kell vásárolnia, és csak utána megoldást. Ez drága út.

Mi fog történni az ügyfélnél a demo és a kifizetett használat között?

A legtöbb AI-termék nem a demóban bukik el. Hanem abban a hosszú, unalmas, politikailag és operatívan nehéz szakaszban, ahol adatot kell adni neki, rendszerekhez kell kötni, embereket kell meggyőzni, kockázatot kell kezelni, és valakinek vállalnia kell érte a döntést. Aki ezekre nem tud válaszolni, az nem terméket gyorsít AI-val. Hanem bizonytalanságot skáláz.

08Zárszó

Az elmúlt évtizedben a sikeres szoftvercégek gyakran azzal védekeztek a piacon, hogy gyorsabban szállítottak. A következő évtizedben azzal fognak, hogy tisztábban értik, kinek és miért szállítanak. A kód olcsóbb lett. A termékké érlelés nem. Aki ezt a két dolgot összemossa, az most nagyon gyorsan, nagyon sok semmit fog termelni.