Skip to main content

Product Manager ဖြစ်ဖို့ Tech အကြောင်း သိမှရမှာလား

Software Engineer လိုမျိုး Technical Background ကနေ Product Manager career ကို ပြောင်းတဲ့အခါ အားသာချက်တွေ အများကြီးရှိသလို ရင်ဆိုင်ကြုံတွေ့ရတတ်တဲ့ Challenge တွေလည်း ရှိပါတယ်။

ဒီ Article ကို ရေးဖြစ်တဲ့အကြာင်းက ရှေ့မှာ “မြန်မာနိုင်ငံမှ Product Manager များ” ခေါင်းစဥ်နဲ့ မြန်မာနိုင်ငံ Industry မျိုးစုံမှာရှိတဲ့ Product Manager တွေရဲ့ Backgoround ကို Research လုပ်ဖြစ်ခဲ့ပြီး ရလဒ်အရ တော်တော်များများက Technical Background ကနေ ပြောင်းလာတယ်ဆိုတဲ့ အချက်ပါ။ ဒီတော့ Product Manager ဖြစ်ဖို့ Technical အကြောင်းကောင်းကောင်း သိမှဖြစ်မှာလားဆိုပြီး မေးလာကြပါတယ်။


အရင်ကလည်း ဖြေဖူးပါတယ်…. Technical Background ရှိမှ / ကျွမ်းကျင်မှ / Code ရေးဖူးမှ Product Manager ဖြစ်တာ မဟုတ်ပါဘူး.. သို့ပေမယ့် Product Manager ဆိုတာ နေ့စဥ် Developers တွေနဲ့ Communicate လုပ်ပြီး Digital Product တစ်ခုကို ရုပ်လုံးဖော်ရတဲ့သူဖြစ်တာမို့ Technical Knowledge က အတိုင်းအတာတစ်ခုအထိ ရှိဖို့လိုပါတယ်။ ဆိုတော့ Technical Background ရှိတဲ့အတွက် ဘာတွေအားသာချက်ရှိလဲ၊ Technical Background ရှိလို့ ကြုံတွေ့ရတတ်တဲ့ Challenge တွေကရော ဘာတွေဖြစ်မလည်းဆိုတာ ဒီ Article မှာ ဝေမျှချင်ပါတယ်။

အားသာချက်များ
  • Developers တွေပြောတဲ့ အကြောင်းအရာတွေနဲ့ Technical Terms တွေကို နားလည်တဲ့အတွက် နေ့စဥ် Team နဲ့ Communicate လုပ်ရတာ ပိုမိုလွယ်ကူတယ်။ Technical side ရဲ့ အခက်အခဲနဲ့ Efforts တွေကို Busienss ဘက်က စဥ်းစားပေးနိုင်တာ၊ Business Requirements တွေကို ကိုယ့် Development Team နားလည်အောင်ပြောပေးနိုင်တာတွေက ကြီးမားတဲ့ အားသာချက်ပါ။
  • Development Team နဲ့ Product Manager ကြားမှာ အချင်းချင်းနားလည်နိုင်တာက ရေရှည် Working Relationship မှာ အထောက်အကူပြုပြီး သူတို့ဆီက Respect ကိုလည်း ရယူနိုင်ပါတယ်။ ကိုယ်ကိုယ်တိုင်လည်း သူတို့အခက်အခဲတွေကို နားလည်နိုင်လို့ Mutual Respect ပိုရှိကြပါတယ်။ (Developers တွေဘက်က သူတို့ပြောတာကို နားမလည်တဲ့ PM ဆို မလေးစားတာ၊ Technically အရမ်းရှုပ်ထွေးသယောင် ပညာပြတာမျိုးလေးတွေလည်း ရှောင်နိုင်သွားတာပေ့ါ)
  • Feature တစ်ခုထည့် / အပြောင်းအလဲတစ်ခုလုပ်တော့မယ်ဆို ဘယ်လောက် ခက်ခဲနိုင်လဲ၊ ဘယ်လောက် impact ရှိနိုင်မလဲဆိုတာ၊ ဘယ်လောက် Resource တွေလိုအပ်မလဲ ခန့်မှန်းနိုင်တယ်။ ခန့်မှန်းဖို့လည်း လိုတဲ့ မေးခွန်းတွေကို ထိထိရောက်ရောက် မေးနိုင်ပါတယ်။
  • Product မှာ Feature တစ်ခုထည့်မယ်ဆိုတိုင်း Business Point of View ကပဲ ထည့်ချင်တဲ့ Feature ကို အာရုံစိုက်ပြောတာမဟုတ်ပဲ Product အပေါ်မှာ ဖြစ်လာနိုင်တဲ့ Impact တွေ၊ Technical Debt တွေကို စဥ်းစားပေးနိုင်၊ နားလည်ပေးနိုင်ပါလိမ့်မယ်။ ရှိပြီးသား Technical Debt တွေကို ဖြေရှင်းဖို့လဲ ပိုအလေးထားကြပါတယ်။
  • Code ကူရေးပေးဖို့ မလိုပေမယ့် တစ်ခါတစ်ရံ လိုအပ်တဲ့ Technical နဲ့ Product ကို ခြုံကြည့်ပြီး Development Team ကို Decison ချဖို့ Input ပေးတာ၊ Advice ပေးတာမျိုးတွေ လုပ်ပေးနိုင်ပါတယ်။

ဒါတွေကတော့ Technical Background ရှိတဲ့ Product Manager တွေအတွက် အားသာရတဲ့ အချက်တွေပါ။ တစ်ချိန်တည်းမှာလည်း မိမိက Software Engineer မဟုတ်တော့ပဲ Product Manager ဆိုတဲ့ Role အသစ်ကို ရောက်လာတဲ့အခါ သူများနဲ့မတူတဲ့ Challenge တွေရှိပြန်ပါတယ်။ ကျွန်တော့်ကိုယ်တွေ့ ကြုံဖူးတဲ့ Challenge တွေကတော့ -

Product Manager က Software နဲ့ အကျွမ်းဝင်နေတာမို့ Development Team ဘက်မှာပဲ နစ်နေပြီး လိုတာထပ် ပို ဝင်ပါမိနေတာမျိုးတွေရှိတတ်ပါတယ်။ တကယ်တမ်း Product Manager တွေရဲ့ တာဝန်က Customer နဲ့ Business ဘက်ကို အဓိက စဥ်းစားပြီး ပြဿနာတွေဖြေရှင်းရသူပါ။ Software Engineer တုန်းက Quality Software ကို Develop လုပ်ဖို့က Goal ဖြစ်ပေမယ့်.. Product Manager ဖြစ်လာတဲ့အခါ Customer ဆီကို ပေးမယ့် Product က တကယ်အသုံးဝင်တဲ့ Product / Solution ဖြစ်လား၊ ကိုယ့် Company ရဲ့ Business Vision အတိုင်းရော ဖြစ်လား စတာတွေကို အာရုံစိုက်ဖို့ လိုပါတယ်။ Technical ဘက်ကို လိုတာထပ်ဝင်ပါမိတာက Developers တွေအတွက် အနှောင့်အယှက်ဖြစ်နိုင်သလို Product အတွက်လည်း လိုအပ်တဲ့ Customer Focus တွေ အားနည်းသွားပါလိမ့်မယ်။
Product Manager ရဲ့ နေ့စဥ် Tasks တွေမှာ Customer နဲ့ Business ဘက်ကို ပိုအာရုံစိုက်ပြီး Technical ဘက်ကို အာရုံအရမ်းမစိုက်မိအောင် Balance ညှိတာ အကောင်းဆုံးပါ။

တစ်ခါတစ်ရံ Product အတွက် Why မေးခွန်းတွေကို ဖြေရှင်းမယ့်အစား Technical ဘက်က How ကိုပဲ အာရုံစိုက်မိတာမျိုး ဖြစ်တတ်ပါတယ်။ Product Manager က မိမိ Product မှာ ဒီ Feature ကို ဘာလို့ထည့်သင့်လဲ၊ ဘာလို့ဖြုတ်သင့်လဲဆိုတဲ့ (Why) တွေကို အာရုံစိုက်ရမယ့်သူဖြစ်ပါတယ်။ ဒီ Feature ကို ဘယ်လို Develop လုပ်မလဲဆိုတဲ့ (How) ကို မဟုတ်ပါဘူး။ ။ Company က အထက်အရာရှိတွေကပါ Product Manager ဆီက Why အစား How မေးခွန်းရဲ့ အဖြေတွေကို မျှော်လင့်တတ်ကြတာလည်း ကြုံရပါတယ်။ ဥပမာ - Software က ဒီ Feature ထပ်ထည့်လို့ရနိုင်လား၊ အရမ်း Development Effort များမှာလား စသည်ဖြင့် Technical ဘက်ကိုပါ Product Manager ကို Focus လုပ်စေချင်တာမျိုးတွေ ကြုံရတတ်ပါတယ်။
ဒါကို ဘယ်လိုကျော်လွှားမလဲဆိုတော့ Product အတွက် Why မေးခွန်းတွေကို ပိုအာရုံစိုက်ပြီး Technical နဲ့ပတ်သက်တဲ့ How မေးခွန်းတွေအတွက် Tech Lead တွေ Project Manager တွေကို Meeting ထဲ ခေါ်ထည့်တာက အကောင်းဆုံးပါပဲ။

Developers တွေက ကိုယ့်ဆီက Development နဲ့ဆိုင်တဲ့ Technical Decision တွေ ချဖို့ အကူအညီတောင်းတာ (ခေါင်းရောင်းတာ) မျိုးတွေ မကြာခဏ ကြုံရပါတယ်။ တကယ်တမ်းက Development Team နဲ့ Tech Lead က Product Manager ဆီက လိုအပ်တဲ့ Input တွေယူပြီး အကောင်းဆုံး Technical Decision ကို ချရမှာဖြစ်ပေမယ့် Product Manager ကလည်း Technical Difficulities တွေ နည်းနည်း ရှင်းပြလိုက်ရင် နားလည်နေတာ့ “A လုပ်လို့ရတယ်၊ B လုပ်လို့ရတယ် ဘယ်ဟာနဲ့လုပ်ချင်လဲ ရွေး?” ဆိုတာမျိုး၊ “A တော့လုပ်ဖို့တော့ခက်တယ် B နဲ့လုပ်လိုက်ရမလား?” “Server A သုံးချင်လား B သုံးချင်လား?” ဆိုတာမျိုး Decision တွေ လာလာချခိုင်းတာ မကြာခဏကို ကြုံရပါတယ်။
အဲ့လိုအခြေအနေမျိုး ကြုံရင်တော့ Team ကို Options တွေ တောင်း၊ ဘယ်ဟာရွေးရင် ဘာ Pros and Cons တွေ Impacts တွေရှိမလဲ မေးခွန်းများများ ပြန်မေးပြီး သူတို့ဘာသာ Brainstorming လုပ်ရင်း အဖြေ တွေ့အောင် ကူညီတာက အသင့်တော်ဆုံးလို့ မြင်ပါတယ်။ အချိန်မပေးချင်တာနဲ့ Decisions တွေ ဝင်ချပေးတာက ရေရှည်အတွက် မကောင်းနိုင်ပါဘူး။

ဒါတွေက Software Engineer ကနေ လာတဲ့ Product Manager အနေနဲ့ ကြုံဖူးတဲ့ Challenge တွေပါ။ Company Culture ပေါ်မူတည်ပြီး ကြုံတွေ့ရတဲ့ Challenge တွေကတော့ ကွဲပြားနိုင်ပါတယ်။ အားလုံးနဲ့ Common ဖြစ်တဲ့ အချက်တွေလည်း ရှိမှာပါ။ ကိုယ့် Background Experience ကနေရတဲ့ အားသာချက်တွေကို အသုံးချပြီး အောင်မြင်တဲ့ Product Manager တစ်ယောက် ဖြစ်အောင် အခက်အခဲတွေကို ကျော်လွှားသွားဖို့က အဓိကပါပဲ။

နောက်ထပ် ဖတ်ချင်တဲ့ Topic တွေရှိရင်လည်း ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။ ProductBaze မှ Product သမားအချင်းချင်း idea တွေ၊ knowledge နဲ့ experience တွေ share ဖို့ နွေးနွေးထွေးထွေးဖိတ်ခေါ်ပါတယ်။ ProductBaze အကြောင်း (၁) မိနစ်စာ မိတ်ဆက် post လေးကို ဒီ link မှာ ဖတ်လို့ရပါတယ်။ ProductBaze ကို ဆက်သွယ်ချင်ရင် productbaze@gmail.com သို့ ပေးပို့ ဆက်သွယ်နိုင်ပါတယ်။

Comments

Popular Posts

အသုံးများတဲ့ Product Testing တွေ

Webinar တစ်ခုမှာ Product Testing တွေအကြောင်းထည့်ပြောတော့ နောက်ဆုံးအမေးအဖြေအချိန်မှာ အမေးခံရဖူးတာလေး မှတ်မှတ်ရရရှိလို့ပါ။ “A/B Testing ဆိုတာ Alpha Testing, Beta Testing ကို ပြောတာလား” ဆိုတဲ့ မေးခွန်းပါ။ သိတဲ့သူအတွက်တော့ ဘာမှမဆိုင်တဲ့ Testing တွေမှန်း တန်းသိနိုင်ပေမယ့် တစ်ဖက်မှာလည်း မေးလည်းမေးချင်စရာ အခေါ်အဝေါ်က ခပ်ဆင်ဆင်တူနေတာကိုးလို့ တွေးမိပါတယ်။ ဒါကြောင့် ဒီဆောင်းပါးမှာ မကြာမကြာလည်း ပြောဖြစ်ကြပြီး၊ အသုံးလည်းများ၊ အသုံးလည်းဝင်တဲ့ Alpha Testing, Beta Testing နဲ့ A/B Testing တို့အကြောင်းကို တီးမိခေါက်မိအောင် ရေးချင်ပါတယ်။ Feature Development တွေပြီးတဲ့အခါ Product Owner နဲ့ Development Team တွေ User Acceptance Testing (UAT) ကို အတူတကွ ပြုလုပ်ကြပါတယ်။ QA က အဓိက Test တာဖြစ်နိုင်ပေမယ့် အားလုံးက ပူးပေါင်းလုပ်ဆောင်ကြရတာပါ။ Product (သို့) Feature က UAT လည်းပြီးပြီ၊ Release လုပ်တော့မယ်လို့ စ Plan တဲ့အခါ Alpha Testing နဲ့ Beta Testing အခန်းကဏ္ဍဆီ ရောက်ပါတယ်။ Alpha Testing Alpha Testing ဆိုတာ လွယ်လွယ်ပြောရရင် ကိုယ့်လူနဲ့ကိုယ် အရင်စမ်းသပ်တဲ့ Testing အမျိုးအစားပါ။ မိမိရဲ့ Software

SMART Goal ဘယ်လိုတည်ဆောက်မလဲ

Personal အတွက်ဖြစ်စေ၊ လုပ်ငန်းခွင်မှာဖြစ်စေ.. ရည်မှန်းချက်ကြီးမားတာ ကောင်းပေမယ့် ကိုယ်စိတ်ကူး ပေါ်ရာ ကိုယ်ဖြစ်ချင်ရာ ရည်မှန်းချက်တွေ ရမ်းသမ်းချမှတ်တာက လက်တွေ့မကျတဲ့၊ ချသာ ချမှတ်ထားပြီး အသုံးမဝင် Effective မဖြစ်တဲ့ ရည်မှန်းချက်တွေ ဖြစ်နေနိုင်ပါတယ်။ မဖြစ်နိုင်တဲ့ Goal နောက်ကိုလိုက်ရင်း ရင်းနှီးမြှုပ်နှံရတဲ့ အချိန်တွေ၊ ငွေကြေးတွေ၊ Resource တွေလည်း ဆုံးရှုံးမှုတွေဖြစ်စေနိုင်ပါတယ်။ “SMART Goal ဖြစ်ဖို့တော့ လိုမယ်နော်” ဆိုတဲ့ စကားမျိုး ကြားဖူးကြပါလိမ့်မယ်။ SMART Goal ဆိုတဲ့ concept ကို စီးပွားရေးလောက၊ Marketing အပြင် နယ်ပယ်အသီးသီးမှာ တွင်တွင်ကျယ်ကျယ်အသုံးပြုကြပါတယ်။ SMART Goal ဆိုတာ တိုတိုပြောရရင် တိကျရှင်းလင်းပြီး လက်တွေ့ကျတဲ့ Goal တွေချမှတ်ခြင်းလို့ ပြောနိုင်ပါတယ်။ မိမိ Business အတွက်၊ Product အတွက်၊ Team အတွက်၊ Personal အတွက် Goal တွေ ချမှတ်တဲ့အခါ လက်တွေ့ဖြစ်နိုင်ချေရှိတဲ့ ရည်မှန်းချက်ကို သေချာသတ်မှတ်ပေးနိုင်တဲ့ SMART Objective နည်းလမ်းကို သုံးကြည့်သင့်ပါတယ်။ SMART Goal ဆိုတာက ကိုယ့်ချမှတ်ရေးဆွဲမယ့် Goal တွေက S (Specific) - ဘာကိုရရှိအောင်လုပ်မယ်ဆိုတာ တိတိကျကျဖြစ်ရမယ် M (

Cross-Functional Team အကြောင်း တစေ့တစောင်း

Cross-functional Team ဆိုတာ အပြောလည်းများသလို အသုံးလည်းများပါတယ်။ Product Team တွေမှာလည်း Cross-functional Team ပုံစံကို တော်တော်များများ အသုံးပြုကြပါတယ်။ ProductBaze ဆောင်းပါးအချို့မှာလည်း ထည့်ရေးဖူးပြီး၊ Product Squad ဆောင်းပါးမှာ Squad တည်ဆောက်ပုံက Cross-functional Team ပုံစံကို အခြေခံတဲ့အကြောင်းရေးရင်းနဲ့ Cross-functional Team အကြောင်းလေးကိုပါ မိတ်ဆက်ပေးဖို့ ဖြစ်လာပါတယ်။ ပုံမှန် Organization တွေမှာ Department တွေ, Team တွေက လုပ်ငန်းသဘောသဘာဝ တူညီရာ (Tech, Marketing, Sales, Operation…) စသဖြင့် အသီးသီး ဖွဲ့စည်းထားကြပြီး ဖွဲ့စည်းပုံကလည်း အထက်ကနေ အောက် Hierarchy အတိုင်းဖြစ်ကြပါတယ်။ Decision တစ်ခုလိုအပ်ရင်လည်း Hierarchy အတိုင်း အပေါ်ကို ပြန်တက်ပြီး Request လုပ်ကြရသလို၊​ Company တစ်ခုထဲက Team အသီးသီးက အခြား Department တွေ ဘာလုပ်နေလဲဆိုတာ သိဖို့ ထင်သလောက် မလွယ်ကူပါဘူး။ Silos Team (တသီးတသန့် အလုပ်လုပ်တဲ့ Team) တွေ ဖြစ်လာပြီး Direction တွေ ညှိရခက်တတ်ပါတယ်။ Cross-functional Team ဆိုတာက Organization ထဲမှာ ကျွမ်းကျင်မှုမတူ (သို့မဟုတ်) ဌာနမတူတဲ့ လူတွေကို Team အနေနဲ့ဖွဲ့ပေးပြီး Project တစ်

ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်မလဲ

“Manage My Boss” ဆိုတဲ့ ခေါင်းစဉ်ကြီးဖတ်လိုက်ရလို့ တမျိုးကြီးဖြစ်သွားမယ်ထင်ပါတယ်။ သို့ပေမယ့် ကျွန်တော် အခုပြောပြမယ့် “How to Manage your Boss” က Management အကြောင်း လေ့လာတဲ့အခါတွေမှာလည်း ပါဝင်လေ့ရှိသလို အပြင်လုပ်ငန်းခွင်မှာလည်း တကယ်အရေးပါတဲ့ ကိစ္စရပ်ပါပဲ။ ကိုယ်ကိုယ်တိုင်က Middle Management Level လို့ပြောကြတဲ့ Manager ဖြစ်နေမယ်၊ ကိုယ့်အောက်မှာ Team Members တွေရှိသလို၊ ကိုယ့်အပေါ်မှာလည်း ကိုယ် Report လုပ်ရတဲ့ Senior Manager သော်လည်းကောင်း၊ Head သော်လည်းကောင်း၊ C-Level သော်လည်းကောင်း ကိုယ့် Boss ရှိမယ်ပေ့ါ။ Management Term အရဆိုရင် ကိုယ့် Team ကို Manage လုပ်ရတာကို “Managing Down” or “Downward Management” လို့ ခေါ်ပြီး၊ ကိုယ့် Boss ကို Manage လုပ်တာကို “Managing Up” or “Upward Management”လို့ခေါ်ပါတယ်။ အဲ့တော့ အခုဆွေးနွေးမှာက Upward Management အကြောင်းပါ။ အိုကေ… ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်တာလဲ??? ကိုယ်က Manage လုပ်ခံရမှာမဟုတ်ဘူးလား??? ကိုယ့်အတွက်ရော ဘယ်လို အကျိုးရှိမှာလဲ??? “Boss ကို Manage လုပ်တယ်ဆိုတာ ဘာလဲ” ကနေ စရအောင်ပါ။ Boss ကို Manage လုပ်တဲ့ အဓိက Goal က Boss ကို အပြည

Product Death Cycle ထဲမဝင်မိအောင်

User-centric Product ဖြစ်ဖို့ ကိုယ့် User တွေရဲ့ Feedback တွေကို အမြဲနားထောင်ပြီး လိုအပ်ချက်တွေ ဖြည့်ဆည်းဖို့၊ Product ကို Improve လုပ်သွားဖို့ အရေးကြီးပါတယ်။ ဒါပေမယ့် ကိုယ့် Existing User တွေက အတောမသတ်နိုင်တဲ့ Feature Request တွေ၊ Changes တွေကို တောင်းဆိုနေ၊ Feedback တွေ ပေးနေခဲ့ရင်ရော? ဒါနဲ့ပတ်သက်ပြီး Product သမားတိုင်း သတိထားမိသင့်တဲ့ စိတ်ဝင်စားစရာ Product Death Circle ဆိုတဲ့ Concept အကြောင်းကို ဝေမျှချင်ပါတယ်။ Feature Factory Product နဲ့လည်း ဆက်စပ်နေတာမို့ စိတ်ဝင်စားရင် ProductBaze က ရေးသားခဲ့တဲ့ Feature Factory Product ဆောင်းပါးကို ဖတ်ကြည့်ဖို့ တိုက်တွန်းပါတယ်။ “Product Death Cycle” ဆိုတဲ့ အခေါ်အဝေါ်ကို Silicon Valley မှာရှိတဲ့ နာမည်ကြီး Author နဲ့ Founder ဖြစ်သူ David Bland က Twitter မှာ ဒီပုံလေးတင်ပြီး ဝေမျှခဲ့ရာကနေ စတင်ပါတယ်။ Product မှာ New User တွေ ရဖို့ခက်ခဲနေတယ်၊ ဘယ်သူမှ သိပ်လာမသုံးကြဘူး။ ဒီအခါ ရှိပြီးသား User တွေကို ဘာအဆင်မပြေလို့လဲ၊ ဘာ Feature တွေ လိုအပ်နေလဲ စသဖြင့် Feedback တွေ တောင်းကြလေ့ရှိပါတယ်။ User တွေကပေးတဲ့ Feedback ပေါ်မူတည်ပြီး Product ကို ပြင်ဆင်ကြ