Product Discovery je inicijalna faza razvoja proizvoda koja nam omogu\u0107ava da otkrijemo problem koji treba da re\u0161imo za na\u0161e korisnike i kako da ga re\u0161imo.<\/p>\n\n\n\n
Gledaju\u0107i kroz istoriju Produkt Menad\u017ementa, ova faza je u fokusu tek u zadnjih desetak godina.<\/p>\n\n\n\n
Ako pogledamo Produkt Menad\u017ement pre 2001., pre nego \u0161to je napisan Agilni manifesto, nije mnogo ura\u0111eno u sferi otkrivanja proizvoda ili bilo kakvom istra\u017eivanju i eksperimentisanju.<\/p>\n\n\n\n
Ideje i biznis slu\u010dajevi su generisano od strane poslovnih \u201cstakeholder\u201d-a. Na osnovu ovih slu\u010dajeva su formirani Roadmap-ovi. Zahtevi za te Roadmap-ove su generisani od strane istih ljudi. Tako su Produkt Menad\u017eeri u tom periodu bili strogo administrativci: sakupljali su, dokumentovali, delili i komunicirali zahteve. Dizajn i pravljenje proizvoda je bilo ra\u0111eno na osnovu tih zahteva. Kad je zavr\u0161en, proizvod se \u0161alje na tr\u017ei\u0161te. Tek kad stigne do radnji i krajnjih korisnika mogli ste da dobijete neku povratnu infomaciju o onome sto ste napravili.<\/p>\n\n\n\n
Ima dosta proizvoda koji su propali kada su ve\u0107 iza\u0161li na tr\u017ei\u0161te. Zamislite koliko bi para i vremena moglo d se u\u0161tedi da su povratne inoformacije od korisnika do\u0161le pre tr\u017ei\u0161nih, mo\u017eda \u010dak i pre nego \u0161to su dizajnirani i napravljeni.<\/p>\n\n\n\n
Sve \u0161to je bilo potrebno je da se odgovori na pitanje \u201cDa li pravimo ne\u0161to \u0161to \u0107e na\u0161e mu\u0161terije \u017eeleti i \u0161to \u0107e im trebati\u201d.<\/p>\n\n\n\n
Ako posmatramo na\u010din na koji je posao organizovan u to vreme, nije postojala mogu\u0107nost da se podr\u017ei rani \u201cFeedback\u201d. Veliki obim posla koji je ra\u0111en u fazama sa \u201cwaterfall\u201d pristupom, ciklusi pravljenja su bili toliko duga\u010dki da dok se stegne mogu\u0107nost da se prikupi povratna informacija, proizvod je ve\u0107 gotov.<\/p>\n\n\n\n
Kada je stigao Agile, otvorio je vrata i kreirao mogu\u0107nost dobijanja ranijih informacija..<\/p>\n\n\n\n
Prema Jeff Sutherland-u, jednom od tvoraca Agile manifesta, kada su smi\u0161ljali manifest i deo o \u201cSaradnja sa korisnicima pre Pregovaranje ugovora\u201d nisu razmi\u0161ljali o krajnjim korisnicima ve\u0107 o njihovim poslovnim \u201cstakeholder\u201d-ima kao njihovim korisnicima.<\/p>\n\n\n\n
Iako nisu uklju\u010dili krajnje korisnike u ovaj proces, uspeli su da pripreme teren za budu\u0107nost otkrivanja prozivoda. Kada su postavili ideju \u201cSoftver koji radi pre Dokumentacije\u201d, podr\u017eali su i kratke cikluse isporuke i prikazivanje isporu\u010denog \u201cstakeholder\u201d-ima. To je bila forma ranih povratnih informacija koje su nedostajale, \u010dak iako je bilo samo od internih koriniska.<\/p>\n\n\n\n
U isto vreme razvojao se jo\u0161 jedan novi trend, Dizajn korisni\u010dkog iskustva (User Experience Design) koji je poku\u0161avao da odgovori na pitanje: \u201cDa li pravimo ne\u0161to \u0161to \u0107e korisnici umeti da koriste\u201d. Design Thinking je bio pristup koji su koristili da ovo istra\u017euju.<\/p>\n\n\n\n
Prava prekretnica je bilo kada su Eric Ries (Lean Startup) i Steve Blank (Customer Development) po\u010deli da istra\u017euju pitanje \u201cDa li pravimo stvar koju na\u0161i korisnici \u017eele\u201d. Pronala\u017eenje najbr\u017eeg i najjeftinijeg na\u010dina da se odgovori na ovo pitanje i validira ideja proizvoda je postao novi standard u otkrivanju proizvoda (Product Discovery) u indutriji vo\u0111enoj tehnologijom.<\/p>\n\n\n\n
Kroy Lean Startup su nam dali dosta razli\u010ditih alata koji su napravljeni da nam pomognu da ogovorimo na \u201cnajskuplja\u201d pitanja \u0161to ranije u procesu kako bi eliminisali prvo najve\u0107e rizike.<\/p>\n\n\n\n
Napredak Product Discovery-a nije stao tu. Novi trendovi se redovno pojavljuju poku\u0161avaju\u0107i da odgovore na nova pitanja tokom otkirvanja proizvoda, prave\u0107i ovaj proces jednostavnijim i direktnijim. Neki od njih su:<\/p>\n\n\n\n
\u201cJobs to be done\u201d – poku\u0161ava da odgovori na pitanje \u201cDa li re\u0161avamo pravi problem za na\u0161e korisnike\u201d<\/p>\n\n\n\n
OKRs (Objectives and Key Results) – fokusiranje na ishode i jednozna\u010dno razumevanje ishod kroz celu kompaniju<\/p>\n\n\n\n
Design Sprint – otkrivanje proizvoda sa \u010dovekom u centru<\/p>\n\n\n\n
Iako vrednost i potreba za otkrivanjem proizvoda postaje jasna u indutriji danas, ima dosta timova koji to jo\u0161 uvek ne koriste.<\/p>\n\n\n\n
Mo\u017eda je to usled pre\u0161iroke palete dotupnih alata za ovaj proces, ljude su preplavljeni in e znaju \u0161ta da koriste i za \u0161ta.<\/p>\n\n\n\n
Pogledajte cilj otkrivanja proizvoda – nau\u010di, tj saznaj \u0161to je br\u017ee mogu\u0107e i \u0161to je ranije u razvoju proizvoda mogu\u0107e \u201cda li je ono \u0161to ho\u0107emo da napravimo prava stvar za napraviti\u201d.<\/p>\n\n\n\n
Sa svakom od gorepomenutih metodologija odgovaramo na razli\u010dito pitanje stakeholde-a i odgovaramo ga \u010dim ranije u procesu:<\/p>\n\n\n\n
Agile<\/strong> – da li ispunjavamo potrebe na\u0161ih stakeholde-ra<\/p>\n\n\n\n User experience design<\/strong> – da li pravimo ono \u0161to na\u0161i korisnici umeju da koriste<\/p>\n\n\n\n Lean Startup<\/strong> – da li korisnici \u017eele na\u0161e re\u0161enje<\/p>\n\n\n\n Job to be done<\/strong> – da li re\u0161avamo problem do kog je korisnicima stalo<\/p>\n\n\n\n OKR<\/strong> – da li svi idemo ka \u017eeljenom ishodu<\/p>\n\n\n\n Izlistana pitanja nisu ne\u0161to \u0161to se odgovori jednom i zavr\u0161eno je. Proces otkrivanja proizvoda mora da bude kontinuiran, bez kraja, ako \u017eeli\u0161 da dr\u017ei\u0161 korak sa svojim korisnicima, sveukupnim tr\u017ei\u0161tem i razli\u010ditim trendovima. Ostati u toku i relevantan u ovim brzo promenjivim vremenima je najizazovniji deo razvoja proizvoda, s toga ne prestaj da otkriva\u0161.<\/p>\n","protected":false},"excerpt":{"rendered":"