PM ไม่ใช่ “คนตามงาน”

PM ไม่ใช่ “คนตามงาน”

“กับดัก 40-20-20-20 ที่อาจทำให้องค์กรทำ Product Management ผิดทาง”

“เมื่อสูตรที่ดูเหมือนถูกต้อง กลับสะท้อนความเข้าใจผิดของหลายองค์กร” สูตรหนึ่งที่ถูกแชร์กันอย่างแพร่หลายเกี่ยวกับบทบาทของ Product Manager (PM) ว่า การทำงานควรแบ่งเวลาเป็น

* 40% Communication & Coordination

* 20% Business

* 20% Design

* และ 20% Engineering

(หมายเหตุ : หลายองค์กรนำสูตรนี้ไปใช้เป็นเหมือนคู่มือการทำงานของ PM และมักอ้างอิงแนวคิดของ Marty Cagan ผู้เขียนหนังสือ INSPIRED ซึ่งเป็นหนึ่งในบุคคลสำคัญของวงการ Product)

แต่ความจริงที่หลายคนอาจไม่ทราบคือ สูตร 40-20-20-20 ไม่ได้ถูกเสนอขึ้นมาเพื่อเป็น “แนวทางที่ควรทำ” หากถูกยกขึ้นมาในบทความนี้ เพื่อวิจารณ์รูปแบบการทำงานที่องค์กรจำนวนมากกำลังเข้าใจผิด

เหตุผล คึอ “เมื่อ PM ใช้เวลา 40% ไปกับการประสานงาน นั่นกำลังสะท้อนบทบาทของ Project Manager มากกว่า Product Manager?”

* ความเข้าใจผิดนี้ดูเหมือนเรื่องเล็ก แต่ในความเป็นจริงมันสะท้อนปัญหาเชิงโครงสร้างขององค์กรจำนวนมาก ที่จ้าง Product Manager เข้ามา แต่ให้ทำหน้าที่เพียง “คนตามงาน” หรือ “ตัวกลางประสานฝ่าย” มากกว่าจะเป็นเจ้าของผลิตภัณฑ์ที่มีอำนาจคิดและตัดสินใจเชิงกลยุทธ์

* ผลลัพธ์คือองค์กรจำนวนมากกำลังทำสิ่งที่เรียกว่า Feature Factory หรือผลิตฟีเจอร์ออกมาอย่างต่อเนื่อง แต่ไม่ได้สร้างคุณค่าที่แท้จริงให้กับลูกค้า

อย่างไรก็ตาม แม้สูตร 40-20-20-20 จะไม่ใช่สูตรสำเร็จ แต่สี่มิติที่กล่าวถึง คือ Communication, Business, Design และ Engineering ยังคงเป็นสนามจริงที่ Product Manager ต้องเข้าไปทำงาน

====

ก่อนอื่นต้องเคลียร์อีกหนึ่งความเข้าใจผิดสำคัญก่อน คือ “PO ≠ PM”

ในช่วงหลายปีที่ผ่านมา หลายองค์กรนำแนวคิด Scrum เข้ามาใช้ และตำแหน่งหนึ่งที่ถูกพูดถึงบ่อยคือ Product Owner (PO) แต่ในทางปฏิบัติ โดยเฉพาะในองค์กรขนาดใหญ่ “คำว่า PO กลับสร้างความสับสนมากกว่าความชัดเจน”

เพราะในตำรา Scrum นั้น PO มีหน้าที่หลักแค่

* จัดการ backlog

* จัดลำดับความสำคัญของงาน

* เป็นตัวแทนลูกค้าของทีมพัฒนา

* ซึ่งเป็นบทบาทที่เน้น การทำงานในระดับทีม (Team Level)

แต่ในโลกของการสร้างผลิตภัณฑ์จริง โดยเฉพาะในองค์กรขนาดใหญ่ บทบาทของ Product Manager ต้องรับผิดชอบมากกว่านั้นมากๆ เช่น

* การกำหนดทิศทางผลิตภัณฑ์

* การตัดสินใจเชิงกลยุทธ์

* การเชื่อมโยงผลิตภัณฑ์กับโมเดลธุรกิจ

* การประสาน stakeholder ระดับองค์กร เป็นต้น

เพราะเหตุนี้ ในช่วงหลังผมจึงมักเรียกคนทำหน้าที่ด้านนี้ว่า “Product Manager หรือเรียกสั้นๆ ว่า Product มากกว่าจะใช้คำว่า Product Owner”

เหตุผลไม่ใช่เพราะคำว่า PO ผิด แต่เพราะในหลายองค์กร คำนี้ทำให้เกิด ความคาดหวังที่ขัดแย้งระหว่างตำรากับความเป็นจริง

“ในตำรา PO ต้องมีอำนาจตัดสินใจ แต่ในองค์กรใหญ่ หลายแห่ง จริงๆ PO กลับเป็นเพียงคนจัด backlog?”

สุดท้ายคนที่ถูกเรียกว่า PO จึงกลายเป็น

* คนรับ requirement

* คนตามงาน sprint

* คนเขียน user story

“ซึ่งใกล้เคียงกับ Project Coordinator มากกว่า Product Leader”

ในต่างประเทศจึงเริ่มมีการนิยามบทบาทใหม่ เช่น

* Product Manager

* Product Lead

* Product Director

เพื่อสะท้อนว่า “งาน Product ไม่ใช่การจัด backlog แต่คือการกำหนดทิศทางผลิตภัณฑ์”

หากองค์กรยังยึดติดกับตำแหน่ง PO แบบตำรา แต่ไม่ได้ให้อำนาจตัดสินใจจริง สิ่งที่เกิดขึ้นมักจะไม่ใช่ Product Management แต่คือ “Scrum Theater”?

ดังนั้น บทความนี้จะชวนทำความเข้าใจ และเน้นที่บทบาทของ “PM” หรือ Product Manager ในชีวิตจริง ดังนั้น ให้วางความเข้าใจตำรา โดยเฉพาะข้อถกเถียงตำแหน่งที่ถูกอุปโลกที่ชื่อ “PO” ออกไปก่อน

บทบาทที่แท้จริงของ PM ในแต่ละมิติจริงๆ ต้องทำยังไง?

====

1. “Communication” = จาก “คนส่งสาร” สู่สถาปนิกแห่งความร่วมมือ

ในหลายองค์กร PM ถูกใช้เป็นเหมือนศูนย์กลางการประสานงาน รับ requirement จากผู้บริหาร ส่งต่อให้ทีมพัฒนา และคอยติดตามสถานะงาน จนหลายครั้งบทบาทของ PM ถูกเข้าใจว่าเป็นเพียง "คนกลาง" ที่ทำหน้าที่ส่งข้อมูลระหว่างฝ่ายธุรกิจกับทีมเทคนิค

แต่การสื่อสารของ PM ระดับมืออาชีพไม่ใช่การทำหน้าที่เป็นเพียง “ไปรษณีย์องค์กร” หากคือการเป็น ตัวแปลภาษาระหว่างโลกธุรกิจกับโลกเทคโนโลยี

ตัวอย่างที่พบได้บ่อย เช่น ผู้บริหารอาจพูดว่า "อยากให้ลูกค้าซื้อซ้ำมากขึ้น" หาก PM ทำหน้าที่แค่ส่งข้อความนี้ต่อไปให้ทีมพัฒนา ทีมวิศวกรรมอาจไม่รู้ว่าควรสร้างอะไร แต่ PM ที่ทำหน้าที่อย่างแท้จริงจะต้องแปลงเป้าหมายทางธุรกิจนี้ให้กลายเป็นโจทย์ที่ชัดเจน เช่น

* ลูกค้าหายไปในขั้นตอนใดของการใช้งาน

* ฟีเจอร์ใดที่ช่วยเพิ่ม retention ได้

* หรือควรทดลองสร้างระบบ recommendation เพื่อเพิ่มการซื้อซ้ำ

ในทางกลับกัน หากทีมวิศวกรรมบอกว่า "ฟีเจอร์นี้ต้องใช้เวลาพัฒนา 4 เดือน" PM ก็ต้องสามารถอธิบายให้ผู้บริหารเข้าใจได้ว่า ปัญหาเกิดจากข้อจำกัดของระบบใด และมีทางเลือกอื่นที่ใช้เวลาน้อยกว่าหรือไม่

นี่คือเหตุผลที่ PM ต้องทำหน้าที่เหมือน ตัวรับแรงกระแทกขององค์กร (organizational shock absorber)เพราะในหลายสถานการณ์ ฝ่ายธุรกิจต้องการความเร็ว ขณะที่ทีมวิศวกรรมต้องการความเสถียรของระบบ

* การสื่อสารที่ดีจึงไม่ใช่เพียงการส่งข้อมูลต่อไปมา

* แต่คือการทำให้ทุกฝ่ายเข้าใจ “ปัญหาเดียวกัน” และตัดสินใจบนข้อมูลชุดเดียวกัน

* เมื่อสิ่งนี้เกิดขึ้น ทีมจึงสามารถเคลื่อนที่ไปในทิศทางเดียวกันได้จริง

====

2. “Business” = PM ต้องคิดเรื่องคุณค่าทางธุรกิจ ไม่ใช่แค่ทำตามคำสั่ง

หนึ่งในความผิดพลาดที่พบได้บ่อยในหลายองค์กรคือ PM ทำหน้าที่เหมือนผู้รับคำสั่งจาก Business Unit หรือผู้บริหาร โดยไม่ได้ตั้งคำถามว่า “ฟีเจอร์ที่กำลังจะสร้างนั้นสร้างคุณค่าทางธุรกิจจริงหรือไม่?”

สถานการณ์แบบนี้เกิดขึ้นบ่อยมาก เช่น ผู้บริหารอาจบอกว่า

"อยากให้เพิ่มฟีเจอร์ใหม่ในแอป เพราะคู่แข่งมีน่ะ"

หาก PM ทำหน้าที่เพียงแค่รับคำสั่งแล้วส่งต่อให้ทีมพัฒนา นั่นคือการทำงานแบบ Feature Factory ซึ่งองค์กรจะผลิตฟีเจอร์ออกมาเรื่อยๆ แต่ไม่รู้ว่าฟีเจอร์เหล่านั้นสร้างผลลัพธ์จริงหรือไม่?

Product Manager ที่แท้จริงต้องหยุดถามคำถามสำคัญก่อนเสมอ เช่น

* ฟีเจอร์นี้แก้ปัญหาของลูกค้าจริงหรือไม่?

* ลูกค้าจะใช้มันจริงหรือไม่?

* และมันสร้างผลลัพธ์ทางธุรกิจให้บริษัทหรือไม่?

ยกตัวอย่างสถานการณ์ที่พบได้บ่อยในธุรกิจดิจิทัล

สมมติว่าบริษัทต้องการเพิ่มยอดขายในแพลตฟอร์ม e‑commerce ผู้บริหารบางคนอาจเสนอให้เพิ่มฟีเจอร์ใหม่ เช่น live commerce หรือ social feature แต่ PM ที่คิดแบบธุรกิจจะไม่รีบสร้างทันที เขาจะเริ่มจากการดูข้อมูลก่อน เช่น

* ลูกค้าหยุดใช้งานตรงขั้นตอนใด

* conversion rate ลดลงในจุดไหน

* ปัญหาที่แท้จริงคือ UX ที่ซับซ้อน หรือระบบชำระเงินที่ไม่สะดวก

ในบางกรณี การปรับปรุงขั้นตอน checkout เพียงเล็กน้อย อาจเพิ่มยอดขายได้มากกว่าการสร้างฟีเจอร์ใหม่ทั้งระบบ

นี่คือเหตุผลที่ PM ต้องเข้าใจทั้ง โมเดลธุรกิจ (Business Model) และ เศรษฐศาสตร์ของโปรดักต์ (Product Economics)

“เพราะในโลกความจริง ทุกฟีเจอร์ที่สร้างขึ้นคือการลงทุน หาก PM ไม่สามารถเชื่อมโยงการพัฒนาผลิตภัณฑ์กับผลลัพธ์ทางธุรกิจได้ โปรดักต์นั้นก็มีโอกาสกลายเป็นเพียงเทคโนโลยีที่ดูดี แต่ไม่สร้างผลกระทบต่อองค์กร”

และนั่นคือจุดที่หลายองค์กรเข้าใจผิดระหว่าง การสร้างผลิตภัณฑ์ (Product Building) กับ การสร้างคุณค่าทางธุรกิจ (Value Creation)

====

3. “Design” = ไม่ใช่เรื่องความสวยงาม แต่คือการเข้าใจผู้ใช้

หลายองค์กรยังเข้าใจว่า Design คือการทำหน้าตาแอปพลิเคชันให้ดูสวยงาม แต่ในความเป็นจริง Design คือกระบวนการทำความเข้าใจปัญหาของผู้ใช้ และหาวิธีแก้ไขปัญหานั้น

ปัญหาที่พบได้บ่อยในองค์กรขนาดใหญ่คือ ความสับสนของบทบาทระหว่าง Product Manager กับ UX/UI หรือ Product Designer บางองค์กรคาดหวังให้ PM เป็นคนออกแบบหน้าจอเอง ขณะที่บางองค์กรกลับแยกทีมออกจากกันจนทำงานคนละทิศทาง

ในความเป็นจริง บทบาทของสองฝ่ายนี้ควรต่างกันแต่ทำงานร่วมกันอย่างใกล้ชิด

* Product Manager มีหน้าที่กำหนดปัญหาที่ต้องแก้ (Problem Definition) และกำหนดผลลัพธ์ทางธุรกิจที่ต้องการ

* Product Designer / UX มีหน้าที่ออกแบบวิธีแก้ปัญหา (Solution Design) และทำให้ประสบการณ์ผู้ใช้ดีที่สุด

กล่าวอีกอย่างหนึ่งคือ PM ต้องตอบคำถามว่า "เราควรแก้ปัญหาอะไร?" ส่วน Designer ต้องตอบว่า "ควรแก้ปัญหานั้นอย่างไร?"

ตัวอย่างสถานการณ์ที่เกิดขึ้นบ่อยในองค์กรดิจิทัลต่างๆ เช่น

บริษัทต้องการเพิ่มจำนวนผู้ใช้ที่สมัครสมาชิกในแอป แต่ conversion rate ต่ำมาก องค์กรที่มีโครงสร้างการทำงานที่ดี PM จะเริ่มจากการตั้งโจทย์ เช่น

* ผู้ใช้หยุดใช้งานในขั้นตอนใด?

* กระบวนการสมัครสมาชิกซับซ้อนเกินไปหรือไม่?

* ผู้ใช้ไม่เข้าใจคุณค่าของบริการหรือไม่? เป็นต้น

จากนั้นทีม Designer จะนำข้อมูลเหล่านี้ไปทดลองออกแบบหลายรูปแบบ เช่น

* ลดจำนวนขั้นตอนในการสมัคร

* เปลี่ยนข้อความอธิบายคุณค่า

* ทดลองวางตำแหน่งปุ่มใหม่

“ก่อนที่จะนำ prototype ไปทดสอบกับผู้ใช้จริงกระบวนการนี้เรียกว่า Product Discovery ซึ่งช่วยลดความเสี่ยงก่อนที่จะลงทุนพัฒนาเต็มรูปแบบ”

แต่หากองค์กรกลับปล่อยให้แต่ละฝ่ายทำงานแยกกัน และมีกระบวนการทำงานของตัวเองเป็นไซโล ปัญหาจะเกิดขึ้นอย่างชัดเจน เช่น

* PM ใช้เวลาหลายสัปดาห์เขียน requirement document ยาวหลายหน้า แล้วส่งต่อให้ทีม Design โดยคิดว่านี่คือการ "ส่งงาน" ให้ทีมออกแบบ

* ขณะเดียวกัน ทีม Design ก็เริ่มทำงานจาก requirement นั้นทันที โดยไม่ได้มีโอกาสเข้าไปทำความเข้าใจปัญหาของลูกค้า หรือเห็นข้อมูลเชิงพฤติกรรมที่ PM วิเคราะห์ไว้

สถานการณ์แบบนี้เกิดขึ้นบ่อยมากในองค์กรใหญ่ เพราะแต่ละทีมมี KPI และกระบวนการของตัวเอง เช่น

* PM ทำ backlog และ requirement ของตัวเอง

* ส่วนทีม Design ก็มี design sprint หรือ workflow ของตัวเอง

* ผลลัพธ์คือสองทีมทำงาน "ขนานกัน" แต่ไม่ได้ทำงาน "ร่วมกัน"

ตัวอย่างที่พบได้จริง เช่น PM ระบุ requirement ว่า ต้องการเพิ่มปุ่มสมัครสมาชิกให้เด่นขึ้น เพราะ conversion ต่ำ ทีม Design ก็อาจทำหน้าจอใหม่ที่ปุ่มใหญ่ขึ้น สีชัดขึ้น แต่ปัญหาที่แท้จริงของผู้ใช้ อาจไม่ใช่ตำแหน่งปุ่มเลย แต่อาจเป็นเพราะขั้นตอนสมัครซับซ้อนเกินไป หรือผู้ใช้ไม่เข้าใจว่าการสมัครให้ประโยชน์อะไร?

เมื่อ PM และ Designer ไม่ได้ร่วมกันทำความเข้าใจปัญหาตั้งแต่ต้น การออกแบบจึงกลายเป็นเพียงการ "ตกแต่ง solution" ที่ถูกตั้งสมมติฐานไว้แล้ว ไม่ใช่การค้นหา solution ที่ดีที่สุดให้กับผู้ใช้ ผลลัพธ์ที่เกิดขึ้นคือสิ่งที่เรียกว่า Design Theater หรือการออกแบบที่ดูดี แต่ไม่ได้แก้ปัญหาจริง

ในขณะเดียวกัน หาก PM พยายามควบคุมงานออกแบบทั้งหมด โดยไม่เปิดพื้นที่ให้ Designer ใช้ความเชี่ยวชาญ ผลลัพธ์ก็มักจะเป็นโปรดักต์ที่ใช้งานยาก เพราะการตัดสินใจไม่ได้มาจากความเข้าใจผู้ใช้

ดังนั้นในองค์กรที่ทำ Product Management อย่างมีประสิทธิภาพ PM และ Designer จึงต้องทำงานเหมือน คู่คิดทางกลยุทธ์ (Strategic Partners)

* PM ทำหน้าที่กำหนดทิศทางของผลิตภัณฑ์

* Designer ทำหน้าที่ทำให้ทิศทางนั้นกลายเป็นประสบการณ์ที่ผู้ใช้ต้องการ

* เมื่อสองบทบาทนี้ทำงานร่วมกันอย่างถูกต้อง ผลิตภัณฑ์จึงไม่เพียงสวยงาม แต่ยังใช้งานง่าย และแก้ปัญหาของผู้ใช้ได้จริง

====

4. “Engineering” = ไม่ต้องเขียนโค้ดเป็น แต่ต้องเข้าใจข้อจำกัดของเทคโนโลยี

Product Manager ไม่จำเป็นต้องเป็นโปรแกรมเมอร์ แต่ก็ไม่สามารถเป็นคนที่ไม่เข้าใจเทคโนโลยีเลยได้เช่นกัน เพราะการตัดสินใจของ PM จำนวนมากเกี่ยวข้องกับ “ความเป็นไปได้ทางเทคนิค” ของสิ่งที่กำลังจะสร้าง

ในหลายองค์กร ปัญหาที่เกิดขึ้นบ่อยคือ PM เสนอแนวคิดที่ดูดีในเชิงธุรกิจ แต่ไม่สอดคล้องกับสภาพของระบบจริง เช่น ผู้บริหารอาจต้องการให้เพิ่มฟีเจอร์แบบ real‑time หรือระบบ recommendation ขั้นสูง แต่ระบบที่ใช้อยู่ถูกพัฒนามานานหลายปีและมีข้อจำกัดด้านโครงสร้าง

หาก PM ไม่เข้าใจข้อจำกัดเหล่านี้ การวาง roadmap อาจกลายเป็นการ “วาดฝันบนกระดาษ” มากกว่าการวางแผนที่ทำได้จริง

ตัวอย่างสถานการณ์ที่พบได้บ่อย เช่น

บริษัทต้องการเพิ่มฟีเจอร์ใหม่ในแอปพลิเคชันเพื่อแข่งขันกับคู่แข่ง PM จึงกำหนด roadmap ว่าฟีเจอร์นี้ควรเปิดตัวภายในสองเดือน แต่เมื่อทีมวิศวกรรมประเมินจริงกลับพบว่าโครงสร้างระบบเดิมไม่รองรับ ต้องแก้ architecture หลายส่วน

ผลลัพธ์ที่เกิดขึ้นมักเป็นดังนี้

* ทีมพัฒนาต้องทำงานเร่งรีบเพื่อให้ทัน timeline

* คุณภาพของระบบลดลง

* และฟีเจอร์ใหม่อาจสร้างปัญหาให้ระบบเดิม

“สถานการณ์เช่นนี้เกิดขึ้นบ่อยเมื่อ PM กับทีมวิศวกรรมไม่ได้พูดคุยกันตั้งแต่ต้น หรือ PM ไม่เข้าใจภาพรวมของระบบ”

อีกแนวคิดสำคัญที่ PM ต้องเข้าใจคือ technical debt หรือ “หนี้ทางเทคนิค” ซึ่งเกิดขึ้นเมื่อทีมพัฒนาต้องเร่งสร้างฟีเจอร์ใหม่โดยไม่มีเวลาแก้ไขโครงสร้างระบบเดิม

* ในระยะสั้น technical debt อาจช่วยให้พัฒนาได้เร็วขึ้น

* แต่หากสะสมมากขึ้นเรื่อยๆ ระบบจะเริ่มเปราะบาง แก้ไขยาก และทุกฟีเจอร์ใหม่จะใช้เวลานานขึ้น

ตัวอย่างที่เกิดขึ้นจริงในหลายองค์กรคือ ช่วงแรกทีมสามารถปล่อยฟีเจอร์ใหม่ได้ทุกสองสัปดาห์ แต่เมื่อระบบเติบโตโดยไม่มีการ refactor โค้ด ระยะเวลาในการพัฒนาอาจเพิ่มเป็นหลายเดือน ดังนั้น PM ที่ทำงานกับทีมวิศวกรรมอย่างมีประสิทธิภาพจึงต้องเข้าใจทั้ง

* ข้อจำกัดของ architecture

* trade‑off ระหว่างความเร็วกับความเสถียร

* และความจำเป็นของการจัดสรรเวลาให้ทีมแก้ technical debt

เมื่อ PM เข้าใจมิติทางเทคนิคมากพอ การสนทนากับทีมวิศวกรรมจะไม่ใช่การ “สั่งงาน” แต่จะกลายเป็นการร่วมกันตัดสินใจว่า

* สิ่งใดควรสร้างก่อน

* สิ่งใดควรเลื่อนออกไป

* และสิ่งใดควรหยุดทำ

เพราะในโลกของการสร้างผลิตภัณฑ์ เทคโนโลยีไม่ใช่เพียงเครื่องมือในการพัฒนา แต่เป็นข้อจำกัดสำคัญที่กำหนดทิศทางของผลิตภัณฑ์ด้วย

====

PM ที่แท้จริงคือศิลปะแห่งการ “เชื่อมจุด”

เมื่อมองจากภาพรวม บทบาทของ Product Manager ไม่ใช่การพยายามเป็นผู้เชี่ยวชาญที่สุดในทุกด้าน แต่คือการเชื่อมโยงองค์ความรู้จากหลายสาขาเข้าด้วยกัน เพื่อสร้างผลิตภัณฑ์ที่แก้ปัญหาของผู้ใช้ และสร้างคุณค่าให้กับธุรกิจ

องค์กรที่เข้าใจบทบาทของ PM อย่างแท้จริงจึงไม่ได้วัดความสำเร็จจากจำนวนฟีเจอร์ที่ปล่อยออกสู่ตลาด แต่ดูจาก ผลลัพธ์ทางธุรกิจและคุณค่าที่ลูกค้าได้รับ

เพราะผลิตภัณฑ์ที่ยิ่งใหญ่ไม่ได้เกิดจากการทำตามรายการงานให้ครบ แต่เกิดจากการตั้งคำถามที่ถูกต้อง เลือกสิ่งที่สำคัญจริงๆ และกล้าปฏิเสธสิ่งที่ไม่สร้างคุณค่า

"Product Manager ที่แท้จริง ไม่ได้มีหน้าที่ทำให้ทุกคนพอใจ แต่มีหน้าที่ทำให้ผลิตภัณฑ์ประสบความสำเร็จ"

#วันละเรื่องสองเรื่อง  #ProductManagement #BusinessStrategy #EmpoweredTeams #TechEconomics #OrganizationalDesign