Neretka je pojava da Product Manageri nemaju tehnički background, bilo u obrazovanju, bilo u iskustvu. Mogu da kažem da i ja pripadam toj pojavi. Koliko je ovo važno govori i činjenica da je jedna od često diskutovanih tema u Product Management zajednici – da li je bolje kada je Product Manager programer ili ne?
Jedan od osnovnih benefita koji se navodi u ovom slučaju jeste bolje razumevanje tehničkih zahteva i izazova pri vođenju proizvoda. Ovo naročito dolazi do izražaja kada se radi na tehnički/tehnološki zahtevnijim proizvodima. Sa druge strane, ljudima od inženjerske struke često fali da budu business savvy, odnosno da dobro kapiraju biznis kontekst proizvoda, kao i da budu customer savvy, da razumeju probleme i zahteve korisnika, i da ih onda sa lakoćom pretoče u tehničke zahteve prilikom definisanja funkcionalnosti. Međutim, bez obzira da li je PM tehnički potkovan ili ne, mislim da je jako važno imati u vidu i jedan širi aspekt razumevanja samog procesa vođenja proizvoda.
Moj put u product managementu je započeo radom na jednom front-end proizvodu. Radio sam na definisanju user flowa, unapređivanju usabilitya, kreirao wireframove, verovao da će neki featuri rešiti probleme korisnika… Onda sam došao u firmu u kojoj mi je bio dodeljen jedan back-end enterprise proizvod. Pozivi metoda, request-ovi, response-ovi, IP adrese su postali deo svakodnevnice, i moram priznati, bilo je čupavo. Ne samo da je bilo teško pratiti šta devsi pričaju, nego je sam proces bio nekako… čudan. Na stranu što je dobar deo ovog problema bio organizacione prirode, očigledan nedostatak tehničkog znanja je učinio da konstantno imam nedefinisan utisak neprilagođenosti, kao da konstantno pokušavam da plivam uzvodno, dok me developeri vuku na drugu stranu. Što bi rekao jedan moj kolega, “izgleda da se tu nešto krvavo pokarabasalo”.
Šest meseci nakon što sam došao u firmu, it hit me. U jednom trenutku kontemplacije na temu uzvodnog guranja kamena, desio se a-ha momenat – ti konstantno pokušavaš da razvijaš (već gotov) proizvod, umesto da ga integrišeš. Daleko od toga da sam posle toga mislio da proizvod ne treba dalje da se razvija, nego je problem bio što sam konstantno zanemarivao, ispuštao iz vida kontekst u kojem proizvod funkcioniše – komponente klijentovog sistema koje su neophodne da proizvod isporuči svoju vrednost – dok sam ja stalno insistirao na upravljačkim funkcionalnostima, podstaknut inputima koji su dolazili od klijentovog osoblja. Prevideo sam prirodno back-end okruženje proizvoda. Fokus mi je bio na front-end delu proizvoda, koji je zapravo bio sekundaran, s obzirom da mu je svrha suštinski bila kontrola, nadziranje i fino doterivanje pojedinih elemenata sistema, i za početak je bio sasvim dovoljno razvijen što sam tek kasnije shvatio.
U čemu je razlika?
Taj momenat ličnog otkrovenja mi je pomogao da shvatim da kod front-end proizvoda vodimo proces razvoja, da je naglasak na definisanju i prilagođavanju funkcionalnosti koje krajnjem korisniku omogućavaju izvršavanje određenih aktivnosti.
Kod back-end proizvoda imamo delivery, implementaciju proizvoda na klijentskoj strani. Ovde je važno voditi proces integracije, a ne razvoja. Potrebno je identifikovati komponente na klijentovoj strani na koje se proizvod povezuje i koje su specifičnosti tog okruženja, kao i koje su ključne i/ili kritične tačke na strani samog proizvoda iz čega se mogu prepoznati i zahtevi klijenta. Nebitno je da li se taj proces dešava on-sight ukoliko je u pitanju neki hardverski proizvod, ili imamo cloud rešenje koje se kroz API implementaciju povezuje sa komponentama na klijentovoj strani. I kod back-end proizvoda imamo razvoj, ali praktično samo onaj inicijalni, koji potencijalno može dosta dugo da traje zbog same kompleksnosti klijentskih zahteva, time i definisanja funkcionalnosti. Nakon toga, klijentsko okruženje u koje se proizvod implementira će biti isto u nekih 80% slučajeva, od klijenta do klijenta, dok će onih preostalih 20% biti prilagođavanje specifičnim zahtevima klijenta, ne toliko, i ne nužno, sam razvoj.
Da pojasnim još jednu stvar. Kad kažem front-end proizvod, ne mislim da tu “nema back-enda”, već da zahtevi dominantno utiču na korisnički deo proizvoda, da postanu vidljivi na front-end delu proizvoda. Drugim rečima, ovde govorim o onome što se zove i consumer-facing proizvod. Kad kažem back-end proizvod, pa, mislim na back-end proizvod, na automatizovano rešenje koje izvršava određene akcije i tako donosi novu i/ili povećava vrednost postojećem klijentovom sistemu.
B2C vs B2B product management
Kad već spominjem consumer-facing, mislim da je zgodno napraviti paralelu sa još jednim osvrtom na product management u zavisnosti od toga kakav je biznis kontekst proizvoda, B2C ili B2B. Dan Schmidt je jedan od novijih autora kojeg sam otkrio pre nekih godinu dana, i koji je svojim idejama prilično uticao na mene i moja razmišljanja o product managementu, što ćete uskoro videti i ovde na blogu. U ovom njegovom odgovoru na jedno pitanje na Quori, Schmidt prilično pojednostavljuje razliku između ova dva tipa proizvoda – B2C proizvodi “hvataju” pažnju, dok B2B proizvodi “naplaćuju” tu pažnju.
Da ne ulazim u detalje (pročitajte članak), poenta kod B2C proizvoda je doći do technology-user fita, odnosno, da proizvod generiše veliku adopciju među korisnicima pre nego što se krene sa nekim vidom monetizacije. S druge strane, kod B2B proizvoda takođe imamo fokus na generisanju baze korisnika, ali je prava validacija proizvoda zapravo to da li biznisi žele da plate za neko rešenje ili ne, i to čak pre nego što su neke funkcionalnosti razvijene. Ovo je maltene tipično za SaaS proizvode, a konkretno pada mi na pamet par (za sada) uspešnih domaćih SaaS startapa, koji su upravo prošli tu golgotu od nekoliko iteracija, bez konkretnog proizvoda, sa ciljem validacije koliko su njihovi potencijalni klijenti voljni da plate njihov proizvod. Schimdt skreće pažnju i da B2C proizvodi nastoje da se pre ili kasnije monetizuju dominantno kroz advertajzing, pa tako svi B2C proizvodi imaju i nezaobilazan B2B aspekt o kojem treba razmišljati.
Za kraj, interesantno mi je bilo kada sam nedavno na ProductHuntu pročitao kako je Ben Horowitz definisao product/market fit:
The big thing is to focus all of your energy on product/market fit. I.e., get to a product that people are adopting very quickly or that you can reliably sell repeatedly.
Indirektna potvrda Schmidtovog rezonovanja.
Naslovna slika: http://php-skola.info/index.php/blog/106-sta-morate-da-znate-pre-nego-sto-pocnete-da-se-bavite-programiranjem