Skip to main content

Product Feature တွေကို ဘယ်လို Prioritize လုပ်မလဲ

Feature Prioritization ဆိုတာ မိမိ Product မှာ ထပ်ထည့်ရမယ့် Features တွေ၊ Backlog ထဲက Major Epic တွေ၊ User Stories တွေကို ဘယ်ဟာတွေက အရင်ဆုံးလုပ်ရမယ့် အရေးအကြီးဆုံးလဲ ရွေးချယ် သတ်မှတ်တဲ့ အလုပ်ဖြစ်ပါတယ်။ Product ရဲ့ ရှေ့ဆက်သွားမယ့် Roadmap ဆွဲဖို့ရာအတွက် Features တွေကို Prioritize လုပ်ရတာ Product Manager ရဲ့ အရေးပါတဲ့ တာဝန်တွေထဲက တစ်ခုပါ။

Product အတွက် မှန်ကန်သင့်တော်တဲ့ Features တွေကို ရွေးချယ်ရတာ ထင်သလောက် မလွယ်ကူပါဘူး။ မိမိစိတ်ထဲမှာ ဒီ Feature လုပ်သင့်တယ်ထင်ရုံနဲ့ ရွေးချယ်လို့မရသလို တစ်ယောက်ယောက်က တောင်းဆိုလို့ ဆိုတာမျိုးနဲ့လည်း ရွေးချယ်ဖို့ မလုံလောက်ပါဘူး။ Product Decisions အတွက် Product နဲ့ ဆက်စပ်နေတဲ့ Stakeholders တွေရဲ့ Input တွေ ထည့်သွင်းစဥ်းစားဖို့ လိုအပ်သလို၊ Product ရဲ့ Data တွေကို ကြည့်ဖို့လည်း လိုအပ်ပါတယ်။ Data တွေ Input တွေ စုဆောင်းပြီးတဲ့အခါ Features တွေကို ရွေးချယ်ဖို့ သင့်တော်တဲ့ Method တွေ၊ Matrix တွေကို အသုံးပြုနိုင်ပါတယ်။


Product အတွက် Feature Prioritization လုပ်ရမှာ အသုံးတဲ့ပြီး လွယ်ကူတဲ့ Method / Matrix အချို့ကို ဝေမျှချင်ပါတယ်။ ကိုယ့် Product ပေါ်မူတည်ပြီး သင့်တော်မယ့် Method ကို စမ်းသုံးကြည့်ဖို့လည်း အကြံပြုချင်ပါတယ်။
  • Value Effort Matrix (Value Cost Matrix)
  • Scoring Method
  • Weighted Scoring (Scorecard)
  • MOSCOW Analysis
  • Story Mapping

(1) Value Effort Matrix (သို့) Value Cost Matrix ဆိုတာ Features တွေကို Business Value နဲ့ Effort ပေါ်မူတည်ပြီး Priority သတ်မှတ်တာဖြစ်ပါတယ်။ ဒီနည်းလမ်းအတွက် မိမိ Product မှာရှိတဲ့ Features တွေ Idea တွေ တစ်ခုချင်းစီကို Develop လုပ်ရင်ရမယ့် Value နဲ့ စိုက်ထုတ်ရမယ့် Team Effort သတ်မှတ်ပြီး Grid ပေါ်မှာ နေရာချရပါတယ်။ Grid ရဲ့ Y ဝင်ရိုးက Business Value ဖြစ်ပြီး X ဝင်ရိုးကတော့ Effort ဖြစ်ပါတယ်။ Effort အစား Cost, Complexity စတာတွေလည်း သုံးနိုင်ပါတယ်။ နေရာချပြီးရင်တော့ အောက်မှာပြထားတဲ့ ပုံထဲကအတိုင်း
  • နံပါတ် 1 က Value အများဆုံးပေးပြီး Effort နည်းနည်းနဲ့ ပြီးနိုင်တာမို့ လုပ်ကိုလုပ်ရမယ့် Features တွေ၊
  • နံပါတ် 2 က လုပ်သင့်တဲ့ Features တွေ၊
  • Question Mark က သိပ်အရေးမကြီးတဲ့ လုပ်သင့်/မလုပ်သင့် မသေချာသေးတဲ့ Features တွေ၊
  • နောက်ဆုံးကတော့ "No"…. Value ရမှာလည်းနည်း Effort လည်းများလို့ မလုပ်တော့မယ့် Features တွေဆိုပြီး သတ်မှတ်တာဖြစ်ပါတယ်။

(2) Scoring Method မှာ Features တွေကို Factors တွေပေါ်အခြေခံပြီး သက်ဆိုင်ရာ Scoring Formula တစ်ခုခုနဲ့ တိုင်းတာတဲ့နည်းလမ်းပါ။ အသုံးများတဲ့ Formula အချို့ကို အောက်မှာနမူနာပြထားပါတယ်။
RICE Scoring က Reach, Impact, Confidence, Effort တို့ကိုရည်ညွှန်းတာဖြစ်ပြီး Reach က သတ်မှတ်တဲ့ အချိန်အတိုင်းအတာတစ်ခုမှာ Feature က သက်ရောက်မယ့်လူအရေအတွက်ပါ။ Impact က Feature ကြောင့် ဘယ်လိုသက်ရောက်မှုတွေရှိတာလဲနဲ့ Confidence က ဒီခန့်မှန်းမှုအတွက် ဘယ်လောက်သေချာမှုရှိလဲပါ။ Effort ကတော့ Cost တွေ၊ Resource တွေ ပါဝင်မှာပါ။
ICE Scoring နဲ့ RICE Scoring ကွာတာက Reach ပမာဏဖြစ်ပါတယ်။ သက်ရောက်မှု အနည်းအများပဲမဟုတ်ပဲ သက်ရောက်မှာက လူနည်းနည်းကို သက်ရောက်မှု အကြီးကြီးလား၊ လူအများကြီးကို သက်ရောက်မှု နည်နည်းလေးလား စသည်ဖြင့် ရှင်ရှင်းလင်းလင်းသိစေဖို့ ဖြစ်ပါတယ်။
BUC ကတော့ Business နဲ့ User Value တွေကို (1-10) သတ်မှတ်၊ Value Score နှစ်ခုကိုပေါင်းပြီး Cost ကို ပြန်နှုတ်တာ ဖြစ်ပါတယ်။
(3) Weighted Scoring (Scorecard) က Scoring Method လို Factors တစ်ခုချင်းစီအတွက် Features ကိုအမှတ်ပေးရုံတင်မဟုတ်ဘဲ Factors တွေကိုပါ Weight ပြန်သတ်မှတ်တာပါ။ Factors အားလုံးပေါင်းကို 100% ထားပြီး ဘယ် Factor က ကိုယ့် Product အတွက် ဘယ်လောက် အရေးပါလဲကို ရာခိုင်နှုန်းပြန်ခွဲတာ ဖြစ်ပါတယ်။ အောက်ကပုံကိုကြည့်ရင် ပိုရှင်းပါလိမ့်မယ်။ Factors ရဲ့ အရေးပါမှု ရာခိုင်နှုန်းပေါ်မူတည်ပြီး Features ရဲ့ Priority Score ကို တွက်တာဖြစ်ပြီး အသုံးများတဲ့ နည်းလမ်းဖြစ်ပါတယ်။




(4) MOSCOW Analysis ကလည်း Management, Business Analysis, Software Development, Product Management စတာတွေမှာ အသုံးများတဲ့ နည်းလမ်းဖြစ်ပါတယ်။ Product အတွက် Features တွေကို
  1.  Must Have - မဖြစ်မနေရှိရမယ့် Feature
  2.  Should Have - ရှိသင့်တယ့် Feature
  3.  Could Have - အချိန်ရော Resource ရောရှိရင်တော့ လုပ်သင့်တယ့် Feature
  4.  Won’t Have - လောလောဆယ်မှာ Product အတွက် ရှိဖို့ကို မလိုအပ်တဲ့ Feature
ဆိုပြီး Categories ၄ ခုအောက်ထဲကို ခွဲထည့်တဲ့ နည်းလမ်းပါ။ ဒီလို Categories တွေနဲ့ ခွဲလိုက်ခြင်းအားဖြင့် ရှေ့လျှောက် Product အတွက် ဘာကို အရင်ဆုံး Develop လုပ်ရမယ်ဆိုတာ ရှင်းရှင်းလင်းလင်း သိစေနိုင်ပြီး အရေးကြီးတဲ့ Features တွေကို Stakeholders တွေနဲ့ ဆွေးနွေးရာမှာလည်း နားလည်လွယ်စေလို့ အသုံးများတဲ့ Method ဖြစ်ပါတယ်။

(5) Story Mapping က ကျွန်တော့်ရဲ့ Personal Favourite နည်းလမ်းလည်းဖြစ်ပါတယ်။ Agile Product Team တွေမှာ အသုံးများပြီး MVP (Minimum Viable Product) ဖြစ်ဖို့ရာ ပါသင့်တဲ့ User Stories တွေကို Prioritize လုပ် Release တွေသတ်မှတ်တာမျိုးပါ။ Story Mapping မှာ Product ရဲ့ Wrokflow တစ်ခုလုံးကို Breakdown လုပ်တာမို့ Product ရဲ့ User Journey အစအဆုံးကိုလည်း Product Team အနေနဲ့ မြင်လွယ်ပါတယ်။ Wrokflow ကို Breakdown လုပ်ရာမှာ User Story အစ-အဆုံးကို Card တစ်ခုချင်းစီမှာ ချရေးပြီး Kanban Board လိုမျိုးမှာ (Sticky Notes နဲ့ နံရံပေါ်မှာကပ်တာ အဆင်ပြေပါတယ်) အစဥ်လိုက် အရေးအကြီးဆုံး User Story ကထိပ်ဆုံး သိပ်အရေးမကြီးတာက အောက်ဆုံး စီသွားတာပါ။ စီထားတဲ့ အစဥ်လိုက်ကို ဘယ် Features အထိက Primary Step မှာ Develop လုပ်မယ်၊ ဘယ် Features တွေကတော့ နောက် ဘယ် Relase တွေမှာ Develop လုပ်သွားမယ်ဆိုတာ ပိုင်းလိုက်တာဖြစ်ပါတယ်။

Feature Prioritization အတွက် အဓိက ပြုလုပ်ထားတဲ့ ProductPlan, Aha စတဲ့ Tools တွေရှိပါတယ်။ သို့ပေမယ့် Product Managers တော်တော်များများကတော့ Trello, Jira တို့လို ရိုးရှင်းတဲ့ Tools တွေနဲ့ Data စုဆောင်းပြီး Spreadsheet ပေါ်မှာပဲ Matrix တွေဆွဲ၊ Scoring တွေတွက်ပြီး Prioritize လုပ်ကြတာ ပိုများပါတယ်။

Feature Prioritization က Roadmap အတွက်တစ်ကြိမ်ပဲ လုပ်ရတာမဟုတ်ပါဘူး။ Business ရဲ့ Priorities တွေက External Factors တွေ Internal Factors တွေပေါ်မူတည်ပြီး အလျင်အမြန် ပြောင်းလဲနိုင်ပါတယ်။ External Factors ဆိုတာ Market Demand, Competitors စတာတွေဖြစ်ပြီး Internal Factors ကတော့ Company Vision အပြောင်းအလဲ၊ Organization Structure နဲ့ Resource အပြောင်းအလဲ စတာတွေဖြစ်ပါတယ်။ Agile Product Team ကလည်း ဒီအပြောင်းအလဲတွေကို အလျင်အမြန် Adpat လုပ်ဖို့လိုပါတယ်။ ဒါ့ကြောင့် Product Manager တစ်ယောက်အနေနဲ့ အမြဲမပြတ် Roadmap ကို ပြန်လည်သုံးသပ်သင့်ပြီး လိုအပ်လာရင် ရှေ့လာမယ့် Sprint တွေအတွက် Features တွေကို အကောင်းဆုံး Prioritize ပြန်လုပ်ရမှာ Product Manager ရဲ့တာဝန်ဖြစ်ပါတယ်။

Feature Prioritization နဲ့ပတ်သက်ပြီး ထပ်သိချင်တာ ရှိရင်လည်း မေးနိုင်ပါတယ်။ မိမိတို့ လက်ရှိသုံးနေတဲ့ Method တွေ၊ အသုံးဝင်တဲ့ Tips တွေရှိရင်လည်း share ခဲ့ပါဦး။

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

Comments

Popular Posts

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 (

ကိုယ့် 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 ကို အပြည

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

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

၅ မိနစ်စာ 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,