UVOD
Ta članek je navdihnjen z lastnimi opažanji, kar malce preroškim opozorilom v knjigi The Lean Startup in zmedo, ki jo je v razvojni cikel prinesla umetna inteligenca. Članek ima dve sporočili, ki sta medsebojno neodvisni, a se funkcionalno navezujeta. Pa vendar
LEAN STARTUP PRIPOROČILO
Predstavljajmo si, da smo prodorno podjetje, ki je s svojim produktom doseglo market fit. Zavedamo se, da je to šele začetek in da mora naš produkt z iteracijami rasti. Seveda tega ne delamo na pamet, ampak imamo v produkt vgrajeno kopico analitike. Redno izvajamo tudi intervjuje, ankete in user testing. Merimo churn rate, daily active users (DAU), retention rate, lifecycle value itd.. Po začetnem skoku, metrike sicer kažejo, da imamo iz meseca v mesec več aktivnih in plačljivih uporabnikov, a sta grafa rasti precej položna.
Zaradi ne preveč impresivnih rezultatov se ekipa počasi začenja spraševati, ali nadgradnje v resnici pomagajo pri omenjeni rasti ali pa je ta posledica drugih faktorjev. To bi bili lahko na primer marketinški napori, viralna adopcija, višanje cen konkurenčnih produktov ali preprosto inercija. Kam se torej najbolj splača vlagati sredstva?
Rešitev, ki jo predlaga The Lean Startup je, da razvojna ekipa vsako iteracijo tretira kot eksperiment. Posledično to pomeni, da je potrebno v naprej določiti metrike na katere računamo, da jih bojo nove funkcionalnosti izboljšale (in za koliko!). Če se po releasu planirane metrike ne spremenijo, je čas, da svoje napore preusmerimo v neko drugo funkcionalnost ali aktivnost v zvezi s produktom (pivot). Če pa se planirana metrika izboljša, je to indikator, da smo na pravi poti.
Da naša neodločnost nebi predolgo trajala, je za analitiko bolje kot sumarne grafe uporabiti kohortno analizo. Graf spodaj je narisan na istih podatkih kot zgornji, a nam da realnejšo sliko napredka. Na kohornem grafu za vsak mesec vidimo kolikšen del celotne rasti predstavlja določen tip uporabnikov.
Čeprav se nam je na sumarnem grafu zdelo, da število plačljivih uporabnikov nekako še rase, nam kohortni graf pove, da so novi plačljivi uporabniki v zadnjih treh mesecih predstavljali le en ali manj procenta vseh novih uporabnikov. Očitno funkcionalnosti, ki smo jih plasirali, niso bile tisto kar bi v resnici pritegnilo uporabnike. Po drugi strani, pa smo v releasu junija nekaj naredili prav (4% novih plačljivih uporabnikov). Bilo bi bolje, da nadaljujemo v tej smeri, kot pa da smo po spisku razvijali naslednje funkcionalnosti. Čeprav so testni uporabniki z njimi bili zadovoljni, kot kaže kljub temu to niso bile funkcionalnosti, ki bi bile za nas donosne ali pa bi nove uporabnike prepričale v našo rešitev. Ta informacija s sumarnega grafa ni bila razvidna, kohortni graf pa jo je lepo izpostavil.
Priporočilo je torej, da pred releasom postavimo hipotezo katerikazalci računamo, da se bojo spremenili (in za koliko). Na osnovi analitike se nato odločimo za pivot ali persevere. Podjetja, ki se držijo tega priporočila, že s tem prekosijo večino svojih agilnih konkurentov.
Omenjeno spoznanje bomo sedaj uporabili še v svetu AI podprtega produktnega razvoja.
KO PROGRAMIRANJE NI VEČ OZKO GRLO…
Čeprav smo vsi že precej siti razglabljanja o AI, idiotskih prerokb nerentabilnih AI velikanov (in njihovih IPO halucinacij), je dejstvo, da je AI spremenil način razvoja novih produktov.
Bistvo agilnega razvoja je hitro in poceni preverjanje idej z naročnikom. To delamo s prototipi in včasih MVPji. MVPji so od prototipov časovno zahtevnejši, se jih pa da načelno takoj vključiti v produkcijo.
Paradoksalno AI ni odpravil ozkega grla razvoja, ampak ga je samo prestavil drugam. Včasih je razvojna ekipa čakala na prototip. Danes prototipi čakajo na uporabnike. Vsak posameznik v razvojnem timu lahko zdaj dnevno kreira množico kvalitetnih prototipov ali MVPjev. Če želimo povratne informacije, je vse te prototipe potrebno testirati z uporabniki (kvantitativno in kvalitativno). Ozko grlo razvojnega procesa se je torej premaknilo z zamudnega razvoja prototipov in MVPjev na njihovo testiranje. Tega se s pravimi tehnikami da pohitriti, a pri tem ne smemo pozabiti kaj je naš cilj (produktni cilj, KPIji…). V nasprotnem se ne bomo mogli odločiti med na primer tremi konkurenčnimi prototipi iste funkcionalnosti.
Predloga za kvalitetno izrabo tega plazu prototipov in MVPjev sta dva.
1. Določi željeni rezultat predno se lotiš testiranja
To je Lean Startup priporočilo, ki smo ga spoznali v prejšnjem poglavju. Če imamo pred seboj deset kvalitetnih prototipov in MVPjev, bo med njimi treba izbrati. Najboljši način za izbiro, je da jo opravimo na osnovi KPIjev, ki smo jih določili pred testiranjem. S tem smo postavili hipotezo, ki jo bo testiranje potrdilo ali ovrglo.
2. Določimo kdaj se bomo ustavili
Kvalitetni alternativni prototipi in MVPji že obstoječih funkcionalnosti bojo prihajali še naprej. Da nebi pozabili na ostale funkcionalnosti in rast produkta, bo na neki točki čas, da se preusmerimo. To lahko pripišemo tudi 20/80 pravilu.
Ker se pritok novih predlogov ne bo ustavil, je v ta namen dobro v naprej določiti kriterije, kdaj bomo smatrali, da je določena funkcija dovolj dobro razvita.
Par primerov takšnega kriterija:
- Ko bo 40% uporabnikov to funkcijo uporabilo vsaj enkrat na sejo, bomo smatrali, da je funkcionalnost zadovoljivo razvita in se bomo posvetili drugim.
- Ko bo 90% uporabnikov, ki so začeli registracijski proces le tega zaključilo, bomo smatrali, da je registracijski proces zadovoljiv in se bomo posvetili še ostalim in novim funkcionalnostim.
- Ko se bo NPS za core funkcionalnost izboljšal za 10 točk, se bomo posvetili integracijam z drugimi produkti.
- Če se do naslednjega petka uporaba te funkcionalnosti ne bo zvišala z 2 na 10%, vanjo več ne bomo vlagali časa.
SKLEP
S pospeševanjem tempa razvoja nekateri že poznani produktni koncepti postajajo bolj kritični kot pred par leti. Z AI generiranje idej in prototipov postaja skoraj brezplačno. Cena validacije z realnimi uporabniki pa se še vedno linearno viša glede na količino testiranja.
Naslednji korak optimizacije razvojnega cikla bo odpravljanje ozkega grla pri user testing. Ta tema presega namen pričujočega članka, a prvi poizkusi so že tukaj. Govorimo o:
- celotnih sintetičnih uporabnikih,
- AI kot pred-filtru za pravi user testing,
- multi-agentnih simulacijah kjer AI agenti ponujajo tvoj izdelek drugim agentom z različnimi funkcijami,
- user digital twin zgrajen na obstoječih uporabniških podatkih
AI user testing ne bo izpodrinil klasičnega, ga bo pa optimiziral. Njegova omejitev bo ostala identifikacija:
- popolnoma novih vedenj,
- nepričakovanih reakcij,
- novih potreb,
- “black swan” uporabnikov,
- kulturnih sprememb.
