← все видео

Regional Scrum Gathering 2022 - Predrag Rajković: Continuous discovery and Opportunity Solution Tree

Agile Serbia & Puzzle Software · 2022-12-08 · 51м 53с · 24 просмотров · YouTube ↗

Топики: product-discovery-loop

🎧 Аудио

📝 Summary

model=deepseek-v4-flash · prompt=summary-v7 · 16 210→2 478 tokens · 2026-07-20 14:36:02

🎯 Главная суть

Continuous Discovery — это практика еженедельного контакта продуктовой команды с пользователями через маленькие исследовательские активности, нацеленные на достижение измеримых бизнес-результатов (outcome), а не на выпуск фич (output). Фреймворк Opportunity Solution Tree (OST) помогает структурировать и приоритизировать обнаруженные проблемы пользователей (opportunities) и потенциальные решения (solutions), выстраивая прозрачную связь между целями продукта и конкретными действиями.


Определение Continuous Discovery

За основу взята концепция Терезы Торрес (Teresa Torres), описанная в книге Continuous Discovery Habits. Ключевые элементы определения: минимум еженедельные контакты команды с пользователями; маленькие исследования (небольшие порции, которые проводятся часто, а не раз в год большое исследование); нацеленность на outcome (исход, результат), а не output. Постоянное получение свежих сигналов от пользователей позволяет не опираться на устаревшие данные и понимать их реальные проблемы.

Продуктовое трио — кто должен заниматься discovery

Discovery — не обязанность одного продакт-менеджера. Три ключевые роли должны работать вместе: продукт-менеджер (знает рынок и потребности пользователей), дизайнер (отвечает за UX) и технический лид/архитектор (знает технологические ограничения и возможности). Каждый приносит свой взгляд, и совместная работа повышает качество решений. Техлид или сеньор-разработчик, участвуя в интервью, может сразу выявить технические риски и не тратить время на неподходящие решения. Навык проведения интервью нужно развивать у всех членов трио — этому можно быстро научиться.

Проблема «фабрики фич» и важность outcome

Многие продуктовые команды работают как «feature factory» — просто выполняют список задач, не понимая, зачем они это делают. Понятие outcome меняет фокус: вместо «сделать новые фильтры» команда договаривается о том, какой бизнес-результат она хочет достичь (например, увеличить число просмотренных страниц на 15%). Тогда решение (фильтры или что-то другое) становится средством для достижения цели, а не самоцелью.

Формулировка outcome и alignment со стейкхолдерами

Перед началом discovery нужно чётко сформулировать желаемый outcome. Это снимает разногласия: часто разные стейкхолдеры думают, что хотят одного и того же, но на деле имеют разные представления. Процесс согласования целевого показателя (например, «увеличить время, проведённое на портале») выравнивает понимание на уровне бизнеса и продукта, а затем позволяет объективно приоритизировать, какие проблемы пользователей решать в первую очередь.

Сбор информации от пользователей: техники и ошибки

Основа discovery — прямое общение с пользователями. Рекомендуется проводить глубинные интервью, наблюдать за их работой. Книга «The Mom Test» («Мам-тест») Роба Фитцпатрика учит, как задавать вопросы, чтобы пользователи не врали из вежливости. Критически важно спрашивать о прошлом опыте («Когда вы в последний раз искали рецепт в интернете?»), а не о гипотетических желаниях («Стали бы вы использовать такой продукт?»). Вопросы «будете ли вы пользоваться» бесполезны: люди не могут предсказать своё поведение в отрыве от контекста и цены. Слушать больше, чем говорить, и фиксировать ответы (лучше с помощью напарника или записи).

Пример контекста B2B (United Cloud)

На примере компании United Cloud (разработчик софта для группы United Group) показано, что у продукта могут быть две группы пользователей: бизнес-пользователи (сотрудники, работающие в backend-инструментах, например, для управления телепрограммой EON TV) и конечные пользователи (зрители). В таких случаях необходимо проводить интервью и с теми, и с другими, но важно понимать разные цели и профили. К бизнес-пользователям проще получить доступ через партнёрские отношения, а конечных пользователей рекрутируют через анкеты и скрининг, предлагая небольшие компенсации (ваучеры) за 30–45 минут разговора.

Построение Opportunity Solution Tree

После серии интервью у команды появляется список проблем (opportunities) и иногда готовых решений. OST помогает организовать этот хаос в древовидную структуру. Корень дерева — outcome. От него растут ключевые opportunities (например, «пользователь не знает, что читать дальше» и «у пользователя нет времени читать»). Каждая из них может иметь дочерние opportunities (например, «не видит, что можно прочитать» и «рекомендации нерелевантны»). Для каждого opportunity затем предлагаются возможные solutions (например, для проблемы «не видит» — большие фотографии или боковая панель с рекомендациями). Такое дерево позволяет видеть всю картину и осознанно выбирать, с какой ветки начать, а не забывать о других.

Приоритизация через OST

Зная outcome, команда может обсудить, какая из проблем (opportunities) сильнее влияет на целевую метрику. Например, «не знает, что читать» кажется более перспективной для увеличения числа просмотров, чем «нет времени». Среди двух дочерних opportunity можно выбрать «низко висящий плод» (low-hanging fruit) — проблему «не видит», которую можно решить быстрее. Такой подход заменяет споры «я думаю это важнее» на аргументированный диалог, основанный на данных и логике.

Валидация решений и прототипирование

Когда для выбранной opportunity предлагается решение, его нужно проверить на пользователях. Важно делать прототипы максимально «уродливыми» и незавершёнными: если прототип выглядит как финальный продукт, пользователям неудобно критиковать его (они думают, что команда уже вложила много усилий). А когда видно, что это набросок, пользователи охотнее указывают на недостатки. Достаточно протестировать прототип на 5–7 человеках — даже при таком небольшом размере выборки становятся очевидны крупные проблемы (например, кнопка посередине экрана, которую половина пользователей не заметила). Статистическая репрезентативность не нужна, важна качественная обратная связь.

Итеративный цикл discovery

Весь процесс не линейный. Определение outcome — самый большой цикл (меняется редко). Сбор opportunities, анализ, выбор, тестирование решений — это повторяющиеся циклы разного масштаба. Команда постоянно движется по спирали: каждый контакт с пользователем увеличивает уровень знаний о продукте и уменьшает неопределённость. Discovery и delivery (разработка) идут параллельно.

Связь с user story

Пользовательские истории (user stories) — это результат работы discovery. OST подготавливает почву для написания качественной user story, потому что фича привязывается к конкретному opportunity и outcome. Без discovery user story остаётся просто списком функциональности без понимания «зачем».

📜 Transcript

hr · 6 897 слов · 105 сегментов · clean

Показать текст транскрипта
Na početku, da se predstavim. Moje ime je Peđa Rajković. Danas sam zamislio da ovdje urodimo jednu radionicu da pričamo malo o tome šta je Continuous Discovery i da pričamo o Opportunity Solution trio. They are native tongue. Dakle, pričamo o Continuous Discovery Opportunity Solution Tree. Ajde, da, i pre nego što počnem, još jedna tehnička stvar. Vidjeli ste u najavi, ovo je radionica iz dva dela. Jedan deo se dešava sad, drugi posle ručka. E sad, moje pitanje za vas je da li hoćete da to spojimo, da bude, što bi rekli u cugu, jedna radionica od sad dok ne završimo. Neće nam trebati dva sata. Ono što je variabilno ovde jeste deo u kome vi sad prezentujete šta ste uradili i dobijete neki feedback. Možda bi trebalo da kažem kako sam zamislio radionicu. Znači prvo jedno pola sata neke teorijske priče da svi budemo na nekom istom nivou razumevanja stvari i da koristimo isti rečnik. Posle toga jedno pola sata vi radite... taj radionički zadatak i posle toga ide deo gdje vi sad prezentujete šta ste uradili i kako ste uradili, a ostali vam daju feedback, znači opet neka vrsta komunikacije i diskusije. I taj deo u stvari nije kontrolabilan, je li dosta zavisi, ja nisam znao koliko će grupa biti, ali mislim, ako kako smo se poređali po stolovima, čini mi se da je to nekih šest grupa, pa sad to je malo manje kontrolabilno. Šta je moje pitanje za vas? Da li hoćete da krenemo sad i da radimo dok ne završimo? U riziku vam je pauza za ručak, onda nećete imati svih sat vremena. Mislim, opet i to je pod našom kontrolom, možemo bilo kada kažemo dobro, sad je dosta i šta smo uradili, uradili, idemo na ručak. Ili da radimo sat vremena, pa pauza za ručak od sat vremena, pa da nastavimo u drugih sat vremena. To je pitanje. Znači opcija A, radimo u cugu, opcija B, sečemo ručkom. Ajmo, ko je za opciju A, neka digne ruku. Opcija A, radimo u cugu. Da. Jedan, dva, tri. Ajde, izvoli. Šta, ako dođu? Aha. Da, da, da, slobodno. Na drugi deo misliš ako dođu novi. Ja se nadam da su razumeli da sesija počinje sad i da traje sve vreme. Tako da ako se neko pojavi... Jel da? Uf, da, to je. Tako je, mislim, i ako dođu oni i... Da, da. I ako... Možemo da organizujemo konsultacije za njih posle. Zato što i ako dođu na drugu sesiju, prosto neće moći da se priključe jer ta će biti sad feedback. Tako da mogu, mogla bi onda da organizuju feedback, ali ako dođu, ja sam tu, pa možemo sa njima da prođemo ako budu zainteresovani. Ajmo onda iz početka. Ko je za to da radimo u cugu? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 12, 13, 13. Dobro, a ko je za to da delimo, da imamo pauzu za ručak? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Dobro. Dobro. Ništa, radimo u cugu. Ljudi koji su planirali nešto u pauzi za ručak, mislim slobodno izađite pa se vratite možda ako imate neki dogovor, neki sastanak. Dobro, ajmo onda da krenemo, da ne gubimo više vreme, da krenemo. Pa reći o meni, zašto sam uopšte ja ovde i zašto ja sad pričam u ovome. Bavim se produkt manažmentom više od 15 godina, radi u različitim industrijama, sa različitim timovima. Nešto u IT industriji, nešto u telco industriji, product management mi je nekako najbliži i ono gde ja najviše vidim sebe. Zašto ova tema i zašto ja pričam o ovoj temi? Prilično je aktuelna. U poslednjih otprilike godinu dana se dosta priča o njoj, a u kompaniju kojoj radim, u United Cloudu, smo počeli da primenjujemo Opportunity Solution 3 i mislim da je onda dobro i da vam ispričam malo iz te perspektive. neko ko je implementiruo i ko je počeo da koristi ovaj framework, da vam dam neki insight kako to izgleda i šta je, a sa druge strane i da probam ovdje da uradimo barem jedan deo aktivnosti vezanih za Opportunity Solution 3. Danasni dan, prošli smo kako izgleda, morali smo malo unapred da radimo i dolazimo do priče o čemu mi u stvari danas ovdje pričamo. što sam ja želeo da obradimo danas, jeste pre svega koncept Continuous Discovery-a, a u kontekstu Continuous Discovery, onda i framework Opportunity Solution 3. Šta je Continuous Discovery uopšte? O čemu mi pričamo? Pa, ajde onako par pitanja za vas pre nego što nastavimo. Koliko vas je radi u IT industriji? Dobro, skoro svi. Nije neočekivan. Onda, verovatno, ste se sreli sa terminima kao što su continuous delivery. Kao što developer imaju svoj continuous delivery, prirodno je nekako da i produkt ima svoj continuous discovery. Zašto? Jedan korak nazad. Ono što pokušavamo da radimo sve vreme jeste da korisnicima pružamo neki value konstantno u toku vremena. Da sa svakim nekim malim release-om pružimo ljudima i neki value. Da bismo bili u stanju da to radimo kontinuirano, da kontinuirano isporučujemo neku vrednost, mi moramo i da kontinuirano radimo discovery, odnosno da razmišljamo o tome šta je to što treba uraditi, odnosno šta je to što treba napraviti za svoje korisnike. Često onako kad pričamo o Scrumu, nekako Scrum je dosta fokusiran na development, na software development pre svega i na developere i njihove probleme. onako sam Scrum dosta previđa ili ne ulazi u to šta se dešava pre backloga, šta se dešava pre nego što stvari stignu do developmenta. A pre te tačke postoji mnogo toga. To mnogo toga praktično je ovaj discovery u kojem pričamo. To je recimo faza ili deo neke aktivnosti u kojima mi... Pokušavamo da shvatimo šta je to što našim korisnicima treba, šta je to što ih muči i na koji način mi to možemo da zadovoljimo te njihove potrebe. Dakle, u ovom načinu funkcionisanja kako danas funkcionišemo, pogotovo u softverskoj industriji, neophodno je da kontinuirano radimo i ovaj kraj, isporuka vrednosti samim korisnicima, a isto tako i... ovaj početak, znači discovery, odnosno otkrivanje, šta je to što želimo korisnicima da isporučimo. Ono na što se ovdje danas referišemo jeste u stvari, ajde da kažem, definicije i rad Tereze Torres. Tereza je, ona sebe zove Product Development Coach, neko ko radi sa pre svega produktnim timovima, osoba koja ima mnogo iskustva. već godine rada po različitim industrijama, u različitim kompanijama, vodi svoj, a ja bi ga nazvao edukativni centar, nisam siguran baš kako ona definiše svoju aktivnost, i piše dosta o produkt managmentu. Prošle godine je objavila knjigu Continuous Discovery Habits, koja u stvari predstavlja skup nekih njenih razmišljanja, pisanja na njenom blogu. uobličeno i formirano u diskusiju o tome kako pomoći product managerima da rade taj discovery. Kako raditi ovaj continuous discovery i koji su to alati koji mogu da pomognu product managerima. Ona sama kaže, za nju je continuous discovery, at a minimum, weekly touch points with customers by the team building. Building the product where they conduct small research activities in pursuit of desired outcome. Sada ću vam malo da seciram ovu njenu definiciju. Šta u stvari po njoj predstavlja ovaj Continuous Discovery? Znači, prva stvar u ovoj definiciji jeste najmanja učestalost jeste jednom nedeljno. Zašto? Zato što poenta ovoga jeste... biti u konstantnom kontaktu sa korisnicima. Bilo kroz customer intervjue, bilo na neki drugi način, ali konstantno primati signale od korisnika. To je nama kao produkt menadžerima jako važno, zato što je to izvor, da kažem, inspiracije za to šta treba u buduće raditi. Ti signali koje dobijemo od korisnika, kroz njih u stvari ulazimo u mozak njihov, shvatamo njihove probleme, shvatamo šta je to sa čime se oni suočavaju, dok koriste naš proizvod ili dok koriste neki drugi proizvod ako želimo da pravimo proizvod od početka. I zato je nužno biti stalno izložen ovim signalima. Pričat ćemo malo kasnije o tome kako se ovo radi. Postoje naravno izazovi, da ih nazovem, ovde. Naravno da je to vremenski zahtevno i naravno da mora se drži pod kontrolom jer uglavnom ovo nije jedina aktivnost koju neki produkt menadžer radi. Druga stvar na koju Tereza ovako baca svetlost jeste ko to treba da radi. I ona kaže tim koji upravlja proizvodom, koji kreira proizvod. I ovo je nekako u saglasnosti sa celom design thinking filozofijom koja insistira na tome na principu get out of the building. Znači vi koji radite na proizvodu, vi ste ti koji morate da izađete... pred svoje korisnike, da sa njima pričate, da razumete šta je to, koje su njihovi problemi. Bez te direktno kontakta između korisnika i osobe koja vodi proizvod, kako da kažem, teško je napraviti nešto za nekoga ako ne razumeš tog nekog i njegove probleme, što bih rekli, ako ne hodaš u njegovim cipelama. Vratit ćemo se malo na to što znači ovo tim koji pravi... proizvod. Znači to su ljudi koji upravljaju proizvodom, ne jedna osoba, već više njih, a vratit ćemo se malo kasnije na tu temu. Da, to je ta tema, samo što nisam završio sa prethodnom. Treća stvar, mala istraživanja. Znači, ovi kontakti sa korisnicima su neki mali čankovi gde mi proveravamo neke stvari, ispitujemo neke stvari, razgovaramo sa korisnicima. Zašto mali? Zato što je logika da ukoliko često imamo male interakcije sa korisnicima, to je efikasnije i efektivnije nego da imamo jednom godišnje neko veliko istraživanje gdje mi sad nebitno odradimo kvalitativno ili kvantitativno istraživanje, pričamo sa korisnicima u fokus grupe i to uradimo u jednom trenutku. Mnogo je efektivnije kad to radimo stalno, jer smo onda stalno dobijamo sveže. jer ako se oslonimo na inpute koje smo dobili u februaru mesecu, a danas je novembar, ti inputi su verovatno prilično bajati. Pitanje je koliko su uopšte validni. Te zbog toga pričamo o ovoj učestalosti, ali malih čankova tog ispitivanja. I konačno, na što bih se jeo stvarno ovdje, jeste ovaj outcome, o kome ona priča, zašto je on važan? Zato što... Priča o outcomeu, uverovatnosti se sretali i kod drugih autora, ono outcome versus output, unosi jednu drugačiju paradigmu u celo posmatranje sobstvenog proizvoda. Šta je outcome? To je, nisam siguran, sad malo smo se u nekom trenutku pričali o tome šta je dobra reč u srpskom jeziku, pa verovatno je to ishod, možda cilj baš nije najbolja reč, ali također dosta dobro objašnjava. To je ono ka čemu težimo, šta je ono što mi želimo da ostvarimo. U ovom slučaju, šta je to što želimo da naš proizvod ostvari u nekom vremenskom periodu. Zašto je to bitno? Zato što pravi jako veliku razliku. Dobar deo produktnih timova, pa science team i development timova, je fokusira na output, na feature koje treba da napravi. I postoje jedna potpuno mračna strana meseca, jedna... nepoznanica zbog čega mi pravimo taj konkretan feature. To su takozvanje feature factory gdje vi kažete, ok, sad treba da ne znam, napravimo nove filtre na našoj stranici, a niko ne zna zašto baš pravimo nove filtre. Neko je rekao i prosto radimo tako. Outcome uvodi to da svi budemo svesni zbog čega, što mi hoćemo postignemo. Čime ćemo to da postignemo, to je onda potpuno druga stvar. Ja bih vas pozvao da slobodno me zaustavite ako negde postoji potreba, ako nešto ja zabrzam. Možno, doći ćemo i na radionici ćemo, to je jedan deo radionice, a doći ćemo i malo kasnije do njih. Ok, ko, sad ulazimo polako u tu priču Continuous Discovery, a ko je u stvari taj koji treba raditi Continuous Discovery? I, Tereza ih zove Produkt Trio, drugi autor ih zovu Trio Migos. Različiti su nazivi, ali suština je u stvari da troje ljudi treba da bude tim koji je odgovoran za razvoj proizvoda. To troje ljudi čine product manager, neko iz tehničkog dela, ali tako neki sistem arhitekta, tech lead, senior developer i neko iz dizajna. Zašto baš te tri osobe treba da vode proizvod? Zato što... Sa jedne strane, njihove uloge su jako važne za sam razvoj proizvoda, krucijalne. Sa druge strane, one unose različite poglede na sam proizvod. Znači svako ima neku svoju ekspertizu, neko svoje znanje koje donosi u taj tim. Product manager zna jako dobro korisnike, šta su njihove potrebe, zna tržište, šta se dešava, šta drugi rade, šta su uradili. Design lead pozna je dobro UX. posmatra aplikaciju i korisnika i korisničku interakciju sa te strane. I osoba sa strane developmenta, sa strane tehnologije, poznaje upravo tu tehnologiju, zna koje su ograničenja, zna šta je to što može, što ne može, gde može da se istražuje, kako stvari mogu da se optimizuju. I on takođe posmatra i korisnik je sa svoje strane, koliki load je na našoj aplikaciji. Svako donosi neko svoje specifično znanje i ta znanja udružena u stvari treba da vode ovaj proizvod. I zbog toga su ovo troje ljudi neko ko treba da upravlja proizvodom i neko ko treba da radi continuous discovery. I ono što se sad ovdje postavlja pitanje jeste imali smisla i kako to, da ne znam, tech lead radi discovery. Zašto bi se on bavio time? Zato što se time postiže u stvari kvalitet ovog discoverija. Zato što u startu tokom discoverija hvatamo stvari koje su... potencijalno problematične, hvatamo koje su to nova rešenja do kojih možemo da dođemo i zato je neophodno da i ta osoba bude tu. Drugo pitanje je koje se poslalja, je li nije to uludo trošenje vremena? Pa, bilo tech leada, bilo design leada, obično ljudi uzimaju kao product manager po defaultu, kao to je njegov posao i treba se baviti time, ali zašto bi se i ovi ostali bavili time, zato nije trošenje vremena. Pa, ako napravimo kvalitetniji proizvod, onda je to najbolje moguće utrošeno vreme. Koliko god daje, napravili smo dobar proizvod. Mnogo je bolje nego da je sam product manager tamo smišljao nešto i onda trošili vreme na neke definisanje tog proizvoda, na promjenu zahteva itd. Prosto ovo je neko najbolje utrošeno vreme. I naravno, jedna od stvari sa kojima se ljudi susreću i mi smo se također susreli kad smo počeli da implementiramo Opportunity Solution 3, jeste šta ako ljudi nisu vešti, prosto nisu nikad radili intervjue sa korisnicima. Pa ništa, moraju da se nauče, ali tako, mora da postoji neko koji će da ih nauči kako se to radi, kako se razgovara sa korisnicima, šta treba pitati, šta ne treba pitati, kako treba pitati i tako dalje. Prosto to je jedan razvoj nekog skillseta koji poseduju ovi ljudi koji učestvuju njemu. Znači, da, oni i razgovaraju sa korisnicima, oni i... zovu te korisnike, organizuju ispitivanja i naravno dalje rade ostatak Discovery-a. Tako da prosto jeste, problematično je, produkt menadžeri kako ko neko ima iskustvo u takvim stvarima, neko nije, tek ljudi uglavnom nisu, dizajneri ako dolaze sa juve strane jesu, ali opet kažem ne nužno, tako da onako to je pomješana jedna ekipa i potrebno je raditi na razvoju svakog od njih. nije ništa nemoguće, niti je preteško, da kažem, vrlo brzo svi uđu u to kako to treba raditi. Dobro, ova priča, sad, oveme smo ispričali kako mi u stvari, šta je continuous discovery, kako pokušamo ga radimo. I sad, kad kažemo ok, skapirali smo ko to radi, da treba stalno sviđamo sa korisnicima, da od njih skupljamo neke informacije, onda se postavlja pitanje, kako to sad izvesti. I ono što Tereza nudi kao predlog, jeste ovaj framework koji ona zove Opportunity Solution 3. Ono što ona kaže da je uočila kod ljudi koji se bave product managementom, jeste da često im nedostaje neka vodilja u smislu šta je sljedeći korak, šta uraditi, kako isprioritizovati stvari, tako dalje, i onda je ona, sa tim insightom, ajde da kažem, izgradila ovaj Opportunity Solution 3. Ona ga zove, to je kao neka vizualna pomoć za ljude koji se bave product managementom, odnosno discoveryom konkretno, u samom sprovođenju tog discoverya. I ono zašto je Opportunity Solution 3 dobar jeste što nam pomaže da uspostavimo vezu između nekih glavnih komponenti. Siguran sam da ste se susretali sa tim da product manager i tim daju, kažu, mi sad radimo na tom i tom feature-u, malo pre ne znam, filteri recimo. I da u stvari niko baš ne ume da opiše kakva je veza tih filtera koje radimo trenutno sa onime što korisnik je muči. Onako, to ostaje malo maglovito. Ono što Opportunity Solution 3 daje jeste u stvari tu vezu između solušena, opportunity-a i ono kad čemu svi treba da težimo, a to je, beogradski uzdači vole baš sirene, a to je sam taj outcome ili cilj koji želimo da postignemo. Znači, pravi jednu onako misalnu vezu između cilja, ono što želimo postignemo, koji su to problemi koje želimo da rešimo korisnicima, a koji nas vode bliža ovom cilju i koje su to rješenja na kraju koja... odgovaraju na ove potrebe korisnika, odnosno njihove probleme. Izvoli. U user story, misliš? Tako je, imamo. Ali, tako je. S tim što user story je posledica ovoga. Tako je, tako je. Ne, ne, to je, mislim, pitanje je odlično, tako je, jer ovo u stvari prethodi pisanju user story-a. Da bismo u user story-u kvalitetno opisali šta želimo, da bismo timu dali okvir... u kome se kreće, neophodno je da mi osvestimo te stvari, a to radimo kroz Discovery. Dakle, postavljanje jedne logičke veze između cilja koje želimo da ostvarimo, opportunity-a, odnosno problema korisničkih koje želimo da rešimo i samih rešenja. Odakle krećemo? Pa krećemo od, ja sam ovdje rekao kao, outcome je... koren, ali pošto je koren, nisu to onako razgranat, a outcome bi trebalo da bude jedan, kao ajde stablo ovog našeg drveta, znači osnova na koju oslanjamo ovo naše drvo. Zašto je bitno da formulišemo outcome? Mislim, nekad u organizacijama ljudi kažu pa dobro, znamo što želimo da postignemo. I sad to znamo što želimo da postignemo je jako opasno, zato što ja znam da želim da postignemo nešto, a ti znaš da želimo da postignemo nešto drugo. A neko treći zna da želimo postignuti nešto treće. Sve dok ne izgovorimo šta je to što želimo postignemo, to je individualno znanje. Tek kad mi sednemo za stoj i kažemo, je li se mi slažemo da želimo postignemo to i to? I kažemo da, mi želimo postignemo da, ne znam, posle ove radionice ljudi izađu svesni toga šta je Opportunity Solution 3 i isprobali su jedan deo njega i to nam je cilj. U tom smislu onda imamo zajednički outcome, zajednički cilj kako me težimo. Znači, pravimo alignment na više nivoa. Jedna stvar jeste alignment sa stakeholderima. Želimo da imamo dogovor sa stakeholderima, sa klijentima, sa predstavnicima korisnika, sa predstavnicima biznisa, kogoda su na stakeholder i o tome šta želimo postignemo sa našom aplikacijom. Malo pre si pitao za biznis ciljeve. Znači, biznis cilje je ono što biznis, kako mu ima kaže, očekuje od našeg proizvoda. Znači, po pravilu biznis ima dosta banalne očekivanja od proizvoda, a to je povećati profitabilnost, povećati zadovoljstvo korisnika, povećati... vidljivost brenda, znači to su najčešće biznis ciljevi koje biznis želi od našeg proizvoda. Kao layer ispod imamo produktne ciljeve. Znači, produktni... Izvim, ništa šta. Produktni ciljevi u stvari priča o tome što želimo konkretno za taj proizvod da on uradi, ne bi li podržao ovaj biznis cilj, je li tako? I onda ako nam je biznis cilj, želimo da povećamo profitabilnost, profitabilnost, produktni cilj bi bio hoćemo više mesta za advertising na našem proizvodu. Znači jedno i drugo moraju da budu u korelaciji. Definisanjem ovih ciljeva mi u stvari se dogovaramo šta je to što želimo da uradimo. Zašto je to bitno? Zato što onda svi težimo u istom cilju. Onda kad pričamo o tome u onom posljednjem ishodištu, kad pričamo o featureima koje treba da uradimo, da li želimo da... stavimo banere sa leve i desne strane ili želimo da sa leve i desne strane stavimo neki poziv za humanitarnu akciju, onda se osvrnemo na taj cilj, šta želimo da uradimo, želimo da povećamo prostor za banere, želimo da bi podržali cilj povećanja profitabilnosti, tako da onda vrlo jasno postaje šta je feature. koji ćemo raditi. I to je u stvari logika kojom se vodi i product management inače, ali kao Opportunity Solution 3 mu pomaže u tome. Dakle, postavljanje outkama ili ishoda ili ciljeva nam omogućava alignment na različitih nivojima kao i prioritizaciju stvari koje želimo da radimo. Kada smo postavili, inače sad ono kao anegdota iz života, Ono što se dešava, recimo kad smo mi sad sa stakeholderima pričali o tome šta želimo da nam bude outcome i kad smo se dogovorili, ono što je interesantno jeste ne samo pojašnjenje komunikacije na relaciji mi kao produkt, tim i naši stakeholderi, nego i bolja komunikacija između stakeholdera. Jer sve do te tačke, onaj sindrom koji sam malo pre pominjao, nas troje, mislimo da isto... mislimo da isto želimo, se u stvari pojavljuje povremeno i onda vidimo da u stvari nemamo baš identičan pristup tome šta želimo od našeg proizvoda. Ovime omogućujemo i alignment, znači kod stakeholdera, ne samo između stakeholdera i produktima. Što je vrlo onako blagotvorno i dosta dobar, tada onda i stakeholder je dobio dosta dobar pogled na sve ovo što radimo. Jer kao i oni videe prepoznaju značaj toga. Kada smo se dogovorili šta je cilj koji želimo da ostvarimo, sljedeća stvar jeste početak priče sa našim korisnicima. Može na različite načine da se radi. Ono što je bitno jeste taj učestalost kontakta i direktna priča sa njima. Može da se radi kroz dubinske intervjue, kroz posmatranje korisnika, kako rade, kako koriste naš ili tuđi proizvod. Ovdje sam navio i Mam Test, to je knjiga Roba Fitzpatrika, moja preporuka za sve koji se bave produkt managmentom, dosta slikovito i jednostavno opisuje šta su dobre prakse, kako komunicirati sa korisnicima, kako postavljati pitanja. Mam Test se zove zato što kažu, jedna od osnovnih pravila u produkt managmentu je kao nemoj svoju mamu da pitaš je li ti dobar proizvod, kao sigurno ću ti reći dobar je proizvod, kao mama ti je. E, pa ovo je kao kako da postaviš pitanja i svojoj mami tako da ona ne može da te slaže. Ispod svega je problem produkt manažmenta kao kako ja da saznam šta korisnici žele kad svi hoće da me slažu. Ne iz loših namera, nego baš nasuprot. Vide da sam ja zainteresovan, da je to moj proizvod, možda sam pustio posao zbog njega, možda mi je jako stalo zbog unapređenja. I onda kad to ljudi prepoznaju, prosto ljudi su empatično bića i onda... te lažu jer ne žele da te povrede, ne žele ti kažu baš ti bez veze, to ja nikad ne bi koristio. Pa ova knjiga baš obrađuje takve stvari. Par nekih tipova kad radiš, nemoj sam da radiš, znači jako je teško da pričaš sa nekom osobom, da se fokusiraš na formu pitanja, kako treba formulisati pitanje, da vodiš taj razgovor i da pri tome pamtiš i beležiš šta je to što ti je druga strana dala. odnosno izgovorila. Lakše je uz pomoć kamera i ostalog, kad ti možeš da snimaš ceo razgovor, posledaj pregledaš, ali je još lakše ako imaš nekog saradnika koji će biti tu i beležiti stvari koje ti ispričaš sa korisnikom. Ono što je jako važno jeste da ti si došao tu da čuješ korisnika, da saznaš nešto od njega. Nisi došao da pičuješ svoj proizvod, nisi došao da... pokažeš kako si ti najpametniji zato što si s nešto smislio, nego si došao da čuješ njega i njegove probleme. Tako da što više ćutati, a što više pustiti ljudi da pričaju. I ono što je jako važno, šta treba ispitivati jeste njihovo iskustvo, a ne šta je to o čemu oni maštaju i žele. Na šta mislim konkretno? Pitanje je da li biste koristili ovakav proizvod, nema nikakvu vrednost. Reći će vam bih koristio ili ne bih koristio, ali ta sama informacija nema vrednost, zato što on u tom trenutku ne može da se stavi u situaciju da li bi u nekom hipotetičkom slučaju nekad koristio proizvod. Pri tome, mnogo faktora utiče na to da li bi on koristio taj proizvod. Nismo pričali o tome koliko košta taj proizvod, u bilo kom smislu. Možda bi ga koristio ako je za džabe, a možda ga ne bi koristio ako košta 5 dolara. Tako da, pitanje te vrste su... prilično, ako besmisleno, ono što u stvari po čemu vi hoćete da kopate jeste njegovo iskustvo sa korišćenjem sličnih proizvode ili njegovo iskustvo sa problemima koje bi taj vaš proizvod rešio. Znači, pitanja tipa, smo imali neki primjer, ovdje nismo, šta je to, recimo, kada ste poslednji put, ne znam, pretraživali šta god, recepte, recimo, na internetu. To je konkretno pitanje koje nas uglači dalje u priču. Zato što osoba onda može da vam kaže, pa posljednji put sam to radio prekjuče. Pa vi onda kažete, ok, šta ste pretraživali, kako je to izgledalo, je li ima nešto što vas je tu frustriralo, je li ste koristili neke različite načine da pronađete recepte i tako dalje. To su pitanja koja kopaju sad po njegovom iskustvu. Znači, to je ono što on zaista radi i to je njegov iskustvo korišćenja nekih proizvoda koje su slične nekom budućem vašem ili vašem koje sad imate. Znači kopamo po iskustvu, a ne po imaginaciji i maštanju. I sad smo ispričali priču sa našim... Izvoli. Da, da, baži. Da, da, može. Da, United Cloud je u suštini B2B. Mi proizvodimo softver za United Group. Međutim, naravno, taj softver koriste i krajnji korisnici. Mislim, ono, sad konkretno ako pričamo, ne znam... SBB je jedan od klijenata United Cloud-a, EON TV, vjerojatnosti ako ne koristite, vidjeli ste po billboardima i reklamama, EON TV je jedan od proizvoda koji radi United Cloud. Naš klijent je SBB, vi kao krajnji korisnici koristite taj EON TV. Ono što mi moramo da radimo jeste priča na obe strane, jer takve proizvodi imaju svoje neke komponente, neke module koje koriste ti ljudi iz SBB-a. da bi ubacili onu metadatu, slike, opise, onaj EPG što se zove, odnosno programsku šemu. Znači naši korisnici naših aplikacija su ovi ljudi iz United Grupe, kao biznis stakeholders, njihov biznis zavisi od toga što mi napravimo, kao korisnici jer koristete back office alate koje mi pravimo i sa druge strane krajnji korisnici koji gledaju sad televiziju preko Eona. I u tom smislu, Kad mi pričamo o ovome, mi pričamo u stvari i sa jednima i sa drugima. Zato što postoje stvari koje targetiraju jedne i koje više targetiraju drugi. Ovi back office alati, za njih su u principu jako zainteresovani. Različiti su koriznici, naravno, i različiti su i stakeholders za njih. Za ove back office alate su zainteresovani... ljudi koji rade hands-on na njima, koji unose taj programske šeme, slike i ostalo, krajnji korisnici opet sa svoje strane gledaju to. Lakše je doći do ovih prvih, jer kao postoje neki tu sad odnosi, poslovni, kolegijelni itd. Na kraju krajeva zainteresovani su da budu tu. Nije problem doći ni do ovih drugih. Do ovih drugih dolazimo raznim metodama rekrutacije. Uglavnom, regrutujemo, znači napravimo profil, kako izgleda osoba sa kojom želimo da razgovaramo za taj i taj konkretan problem. I onda idemo, tako kažem, regrutacija unutar firme. Znači, ajmo sad, ko zna ljude koji zadovoljavaju ovaj profil? Nešto kao dobrovnje davalci krvi. Pa sad ti prijavljuješ svoje rodbinu i ostalo, radimo trijažu da vidimo taj koga si prijavio, stvarno se uklapa u naš profil. ili ne, i obezbeđujemo neke incentive, tipa voucheri za, mislim da je bilo za Lidl, ako se ne varam, tog tipa incentive obezbeđujemo, prosto da ljudima nadoknadimo tih nekih pola sata, 45 minuta, sat vremena koje su proveli sa nama pričajući o njihovom iskustvu kako koriste proizvod. Nismo, da, za sada smo još uvek, ja moram da se skinu meni vruće ovde, ne znam vama, otvoreni su prozori, ali... Dobro. E, dakle, ispričali smo priču sa korisnicima i do čega smo mi došli? Došli smo do jedne pozamašne liste stvari koje su oni iznali kao svojih problemi. Međutim problemima našli su se i neka potencijalna rješenja, jel? Ali imamo gomilu, ja sam sad ovdje izmislio nekih 6-7 stvari i kažemo, ok, mi znamo da je naš cilj povećati broj poseta ili broj korisnika na nekoj strani. I kad smo pričali sa korisnicima, shvatili smo da korisnici ne znaju šta sledeće da čitaju. Ovo je neki naš portal izmišljeni. Bilo bi dobro da imamo veće fotografije koje bi privlačile korisnike. Korisnici nemaju ideju šta da čitaju dalje. Stvari koje im preporučujemo za čitanje kao neki sledeći članak nisu relevantne za njih. treba koristiti one sidebarove za predlog je šta da oni čitaju dalje. Korisnici nemaju vremena da čitaju. I sad mi kao product manageri smo se našli u jednom, da ne kažem, nebranom grožđu, ali u jednoj nekultivisanoj bašti. Imamo gomilu stvari koje smo otkrili i mi sad treba kažemo, ok, čime ćemo i da se bavimo? I dolazimo do problema, mi treba isprioritizujemo ove stvari, ali tako ne može tim da uzme da radi na svemu ovome. Moramo kažemo je prvo radi na ovome, pa na ovome, pa na ovome i tako dalje. Ok, znamo da hoćemo poveći broj strana koje otvoramo, ali kako da uporedimo sad koristnik ne zna šta da čita sledeće sa preporučene stvari nisu relevantne za njih. Šta je od toga sad bolje da radimo prvo? A da ne uđemo u borba mišljenja, ono, straglovo opinion, pa ja mislim i ti misliš i sad kao... I tu onda uskače Opportunity 3 kao moguće rješenje. Ono što nam Opportunity 3 nudi jeste u stvari struktura koja sada organizuje ove naše stvari. To je mi organizamo kroz tu strukturu, neće Opportunity 3 sam ništa da uradi, nego moramo mi kroz njega. I mi u stvari onda kažemo, ok, ovaj prvi nivo, takozvani outcome layer, je jasan, kao njega smo odredili. I onda ređemo opportunity. Pokušamo da ustanujemo koji su odnosi između svih tih opportunity koje smo mi otkrili. I odnosi mogu da budu sestre, mogu da budu u nekom istom nivou, mogu da budu majka i čerka, ili majka i više čerke. I sad u ovom našem hipotetičkom primjeru mi kažemo, ok, otkrili smo opportunity koji kaže korisnik nema šta da čita. I drugi opportunity koji kaže korisnik nema vreme da čita. To su neke dve stvari sa koje mi baratamo. A onda unutar ovoga korisnik nema šta da čita, smo otkrili da korisnik ne vidi šta je sledeće što može da čita i preporučene stvari nisu relevantne. I jedna i druga gađaju ovaj problem da korisnik nema šta da čita. Bilo što ne vidi, bilo što mu preporučuju mu bez veze. Zato su njih dve čerke ovog gore, a međusobno sestri. I na kraju od onih stvari koje smo izređili imali smo i dva solušona. Znači ovo je neki opportunity space i ulazimo u solution space gdje kažemo za ovaj opportunity korisnik ne vidi šta da čita, možemo da mu ponudimo da na sidebaru istaknemo neke preporuke ili da napravimo veće fotografije koje će ga privući, kao nije primetio, nije provaljivao, da uopšte postoji nešto tu da se čita, a mi ćemo sad većim fotografijama da mu to istaknemo. Šta nam ovo omogućava? Ovo nam omogućava da mi sad lako možemo da pričamo o tome na šta hoćemo da se fokusiramo. Zato što mi kažemo, ok, ako hoćemo povećamo broj posetilaca ili broj strana otvorenih, da li će više na to da utiče to što korisnik nema šta da čita ili to što nema vremena da čita. I onda ulazimo u jednu konstruktivnu i... relativno laku diskusiju o tome koje oportuniti smatramo da ima smisla prvo raditi. Znači ono što je važno ovde jeste ne zaboravljamo mi ništa od ovoga. Mi samo radimo trenutne prioritete. I prema trenutnim prioritetima mi kažemo smatramo da je korisnik u veći problem to što nema šta čita. On je došao na naš portal. Verojatno ima nešto vremna, svakako neki nemaju. Došlo mu je autobus, on je čito na stanici, došlo mu je autobus, on je prekinuo da bi ušao u autobus, ili tako. Ili se nalazi između sastanaka ili na sastanku, krišom čita i nema vremena čita. Ali, kažemo, ipak je ovde verojatno veći potencijal da popravimo ovaj naš, ili da dostignemo ovaj naš cilj. Od ove dve sestre, čime ćemo se bavimo? Rekomendejšnom ili to što ne vidi šta da čita? Možda je to što ne vidi low hanging fruit, ajde prvo to da rešimo. I isto tako ulazimo u solution. Kada smo ovo uradili, ulazimo u zonu testiranja, odnosno pravljenja rešenja. Prvo ja sam malo sad skočio već da bih se ubrzao sa vremenom. Koje su to sad tehnike koje možemo da koristimo pri... pa i principi, sad ovdje je malo sve povezano, odnosno stavljeno na jednu listu. Prvo, ono što je bitno da tokom intervjua slušamo korisnika šta priča. Neka će izleteti rešenja i odatle iz te priče. Naravno, nije pojenta da mi zabeležimo kao to treba da uradimo. To treba da validiramo, da li treba da uradimo, ali svakako je vredno toga da zapišemo. Znači, neki solušeni nastaju, neke rešenje, neki fičeri nastaju i tokom razgovora sa korisnicima. Ono što je jako važno ovdje jeste definisanje persone, zato što u zavisnosti toga ko nam je ciljna grupa, ko su ciljni ljudi koje želimo da pogodimo, zavisići toga kako će izgledati taj feature koji ćemo napraviti. Različiti treba izgledati feature koji je pravljen za neko koji ima 19 godina od neko koji ima 39 godina. Različite ponašanje, različite su potrebe. Ono što je jako bitno jeste smenjivati takozvani diverge-converge princip. da izbacimo što više mogućih rješenja, što više ideja, pa onda njih da sužavamo, da odbacujemo neke koje nam se čine kao dobre. Sa druge strane, razmena mišljenja je jako dobra u fazi evaluacije nečega. Ljudi su dobri da samostalno kreiraju ideje, ali su jako dobri da u grupi evaluiraju neke ideje. Tako da i tu treba praviti jedan i drugi pristup. Malo pojedinačni rad, malo grupni rad. Kada smo sad... uradili neke rješenja, dolazimo do validacije ovih rješenja. Ono što je dobro raditi jeste koristi prototip. I ono što je važno za prototip, samo par reči, jeste prototip treba da bude ružan. Treba da se vidi da to nije gotova aplikacija. Zašto? Zato što kad pred korisnika stavite nešto što izgleda kao gotova aplikacija, on kaže, aha, ovo je nešto gotovo. taj čovjek je uložio puno vremena ili ti ljudi su uložili puno vremena u to, ja ne mogu sada im kažem da je ovo bez veze. Oseća će se loše. Uložili su puno vremena u nešto što ću ja sad kažem pa meni ovo ne radi posao ili ja ne umem ovdje da se snađim itd. Zato je važno da prototip bude jasno da je prototip i bez mnogo objašnjavanja. Zato što je onda jasno, ha, ok, to ste vi nešto na brzaka uradili, pa to što ste radili na brzaka ne valja ovo, ne valja ovo, ne valja ovo i pokupite u stvari mnogo veći... set informacija i spravnijih nego da ste se trudili, stvarno uložili puno vremena i napravili prototip koji izgleda kao nešto finalno. Ono, čisto kao inspiracije radi. E, izvoli. Uglavnom ne isti nego drugi. Sad zavisi od konkretnog slučaja. Kad su ovi... poslovni korisnici, naše kolege, onda koristimo i iste, jer to su onda često ljudi koji već imaju iskustva, radu na tim aplikacijama i tako, kad su eksterni korisnici, krajnji korisnici, onda uglavnom zovemo različite da dođu, jer onda nema nikakvo znanja o tome, o čemu smo pričali ranije, nego prosto gledaju to kao... A kako onda je... Vidi, pošto ovo radimo u malim čankovima, radiš sa petoro, šestoro ljudi. Jer cela ovdje ideja jeste ti... smanjuješ stepen neznanja, sobstvenog neznanja o proizvodu, o oportunitima, o feature-ima koji želiš da radiš. I ti ono što biraš jeste, hoću da testiram ono o čemu najmanje znam, je li tako? Sa svakim pomakom, i zato je sad bitan onaj continue ti sa početka, jer ti sa svakim pomakom ti povećaš stepen znanja o tom problemu ili o tom tvom solutionu. I zato ti je okej u UX istraživanjima što se radi. Ti pričaš sa petoro, šestoro, sedmoro ljudi. I sad, statistički to nije reprezentivan uzrak, ali tako, reprezentivan uzrak na nivou Srbije je hiljadu ljudi. Ali gde je razlika? Razlika je što radiš, kad radiš ovu vrstu validacije, ti u stvari već posle troje ljudi počinješ da hvataš velike streamove, ajde tako kažem, velike važne elemente. I ti vidiš, ali bukvalno se vidi, prvi prođi ti, ne znam, kaži ti sad ono, radio sam skoro sa jednom firmom, Pa smo pravili neki aplikaciju na kojoj korisnik trebali u nekom trenutku klikne na dugme koje kaže, nema pojem, potvrdi nešto, šta godi. I sad skrin izgleda mobilni telefon u pitanju, skrin izgleda tako što kao, jel, skrin mobilnog telefona, na sredini dugme potvrdi nešto. I pre nego što smo uši, ja kažem onako kao više kao to, anegdota, trivia, rekao, pitanje je da li će oni da provale uopšte da ode treba. Ja kao, ne moguće, koliko je dugme na sred ekranu. I ja kao, dobro, okej, aj vidjet ćemo. I sad dolazi prvi korisnik i kao treba da potvrdi tu svoju akciju, i kao sad scrolle gore, dole, gleda navigaciju gore, i znaš li sad ovih u timu, znaš li kao u fazonu, čekaj, u čemu je problem? I kao, pa ne zna, i sad ovaj nesvršnik što ga ispitivo, kao pa dobro, šta mislite, gde sad, ne možda mu kaže klikni na elvič dugme ovde, nego sad kao, pa šta biste vi tu uradili? Pa kao, nemam pojma, ja bi sad da vidim kao u šume, neke sulude onako putanje, kao nešto što čovjek nikad ne bi očekivao. I kao u fazono na kraju dođu neko dođu kao ajde, ok, kliknuo bi ovde na dugmu. I kao super. Drugi, treći, evo peti korisnik i ti vidiš da od nebitnoj njih petoro, šestoro, sedmoro, njih dvoje, troje su imali isti problem. Nisu izvaljivali dugmu. To je, ne zaključiš ti statistički, ne kažeš ti aha, od šestoro ljudi troje mi nije vidjelo dugmu, znači 50% je vidjelo, 50% nije, pa ću ja sad da popravim naću. Ne, ti hvataš šta je to što je... što je korisnicima problem, jel? Uhvatio si da je problem korisnicima. Da li je to za 50% korisnika ili za 30% nije ti mnogo značeno, to je nešto što zaslužuje da obratiš pažnju to i da ga rešiš na neki način. Ko ću još, kažem, nekad stvari koje nama izgledaju očigledne, krajnji korisnicima nisu. Zašto? Zato što to nije njihov svet, nije njihov život. On je tu sad izmešten, nešto treba da uradi. Mene podsjećaju ovi razno razne što nude telekom i ostale usluge koje me zovu dva put dnevno već. I koja ne mogu da ime objasnim, ljudi, meni ne treba mi to što nudite. Pa znam ali kao bit će jeftinije, ali ne treba mi kao, znaš, kao prosto, kao ne želim, ono kao ne želim novi mobilni telefon, pa makar bio i za dinar, kao ne treba mi. E to im nekako teško ide u glavu, da me maše sa ponudom svoj. Par nekih prototipova, ne znam da li ih prepoznajete. Znate šta je ovo? Da, računar, ustvari laptop. Ovo je prvi miš, to je prototip miša. Ovo su one Google naočere koje su bile priče o tome kako prototip treba da izgleda ružno. I na kraju, sve ovo treba upakovati sad da se ovo stalno dešava. Ovo nije sad, sad sam je pričao kao linearno, sve smo prošli jednom, ali ovo je u stvari nešto što treba da se vrti u krug, kao konstantno ideš. Neću sad pretredno zadržavati ovdje da bismo prešli na praktični rad, a ovo nam i nije svakako neophodno za praktični rad. ali u suštini imaš stvari koje se dešavaju u manjim loopovima, u većim i u najvećim. Je li tako? Definisanje outcome je najveći loop. Nećeš ga definisati svaki put kad te pričaš s korisnicima. Gledaš da ti outcome drži neko vreme, ok, možeš da ga svičuješ, ali ono, stalnostka kutanje sa jednog na drugi outcome nije dobra praksa. Ima probleme. I tako smo došli do današnjeg zadatka. Može ga, apsolutno. Da, to je dobro pitanje i ja bih... Na sreću ovih što su glasali da imamo ručak između, završio ovdje, toliko samo ćemo ispričamo šta je zadatak, a onda ćemo da se vratimo ovdje da radimo zadatak i da imamo feedback. Tako da jeste čina bila bez pauze, ali morat ćemo da imamo pauzu. Dobro, šta će nam biti zadatak za danas? Zadatak za danas je, mi imamo neki web shop ovdje, možda ga prepoznajete u pozadini, tu čisto inspiracija radi. gdje imamo neke ciljeve, neke probleme koje želimo da postignemo. Kroz intervjue smo prikupili gomilo nekih opportunity-a i sad treba nešto sa njima da uradimo. Znači moramo da organizujemo ove opportunity koje imamo u formu ovog stabla, da isprioritizujemo šta je to što prvo želimo, naravno imajući u vidu cilj koji želimo postignemo, Dođemo do toga, to nam je fokus, kao neki ono, stretch bi bio da dođemo i do nekih da predložimo neke solušene za neke od opportunity-a i eventualno razmislimo malo o tome kako bismo testirali te solušene. Posle toga prezentujete, svaka grupa će da prezentuje to šta je uradila, mi ostali gledamo i komentarično malo, ali se nama čini da je to dobro napravljena struktura, jesu to zaista sestre opportunity-e ili nisu, da li se negde solušen umuvo gdje nije trebalo i tako dalje. Dobijete feedback kroz to.

⚙️ Pipeline jobs

StageStatusAtt.UpdatedError
download done 1/3 2026-07-20 14:35:05
transcribe done 1/3 2026-07-20 14:35:35
summarize done 1/3 2026-07-20 14:36:02
embed done 1/3 2026-07-20 14:36:03

📄 Описание YouTube

Показать
Have you already heard of Continuous Discovery and Opportunity Solution Tree 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.

Here, you will learn about the Continuous discovery and Opportunity Solution Tree. You will have the opportunity to try the framework on a real-life example. Lastly, the workshop will provide you a tool that you can continue using in your everyday life.