Skip to main content

Feature Factory Product မဖြစ်အောင် သတိထားသင့်တဲ့ Tips များ


Feature Factory Product မဖြစ်ဖို့ ဘာတွေအာရုံစိုက်ကြမလဲ?
Feature Factory Product ဘာလဲနဲ့ ဘာလို့ရေရှည်မှာ မအောင်မြင်နိုင်သလဲ ဆိုတာ အရင် post မှာဆွေးနွေးခဲ့ပါတယ်.. ဒီတစ်ခါ Feature Factory Product မဖြစ်အောင် ဘယ်အချက်တွေကို အာရုံစိုက်သင့်လဲဆိုတဲ့ အသေးစိတ်အချက် ၆ ချက်ကို ဆက်ဆွေးနွေးချင်ပါတယ်။
1. Focus the Customer
  • Feature အသစ်တစ်ခု စတော့မယ်ဆိုရင် ဒါက customer ရဲ့ ဘယ်အခက်အခဲကိုရှင်းပေးဖို့ develop လုပ်တာလဲ၊ ဒီ feature ထပ်ထည့်တာ အကောင်းဆုံး solution လား၊ ရှိပြီးသား feature တွေနဲ့ customer ဘက်မှာ ပိုရှုပ်သွားနိုင်လားဆိုတာ အရင် analysis လုပ်သင့်ပါတယ်။
  • Analysis လုပ်ပြီးမှ develop လုပ်ပေမယ့်လည်း၊ deliver လုပ်တဲ့အခါ customer အသံကိုနားစွင့်တဲ့အနေနဲ့ A/B testing တွေ၊ transaction analysis တွေ၊ user research တွေကို ဆက်လုပ်ဖို့ plan ဆွဲပြီး အကောင်အထည်ဖော်သင့်တယ်။
  • (ဘာလို့ plan ဆွဲပြီးလို့ ထည့်ပြောလဲဆိုရင် လက်တွေ့မှာ အစတည်းက အချိန်ရော၊ resource ရော plan မလုပ်ထားဖြစ်ရင် သေချာတယ် နောက် feature တစ်ခုစဖို့ဆီဘဲ ဦးတည်သွားပြီး customer အသံကိုနားစွင့်ဖို့ဆိုတဲ့ဆီကို ရောက်ဖို့မလွယ်တော့လို့ပါ)

2. Measure the Results
  • Feature တစ်ခု deliver လုပ်လိုက်ပြီးရင် အောင်မြင်တယ်/မအောင်မြင်ဘူး ဘာနဲ့တိုင်းမှာလဲ သတ်မှတ်သင့်၊ အာရုံစိုက်ပြီး တိုင်းတာသင့်ပါတယ်။
  • တိုင်းတာမှလည်း အောင်မြင်တယ်/မအောင်မြင်ဘူးသိနိုင်ပြီး ရည်ရွယ်တဲ့ရလဒ်အထိမရသေးရင် ထပ်ပြီးကောင်းအောင်ဆက်လုပ်သွားရမှာပါ။
  • ဥပမာ - ထည့်လိုက်တဲ့ Feature က လက်ရှိ Customer 20% ကသုံးရင်၊ Conversion Rate 30% ရှိရင် ဒီ feature အောင်မြင်တယ်လို့ ကြိုတင်သတ်မှတ်တာမျိုးပါ။

3. Communication in cross-functional teams
  • Engineering team က feature တစ်ခုကို develop လုပ်လိုက်ယုံနဲ့မပြီးပဲ အခြား marketing team, operation team, customer support team တွေနဲ့ communicate လုပ်သင့်ပါတယ်။
  • Communicate လုပ်တဲ့နေရာမှာ develop မလုပ်ခင်မှာ လိုအပ်တဲ့ input တွေရယူတာ၊ deliver လုပ်တဲ့ အချိန်မှာ demo ပြပြီး feedback ယူတာတွေအပြင်၊ deliver လုပ်ပြီးသွားတဲ့အချိန်မှာ အခြား team တွေအတွက် အဲဒီ feature ကို customer ဆီရောက်အောင် အကောင်းဆုံး support ပေးနိုင်ဖို့ လိုအပ်တဲ့ infomation ပေးတာတွေပါ ပါဝင်ပါတယ်။

4. Celebration of outcome
  • Company အနေနဲ့လည်း ကိုယ့် product team ရဲ့ အောင်ပွဲခံတဲ့အလေ့က feature deliver လုပ်လိုက်တဲ့အချိန်ပဲ မဟုတ်ပဲ အပေါ်ကပြောသလို metrics တွေနဲ့ တိုင်းတာပြီး အောင်မြင်တဲ့အချိန်တွေကိုပါ အာရုံစိုက်သင့်ပါတယ်။
  • Product team ရဲ့ အောင်မြင်မှုကိုတိုင်းတာတဲ့အချက် KPI တွေမှာလည်း metrics တွေ ထည့်စဥ်းစားသင့်ပါတယ်။
  • (အဲဒါမှလည်း product team က deliver လုပ်လိုက်တဲ့ feature ကို ပိုကောင်းတဲ့ ရလဒ်ရဖို့ စဥ်ဆက်မပြတ်အားထုတ်မှာ ဖြစ်ပါတယ်၊ နောက် sprint တွေမှာ လိုတာတွေကို iterative ပြန်လုပ်သွားတာကို ဆိုလိုတာပါ)

5. Remove the unnecessary
  • Deliver လုပ်ခဲ့တဲ့ Features တွေ မအောင်မြင်ခဲ့ရင် ပြန်ဖြုတ်ဖို့ ပြန်ရှင်းဖို့လည်း ထည့်စဥ်းစားသင့်ပါတယ်။
  • (customer သိပ်မသုံးတဲ့ features တွေကို ဒီတိုင်းဆက်ထားရင် ရှုပ်ပွနေတဲ့ product ဖြစ်ရုံအပြင် ပိုကောင်းစရာမရှိပါဘူး၊ အသုံးလည်းမဝင်ပဲ ထားထားလို့ technical maintenance နဲ့ operation က support လုပ်ရတဲ့ ဝန်ပဲ ပိုပါလိမ့်မယ်)

6. Roadmap and Prioritization
  • Product ကို review မလုပ်ပဲ roadmap ထဲမှာရှိနေတဲ့ features တွေကို တစ်ခုပြီးတစ်ခု deliver လုပ်ဖို့ပဲ အာရုံစိုက်ပြီး prioritize လုပ်တာက product manager ရဲ့ goal မဟုတ်သင့်ပါဘူး။
  • Roadmap ရဲ့ features ကိုပဲ အာရုံစိုက်တာထပ် တကယ့် customer တွေ ဖြစ်နေတဲ့ လက်ရှိအခက်အခဲတွေ၊ လိုအပ်ချက်တွေကို ကြို plan ထားတဲ့ roadmapကြီး ရဲ့ features တွေထပ် ပိုအရေးကြီးလားပါ အမြဲစဥ်းစားပြီး deliver လုပ်သင့်ပါတယ်။

အချုပ်ပြောရရင်တော့ Feature Factory Product မဖြစ်ဖို့ Product တစ်ခုမှာ features အရေအတွက်ထပ် ရလဒ်ကို ဦးစားပေးပြီး customer တွေ ​ရေရှည်မှာ အသုံးဝင်တဲ့ features တွေပဲ ပေးသွားဖို့ပဲ ဖြစ်ပါတယ်။
Feature Factory Product နဲ့ ပတ်သက်တဲ့ ကိုယ့်အတွေ့အကြုံတွေ၊ တွေးမိတာတွေကို အောက်က Comment ထဲမှာ ‌‌‌‌‌ဝေမျှပေးစေချင်ပါတယ်။ Product သမားအချင်းချင်း idea တွေ၊ knowledge နဲ့ experience တွေ share ဖို့ နွေးနွေးထွေးထွေးဖိတ်ခေါ်ပါတယ်။ နောက်ထပ် Post တွေမှာ product management နဲ့ ပတ်သက်တဲ့ ဘယ်လို topic တွေဖတ်ချင်လဲဆိုတာ ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။
ProductBaze အကြောင်း (၁) မိနစ်စာ မိတ်ဆက် post လေးကို ဒီ link မှာ ဖတ်လို့ရပါတယ်။ ProductBaze ကို ဆက်သွယ်ချင်ရင် productbaze@gmail.com သို့ ပေးပို့ ဆက်သွယ်နိုင်ပါတယ်။
Labels:

Comments

Post a Comment

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 (
Post a Comment
Read more

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 တစ်
Post a Comment
Read more

ကိုယ့် 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 ကို အပြည
Post a Comment
Read more

အသုံးများတဲ့ 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
Post a Comment
Read more

၅ မိနစ်စာ 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,
Post a Comment
Read more