Product Owner u savremenom IT poslovanju: između korisnika, razvoja i poslovne strategije

Key Takeaways – šta je najvažnije u ovom tekstu

• Product Owner je prema zvaničnom Scrum Guide-u odgovoran za maksimizovanje vrednosti proizvoda, a ne samo za administrativno vođenje Product Backloga.

• Upravljanje Product Backlogom (Product Backlog Management) predstavlja samo sredstvo. Cilj proizvoda (Product Goal), strateški prioriteti i stvarna vrednost jesu suština.

• Dobar Product Owner ne predstavlja samo „biznis pred programerima“ niti „programere pred biznisom“ – on donosi odluke na samom preseku potreba korisnika, mogućnosti tehnologije i poslovne strategije.

• Korisnička priča (User Story), funkcionalnost (Feature) i formalno zatvoren Sprint nisu poslovna vrednost sami po sebi. Product Owner mora jasno da razlikuje Output, Outcome i Business Impact.

• Product Owner koji samo prepisuje zahteve stejkholdera postaje puki primalac naloga (Order Taker), a ne stvarni vlasnik vrednosti proizvoda.

• Veštačka inteligencija automatizuje veliki deo administrativnog rada Product Ownera, čime strateško razmišljanje, donošenje teških odluka, prioritizacija i preuzimanje odgovornosti postaju još važniji.

• U velikim korporacijama najveći problem često nije nedostatak Product Ownera, već to što ih ima previše – pri čemu niko od njih nema stvarnu moć da donese konačnu odluku o proizvodu.

Zvanični Scrum Guide vrlo jasno definiše Product Ownera kao osobu odgovornu za maksimizovanje vrednosti proizvoda koja nastaje radom Scrum tima. U njegove formalne odgovornosti spadaju razvoj i jasno komuniciranje cilja proizvoda (Product Goal), kreiranje i komunikacija stavki iz Product Backloga, njihovo uređivanje po prioritetu, kao i obezbeđivanje da Backlog bude u potpunosti transparentan, vidljiv i svima razumljiv.

Ipak, upravo na toj tački nastaje jedan od najvećih nesporazuma u savremenom agilnom poslovanju. Organizacije pročitaju termin „Product Backlog“ i automatski zaključe: „Aha, Product Owner je osoba koja održava Jiru.“ To je ekvivalentno tvrdnji da je glavni posao direktora kompanije da uređuje PowerPoint prezentacije samo zato što ih redovno koristi.

Product Owner nije administrator Backloga

Ako Product Owner najveći deo svog radnog dana provodi pišući korisničke priče, popravljajući kriterijume prihvatanja (Acceptance Criteria), sređujući nazive zadataka, pomerajući kartice kroz kolone i jureći programere za statusne informacije, organizaciona postavka je suštinski pogrešna.

Scrum.org i tokom 2026. godine eksplicitno upozorava na opasnost od svođenja ove uloge na tehničku administraciju. U tekstu „The Product Owner Is Far More Strategic Than Most People Realize“ naglašava se da je Product Owner znatno više od nekoga ko dokumentuje korisničke zahteve: on direktno povezuje viziju kompanije (Company Vision) i poslovnu strategiju sa konkretnim razvojnim smerom proizvoda.

Još direktnije, Scrum.org analiza iz septembra 2026. godine „5 Things the Product Owner Shouldn’t Be Doing“ upozorava da Product Owner ne sme da postane kontrolna tačka i usko grlo (Bottleneck) kroz koje mora proći svaka operativna sitnica. Ako svaki obavljeni zadatak zahteva njegovo formalno odobrenje, inženjeri gube autonomiju i lični osećaj odgovornosti za kvalitet rešenja. Product Owner mora da poseduje i vodi pravac i strategiju, a ne svaku pojedinačnu rečenicu u Backlogu.

Product Owner nije Project Manager sa novom titulom

Ovo je verovatno najčešća organizaciona greška u korporativnim agilnim transformacijama: kompanija formalno pređe na Agile, Project Manager preko noći postane Product Owner, dok svi stari KPI parametri ostaju netaknuti – prate se fiksni rokovi, zadati obim (Scope), budžet i ukupan broj isporučenih funkcionalnosti. Promenjena je vizitkarta, ali je operativni model ostao potpuno isti.

Scrum.org u tekstu „Product Owner Is Not… Product Owner Is…“ vrlo precizno pravi razliku:

• Product Owner nije Project Manager, već Value Maximizer – osoba koja maksimizuje ostvarenu vrednost;

• Nije Order Taker (primalac naloga), već Decision Maker – donosilac odluka;

• Nije fokusiran isključivo na isporučeni rad (Output), već na merljive efekte i promenu ponašanja korisnika (Outcome).

Ta razlika je fundamentalna i ogromna.

Project Manager pita: „Da li smo isporučili Scope?“, a Product Owner: „Da li smo rešili problem?“

Posmatrajmo primer uvođenja novog procesa registracije i aktivacije korisnika (onboarding):

• Projektna perspektiva:

  • Svih 14 korisničkih priča je završeno;

  • Nova verzija (Release) je puštena u produkciju 4. septembra;

  • Budžet nije probijen;

  • Projekat je u statusnom izveštaju označen zelenom bojom (Green).

• Produktna perspektiva:

  • Stopa aktivacije (Activation Rate) pre lansiranja iznosila je 48%;

  • Stopa aktivacije nakon lansiranja iznosi 49%.

Drugim rečima: tehnički smo završili skoro sve što smo planirali, ali se poslovno skoro ništa nije dogodilo. Da li je posao uspeo? Product Owner koji razmišlja samo projektno reći će da jeste, jer je plan ispunjen. Product Owner koji razmišlja proizvodno reći će da tim još uvek ne zna zašto je pretpostavka bila pogrešna i zašto problem nije rešen.

Output nije isto što i Outcome

Razumevanje ove razlike predstavlja temelj savremenog vođenja proizvoda:

• Output: Napravljena je i puštena nova funkcionalnost.

• Outcome: Korisnici su zbog te funkcionalnosti promenili svoje navike i ponašanje.

• Business Impact: Ta promena ponašanja proizvela je konkretan i merljiv poslovni rezultat.

Primer:

• Output: Razvijen je novi algoritam za preporuku proizvoda (Recommendation Engine).

• Outcome: Korisnici otvaraju 24% više preporučenih artikala nego ranije.

• Business Impact: Prosečna vrednost potrošačke korpe raste za 7%.

Tek poslednja dva nivoa pokazuju zašto smo nešto uopšte pravili. Na ITNetwork-u smo u tekstu „Merenje uspeha Agile timova: zašto velocity nije dovoljan KPI“ upravo ovu razliku postavili kao centralnu: završeni Story poeni mogu pomoći internom planiranju tima, ali sami po sebi ne govore da li je korisnik dobio bilo šta vrednije. Za Product Ownera je ta razlika egzistencijalna: ako meri samo Output, on tim pretvara u fabriku funkcionalnosti (Feature Factory).

Product Owner mora da zna da kaže „ne“

Sposobnost odbijanja zahteva verovatno je najvažnija praktična veština Product Ownera. Različiti stejkholderi uvek imaju oprečne zahteve:

• Stejkholder A traži novi kontrolni panel (Dashboard);

• Prodaja zahteva novi filter;

• Marketing zahteva Campaign Builder;

• Generalni direktor (CEO) želi AI Chatbot;

• Korisnička podrška zahteva unapređenu pretragu (Search).

Svaka od ovih ideja pojedinačno može zvučati sasvim razumno. Međutim, tim nema beskonačan kapacitet. Ako Product Owner na svaki prispeli zahtev odgovori sa: „Ubacićemo to u Backlog“, Backlog prestaje da bude strategija i pretvara se u magacin neodbijenih zahteva.

Scrum.org je ovu pogrešnu poziciju opisao kao profil službenika (Clerk stance) – Product Owner postaje administrativni posrednik koji prihvata gotovo sve zahteve i samo ih mehanički prosleđuje timu. Nasuprot tome, dobar Product Owner mora biti sposoban da kaže:

• „Ne sada.“

• „Nemamo dokaz da ovo rešava relevantan problem.“

• „Postoji vrednija stvar kojoj moramo dati prednost.“

• „Prvo ćemo kroz brz eksperiment testirati početnu pretpostavku.“

To nije tvrdoglavost, već suština prioritizacije.

Prioritet nije redosled zahteva stejkholdera po hijerarhiji

Kada generalni direktor kaže: „Napravite ovo“, a Backlog automatski dobije novu stavku broj jedan bez ikakve analize, Product Owner nema stvarno vlasništvo nad proizvodom (Product Ownership), već se bavi administrativnim posredovanjem.

Izvršni menadžment određuje krovnu strategiju kompanije i ima ogroman, legitiman uticaj na prioritete. Ipak, Product Owner mora postaviti ključna pitanja:

• Koji tačno problem ovim rešavamo?

• Za koga ga rešavamo?

• Kolika je očekivana vrednost ove promene?

• Koji je oportunitetni trošak (Opportunity Cost) – šta tačno zbog ovoga nećemo uraditi?

• Kako ćemo precizno meriti rezultat?

Ukoliko se postavljanje ovakvih pitanja u kompaniji smatra „neposlušnošću“, problem se ne nalazi u Product Owneru, već u celokupnom operativnom modelu preduzeća (Operating Model).

Product Goal je mnogo važniji od savršenog Backloga

Zvanični Scrum Guide definiše cilj proizvoda (Product Goal) kao buduće stanje proizvoda koje Scrum timu služi kao cilj prema kojem planira rad. To je ključna stvar.

Product Goal odgovara na pitanje: „Gde pokušavamo da stignemo?“, dok Backlog odgovara na pitanje: „Koji posao u ovom trenutku mislimo da će nas tamo dovesti?“ Sadržaj Backloga mora biti podložan stalnim promenama. Ako ga ne smemo menjati na osnovu novih saznanja, onda nemamo Backlog, već unapred zaključan projektni plan (Project Plan). Scrum Guide zato Backlog tretira kao evolutivan i promenljiv (emergent), a Product Goal kao stabilan, dugoročniji fokus tima.

Dobar Product Owner štiti tim od haotične prioritizacije

Tim koji svakog jutra dobija novi „prioritet broj jedan“ zapravo uopšte nema prioritete – on trpi stalne prekide u radu. Product Owner mora biti strateški filter koji ne blokira protok informacija, ali štiti inženjerski fokus.

To ne znači izolovati programere od korisnika i stejkholdera. Naprotiv, inženjeri treba da imaju što direktniji kontakt sa korisnicima, podacima i stvarnim problemima. Scrum.org eksplicitno upozorava na anti-obrazac u kome Product Owner postaje golub pismonoša (carrier pigeon / The Story Writer) između stejkholdera i tima. Kada sve informacije prolaze isključivo kroz jednu osobu, tim gubi domensko znanje i autonomiju. Product Owner ne treba da bude neprobojan zid, već pouzdan orijentir.

Product Owner između korisnika i poslovanja

Korisnik često dolazi sa gotovim zahtevom: „Treba mi mogućnost izvoza svega u Excel.“ Da li automatski treba isprogramirati Export to Excel? Možda. A možda pravi problem zapravo glasi: „Ne mogu da donesem odluku unutar vašeg sistema, pa moram da izvezem podatke negde drugde.“

To su dve veoma različite stvari:

• Slab Product Owner samo mehanički zapisuje: Feature Request: Export to Excel.

• Dobar Product Owner pita: Zašto? Šta korisnik pokušava da uradi? Šta danas ne može da postigne? Koliko često se javlja ta potreba i kako taj problem utiče na njegov svakodnevni posao?

Tek tada tražimo pravo rešenje. Možda to zaista jeste Excel, a možda je potpuno drugačije sistemsko unapređenje.

Customer Request nije isto što i Customer Need

Henriju Fordu se često pripisuje rečenica da bi ljudi, da ih je pitao šta žele, zatražili samo brže konje. Bez obzira na istorijsku autentičnost tog citata, princip u razvoju proizvoda je izuzetno koristan: korisnik je dragocen izvor informacija o sopstvenom problemu, ali je znatno manje pouzdan kao jedini izvor za definisanje tehničkog rešenja.

Istraživanje korisnika (Customer Research) služi tome da se otkriju stvarni bol, kontekst rada, ponašanje i motivacija. Nakon toga produktni tim osmišljava najbolje rešenje. Ako Product Owner samo realizuje pojedinačne zahteve (Feature Requests), istraživanje potreba (Customer Discovery) se praktično pretvara u obično glasanje o funkcionalnostima.

Šta ako korisnik traži nešto što se ne uklapa u poslovnu strategiju?

Tada na scenu stupa druga strana posla Product Ownera. Digitalni proizvod nije dobrotvorni servis za ispunjavanje svake pojedinačne želje sa tržišta. Kompanija ima svoju strategiju, pozicioniranje, operativne troškove, zahteve profitabilnosti i rizike. Korisnička vrednost i poslovna vrednost moraju se sresti.

Ako jedan veliki korporativni (Enterprise) klijent traži funkciju koja bi razvojnom timu uzela šest meseci rada, pitanje ne sme ostati samo na tome da li njemu to treba. Neophodno je proceniti:

• Koliki prihod taj zahtev donosi?

• Da li to rešenje koristi i drugim korisnicima ili stvara izolovan sistem?

• Da li nas takav razvoj vodi prema strategiji ili nas udaljava od nje?

• Koliki je dugoročni trošak održavanja (maintenance cost)?

• Šta sve nećemo napraviti tokom tih šest meseci rada?

To je stvarna odgovornost upravljanja proizvodom.

Product Owner između razvoja i poslovne strategije

Sa druge strane pregovaračkog stola sedi inženjerski tim (Engineering) i kaže: „Ovo nije jednostavno.“ Poslovna strana najčešće vidi samo jedno dugme na ekranu, dok inženjeri vide integraciju novog API-ja, migraciju miliona zapisa u bazi podataka, bezbednosne provere (Security), nadzor performansi sistema (observability), kompatibilnost sa starijim verzijama (Backward Compatibility) i pisanje automatizovanih testova.

Dobar Product Owner ne mora nužno biti najbolji programer u timu, ali mora posedovati dovoljno tehničke pismenosti da razume kompromise (trade-off), rizike, tehnički dug i ograničenja postojeće arhitekture. Inače će prioritizovati samo ono što je vidljivo korisniku na interfejsu, dok će se proizvod ispod površine postepeno raspadati.

Product Owner koji ignoriše tehnički dug zapravo ignoriše poslovni rizik

Uobičajen argument glasi: „Krajnji korisnik ne vidi refaktorisanje koda (Refactoring).“ To je tačno, ali korisnik i te kako vidi posledice kada svaki novi Feature počne da kasni, sistem pada pod opterećenjem, broj bagova nekontrolisano raste, a promena koja je ranije trajala dva dana odjednom počne da zahteva dve nedelje rada.

Na ITNetwork-u smo u tekstu o tehničkom dugu već pokazali da Technical Debt postaje ozbiljan poslovni problem onog trenutka kada povećava cenu i vreme svake buduće promene. Product Owner zato mora razumeti da Backlog ne čine samo nove funkcionalnosti. Postoje i:

• Otklanjanje defekata (Defects);

• Upravljanje bezbednosnim i sistemskim rizicima (Risk);

• Smanjenje tehničkog duga (Technical Debt);

• Regulatorna usklađenost (Compliance);

• Arhitektonska unapređenja (Architecture).

Ukoliko 100% inženjerskog kapaciteta stalno odlazi isključivo na nove funkcionalnosti, prividna brzina razvoja predstavlja samo kredit koji ćemo kasnije izuzetno skupo vraćati.

Product Owner ne određuje kako programeri treba da rade

Ovo je izuzetno važna granica odgovornosti. Product Owner određuje šta donosi najveću vrednost, iz kojih razloga i koji cilj proizvoda (Product Goal) jurimo. Programeri (Developers) samostalno određuju kako će to tehnički izvesti.

Zvanični Scrum Guide jasno postavlja Scrum tim kao samoupravljajući kolektiv (self-managing): tim interno i samostalno odlučuje ko radi šta, kada i na koji način. Ako Product Owner počne da govori: „Marko radi API, Jelena frontend, moraćete da koristite ovu biblioteku i sve mora biti završeno do četvrtka“, više ne govorimo o upravljanju proizvodom, već ulazimo u klasičan operativni mikromenadžment zadataka (Task Management).

Programeri takođe ne određuju sami poslovni prioritet

Autonomija tima ne podrazumeva anarhiju. Inženjerski tim možda želi kompletno prepisivanje sistema iz temelja (Rewrite), dok Product Owner želi plasiranje nove funkcionalnosti na tržište. Obe strane mogu imati potpuno racionalne argumente.

Zato je neophodno otvoreno razgovarati o:

• Stvorenoj vrednosti;

• Preuzetom riziku;

• Trošku odlaganja posla (Cost of Delay);

• Dugoročnoj stabilnosti toka rada (Flow).

Kvalitetan Product Owner nikada ne nastupa sa rigidnim stavom da je biznis a priori važniji, ali isto tako ne prepušta sve rečima da tehnologija zna najbolje. Njegov zadatak je pronalaženje optimalnog kompromisa za održiv razvoj proizvoda.

Product Owner mora da razume tok (Flow), a ne samo Backlog

Zamislimo da je prioritet savršeno postavljen i da je funkcionalnost A označena kao najvažnija. Međutim, rad na njoj prolazi kroz niz odvojenih faza: specifikacija → razvoj → testiranje → bezbednosna provera → puštanje u rad. Usled čekanja na odobrenja, cela stavka provede 25 dana na čekanju.

Product Owner koji posmatra samo Jiru može pomisliti da mu je posao završen onog trenutka kada je priča raspisana. Nije. Ako organizacija sporo pretvara odluke u stvarnu korist za korisnika, Product Owner mora razumeti gde se tok raspada.

Na ITNetwork-u smo u tekstu „Value Stream Management: od Agile taskova do merljive poslovne vrednosti“ upravo pokazali zašto lokalna brzina pojedinačnog tima ne znači brzinu celog toka vrednosti. Product Owner ne mora biti ekspert za upravljanje tokovima vrednosti, ali mora razumeti da prva pozicija u Backlogu nema nikakvu realnu vrednost ako šest nedelja ne može da stigne do korisnika.

U velikoj kompaniji Product Owner lako postane samo još jedan administrativni nivo

U velikim korporacijama struktura često dobije previše nivoa: Team PO, Area PO, Lead PO, Chief PO, Product Manager, Program Manager, Portfolio Manager, Business Owner. Kada postavite pitanje ko zaista odlučuje, najčešći odgovor glasi: „Zavisi.“

To je problem. Na ITNetwork-u smo u tekstu „Agile at Scale: izazovi primene agilnih metoda u velikim IT organizacijama“ već analizirali ovu situaciju: ako svaki nivo samo filtrira i prenosi prioritete sledećem, organizacija nije dobila Product Management, već je samo stvorila skuplji lanac posrednika.

Scrum Guide je po ovom pitanju prilično radikalan: čak i kada na jednom složenom proizvodu radi više različitih Scrum timova, oni dele isti Product Goal, isti Product Backlog i jednog zajedničkog Product Ownera.

Product Owner je jedna osoba, ne odbor

Scrum okvir je namerno dizajniran tako da postoji jasna lična odgovornost (Accountability). Zašto? Zato što kompleksan digitalni proizvod zahteva brze i jasne odluke. Ako prioritet mora da odobri komisija od 14 članova, odluka neće biti ni brza ni jasna.

Naravno, Product Owner mora redovno razgovarati sa prodajom, marketingom, finansijama, pravnom službom, timom za bezbednost, inženjerima i korisnicima. Međutim, konsultovanje nije isto što i distribuirana, razvodnjena odgovornost. Ako u organizaciji niko na kraju ne zna ko ima mandat da preseče i kaže „radimo A, a ne radimo B“, preduzeće nema Product Ownership, već problem sa korporativnim upravljanjem (Governance).

Product Owner bez stvarnog ovlašćenja je Proxy Product Owner

Ovo je verovatno najčešći korporativni model: zaposleni formalno nosi titulu i „poseduje“ Backlog, ali u stvarnosti ne sme samostalno da promeni mapu razvoja (Roadmap), odbije zahtev direktora, odluči o datumu puštanja verzije (Release), utiče na budžet ili redefiniše cilj proizvoda.

Šta onda takva osoba poseduje? Poseduje samo ekran u Jiri. Scrum.org godinama upozorava na ovaj problem: organizacije često preimenuju poslovne analitičare ili projektne menadžere u Product Ownere, uskraćujući im pritom stvarno ovlašćenje da odlučuju o vrednosti, prioritetima i tržišnoj validaciji. Ako organizacija sistematski ignoriše ili poništava odluke svog Product Ownera, njegova funkcija je čisto dekorativna.

Product Owner i Product Manager – gde je granica?

Ovo je pitanje bez jednog univerzalnog odgovora u industriji. Scrum definiše odgovornost Product Ownera unutar tima, ali ne definiše poziciju Product Managera u kompanijskoj šemi.

U manjim i srednjim organizacijama jedna osoba najčešće obavlja obe funkcije. U većim sistemima uloge se ponekad dele: Product Manager se primarno bavi istraživanjem tržišta, širim pozicioniranjem, cenovnom politikom i strategijom plasiranja na tržište (Go-to-Market), dok Product Owner radi neposredno sa inženjerskim timom na realizaciji ciljeva.

To može funkcionisati u praksi, ali nosi ozbiljnu opasnost: ako Product Manager postane jedini „pravi vlasnik“, a Product Owner bude sveden na osobu koja samo pasivno razlaže tuđe planove na korisničke priče, PO ponovo postaje proxy posrednik. Najvažnije pitanje nikada nije naziv pozicije na LinkedIn profilu, već ko je u organizaciji zaista odgovoran za vrednost proizvoda i ima ovlašćenje da menja prioritete.

Savremeni Product Owner mora mnogo više da razume Product Discovery

Tradicionalni Product Owner najčešće dobije gotove zahteve sa vrha. Savremeni PO mora aktivno raditi na istraživanju problema (Problem Discovery), intervjuima sa korisnicima, analitici ponašanja u proizvodu, postavljanju hipoteza i brzim eksperimentima.

Pre nego što inženjerski tim uđe u tromesečno programiranje složenog modula, ključno pitanje glasi: možemo li osnovnu pretpostavku proveriti za tri dana kroz jednostavan prototip? To je jedan od najvećih pomaka u modernom razvoju softvera. Product Owner više ne upravlja samo time šta gradimo, već mora biti duboko uključen u razumevanje zašto verujemo da to uopšte vredi graditi.

Hipoteza je zdravija od zahteva

Posmatrajmo razliku u formulaciji:

• Forma zahteva: „Napraviti AI asistenta u sistemu.“

• Forma hipoteze: „Verujemo da će AI asistent smanjiti prosečno vreme rešavanja korisničkog problema sa osam na pet minuta.“

Kada zadatak postavimo kao hipotezu, odmah imamo definisan problem, pretpostavljeno rešenje i merljivi ishod (Outcome). Tada možemo pristupiti testiranju. Ako nakon puštanja u rad prosečno vreme i dalje ostane osam minuta, nije dovoljno reći: „Ali AI funkcionalnost je uspešno isporučena.“ Product Owner mora otvoreno konstatovati da hipoteza nije potvrđena. To je psihološki znatno teže, ali je poslovno višestruko korisnije.

Dobar Product Owner se ne zaljubljuje u Feature

Razvojni tim provede tri meseca na izradi nove opcije. Funkcionalnost izađe u produkciju, a nivo korišćenja (Adoption) iznosi svega 4%. Šta radimo u toj situaciji?

Najlakši, ali ujedno i najlošiji izgovor glasi: „Marketing mora bolje da ga promoviše.“ To jeste moguće, ali je znatno verovatnije da korisniku ta opcija jednostavno nije dovoljno vredna. Product Owner mora imati profesionalnu i intelektualnu disciplinu da prizna grešku u proceni, a zatim donese odluku o izmeni, pojednostavljenju ili trajnom gašenju tog koda. Prethodno uloženi novac i vreme ne smeju postati strategija proizvoda (Sunk Cost Fallacy).

Product Owner i podaci: analitika nije dodatak

Savremeni Product Owner ne može se oslanjati samo na mišljenja stejkholdera. Neophodni su mu egzaktni podaci:

• Analitika proizvoda (Product Analytics);

• Podaci o korišćenju (Usage);

• Levak napuštanja procesa (Funnel);

• Zadržavanje korisnika (Retention);

• Odliv korisnika (Churn);

• Izveštaji korisničke podrške;

• Kvalitativne povratne informacije (Qualitative Feedback).

Međutim, ni sami brojevi nisu apsolutna istina. Ako podaci pokažu da 80% korisnika ne koristi novu opciju, procenat sam po sebi ne nudi odgovor zašto je to tako. Možda korisnici ne mogu da pronađu dugme u interfejsu, možda im opcija ne treba, a možda je koriste samo jednom mesečno prilikom obračuna. Zato se kvantitativni podaci uvek moraju kombinovati sa direktnim istraživanjem korisnika. Broj pokazuje šta se dešava, dok razgovor objašnjava zašto.

Product Owner mora razumeti ekonomiju proizvoda

Poslovna vrednost se ne svodi samo na konstataciju da je korisnik srećan. Proizvod mora biti finansijski održiv i profitabilan. Product Owner ne mora biti finansijski direktor (CFO), ali mora razumeti osnovne ekonomske pokazatelje:

• Prihode (Revenue);

• Operativne i fiksne troškove (Cost);

• Profitne marže (Margin);

• Trošak akvizicije korisnika (Customer Acquisition Cost – CAC);

• Životnu vrednost korisnika (Lifetime Value – LTV);

• Trošak pružanja usluge (Cost to Serve);

• Stope zadržavanja i odliva.

Ukoliko Product Owner ne razume ekonomski model na kome proizvod počiva, postavlja se pitanje kako uopšte može da donosi odluke o maksimizovanju vrednosti.

Prioritizacija nije formula

Okviri za prioritizaciju kao što su RICE, MoSCoW, WSJF ili matrice vrednosti naspram napora (Value vs Effort) mogu biti korisni alati, ali nijedna tabela ne može doneti odluku umesto Product Ownera.

Zamislimo rezultat: RICE Score = 842. To na papiru deluje matematički precizno. Međutim, procena dosega (Reach) je gruba pretpostavka, procena uticaja (Impact) je pretpostavka, procena pouzdanosti (Confidence) je subjektivna, a procena potrebnog inženjerskog napora (Effort) takođe je procena. Pomnožili smo četiri neizvesnosti i dobili trocifren broj sa prividom egzaktnosti. Takvi modeli služe za strukturiranje kvalitetnog razgovora, a ne kao izgovor za bežanje od lične odgovornosti za odluku.

Hitno nije isto što i vredno

Kada stejkholder uđe na sastanak sa zahtevom: „Ovo je hitno, klijent čeka!“, Product Owner mora utvrditi činjenice:

• Koliko tačno klijenata ima taj problem? Samo jedan.

• Kolika je realna ekonomska vrednost te promene? Ne znamo.

• Koliki je oportunitetni trošak i trošak odlaganja (Cost of Delay) strateških poslova koje ćemo prekinuti zbog ovog zahteva? Ne znamo.

Product Owner mora praviti jasnu razliku između zahteva koji su samo glasno izrečeni i onih koji su zaista važni. Organizacije bez stabilnog produktnog vođstva često imaju mapu razvoja koja zapravo predstavlja spisak želja najglasnijih ljudi u kompaniji.

Product Owner i poslovna strategija: proizvod ne postoji u vakuumu

Ako kompanijska strategija nalaže ulazak u segment velikih korporativnih klijenata (Enterprise), cilj proizvoda ne može potpuno nezavisno ostati fokusiran na optimizaciju besplatnih naloga za pojedince.

Strategija se mora spuštati kroz jasan lanac:

Cilj kompanije (Company Goal) → Strategija proizvoda (Product Strategy) → Cilj proizvoda (Product Goal) → Product Backlog.

To ne znači slepo izvršavanje naloga tipa „Direktor je rekao da napravimo opciju X“. Strategija definiše problem, ciljnu grupu i smer, dok produktni tim pronalazi najbolje rešenje. Scrum.org tokom 2026. godine dodatno naglašava stratešku prirodu ove uloge: vizija i cilj proizvoda moraju funkcionisati kao most između šire poslovne strategije i svakodnevnog rada inženjera.

Product Owner nije vlasnik svega

Naziv „Owner“ u praksi može zavarati. Product Owner nije linijski menadžer ljudi, nije tehnički direktor (Engineering Manager), nije Scrum Master, nije vodeći dizajner (UX Lead), niti je direktor kompanije. On ne donosi svaku odluku samostalno.

Scrum tim kao celina nosi odgovornost za stvaranje vrednog i upotrebljivog priraštaja (Increment) na kraju svakog ciklusa, dok programeri imaju punu odgovornost za tehnički kvalitet i način izvođenja koda. Dobar Product Owner mora tačno znati šta zadržava pod svojom kontrolom, a šta delegira članovima tima. To nije gubitak autoriteta, već osnovni preduslov za skaliranje rada.

Product Owner koji odobrava svaku sitnicu postaje usko grlo

Ukoliko inženjerski tim za svaku operativnu sitnicu mora da traži odobrenje od Product Ownera:

• „Možemo li promeniti boju ovog dugmeta?“

• „Možemo li ispraviti ovaj tekst poruke?“

• „Možemo li refaktorisati ovu klasu u kodu?“

organizacija je stvorila rigidnu, centralizovanu tačku odlučivanja koja guši produktivnost.

Smernice Scrum.org-a iz 2026. godine direktno upozoravaju da Product Owner ne sme postati lektor tekstova, kontrolor svakog testa ili jedina osoba koja ima pravo da unosi zadatke u Backlog. Product Owner mora čuvati svoje vreme za strategiju, razgovore sa korisnicima, prioritizaciju, cilj proizvoda i merenje ostvarenih ishoda.

AI će prvo pogoditi administrativni deo Product Ownership-a

Ovo predstavlja najvažniju promenu u industriji. Savremeni alati veštačke inteligencije već danas sa visokom efikasnošću mogu da:

• Sažimaju beleške iz intervjua sa korisnicima;

• Analiziraju i kategorišu hiljade tiketa podrške;

• Predlažu strukturu korisničkih priča;

• Definišu kriterijume prihvatanja (Acceptance Criteria);

• Grupišu povratne informacije korisnika;

• Analiziraju funkcionalnosti konkurentskih servisa;

• Pišu radne verzije mapa razvoja;

• Predlažu raspored prioriteta na osnovu zadatih parametara.

Scrum.org je pokrenuo zvaničnu obuku „Professional Scrum Product Owner – AI Essentials“ upravo zato što veštačka inteligencija postaje sastavni deo svakodnevnog rada na otkrivanju, definisanju i isporuci proizvoda. Posledica ove promene je jasna: ako se nečiji posao do sada svodio isključivo na pisanje kartica i administrativno slaganje Backloga, veštačka inteligencija mu predstavlja direktnu i ozbiljnu konkurenciju.

AI neće zameniti dobrog Product Ownera, već će ogoliti lošu definiciju uloge

Scrum.org u analizama iz 2026. godine otvoreno ukazuje na promene na tržištu rada: prostor za administrativne PO pozicije ubrzano nestaje, dok istovremeno rastu zahtevi prema stručnjacima koji suvereno spajaju strategiju, tehničko razumevanje, analitiku i donošenje teških odluka.

U analizi „AI and the Product Owner’s Accountability“ iz oktobra 2026. navodi se provokativan primer iz prakse: napredni AI sistem je u stanju da preko vikenda obradi sve tikete podrške, analizira transkripte prodajnih razgovora, uporedi poteze konkurencije, reorganizuje celokupan Product Backlog i predloži novi Product Goal.

Šta u takvim okolnostima preostaje Product Owneru? Njegov zadatak sigurno nije da pokuša da kuca zadatke brže od algoritma. Njegova stvarna vrednost leži u:

• Preuzimanju lične odgovornosti za odluke;

• Rešavanju teških kompromisa u uslovima neizvesnosti;

• Dubokom razumevanju ljudskog i organizacionog konteksta;

• Vođenju strategije i etičkom rasuđivanju;

• Proceni dugoročnih posledica poslovnih izbora.

AI može da preporuči prioritet, ali ne može da preuzme organizacionu odgovornost

Sistem veštačke inteligencije može na osnovu obrade podataka predložiti da funkcionalnost A ima najveći poslovni potencijal. Međutim, algoritam ne može znati:

• Da li u prikupljenim podacima postoji statistička pristrasnost (Bias)?

• Šta ako ta funkcionalnost donosi veći kratkoročni prihod, ali stvara ogroman regulatorni rizik?

• Šta ako korisnici traže nešto što se direktno kosi sa dugoročnom strategijom brenda?

• Šta ako optimizujemo trenutnu angažovanost na štetu dugoročnog poverenja korisnika?

To su strateške odluke o proizvodu. Tehnologija može pružiti analitičku podršku, ali čovek mora snositi finansijske, operativne i moralne posledice donetih odluka.

Autonomni AI agenti menjaju definiciju korisnika

Proizvode više ne koriste isključivo ljudi. Autonomni softverski agenti (Agentic AI) preuzimaju ulogu korisnika sistema: oni postaju kupci koji komuniciraju preko API servisa, izvršavaju procese i samostalno biraju proizvode umesto ljudi.

Scrum.org tokom 2026. godine otvara pitanje prilagođavanja proizvoda ne-ljudskim korisnicima. U sistemima elektronske trgovine ili rezervacija, čovek više ne pretražuje ponude ručno – umesto njega softverski agent poredi opcije, proverava uslove i realizuje transakciju. Proizvod modernog doba mora biti funkcionalan i privlačan na dva fronta: za ljudsko oko i za mašinski interfejs. Product Owner mora razumeti oba korisnička toka (Customer Journey).

Zamka uvođenja posebnih „AI Product Owner“ uloga

Uvođenje posebne pozicije pod nazivom „AI Product Owner“ može u početku delovati privlačno organizacijama koje žele ubrzanu primenu novih tehnologija. Ipak, Scrum.org upozorava na paradoks: centralizovani AI Product Owner lako postaje nova tačka zavisnosti koja usporava timove i oduzima im autonomiju u odlučivanju.

Upravljanje primenom veštačke inteligencije (AI Capability Governance) mora postojati na nivou kompanije, ali ne treba stvarati novu birokratsku kapiju kroz koju svaki produktni tim mora da prolazi kako bi uneo izmenu.

Kritičko preispitivanje rezultata veštačke inteligencije

Jedna od ključnih kompetencija savremenog Product Ownera postaje prepoznavanje situacija u kojima modelima ne treba verovati na reč. Sistemi veštačke inteligencije mogu:

• Generisati netačne tvrdnje (halucinacije);

• Pogrešno klasifikovati kontekst u komentarima korisnika;

• Dati preveliki značaj najglasnijoj grupi posetilaca;

• Potpuno prevideti manjinski, ali strateški najvažniji segment kupaca;

• Izvući statističku korelaciju i lažno je predstaviti kao uzročno-posledičnu vezu.

Zato profesionalac ne pita samo šta je model predložio, već na kojim je tačno podacima i pretpostavkama taj predlog zasnovan.

Razumevanje poslovnog procesa u digitalnoj transformaciji

Na ITNetwork-u smo u tekstu „Digitalizacija nije kupovina softvera: kako promeniti proces, a ne samo alat“ Product Ownera pozicionirali kao osobu koja usklađuje funkcionalnosti i stvarne potrebe korisnika u širem sistemu gde IT pokriva integracije, arhitekturu i bezbednost, dok ključni korisnici daju povratne informacije iz realnog rada.

Nije dovoljno poznavati samo rad u određenim softverskim programima. Product Owner mora dubinski razumeti realan poslovni proces koji taj softver treba da automatizuje, pojednostavi ili unapredi.

Pouka iz prakse agencije Joombooz: automatizacija bez vlasništva nad proizvodom stvara brži haos

Ista logika važi i van klasičnog softverskog inženjeringa, što se jasno vidi na primerima automatizacije poslovnih procesa koje agencija Joombooz realizuje primenom API integracija, veštačke inteligencije i platformi poput n8n, Make i Zapier.

Ukoliko se automatizuje pogrešno postavljen proces sa nejasnim odgovornostima i lošim prioritetima, jedini rezultat biće pogrešan proces koji sada pravi greške znatno brže nego ranije. Zato je i u internoj automatizaciji neophodan princip vlasništva nad proizvodom:

• Ko je stvarni korisnik ovog toka rada?

• Šta tačno želimo da optimizujemo?

• Koji merljiv ishod (Outcome) očekujemo nakon automatizacije?

• Koje parametre pratimo i merimo?

• Ko donosi odluku o izmeni toka kada se poslovne okolnosti promene?

Suština ostaje identična, bez obzira na to da li razvijate komercijalni softver za tržište ili automatizujete interne operacije preduzeća.

Kako zaista izgleda radni dan dobrog Product Ownera?

Efikasno raspoređen radni dan ne izgleda ovako:

• 08:00 Jira;

• 09:00 Jira;

• 10:00 Daily sastanak;

• 11:00 Pisanje korisničkih priča;

• 12:00 Jira.

Realna, strateški zrela struktura radnog vremena obuhvata:

• Razgovore sa stvarnim korisnicima i kupcima;

• Analizu analitike i podataka o ponašanju u proizvodu;

• Tehničke konsultacije sa inženjerima o mogućim kompromisima i arhitekturi;

• Usklađivanje prioriteta sa prodajnim i marketinškim timovima;

• Istraživanje problema i testiranje novih ideja (Product Discovery);

• Preispitivanje i doradu strateškog cilja proizvoda (Product Goal);

• Određivanje prioriteta za naredni period;

• Analizu rezultata prethodno lansiranih eksperimenata;

• Zajednički rad sa inženjerima na pojašnjavanju stavki Backloga (Backlog Refinement).

Backlog je prisutan, ali on predstavlja prirodnu posledicu strateškog promišljanja, a ne svrhu postojanja same uloge.

Najvažniji alati nisu Jira i Confluence

Glavni alati uspešnog Product Ownera nisu programi za vođenje projekata, već:

• Postavljanje pravih pitanja;

• Rad sa pouzdanim podacima;

• Postavljanje proverljivih hipoteza;

• Definisanje prioriteta;

• Donošenje odluka i preuzimanje odgovornosti.

Softverski alati služe samo kao evidencija rada. Upravljanje proizvodom se dešava pre nego što se kartica u sistemu uopšte kreira (provera da li to uopšte vredi raditi) i nakon što se kartica zatvori (merenje da li je rešenje proizvelo stvarnu vrednost). Sve između toga predstavlja fazu tehničke isporuke (Delivery).

Merenje uspešnosti rada Product Ownera

Uspešnost Product Ownera nikada se ne meri brojem napisanih korisničkih priča, obimom stavki u Backlogu niti brojem odrađenih Sprintova. Zreo set pokazatelja obuhvata:

• Korisnički ishodi (Product Outcome):

  • Stopa usvajanja novih opcija (Adoption);

  • Procenat uspešne aktivacije korisnika (Activation);

  • Zadržavanje korisnika (Retention);

  • Uspešnost završetka ključnih radnji (Task Success).

• Poslovni ishodi (Business Outcome):

  • Rast prihoda i profitnih marži;

  • Smanjenje troškova pružanja usluge;

  • Smanjenje stope napuštanja usluge (Churn).

• Efikasnost toka (Flow):

  • Vreme od ideje do ostvarenja prve vrednosti (Idea-to-Value Time);

  • Ukupno vreme isporuke (Lead Time);

  • Količina paralelnog rada u toku (Work in Progress – WIP).

• Kvalitet rešenja (Quality):

  • Broj kritičnih incidenata i defekata u produkciji;

  • Stabilnost rada sistema;

  • Udeo neplaniranog rada i dorada (Rework).

• Brzina učenja (Learning):

  • Vreme potrebno za potvrdu ili odbacivanje hipoteze (Time to Learning);

  • Broj ključnih pretpostavki testiranih pre ulaska u skupe faze programiranja.

Product Owner se ocenjuje prema sposobnosti proizvoda da stvara održivu vrednost, a ne prema količini sprovedene administracije.

Zašto je oslanjanje na samo jedan KPI opasno?

Ukoliko se pred Product Ownera postavi samo jedan izolovan zahtev, poput „Povećaj prihod“, on može početi da forsira agresivne prodajne poruke, manipulativne obrasce u dizajnu (Dark Patterns) i otežano otkazivanje pretplate. Prihod će kratkoročno porasti, ali će stopa zadržavanja naglo pasti, a poverenje korisnika biti trajno uništeno.

Isto važi za nalog „Povećaj angažovanost korisnika (Engagement)“. Zato se uz primarni ishod uvek moraju postaviti zaštitne metrike (Guardrail Metrics). Na primer: povećati stopu konverzije, ali pod uslovom da stopa povraćaja novca ne poraste, a da ocena zadovoljstva korisnika ostane stabilna. To odlikuje zreliji menadžment proizvoda.

Balans između potreba ključnih klijenata i očuvanja celovitosti proizvoda

U razvoju softvera za velike poslovne sisteme (Enterprise) redovno se javlja pritisak: najveći klijent zahteva specifičnu opciju, uz upozorenje prodaje da je bez toga ugovor vredan milion evra direktno ugrožen. To jeste važan poslovni signal.

Međutim, ako proizvod nakon deset takvih odluka postane zbir nestandardnih, prilagođenih funkcija napravljenih za deset pojedinačnih kupaca, postavlja se pitanje da li kompanija i dalje ima skalabilan proizvod ili se pretvorila u običnu projektnu kuću. Product Owner mora balansirati između legitimnih potreba strateških klijenata i očuvanja jedinstvene, stabilne arhitekture celog sistema. Za to ne postoji univerzalna formula, već je neophodno stalno strateško preispitivanje.

Vizija proizvoda nastaje kroz timski rad

Product Owner nosi formalnu odgovornost za cilj proizvoda (Product Goal), ali on tu viziju ne stvara u potpunoj izolaciji od ostatka firme. Vizija se gradi kroz saradnju sa korisnicima, inženjerima, dizajnerima, prodajnim sektorom i upravom kompanije.

Scrum.org naglašava da postavljanje cilja proizvoda jeste odgovornost Product Ownera, ali taj cilj uvek nastaje kroz partnerski dijalog. Lična odgovornost za odluku ne znači usamljenost u procesu – dobar Product Owner odlučuje samostalno, ali odluku donosi na osnovu sveobuhvatnih i proverenih informacija.

Zamka eksperta za usku oblast (Subject Matter Expert)

Preterano poznavanje jedne specifične oblasti može paradoksalno stvoriti problem. Ukoliko se Product Owner postavi kao jedini autoritet za domen poslovanja, inženjeri prestaju samostalno da istražuju problem i za svaku sitnicu traže njegovo mišljenje.

Znanje se u tom slučaju ne širi kroz tim, a Product Owner postaje jedina tačka zastoja u sistemu (Single Point of Failure). Scrum.org je ovu poziciju opisao kao profil eksperta za usku oblast (Subject Matter Expert stance): domensko znanje jeste izuzetno vredno, ali Product Owner ne sme pretvoriti inženjere u grupu pasivnih izvršilaca svojih detaljnih uputstava. Uspešan Product Owner timu prenosi kontekst i suštinu problema, a ne samo mehaničke zahteve.

Zašto je razumevanje uzroka važnije od pukog opisa zadatka

• Loše formulisan zadatak: „Dodati dugme za izvoz podataka (Export).“

• Kvalitetno formulisan zadatak: „Poslovni korisnici trenutno ručno prepisuju podatke iz pet različitih izveštaja kako bi sastavili nedeljni pregled za regulatore, što im u proseku oduzima četiri sata rada svakog ponedeljka.“

U drugom slučaju inženjerski tim tačno razume suštinu problema. Rešenje uopšte ne mora biti ručni izvoz u tabelu – programeri mogu osmisliti automatizovani API servis ili generisanje gotovog izveštaja jednim klikom. Kada tim razume zašto se nešto radi, on koristi svoju punu kreativnost; kada dobije samo nalog šta da napravi, on se svodi na pukog izvršioca. To je ključna razlika između autentičnog produktnog tima i fabrike funkcionalnosti.

Maksimizovanje vrednosti u okviru ograničenih resursa

Svaki tim raspolaže ograničenim vremenom, fiksnim brojem inženjera i određenim nivoom pažnje. Zato je upravljanje proizvodom u svojoj osnovi ekonomija racionalnog izbora: odluka da se radi na funkcionalnosti A automatski znači da se u tom trenutku odustaje od funkcionalnosti B.

Ako izrada opcije C zahteva tri meseca inženjerskog rada, cena te odluke nije samo plata isplaćena programerima za taj period, već i propuštena dobit koju su sve druge odložene ideje mogle doneti kompaniji (Opportunity Cost). Dobar Product Owner kontinuirano upravlja upravo tim balansom.

Ponekad je najbolja odluka – ne praviti ništa

Korisnici se žale na određeni proces, a tim odmah predlaže programiranje nove funkcionalnosti koja bi zahtevala šest nedelja rada. Međutim, dublja analiza pokaže da je sistem zapravo tehnički ispravan, ali da su postojeća uputstva i dokumentacija bili nejasni i konfuzni.

Ispravka dokumentacije traje dva dana, dok bi razvoj novog modula trajao mesec i po dana. Product Owner koji svoj uspeh meri brojem isporučenih opcija verovatno bi izabrao novi softverski modul. Racionalan Product Owner bira promenu dokumentacije – jer krajnji cilj nikada nije gomilanje programskog koda, već efikasno i ekonomično rešavanje problema.

Budućnost uloge: prelazak sa administracije na odgovornost

Sistemi veštačke inteligencije nastaviće da preuzimaju poslove formulisanja korisničkih priča, obrade podataka, sažimanja informacija i operativne organizacije rada. Zbog toga će postati nemoguće opravdati postojanje uloge čiji se rad svodi samo na održavanje urednog Backloga.

Kriterijumi se znatno podižu. Scrum.org tokom 2026. godine jasno ukazuje na ove smernice: naglasak se stavlja na poznavanje veštačke inteligencije, strateško vođenje proizvoda i odvajanje administrativnih aktivnosti od suštinske odgovornosti. Product Owner budućnosti moraće znatno dublje da razume:

• Poslovnu strategiju (Business Strategy);

• Istraživanje korisničkih potreba (Customer Research);

• Rad sa podacima i analitiku (Data);

• Mogućnosti i ograničenja veštačke inteligencije (AI);

• Tehnologiju i inženjerske kompromise;

• Ekonomiju proizvoda i procenu rizika.

Znatno manje vremena trošiće se na pitanje kako savršeno formatirati korisničku priču u alatu.

Da li će AI u potpunosti zameniti Product Ownera?

Ukoliko se nečiji svakodnevni posao sastoji isključivo od evidentiranja zahteva, sortiranja kartica u alatu, pravljenja sažetaka sa sastanaka i slanja statusnih izveštaja, takav profil rada već danas u velikoj meri biva automatizovan.

Međutim, ako Product Owner aktivno preuzima ličnu odgovornost za odluke, balansira suprotstavljene interese stejkholdera, procenjuje rizike u neizvesnim okolnostima, gradi poverenje unutar tima, zna kada treba reći „ne“ upravi kompanije i strateški balansira između kratkoročnog profita i dugoročne vizije – tehnologija tu poziciju ne može zameniti.

Pravo pitanje se zato ne bavi time da li će veštačka inteligencija zameniti Product Ownera, već koji je deo ovog posla ikada zaista zahtevao čoveka. Godina 2026. nas primorava da napravimo to jasno razgraničenje.

Profil profesionalca koji će opstati na tržištu

Opstanak na tržištu neće osigurati poznavanje prečica na tastaturi u Jiri, već sposobnost da se:

• Dubinski razumeju stvarne potrebe i ponašanje korisnika;

• Razume ekonomska struktura i poslovni model proizvoda;

• Poseduje adekvatna tehnička pismenost za ravnopravan dijalog sa inženjerima;

• Donose pravovremene i teške odluke u uslovima neizvesnosti;

• Odlučno definiše šta tim neće praviti;

• Prate i mere stvarni korisnički i finansijski rezultati;

• Menja pravac delovanja onog trenutka kada podaci pokažu da je početna pretpostavka bila pogrešna.

To jesu znatno viši standardi od dosadašnjih, ali oni predstavljaju izvornu suštinu kojoj je ova uloga od samog početka bila namenjena.

Povezivanje različitih svetova u funkcionalnu celinu

Često se navodi metafora da je Product Owner „most između biznisa i razvoja“. Iako korisna, ta definicija je nepotpuna: most samo pasivno propušta saobraćaj sa jedne strane na drugu. Uspešan Product Owner radi znatno više – on aktivno pomaže organizaciji da donese odluku koji put uopšte ima smisla graditi.

On mora:

• Poznavati korisnika dovoljno duboko da razlikuje stvarni problem od površnog zahteva;

• Poznavati biznis dovoljno dobro da prepozna ekonomsku i stratešku opravdanost;

• Razumeti inženjerski rad dovoljno dobro da proceni cenu, dugoročnu stabilnost i posledice donetih odluka.

Nakon toga sledi najvažniji korak koji nijedan metodološki okvir ne može obaviti samostalno: donošenje odluke o izboru pravca. Ne deset prioriteta, već jedan najvažniji problem koji se rešava sledeći. Ne svaki prispeli zahtev, već samo onaj koji ekonomski opravdava ulaganje inženjerskog kapaciteta. Ne funkcionalnost zato što je neko na sastanku bio najglasniji, već ishod zbog koga ta opcija ima smisla.

To je upravljanje proizvodom. Backlog je samo pisana evidencija donetih odluka. Ako Product Owner postane administrator koji samo uređuje tu evidenciju, organizacija gubi suštinu ove uloge. Algoritam može generisati korisničku priču i predložiti raspored zadataka, ali čovek mora reći: „Da, ovo je problem koji zaista vredi rešavati – i ja lično stojim iza te odluke.“ U tom trenutku Product Owner prestaje da bude administrativni beležnik i postaje ono što mu sam naziv nalaže: istinski vlasnik vrednosti proizvoda.

FAQ – Product Owner u savremenom IT poslovanju

Šta je Product Owner?

Product Owner je član Scrum tima koji nosi punu odgovornost za maksimizovanje vrednosti proizvoda koja nastaje kao rezultat rada celog tima.

Šta Scrum Guide navodi kao formalne odgovornosti Product Ownera?

Razvoj i jasno komuniciranje cilja proizvoda (Product Goal), kreiranje i komunikaciju stavki Product Backloga, njihovo uređivanje po prioritetu, kao i obezbeđivanje da Backlog bude transparentan, vidljiv i razumljiv svima.

Mora li Product Owner samostalno da piše sve korisničke priče (User Stories)?

Ne. Product Owner može delegirati operativni rad na detaljisanju stavki Backloga članovima tima, ali u svakom trenutku zadržava konačnu odgovornost za njegovo efektivno vođenje i prioritete.

Da li samo Product Owner sme da unosi izmene u Product Backlog?

Ne treba ga posmatrati kao jedinog administratora baze. Product Owner nosi punu odgovornost za prioritete i upravljanje, ali Scrum tim može aktivno doprinositi definisanju i detaljisanju stavki.

Da li je Product Owner isto što i Project Manager?

Ne. Project Manager je tradicionalno fokusiran na realizaciju posla unutar zadatog obima (Scope), fiksiranih rokova i budžeta, dok Product Owner maksimizuje poslovnu i korisničku vrednost proizvoda.

Da li je Product Owner isto što i Product Manager?

Ne nužno. U manjim kompanijama jedna osoba često obavlja obe funkcije, dok su u složenijim korporacijama strateški poslovi istraživanja tržišta i pozicioniranja (Product Management) ponekad odvojeni od operativne saradnje sa inženjerskim timom na Backlogu (Product Ownership).

Ko je direktno nadređen Product Owneru?

Scrum okvir ne definiše hijerarhiju unutar samog tima. U kompanijskoj strukturi Product Owner može odgovarati direktoru sektora ili upravi, ali na nivou samog proizvoda mora imati stvarno ovlašćenje nad prioritetima kako bi ispunio svoju odgovornost.

Može li ulogu Product Ownera obavljati odbor ili komisija?

Ne. Zvanični Scrum okvir eksplicitno navodi da Product Owner mora biti jedna konkretna osoba sa jasnom ličnom odgovornošću, a ne komisija ili upravni odbor.

Šta je cilj proizvoda (Product Goal)?

To je dugoročna strateška odrednica koja opisuje željeno buduće stanje proizvoda i služi Scrum timu kao fokus za planiranje svakodnevnog rada.

Ko definiše Product Goal?

Product Owner snosi odgovornost za njegovo postavljanje, ali kvalitetan cilj nastaje kroz saradnju sa inženjerskim timom i ključnim poslovnim stejkholderima.

Šta je Product Backlog?

To je evoluirajuća lista svega onoga što je prepoznato kao potrebno za unapređenje proizvoda, i predstavlja jedini zvanični izvor rada koji Scrum tim preuzima u vezi sa proizvodom.

Mora li Backlog sadržati stotine detaljno raspisanih zadataka mesecima unapred?

Ne mora. Predaleko detaljisanje budućeg rada stvara nepotreban administrativni trošak i lažnu sliku preciznosti, jer se prioriteti i okolnosti na tržištu neprekidno menjaju.

Šta u praksi znači maksimizovati vrednost proizvoda?

To znači birati i usmeravati rad tako da ograničeni inženjerski kapacitet tima proizvodi što veću relevantnu korist za korisnike i donosi najveću održivu vrednost kompaniji.

Da li se poslovna vrednost meri Story poenima?

Ne. Story poeni procenjuju relativnu veličinu ili tehničku složenost posla i nisu jedinica mere za poslovnu ili korisničku vrednost.

Šta predstavlja Outcome?

Outcome je merljiva promena u ponašanju, navikama ili iskustvu korisnika koja nastaje kao direktna posledica korišćenja isporučene funkcionalnosti.

Šta predstavlja Output?

Output je ono što je inženjerski tim napravio ili isporučio: gotova funkcionalnost (Feature), puštena verzija (Release), izmena u kodu ili drugi konkretan zadatak.

Šta predstavlja Business Impact?

To je krajnji finansijski ili operativni efekat koji promena u ponašanju korisnika donosi poslovanju, poput rasta prihoda, smanjenja odliva korisnika (Churn), većeg zadržavanja (Retention) ili smanjenja operativnih troškova.

Šta označava termin Feature Factory?

To je naziv za organizaciju koja funkcioniše kao fabrika: efikasno proizvodi i izbacuje veliki broj funkcionalnosti, ali nedovoljno proverava da li one stvaraju realnu korisničku i poslovnu vrednost.

Zašto Product Owner mora da ume da kaže „ne“?

Zato što je inženjerski kapacitet tima ograničen i svaki novi prihvaćeni zahtev nosi oportunitetni trošak (Opportunity Cost). Kada se sve prihvati bez selekcije, stabilna strategija prestaje da postoji.

Treba li Product Owner direktno da komunicira sa korisnicima?

Da. U većini savremenih okruženja to je neophodno. Product Owner mora razumeti probleme korisnika iz primarnih izvora, a ne samo kroz interne posrednike.

Treba li programeri direktno da razgovaraju sa krajnjim korisnicima?

Da, kad god postoje organizacioni uslovi za to. Product Owner ne sme biti informativni zid između inženjera i stvarnih korisnika.

Da li Product Owner određuje tehnički način implementacije?

Ne. Product Owner odlučuje o vrednosti, ciljevima i prioritetima rada, dok inženjerski tim samostalno određuje tehnički način implementacije rešenja.

Da li Product Owner upravlja ljudima u kadrovskom smislu?

Prema Scrum definiciji ne. Product Owner nije linijski menadžer ljudi u timu.

Koliko tehničkog znanja je potrebno Product Owneru?

Ne mora biti programer, ali je neophodan dovoljan nivo tehničke pismenosti kako bi razumeo ključne kompromise (trade-off), bezbednosne rizike, tehnički dug i posledice arhitektonskih odluka.

Ko odlučuje o rešavanju tehničkog duga?

Odluka se donosi kroz saradnju: inženjeri predočavaju tehničke rizike, dok Product Owner mora razumeti poslovni efekat tehničkog duga i uključiti ga u raspored prioriteta.

Šta je Product Discovery?

To je proces istraživanja korisničkih problema, analize tržišta i prepoznavanja rizika koji se sprovodi pre i tokom samog programiranja, kako bi se potvrdilo da li rešenje vredi graditi.

Mora li Product Owner lično učestvovati u Product Discovery fazi?

Da. U savremenom razvoju proizvoda Product Owner mora biti veoma aktivno uključen u istraživanje i testiranje hipoteza ravnopravno sa dizajnerima i inženjerima.

Šta podrazumeva Customer Discovery?

To je proces direktnog istraživanja stvarnih potreba, problema, navika i radnog konteksta korisnika.

Treba li napraviti svaku opciju koju korisnik izričito zatraži?

Ne. Zahtev korisnika je jasan signal o postojanju problema, ali njegovo predloženo rešenje često nije najefikasniji niti najbolji način da se taj problem trajno reši.

Kako Product Owner postavlja prioritete u praksi?

Kombinovanjem strategije proizvoda, korisničke vrednosti, poslovnog efekta, procene rizika, tehničkog konteksta, troška odlaganja (Cost of Delay), raspoloživog kapaciteta i dokaza prikupljenih iz podataka.

Postoji li univerzalno najbolji model za prioritizaciju?

Ne. Modeli poput RICE, WSJF ili MoSCoW pomažu pri strukturiranju odluke, ali ne mogu zameniti potrebu za zrelom procenom u zavisnosti od konteksta.

Šta predstavlja trošak odlaganja (Cost of Delay)?

To je ekonomska i strateška vrednost koju kompanija gubi zato što određena funkcionalnost ili servis kasni sa plasiranjem na tržište.

Šta predstavlja oportunitetni trošak (Opportunity Cost)?

To je vrednost najbolje alternativne mogućnosti koju svesno gubimo zato što smo inženjerski kapacitet odlučili da investiramo u nešto drugo.

Kako Product Owner sarađuje sa stejkholderima?

Prikuplja relevantne informacije, argumentovano objašnjava prioritete, gradi zajedničko razumevanje i donosi odluke uzimajući u obzir njihove potrebe i širi strateški kontekst.

Može li uticajni stejkholder direktno promeniti prioritet rada tima?

U zdravom operativnom modelu prioriteti moraju prolaziti kroz jasnu odgovornost Product Ownera, a ne se menjati prema hijerarhijskoj snazi svakog pojedinačnog stejkholdera.

Kako prepoznati model bez stvarnih ovlašćenja (Proxy Product Owner)?

To je osoba koja formalno ažurira Backlog i prenosi zahteve, ali nema realnu mogućnost da samostalno odlučuje o cilju proizvoda, prioritetima i alokaciji vrednosti.

Zašto je postojanje Proxy Product Ownera problematično za kompaniju?

Zato što povećava broj posrednika u lancu komunikacije, usporava donošenje odluka i razdvaja formalnu odgovornost od stvarne moći odlučivanja.

Kako Product Owner sarađuje sa Product Managerom?

Model zavisi od kompanije, ali je ključno da granice odgovornosti budu precizno postavljene, tako da Product Owner ne postane sveden na administrativnog prevodioca tuđih odluka.

Da li na jednom digitalnom proizvodu treba da radi više Product Ownera?

Prema Scrum Guide-u, čak i kada na razvoju jednog proizvoda sarađuje više razvojnih timova, oni dele isti Product Goal, isti Product Backlog i jednog zajedničkog Product Ownera.

Kako Product Owner funkcioniše u agilnim sistemima velikog obima (Agile at Scale)?

Mora održavati jasnu liniju odgovornosti nad proizvodom i sprečavati da dodatni koordinacioni nivoi pretvore menadžment u trom i skup lanac posrednika.

Koje metrike Product Owner treba da prati?

One koje odgovaraju konkretnom proizvodu: stope usvajanja (Adoption), aktivacije (Activation) i zadržavanja (Retention), stopu konverzije, zadovoljstvo korisnika, prihode, troškove, kao i pokazatelje stabilnosti i toka isporuke.

Da li je praćenje rasta prihoda (Revenue) dovoljno za ocenu uspeha?

Nije. Neophodno je pratiti i zaštitne parametre (Guardrail Metrics), kako kratkoročno povećanje prihoda ne bi uništilo zadržavanje korisnika, kvalitet softvera ili poverenje na tržištu.

Šta su zaštitne metrike (Guardrail Metrics)?

To su prateći pokazatelji koji štite druge vitalne dimenzije sistema dok optimizujemo glavni željeni ishod (Outcome).

Na koji način AI tehnologije pomažu Product Owneru?

Ubrzavaju analizu komentara korisnika, sažimaju intervjue, pretražuju aktivnosti konkurencije, predlažu strukturu novih zadataka, generišu hipoteze i automatizuju administrativne poslove.

Može li veštačka inteligencija u potpunosti zameniti ulogu Product Ownera?

AI će vrlo verovatno preuzeti značajan deo administrativnih aktivnosti, ali ne može zameniti organizacionu odgovornost, kompleksne strateške kompromise i razumevanje konteksta u kome se procenjuje šta je zaista vredno.

Šta predstavlja Agentic AI u kontekstu razvoja proizvoda?

To su napredni autonomni sistemi koji ne samo da generišu sadržaj, već samostalno izvršavaju višekoračne aktivnosti, kao što su dubinska analiza podataka, istraživanje i priprema predloga odluka.

Hoće li AI agenti postati redovni korisnici digitalnih servisa?

Sve češće da. API servisi, strukturirani podaci i mašinski čitljivi interfejsi postaće presudni kako softverski agenti počnu samostalno da biraju i koriste usluge u ime ljudi.

Mora li Product Owner u budućnosti posedovati viši nivo tehničkih znanja?

Vrlo verovatno da. Sa razvojem veštačke inteligencije i sistema zasnovanih na mašinskoj komunikaciji, razumevanje tehnoloških principa i rada sa podacima postaje neophodan uslov za donošenje zrelih odluka.

Koja je najvažnija veština Product Ownera?

Sposobnost donošenja kvalitetnih i argumentovanih odluka o vrednosti u uslovima stalne poslovne i tržišne neizvesnosti.

Koja je najveća greška koju Product Owner može napraviti?

Pretvaranje sopstvene uloge u administrativnog službenika koji bez pogovora sve prihvata, ništa stvarno ne prioritizuje i nema direktan kontakt sa korisnicima niti sa poslovnim ishodima.

Kako prepoznati da Product Owner uspešno vodi proizvod?

Ne po urednosti Backloga u alatu, već po tome da li tim ima jasan cilj proizvoda, razume zašto nešto radi, donosi brze odluke, dobija povratne informacije od korisnika i u kontinuitetu isporučuje merljivu vrednost.

Koja je najpreciznija definicija savremenog Product Ownera?

To je osoba odgovorna za to da ograničeni kapacitet produktnog tima bude uložen u rešavanje onih problema čiji ishod donosi najveću i dugoročno održivu vrednost za korisnike i kompaniju.