“กำหนดขอบเขต PO/PM ให้ชัดเจน = กุญแจแก้ปัญหาวนเวียนในองค์กรใหญ่”
(ภาคต่อจากบทความก่อนหน้า)

บทความนี้เป็นภาคต่อของบทความที่เขียนก่อนหน้านี้ เรื่อง “บทบาท PO/PM ในองค์กรใหญ่ (Corporate)” ใครยังไม่ได้อ่าน แนะนำให้อ่านตอนก่อนหน้านี้ที่
จากบทความก่อนหน้าที่ชี้ให้เห็นความท้าทายของบทบาท Product Owner (PO) และ Product Manager (PM) ในองค์กรใหญ่ ปัญหาส่วนหนึ่งเกิดจาก “ความไม่ชัดเจนของขอบเขตงาน” และ “การเอา Role หรือ Scope งานแบบตะวันตก หรือแบบ Agile เช่น Role ใน Scrum มาติดตั้งแบบครึ่งๆ กลางๆ” ทำให้ทั้งองค์กรและตัว PO/PM ต้องเผชิญความขัดแย้งและ turnover สูง บทความนี้จะเจาะลึกวิธีกำหนดบทบาทให้ตรงกับความต้องการจริงขององค์กร
1. ปัญหาวนเวียน “ JD สวยหรู” vs. “ความต้องการจริง”?
หลายองค์กรเขียนประกาศรับสมัคร PO/PM โดยคัดลอก Job Description (JD) จากบริษัทชั้นนำ เช่น ต้องการคนที่ “สร้าง Product Strategy”, “วิเคราะห์ตลาด”, หรือ “ตัดสินใจ Roadmap” แต่ในทางปฏิบัติ กลับมอบหมายให้ทำงานแค่ “เรียง Backlog” และ “ติดตาม Delivery” เป็นต้นให้กับ PO/PM นั้น
ผลที่ตามมาคือ
- คนที่อยากทำงานเชิงกลยุทธ์ — จะรู้สึกว่าถูกกดความสามารถ จึงลาออก
- คนที่ถนัดทำงาน Operation — แต่กลับถูกดันให้ทำ Strategic Planning ทั้งที่ขาดทักษะ ทำให้ผลงานไม่เป็นไปตามเป้า เป็นต้น
2. ทางออก — กำหนด Scope งานให้ตรงจุดตั้งแต่แรก
2.1 วิเคราะห์ปัญหาที่ต้องการแก้
- หากองค์กรต้องการ “เพิ่มประสิทธิภาพการ Delivery” — ควรหาคนที่เชี่ยวชาญกระบวนการ Agile (ที่ต้องการประยุกต์ใช้) และการประสานงาน
- หากต้องการ “สร้าง Product ใหม่” — ต้องหาคนที่มีทักษะด้าน Market Research, Business Model, Innovation หรือ Ideation/ทำงานบนพื้นฐานการทดสอบสมมุติฐาน เป็นต้น
2.2 ตั้งชื่อบทบาทให้สอดคล้องกับงาน
Delivery Manager = โฟกัสที่การส่งมอบงานตามแผน
Product Strategist = โฟกัสที่การออกแบบกลยุทธ์ผลิตภัณฑ์
Hybrid Role = ผสมผสานทั้งสองด้าน แต่ต้องกำหนดสัดส่วนให้ชัด เช่น 70% Delivery 30% Strategy
“อย่าใช้ตำแหน่ง copy JD มาแล้วก็ไม่ได้ทำตาม JD นั้นเพียงเพราะแค่ต้องการหาคนมาเติมเต็มตำแหน่งในองค์กร เพราะจะมีแต่ผลเสีย”
2.3 สื่อสารความคาดหวังให้ตรงกัน
- ใน JD ให้ระบุให้ชัดว่า “ต้องทำงานร่วมกับทีมธุรกิจแค่ไหน” และ “มีอำนาจตัดสินใจระดับใด”
- ในการสัมภาษณ์ — ให้ฝั่งผู้มาสัมภาษณ์งานก็ต้องถามตรงๆ ว่า “ปัญหาหลักขององค์กรคืออะไร?” และ “คาดหวังให้ผู้สมัครแก้ปัญหานั้นอย่างไร?”
3. Case Study — เมื่อองค์กรกำหนด Scope ถูกต้อง?
บริษัทเทคโนโลยีไทยแห่งหนึ่งเคยเผชิญปัญหา PO ลาออกบ่อย เพราะ JD ระบุว่า “ต้องสร้าง Product Roadmap” แต่ในทางปฏิบัติ PO ถูกจำกัดให้แค่รับ Requirement จากผู้บริหาร หรือ BUs เท่านั้น โดยหลังจากปรับกระบวนการใหม่เกิดการ
แยกบทบาทเป็น “Technical PO” (ดูแล Delivery) และ “Business PO”(ดูแล Strategy)
กำหนด KPI ที่สอดคล้องกับบทบาท เช่น Technical PO วัดจากความเร็วการส่งมอบ Business PO วัดจากส่วนแบ่งตลาด เป็นต้น
ผลลัพธ์ คือ เมื่อกำหนดความชัดเจน “ปัญหาการลาออกลดลง 40% ภายใน 6 เดือน”
4. บทเรียนสำคัญ คือ “ไม่มีสูตรสำเร็จรูป”
การจะกำหนดบทบาท PO/PM ให้เหมาะกับองค์กร ต้องเริ่มจากการตอบคำถาม 3 ข้อ ได้แก่
- ปัญหาที่ต้องการแก้คืออะไร?
- ทักษะหลักที่จำเป็นสำหรับปัญหานั้นมีอะไรบ้าง?
- อำนาจตัดสินใจที่มอบให้ PO/PM ควรอยู่ในระดับไหน?
สรุป คือ “ความชัดเจนคือจุดเริ่มต้นของประสิทธิภาพ”
PO/PM ไม่ใช่ตำแหน่งที่ใช้คำจำกัดความเดียวกันได้ทุกองค์กร แม้จะมีคนบอกอ้างจาก scrum guideline หรือ framework อื่นๆ เช่น spotify squads แต่ชวนคิด guideline นั้นมันตามโครงสร้างองค์กร และกำหนดขอบเขตงานให้ชัดเจนตามทฤษฏี?
ดังนั้น องค์กรต้องออกแบบโครงสร้างและขอบเขตว่าทำอะไรให้ชัดแต่แรก ไม่สร้างความคาดหวังที่ผิดจะช่วยลดความขัดแย้ง ดึงดูดคนที่เหมาะสม และสร้างผลงานที่เป็นไปตามเป้าหมายธุรกิจ
“กำหนดขอบเขตให้ชัด แม้จะไม่ครบทุกทักษะ แต่ตรงกับปัญหาที่ต้องแก้ — นั่นคือหัวใจของการทำงานอย่างมืออาชีพ”
#วันละเรื่องสองเรื่อง