Product Manager အနေနဲ့ Feature အသစ်တွေကို ဘယ်လိုငြင်းမလဲ

Product Manager တစ်ယောက် နေ့စဥ်ကြုံတွေ့ရတဲ့ challenging task တွေအများကြီးပါ။ အဲ့ဒါတွေကို ရင်ဆိုင်ဖြေရှင်းဖို့အတွက် “ငြင်းပယ်ခြင်း” (Saying No) က မရှိမဖြစ် soft skill တစ်ခုဆိုလည်း မမှားပါဘူး။ မိမိ Product အတွက် Product Manager ကောင်းတစ်ယောက်ဖြစ်ဖို့ ဘာတွေကိုငြင်းပယ်ရမှာလည်း၊ ဘယ်လိုငြင်းပယ်ရမှာလည်း၊ ဘာလို့ငြင်းပယ်ရမှာလည်း?

မိမိ Product နဲ့ ဆက်စပ်နေတဲ့ Stakeholders တွေ၊ Internal team တွေနဲ့ စေ့စပ်ညှိနှိုင်းရတဲ့ Product Manager တစ်ယောက်ဆီကို အဖက်ဖက်ကနေလာတဲ့ feature request တွေ၊ Product အတွက် brainstroaming လုပ်ထားကြတဲ့ idea တွေ အမြဲမပြတ် ရောက်လာတတ်ပါတယ်။ Idea တွေကလည်း ကောင်းနိုင်ပါတယ်... features တွေကလည်း လိုအပ်ကောင်း လိုအပ်နိုင်ပါတယ်... ဒါပေမယ့် ရှေ့ဆက် develop လုပ်ဖို့ prioritize လုပ်ပြီးသား Product Roadmap ရယ်၊ ဒီ Product အတွက် develop လုပ်မယ့် engineers resources တွေဟာ အကန့်အသတ်နဲ့ပါ.. ဒါ့အပြင် ရောက်လာသမျှ Product idea တွေတိုင်းကို develop လုပ်ဖို့က မဖြစ်နိုင်သလို Product အတွက်လည်း focus တွေများနေတာက effective မဖြစ်တဲ့အပြင် Feature Factory Product ဆီကို ဦးတည်သွားပါလိမ့်မယ်...

ဆိုတော့ develop လုပ်မယ်/မလုပ်ဘူး (Say Yes or No) နဲ့ ဘယ်တော့ develop လုပ်မယ် ဆိုတဲ့ Prioritization က Product Manager ရဲ့ အဓိက တာဝန်ပါပဲ။

ဆိုပါစို့... သင့်ရဲ့ stakeholder တစ်ယောက်က သင့်ကို customer retention တွေတက်အောင် ဘယ်လိုအရမ်းမိုက်တဲ့ feature တစ်ခု ထပ်ထည့်ကြမယ်လို့ အကြံပေးတယ်၊ အကြံပေးတဲ့သူက အရေးကြီးတဲ့ Chief Level တွေ၊ investor တွေ၊ stakeholder တွေထဲက ဖြစ်တယ်... ဒီ Product မှာ အချိန်တွေ အများကြီး invest လုပ်ထားတဲ့ Product Manager သင့်အတွက် ဒီ idea က ကြားလိုက်တာနဲ့ ကိုယ့် Product နဲ့ align မဖြစ်ဘူးဆိုတာ တန်းသိကောင်းသိနိုင်တယ်၊ သင်တို့ ဟိုးအရင်ထဲက ရထားပြီးသား idea ကိုမှ develop အတွက် ထည့်ရမယ့် resource နဲ့ ပြန်ရမယ့် ROI မကိုက်တာမို့ Product Roadmap ရဲ့ backlog အရှည်ကြီးထဲ အိပ်နေရတဲ့ feature လည်း ဖြစ်နိုင်တယ်။ သို့သောက် တန်းပြီး ဒီ feature ကို ထည့်ဖို့မဖြစ်နိုင်ကြောင်း တစ်ခွန်းတည်းနဲ့ ငြင်းပယ်လိုက်ဖို့ မလွယ်ပါဘူး၊ သင်လည်း ငြင်းဖို့ ဝန်လေးနိုင်ပါတယ်။ အဲ့လိုအခြေအနေမှာ ကျွန်တော်တို့ Product Manager တွေ ရှောင်တတ်တဲ့ အကွက်က “Backlog ထဲထည့်ထားပြီး develop လုပ်လိုက်ပါမယ်” ဆိုတာပါပဲ။

အဲ့ဖြေရှင်းနည်းက တစ်ကြိမ် နှစ်ကြိမ်တော့ တကယ် အသုံးဝင်ပါတယ်... သို့သော် လူတွေက သူတို့တောင်းဆိုထားတဲ့ idea တွေ၊ request ကို လွယ်လွယ်နဲ့ မမေ့တတ်ကြပါဘူး။ Stakeholder က တောင်းတဲ့ feature တိုင်းကို ကြားလိုက်တည်းက develop လုပ်ပေးဖို့ မဖြစ်နိုင်မှန်း သိရက်နဲ့ Backlog ထဲထည့်ထားမယ်ပြောလိုက်၊ request feature က ထွက်မလာလိုက်နဲ့ အကြိမ်ရေများလာရင် false hope ပေးမိတဲ့အတွက် Product Manager နဲ့ အခြား stakeholders တွေကြား တည်ဆောက်ထားတဲ့ TRUST အပေါ် အများကြီး ထိခိုက်လာပါလိမ့်မယ်။ အကောင်းဆုံး အကြံပေးချင်တာက develop လုပ်ဖို့ မဖြစ်နိုင်ဘူးဆိုရင် အစတည်းက ပွင့်ပွင့်လင်းလင်း ရှင်းပြပြီး ငြင်းပယ်ဖို့ပါပဲ။

Saying No…. “ငြင်းပယ်”ရတာ ခက်ခဲပါတယ်။ ငြင်းပယ်လိုက်ရင် stakeholders တွေနဲ့ Relationship ထိခိုက်နိုင်ပါတယ်။ Relationship လည်း မထိခိုက်အောင် False hope လည်း မပေးမိအောင် ဘယ်လိုငြင်းပယ်ကြမလဲ။ အောက်မှာ ဆက်ဆွေးနွေးမယ့် tips တွေက သင့်အတွက် အသုံးဝင်ပါလိမ့်မယ်။

1. အချိန်ပေးပြီး idea တွေ request တွေကို ဆွေးနွေးပါ၊ အသိအမှတ်ပြုဖို့ မမေ့ပါနဲ့
ကိုယ့် Company တွင်းက Internal stakeholders တွေ၊ ကိုယ့် Customers တွေရဲ့ feedback, request နဲ့ idea တွေကို အချိန်ပေးပြီး အာရုံစိုက်နားထောင်ပေးပါ။ လူတွေက သူတို့ အတွေးအမြင်တွေကို နားထောင်ပေးတာ သဘောကျကြပါတယ်။ Product နဲ့ ပတ်တက်တဲ့ သူတို့ idea တွေ၊ ထပ်ထည့်ဖို့တောင်းဆိုတဲ့ feature တွေကို တကယ်နားလည်တဲ့အထိ အာရုံစိုက်ဆွေးနွေးပေးပါ။ သူတို့ဘက်က လိုချင်တဲ့ feature ကို မိမိ နားလည်ကြောင်းလည်း ပြပေးပါ။ ထပ်ထည့်ဖို့ မလိုတဲ့ feature ဖြစ်ခဲ့ရင် မငြင်းပယ်ခင် သူတို့ဘက်က တောင်းဆိုလာတဲ့ feature တွေက “Product အတွက် အသုံးဝင်တဲ့ idea ကောင်းဖြစ်ကြောင်း၊ ကျေးဇူးတင်ကြောင်း” သင့်အနေနဲ့ အသိအမှတ်ပြုဖို့ မမေ့ပါနဲ့။ အသိအမှတ်ပြုခံရတာကို လူတိုင်း နှစ်ခြိုက်ကျပါတယ်။

2. ဘာလို့ ငြင်းပယ်ရကြောင်း သေချာနားလည်အောင် ရှင်းပြပါ
အရင်ဆုံး ဘယ် problem ကိုသူတို့ဖြေရှင်းဖို့ ကြိုးစားနေတာလဲဆိုတဲ့ root cause ကို သိဖို့ “ဘာလို့ ဒီ feature ကို ထပ်ထည့်ချင်တာလဲ” ဆိုတဲ့ မေးခွန်းများများမေးပါ။ 5 Whys technique ကို အသုံးချဖို့ တိုက်တွန်းလိုပါတယ်။ အကယ်၍ Feature အသစ်က develop လုပ်ဖို့ အဆင်မပြေဘူး / မလိုအပ်ဘူးဆိုရင် ဘာလို့ငြင်းပယ်ရတယ်ဆိုတဲ့ အကြောင်းပြချက်ကို မိမိတို့် product ရဲ့ လက်ရှိ metrics တွေ၊ data တွေ၊ စုစည်း ထားတဲ့ customer feedback တွေကို အသုံးပြုပြီး ချက်ကျလက်ကျ ရှင်းပြပေးပါ။ တခြား အရေးကြီး development တွေရှိလို့ ဒီ feature အသစ်ကို မထည့်ပေးနိုင်ဘူးဆိုတာမျိုးက stakeholders တိုင်း လိုလိုလားလားလက်ခံချင်လောက်တဲ့ အကြောင်းပြချက်ကောင်းမဟုတ်ပါဘူး။

3. Product အတွက် Roadmap မှာ ဘာတွေ Prioritize လုပ်ထားတယ်ဆိုတာ ပွင့်ပွင့်လင်းလင်း ပေးသိပါ
ကျွန်တော်တို့ Product Tech team တွေက များသောအားဖြင့် အခုလောလောဆယ် sprint တွေတင်မက ရှေ့ quarter တွေအတွက်ပါ roadmap ထဲက features တွေနဲ့ task အပြည့် sprint အပြည့်ပါ။ ဘယ် development တွေကို ဦးစားပေးပြီး plan ထားတယ်၊ နောက် sprint တွေမှာ ဘာ feature တွေ develop လုပ်ပြီး ဘယ်တော့ deilver လုပ်မယ်ဆိုတာ stakeholders တွေကိုပါ ပွင့်လင်းမြင်သာအောင် အသိပေးထားသင့်ပါတယ်။ Product development ကို agile နဲ့ run နေသရွေ့ Product Roadmap ရဲ့ prioritization က business နဲ့ product ရဲ့ လိုအပ်ချက်ပေါ်မူတည်ပြီး ပြောင်းလဲနိုင်ပါတယ်။ ဆိုပေမယ့် ရှိပြီးသား plan နဲ့ backlog ကို ပေးသိထားခြင်းက မလိုအပ်တဲ့ request တွေကို လျော့ချနိုင်သလို request ကို ငြင်းပယ်ရာမှာလည်း တစ်နည်းတစ်ဖုံ အသုံးဝင်ပါတယ်။

4. Problem အတွက် ဖြေရှင်းလို့ရမယ့် အခြား Solution ရှာပေးပါ
Problem တွေအတွက် solution က တစ်ခုထဲရှိတာ မဟုတ်ပါဘူး... အခြား solution တွေ ရှာလို့ရပါလိမ့်မယ်... အမြဲတမ်း workaround တွေ ရှိတတ်ပါတယ်... Product နဲ့ပတ်သက်တဲ့ အချက်အလက်တွေ လိုအပ်တဲ့ အကူအညီတွေကို Stakeholders တွေဆီ အကောင်းဆုံး provide ပေးဖို့က Product Manager ရဲ့တာဝန်ဖြစ်ပါတယ်။ ဆိုတော့ တောင်းဆိုလာတဲ့ feature က Product မှာ ထပ်ထည့်ဖို့ အဆင်မပြေရင် ရှိပြီးသား ဘယ် features တွေကရော သူတို့ problem ကို တစ်နည်းတစ်ဖုံ ဖြေရှင်းနိုင်မလဲဆိုတဲ့ တခြား solution ကို စဥ်းစားပေးပြီး provide လုပ်ပေးဖို့လိုပါတယ်။ ဒီနည်းလမ်းက feature request တွေကို ငြင်းပယ်ရာမှာ ကျွန်တော့် အတွေ့အကြုံအရ အတော်အသုံးဝင်တဲ့ သုံးသင့်တဲ့ နည်းလမ်းဖြစ်ပါတယ်။ ဒီနည်းကို သုံးနိုင်ဖို့အတွက် Product Manager က မိမိ Product မှာ ဘယ်လို features တွေရှိပြီး ဘာတွေသုံးနေလည်း၊ ဘာတွေသုံးမနေဖူးလည်း၊ ဘယ်လိုတွေအသုံးဝင်လဲ အစရှိတဲ့ product နဲ့ဆိုင်တဲ့ အချက်အလက်တွေကို အကျွမ်းကျင်ဆုံးဖြစ်နေအောင် လေ့လာထားဖို့ အကြံပေးလိုပါတယ်။

5. အခုချက်ခြင်း develop မလုပ်နိုင်ပေမယ့် အမြဲတမ်းအတွက် ငြင်းပယ်တာ မဟုတ်ကြောင်းပြောပြပါ
ခုလက်ရှိမှာ develop လုပ်ရမယ့် ပိုအရေးကြီးတဲ့ ဘယ် feature တွေ၊ ဘာ improvement တွေရှိနေလည်းဆိုတာ Product Manager က အသိဆုံးပါ။ Idea တွေ ဘယ်လောက်ကောင်းကောင်း “Must have” လား၊ “Should have” လား၊ “Nice to have” လားဆိုတာ prioritize လုပ်ဖို့လိုပါတယ်။ request လုပ်ခံရတဲ့ feature က ခုချက်ခြင်း develop လုပ်ဖို့ မဖြစ်နိုင်ဘူးဆိုပေမယ့် Product Vision နဲ့လည်း align ဖြစ်ပြီး၊ မိမိ product ရဲ့ problem ကို solve လုပ်နိုင်တယ်၊ နောက် sprint တွေမှာ ထည့်ဖို့လည်း ဖြစ်နိုင်တယ်ဆိုရင် အဲ့ဒီအခြေအနေကို အပေါ်က နံပါတ် ၃ အချက်နဲ့အတူတွဲပြီး သေချာနားလည်အောင် ရှင်းပြစေလိုပါတယ်။ backlog ထဲမှာ ထည့်ထားပြီး ဘယ် feature development ပြီးရင် ဘယ်တော့မှာ develop လုပ်နိုင်တယ်ဆိုတာ stakeholders တွေကို သေချာရှင်းပြဖို့လိုပါတယ်။ မသေချာပဲနဲ့ နောက်ပိုင်း develop လုပ်ပေးမယ်လို့ အလွယ်ပြောတာမျိုး မဖြစ်ဖို့တော့ သတိထားသင့်ပါတယ်။

Bonus Tip:
ငြင်းပယ်တဲ့အခါ တတ်နိုင်သမျှ “ကျွန်တော့အမြင်ကတော့” ဆိုတဲ့ individual ဆန်တဲ့ အသုံးအနှုန်းကို ရှောင်ပါ။ “ကျွန်တော်တို့”၊ “ငါတို့” ဆိုတဲ့ product team တစ်ခုလုံးကို ကိုယ်စားပြုတဲ့ အသုံးအနှုန်းမျိုးက သင့်တို့ conversation ကို comfortable ပိုဖြစ်စေပါတယ်။ “ကျွန်တော်တို့ Product သွားနေတဲ့ လမ်းကြောင်းက”၊ “ကျွန်တော်တို့ Customers တွေလိုနေတာက”၊ “ကျွန်တော်တို့ data တွေက ပြနေတာက” စသည်ဖြင့် ငါတို့အားလုံးက ဒီ product အောင်မြင်ဖို့ ဦးတည်နေတဲ့ တစ်လှေတည်းစီးသူတွေဆိုတဲ့ ခံစားချက်ကို ပေးနိုင်တာက bonding ကို ပိုခိုင်မာစေပြီး မဖြစ်မနေ ငြင်းပယ်ရတဲ့ အခါတွေမှာလည်း တစ်ဖက်လူရဲ့ နားလည်မှုကို ပိုရစေပါတယ်။

ဒီ Tips တွေကတော့ ကျွန်တော်တို့ Product Manager တွေ နေ့စဥ်ကြုံတွေ့နေရတဲ့ feature request တွေကို ငြင်းပယ်တဲ့အခါ အသုံးဝင်တဲ့ နည်းလမ်းတွေဖြစ်ပါတယ်။ Stakeholders တွေနဲ့ relationship လည်း မပျက်အောင် ငြင်းပယ်တတ်ဖို့ ဒီနည်းလမ်းလေးတွေနဲ့ Try ကြည့်ကြည့်ပါ... တခြား နည်းလမ်းတွေနဲ့ Try ဖူးရင်လည်း အောက်က Comment လေးမှာ Share ပေးပါဦး။

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