🛑 จุดจบ “พนักงานรับส่ง Requirement”?
เมื่อองค์กรไทยมี Product Manager…แต่ใช้งานเหมือน Messenger
ในช่วงไม่กี่ปีที่ผ่านมา คำว่า “Product Manager (PM)” และ “Product Owner (PO)” กลายเป็นตำแหน่งยอดนิยมที่แทบทุกองค์กรต้องมี
ไม่ว่าจะเป็น Tech Company, ธนาคาร, องค์กรใหญ่ หรือแม้แต่ธุรกิจดั้งเดิมที่กำลังทำ Digital Transformation
แต่คำถามสำคัญคือ…
เรา “มีตำแหน่ง” นี้จริง หรือแค่ “มีชื่อเรียก” นี้?
เพราะในหลายองค์กร สิ่งที่เรียกว่า PM/PO ในทางปฏิบัติ กลับเป็นเพียง
* คนรับ Requirement จากผู้บริหาร
* คนจดสรุปประชุม
* หรือคนวิ่งประสานงานระหว่าง Business กับ Dev
พูดตรงๆ คือ…“Messenger ที่เงินเดือนแพงขึ้น”
และนี่ไม่ใช่แค่การใช้คนผิดงาน แต่มันคือ “ความผิดพลาดเชิงโครงสร้าง” ที่กำลังกัดกินความสามารถในการสร้างโปรดักต์ขององค์กร
====
📉 1. The Messenger Trap
ลองถาม PM ในองค์กรส่วนใหญ่ดูว่าแต่ละวันทำอะไร?
คำตอบที่ได้ มักจะคล้ายกันอย่างน่าตกใจ เช่น
🔻 รับออเดอร์จากเบื้องบน
ฟีเจอร์ถูกคิดมาเสร็จแล้วจากผู้บริหารหรือ Sales
PM มีหน้าที่แค่ “แปล Requirement” แล้วส่งต่อให้ Dev
โดยไม่มีสิทธิ์ถามว่า
“สิ่งนี้แก้ปัญหาลูกค้าจริงไหม?”
🔻 ถูกตัดขาดจากลูกค้าจริง
PM ไม่ได้คุยกับผู้ใช้โดยตรง
ต้องอาศัยข้อมูลมือสอง มือสาม จากทีมอื่น
สุดท้าย “ความเข้าใจลูกค้า” กลายเป็นสิ่งที่เล่าต่อๆ กันมา
ไม่ใช่สิ่งที่เห็นด้วยตัวเอง
🔻 ไม่มีอำนาจตัดสินใจ
PM ไม่มีสิทธิ์ปฏิเสธ
ไม่มีสิทธิ์ Kill Feature
และไม่มีสิทธิ์ Prioritize จริง
ผลลัพธ์คือ
กลายเป็น “buffer” รับแรงกดดันระหว่าง Business กับ Tech
แทนที่จะเป็นคนกำหนดทิศทาง
นี่ไม่ใช่ Product Management แต่มันคือ “Project Coordination ที่ใส่ชื่อใหม่ให้ดูทันสมัย”
====
⚔️ 2. PM ตัวจริง =ไม่ใช่คนสั่ง…แต่คือคนตัดสินใจในสิ่งที่ยาก
ในองค์กรเทคโนโลยีระดับโลก PM ไม่ได้มีอำนาจสั่ง Dev
แต่มี “อำนาจในการตัดสินใจ” บางอย่างที่สำคัญมาก
นั่นคือ
“จะทำอะไร…และที่สำคัญกว่า…จะไม่ทำอะไร”
PM ที่ดี ไม่ได้เพิ่ม Feature
แต่ “คัดกรอง Feature”
ไม่ได้บอกว่าอะไรควรทำ
แต่กล้าบอกว่าอะไร “ไม่ควรทำ”
เพราะทรัพยากรขององค์กรมีจำกัด
ทุกสิ่งที่คุณเลือกทำ = คุณกำลัง “ไม่ทำ” อีกหลายอย่าง
PM ที่แท้จริงจึงอยู่ตรงจุดตัดของ
* Business (สิ่งที่องค์กรต้องการ)
* User (สิ่งที่ลูกค้าต้องการ)
* Tech (สิ่งที่ทำได้จริง)
และหน้าที่ของเขา ไม่ใช่การเอาทั้ง 3 อย่างมารวมกันแบบ compromise
แต่คือ “เลือกทางที่สร้างคุณค่ามากที่สุด…แม้ต้องขัดใจบางฝ่าย”
====
📌 3. แล้วทำไมองค์กรไทยถึงติดกับดักนี้?
ปัญหานี้ไม่ได้เกิดเพราะ PM ไม่เก่ง แต่เกิดจาก “ระบบไม่อนุญาตให้เขาเก่ง”
🔻 Decision ยังรวมศูนย์
ทุกอย่างต้องผ่าน C-Level
PM ไม่มีสิทธิ์ตัดสินใจหน้างาน
🔻 Culture ไม่ยอมรับการปฏิเสธ
การพูดว่า “ไม่ทำ” ถูกมองว่าเป็นการขัดผู้ใหญ่
สุดท้ายทุกอย่างถูก approve
และองค์กรเต็มไปด้วย Feature ที่ไม่มีใครใช้
🔻 วัดผลผิด
PM ถูกวัดจาก
* ส่งงานทันไหม
* ปล่อยฟีเจอร์ได้กี่ตัว
ไม่ใช่
* ลูกค้าใช้ไหม
* ธุรกิจดีขึ้นไหม
====
📌 ตัวอย่างเมื่อโครงสร้างทำให้คนเก่งกลายเป็นคนส่งงาน
❌ Case 1: “Agile Theatre” ในองค์กรขนาดใหญ่
องค์กรระดับประเทศแห่งหนึ่งลงทุนตั้งทีม Agile อย่างจริงจัง มี PO ครบทุกทีม ใช้ Scrum เต็มรูปแบบ ตั้ง OKR และมีพิธีการครบถ้วนตามตำรา
บนสไลด์…ทุกอย่าง “ดูถูกต้อง”
แต่ในหน้างานจริง ทุกการตัดสินใจสำคัญยังต้องผ่าน “คณะกรรมการ” หลายชั้น
สิ่งที่เกิดขึ้นซ้ำๆ ในแต่ละ Sprint คือ
* ทีมวางแผน Sprint ตามลำดับความสำคัญที่ตกลงกัน
* กลาง Sprint มี “งานด่วนจากผู้บริหาร” แทรกเข้ามา
* PO ไม่สามารถปฏิเสธได้ จึงต้องรื้อแผนและเปลี่ยนลำดับงาน
* เมื่องานเสร็จ ยังต้องรอรอบอนุมัติ ก่อนปล่อยใช้งานจริง
ผลลัพธ์เชิงระบบจึงกลายเป็นว่า
* ทีมมีพิธี Agile ครบ แต่ “ไม่มีอำนาจตัดสินใจจริง”
* Lead time ยาวขึ้น เพราะต้องรอการอนุมัติหลายรอบ
* Backlog เต็มไปด้วยฟีเจอร์ที่ “มีคนสั่ง” แต่ไม่ชัดว่า “มีคนใช้”
* ทีม Dev เหนื่อยจาก context switching แต่ไม่ได้สร้าง impact จริง
* PO กลายเป็นคนประสานงาน มากกว่าคนกำหนดทิศทาง
สุดท้ายสิ่งที่องค์กรได้ ไม่ใช่ความเร็ว
แต่คือ “ภาพลวงของความเป็น Agile” นี่ไม่ใช่ Agile
แต่มันคือ “Agile Theatre” หรือการทำ Agile เพื่อให้ดูเหมือน Agile
✅ Case 2: ทีมขนาดเล็กที่กล้าพูดว่า “ไม่ทำ”
บริษัท B2B SaaS ในไทยแห่งหนึ่ง ถูกทีม Sales กดดันให้สร้าง Feature OCR เพื่อปิดดีลลูกค้ารายใหญ่
บนกระดาษ เหตุผลดูสมเหตุสมผล
“มี OCR = ปิดดีลง่ายขึ้น”
แต่ PM ของทีมเลือกทำสิ่งที่ยากกว่า คือ “ไม่เชื่อ assumption ทันที” และลงไปคุยลูกค้าจริง
สิ่งที่พบคือ ลูกค้าไม่ได้มีปัญหาเรื่องการอ่านเอกสาร แต่มีปัญหาเรื่อง “การจัดการ workflow หลังจากได้ข้อมูลแล้ว”
ทีมจึงตัดสินใจอย่างชัดเจน
* ปัดตก OCR (แม้จะขัดใจ Sales)
* นิยามปัญหาใหม่จาก “อ่านเอกสาร” → “จัดการงานหลังเอกสาร”
* สร้าง Template + Workflow System ที่ปรับได้ตามแต่ละองค์กร
* ทดลองกับลูกค้ากลุ่มเล็กก่อน (pilot)
* วัดผลจาก adoption และเวลาที่ลดลงจริง
ผลลัพธ์ใน 2–3 ไตรมาสถัดมา คือ
* ใช้ resource น้อยกว่าการทำ OCR อย่างมีนัยสำคัญ
* Adoption สูง เพราะแก้ pain ที่เกิด “ทุกวัน” ไม่ใช่ edge case
* ทีม Sales ปิดดีลง่ายขึ้น เพราะ value ชัด ไม่ต้องอธิบายเยอะ
* Feature นี้กลายเป็น core module ที่ขยายไปลูกค้ากลุ่มอื่นได้
สิ่งที่สำคัญไม่ใช่แค่ “ตัดสินใจถูกครั้งเดียว” แต่คือการมีระบบที่ทำให้ “ตัดสินใจถูกซ้ำได้”
สองเคสนี้ต่างกันแค่เรื่องเดียว
“มีสิทธิ์ปฏิเสธ หรือไม่มี”
ผลลัพธ์ของโครงสร้างแบบเดิมคือ
องค์กรเต็มไปด้วย “Output” แต่ไม่มี “Outcome”
และสิ่งที่น่ากลัวกว่านั้นคือ
องค์กรกำลังจ้างคนเก่ง…มาทำงานที่ไม่ต้องใช้ความเก่ง
นี่คือการสูญเสียที่แพงที่สุด ไม่ใช่แค่เงิน
แต่คือ “ศักยภาพของคน” ที่ถูกกดทับโดยระบบ
====
🚀 4. ถ้าอยากได้ Product จริง ต้องรื้อโครงสร้าง
ถ้าคุณอยากได้ Product ที่แข่งขันได้จริง
คุณต้องหยุดใช้ PM เป็น Messenger
และเริ่มให้เขาเป็น “Owner”
1. ให้ PM เข้าถึงลูกค้าจริง
ถ้าไม่ได้คุยกับลูกค้า
เขาจะไม่มีวันเข้าใจปัญหา
2. เปลี่ยน KPI เป็น Outcome
เลิกวัดจาก Feature
วัดจาก Impact
3. กระจายอำนาจการตัดสินใจ
ทีมต้องมีสิทธิ์ “ตัดสินใจหน้างาน”
ไม่ใช่รออนุมัติทุกเรื่อง
4. ใช้ Data แทน Opinion
เลิกใช้ HiPPO (Highest Paid Person’s Opinion)
แล้วใช้ Evidence ในการตัดสินใจ
====
🚀 ดังนั้น คุณต้องการ “คนคุมหางเสือ” หรือแค่ “คนส่งไม้”?
Product Manager ไม่ใช่คนทำให้ของเสร็จ
แต่คือคนทำให้ “ของที่ควรทำ” ถูกเลือกขึ้นมาทำ
ถ้าองค์กรยังใช้ PM เป็นแค่คนรับคำสั่ง
คุณจะได้แค่ “ซอฟต์แวร์ที่ทำตามบรีฟ” ไม่ใช่
“โปรดักต์ที่สร้างคุณค่า”
✨ องค์กรอาจไม่ได้ขาดคนเก่ง
แต่ขาด “พื้นที่ให้คนเก่งตัดสินใจ”
และถ้าคุณยังไม่กล้าให้ PM ตัดสินใจ
คุณก็ไม่มีวันได้ Product ที่แตกต่าง
#วันละเรื่องสองเรื่อง
#ExecutiveMindset
#ProductManagement
#AgileInContext
#OutcomeOverOutput
#FutureOfWork
#BusinessStrategy

โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
