Skip to main content

Product Manager တစ်ယောက်ရဲ့ Balance ချိန်ညှိခြင်း အနုပညာ

Product Management က Customer (UX), Business နဲ့ Tech ဆိုတဲ့ ကဏ္ဏသုံးခုကြားမှာနေပြီး တစ်ခုနဲ့တစ်ခု အချိတ်အဆက်မိတဲ့ Product ကောင်းဖြစ်အောင် Communicate လုပ်ပေးရတဲ့ အလုပ်ဖြစ်ပါတယ်။

Product Manager ဖြစ်ဖို့ Digital Product မို့ Tech Background ရှိတဲ့သူပဲ ဖြစ်ရမယ်ဆိုတာမျိုး၊ Product ရဲ့ Industrial Knowledge ရှိတဲ့သူပဲ ဖြစ်ရမယ်ဆိုတာမျိုး မသတ်မှတ်ထားကြပါဘူး။ Product Manager တွေက Career အမျိုးမျိုးက လာကြပါတယ်။ အစမှာ ပြောခဲ့သလို Customer (UX), Business နဲ့ Tech ဆိုတဲ့ အပိုင်း သုံးခုနဲ့ ချိတ်ဆက်ရသူမို့ Business / Market ကို ကောင်းကောင်းသိတဲ့သူလည်း ဖြစ်နိုင်ပါတယ်၊ UI/UX ကျွမ်းတဲ့ Design ဘက်ကသူလည်း ဖြစ်နိုင်ပါတယ်၊ Software Developer, QA Engineer, System Analyst စတဲ့ Technical Background ရှိသူတွေဖြစ်နိုင်သလို၊ အဲဒီတွေထဲက လုံးဝမဟုတ်တဲ့သူလည်း ဖြစ်နိုင်ပါတယ်။


ဘယ် Background ကပဲ လာလာ၊ Product Manager က ဒီကဏ္ဏသုံးခုလုံးနဲ့ အမြဲမပြတ် ဆက်စပ်နေရတာဖြစ်လို့ သူတို့နဲ့ ပတ်သက်တဲ့ Knowledge တွေ ရှိဖို့လိုအပ်တာ အမှန်ပါပဲ။

ဒါ့အပြင် အဲဒီ Customer (UX), Business နဲ့ Tech... သုံးခုလုံးက မိမိ Product အတွက် အရေးပါတာမို့ တစ်ခုချင်းစီပေါ်ထားတဲ့ Focus ကို Balance ညီအောင် ချိန်ညှိဖို့ကလည်း အရေးကြီးပြန်ပါတယ်။ Product Manager က မိမိ ပိုကျွမ်းကျင်တဲ့၊ Background Knowledge ပိုများတဲ့ အပိုင်း တစ်ပိုင်းထဲကိုပဲ ဦးစားပေးကြည့်တာမျိုး မဖြစ်အောင် သတိပြုရမှာပါ။ ဒါကြောင့် Balance ညှိချင်းက Product Manager အတွက် တော်တော်လေး အရေးပါပါတယ်။

ဘာလို့အရေးကြီးတာလဲဆိုတာ မြင်သာအောင် ဥပမာပြောရရင် –
  • PM က Customer Experience (UX) မှာ အားသာတဲ့အတွက် Customer လိုအပ်ချက်နဲ့ User Experience ကိုပဲ ဦးစားပေးနေပြီး ကိုယ့် Company ရဲ့ Business Vision နဲ့ ကိုက်/မကိုက်၊ Tech ဘက်က Develop လုပ်ဖို့ ဖြစ်နိုင် / မဖြစ်နိုင်၊ သင့်တော် / မသင့်တော် စတာတွေကို အာရုံမစိုက်မိတော့ပဲ ဖြစ်တတ်ပါတယ်။
  • PM က Business မှာ ပိုအားသာပြီး Business Vision အတိုင်းရောက်အောင် သွားနေတယ်၊ Competitor, Market Share, Revenue စတာတွေပဲ အာရုံစိုက်နေတယ်၊ ကိုယ့် Target Customer နဲ့ မကိုက်တာ၊ ကိုယ့် Product က တကယ်ပေးချင်တဲ့ Value ပျောက်ပြီး ရောသမမွှေ Product ဖြစ်လာတာ စတာတွေကို အာရုံမစိုက်မိ ဖြစ်တတ်ပါတယ်။
  • PM က Development မှာ ပိုအားသာပြီး ကျန်တဲ့ နှစ်ဖက်မှာ အားနည်းရင်လည်း Tech Team က ဆက်လုပ်မယ်လို့ သတ်မှတ်ထားတဲ့ Feature တွေကိုပဲ Develop လုပ်ဖို့အဆင်ပြေ/မပြေ သာ အာရုံစိုက်နေမယ်၊ ဘယ်လို Develop လုပ်ကြမယ် (How) တွေကို အာရုံစိုက်နေမယ်၊ နှစ်အစမှာ ချခဲ့တဲ့ Roadmap က နှစ်ကုန်လောက်မှာ Market အပြောင်းအလဲတွေကြောင့် Develop မလုပ်သင့်တော့လည်း PM အနေနဲ့ သတိမထားမိဘဲ တစ်ခုပြီး တစ်ခု Develop လုပ်ဖို့သာ အားသန်နေမယ် စတာမျိုးတွေ ဖြစ်တတ်ပါတယ်။
အဲ့လိုတွေ တစ်ဖက်ထဲကိုပဲ အာရုံမစိုက်မိအောင် သတိပြုမိဖို့အတွက်က မိမိအနေနဲ့ ဘယ်အပိုင်း အားသာလဲ၊ ဘယ်အပိုင်း အားနည်းလဲ သိမှသာ Balance ညှိနိုင်မှာပါ။ Product Manager တစ်ယောက်က စစချင်းမှာ ကဏ္ဏသုံးခုလုံးကို ကောင်းကောင်းသိဖို့၊ ကျွမ်းကျင်ဖို့ မလွယ်ပါဘူး။ ပထမဆုံးအနေနဲ့ မိမိ ကျွမ်းကျင်တဲ့ Background က ဘာလဲ၊ မိမိပို စိတ်ဝင်တစားရှိနေတဲ့ အပိုင်းက ဘာလဲ၊ မိမိ အားနည်းတဲ့ အပိုင်းက ဘာလဲဆိုတာတွေ သိဖို့လိုပါတယ်။

ဒါ့အပြင် Product Manager တစ်ယောက်လေ့လာရမယ့် အပိုင်းတွေထဲမှာ Communication နဲ့ Leadership Skills လို Soft Skills တွေလည်း ရှိပါသေးတယ်။ Product အတွက် အပိုင်း သုံးပိုင်းလုံးကို သိနားလည်ဖို့ အာရုံစိုက်နေပေမယ့် အဲ့ဒီလူတွေနဲ့ Communicate လုပ်ဖို့၊ Lead လုပ်ဖို့မှာ အားနည်းနေလို့လည်း အလုပ်မဖြစ်ပြန်ပါဘူး။​ ဒါက Product Manager အတွက် နောက်ထပ် ချိန်ညှိရမယ့် Balance ပဲ ဖြစ်ပါတယ်။ ဒီနှစ်ခုမှာက တစ်ခုခုက အားသာနေလို့ ကိစ္စမရှိပေမယ့် တစ်ခုခုက အရမ်းအားနည်းသွားရင် Product Manager ရဲ့ နေ့စဥ်လုပ်ငန်းဆောင်တာတွေမှာ အတားအဆီးဖြစ်နိုင်ပါတယ်။

Product Manager အနေနဲ့ မိမိရဲ့ အားသာချက်၊ အားနည်းချက်တွေကို Product Area သုံးခု (Business, Customer, Tech) နဲ့ ပတ်သက်တဲ့ Knowledge ရော၊ Soft Skills အပိုင်းမှာရော ဆန်းစစ်ပြီးရင်တော့…. အဲ့ဒါတွေကို အားဖြည့်ဖို့ မိမိနဲ့ သင့်တော်တဲ့ နည်းလမ်းကိုရွေးပြီး လေ့လာရတော့မှာဖြစ်ပါတယ်။
  • လိုအပ်တဲ့ သင်တန်းတွေကို သင်တန်းကျောင်းတွေမှာ တက်မလား (Certificate, Diploma, Master စသည်)
  • Online Course တွေ တက်မလား
  • စာအုပ်တွေ Blog တွေ ဖတ်မလား
  • လက်ရှိ Product Manager တွေနဲ့ လှမ်းချိတ်ဆက်ပြီး သူတို့ဆီက လေ့လာမလား (eg. Linkedin ကနေတဆင့်၊ Meetup တွေကနေတဆင့်)
  • အလုပ်ကနေပဲ တဖြည်းဖြည်း လေ့လာသင်ယူသွားမလား
စသဖြင့် မိမိနဲ့ ကိုက်ညီသင့်တော်တဲ့ နည်းလမ်းကို ရွေးနိုင်ပါတယ်။

အချုပ်ပြောရရင်တော့ Product Manager က မိမိ အားသာချက်တွေကို ကောင်းကောင်းအသုံးချရင်းနဲ့ မိမိအားနည်းတဲ့အပိုင်းတွေမှာ မလစ်ဟာသွားအောင်၊ တစ်ဖက်စောင်းနင်း မဖြစ်သွားအောင် သတိပြုရင်း လိုအပ်တဲ့ Skills တွေနဲ့ Knowledge တွေကို အမြဲမပြတ် သင်ယူသွားသင့်ပါတယ်။

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

- - -

Product Manager ကောင်းတစ်ယောက်ဖြစ်ဖို့၊ မိမိကိုယ်ပိုင် Product တစ်ခုကို တည်ဆောက်ဖို့ Product Management နဲ့ပတ်သက်ပြီး မဖြစ်မနေလိုအပ်တဲ့ Knowledge တွေ၊ Skills တွေကို ProductBaze ရဲ့ Product Management Foundation Course မှာ လေ့လာနိုင်ပါတယ်။ Online Course ဖြစ်ပြီး လေ့လာရုံတင်မကဘဲ Learn by Doing စနစ်နဲ့ Product တစ်ခုလည်း ကိုယ်တိုင် တည်ဆောက်ရမှာဖြစ်ပါတယ်။

Follow us on Facebook and Linkedin for the latest updates.

Comments

Popular Posts

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 တစ်

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 (

အသုံးများတဲ့ 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

Business Model Canvas ဘယ်လိုဆွဲမလဲ

Business တစ်ခု (သို့) Product တစ်ခုအတွက် Business Model Canvas (BMC) ဘယ်လိုဆွဲမလဲ? BMC ဘယ်လိုဆွဲမလဲကို မသွားခင်မှာ BMC ဆိုတာဘာလဲ နဲ့ ဘယ်လိုအသုံးဝင်လဲ ဆိုတာကို အရင်လေ့လာကြည့်ရအောင်။ Business Model Canvas ( BMC ) ရဲ့ Definition က “အောင်မြင်တဲ့ Business တစ်ခု စတင်ဖို့ လိုအပ်မယ့် ရင်းနှီးမြှုပ်နှံမှု” ၊ ဝင်ငွေဘယ်ကရမလဲ နဲ့ “မိမိရဲ့ဖောက်သည်က ဘယ်သူတွေလဲ” ဆိုတာတွေကို အကျဥ်းချုပ် ချစွဲထားတဲ့ အစီအစဥ် (Plan) တစ်ခု ” ဖြစ်ပါမယ်။ စီးပွားရေးလုပ်ငန်းရှင်တွေအနေနဲ့ Business တစ်ခု (သို့) Product တစ်ခုမစခင် အဲဒီ Business ကို ဘယ်လိုအကောင်အထည်ဖော်မလဲဆိုတာ မြင်သာအောင်ဆွဲတတ်ကြပြီး ကျွန်တော်တို့လို Product Manager တွေအတွက်လည်း Management နဲ့ဖြစ်စေ၊ တခြား Stakeholders တွေနဲ့ ဖြစ်စေ Communicate လုပ်ရာမှာ နားလည်လွယ်ပြီး အသုံးဝင်ပါတယ်။ ဘာကြောင့် BMC ကို ဆွဲကြတာလဲ ကျွန်တော်တို့အတွက် BMC က နားလည်ရလွယ်တယ် တိုတိုနဲ့ ရှင်းရှင်းလင်းလင်းရှိတယ် ပြင်လွယ်ပြောင်းလွယ်တယ် Customer, Business, Partners နဲ့ Business Activities တွေအချိတ်အဆက်မိမိ မြင်သာတယ် ကဲ… BMC ရဲ့ What နဲ့ Why ကို သိပြီဆိုတော့ ဘယ်လိုဆွဲကြမ

၅ မိနစ်စာ Product Roadmap

Product တစ်ခုစလုပ်ရင် အလိုအပ်ဆုံးက Product Roadmap လို့ပြောလို့ရမယ်။ Product Roadmap က မိမိ လုပ်မယ့် Product အကြောင်း Overview ပြောပြပေးနိုင်သလို၊ မိမိ Product Goal တွေကို ဘယ်လိုရောက်အောင် လျှောက်မလဲဆိုတာကို ချပြပေးလို့ပါပဲ။ Product Roadmap မရှိရင် ကိုယ်ထင်ရာ လုပ်မိနေနိုင်ပြီး မိမိ Goals တွေကို လက်လှမ်းမမှီနိုင်ဖြစ်သွားလိမ့်မယ်။ Product Roadmap ရှိတော့ ကိုယ့် Team Member တွေဖြစ်ဖြစ်၊ CEO ဒါမှမဟုတ် Investor တွေနဲ့ပဲပြောပြော အသုံးဝင်ပါလိမ့်မယ်။ ဒါဆို Product Roadmap ဘယ်လိုဆွဲရမလဲလို့မေးမယ် ။ အလုပ်အဖြစ်ဆုံး Product Roadmap Template ဆိုပြီးတော့မရှိပါဘူး။ မိမိ Roadmap ကို ကြည့်မယ့်လူပေါ်မူတည်ပြီး Roadmap ဒီဇိုင်းတွေကပြောင်းလဲရပါမယ်။ ဥပမာ… CEO က Timeline တွေနဲ့ ဘယ်နေ့ဘာ Feature ပြီးမှာလဲကို ကြည့်ချင်နေတဲ့အချိန် ကိုယ်က Feature List ပဲ သွားပြလို့မရပါဘူး။ Template မရှိပေမယ့် ဒီနေရာမှာ Share ပေးချင်တာက ကျွန်တော့် အတွက် အလုပ်ဖြစ်ခဲ့တဲ့ Roadmap Key Components တွေနဲ့ တခြား popular ဖြစ်တဲ့ Product Roadmap တွေကို ဝေမျှပေးသွားပါမယ်။ Product Roadmap မှာ အတွေ့အများဆုံးက Quarterly Roadmap (Q1,