A mérnök tervez, programoz, infrastruktúrát konfigurál. A marketinges web oldalt, brossurákat tervez, sajtó közleményeket ír. A projekt manager projekt tervet készít, és a mérnök nyakába liheg, ha közeledik határidő.
De mire jó a product manager?
Amikor csatlakoztam a Twilio Real Time Data csapatához, akkor volt egy zseniális technológiánk. Viszont nem volt egyetlen kész termékünk, vevőnk, vagy egy fillér bevételünk sem. Ma, 12 hónappal később, van három termékünk, amit erre a technológiára építettünk, és immár a vevőink között tudhatjuk a világ egyik legnagyobb bankcsoportját épp úgy, mint a Szilicium Völgy vagy épp London legmenőbb startupjait.
Rengeteg más szereplő között a product managereknek óriási szerepük volt ebben. Ma szeretnék saját tapasztalataimról mesélni, mint a három product manager egyike.
A product manager két legfontosabb feladata
A csapaton belül, mint product manager, a Signal konferencián május végén bejelentett termékért, a Notify-ért vagyok felelős. Az én szerepem alapvetően kettős. Egyrészt, ki kell találjam, hogy hogyan csináljunk pénzt a technológiából. Másrészt biztosítanom kell, hogy a tervet sikeresen végre is hajtjuk.
Amikor csatlakoztam a Twiliohoz, volt egy kiváló frameworkünk arra, hogy üzeneteket küldjünk különböző mobil vagy webes klienseknek. Ezt a technológiát elsősorban az induló chat termékünkhöz használtuk, az IP Messaging-hez. Az első feladatom az volt, hogy kitaláljam hogyan lehetne ebből a frameworkből pénzt csinálni.
Müller Viktor 2009-ben végzett a BME Műszaki Informatika szakán. Egy évet dolgozott az IBM Research zürichi laboratóriumában szoftver fejlesztőként és kutató gyakornokként. Majd a The Boston Consulting Group stratégiai tanácsadó cégnél folytatta pályáját tanácsadóként, ahol elsősorban bankok és telekom cégek felső vezetőit támogatta stratégiai kérdésekben Magyarországon, Abu Dhabiban, Törökországban és Indiában.
2015-ben diplomázott a Harvard Business School MBA képzésén. Tanulmányai alatt több magyar, amerikai és brit startupokkal dolgozott együtt. 2015 óta a san franciscioi székhelyű telekommunikációs startup, a Twilio londoni irodájában a Notify termék product managere.
Első feladat: hogy lesz ebből pénz
Adott volt a probléma: kitalálni, hogy hogyan tudunk pénzt csinálni a meglévő üzenetküldő technológiánkból. Ehhez először megértettem, mire is képes a saját technológiánk. Aztán megvizsgáltam, kik ajánlanak hasonló termékeket. Mindent összegyűjtöttem róluk. Milyen use-case-eket reklámoznak a weboldalukon? Milyen feature-eik vannak? Mennyibe kerülnek? Kipróbáltam néhány API-t, hogy lássam, mitől lesz az egyik jobb mint a másik.
Kitaláltam, hogy kezdjünk egy egyszerű mobil push notification termékkel Androidra és iOSre fókuszálva. Felhívtam néhány lehetséges vevőt, meséltem nekik a termékről, és hogy mire lehetne használni. A beszélgetés utána általában így folytatódott:
Vevő: Ez mégis mitől más mint xy cég terméke?
Viktor: Ööööö… Őszintén... semmitől. De mi az amit ti szeretnétek csinálni, milyen user experience-t szeretnétek?
Vevő: A push notification-t imádjuk, de néha nem érkezik meg, és szuper lenne, ilyenkor küldeni egy SMS-t. De ezt nagyon sokáig tartana nekünk lefejleszteni.
Aha...! Szóval az alap push notification már megoldott probléma. Viszont, intelligensen kombinálni más csatornákkal (pl.: SMS-sel) az még nem.
Innentől megvolt az ötlet a fejemben. Egyedül viszont tudtam, hogy nem tudom ezt megcsinálni. Ahhoz hogy az ötlet eljusson a megvalósításhoz, kellett hozzá támogatás a cégben felülről és oldalról is. Úgyhogy összeraktam egy stratégiai anyagot a menedzsmentnek. Leírtam a problémát, amivel a vevőink küzdenek, egy víziót, hogy hogyan is lehetne megoldani és egy roadmap-et, hogy hogyan fogunk a végső megoldásig eljutni. Az executive team imádta, így megvolt a támogatás fentről: pénz, paripa, fegyver. Más szóval erőforrások az termék építéséhez és a piacra viteléhez. :)
De programozni nem a CEO fog, és ha a mérnök csapat nem hisz a termékben, az sose készül el, vagy rossz lesz. Szóval a csapatnak is el kellett adni a víziót. Ez nem volt nehéz, szerencsére nagyon érdeklődő, széles látókörű mérnökeink vannak, akiket érdekel, hogy mit akar a vevő. Amint konkrét példákat tudtam mondani, hogy melyik vevő milyen problémával küzd, meg volt a "buy-in".
A következő lépés: megépíteni a terméket.
Második feladat: végrehajtás
A CEO-nak eladott, magas szintű roadmap-et le kellett bontanunk egy részletesebbre. Az első lépés a minimális scope meghatározása volt, a Minimum Viable Product (MVP) azonosítása. A mi esetünkben ez egy cím regiszter volt felhasználó szegmentálással, plusz iOS és Android push notification csatornával.
Készítettünk egy részletes specifikációt. Ezt aztán néhány nap alatt elvégezhető feladatokra bontottuk és ticketként felvittük a feladatkezelő rendszerbe. A csapattal aztán minden héten megegyeztünk, hogy ki melyik ticketen fog dolgozni. Minden héten pénteken pedig demozták a mérnökök, hogy épp ki mivel készült el.
Az MVP a Minimum Viable Product (Minimális Életképes Termék) rövidítése. Rengeteg definíciója van, hogy ez pontosan mit takar, szerintem az alábbi leírás a Lean Stack oldalról jól összefoglalja:
"A Minimum Viable Product a legkisebb dolog, amit el tudsz készíteni, és a vevőknek értéket teremt (és bónusz, ha ezért a vevő hajlandó fizetni is)."
Más szóval, az MVP az a termék, amit a lehető leggyorsabban és legkisebb befektetéssel el tudsz készíteni - és amiért a vevőid fizetni fognak. Ez legtöbbször sokkal kisebb dolgot jelent, mint amit elsőre gondolnál.
Annak, hogy egy MVP-t adsz ki ahelyett, hogy a végső termék építésére fókuszálnál hatalmas előnye van: nagyon korán tudsz visszajelzéseket gyűjteni, így azonnal azokra a részekre tudsz koncentrálni, amik a legnagyobb értéket teremtik.
Emellett ha van egy terméked, akkor sokkal több ember fog szóba állni veled, és komolyan venni. Persze fontos, hogy a leendő vevőiddel már azelőtt beszélj, hogy van egy kész terméked, viszont termék nélkül a visszajelzésük sokkal kevésbé lesz hasznos, mint ha már használták azt. (Itt egy remek útmutató, hogy hogyan végezd hatékonyan ezeket a korai interjúkat.) Ez annyira igaz, hogy még a cégen belül is sokkal könnyebb volt rávennem az account managereinket, hogy a meglévő vevőinkkel szervezzenek egy megbeszélést, miután már volt egy konkrét termék a kezünkben, nem csak egy ötlet.
Ahhoz azonban, hogy ez a termék sikeres legyen, sokkal több kell, mint egy jó API, amit a vevőink használnak. Kell dokumentáció, tutorialok, egy portál a konfigurációknak és debug információnak. Kell marketing anyag, kell demo alkalmazás, kell egy sajtóközlemény az induláshoz, kell egy bemutató beszéd, amivel a Signal konferencián bejelentjük a terméket. Végül pedig kellenek vevők, akik részt vesznek a béta programban, és segítenek tökéletesíteni a terméket.
Ezeknek a koordinálása is a product manager feladata - és ha nincs más, aki megcsinálja, akkor a product manager feltűri az ingujját és dokumentációt ír, teszteli a portált, demo alkalmazást programoz, és összerakja a marketing anyagokat. Meg persze előad a termékről a konferencián.
Minden készen, indulhatunk. Vagyis, még kellene egy apróság...
Minden a terv szerint halad, rövidesen készen állunk az indulásra. De persze az élet mindig tartogat meglepetéseket. Néhány héttel a termék bemutatása előtt a CEO elkezdte kérdezgetni, hogy ugye a bemutatóra még integráljuk az SMS és Facebook Messenger csatornákat is. Meg ugye lesz automatikus failover push notification-ről SMS-re. Bár ezek mindig is részei voltak a roadmapnek, de nem terveztük a következő néhány hétben implementálni őket, hiszen nem triviális feature-ökről van szó.
Ebben a pillantban, amikor másoktól jönnek feature request-ek, vált újra nagyon hasznossá a product manager. A mérnök csapathoz ezek a kérések nem jutottak el, mert mind hozzám futott be. Ezért aztán ők nem is stresszeltek, hanem tudtak a meglévő feladataikra fókuszálni. Mivel az eredeti MVP-vel jobban haladtunk mint terveztük, gondoltam legalább nézzük meg mit érdemes ezekből a kérésekből megfontolni.
A tech leaddel közösen megbecsültük, hogy az SMS és Messenger integrációt van értelme megpróbálni, de a többit nincs. Erről aztán meggyőztem a menedzsmentet is, így megszűnt felülről a nyomás. Leszerveztük a többi csapattal, akikre szintén feladatott róttak ezek a fejlesztések, hogy ők is benne vannak. Az így már reálisnak tűnő tervvel álltunk aztán a csapat elé, de nem mint elvárás, hanem mint kérdés, hogy szerintük is van-e ennek értelme. Miután ők is lelkesek voltak, így belevágtunk. A többi pedig már történelem - sikerült ugyanis a május 25-i bemutatóra, a Signal-ra lefejlesztenünk ezeket, amit aztán tech sajtó pozitívan fogadott.
A május 25-i bemutatóval még nem ért véget a munka. Még előttünk van egy profi ügyfélszolgálat megszervezése - jelenleg ugyanis én vagyok a customer support egy személyben. A terméket be kell még árazni, az árat pedig be kell tudni szedni (billing). Hátra van az értékesítési adatok monitorozása, és marketing folyamatos javítása az adatok alapján, illetve az értékesítők (sales) oktatása, támogatása. Meg persze a termék folyamatos, iteratív fejlesztése új funkciókkal, miközben az infrastruktúrát is skálázni kell.
Szóval, mire is jó egy product manager? Arra, hogy kitalálja, hogyan is lehetne a technológiából pénzt csinálni, és biztosítja a végrehajtást. Röviden: ő a felelős, hogy a termék sikeres legyen.