Predrag Rajkovic, Ivan Pavlovic - Implementing Opportunity Solution Tree, Challenges and Benefits

Epa, ćao svima. Nadam se da se lepo čujemo i vidimo. Ako ima nekih problema, javljajte. Milica će da nas obaveštava šta se deša. Hvala što ste došli na ovu podnevnu sesiju. Ivan i ja ćemo se potruditi da vam bude zanimljivo. Ono o čemu smo mi danas odlučili da pričamo jeste... Primjena Opportunity Solution 3-a kod nas u našoj firmi na jednoj proizvodnoj liniji. Od prilike kako će izgledati ovih naših pola sata druženja, malo ćemo potrošiti vremena da pričamo o tome šta je uopšte Opportunity Solution 3. Verujem da dobar deo vas se upoznao verovatno sa tim, možda ste neki i probali. kako to izgleda, ipak da bi prosto svi imali istu polaznu tačku, malo ćemo se upoznati sa terminima, sa konceptom itd. Neće predugo trajati, kažem, pošto verujem da je dobar deo vas već upoznat sa tim. Onda pa reći o tome gde smo mi ošte implementirali ovaj način rada. zašto smo se odlučili za njega i neki challenge na koje smo našli, neka rješenja na koje smo našli i prvi utisci naši gde vidimo vrednost u tone. Ono što moram na početku da kažem, mi smo novi u ovome, znači skoro smo počeli da implementiramo OSIT, tako da ovi rezultati o kojima budemo pričali i nalazi koje budemo istakli, Nisu baš sve obuhvatne, upako. Negde leto smo otvrlike počeli da implementiramo Opportunity Solution 3. Tako da mislili smo ipak da je vredno da podelimo sa vama. Dosta se pričalo u proteklih godinu dana o Opportunity Solution 3. Dosta je ljudi pokazalo interesovanje i onda smo mislili da ima smisla da popričamo, iako smo još uvek u nekoj ranoj fazi. Izvimi, pređe, upredno što nastavimo, da li imamo nekoga ko ne razume srpski ili... Da, odlično, pitanje. Anyone speaking English or not understanding Serbian? Ok, izgleda svi razume srpski. Dobre. Ništa, u tom slučaju možemo da nastavimo na srpskom. Ok, da. Dobre. Da, sad ovde razmišljam, pričali smo o ovom doguru engleski i srpski, ali pošto se niko nije prijavio da ne razume engleski, da onda ne komplikujemo dalje. Pa reći o nama. Ovo ćem prezentovati Ivan Pavlović, moj kolega, koji je na poziciji produkt direktora za proizvodnu liniju Kameleon. Head of Product Management and Operations je moja uloga, radimo obojca u United Cloud. Ok, zašto baš Opportunity Solution 3, šta je Continuous Discovery, o čemu mi ovde pričamo? U ovom modernom svetu nekako isporuka vrednosti kranjim korisniku ide kontinuirano. Pričamo o Continuous Developmentu, Continuous Deploymentu i onda takvu kontinuiranu... isporuku u vrednosti, mora da prati i logično je da prati i continuous discovery, odnosno onaj deo gde mi u stvari otkrivamo šta je to, koji su to problemi koje za korisnika treba da rešimo, šta je to što njih muči i doloženje do nekog rješenja, odnosno pronalaženje odgovarajućih rješenja za te njihove probleme. Sve to trebalo bi se dešava kontinuirano, tako da prati ga i kontinuirani development. Sam koncept naravno nije nov. Ovde ono o čemu se mi baziramo i o čemu pričamo jeste framework koji je dala Teresa Torres. Teresa Torres je inače poznata, ona sebe zove Product Discovery Coach. Osoba koja ima mnogo iskustva u Discovery, mnogo iskustva u radu različitim proizvodima, u različitim firmama, bavi se uglavnom coachingom u poslednje vreme. Prošle godine je objavila knjigu Continuous Discovery Habits u kome opisuje i framework Opportunity Solution 3. Baziramo se na njenoj ovoj priči iz knjige. Pa onda i ovde uzimam šta je Continuous Discovery, kako ga ona vidi kao najmanje nedeljne neke kontakti sa korisnicima koje radi tim, koje radi na proizvodu. način malih istraživanja i vođeni outcome. Sad ovo su neke bitne elementi i bitne stvari na koje ćemo se mi oslanjati u našem rade i dalje priče ovde. Ono što bih ja naročito, na što bih skrenuo pažnje, jesu dve stvari. Jedno je da ova istraživanja i discovery učestvuje tim koji radi na proizvodu, koji gradi proizvod. Što znači, u principu, ljudi koji vode proizvod, koji ga prave, treba da dade i sve aktivnosti koje se tiču diskaverja. Druga tačka koja bih skrenuo pažnju, jeste ovaj koncept outkama. To nije nešto što sama Tereza uvodi, naravno, ali je jako važno za priču ovde, a to je da mi u stvari ne želimo da pričamo o tome šta su neki feature-i koje pravimo ili šta su... i neki koje timovi treba da proizvedu, već želimo prično tome šta je outcome, odnosno šta je neki cilj ili ishod ka kome težimo. I to je jako bitna promena paradigme gde se mi u stvari fokusiramo na ono što želimo da naš proizvod postigne, a ne na feature koje treba da isporučujemo. Ok, više o tome će pričati Ivan malo kasnije, ovdje da kažem samo uvodim neke od osnovih pojmova kako bismo mogli da pratimo dalje šta se dešava. Ko su ljudi koji treba u stvari da rade ovaj Continuous Discovery? Treza se ostaje na koncept koji se je produkt Trio, neke ga zove još Trio Migos, ima različite nazive, u suštini tri neke... pozicije, funkcije, tri različita tipa osobe ili specijalnosti treba da učestvuju u vođenju proizvoda, pa samim tim i u discovery. Jedno je product manager, znači neko ko dobro poznaje same korisnike, njihove potrebe, šta je to što njima treba, ali takođe i poznaje i tržište, samo okruženje u kome proizvod funkcioniše. Drugo je tech lead, znači neko sa strane tehnike, neko ko poznaje dobro proizvod ispod haube, što bi se reklo. I treća osoba je design lead, odnosno neko ko poznaje UX, ko je zainteresovan da ta user experience u proizvodima funkcioniše glatko. Sve ove tri osobe su jako važne za upravljanje proizvodom, zato što, kao što rekla malo pre, donose različite ekspertize, ali isto tako i različite poglede na sam proizvod i... na probleme koji postoje oko proizvoda. Ove tri osobe su osobe koje rade na Discovery, koje paralelno vode Discovery, sve aktivnosti koje se tiču samog Discovery. Ono što nisam rekao, ja mogu bih sada napomenem, dogovor je da ukoliko imate neka pitanja, slobodno ih postavljajte, Milica će da nas obavesti, tako da možemo i da odgovaramo na pitanja. dok pričamo, ne moramo da čekamo kraj sesije pa da onda odgovaramo na sva pitanja. Tako da slobodno, ko ima pitanja, pite. Dobro, kad smo razrešili šta smatramo pod Continuous Discoveriem i koji su to ljudi koji učestvuju u njemu, hajde malo da popričamo o tome šta je Opportunity Solution 3. Kako ga sama Tereza naziva, Opportunity Solution 3 je u stvari neka vrsta pomoći produkt menadžerima da organizuju svoj continuous discovery. Kada pričamo o continuous discovery, podrazumemo o sve te aktivnosti koje su potrebne da mi dođemo do toga koji problem rešavamo za korisnika, šta je najvažnije da rešavamo u ovom trenutku, koja su to rješenja koje će potencijalno rješiti problem, testiranje tih rješenja itd. Kada ovo radimo kontinuirano, stvari se dosta komplikuju, narasta broj tih nekih variabli sa kojima operišemo. I vrlo lako da se čovjek izgubi, da kažem u svemu tome. Ona je radeći sa različitim produkt menadžerima, prepoznala te pain pointe samih produkt menadžera i rešila je da pokuša na ovaj način da im pomove. Formirajući jedan framework koji u formi stabla omogućava lako razumevanje odnosa između različitih problema koje pokušamo da rešimo, rešenja koja postoje za njih. I sve to stavlja u kontekst postizanja onog cilja ili ishoda koji smo pričali koji želimo da naš proizod postigne. Kada posmatramo ovako ovaj framework, ovo stablo, vidimo nekako se iz dva i tri celine, jedna je taj outcome ili ishod ka kome želimo da... koje želimo da postignemo. Drugi je tzv. opportunity space, znači područje opportunity-a ili problema koje želimo da rešimo za korisnike. I treći deo je tzv. solution space, odnosno prostor u kome definišemo sama rešenja problema. Da ne bi smo pričali ovako abstraktno na ovom nivou, možda pogledamo jedan primer. Mislim da će biti lakše da ispratimo. Ako imamo neki portal gde želimo da formulisali smo cilj, ishod, kao želimo da podignemo broj strana koje poseti svaki korisnik. To je ono ka čemu idemo, to je ono što želimo da postigne. Onda kažemo, ok, neki problemi koje smo tu detektovali u priči sa... korisnicim sa čitavcima mogu da budu korisnik nema šta da čita, ili korisnik nema dovoljno vremena da čita. Jedno i drugo vode ka tome da on je pročitao željeni neki broj strana koji bi su mi voleli da ostavimo ovde. I to su neke opportunity koje su na nekom ravnopravnom nivou međusob. Sa druge strane, ovaj korisnik nema šta da čita, ima, ajde da kažem, neke... pod opportunity ili čerke opportunity koje kažu korisnik ne vidi šta bi moglo čita sledeće. Sa druge strane preporuke, ono što dobija kao preporuke za čitanje nisu relevantne. I sad ono što ovde hoću da kažem je to je sad ta struktura stabla. Ove donje dve da nema šta da čita i da su preporuke irrelevantne su neki problemi koje možemo da rešimo. a u stvari su deo ovog većeg problema koji kaže on nema šta da čita. I onda na kraju sledeći taj space, odnosno solution space, sad na primjer ovo korisnik nema šta da čita, može da bude, ajde da iskoristimo sidebar sa strane, da mu damo predloge, da bi on video šta može da pročita, jer ne vidi, ajde da mu stavimo pod nos, ili recimo, ajde da napravimo veće fotografije da privučemo korisnika da čita nove stvaje. Znači to su već ušli smo u domen rešenja za ove opportunity. Ono što nam ovde ovaj framework nudi jeste da mi na lak način možemo da prežemo, ok, sad, sve od svih ovih opportunity-a, koje nama najvažnije da rešavamo? Koji najviše utiče na postizanje ovog cilja i to je jedna od njegovih vrednosti? Imamo jedno pitanje. Pitanje glasi može li da se podeli iskustvo organizovanja kontakta sa korisnicima u United Cloudu? Imate li neki ustaljeni proces, kako komunicirate sa njima, kako dolazite do njih, koja pitanja postavljaju i sl. Da, mogu. Evo sad ću sad kao uvodu odgovor na to pitanje samo malo da dam kontekst u kome mi ovo radimo. United Cloud ima... više proizvoda koje razvija. Jedan od proizvoda je medijska platforma, mi je zovemo Kameleon. Kameleon sastoji od CMS-a kroz koji novinari i urednici upravljaju portalima i samih aplikacija koje krajnji korisnici gledaju. Ovo su neke od portala koji se vrte na toj platformi, predpostavljam da su vam poznati. Nekoliko development teamova radi. Formirali je dva produkta trija na ovoj proizvodnoj liniji i sad u uvodu u odgovor na ovo pitanje konkretan jeste ono što mi razlikujemo ovde su tri tipa korisnika. Jedan su sami novinari koji pišu članke i objavljaju, drugo su urednici njihovi i treći su naravno krajnji korisnici koji koriste, koji čitaju ovu platformu. Sa sva tri tipa... korisnika mi pričamo kad radimo ovi discover. Naravno, zavisnosti od toga koji konkretan cilj želimo postigdemo i koje opportunity obrađujemo, pričamo možda sa nekom vrstom korisnika za konkretan opportunity, za neke, opet kažem, neke korisnike možda nisu toliko relevante. Kako radimo? Imamo... Možda će Ivan malo kasnije više da pomene. Ukratko, imamo redovne sesije kad se vidimo sa njima. Što se tiče novinara i urednika, imamo ljude sa kojima pričamo na redovnom nivou. Mislim, urednici su, da kažemo, granjačni broj ljudi, nema ih beskonačno mnogo. Novinara ima više. Uspostavili smo neki, idamo komunikacije sa njima i gledamo da... što se tiče samih novinara, variramo malo ljude sa kojima pričamo. Što se tiče krajnjih korisnika, opet ukoliko pričamo opportunity-u koji je njih tangira, pošto ih ne tangiraju svi, radimo rekrutaciju ljudi, sad tržičita prosto nekih naših ciljenih korisnika i opet ih uvodimo u neki redovan način komunikacije. Ako ima dodatno pitanje ili ovde, Ako mislite da je potrebno još pojasniti, slobodno pitite. Imamo još neko pitanje, Milice? Za sada ne, samo to je jedna bila. Dobro, paži, hvala. I u ovom trenutku ja bih vas sad prepustio Ivanu, koji će nam sada dati više informacija, če ovo je bila neka, da kažem, uvodna opšta priča, a Ivan će sad da vam ispriče malo više. Da, samo trenutak. Samo dok Ivan namesti, da, jednu stvar koju sam propustio da ponavim ovde jeste, sad otkud nas dvojca u ovoj priči, kao što rekli, Ivan je zadužen za sam proizvod, odgovoran za sam proizvod Kameleon i s te strane je on zainteresovan da Kameleon radi kako treba i da ispunjava svoje ciljeve i zadovoljava koristničke potrebe. Sa druge strane, moja uloga jeste da... uvodim nove prakse u product management, ali isto tako i da širim one koje su dobre. I onda smo Kameleon tako odabrali da isprobamo njemu Opportunity Solution 3. Ako se pokaže da je ok, onda ćemo ga implementirati i na druge proizvodne linije u United Club. Izvolite. Hvala ti, Peđa. I pre svega želim da vam se zahvalim na ovoj prilici da podelimo iskustvo sa Opportunity Solution 3. zato što je onako prilično zanimljivo, moram priznati, u praksi. U suštini, prije nego što pređemo na konkretno, da kažem, zašto smo se baš odlučili na Opportunity Solution 3 kao framework za koji mislimo da može da nam pomogne da rešimo neke svoje probleme, da ću vam malo prvo kontekst o tome... gde se mi kao kompanija nalazimo, da biste bolje u principu shvatili. Ilajte takva od kompanija koja postoje već šest godina i već za tih koliko šest godina dosta nekih proizvodnih linija smo ovde postoje i samim tim dosta je i biznis stajholdera koji u sluštini kandiduju sad svoje feature za naš roadmap. I onda se vrlo lako sklizne u praktično nekakav... način rada gde imate ogroman broj nekih feature-a unotvar kojih sad treba da na neki način isprioritizujete na čemu treba sledeće da se radi. I onda se, da kažem, lako sklizne u nekakav feature factory model rada gde u stvari timovi optimizuju svoj način rada za isporuku tih feature-a, a ne za u stvari rešavanje problema naših korisnika. Tako da smo u tom kontra... Sad naravno znamo svi zašto to nije... da kažem, optimalno rešenje. Prvo zato što onda se u stvari vrlo lako dođe do proizvoda koji je onako prilično balki, ima puno nekih feature-a koje u stvari pitanje da su potrebni kanjem korisniku. Sa druge strane, sam korisnik bude nezadovoljan jer ima neki proizvod koji sad nešto radi, ne radi baš ono što u stvari korisniku treba. I sa treće strane, ono što... Što smo primetili je da kada uđemo u takav model rada i objektivno timovi postanu nemotivisani zato što onda više se bave štancovanjem fičera nego stvarno pradenjem proizvoda i rešavanjem korisničkih, to je problema našeg korisnika. Prosto u tom kontekstu smo svesni da nam je potreban nekakav malo i drugačiji model rada. U tom kontekstu se u neko slično vreme i moja rola unutar cloud-a promenila da sam se više fokusirao na Kameleon produktnu liniju, tako da smo onda, kao što je rekao Peđa, odlučili da isprobamo praktično Opportunity Solution 3 framework na Kameleon. U stoštini ideja nam je bila da u stvari koristeći ovaj framework se fokusiramo na praktično rešavanje problema korisnika na način da razvijemo feature koji će doprinositi i biznisu. Tako da na neki način uspostavimo sistem koji će moći da s jedne strane postiže biznis ciljeve koje biznis kandiduje, s druge strane da... i da se s druge strane korisnicima reši njihove probleme. Tako da tu je jedan razlog, ja bih rekao, i najbitniji zašto smo odlučili da isprobamo Operativnite Solution 3. Ono što je takođe dobro u ovom kontekstu je da Operativnite Solution 3 daje i praktično rešenje za slučaj kada ste... kada imate ogromnu listu raznih feature-a koja vam neko traže i kada treba da u soštini, da kažem, u tom haosu odlučite koji feature da rodite prvi, koji drugi itd. Sljedeća stavka, a lepo se nastavlja na ovo što sam upravo rekao, je da nam je, s obzirom na veliki broj stakeholder-a, kako sam malo preo objasnio, imamo različite zahtjeve. koje nam dolaze i onda je bez određenog modela koji će na osnovu biznis vrednosti svih tih zahteva da umogući prioritizaciju, jako je teško da odlučiti se koji feature da se uradi jer nekoga svakako moramo da razočaramo u smislu tih stakeholdera. Tako da, opretujem te slušnju, 3 se i page meni učinio kao jedan super framework koji stvarno definiše na jasan način šta je business outcome i business cilj koji određeni, da kažem, feature koji neko traži treba da postigne i prilično se dobro uklapa u kontekst u kom se trenutno nalazimo da imamo dosta stakeholder-a koji imaju određene potrebe. Sa druge strane, ovakav način rada omogućuje da sa tim business stakeholderima u stvari komuniciramo ne kroz jezik fičera, već kroz zbukamo jezik biznis, onaj, outkama koje oni žele da postignu na našoj platformi. Ono što je Peđa spomenuo... Samo ja da proširim zarad boljeg shvatanja, na Kameleon platformi se trenutno vrti desetak velikih portala i isto toliko radečitih redakcija. Svaka redakcija sa svojim uradnikom ima sad neke svoje potrebe. Bez nekog sistema gde će svaki, svačija potreba da bude izmerena u kontekstu biznis vrednosti, jako je teško funkcionisati u smislu prioritizacije. To je još jedan razlog zašto smo odlučili da koristimo OST kao frema. Poslednja stvar, a što bih rekli ne najmanje važna, je da smo u stvari hteli da kroz ovu promenu praktično omogućimo tim ovima da se fokusiraju na praktično rešavanje problema korisnika i na upoznavanje tih korisnika. Peđe je objasnio na par ranjih slajdova ko su naši korisnici. U suštini primerni naši korisnici su novinari i urednici koji koriste našu platformu za objavu svog sadržanja, svojih vesti, videoklipova i ostalo. A u tom kontekstu sekundarni korisnici su nam... kranji čitalci. To je ono što smo interno kroz našu produktnu viziju jasno definisali, zato što je onako u kontekstu developera vrlo lako da se sklizne u onaj model, to je u onu percepciju da u stvari mi pravimo portale za kranjeg čitalca, pravimo i za njega, ali suštinski pravimo za novinare i urednike. Ono što smo u stvari kroz OST videli, a vidjet ćete kasnije kroz određene challenge-e i rezultate koje smo do sad postigli je da u stvari timovi veoma žele da upoznaju tog korisnika, veoma žele da u stvari njegove korisničke probleme rešavaju, a ne samo da štancoju feature-e i da u tom kontekstu nemaju jasnu ideju zašto to radite. To je jedna vrlo... bitan razlog zašto smo savlučili za Opportunity Solution 3. Prijeću sad brzo kroz to kako smo implementirali kod nas Opportunity Solution 3, jer će možda nekom od vas to biti korisno. U suštini, Peđ je rekao da smo formirali dva product trio teama, zato što imamo dve veće... inicijative na kojima internno radimo i ideja je da sa ova dva produktima da kažem prođemo kompletno ciklus i da zavratimo Continuous Discovery, a da onda u kontekstu i ostale ostatka roadmape i ostalih triotimovima praktično formiramo još produkt triotimova. Tako da inicijalno smo organizovali trening za te produkt triotimove. Prosto služuje da se upoznaju sa ovim premarkom. S jedine strane, s druge strane da prosto malo nauče i kako da rade intervju sa korisnicima, kako stvari s njima da komuniciraju. Zato što je u kontekstu tih treninga, nije to običan razgovor sa korisnikom u smislu šta ti se sviđa, šta ti se ne sviđa, već su to prilično fokusirana pitanja koje imaju za cilj da otkriju kako korisnik koristi proizvod, gde su mu problemi, gde... i šta su potencijalno opportunity koje na taj način možemo da identifikujemo. Sa druge strane, pošto taj customer interviewing proces traže određenu tehniku, organizovali smo i dry run sesije gde su ljudi to mogli malo i da vežbaju. Nakon toga, u stvari smo napravili sa stakeholderima sastanak na kome smo se bavili definisanjem biznis outcana, biznis ciljeva za obe te inicijative. Sam taj sastanak je jako bio pozitivan i donao je rezultat u smislu da su se i staj holderi međusobno dobro poravnali u smislu očekivanja šta u stvari žele da postignu. Daću vam primjer, jedan od sve dve inicijative je redesign nekog od portala. I sad, bez jasnog cilja, biznis cilja, šta u stvari oni time žele da postignu, lako može taj redesign da ode u nekom smeru koji na kraju neće za biznis ništa novo doneti, nego će biti opet neki nov portal koji drugačije izgleda, ali u suštini ništa značajno ne doprinosi biznisu. Nakon sastavnaka na kojima smo definisali biznis outcome, timovi su, Prvo su definisali predloge za KPI-eve koje onda će biti koreštene da se validira da li je zaista postinut taj business outcome. I onda su krenuli u proces praktično intervjuisanja korisnika. Taj smo proces pokrenuli na dvonedeljnom nivou, kasnije ću objasniti i zašto. sa praktično idejom da to kako se timovi budu uhodeli praktično svedemo na jednom nedeljno touch point prema onome što i Tereza, da kažem, savetuje, zato što i mi vidimo da je to sasvim dobra kadenca da se naši ljudi vide, to je produktrija timovi da razgovaraju sa korisnikom i da prosto, s jedne strane... Nešto novo sazna i s druge strane da nešto provere od onoga što su prethodno uradili itd. Posle nekoliko tih customer interviewing sesija, tim su napravili prvi draft svojih OST-ova, to je Opportunity Solution 3, gde se u stvari prvi put vidjelo šta su se opportunity na kojima možemo da radimo. Iza toga, i trenutno smo u toj fazi da se sad bavimo praktično validacijom, prototypingom i validacijom tih solutiona. I tu se već onako lepo vidi benefit razgovora sa kranjim korisnikom jer sad dobijemo tačno feedback i vidi se stvarno da se kreće u pravom smerom. U suštini zbog određenih... izazova u ovom procesu, kroz koje će sad proći. Page ja smo postavili redovne weekly check pointe sa sim timovima, prosto da vidimo gde su, da vidimo gde su im problemi, da li su negde zapeli, da li u nekom korahu ne znaju što da urode sledeće. I naravno ja kao neko ko vodi produktnu liniju i učestujemo u tim timovima hands on. U tom smislu, to je da kažem ukratko način na koji smo na Kameleon Product Melemi implementirali Opportunity Solution 3 za sad. Jel ima možda neko pitanje u ovom trenutku sad? Da, dobar je trenutak. Dobro. Ok, ništa prošli smo malo pre kroz, u suštini, način na koji smo implementirali Opportunity Solution 3. Sad ću malo proći kroz u suštini određene izazove koje smo do sad primetili i potencijalne pitfalle u koji timovi mogu da upadnu kad započinju nešto ovako da rad. U suštini, kao što znamo i svi, svaki početak je težak i spor. Ono što smo mi primetili je da, pošto timovi nisu navikli da komuniciraju sa konkretno... korisnicima, tu im je trebalo vremena da se oni malo, da se prosto u tom kontekstu, da prvo zakažu sastanke, da onda se na neki način pripreme za te sastanke, da u tom kontekstu, da kažem, prosto vidjelo se da im treba malo, da kažem, podoške da se proces zavrti. Ono što smo tu radili page, ja sam naravno učestvovao sa timoima da... da te stvari uradimo. Ono što smo radili je da smo uveli te redovne weekly check pointe, sastavke gde smo ustvarili na neki način one držaju takt da ljudi se bave ovim. Ono što smo isto primetili je da, s obzirom da svi ti ljudi unutar Product Rio timova već rade određene svoje uslovno-primerne aktivnosti, ono što smo primetili je da su oni ovo počeli da posmatri kao neku... ono zanimljivu, atraktivnu, nice to have aktivnost koja nije primatna. Tako da u tom kontekstu smo, da kažem, morali malo da ih refokusiramo. Kažemo, ljudi, ovo je bitna stvar, zato što su na kraju krajeva te inicijative nama. sledeće roadmap je jako bitne. Tako da, prosto u nekom trenutku smo malo morali da primenimo više fokusa i pažnje na timu i da se uhodaju u proces. Ono što je se kasnije ridelo je da je to pomogli, da su timovi zaista ušli u redovan ritam komunikacije i sa stakeholderima i sa korisnicima i da prosto... Posle jedno, ja bih rekao, tri nedelje procesa je stvar se upodala i funkcioniše normalno. Ono što je takođe bio izazov za timove, ono što sam primetio, je da su se malo mučili oko identifikacije KPI-a. Zato što, ako sećate, rekao sam da smo definisali biznis ciljeve sa stakeholderima, iza toga smo sa timovima radili da prosto... identifikujemo i dajamo predlog za KPI-e, kojima ćemo da izmerimo da li je zaista postinut taj biznis cilj. I tu je bio izazov za timove, zato što znate ko su članovi tima, nisu svi do tad razmišljali u kontekstu biznis ciljeva, te je to bilo za njih nešto u čemu se nisu baš nalazili, nije mi bilo udobno. Daću i primjer jednoj situaciji. Imali smo recimo... Jednog inicijativa je da povećemo brzinu publishing procesa unutar CMS. To je bio jedan biznis cilj. KPI za taj biznis cilj može da bude svašta nešto. Prvo su timovikani da razmišljaju ovo da kažem inženjerski, sad ćemo da izmerimo u sekundu koliko traje, da ja novinar unese članak i da ga objavi. S druge strane, razmišljalo se i u kontekstu čekli što znači brzina publishing workflowa. Da li to možda znači da izmerimo truput cele redakcije u nekoj jedinici vremena pa da na neki način taj truput povećavamo što će implicitno značiti da se... ubrzov workflow. Na kraju, konkretno za taj primjer, timovi su došli i tim je došao do predloga KPI-a koji mislim da ima super smisle da KPI glasi time to user. To je koliko treba vremena da je jedan novinar otkad je otvorio CMS, uneo vest, objavio vest, dokad ta vest zaista dođe do... korisnika, do krajanjeg čitavca. Da li je on došao kroz homepage ili došao preko mreže. Tako da u tom kontekstu timovi su prošli jedan proces dok su shvatili kako da u stvari definišu KPI na način da može da se izmeri i da opet samo pokazuje da je postavljeno u biznisu. Dobro. I još jedan challenge koji sam ranje već spomenuo, to je da u suštini Osim što trebalo više vremena, bila je potrebna i određena pomoć produkt triatimovima oko prosto tehnike vođenja intervjua. To je načina na koji se prvo definišu pitanja koje treba da postave i onda prosto vođeni samog intervjua koji prosto će dovesti do nekog koristnog zaključka. Zato što nije pojenta da se samo sa korisnikom razgovara. da kažem, bez neke, bez dobro pripremljene agende i pitanja, zato što vrlo lako taj razgovor može da... ne bude koristan, da se svašta nešto ispriča, ali da se na kraju nije zaključilo šta je to u stvari što u tom korisniku je problem. Ono što je tu smo primenili, to je da smo uveli UX researcher, trebali smo pomoći od kolege iz našeg UX teama, koji su onda pomogli timu da unapri pripremi pitanja, koja su onda pomogla da bolje tim shvati kako korisnik koristi proizvod. Jer se često, da kažem, otkrije problem unutar objašnjavanja kako korisni je korisni proizvod. I sa druge strane, kako da dođemo do toga da korisnik stvarno kaže gde on stvari zapinje, gde su mu problemi, šta bi on voleo da može drugačije itd. Tako da to je prosto jedan proces s koji svaki tim koji kreće u Customer Intervju, mora da prođe, mora prosto da savada tu tehniku. Imamo neka pitanja. Prvo je, spomenuli ste da ste sa stakeholderima postavili na inicijalnom sastanku business outcome-e. U kojoj formi ste ih postavili? Kao KPI-eve ste spomenuli. Da. Pa, konkretno imali smo više inicijativa na kojima smo, dve inicijative, da budem konkretan, na kojima smo radili. Na obe inicijative smo pričali bukvalno sa headom United Media, pošto United Media je kompanija unutar United Grupe koja je owner svih portala. Tako da smo u kontekstu sa tim ljudima pričali u smislu gde oni u kontekstu biznisa žele da ti portali napreduju. I onda smo pričali o konkretnom portalu koji je imao... za cilj koji ima određene, da kažem uslovno loše rezultate u određenim merenjima, kako da to napredimo. I onda u tom kontekstu je biznis cilj bio definisan prilično jasno za konkretno taj portal koji smo kasnije razrađivali kroz Opportunity Space u smislu koje probleme da rešimo da bismo za konkretno taj portal postojećih korisnika. I s druge strane ste imali cilj da novi korisnici koji slete na portal, da oni unutar te sesije otvore barem još jednu stranicu. To je bio cilj kojim su oni hteli da pomere taj portal dalje u kontekstu biznisa. Jer s jedne strane taj portal je imao problem da ima lojalnu publiku koja je relativno homogena, dok sve nove korisnike nisu uspevali da zadrže, da ih konvertuju lojalne korisnike. I onda u tom kontekstu je bio definisan taj cilj. Nadam se da sam dao jasan odgovor na pitanje. Da, iz ovoga, sad samo ja sam zadođem, pošto čini mi se da je deo pitanja bio i KPI-evi, znači iz ovakve formulacije cilja smo onda rekli, ok, kako ćemo mi to da merimo, jel? I to je onda ovaj deo što imam pričao o KPI-evima, koji su tu izazovi za formulisanje. Da, konkretno za taj cilj su KTI-e prilično jasni. Nema mnogo dileme. Za drugi cilj koji se više bavi samim publishing workflow-om je KTI malo tricky da se definiše. Ali ovo je formulacija samog biznisa. Ok, imamo još pitanja. Možete li malo detaljnije o tome kako vam je OST pomogao u prioritizaciji? Kako ste zapravo radili s pomoći OST-a? Pa u suštini mi ovo primenjujemo i na, kao što sam već objasnio, nove stavke koje nam dolaze sa roadmape. I tu smo krenuli top-down prvo kroz definisani business outcome, a onda dalje kroz standardni proces. Sa druge strane mi OST primenjujemo i na već ranije identifikovane feature koje stakeholders traže. E sad tu primenjujemo bottom-up. praktično pristup, u smislu da za te feature prvo smo razgovarali o tome da shvatimo u stvari koji oni problem rešavaju. Jer neko dođe traže sad, ne znam, određeni feature na nekom portalu, određeno, ne znam, funkcionalno od strane, su što gore. Da bismo znali prosto, da, da, samo da kažem ovu bitnu stvar, u suštini da bismo imali dobar alignment između različitih redakcija, pošto sad svako traži nešto svoje. U suštini imamo princip rada gde mi kao cloud proveravamo prioritizaciju sa headom United Media. Jer u principu head of United Media nam pomaže da alignujemo zahtevi među portala. E sad, da bismo to mogli da uradimo na smislen način, primenili smo OST u kontekstu da smo za svaki feature koji se nam tražile redakcije, Prvo, u prvom koraku sa redakcijama razradili šta je to u stvari business value koji njima donosi taj konkretno feature. Šta je to business outcome za koji oni misle da će baš ovaj feature da im pomogne. Da kažem, to je malo bottom up, kontra ovaj pristup, ali je opet vrlo koristan. I onda kada smo to identifikovali sa redakcijama, onda smo sa Head of United Media praktično vrlo lako dolazili do prioriteta. jasno vidjelo šta je business value za određeni portal vs business value za neki drugi portal, a oba portala traže nešto. Tako da u tom kontekstu nam je pomoglo. Ono što u stvari u kontekstu OST frameworka ćemo raditi u buduće, to je da ćemo gledati da svu komunikaciju sa i portalima i ovim United medijom da vodimo u kontekstu business outcome-a. Jer to je suština, to daje slobodu timovima da predlažu različite feature koji će da pomogu da se postignete business outpost. Jer u stvari mi želimo da na ovaj način izrađemo iz moda gde smo ograničeni već definisanim featureima koje neko traži. Suština je da mi imamo slobodu da kad neko kaže zašto mu to treba, šta on time želi da postigne, da onda mi u stvari imamo slobodu da damo predlog. možda drugačijeg feature-a koji će bolje pomoći da se taj problem reši. Treba sam sad samo da uskočim, gde ja vidim sad značaj OST-a, jeste u stvari što je jako komplikovano da ti na nivou feature-a prioritizuješ stvari. Da kažeš koji pojedinačni feature više utječe na sam cilj. a ti kroz OST u stvari dižeš ono nivo abstrakcije na više, ali u stvari ne prioritizuješ feature-e, jer tu je glavo bolja, nego prioritizuješ same opportunity-e. Ako se setite onog slajda sa primerom, mnogo ti je lakše na nivou opportunity-e kažeš koje od ova dva ili od ovih N opportunity-e će najviše uticati na postizanje cilja. Nekako mnogo je lakše da... da to uvidiš, da uvidiš vezu između opportunity-a i outcome-a, nego onih sitnih feature-a dole kojih može da bude milion i koje ti prioritizuješ. I onda u stvari, kada prioritizuješ gore na višem nivou abstrakcije, ti jednostavnije prioritizuješ, a on vuče celu granu dole i onda kažeš, aha, ok, ako mi je ovo opportunity koji mi je sad najvažnije da rešavam, onda se bavim njegovom granom dole i onda imam ograničeni broj feature-a koje kasnije moram da izprioritizujem. Mnogo lakšam sebi. Učer kao pričamo nebitno je. Pet, sedam feature-a, ne pričamo o 77. I setite se, jedna od stavljaka koja sam rekao je da u stvari želimo engagement timova. Želimo da timovi ne budu samo ljudi koji naprave feature-a i to je to, nego ljudi koji mogu da predlože drugačiji feature koji će bolje praktično rešiti uređeni opportunity posleđe odgledaći business team. Ok, imamo još nekoliko pitanja. Hoćete da zavšite prezentaciju pa da ih prođemo ili hoćete sada da... Može, da, u suštini. U kontekstu još prezentacijama još ovaj slajd gde smo sumirali u stvari šta su nam do sada rezultati. Kao što je rekao Peđe, mi smo relativno skoro počeli da primenjujemo ovaj framework i u suštini ono što smo do sad... zaključili i vidjeli, je da je zaista feedback od svih učesnika veoma dobar i pozitivan. Počeo od timova koji su zaista imali smo ogroman interesovanje svih ljudi u timovima da žele da razgovaraju sa korisnicima, da žele da učestvuju u tom smislu. S druge strane, odličan feedback od... od stakeholdera, jer u suštini njima je, kad ih odvežemo u kontekstu da ne pričaju više o feature-ima nego o tome gde oni vide biznis kude treba da ide, njima je na to mnogo lakše i mnogo im je prirodnije da u tom kontekstu razgovaraju. Ono što smo takođe vidjeli je da je odličan feedback i od korisnika, od novinarne urednika, jer su sad i oni da kažem... vide da mogu redovni checkpoint da imaju i razgovor ne samo sa nama kao produkt delom organizacije Kameleona, već i sa i developerima i dizajnjima. Tako da u tom smislu stvarno je odličan feedback. Sa druge strane, malo pre sam spomenuo, omogućio nam mnogo bolje alignment sa stakeholdersima, zato što sve što oni traže... prethodno u formi feature-a, smo mi morali mnogo više da razjašnjavamo s njima zašto oni to traže, da bismo shvatili bolje. Sad kad pričamo više u kontekstu prvo biznis cilja, a onda posle naših predloga za rešavanje, mnogo nam je bolji u tom smislu alignment. Išta naista stvar koja možda nije očigledna, to je kada vi imate mali, kada imate jedan produkt tim, jedan od produkt menadžera i jedan proizvod, nekako u tom kontekstu lakše je tom timu i tom produkt menadžeru da vozi proizvod. Ali kao što je u FEC spomenuo, mi na Kamelanu imamo trenutno pet timova, imamo četiri pet produkt menadžera i dosta već veliku organizaciju. Ovaj način rada gde se prvo jasno definiše šta mi hoćemo da postignemo u kontekstu business outcom-a, olakšava svima. da rade svoj posao, jer u suštini jasno je zašto nešto radimo u odnosu na prethodni model gde u stvari kad neko dobije zahtev za nekim feature-om, bude malo nejasno u stvari koji ti problem tim feature-om želeš da rešiš. I ono što smo isto primetili, kažem da je stvarno povećala se motivacija timova i njihov engagement, zato što su već vide korisnika za koga prave proizvodi i konkretno vide dinu i slobodu da predlože drugačiji način, drugačiji feature odnosno na ono što im se traže. Tako da manje niše, to je ono što smo do sad vidjeli i ukratko, svakako nastavljamo sa OST-om, tako da... vidjet ćemo možda za sljedeću konferenciju da imamo malo više konkretnijih rezultata i bolje feedbacka. Super, hvala. Imamo još pitanja. Sad nam kriječe pauza za ručak, ali možemo da odgovorimo na otopjenja. Može. Milice, pošto ti si timekeeper, ako ne stignemo na sva pitanja da odgovorimo, mogu ljudi da nas... Simno bilo večeras na eventu, bilo preko LinkedIn profila, kako god odgovaramo. Nije problem ako na neče pitanje ne odgovorimo sad, možemo kasnije. Ajde ti pucaj koliko vremena imamo ti kad spuštamo rampu. Kompanija u vašim citpelama se muče često da obezbede ljude sa strane klijenta koje bi bile uključene u development, tipa te dvonedeljne sastanke. Kako ste si izborili za kapacitet reprezentanta korisnika? Jeste li pokrili ugovoru ili prilikom definisanja saradnja na početku? U suštini spomenuli smo da su nama u stvari primerni... korisnici u ovom smislu su novinari i urednici. Tako da u tom kontekstu ono što smo mi imali prilike da vidimo je da oni prosto nemaju nikakav problem da ono stvari žele s nama da razgovaraju. Tako da nismo imali nikakav takav problem. Ono što je isto bilo dobro je što u stvari smo primetili da je njima i sami su želeli da s nama komuniciraju direktno, direktnije nego do tada. Tako da nismo li takav do sada problem da smo morali na neki način sad nekoga da primoravamo da se sad odazove na sastanak. Sa čitalcima, s jedne strane, Granded Cloud je kompanija od 300 plus ljudi, tako da jedan deo tih kranjih čitalaca kao tipa korisnika smo rekrotovali iz naših redova. a drugi deo, kao što je rekopeđa sa tržišta, tako da u tom smislu isto da kažem mi smo imali neki pretirani problem da stupimo u kontakt sa korisnicima. Mislim da je to onako više percepcija pre nego što se uđe u sam proces, kad se uđe u proces, ono i uspostavi se da to nije toliko išu. Da, možda nije lošo ovde napomenuti, znači ovde kad pričamo o intervjuovima sa korisnicima, ne radimo sa ogromnim... brojem ljudi sad pa da vam treba puno ispitanika. To je po jednom ovom flytu što bi rekli ono šest, sedam, osam, šestoro, sedmoro, osmoro ljudi. Znači nije sad da nam treba 150 korisnika da bi pričali sa njima. Tako da čisto ono je to možda. Ok, super. Hvala. Sledeće pitanje je koji bi bio dobar pristup uvođenja ovakve ili neke slične outcome focus inicijative u kompaniji koja nema pretarano razvijeno svesto tome? Da li je moguće izgurati ovu inicijativu bottom up ili morate dođe od oskova? Da, pa to je dobro pitanje, zato što u jednoj kompaniji apsolutno mogu da zamislim da postoji nekakav jak stakeholder koji ima svoj... Ono što je unutar clouda nam je trenutna organizacija da imamo podeljeno po produktnim linijama, gde smo postavili na čelo produktne linije osobu koja je responsible end-to-end za cijelu produktnu liniju. Tako da u tom kontekstu Kameleon je uslovno moj i... imam slobodu da mogu da određene promene u tom kontekstu uradim, ali ono što ja predlažem, ukoliko imate potencijalno problem u organizaciji, u kompaniji, pokušajte sa jednom inicijativom... da je na ovaj način uradite. Ne morate sad frontalno da promenite odjednom ceo proces rada, nego verujem da ćete unutar tima sa kojim radite imati nekoga koji je zainteresovan da neformalno uđe u jedan produkt, Rio Team, i da onda na jednoj stvari, na jednom, recimo, konkretnom jednoj inicijativi da pokažete da ovo može da funkcioniše. Ja bih rekao da je to ovako najbolji način da prosto... Da sad nekoga ne ubeđujete u to da je ovo sad super, najke mi, nego pokažete na primjeru da ovaj sistem funkcioniše. A čim se razgovara sa krajnim korisnikom, mislim da tu mnogo toga korisnog može da se sazna i da se u tom smislu, ako se tom korisniku reši njegov problem, ne može da se pogreši. Da se osnovne samo to da li mogući bottom-up approach. Jeste, čak bih ja rekao i da je ovo što vam kaže vrlo zgodan i korisnan, jer kontrolišete situaciju, na manjem nekom uzorku probate, a i ovo što mi radimo je u suštini, ajde da kažem, može da se posnate kao bottom up, jer mi nismo doneli odluku kao sad mi radimo ovako i sad svi proizvodi rade na ovaj način. Mi smo isto odabrali ovu proizvodnu liniju da sa njom probamo da vidimo kako će da ide, pa ako sve bude super širit ćemo na druge, tako da bottom up je skroz ok. Tako je. Ok. Usteguo još jedno. Imamo još nekih pet minuta, pa ajde koliko stignemo. Na koji način ste generisali ideje za solucije? Da li ste uveli ideju validacije za prioritizaciju istih? Da, pa u suštini u kontekstu solution space-a, u suštini i jedan veliki benefit praktično... pravljenja product trija u kojeg čine product manager, design lead i neko iz developmenta, tech lead, kako god. U suštini ideja sa takvom strukturom tima je u stvari da takav tim može da predloži u stvari najbolji predlog solušana, različiti solušana, jer svako donosi na to neko svoje znanje koje može biti korisno. Developer nas to donosi... poznavanje tehnologije. Pa sad u tom kontekstu on zna da je sad potencijalno nešto moguće uraditi što nije moglo da se uradi pre godinu dana, recimo u tom smislu. S drugi strane, produkt menedžer poznaje korisnika pa može da pregođe u tom smislu. Znači, zaista nismo primetili nikakav problem u kontekstu solutioninga. Zato što u radu sa korisnikom u kontekstu intervjusanja se često, da kažem, puno korisnik, hintova dobije koji prilično dobro pokazuju šta bi moglo da bude solušen. Nekad čak i ti korisnici kažu što je bilo super kad bih imao nešto drugačije. Dakle, u tom smislu nije stano išio ideja. Prosto jeste da taj product, trio team, dođe do različitih ideja. I samo još da kažem, koncept OST-a jeste takav da za jedan opportunity vi možete da predložite više solušena. a onda prosto validirate te solution da biste videli koji najbolje rešava ovaj problem. I sa druge strane, to je nešto što je isto predmet checkpointa sa korisnikom. Vi mu predložite više mogućnosti i dobijete feedback i na to.

More about Roadmaps Conference 2022 on: https://roadmapsconference.com/

Have you already heard of Continuous Discovery and Opportunity Solution Tree (OST) by Teresa Torres? This might be the thing that will help you create and improve your products with features customers actually need. In addition, this framework will help you systematize your discovery activities, focus all ideas you have for product improvement, and lead you toward product goal achievement. At this session, you will hear about the good sides, and also about the challenges of using OST. The speakers will bring up their views based on the experience in implementing the framework in their every-day work. No previous knowledge, apart from general product management vocabulary, is required.

Bio
Experienced People and Product Manager, expert in Product Development. Agile practitioner and Agile Coach. Predrag is certified facilitator of the Design Sprint framework, through which he helps teams discover problem that needs to be solved for users, propose solution, create prototype, and validate the solution with end-users, in order to put the best products in front of their customers. Predrag is currently implementing latest product development techniques in United Cloud, helping the company shape products through rational, data based and consumer validated approach. He is experienced and engaging storyteller keeping audience active even in after-lunch sessions. Hands-on experience gives him ability to speak of the challenges lively with numerous real-life examples.

Bio
Ivan as an experienced business leader inspired by crafting technology-based products which solve customer pains and at the same time achieve business goals for the company. With background in math and with plenty of years as a developer during the first part of his career, Ivan still finds immense pleasure in coding as part of working on his hobby projects. As the saying goes – once a developer, always a developer. After being a developer, Ivan has worked in different positions to learn the ins and outs of how a company works – from doing business development work, strategizing with company founders, to operations to improve processes inside a company. However, the biggest excitement for Ivan comes from challenges in product discovery, working with (and usually leading) a team of talented people eager to solve customer problems and build products which will make them proud in the end. Because of that, he is always looking forward to trying different methods and approaches in uncovering the problem worth solving for people. One of ways to do that is by using the continuous discovery approach, for which he would like to share his experience and findings.