บทบาทผู้จัดการผลิตภัณฑ์คือความผิดพลาด
(sollecitom.github.io)- หากบริษัทซอฟต์แวร์ผลิตภัณฑ์เข้าใจ product-led ผิดว่าเป็น “โครงสร้างที่ PM ตัดสินใจทุกอย่าง” ก็จะกลายเป็นการเอาโมเดลที่เหมาะกับผู้นำแบบผู้ก่อตั้งที่พิเศษมาก ไปใช้กับ PM สายอาชีพทั่วไป
- วิธีมอบอำนาจควบคุมผลิตภัณฑ์ให้ผู้นำคนเดียว ประเด็นสำคัญไม่ใช่แค่ตัวรูปแบบเอง แต่คือ มอบให้ใคร โดยตั้งอยู่บนสมมติฐานว่ามีคนหายากที่มีวิสัยทัศน์ คาริสม่า ความสามารถทางเทคนิค และความเชื่อมั่นแรงกล้า
- เมื่อ PM ทั่วไปได้อำนาจมากเกินไป ข้อมูล กรอบแนวคิด ขั้นตอนอนุมัติ การประชุม และโครงสร้างบทบาท จะไม่ใช่เครื่องมือช่วยตัดสินใจอีกต่อไป แต่กลายเป็นเกราะกำบังสำหรับ การเลี่ยงความรับผิดชอบและการเมืองในองค์กร
- กระแสแบบนี้ทำให้คนเก่งจริงทยอยออกจากบริษัท และบริษัทก็ติดอยู่กับงานความเสี่ยงต่ำกับกระบวนการภายใน จนค่อย ๆ สูญเสียทั้ง วิสัยทัศน์และพรสวรรค์
- ทางเลือกไม่ใช่โครงสร้างที่ยึดตำแหน่ง PM เป็นศูนย์กลาง แต่คือการรวม คนที่หมกมุ่นกับเทคนิคและคุณภาพ ในแต่ละด้านมาอยู่ทีมเดียวกัน เพื่อร่วมกันดูแล product discovery, observability, engineering, design, business และความรู้เชิงโดเมน
ปัญหาของการเข้าใจ product-led ว่าเป็นโครงสร้างผูกขาดโดย PM
- บริษัทซอฟต์แวร์ผลิตภัณฑ์จำนวนมากมักก่อตั้งโดยคนที่เก่งเรื่อง การระดมทุน และเข้าใจอุตสาหกรรมเป้าหมาย มากกว่าคนที่มีประสบการณ์สร้างซอฟต์แวร์ผลิตภัณฑ์อย่างลึกซึ้ง
- ผู้ก่อตั้งแบบนี้เริ่มต้นบริษัทจากประสบการณ์ในอุตสาหกรรมและความสัมพันธ์ที่มีอยู่ แต่ถ้ายังนำการตัดสินใจทุกอย่างด้วยตัวเอง ความมั่นใจแบบผู้เชี่ยวชาญโดเมนอาจกลับกลายเป็นผลเสียต่อบริษัท
- ผู้ก่อตั้งบางคนยอมรับว่าตัวเองอาจเป็นความเสี่ยง จึงจ้างคนมารับผิดชอบการตัดสินใจแทน
- ตรงนี้มักเกิดความเข้าใจผิดว่า “เราต้องเป็นบริษัทผลิตภัณฑ์ ไม่ใช่องค์กรบริการ และบริษัทผลิตภัณฑ์ก็ต้องเป็น product-led ดังนั้น PM ต้องรับผิดชอบ”
- แต่ product-led ในที่นี้ไม่ได้หมายความว่า PM ต้องเป็นคนตัดสินใจทุกอย่าง
- เมื่อมีคนโต้แย้ง ก็มักมีการยกบริษัทชั้นยอดอย่าง Amazon, Apple, Tesla ขึ้นมาแย้งว่า บริษัทดี ๆ ก็ให้อำนาจควบคุมกับคนคนเดียวเหมือนกัน
- บริษัทที่ยอดเยี่ยมจำนวนมากมอบอำนาจควบคุมให้บุคคลเพียงคนเดียวก็จริง แต่ก็ไม่ใช่ว่าทุกบริษัทที่ยอดเยี่ยมจะใช้โมเดลเดียวกัน
เงื่อนไขตั้งต้นของโมเดลผู้ตัดสินใจคนเดียว
- โมเดลที่มอบอำนาจควบคุมบริษัทให้คนคนเดียว ไม่ได้ผิดในตัวมันเอง แต่ความสำเร็จหรือความล้มเหลวขึ้นอยู่กับว่า ให้ใครถืออำนาจนั้น
- คนอย่าง Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo เป็นบุคคลที่ผู้คนยกย่องจากวิสัยทัศน์ คาริสม่า ความมั่นใจ ความทรหด และความยอดเยี่ยม
- พวกเขาเป็นคนประเภทที่จินตนาการความจริงอีกแบบหนึ่งได้ ทุ่มเทกับงานของตัวเองอย่างสุดขีด และสร้างการเปลี่ยนแปลงครั้งใหญ่ด้วยแรงผลักดันของตนเอง
- ถ้ามีคนแบบนี้อยู่จริง โมเดลอำนาจควบคุมแบบรวมศูนย์ที่คนเดียวสามารถทำงานได้อย่างทรงพลัง
บุคคลที่พิเศษมากไม่ใช่ PM ทั่วไป
- บุคคลผู้ยิ่งใหญ่เหล่านี้ไม่ใช่ product manager
- พวกเขาเป็นศิลปิน นักคณิตศาสตร์ นักประดิษฐ์ นักวิทยาศาสตร์ หรือ CEO และบางครั้งก็มีหลายบทบาทพร้อมกัน
- คนเหล่านี้ยึดติดกับ วิสัยทัศน์และทักษะของตัวเอง มากกว่า OKR, KPI, ข้อมูล หรือความคิดเห็นของคนอื่น
- บุคคลที่พิเศษมากอาจมีความเห็นชัดเจน อีโก้สูง มีวิธีของตัวเอง ดิบกระด้าง และดูแคลนความธรรมดา
- ด้วยลักษณะแบบนี้ บริษัททั่วไปจึงจ้างได้ยาก และเจ้าตัวเองก็มักไม่อยากทำงานในบริษัทส่วนใหญ่
- หากหาคนระดับนั้นเจอ ไม่ขัดขวางเขา และทนรับความเข้มข้นของเขาได้ ก็อาจมอบอำนาจควบคุมผลิตภัณฑ์และบริษัทให้ได้
- แต่ในโลกจริง การหาคนแบบนั้นเป็นเรื่องยาก และต่อให้หาเจอ พวกเขาอาจไม่อยากร่วมงาน หรือบริษัทเองก็อาจรับมือกับอีโก้และความเข้มข้นของพวกเขาไม่ไหว
เมื่อเอาโครงสร้างที่ออกแบบมาสำหรับคนระดับมหากาพย์ไปใช้กับ PM ทั่วไป
- ความผิดพลาดใหญ่ที่สุดคือการนำโมเดลการดำเนินงานที่ต้องการ บุคคลพิเศษมาก มาใช้โดยไม่มีบุคคลแบบนั้นอยู่จริง
- มีการวิจารณ์ว่า PM สายอาชีพที่บริษัทจ้างได้อย่างสบายใจ ส่วนใหญ่มักไม่ใช่คนระดับนั้น
- มักถูกมองว่าเป็นลูกมือฝ่ายธุรกิจ ผู้ศรัทธาใน framework ผู้เชี่ยวชาญเฉพาะเรื่อง อดีตคนทำของที่ไต่บันไดองค์กร คนเสพติดตัวชี้วัด หรือคนจบ MBA
- หากเข้าใจ “product-led” ว่าหมายถึง PM ตัดสินใจทุกอย่าง แล้วจ้าง PM สายอาชีพมาใช้งาน ผลลัพธ์อาจร้ายแรงมาก
- เพราะ PM กลุ่มนี้ขาดวิสัยทัศน์ คาริสม่า ความเชี่ยวชาญ ความเชื่อมั่นแรงกล้า และความสามารถทางเทคนิค จึงมักเคลื่อนตัวอย่างปลอดภัยและเล่นการเมือง
- เมื่อรู้ตัวว่าตัวเองมีข้อจำกัด ก็จะเกิดพฤติกรรมพยายามรับเครดิต แต่หลบเลี่ยงความรับผิดซ้ำ ๆ
เมื่อข้อมูลและกระบวนการกลายเป็นเครื่องมือป้องกันตัว
- ขั้นแรกคือการทำให้ data-driven decision making กลายเป็นอาวุธ
- ไม่ยอมรับว่าคุณสามารถหาข้อมูลมาสนับสนุนข้ออ้างได้แทบทุกแบบ แต่กลับทำให้ดูเหมือนว่าการตัดสินใจของตัวเองเท่านั้นที่สมเหตุสมผลตามข้อมูล
- หากงานผิดพลาด ก็โทษตลาด คุณภาพข้อมูล หรือความโชคร้ายของบริษัท แล้วอ้างว่าไม่ใช่ความรับผิดชอบของตัวเอง
- ขั้นถัดมาคือการใส่ framework และบทบาทลงไปในทุกสิ่ง
- มีทั้งกรอบสายอาชีพ 18 ขั้น การประเมินผลงานรายไตรมาส, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe
- การไม่ทำตามกระบวนการ ไม่ data-driven เอกสารไม่พอ หรือเอกสารไม่อัปเดต กลายเป็นเหตุผลสำหรับการตำหนิ
- ในองค์กรจะเริ่มมีบทบาทอย่าง Director of KPIs, Deputy Director of Product Operations, Global Head of Digital Whiteboard Solutions
- ทุกอย่างต้องขออนุมัติ และไม่มีใครคนเดียวควบคุมกระบวนการหรือขอบเขตงานใดได้อย่างแท้จริง
- ในคณะกรรมการใหญ่ ๆ ทุกคนพูดว่า “no” ได้ แต่ไม่มีใครพูด “yes” ได้อย่างเต็มที่
- การประชุมก็พุ่งสูงขึ้น
- ทั้งรายงานสถานะ การประชุม alignment, 1:1, การประชุม staff, การคุยเชิงกลยุทธ์, การตั้งบริบท, release go/no-go, รายงานโครงการ
- ขั้นสุดท้ายคือการจ้างคนไม่ดีเข้ามาจำนวนมาก
- เกณฑ์จ้างคือคนคนนั้นดูไม่เป็นภัยคุกคามหรือไม่ และร่องรอยของความยอดเยี่ยมกลับกลายเป็นเหตุผลที่ถูกปฏิเสธ
- ผู้สมัครในอุดมคติคือคนสารพัดประโยชน์ที่ทำงานตามสั่งพอถูไถได้ โดยไม่โต้แย้งและไม่สนใจคุณภาพ
- จำนวน PM จะเพิ่มขึ้นอย่างรวดเร็ว และเกิดลำดับชั้นของ PM ในทุกทีมทุกขอบเขต พร้อมทำพฤติกรรมเดิมซ้ำไปเรื่อย ๆ
สิ่งที่องค์กรสูญเสียไป
- เมื่อกระแสที่คนธรรมดาได้อำนาจเริ่มต้นขึ้น คนที่ยอดเยี่ยมจริง ก็จะจากไปในที่สุด
- พวกเขาอาจถูกเบียดออกโดยเผด็จการแบบคนธรรมดา หรือทนสภาพแวดล้อมไม่ไหวจนเลือกออกเอง
- ความเร็วในการทำงานจะหยุดชะงัก และการลงมือทำอะไรก็ตามจะกลายเป็นความเจ็บปวด เป็นคำมั่นสัญญาใหญ่โต และเป็นความเสี่ยงอันตราย
- วิสัยทัศน์ขนาดใหญ่จะถูกมองว่าไม่สมจริง และถูกทิ้งอย่างรวดเร็ว
- สิ่งที่บริษัททำจะจำกัดอยู่แค่งานที่เก็บได้ง่ายและตัวเลือกที่ปลอดภัย
- แม้แต่คนที่ไม่ได้หลงใหลในงานฝีมือของตัวเองมากนักก็ยังรู้สึกทรมานและจากไป ส่วนคนที่ด้านพอจะอยู่ต่อได้ก็ยิ่งทำให้ปัญหาแย่ลง
- บริษัทจะสูญเสียคนเก่งที่สุด ลืมวิสัยทัศน์ หันเข้าหาตัวเอง และค่อย ๆ ไร้ความหมาย
- ในกรณีดีที่สุด มันตายลงในสักจุดหนึ่ง และในกรณีเลวร้ายที่สุด มันจะอยู่รอดแบบครึ่ง ๆ กลาง ๆ พร้อมเปลี่ยนคนที่เคยมีไฟให้กลายเป็นซอมบี้ที่เกลียดงานตัวเอง
ทางเลือกคือทีมของคนที่ยอดเยี่ยมในชีวิตประจำวัน
- นอกจากการพยายามหาบุคคลพิเศษมากมาจ้าง มอบอำนาจควบคุมให้ และทนรับความเข้มข้นของเขาแล้ว ก็ยังมีวิธีสร้างบริษัทผลิตภัณฑ์ที่ประสบความสำเร็จได้
- ทางเลือกคือการจ้าง คนที่ยอดเยี่ยมอย่างสม่ำเสมอในชีวิตจริง
- แต่ละคนต้องเก่งในบางด้าน
- ต้องหมกมุ่นกับทักษะของตัวเองและขับเคลื่อนด้วยคุณภาพ
- ควรจัดทีมให้ขอบเขตความยอดเยี่ยมของแต่ละคนทับซ้อนกันน้อยที่สุด
- แทนที่จะแยกความรับผิดชอบเป็นชิ้นเล็ก ๆ ตามตัวบุคคล ก็ควรปล่อยให้พวกเขาได้ทำงานที่รักอย่างสนุก และใช้เวลาและทักษะของตนเพื่อบริษัท
- คนประเภทนี้ก็อาจท้าทาย ดื้อ อีโก้สูง แปลก และอารมณ์แปรปรวนได้เช่นกัน
- แต่ถ้าให้ปัญหาที่ดีและเปิดโอกาสให้ทำงานที่ยอดเยี่ยม พวกเขาจะทุ่มเทต่อความสำเร็จของบริษัทอย่างเต็มที่
ตำแหน่งที่ผู้นำและ PM ควรอยู่
- ไม่จำเป็นต้องเลิกมีผู้นำไปเสียทั้งหมด อาจตัด team lead ออก และให้ lead ของแต่ละขอบเขตทำหน้าที่ประสานงานระหว่างภายนอกกับภายในก็ได้
- หากจะมีผู้นำรับผิดชอบในแต่ละขอบเขต ก็ควรให้บทบาทนั้นตกเป็นของ คนที่ใกล้เคียงกับบุคคลผู้ยิ่งใหญ่
- หมายถึงคนที่ใกล้กับ Jobs, Musk, Bezos ในแง่วิสัยทัศน์ คาริสม่า ความเข้มข้น ความหลงใหล และความสุดโต่งในการลงมือทำ
- ถ้าตั้งคนที่สบายในระยะสั้น ทำตามคำสั่งเก่ง และไม่ต้องการความใส่ใจมาก มาเป็นผู้รับผิดชอบ ก็เสี่ยงจะตกไปอยู่ในสภาพที่กล่าวมาทั้งหมดก่อนหน้านี้
- บทบาท PM ในความหมายดั้งเดิมถูกมองว่าไม่มีที่ทางในบริษัทที่ทำงานได้ดี
- อย่างไรก็ดี ยังจำเป็นต้องมีคนที่หมกมุ่นกับด้านอย่าง product discovery หรือ product observability ซึ่งเดิมมักมอบให้ PM ดูแล
- คนเหล่านี้อาจเคยมีตำแหน่ง PM มาก่อน และนั่นไม่ใช่ปัญหา
- เหตุผลที่จ้างคือความหมกมุ่นและจุดแข็ง ไม่ใช่ชื่อตำแหน่ง
- แทนที่จะแยกพวกเขาไว้ในบทบาท PM โดยเฉพาะ ควรให้ไปอยู่ทีมเดียวกับคนที่หมกมุ่นกับ engineering, design, performance, business และความรู้เชิงโดเมน
ไม่ใช่ปัญหาของ PM อย่างเดียว
- หากคนที่ไม่มีวิสัยทัศน์ คาริสม่า ความหลงใหล ความสามารถทางเทคนิค หรือพลังใจ ได้กลายเป็นผู้รับผิดชอบ ปัญหาแบบเดียวกันก็จะเกิดขึ้น
- เหตุผลที่บทความนี้โฟกัสที่ PM ก็เพราะในการพัฒนาซอฟต์แวร์ผลิตภัณฑ์ มีแนวโน้มจะตั้งคนที่มีตำแหน่ง product manager ขึ้นมาเป็นผู้รับผิดชอบ
- PM บางคนพิเศษจริง และอาจทำได้ดีมากในทั้งสองโมเดล
- แต่ก็ไม่ได้หมายความว่า PM แบบนั้นจะต้องทำได้ดีกว่าคนเก่งจากพื้นเพอื่นเสมอไป
- PM แบบนั้นมีอยู่น้อยมาก และมุมมองนี้เห็นว่า PM สายอาชีพส่วนใหญ่ยังห่างไกลจากความสามารถในการนำด้วยความยอดเยี่ยม
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
บริษัทที่ผมอยู่ตอนนี้มีคนฉลาดมากมาย แต่ด้วยเหตุผลหลายอย่างเราไม่มี ผู้จัดการผลิตภัณฑ์ และผลก็คืองานที่ผู้จัดการผลิตภัณฑ์ควรทำกลับไม่ได้ถูกทำเลย
แทบไม่มีวิศวกรคนไหนอยากทำงานอย่างการรักษาความสัมพันธ์กับลูกค้า สัมภาษณ์ผู้ใช้ ค้นหาฟีเจอร์ที่อาจเป็นไปได้ โน้มน้าวผู้บริหาร หรือเล่นการเมืองเพื่อจัดสรรทรัพยากร
ที่บริษัทก่อนหน้า ผู้จัดการผลิตภัณฑ์ 2 ใน 3 คนไร้ความสามารถจนถูกไล่ออก แต่มี 1 คนที่เก่งจริง ๆ และเพียงเวลาบางส่วนของคนนั้นก็ทำงานภายใน 1 ปีได้มากกว่าที่บริษัทปัจจุบันทำมานานกว่า 2 ปี
ผมเห็นด้วยว่าเรามีผู้จัดการผลิตภัณฑ์ที่ดีไม่พอ จำนวนคนที่มีแววเป็นผู้จัดการผลิตภัณฑ์ที่ดีน่าจะเพิ่มตามจำนวนประชากรแบบเส้นตรง แต่ индустрซอฟต์แวร์เติบโตระเบิดแบบทวีคูณ จนต้องการ บทบาท PM มากกว่า PM ที่ยอดเยี่ยมจริง ๆ ถึง 100 เท่า
พวกเขาไม่ถนัดด้านเทคนิคด้วย จึงไม่ได้จัดการตั๋ว Jira ส่วนการบริหารผู้บริหารก็ส่วนใหญ่เป็นหน้าที่ของผู้จัดการ
เท่าที่เห็น ผู้จัดการผลิตภัณฑ์เหล่านั้นหลัก ๆ คือเข้าประชุม คุยกับผู้บริหาร คุยกับวิศวกร เขียนเอกสาร และเป็นประธานการประชุมวางแผนสปรินต์ที่ยืดยาว
ถ้าเป็นผู้จัดการผลิตภัณฑ์ที่จัดการประเด็นลูกค้า ผู้ใช้ และทรัพยากร ก็คงมีคุณค่ากว่ามาก
ผมได้ยินอยู่เรื่อย ๆ ว่า “เราเป็นบริษัทที่ให้ความสำคัญกับวิศวกรรมก่อน” แต่ในความเป็นจริงหมายถึงทีมวิศวกรรมต่าง ๆ ไล่ตามแต่เทคโนโลยีล่าสุดตามใจตัวเอง
มีผลิตภัณฑ์หลัก 3.5 ตัว หรือจริง ๆ แล้วแทบจะ 4.5 ตัว ซึ่งแต่ละตัวสร้างด้วย tech stack คนละชุดกัน และยังมีผลิตภัณฑ์อีกประมาณ 8 ตัวที่ต้องรองรับเพราะข้อกำหนด legacy ไม่มีการทำมาตรฐานหรือ interoperability ระหว่างผลิตภัณฑ์ และไม่มีการถ่ายทอดความรู้ ทำให้ต้นทุนการพัฒนาพุ่งทะลุเพดาน
ปีนี้ถึงสองครั้ง ผมต้องอธิบายให้วิศวกรที่อยู่มา 20 ปีฟังว่า ทำไมการที่ API บางตัวใช้เฉพาะ TLS 1.3 บางตัวเป็น 1.x และบางตัวไม่บังคับใช้ TLS เลยนั้นเป็นเรื่องแย่
ลูกค้าเกลียดเรา ผลิตภัณฑ์ของผมเริ่มจากเขียนสื่อการตลาดไว้ก่อน แล้วปล่อยให้วิศวกรไปสร้างเอาเอง ขั้นตอนเดียวในการย้ายข้อมูล Oracle ไปเป็น parquet ถูกทำด้วยภาษาสามภาษาและฐานข้อมูลกลางสองตัว (MySQL กับ PG) แถมผมยังต้องห้ามไม่ให้ใส่ Redis เข้าไปอีก
โชคดีที่เมื่อ 2 ปีก่อนบริษัท private equity เข้ามาซื้อ และตอนนี้เราได้รับคำขาดว่าถ้าทำเงินไม่ได้ก็จบ บริษัทอายุ 20 ปีนี้เป็น cost center ที่ไม่เคยทำเงินได้เลย และต่อให้เราพลาดเป้า ผมก็คิดว่าจักรวาลน่าจะดีขึ้นถ้า มหันตภัยด้านการออกแบบซอฟต์แวร์ ที่เราสร้างไว้หายไป
ผู้จัดการผลิตภัณฑ์ที่ไม่ฉลาดจะกลายเป็นกึ่งผู้จัดการโครงการที่คอยติดตามสมุดบัญชีงานอีกชุดหนึ่ง ส่วนคนฉลาดจะเข้าใจธุรกิจอย่างลึกซึ้งจนได้เลื่อนตำแหน่งหรือไม่ก็ออกไป
บทบาทนี้กำกับดูแลก็ยาก บางครั้งได้เครดิตก้อนใหญ่จากงานของคนอื่น และบางครั้งกลับไม่ได้รับเครดิตเลยจนเส้นทางอาชีพหยุดนิ่ง
ถ้าโยนบทบาทนี้ไปให้วิศวกรรม การจัดการวิศวกรรม หรือการจัดการทั่วไป ความสามารถด้านวิศวกรรมจะอ่อนลง ถ้าจะจ้างวิศวกรก็ควรคัดจากความสามารถนั้นและปกป้องพวกเขาจากคนนอก แต่ถ้าทีมต้องจัดการการปฏิสัมพันธ์เหล่านั้นด้วย ก็จะลงเอยด้วยการจ้างคนที่มีความสามารถแบบผสม และสุดท้ายด้านวิศวกรรมก็ถูกเจือจาง
การจงใจทำให้เวลาของผู้จัดการผลิตภัณฑ์ตึงมืออาจเป็น กลไกบังคับ ให้โฟกัสกับระดับภาพรวมและวิสัยทัศน์ และหลีกเลี่ยงการลงลึกเกินไปจนสร้างกระบวนการไร้ประโยชน์หรือกำหนดฟีเจอร์ละเอียดเกินจำเป็น
ในวงการเทคโนโลยีที่พองตัวจาก การเติบโตยุคดอกเบี้ยต่ำ มานานกว่า 10 ปี หลายคนก็ประสบความสำเร็จได้เพียงแค่ไปทำงานเท่านั้น
เป็นบทความที่ชวนสับสน บอกว่า “ควรยกเลิกบทบาท PM” แต่ก็ยังบอกว่า “ยังจำเป็นต้องมีคนที่รับผิดชอบงานที่ PM เคยทำโดยเฉพาะ แต่อย่าเรียกว่า PM เรียกแบบธรรมดาว่าเป็นคนที่เก่งยอดเยี่ยมก็พอ”
ดูเหมือนผู้เขียนมีประสบการณ์ไม่ดีกับ PM และพอเห็นพูดถึง MBA ก็เห็นร่องรอยนั้น เลยเหมือนจะโยนเด็กทิ้งไปพร้อมน้ำอาบ
เมื่อธุรกิจมีขนาดใหญ่ขึ้น การทำให้บทบาทเฉพาะทางก็เกิดขึ้นและจำเป็นขึ้นมา มี PM แย่ ๆ อยู่จริง และเป็นงานที่ยาก แต่ถ้าทีมของเรา เสีย PM ไป ผมคงผิดหวังมากจริง ๆ
อาจเป็นเพราะผมเคยมีแต่ประสบการณ์ดีกับ PM ก็ได้ แต่ PM ในบริษัทเราจะทำความเข้าใจว่าลูกค้าต้องการอะไรและผลิตภัณฑ์ควรให้อะไร แล้วร่วมกับ engineering manager ปรับสมดุลว่าทางเทคนิคทำได้หรือไม่และมีแรงพอจะลงมือทำหรือเปล่า
ถ้า engineering manager บอกว่า “กำหนดการนี้ไม่มีทางได้แน่” PM ก็จะหา แผนทางเลือก สำหรับผลิตภัณฑ์
บทความนี้ดูเหมือนข้ามขั้นตอนตรงกลางไป แล้วแค่พยายาม เปลี่ยนชื่อเท่านั้น โดยไม่มีเหตุผล
แล้วคิดว่าใครกันแน่เป็นคนตัดสินว่าทีมควรให้ความสำคัญกับปัญหาไหนก่อน? นั่นแหละคือ ความรับผิดชอบหลักของบทบาท PM
สุดท้ายก็ดูเหมือนเคยมีประสบการณ์ไม่ดีกับ PM ที่ตัดสินลำดับความสำคัญนั้นไม่ได้
แต่เพราะคนนั้น ผมต้องเข้าไปร่วมประชุมที่กระอักกระอ่วนที่สุดครั้งหนึ่งเท่าที่เคยเข้ามา โดยตลอดหนึ่งชั่วโมงตั้งแต่ต้นจนจบ เขาเผยต่อหน้าผู้บริหารระดับสูงว่าไม่เข้าใจผลิตภัณฑ์เลยสักนิด ขณะที่ผู้บริหารระดับสูงคนนั้นเข้าใจผลิตภัณฑ์
PM ที่ดีช่วยได้มาก เพราะเข้าใจสิ่งที่ลูกค้าต้องการ สิ่งที่เราส่งมอบได้ กำหนดการที่เป็นจริงได้ รวมถึงการรับมือกับฝ่ายกฎหมายและผู้มีส่วนได้ส่วนเสียทางธุรกิจ ส่วนผมช่วยพวกเขาเมื่อต้องตรวจสอบด้านเทคนิค
ทีมแทบไม่เคยขาดไอเดียที่จะสร้าง หรือวิธีปรับปรุงประสบการณ์ด้านผลิตภัณฑ์และการปฏิบัติการ product manager คือคนที่พยายามทำให้ทีม สร้างสิ่งที่ถูกต้อง
ผมเป็น PM ที่มีประสบการณ์ IT 20 ปี และกำลังพิจารณาเรียน MBA เพื่อให้ได้ความรู้และความเข้าใจธุรกิจอย่างเป็นทางการ รวมถึงช่วยให้เติบโตต่อไป
PM ที่คล้ายกับผมไม่ได้เริ่มเล่นเกมทำเรื่องไร้สาระทันทีที่ได้ MBA ถ้ายืมสำนวนแบบทหารมาใช้
ปัญหาคือคนที่เดินตรงจากมัธยม มหาวิทยาลัย MBA แล้วไปตำแหน่งบริหารเลย ต่างหาก ถ้าไม่นับการฝึกงานสั้น ๆ ระหว่างปริญญาตรี หลายคนไม่มีประสบการณ์หน้างานแม้แต่วันเดียว
เป็นบทความแปลก ๆ ใช้คำพูดมากมาย แต่สุดท้ายเหมือนจะบอกแค่ว่า “ถ้าจ้างคนผลงานต่ำก็เป็นโทษต่อบริษัท”
ทางเลือกที่เสนอก็เป็นแนวว่า “จ้างคนดี ๆ แต่อย่าจ้างในบทบาท PM”
อ่านแล้วเหมือนเขียนโดยคนที่มีประสบการณ์ไม่ดีกับ PM ที่คิดว่าตัวเองเป็น Steve Jobs ทั้งที่ PM ก็เป็นคนธรรมดา ไม่เข้าใจว่าทำไมถึงสมมติว่าคนที่มีตำแหน่งนี้ทุกคนเป็นพวกคิดว่าตัวเองมีอภิสิทธิ์
ในองค์กรอาจมี PM เป็นพันคน และแต่ละคนก็มีหัวหน้าอยู่ เป็นแค่ บทความแปลก ๆ จริง ๆ
ประมาณว่า “อย่าจ้าง product manager เพราะพวกเขาคงไม่ใช่คนยอดเยี่ยม ให้จ้างคนยอดเยี่ยมแทน แถมไม่ใช่แค่คนเดียว แต่ทั้งทีมเลย!”
จ้างคนผลงานต่ำกันทุกวัน แต่ก็ไม่รู้ว่าทำไม ชิมแปนซีที่ไม่ได้รับการฝึกถือกองเรซูเม่อาจมีอัตราทายถูกดีกว่าด้วยซ้ำ
PM ตอบโจทย์ความต้องการที่เฉพาะมาก ความต้องการนั้นวัดเป็นตัวเลขได้ยาก แต่พูดได้ว่าถ้าไม่มี PM ที่ดี ทุกอย่างจะพัง
โดยทั่วไปพวกเขาจะรวบรวมข้อมูลจากผู้ใช้ว่าอะไรเวิร์กหรือไม่เวิร์ก ฟังจากผู้บริหารว่าสิ่งใดจำเป็นต่อการดำเนินงานของบริษัท เข้าใจจากผู้นำในอุตสาหกรรมว่าอุตสาหกรรมกำลังมุ่งไปทางไหน ทำงานกับฝ่ายออกแบบ แล้วกลั่นทั้งหมดนี้ออกมาเป็นฟีเจอร์ที่ต้องสร้างจริง ๆ
อีกทั้งยังทำงานร่วมกับ engineering เพื่อประเมินว่าอะไรทำได้จริง ใช้เวลาประมาณเท่าไร ตัดฟีเจอร์ที่ใช้เวลามากแต่มีคุณค่าน้อยออก และช่วยให้การประมาณการกับความเร็วของทีมคาดการณ์ได้ในระดับหนึ่ง
แค่นี้ก็อธิบายงานไปแล้วเท่ากับงาน 1.5 คน ถ้าตัดองค์กรผลิตภัณฑ์ออก งานทั้งหมดนี้จะกระจายไปที่ทีม engineering ซึ่งไม่ใช่ทุกคนในทีมจะทำงานนี้ได้ดี
ต่อให้หาสมดุลได้ แต่เมื่อมีคนหนึ่งลาออก ก็จะเกิด ช่องว่างที่มองไม่เห็น ซึ่งตอนจ้างงานก็ไม่ได้มองหาไว้ด้วยซ้ำ
ดูเหมือนหลายทีมจะเจ็บช้ำจากองค์กรผลิตภัณฑ์ที่ทำงานผิดปกติ องค์กรแบบนั้นดูเหมือนตัดขาดจากหรือไม่สนใจฝั่งลูกค้า อุตสาหกรรม และองค์กร แต่กลับเผาเวลามหาศาลไปกับการประชุมวนซ้ำเรื่อง mockup, micromanage ดีไซเนอร์จนคนดี ๆ ลาออก และผูกวิศวกรไว้กับการประชุมผลิตภัณฑ์ที่ไม่จำเป็น
PM ทำงานอย่างใกล้ชิดกับทีมเพื่อกำหนด roadmap และจัดลำดับความสำคัญของงานที่จะสร้างผลกระทบมากที่สุดต่อลูกค้าและธุรกิจ
ถ้า PM ทำงานได้ดี วิศวกรจะเข้าใจชัดเจนมากว่าปัญหาต่อไปที่ต้องแก้คืออะไร และทำไมต้องแก้
อย่างที่สอง สิ่งสำคัญคือมีสถานะภายในองค์กรพอที่จะสื่อสารกับผู้บริหารระดับสูงเกี่ยวกับโครงการหรือไม่ ถ้ามีครบทั้งสองอย่างนี้ ก็ถือว่าอยู่ในสภาพที่ดี
สิ่งที่ได้เรียนรู้จากการทำงานในวงการเทคโนโลยีมากกว่า 12 ปี คือ “บทบาท” เป็นเพียงวิธีที่องค์กรใช้แสดงความต้องการของตนเท่านั้น
ถ้าอยากให้ใครสักคนคิดในเชิงผลิตภัณฑ์ ก็เปิดตำแหน่ง PM; ถ้าอยากได้ผู้นำทีม ก็สร้างตำแหน่ง Engineering Manager
ตำแหน่งงานเป็นองค์ประกอบสมมติที่ทำให้เราเล่น RPG ที่เรียกว่า “งาน” ได้จากหลายมุม สุดท้ายแล้ว สิ่งที่แต่ละคนนำไปสู่ที่ทำงานคือส่วนผสมเฉพาะตัวของพรสวรรค์และประสบการณ์
บางคนมักข้ามเส้นแบ่งของบทบาทเหล่านี้ และนั่นก็ไม่เป็นไร พวกเขามีไอเดีย และยังสร้างตำแหน่งของตัวเองขึ้นมาได้ด้วย
องค์กรควรฉลาดพอที่จะปล่อยให้คนแบบนั้นเติบโตและรุ่งเรืองได้ นี่ไม่ได้หมายความว่า PM จะประสบความสำเร็จหรือทำงานดี ๆ ไม่ได้ แต่หมายความว่าโดยทั่วไปองค์กรไม่ได้ลงทุนเวลามากพอที่จะทำความเข้าใจคนที่รับเข้ามาอย่างลึกซึ้ง จึงมอบ บทบาทสำเร็จรูป ให้ล่วงหน้า
วิศวกรก็ทำบทบาทของ PM ได้ แต่ไม่ได้คิดทุกอย่างจากมุม PM เพราะตัวตนหลักของเขาไม่ใช่ PM แต่เป็นวิศวกร
อีกอย่างที่เพิ่งตระหนักในบริบทของการข้ามเส้นบทบาทคือ โดยมากแล้วส่วนที่มีคุณค่าที่สุดของบทบาทคนคนหนึ่งคือความรับผิดชอบที่ไม่ได้ถูกนิยามไว้อย่างชัดเจน
อธิบายยาก แต่ผู้คนมักสร้างคุณค่าในแบบที่บรรยายหรือวัดเป็นตัวเลขได้ยาก
โดยรวมแล้วเป็นมุมมองที่ค่อนข้าง harsh แต่ก็มีส่วนที่ถูกอยู่ชัดเจน เมื่อมี องค์กรผลิตภัณฑ์ เกิดขึ้นในบริษัท ก็มักไหลไปสู่คณะกรรมการ, OKR, รอบการรีวิว, การวางแผน และระบบราชการจำนวนมาก เหมือนที่ผู้เขียนบรรยายไว้
ก่อนหน้านี้ผม/ฉันอยู่ในบทบาท sales engineering ที่พบลูกค้าโดยตรง และกำลังผลักดันผลิตภัณฑ์ได้สำเร็จมากผ่านอิทธิพล จึงรับงาน Product Manager อย่างไร้เดียงสา เพราะคิดว่าจะได้อำนาจควบคุมอย่างเป็นทางการ
แต่พอได้นั่งตำแหน่งจริง ๆ กลับเป็นงานออฟฟิศที่ถูกจำกัดอย่างสุดขีด และไม่เข้ากับผม/ฉันเลย งานส่วนใหญ่คือจัดการ ticket กับ backlog, ประสานงานแทนการตัดสินใจ, ทำรายงาน PowerPoint ไม่รู้จบ และงานที่สร้างสรรค์ที่สุดคือการสร้างกระบวนการให้บริษัททำ product roadmap อย่างเป็นทางการ ผม/ฉันหนีออกมาหลัง 6 เดือน
ฟังก์ชันนี้ค่อนข้างมีประโยชน์ในการให้การมองเห็นว่าสิ่งใดกำลังถูกสร้าง และจัดการลำดับความสำคัญที่ขัดแย้งกันของผลิตภัณฑ์ที่กำลังเติบโต แต่มันไม่ใช่งานกำหนดรูปทรงหรือควบคุมทิศทางวิวัฒนาการของผลิตภัณฑ์
มันคือฟังก์ชันการจัดเรียง การกรอง และถ้าโชคดีก็การรวบรวมข้อมูล เป็นบทบาทที่สร้างร่องรอยการตัดสินใจที่ตรวจสอบย้อนหลังได้ และสร้างภาพลักษณ์ของการตัดสินใจที่มีวุฒิภาวะ เพื่อให้บรรดา MBA ข้างบนหลับสบายขึ้นอีกนิด
โดยปกติจะทำข้อเสนอฟีเจอร์ใหม่ (PRD) เดือนละ 4–12 ฉบับ จำนวนต่างกันไปตามขนาดบริษัทและปริมาณกระบวนการที่จำเป็น
รูปแบบมักเป็น “ผู้ใช้มีปัญหา X อยู่ตอนนี้ และเพื่อแก้ปัญหานั้น เราควรสร้าง Y โดย Y จะมีหน้าตาแบบนี้…”
แน่นอนว่ามีความยากเรื่องการประสานงานและการสื่อสาร แต่ทั้งหมดก็เพื่อหาว่าควรสร้างอะไรต่อไปเสมอ
ผม/ฉันเข้าใจว่าไม่ใช่บทบาท PM ทุกที่เป็นแบบนี้ แต่ไม่เห็นด้วยกับคำกล่าวที่ว่า PM ไม่มีทางดีไปกว่า “การจัดแนว/การกรอง/ละครเวทีว่าการตัดสินใจมีวุฒิภาวะ”
ถ้ามันเป็นแค่บทบาทจัดลำดับ backlog ที่มีอยู่ ผม/ฉันก็สงสัยว่าใครเป็นคนกำหนดรายการใหม่ที่จะใส่เข้าไปใน backlog
เห็นด้วยว่าองค์กรผลิตภัณฑ์อาจกลายเป็นตัวตนทางการเมืองและระบบราชการ แทนที่จะเป็นฝ่ายสนับสนุน
โดยส่วนตัว ผม/ฉันคิดว่าบทบาทผลิตภัณฑ์ควรถูกฝังอยู่ในทีมวิศวกรรม และรายงานต่อผู้นำคนเดียวกัน ระดับตำแหน่งอาจถกเถียงกันได้ แต่ด้วยวิธีนี้ PM ที่แย่ก็จะถูกจัดการได้เหมือนวิศวกรที่แย่
แน่นอน ถ้าบริษัทไล่วิศวกรที่แย่ออกไม่ได้ด้วย นั่นก็เป็นอีกปัญหาหนึ่ง
ผู้เขียนไม่ได้เสนอเฟรมเวิร์กสำหรับเรื่องนี้ไว้มากนัก
ทางออกในบทความมีกลิ่นของ ทฤษฎีมหาบุรุษ
ช่วงท้ายที่ว่า “คนที่ยอดเยี่ยมจินตนาการถึงความเป็นจริงทางเลือก ทุ่มเทให้กับงานอย่างสมบูรณ์ และย้ายภูเขาด้วยพลังใจ” นั้นลดทอนความจริงเกินไป
สิ่งที่ย้ายภูเขาไม่ใช่พลังใจ แต่คือคนระดับล่างที่นำวิสัยทัศน์ไปลงมือทำจริง อย่างดีที่สุด “คนผู้ยิ่งใหญ่” คนนั้นก็แค่จัดแรงจูงใจให้สอดคล้อง เพื่อให้ผู้ลงมือทำจริงและผู้เชี่ยวชาญขยับตัว
ตอนนี้ทำงานอยู่ในบริษัทเทคโนโลยีขนาดใหญ่ที่แทบไม่มีบทบาท PM เลย จึงบอกความรู้สึกจากประสบการณ์ตรงได้
จนถึงตอนนี้ผลออกมาปะปนกัน ผม/ฉันเคยทำงานในองค์กรที่มี PM เยอะ และเห็นด้วยว่าองค์กรแบบนั้นไม่ค่อยดีนัก แต่สุดท้ายงานที่ PM ทำก็ยังจำเป็นอยู่
ในองค์กรของเรา ความรับผิดชอบนั้นตกอยู่กับผู้จัดการซอฟต์แวร์และนักพัฒนาระดับ senior ขึ้นไปอย่างเป็นทางการ
เช่น ถ้าเป็น senior engineer ที่นำ initiative ของทีม ก็ต้องรับผิดชอบกิจกรรมทั้งหมดที่ PM เคยทำ กิจกรรมอื่น ๆ ผู้จัดการหรือ senior manager จะรับไป
จากมุมมองของนักพัฒนา นี่ค่อนข้างหนัก ต้องทำงานของตัวเองในฐานะ individual contributor ให้สำเร็จ ขณะเดียวกันก็ต้องประสานคนอื่นและทำให้แน่ใจว่างานเสร็จ
ไม่ใช่แค่งานเพิ่มเท่านั้น แต่พูดตรง ๆ นักพัฒนาหลายคนไม่มีทักษะที่จะเป็น PM ที่มีประสิทธิภาพ การทำงานข้ามทีมก็ยากขึ้น เพราะต้องประสานกับคนที่อยู่คนละสายรายงาน
วิธีนี้มักนำไปสู่การขาด ownership, ขาด accountability, ความพยายามซ้ำซ้อน, งานที่หลุดรอดไปตามช่องว่าง และความไร้ระเบียบโดยรวม
อย่างไรก็ตาม มันทำงานได้ดีสำหรับ initiative ภายในทีมเล็ก ๆ ที่มีคนเข้าร่วมไม่กี่คน เพราะตัด overhead ของ PM ออกและให้คนที่สร้างสิ่งนั้นมีอำนาจควบคุม แต่ยังไม่มั่นใจว่าเหมาะกับ initiative ที่ใหญ่กว่านี้หรือไม่
จริงที่นักพัฒนาหลายคนไม่มีทักษะ PM ที่มีประสิทธิภาพ แต่ถ้าพูดอย่างเป็นธรรม PM จำนวนมากก็ไม่มีทักษะ PM ที่มีประสิทธิภาพเช่นกัน
ความยากในการประสานกับคนที่อยู่คนละสายรายงานก็เป็นเรื่องเดียวกันสำหรับ PM
ความแตกต่างหลักดูเหมือนอยู่ที่การตัดสินว่า “งานนี้คุ้มไหมที่จะแยกออกมาเป็นบทบาทเต็มเวลา” ส่วนตัวผม/ฉันมักคิดว่าแทบไม่คุ้มสำหรับวิศวกร
เห็นแค่หัวข้อก็เตรียมจะไม่ชอบแล้ว คิดว่าจะเป็นบทความแบบเดิม ๆ ที่ว่า “PM โง่ และบริษัทควรมีแค่วิศวกรฉลาด ๆ ที่ครองโลกได้ก็พอ”
แต่จริง ๆ ไม่ใช่บทความแบบนั้น และผมคิดว่ามันชี้ปัญหาได้เกือบสมบูรณ์แบบ
แต่ทางแก้กลับหายวับไปเหมือนโบกมือผ่าน ๆ ประมาณว่า “จ้างคนธรรมดาที่เก่งอย่างยอดเยี่ยมในบางเรื่อง หมกมุ่นกับทักษะของตัวเอง และขับเคลื่อนด้วยคุณภาพ เอามารวมเป็นทีม แล้วให้ทำงานโดยไม่มีความรับผิดชอบรายบุคคล”
ฟังดูดี แต่ในโลกจริง ใครพอจะยกตัวอย่างบริษัทที่มี มากกว่า 100 คน แล้วทำวิธีนี้สำเร็จได้บ้าง? ผมนึกไม่ออกว่ามันจะทำงานได้จริงอย่างไร
Valve ดูเหมือนทำ หรืออย่างน้อยก็เคยทำอะไรที่คล้ายกันมาก คู่มือพนักงาน[0] เคยเป็นของประจำใน HN สมัยก่อน แต่ช่วงนี้ไม่ค่อยเห็นแล้ว สงสัยเหมือนกันว่ามันยังเวิร์กสำหรับพวกเขาอยู่ไหม
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
ผู้เขียนคงเคยทำงานกับผู้จัดการผลิตภัณฑ์ที่ธรรมดามากจริง ๆ ผมเป็น PM ที่มีพื้นฐานวิศวกรรมแบบเรียนด้วยตัวเอง และก็เคยเห็นคนธรรมดา ๆ มาเยอะในหลายสายงาน
ผมมองงานของตัวเองหลัก ๆ ว่าเป็น การจัดการความเสี่ยง แม้แต่ทีมวิศวกรและดีไซเนอร์ที่ยอดเยี่ยมก็ยังต้องเจอความเสี่ยงมากมายระหว่างการปล่อยผลิตภัณฑ์ที่ดี
พวกเขาอาจไม่มีทักษะในการอธิบายวิสัยทัศน์เพื่อโน้มน้าวคนอื่น หรือทีมกฎหมายอาจกำหนดข้อกำหนดหรือข้อจำกัดว่าอะไรทำได้และทำไม่ได้
งานของผมคือจัดการสิ่งเหล่านั้นเพื่อดึงจุดแข็งของทีมออกมา และช่วยให้ทีมโฟกัสกับงานที่สำคัญจริง ๆ นั่นคือการสร้างและปล่อยผลิตภัณฑ์ที่ดี
ผมตัดสินความสำเร็จจากการที่ตัวเองกลายเป็นคนไม่จำเป็นได้มากแค่ไหน เป้าหมายคือทำให้ทีมไม่ต้องพึ่งผม ให้ทีมมีบริบท ความมั่นใจ และการสนับสนุนพอที่จะตัดสินใจดี ๆ ได้แม้ไม่มีผม
ผมชอบทำงานร่วมกับวิศวกรเพื่อให้พวกเขาพัฒนาความสามารถแบบนั้น และทำงานกับพาร์ตเนอร์ที่เป็นผู้จัดการฝ่ายวิศวกรรมเพื่อทำความเข้าใจจุดแข็ง จุดอ่อน และเป้าหมายของวิศวกรแต่ละคน แล้วหาวิธีช่วยให้เติบโต
ผมเข้าใจข้อโต้แย้งที่ว่าในยูโทเปียอุดมคติ ผมอาจไม่จำเป็นเลยก็ได้ แต่ในกรณีส่วนใหญ่ ถ้าจะทำงานที่ยอดเยี่ยมจริง ๆ ก็ต้องเผชิญความท้าทายและความเสี่ยง และ PM ที่ดีคือ ผู้เพิ่มคุณค่าสุทธิ ที่ร่วมมือกับทีมเพื่อช่วยให้ก้าวข้ามสิ่งเหล่านั้นไปได้
คือทำให้ทีมมีบริบท ข้อกำหนด อินไซต์ เมตริก เป้าหมาย ฯลฯ ที่จำเป็นต่อการทำงานที่ดีที่สุด และเข้าใจว่าควรแก้ปัญหาอะไร แก้ให้ใคร และทำไมต้องแก้
PM ที่ดีสร้างสภาพแวดล้อมได้ดีจนวิศวกรคิดว่า “PM ไม่ได้ทำอะไรเลย เลยไม่จำเป็น” การตัดสินแบบนั้นมองสั้น และพูดตรง ๆ ก็ค่อนข้างดูถูกกัน