A sikeres digitális termékek alapelvei túléltek mindent – még az AI-t is

Míg az AI forradalom átalakítja az eszköztárát annak ahogyan digitális termékeket hozunk létre, addig a sikereres productok mögött meghúzódó alapelvek meglepően állandóak maradtak. 

Mostanában – de karrierem során nem első alkalommal – az foglalkoztat, hogyan működnek a szilícium-völgyi tech cégek és miként olyan sikeresek a termék és szolgáltatások biztosításában. A jelenlegi AI helyzet ugyanis felértékelte ezt a tudást, de erről bővebben később. 

Ezért kutatok sokat a témában, olvasok és az egyik friss olvasmányélményemben elég sok értéket fedeztem fel, amit hasznosnak gondoltam megosztani. 

Miről szól a Transformed? 

Marty Cagan a szakma nagy öregje, Inspired című klasszikus könyve – amit idén újra is olvastam a móka kedvéért – közismert a témában, de van egy valamivel újabb műve is a Transformed Moving to the Product Operating Model, ami kifejezetten internet előtt befutott, tehát nem tech cégek számára próbál iránymutatással szolgálni.

Egyrészt a transzformáció kapcsán tartalmaz egy rakás ajánlást, aminek a célja, hogy valami hasonlót tudjanak létrehozni old-school cégek mint a Szilícium-völgyben, ő ezt a keretet product operations modellnek hívja. Viszont van a könyvnek egy olyan viszonylag hosszú része is, ami szintén nagyon értékes, ahol kifejezetteb a sikeres product cégek alapelveit részletezi. 

A folyamatosan értéket teremteni képes – a felhasználónak, és a cég számára – termék biztosításának szabályai Marty Cagan szerint nem változtak.

Kétségtelenül jelen világunkban uralkodik éppen egy diszruptív helyzet. Az AI egyfelől sokkal könnyebbé teszi a productok előállítását, másfelől mégis a kiváló termékek alapelvei ugyanazok maradtak, csak éppen könnyen megfeledkezhetünk róluk. Látni kell azt is, hogy jelenleg megnövekedett a kísértés a deliveryre, mert villámgyorsan lehet szoftvereket és funkciókat elállítani, ez pedig már most is meglévő rossz szokások felerősödését is okozhatja.

Akik most is jók a digitális termékekben – mint a Revolut, Spotify, Amazon – azok biztosan nyertesei lesznek a forradalomnak, viszont az internet előtti hagyományos vállalatok hátrányból indulnak, mert főleg IT driven modellben léteznek, nem tanulták meg ennyi év alatt sem, hogyan tudnak a techcégek olyan sikeresen termékeket biztosítani.

Ezért úgy gondolom a Transformed azon része, ami az alapelvekkel foglalkozik – amire Marty Cagen “termékmodell koncepciókként” hivatkozik -, különösen értékes és időtálló, még az AI diszruptív időszakban is, sőt felértékelődik a szerepe.

A termék modell koncepciók öt, a sikeres termékek szempontjából kritikus pillér mentén – termékcsapatok, termékstratégia, discovery, delivery, termék kultúra – tartalmaznak összesen húsz elvet.

Az irányelv kifejezés talán még jobb, mert azt Marty Cagan többször elismétli a könyvben, hogy jó digitális terméket nem csak egyféleképpen lehet csinálni, ezért termék modell koncepciók bőven hagynak mozgásteret a cégeknek a testreszabásban.

Az alábbiakban az irányelveket ismertetem részletesen.

Termékcsapatok

A tech cégek sikerei mögött álló egyik “titok” a product csapatokban keresendő, amelyek felismerhető minták szerint működnek. A cél, – Marty gyakori kifejezésével élve – hogy a termékcsapatok tagjai “misszionáriusok és ne csak “zsoldosok” legyenek. 

Felhatalmazott csapatok, probléma megoldására

A legfontosabb alapelv a kereszt-funkcionális, felhatalmazott termékcsapat fogalma: olyan szerveződés, ami problémák megoldására van létrehozva, nem csak megoldások szállítására, cserébe felelősséggel tartozik az eredményekért.  

Érdemes észrevenni, hogy ez nagyon más mint az IT modell, ahol “projekt teamek” vannak, amelyek priorizált funkció listák leszállítására jönnek létre. 

Problémák alatt a termékhez köthető problémákra és célokra kell gondolni, például csökkenteni akarjuk a churn ratetet.

A kereszt-funkcionalitás meg azt jelenti, hogy mindegyik képesség jelen van, ami kell a sikeres termékhez: a fejlesztés, a product design és a product management. 

Itt a magyar olvasóknak külön is kiemelném, hogy a product design nem a futottak még kategória, hanem ugyanolyan szintű, kötelező skill a termékcsapatokba mint a másik kettő képesség és szerepkör. 

Az IT szervezetekben – Marty Cagan megfogalmazása szerint – feature teamek vannak, ahol a fejlesztők csak arra kellenek, hogy lekódolják ami a követelményekben szerepel, a designerek meg kicsinosítsák a végeredményt. Gyakorlatilag így értékes szellemi kapacitásokat herdálunk el, zsoldosoknak használjuk ezeket az igen értékes szakembereket. Ha ki vannak szervezve ezek a szerepkörök, akkor még rosszabb a képlet, mert szó szerint zsoldosok szállítanak a cég számára.

A jó termékcsapatban azonban a fejlesztőink nem csak azért vannak, hogy építsenek, és a product designerek sem csak azért, hogy tervezzenek, hanem azért is, hogy segítsenek megtalálni a megfelelő megoldást az adott problémára: ezt jelenti a felhatalmazott product csapat elv.  

Outcomes over Output

Ami a product teamek értelmezhető értékét adja, hogy tevékenységének milyen eredménye lesz a felhasználó/ügyfél és az üzlet számára. 

Ugyan elképzelhető, hogy funkciók szállítása  jó érzéssel tölt el bennünket, azonban ha azok nem eredményeznek kimutatható üzleti eredményt, akkor lényegében kudarcot vallottunk. 

Tetszik a könyvből a “time to money over time to market” megközelítés, ami értelemszerűen arra utal, hogy a lényeg, hogy mennyi idő alatt hoz üzleti eredményt egy termék vagy funkció.

Ownership 

Nagyon egyszerű elv: minden termékcsapatnak felelősséget kell vállalnia valamilyen értelmes dologért. Itt amúgy a csapat szót kiemelném az ownershipet a termékcsapat viseli, nem pedig a product managger.

Lehet, hogy egy teljes termékről beszélünk, de manapság gyakrabban egy sokkal nagyobb product vagy service valamely értelmes részhalmazáról van szó. Nem túl szokatlan, hogy egyetlen terméknél vagy szolgáltatásnál több tucat product team dolgozik.

Marty szerint a termék csapatok felelősséget vállalnak problémák felderítéséért – product discovery – valamint a megoldások kidolgozásáért és az ügyfelekhez való eljuttatásáért – product delivery. 

Egyébként ennek a két felelősségnek a szeparálása különböző teamekbe számos gyakorlati és kulturális problémához vezethet. 

Tényleges kollaboráció

Nyilvánvalóan az együttműködés alapfeladata a termékcsapatoknak. Csakhogy amiről sokan azt hiszik, hogy kollaboráció, az valójában nem kifejezetten az.

Mind a mai napig sok csapat valójában a jó öreg vízesés modellben dolgozik – esetleg agilis fejlesztésnek  átnevezve, de agilitást nyomokban sem tartalmazva –  ahol a product manager/vagy inkább product owner definiálja a követelményeket, átadja a product designernek, hogy álljon elő egy olyan designal, amely megfelel ezeknek a követelményeknek, majd – általában a sprint planningnél – tovább adja a követelményeket és a design terveket a megvalósító fejlesztőknek.

Ez a modell határozottan nem kollaboráció, sőt Marty az Inspired-ben az termék failek egyik fő okának nevezte:

Az egyik dolog, ami kiemelendő, hogy a kollaboráció nem konszenzus Marty szerint: néha egyet nem értés van, és hajlandóak vagyunk elengedni az eredeti elképzelést. Különösen tetszett az a gondolat, hogy a product és service vezetőknek kötelességük megtámadni a vitatható döntéseket, ha nem értenek egyet, még akkor is, ha ez kényelmetlen vagy fárasztó. 

A kollaboráció nem a kézzelfogható outputokról az “artifactekről”szól. Ez alatt azt érti Marty, hogy sok product managger azt gondolja fő feladatának, hogy követelményeket, meg user storikat szállítson. A gond ezzel, hogy amint követelménynek hívunk valamit, akkor azonnal véget ér a beszélgetés és deliverybe fordulunk. 

Ekkor ugyanis a product designer jogosan gondolja, hogy a feladata abban áll, hogy a design megfeleljen a vállalati style guidenak – vagy a design sytemből ki legyen rakva, ami a követelményekben szerepel – a fejlesztő meg hasonlóképpen úgy érezheti, hogy kódolni van csak a csapatban. Ezzel pedig vissza is jutottunk a waterfall modellhez. 

Ideálisan a product teamekben lévő kompetenciák – designer, fejlesztők, product managger – behozzák a szükséges tudást, és köztük intenzív és állandósított kollaborációnak kell történnie – például prototípusok segítségével -, hogy a user és a üzlet is folyamatosan értéket tudjon kivenni a termékből. 

---

Termékstratégia

A termékszintű stratégia azt jelenti, hogy remélhetőleg van egy erős víziónk, s a stratégia lesz, ami segít azt megvalósítani. 

Ahogyan említettem ideális esetben a product csapat problémákat old meg – nem csak funkciókat szállít – és számukra a termékstratégia lesz, ami segít eldönteni mely problémák a legfontosabbak. 

A fókuszálás és a termékstratégia kéz a kézben járnak 

Ennél az alapelvnél Marty Cagan Steve Jobsot idézte meg:

“Számtalan dologra vagyok büszke, amit nem tettünk meg, és számtalan olyanra is, amit megtettünk. Az innováció dolgok ezreire mond nemet.” 

Ezzel szemben egy stakholder-vezérelte modellben a fókusz elérése lehetetlen, mert minden érintettnek megvannak a saját céljai és igényei, a vállalat pedig egészen egyszerűen arra törekszik, hogy a lehető legtöbb érintettet kielégítse.

A product modellben rendkívül más a mindset, holisztikusan kell szemlélni a lehetőségeket és a veszélyeket egyaránt: a termékstratégia pedig abban segít, hogy definiálja hova kell koncentrálni az erőforrásainkat a legnagyobb hatás érdekében. 

A fókuszálás nekem is nagy nünükém, ezért különösen tetszett a tanács miszerint a CEO-kat arra kell ösztönözni, hogy definiálják a 2-3 legfontosabb célt, és a termékvezetők pedig ezek kielégítésén dolgozzanak. 

Insightok táplálják

Ahhoz, hogy fókuszálni tudjunk insightok kellenek, amik megmutatják hová koncentráljuk szűkös erőforrásainkat. 

Akinek nagyobb a tudása, az lesz sikeres a termékstratégiában is, s a tudást támogató adatok sokfelől jöhetnek de különösen az alábbiakból.

• Ügyfél és felhasználói adatok elemzése: Adatok arról, hogy a felhasználóid hogyan használják termékedet. Adatok arról, hogy az ügyfeleid hogyan vásárolják meg termékeit. Adatok arról, hogy ez hogyan változik az idő múlásával.
• Új enabling technológiák: Mi tudnak megoldani ma a fejlesztők, amit korábban nem? Milyen új lehetőségeket nyitnak meg az új technológiák?
• Szélesebb iparág rendszeres szkennelése: Mit tanulhatunk a tágabb versenykörnyezetből? Milyen trendek befolyásolják iparágadat vagy kapcsolódó iparágakat? Hogyan változnak az ügyfelek elvárásai az idő múlásával?

Transzparencia 

A termék modellben annak eldöntése, hogy mely problémákat kell megoldani, a különböző stakeholderek közötti szétosztás helyett átkerül a termékvezetőkre. 

A product leaderek a vezetőkkel és a stakeholderekkel együttműködve a leghatásosabb termék víziót és stratégiát dolgozzák ki, hogy a legértékesebb lehetőségekkel tudjanak élni valamint a legsúlyosabb fenyegetésekre válaszoljanak. 

Könnyen belátható, hogy ez könnyen féltékenységet vagy frusztrációt okozhat, ha a stakeholderek attól tartanak, hogy a termékvezetők a saját érdekeiket és programjaikat követik. 

Ezért nagyon fontos, hogy a termékvezetők nyitottak és átláthatóak legyenek azon adatokkal és érveléssel kapcsolatban, amelyeket a termékstratégiai döntések meghozatalához használnak.

A termékstratégiai fogadások

Marty Cagen szerint a termékstratégia nem tudomány. Még a legjobb stratégia, nagyon képzett termékcsapatok mellett is számítani kell arra, hogy nem minden probléma oldható meg óramű pontossággal.

Egyes problémák egyszerűen sokkal nehezebbek, mint mások, bizonyos problémák meg különböző kockázati profillal rendelkeznek.

Az IT-modellben nagyon gyakori hiba, hogy figyelmen kívül hagyják ezt a valóságot, majd meglepődnek, amikor a projektek a vártnál sokkal tovább tartanak, vagy nem hoznak érdemi eredményt.

Az egyik hasznos megközelítés ennek a valóságnak a kezelésére a többszörös fogadás fogalma: ha egy kritikus fontosságú problémát kell megoldanunk, akkor azt több termékcsapathoz is hozzá rendelhetjük, abban a reményben, hogy legalább az egyikük jelentős előrelépést fog elérni az adott negyedévben.

---

Product Discovery

Ideális esetben a termékcsapatok felelősek azért, hogy megtalálják a legjobb megoldást azokra a problémákra, amelyek megoldására felkérték őket, majd pedig megalkossák ezeket a megoldásokat. Az előbbi a product discovery az utóbbi a product delivery.

Magyarországon sajnos product discovery elvétve létezett eddig is – a discovery nem egyenlő a követelmény elemzéssel – , ezért ezeknek az elveknek a leporolását különösen fontosnak gondolom.

Ugyanakkor az AI tekintetében is itt van az egyik legjelentősebb potenciál, mert még könnyebbé válhat a prototipizálás. 

A pazarlás minimalizálása

Az Inspiredben azt írta Marty Cagan, hogy ötleteinknek legalább a fele egyszerűen nem fog működni a valóságban. Ezért aztán az igazán jó csapatok azt feltételezik, hogy az ötletek legalább háromnegyede nem úgy fog működni, ahogyan azt remélik.

A cél, hogy megpróbáljuk az adott problémát minimális elvesztegetett idővel és erőfeszítéssel megoldani. A product discoveryben éppen ezért a termékötleteket nagyon gyorsan teszteljük – protoipizálással és felhasználókkal – annak érdekében, hogy megtaláljuk azt a megoldást, amelyet érdemes megépíteni, majd piacra vinni.

Ezzel sokkal gyorsabb “time to money” és üzleti eredményesség elérése a cél, kevesebb pazarlás mellett. 

A termékkockázatok kezelése

Mindig kockázatokkal jár digitális termékeket építeni, melynek Marty Cagan négy alaptípusát szokta említeni:

És ezen felül a plusz egy, hogy vannak-e etikai megfontolások is a termék kapcsán. 

A legfontosabb alapelv itt, hogy fel kell mérned és kezelned kell ezeket a kockázatokat, mielőtt bármit is építenél. 

Rapid tesztelés

Ezen kockázatok vizsgálatának egy része elképzelhetetlen a felhasználók bevonása nélkül. Jelesül prototípus létrehozása és néhány felhasználóval történő teszt elvégzése nélkül képtelenség megállapítani, hogy az emberek valóban képesek lennének használni egy új terméket.

Felelősségteljes tesztelés

Discovery technikákat mindenféle méretű cégek alkalmaznak, de vannak dolgok, amelyek könnyebbek egy startupnál, mások nehezebbek. Például egy startup nehezen tud A/B tesztelni, mert nem rendelkezik még kellően nagy forgalommal. 

Egy nagyvállalatnak viszont sok forgalma van, több pénze, jelentős reputációja ezért többet is veszíthet. Egy nagyobb cégnek tehát úgy kell tesztelnie és megválasztania a megfelelő módszert, hogy megvédje ezen javait. 

---

Product Delivery

Mint látszik, a digital product biztosítása nem csak a “fejlesztést” jelent, hanem számos egyéb tényező is szükséges hozzá.

Ha viszont a deliveryről van szó, az sem teljesen mindegy, hogy milyen elveket követ, sőt döntően meghatározza a termékünk kilátásait. 

Gyakori apró releasek 

Marty korábbi műveiben is és persze a Transformedben is azt képviseli, hogy a termék csapatok legalább kéthetente releaselnek: a nagyon erős tech – például a Revolut – cégek pedig naponta többször is kiadnak frissítéseket. 

A kedvenc termékeidnél mondjuk a Spotifynál azért nem veszel ebből észre szinte semmit, mert egyfajta folyamatos streamként tolnak ki apró kis frissítéseket. 

Nagyon érdekes egyébként ennek a matekja: minél kisebb a relase, annál könnyebb biztosítani annak minőségét. Valamint, ha probléma merülne fel ezekkel a kis frissítésekkel, akkor egyszerűbb azonosítani a hibát, hiszen csak néhány dolgot változtatunk meg.

Egy jelentős frissítés-csomag, egy “big bang release” esetén sokkal jelentősebb a stabilitási kockázat, nehezebb a debugging és végső soron a felhasználóknak is előnytelenebb lehet, pláne ha radikálisan változik az interface is. Ebbe a hibába sok hagyományos IT-driven vállalat beleesik, lásd a CIB Bank 30 órás leállásnak tanulságait.

Mindez azt jelenti, hogy ha tényleg törődsz az ügyfeleddel, akkor ki kell fejlesztened a képességet, hogy gyakran, gyorsan legyél képes apró relaseket kitolni. 

Mérés biztosítása

Mivel elköteleztük magunkat a problémák megoldása mellett, és felelősséget vállalunk az eredmények eléréséért, elengedhetetlen, hogy megértsük, hogyan – vagy egyáltalán –  használják a termékünket. 

Ez azt jelenti, hogy biztosítani kell, hogy terméked olyan mérőeszközökkel, rendszerekkel legyenek felszerelve, amelyek lehetővé teszik a történések megértését. 

Ezen mérőeszközök nélkül gyakorlatilag vakon repülsz. Releaselhetsz egy új funkciót, de fogalmad sem lesz róla, hogy használják-e és hogyan, illetve hol küzdhetnek a felhasználóid nehézségekkel. 

Viszont megfelelő mérőeszközökkel és elemzésekkel gyorsan észlelheted és javíthatod a problémákat. 

Monitoring

Az előző alapelvben ismertetett mérőeszközöknek számos előnye van, de az egyik legfontosabb, hogy a mérőeszközök lehetővé teszik egy másik delivery alapelv megvalósítását: a felügyeletet, más néven megfigyelhetőséget.

Erős felügyeleti rendszerrel nagyon gyorsan észlelheted a problémákat, gyakran még mielőtt ügyfeleid egyáltalán találkoznának velük.

Deployment infrastruktúra

Tegyük fel már képesek vagyunk kis, gyakori releaseket kiadni, de van még pár dolog, amire a deployment infrának képesnek kell lennie:

• Vissza tudjuk vonni a változtatásokat – rollback -, ha problémák merülnek fel
• Mérni tudjuk az új funkciók valódi értékét az A/B tesztelés segítségével
• Kontrollálni tudjuk, mely felhasználók látják az új funkciókat és mikor

---

Termékkultúra

A termékcsapatok, termékstratégia, discovery és delviery elveit összegyűjtöttük, és mindezeket ha egyben tekinted láthatod mit jelent az erős termékkultúra egy erős product centrikus vállalatnál. 

Azonban a termék kultúrának is megvannak az elvei, vagy ha úgy tetszik meta-elvei. 

Az elvek a folyamatok felett állnak 

Sok vállalat, amely transzformációban van éppen, korai éveiben kifejezetten jó volt az innovációban, de aztán valahogy elveszítette ezt a képességét.

Sajnos ez nagyon gyakori jelenség, és valami, amitől az erős termékközpontú vállalatok mindig tartanak, hogy velük is megtörténhet.

Ezen a ponton Marty Jeff Bezost idézi:

„A jó folyamat téged szolgál, hogy szolgálhasd az ügyfeleket. De ha nem vagy éber, a folyamat válhat a fő céllá. Ez könnyen megtörténhet nagy szervezetekben… A folyamat nem a lényeg. Mindig érdemes megkérdezni: mi birtokoljuk a folyamatot, vagy a folyamat birtokol minket?”

Bizalom a kontroll helyett

Ha eljutottál idáig ebben a masszív guideban, már biztosan magad is rájöttél, hogy a termékmodellre való áttérés nemcsak a kompetenciák és fogalmak változását jelenti, hanem alapvető kulturális változást is képvisel.

Sok vezető számára, különösen azoknak, akik karrierjüket a top-down, ”command-and-control“ modellre építették, ez hatalmas változás. Ez ugyanis egy olyan modell, amely inkább a bizalomra épül, mint a kontrollra.

Általánosabban fogalmazva, ez azt jelenti, hogy a mikromenedzsmenttől el kell mozdulni a szolgáló vezetés felé, aktív coachinggal: vagyis kontextussal vezetünk, nem pedig kontrollal.

Kiszámíthatóság helyett innováció

Sok cégnél az innováció hiányának gyökere meglehetősen nyilvánvaló. Úgy tervezték szervezetüket és működésüket, hogy a kiszámíthatóságot helyezték a középpontba. Például egyszerűen arra összpontosítanak, hogy minden negyedévben nagy számú funkciót tudjanak leszállítani.

Nem arról van szó, hogy szándékosan lemondanának az innovációról általában, de ahogy Henrik Kniberg mondja, „100% kiszámíthatóság = 0% innováció.”

Bár a kiszámíthatóság jó dolog, de közel sem olyan fontos vagy szükséges, mint az innováció.

Kudarc helyett tanulás

Sok vállalatban mélyen gyökerezik a kudarctól való félelem. Ez a félelem arra készteti az embereket, hogy kockázatkerülővé váljanak, és képtelenek legyenek reagálni a piac változó igényeire és az új technológiai lehetőségekre. 

Marty Cagan sem akarja idealizálni a kudarcot, csak azt mondja, hogy a hangsúlyt a kockázatok kezelésére és a gyors tanulásra kell helyezni. 

Amikor tesztelést végzel a product discovery során, nincs olyan fogalom, hogy siker vagy kudarc; csak az a kérdés létezik, hogy „Mit tanultunk?”

A célod az, hogy megtudd, mi működik és mi nem a discovery során, ahol a költségek és az idő drámaian csökkennek, és a kockázat mérséklődik. Ennek köszönhetően, amikor ténylegesen belecsapsz a termékek megépítésébe, időt és pénzt fordítva rá, bizonyítékkal és magabiztossággal rendelkezel arra vonatkozóan, hogy a termék nem lesz kudarc.

Az AI forradalma kétségtelenül átrendezi a termékfejlesztés eszköztárát és gyorsítja a szoftverfejlesztés folyamatait. Mégis, ahogy Marty Cagan rámutat, a sikeres termékközpontú vállalatok nem a folyamatok vagy a technológiák, hanem az alapelvek miatt kiemelkedőek. A felhatalmazott, kereszt-funkcionális csapatok, a problémamegoldásra való fókuszálás, valamint a kísérletezés és tanulás kultúrája olyan fundamentumok, amelyek az új technológiai környezetben is relevánsak maradnak.