Skip to main content

Customer Interview မှာ ဆောင်ရန်၊ ရှောင်ရန်များ

Product Development လုပ်ငန်းစဥ်တွေထဲမှာ ကျွန်တော်တို့ချန်မထားသင့်တာက Customer နဲ့ တိုက်ရိုက်ထိတွေ့ပြီး Feedback ရယူတဲ့အပိုင်း ဖြစ်ပါတယ်။ Product Manager တစ်ယောက်အတွက် Features တွေ အသစ်လုပ်ရင်လည်း အမြန်ဆုံး ပြေးတွေ့သင့်တာကတော့ မိမိ Product တွေကို သုံးနေတဲ့ Customers တွေပါဘဲ။ Customer Interview က Product Research အတွက် အလွန် အသုံးဝင်တဲ့ နည်းလမ်းဖြစ်ပြီး အခွင့်သင့်မှ မဟုတ်ပဲ Product Development တောက်လျှောက် ပုံမှန်လုပ်ဆောင်သင့်ပါတယ်။

Customer Interview လုပ်တဲ့အခါ မိမိလိုချင်တဲ့ Feedback တွေ၊ အဖြေတွေကို ရအောင်ရှာနိုင်ဖို့က အရေးကြီးဆုံးပါ။ ဒီအတိုင်း ထိုင်ပြီး စကားပြောနေရင်တော့ လက်ဘက်ရည် စကားဝိုင်းဘဲ ဖြစ်သွားပါမယ်။ ဒီဆောင်းပါးမှာ Customers တွေနဲ့ ထိတွေ့ရာမှာ လိုအပ်တဲ့ ဆောင်ရန်၊ ရှောင်ရန်များကို ဆွေးနွေးသွားပါမယ်။


Customer တစ်ယောက်ဆီက အကောင်းဆုံး Signal (Information) တွေရဖို့ Interview တစ်ခု ဘယ်လိုလုပ်ရမလဲဆိုတာ အရင်ဆုံး သိဖို့လိုပါတယ်။ ထိုင်ပြီး မိမိ Product အကြောင်းဘဲ Pitch (ထိုင်ဆွေးနွေး) နေရင် မိမိလိုချင်တဲ့ တိကျတဲ့ အဖြေကိုမရနိုင်ပါဘူး။ Customer Interview လုပ်ရခြင်းရဲ့ အဓိက အကြောင်းရင်းက မိမိ Customers တွေရဲ့ နေ့စဥ်တွေ့ကြုံနေရတဲ့ အခက်အခဲ၊ လိုအပ်ချက်တွေ ကို ဖော်ထုတ်ဖို့ပါ။ မိမိ Product ကို တစ်ချိန်လုံး Marketing ဆင်းဖို့မဟုတ်ပါဘူး။

၁။ သက်တောင့်သက်သာနေပါ။
အရင်ဆုံး လုပ်သင့်တာကတော့ Customer နဲ့ မိမိ ကြားမှာ ရင်းနှီးအောင်နေဖို့ပါ။ ပထမဆုံးအကြိမ် Customer နဲ့ မေးထူးခေါ်ပြော လုပ်ရမှာဆိုတော့ ရှက်တာတွေ၊ တွန့်ဆုတ်တာတွေမဖြစ်အောင် နေရပါမယ်။ လူစိမ်းတစ်ယောက်ဖြစ်နိုင်ပေမယ့် ကိုယ်နဲ့သိကျွမ်းဖူးတဲ့ လူပုံစံဖြစ်အောင် အရင်ကြိုးစားပါ။ တွေ့တာနဲ့ Interview တန်းမမေးမိအောင် ဆင်ခြင်ပါ။ ကိုယ့်ကိုကိုယ် အရင် မိတ်ဆက်ပါ။ သူ့အကြောင်း နားထောင်ပါ။ နှစ်ဘက် သက်တောင့်သက်သာဖြစ်မှ Interview စတာက မိမိလိုချင်တဲ့ Feedback တွေရဖို့ ပိုလွယ်ကူပါလိမ့်မယ်။ တစ်ခါတစ်လေ Negative Feedback ရရင်တောင် ဒေါသမဖြစ်သွားပါနဲ့။ ကိုယ့် Product ကို စိတ်ထဲရှိလို့ အချိန်ပေးပြီး မကောင်းတဲ့အချက်ကို ထောက်ပြနေတာမို့ ကျေးဇူးတင်ရမှာပါ။ စိတ်ထဲရှိသမျှ မကျေနပ်တာတွေပြောရင်တောင် နားထောင်ပေးသင့်ပြီး.. ဒီအနေအထားက Customer နဲ့ ကိုယ်ကြားမှာ ရင်းနှီးမှုနဲ့ ယုံကြည်မှုကို ဖြစ်ပေါ်စေလို့ လိုချင်တဲ့ အဖြေတွေရမှာ သေချာပါတယ်။

၂။ Customer ကို စကားပေးပြောပါ။
တစ်ခါတစ်ခါ ကျွန်တော်တို့ သတိမထားမိတဲ့ အကြောင်းအရာကတော့ မိမိက စကားအများကြီး ပြောနေမိခြင်းပါ။ Customer Interview တစ်ခုလုပ်ရင် မိမိက မေးခွန်း မေးတဲ့ လူ၊ Customer က မေးခွန်းဖြေတဲ့လူ ဖြစ်ပါတယ်။ တစ်ခါတစ်လေ စကားပြောကောင်း၊ အားတွေ၊ မာန်တွေ ပါသွားပြီး ကိုယ်ကပဲ မေး၊ ကိုယ်ကပဲ ဖြေသွားတာမျိုးတွေ လုပ်မိတတ်တာကို သတိထာသင့်ပါတယ်။ Interview တစ်ခုလုံးရဲ့ ၉၅ ရာခိုင်နှုန်းက Customer တွေကို ပေးပြောသင့်ပြီး၊ ၅ ရာခိုင်နှုန်းသာ မိမိ ပြောနိုင်အောင် ကြိုးစားကြည့်ပါ။ အများကြီးတွေ ပြောခိုင်းတော့ တစ်ခါတစ်လေ အကြောင်းအရာလွဲ (Off-topic) ဖြစ်သွားရင်ကော ဘယ်လိုလုပ်မလဲ လို့မေးစရာရှိပါတယ်။ စိတ်မပူသင့်ပါဘူး။ သူတို့ရဲ့ ကိုယ်မသိသေးတဲ့ အခက်အခဲတွေ ကိုယ်ကမမေးပဲ ပြောနေရင် ပိုတောင် အကျိုးရှိပါတယ်။

၃။ မိမိရဲ့ အဖြေတွေကို မပြောပါနဲ့
Customer က သူတို့ ရဲ့ အခက်အခဲ တစ်ခုကို ပြောပြတယ်။ အဲ့တာကို ဖြေရှင်းထားတဲ့ Features ကလည်း မိမိ Product ထဲမှာရှိတယ်။ သူသိသင့်ပါတယ် ဆိုပြီး သွားမပြောပါနဲ့။ ပြန်ပြောရရင် ကျွန်တော်တို့က Customers တွေရဲ့ နေ့စဥ◌် အခက်အခဲတွေကို နားထောင်နေတာပါ။ ကိုယ်က ရုတ်တရက်ကြီး အဖြေတွေ သွားချပြလိုက်ရင် တွေ့ကြုံနေရတဲ့ အခက်အခဲ အကုန်မသိတော့ဘူးဖြစ်သွားနိုင်ပါတယ်။ အရင်ဆုံး ဆုံးအောင်နားထောင် ပြဿနာ အရင်းအမြစ်ကို နားထောင်မှတ်သားဖို့က အရေးကြီးဆုံးပါ။

၄။ စကား အတင်းမပြောခိုင်းပါနဲ့
အပေါ်မှာတုန်းက Customer ကို စကားပေးပြော၊၊ အခု စကားအတင်းမပြောခိုင်းပါနဲ့ ဆိုတော့ တစ်ခုခုမှားနေလားဆိုတော့ မမှားပါဘူး။ စကားပြောခိုင်းတာကောင်းပေမယ့် အတင်းကြီး လုပ်ယူ မပြောစေဖို့ သတိထားဖို့ပါ။ ကျွန်တော်တို့က တစ်ခါတစ်လေ မိမိ လိုချင်တဲ့ အကြောင်းအရာတွေကို ကြိုသိထားပြီး အဲ့အကြောင်းအရာတွေကို ဖိပြောခိုင်းရင် Customers တွေရဲ့ အခက်အခဲ အလုံးစုံကို မသိနိုင်ဘဲ ဖြစ်သွားနိုင်ပါတယ်။ ဒါကြောင့် Yes or No မေးခွန်းတွေမမေးဘဲ 5 W လို့ခေါ်တဲ့ (Who, What, When, Where, Why) ဆိုတာတွေနဲ့ မေးခွန်းတွေကို Guide လုပ်သွားပါ။

Customer Interview လို့ဆိုရာမှာ Customer ဆီသွားပြီး တိုက်ရိုက်ထိတွေတဲ့ Process တွေအားလုံးကို ရည်ရွယ်ပါတယ်။ Qualitative Research ဖြစ်တဲ့ တိုက်ရိုက် မေးခွန်းတွေ မေးတာ၊ Customer တွေကို အုပ်စုဖွဲ့ပြီး ဆွေးနွေးခိုင်းတာ စတာတွေပါဝင်သလို၊ Customer ဆီသွား စကားစမည်ပြောပြီး Survey ဖြေခိုင်းတဲ့ Quantitative Research နည်းတွေလည်း ပါဝင်ပါတယ်။ Customer ရဲ့ Feedback ရယူရာမှာ သတိထားသင့်တဲ့အချက်တွေလို့ဆိုနိုင်တာမို့ Qualitative နည်းလမ်းရော၊ Quantitative နည်းလမ်းမှာပါ ကျင့်သုံးကြည့်နိုင်ပါတယ်။

ဒီဆောင်ရန် ရှောင်ရန်တွေကို သတိထားခြင်းဖြင့် မိမိ Product အတွက် လိုအပ်တဲ့ Feedback အဖြေတွေကိုလည်းရနိုင်ပြီး ပိုမိုထိရောက်တဲ့ Customer Interview တစ်ခု ဖန်တီးနိုင်ပါလိမ့်မယ်။ တခြား တွေးမိတဲ့ ဆောင်ရန် ရှောင်ရန်များ ရှိရင်လည်း Comment ပေးခဲ့ပါဦး။ နောက်ထပ် ဖတ်ချင်တဲ့ 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 (

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 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,