เลิก ‘ก๊อปปี้’ แล้วหันมาสร้าง ‘ดีเอ็นเอ’ ของตัวเอง
🏗️ “Product Operating Model ขององค์กร” = เลิก ‘ก๊อปปี้’ แล้วหันมาสร้าง ‘ดีเอ็นเอ’ ของตัวเอง
เมื่อ ‘ชื่อตำแหน่งไม่เท่ากับหน้าที่’ และ ‘การมี Engineer ในห้องประชุม’ สำคัญกว่าที่คุณคิด
ตลอดทศวรรษที่ผ่านมา แทบทุกองค์กรล้วนประกาศตัวว่าเป็น Tech Company หรืออย่างน้อยก็อยู่ระหว่าง Digital Transformation คำศัพท์อย่าง Agile, Scrum, Spotify Model, Squad–Tribe–Chapter–Guild ถูกหยิบมาใช้ราวกับเป็นคัมภีร์ลัดสู่ความสำเร็จ ผู้บริหารจำนวนไม่น้อยเชื่อโดยบริยายว่า หากโครงสร้างองค์กรและกระบวนการทำงานมี ‘หน้าตาเหมือน’ บริษัทเทคโนโลยีระดับโลก ผลลัพธ์ทางธุรกิจย่อมต้องดีขึ้นตามไปด้วย
แต่เรื่องจริงกลับพบว่า การก๊อปปี้ Org Chart ไม่เคยทำให้องค์กรใดกลายเป็น Spotify, Google หรือ Amazon ได้ สิ่งที่มักเกิดขึ้นคือ ได้ชื่อตำแหน่งใหม่ ได้พิธีกรรมใหม่ ได้ศัพท์เทคนิคใหม่เต็มห้องประชุม แต่คุณค่าที่ส่งถึงลูกค้า (Customer Value) และผลลัพธ์ทางธุรกิจ (Business Outcome) กลับไม่ขยับ หรือบางครั้งถอยหลังด้วยซ้ำ
Marty Cagan ผู้เชี่ยวชาญด้าน Product ระดับโลก และผู้เขียนหนังสือ Transformed: Moving to the Product Operating Model(2024) ชี้ให้เห็นอย่างตรงไปตรงมาว่า องค์กรส่วนใหญ่ไม่ได้ล้มเหลวเพราะขาดคนเก่งหรือเทคโนโลยี แต่ล้มเหลวเพราะ หลงทางไปกับ ‘รูป แบบ’ มากกว่า ‘สาระ’ ติดกับดักพิธีกรรม (Rituals) และชื่อตำแหน่ง (Titles) จนลืมคำถามสำคัญที่สุดว่า
“เรากำลังสร้าง Product ที่แก้ปัญหาจริงให้ลูกค้า และสร้างคุณค่าให้ธุรกิจอยู่หรือไม่?”
บทความนี้จึงไม่ได้ชวนคุณลอกใคร แต่ชวนกลับมาตั้งคำถามเชิงระบบว่า Product Operating Model ที่เหมาะกับองค์กรของคุณควรถูก “ออกแบบ” อย่างไร และอะไรคือแก่นแท้ที่ไม่ควรถูกลดทอนเหลือแค่โครงสร้างบนสไลด์
⸻
1. Product Manager ≠ คนรับออเดอร์
กับดักที่พบบ่อยที่สุดในองค์กรที่อ้างว่าทำ Product คือการลดบทบาท Product Manager ให้เหลือเพียง ‘คนจัดเรียง Backlog’ หรือ ‘คนเขียน Ticket’ ตามคำสั่งจากบนลงล่าง โดยเฉพาะในองค์กรที่ตีความบทบาท Product Owner แบบแคบ จนกลายเป็นตำแหน่งเชิงปฏิบัติการล้วนๆ
ใน Product Operating Model ที่แข็งแรง Product Manager ไม่ได้ถูกจ้างมาเพื่อ “บริหารงาน” แต่ถูกจ้างมาเพื่อ รับผิดชอบการตัดสินใจที่ยาก และผลลัพธ์ที่ตามมา บทบาทนี้ต้องแบกรับคำถามสำคัญสามมิติพร้อมกัน ได้แก่
* Value: สิ่งที่กำลังจะสร้าง มีคุณค่ากับลูกค้าจริงหรือไม่ หรือเป็นเพียงสมมติฐานจากห้องประชุม
* Viability: สิ่งนี้สอดคล้องกับโมเดลธุรกิจ กลยุทธ์ และข้อจำกัดขององค์กรหรือไม่
* Accountability: หากผลลัพธ์ไม่เป็นไปตามคาด ใครคือคนที่ต้องอธิบาย เรียนรู้ และปรับทิศทาง
Product Manager ในความหมายนี้ จึงไม่ใช่ผู้ประสานงาน แต่คือ เจ้าของปัญหา และ เจ้าของผลลัพธ์ อย่างแท้จริง
หาก Product Manager ของคุณยังต้องรอคำสั่งว่าจะ ‘ให้ทำฟีเจอร์อะไร?’ บทบาทนั้นอาจไม่ต่างจาก Project Manager ที่เปลี่ยนชื่อเรียก และองค์กรกำลังหลอกตัวเองว่าได้ทำ Product แล้ว
⸻
2. คืนเก้าอี้ให้ Engineer ในห้องตัดสินใจ
หนึ่งในความผิดพลาดเชิงโครงสร้างที่ร้ายแรงที่สุด คือการมอง Engineer เป็นเพียง Executor หรือผู้รับคำสั่ง ทั้งที่ในความเป็นจริง Engineer คือกลุ่มคนที่เข้าใจข้อจำกัดและศักยภาพของเทคโนโลยีมากที่สุดในองค์กร
คำถามที่ควรถามคือ คนที่ทำให้ Product เป็นจริงได้คือ Engineer แล้วเหตุใดพวกเขาถึงไม่ได้นั่งอยู่ในห้องที่ตัดสินใจว่าจะสร้างอะไร?
* ใน Product Operating Model ที่มีประสิทธิภาพ Engineer ต้องมีบทบาทมากกว่าการประเมิน Feasibility พวกเขาควรมีส่วนร่วมตั้งแต่ขั้น Discovery ตั้งแต่การตั้งคำถาม การทดลองแนวทาง ไปจนถึงการเสนอวิธีแก้ปัญหาที่ผู้บริหารอาจมองไม่เห็นจากมุมกลยุทธ์
* นวัตกรรมจำนวนมากไม่ได้เกิดจาก PowerPoint แต่เกิดจาก Engineer ที่รู้ว่าเทคโนโลยีสามารถ “พลิกเกม” ปัญหาเดิมได้อย่างไร การตัด Engineer ออกจาก Roadmap จึงไม่ใช่แค่ปัญหาด้านวัฒนธรรม แต่คือการตัดโอกาสทางนวัตกรรม ขององค์กรทิ้งไปโดยไม่รู้ตัว
⸻
3. Product Designer คือคนที่ทำให้ได้มากกว่าความสวย คือการทำให้คุณค่า ‘เข้าถึงได้’
ในหลายองค์กร Product Designer ยังถูกจำกัดบทบาทไว้ที่การทำ UI ให้สวย หรือขยับพิกเซลตาม Requirement ที่ถูกส่งต่อมาจากเอกสารสเปก แต่ใน Product Operating Model ที่แท้จริง บทบาทนี้คือผู้รับผิดชอบ ‘ประสบการณ์’ (Experience) ทั้งระบบ ตั้งแต่จุดที่ลูกค้ายังไม่รู้จัก Product ไปจนถึงวันที่ตัดสินใจใช้ต่อหรือเลิกใช้
* ลองนึกภาพแอปธนาคารสองแอปที่ฟังก์ชันใกล้เคียงกัน แอปแรกมีปุ่มสวย สีดี แต่ลูกค้าโอนเงินผิดบัญชีบ่อย หาเมนูไม่เจอ และไม่แน่ใจว่าธุรกรรมสำเร็จหรือยัง ส่วนอีกแอปหนึ่งหน้าตาอาจไม่ได้หวือหวา แต่ลำดับขั้นตอนชัด เตือนก่อนกดผิด และทำให้ผู้ใช้ “มั่นใจ” ทุกครั้งที่กดใช้งาน แอปหลังต่างหากที่ Product Designer ทำหน้าที่ไ ด้ครบถ้วน
* Product Designer ต้องตอบคำถามให้ได้ว่า ลูกค้าจะเข้าใจคุณค่า (Value) ของ Product นี้ได้อย่างไร จะใช้งานอย่างไรโดยไม่สับสน และจะรู้สึกอย่างไรเมื่อมีปฏิสัมพันธ์กับมัน งานของเขาจึงไม่ใช่เรื่องศิลปะล้วนๆ แต่คือการผสมผสานระหว่างพฤติกรรมมนุษย์ เทคโนโลยี และบริบทการใช้งานจริง
ตัวอย่างเช่น หากองค์กรต้องการเพิ่ม Conversion การสมัครสมาชิก คำถามของ Designer ไม่ใช่ “ปุ่มสมัครควรเป็นสีอะไร” แต่คือ “ผู้ใช้ลังเลตรงไหน? ทำไมยังไม่สมัคร? และเราจะลดแรงเสียดทานนั้นอย่างไร?” ซึ่งอาจจบด้วยการลดขั้นตอน เพิ่มคำอธิบาย หรือออกแบบ Flow ใหม่ทั้งหมด
“ความสวยงามจึงเป็นเพียงผลลัพธ์ปลายทาง ไม่ใช่เป้าหมายหลักของบทบาทนี้”
⸻
4. มิติที่ขาดกันไม่ได้ คือ “Strategy – Discovery – Delivery”
สาเหตุที่การก๊อปปี้โมเดลของคนอื่นมักล้มเหลว เพราะแต่ละองค์กรมีบริบททางธุรกิจ คน และวัฒนธรรมที่ต่างกัน สิ่งที่ควรทำไม่ใช่การ Adopt โมเดลสำเร็จรูป แต่คือการ Design Product Operating Model ของตัวเอง โดยยึดสามมิติสำคัญที่ต้องทำงานเชื่อมกันตลอดเวลา
* Product Strategy: เราเลือกแก้ปัญหาอะไร? และเหตุใดปัญหานี้จึงสำคัญต่อธุรกิจมากกว่าปัญหาอื่น? เช่น บริษัทหนึ่งอาจมีไอเดียฟีเจอร์เป็นสิบ แต่ Strategy จะช่วยตัดสินว่า ฟีเจอร์ไหนส่งผลต่อรายได้ การเติบโต หรือความอยู่รอดมากที่สุด
* Product Discovery: เมื่อเลือกปัญหาแล้ว เราจะรู้ได้อย่างไรว่าวิธีแก้ที่คิดไว้ “ใช่จริง?” ไม่ใช่แค่เดา Discovery คือช่วงของการทดลอง พูดคุยกับลูกค้า ทำ Prototype ทดสอบ และยอมรับว่าความคิดแรกอาจผิด เพื่อเรียนรู้ให้เร็วและเสียต้นทุนน้อย
* Product Delivery: ต่อให้ไอเดียดีแค่ไหน หากทีมสร้างไม่ได้จริง หรือส่งมอบช้าเกินไป โอกาสทางธุรกิ จก็หายไป Delivery คือความสามารถในการสร้างของที่ใช้งานได้จริง มีคุณภาพ และส่งถึงมือลูกค้าอย่างสม่ำเสมอ
ลองนึกถึงทีมที่มี Strategy ชัด แต่ไม่ทำ Discovery พวกเขามักสร้างของที่ไม่มีใครใช้ ในทางกลับกัน ทีมที่ Discovery เก่งแต่ Delivery อ่อน จะได้แต่ Insight ดีๆ เต็มลิ้นชักแต่ไม่เคยออกสู่ตลาด และหากมี Delivery อย่างเดียวโดยไร้ Strategy ทีมจะยุ่งอยู่กับงานที่ไม่สร้างผลลัพธ์สำคัญ
“หากขาดมิติใดมิติหนึ่ง ทีมจะตกอยู่ในกับดัก คือสร้างของที่ไม่มีใครใช้ หรือสร้างไม่ทันจนเสียโอกาสทางธุรกิจ”
⸻
5. กับดักการสื่อสารกับผู้บริหาร?
หลายทีม Product มักบ่นว่าผู้บริหารไม่เข้าใจ Product ชอบสั่ง เปลี่ยนใจบ่อย หรือแทรกแซงรายละเอียด (Micro-management) แต่ Marty Cagan เคยกล่าวไว้ว่า “ปัญหานี้ในหลายกรณีไม่ได้อยู่ที่ผู้บริหาร แต่อยู่ที่วิธีสื่อสารของทีม Product เอง”
ลองจินตนาการบทสนทนาสองแบบ
* แบบแรกคือ “ทีมอยากทำฟีเจอร์นี้ เพราะลูกค้าน่าจะชอบ” ผู้บริหารย่อมถามกลับทันทีว่า ทำไปทำไม คุ้มไหม และกระทบเป้าหมายบริษัทอย่างไร? “เมื่อคำตอบไม่ชัด สิ่งที่ตามมาคือคำสั่งและการควบคุม”
* อีกแบบหนึ่งคือ “เราพบว่าลูกค้ากลุ่มหลักเลิกใช้เพราะขั้นตอนนี้ และถ้าแก้ได้จะเพิ่มอัตราการใช้งานซ้ำ X% ซึ่งส่งผลต่อรายได้โดยตรง” บทสนทนาเช่นนี้เปลี่ยนบทบาทผู้บริหารจาก ‘คนสั่ง’ เป็น ‘คนสนับสนุน’ โดยอัตโนมัติ
“หากคุณอธิบายไม่ได้ว่าสิ่งที่คุณทำจะช่วยแก้ปัญหาทางธุรกิจได้อย่างไร คุณไม่มีทางได้อิสระในการตัดสินใจอย่างแท้จริง”
Product Operating Model ที่ดีต้องเชื่อมเป้าหมายของทีมเข้ากับเป้าหมายขององค์กร เมื่อภาษาที่ใช้คุยเปลี่ยนจาก Feature เป็น Outcome จาก Roadmap เ ป็น Impact รูปแบบการบริหารจะค่อยๆ ขยับจาก Command & Control ไปสู่ Empowermentอย่างเป็นธรรมชาติ และความเชื่อใจจะค่อย ๆ ถูกสร้างขึ้นจากผลงาน ไม่ใช่จากตำแหน่ง
⸻
ดังนั้น จงออกแบบ Process ให้เหมาะกับงาน (Job) ไม่ใช่บทบาท (Role)
การออกแบบ Product Operating Model ไม่ใช่การตามล่า Org Chart ที่สมบูรณ์แบบที่สุด แต่คือการกลับมาถามตัวเองอย่างซื่อสัตย์ว่า
* งานที่องค์กรต้องทำจริงๆ คืออะไร?
* เราใส่คนที่เหมาะสมเข้าไปในกระบวนการที่เอื้อให้เขาใช้ศักยภาพสูงสุดแล้วหรือยัง
* หยุดยัดเยียดชื่อตำแหน่งให้พนักงาน แต่จงมอบอำนาจและความรับผิดชอบในการแก้ปัญหา เพราะ Product Operating Model ไม่ได้อยู่บนกระดาษ แต่อยู่ในวิธีคิด วิธีตัดสินใจ และวัฒนธรรมการทำงานขององค์กร
การเปลี่ยนแปลง Product Operating Model ขององค์กรนั้น ไม่ได้หมายความแค่เปลี่ยนชื่อหรือโครงสร้างบนแผนภาพเท่านั้น แต่เป็นการสร้างวัฒนธรรมองค์กรและกระบวนการทำงานที่ตอบโจทย์บริบทและศักยภาพเฉพาะขององค์กรเองอย่างแท้จริง จากประสบการณ์ทำงานในสายเทคโนโลยีและการพัฒนาผลิตภัณฑ์ ผมพบว่าหลายองค์กรยังติดกับดักการเลียนแบบโมเดลองค์กรดัง ๆ โดยไม่ได้ตั้งคำถามว่า นโยบายหรือวิธีการที่นำมาใช้เหมาะสมกับสภาพจริงหรือไม่ หลายครั้งที่เห็น Product Manager ถูกลดบทบาทเป็นเพียงผู้รับคำสั่งส่งต่อให้ทีมทำงาน โดยขาดอำนาจตัดสินใจและรับผิดชอบผลลัพธ์ที่แท้จริง ส่งผลให้นวัตกรรมและความคิดสร้างสรรค์ไม่เกิดขึ้นจริง ในขณะเดียวกัน การดึง Engineer เข้าไปมีส่วนร่วมตั้งแต่ขั้น Discovery ช่วยให้องค์กรได้ไอเดียที่เป็นไปได้จริงทางเทคนิคและนวัตกรรมที่ซ่อนอยู่ เสริมความแข็งแกร่งให้กับโมเดลการทำงานไม่ใช่เพียงแค่กลไกทางรูปแบบ แต่เป็นความเข้าใจเชิงลึกของคนที่พัฒนา ทั้งนี้ Product Designer ก็เป็นส่วนสำคัญที่ช่วยให้คุณค่าและความต้องการของลูกค้าไม่หยุดอยู่แค่ฟีเจอร์หรือหน้าตาสวยงาม แต่เป็นการสร้างประสบการณ์ใช้งานที่สะดวก เข้าใจง่าย และเกิดความเชื่อมั่นในการใช้บริการ ผมอยากแนะนำให้องค์กรอย่าหลงลืมการสร้างความเชื่อมโยงระหว่าง "Strategy – Discovery – Delivery" ซึ่งเป็นหัวใจสำคัญ โมเดลนี้จะช่วยให้ทีมมีเป้าหมายชัดเจน รู้ว่าปัญหาไหนสำคัญที่สุด ทดสอบสมมติฐานก่อนลงมือพัฒนา และส่งมอบผลิตภัณฑ์ที่ได้มาตรฐานและตรงกับความต้องการตลาดอย่างแท้จริง สุดท้าย การสื่อสารกับผู้บริหารก็เป็นส่วนหนึ่งที่ทีม Product ต้องปรับตัว เพราะผู้บริหารต้องการข้อมูลที่ชัดเจนว่าผลิตภัณฑ์แก้ไขปัญหาอะไร สร้างผลลัพธ์อย่างไร เพื่อเปลี่ยนจากการควบคุมเป็นการสนับสนุน ส่งเสริมให้ทีมมีอิสระและความรับผิดชอบสูงสุด สรุปคือการออกแบบ Product Operating Model ที่เหมาะสมกับองค์กร คือการมองภาพรวมของงานจริงที่องค์กรต้องทำ ใส่คนที่ใช่ในบทบาทที่เหมาะสม และส่งเสริมให้เกิดวัฒนธรรมการทำงานที่ผสมผสานความคิดสร้างสรรค์ การวางแผน และการลงมือปฏิบัติได้อย่างสมดุล ซึ่งจะเป็นกุญแจสำคัญสู่การพัฒนาองค์กรที่ยืนหยัดและเติบโตอย่างยั่งยืน
