แนวโน้มที่ผลิตภัณฑ์เพิ่มขึ้น แต่ผู้จัดการผลิตภัณฑ์ลดลง
(kitemaker.co)- การถกเถียงว่าในทีมผลิตภัณฑ์ควรมี PM กี่คน เข้มข้นขึ้น หลังจาก Airbnb ปรับโครงสร้างองค์กร Product Management และมีกรณีสตาร์ทอัพที่เติบโตได้โดยไม่มี PM
- ยิ่งมี PM มากขึ้น อาจเกิดโครงสร้างที่ใช้เวลาไปกับ การจัดการโครงการและการอัปเดตโรดแมป มากกว่าผลลัพธ์ทางธุรกิจของผลิตภัณฑ์
- ในทีมที่มีดีไซเนอร์และวิศวกรที่มีประสบการณ์ งานของ PM ไม่จำเป็นต้องเป็นบทบาทแบบเต็มเวลาเสมอไป และโมเดลมี PM 1 คนต่อทีมก็ควรถูกทบทวนใหม่ตามสถานการณ์
- การจ้าง PM คนแรกมักพิจารณาเมื่อผู้ก่อตั้งเริ่มเข้าไปมีส่วนร่วมในการตัดสินใจสำคัญด้านผลิตภัณฑ์ทั้งหมดได้ยาก โดยทั่วไปอยู่ที่ขนาดองค์กร 50~100 คน และมีทีมผลิตภัณฑ์ 3~5 ทีม
- การเพิ่มจำนวน PM เพียงอย่างเดียวไม่ได้ทำให้องค์กรกลายเป็นองค์กรที่เน้นผลิตภัณฑ์ และอาจทำให้ ความรับผิดชอบต่อผลิตภัณฑ์ ที่ดีไซเนอร์และวิศวกรควรมีอ่อนลงด้วยซ้ำ
โครงสร้างที่ลดจำนวน PM และขยายความรับผิดชอบต่อผลิตภัณฑ์
- การถกเถียงเรื่องจำนวน PM ที่จำเป็นคึกคักขึ้นหลังจากมีบทความเกี่ยวกับการปรับโครงสร้างองค์กร Product Management ของ Airbnb และกรณีสตาร์ทอัพที่เติบโตได้แม้ไม่มี PM
- ในหลายบริษัท PM มักใช้เวลาในแต่ละวันไปกับงานอย่าง การจัดการโครงการ และการอัปเดตโรดแมป มากกว่าการปรับผลิตภัณฑ์ให้เหมาะกับธุรกิจ
- โดยทั่วไป จำนวน PM ควรน้อยกว่า จำนวนทีมผลิตภัณฑ์ และโครงสร้างที่มี PM 1 คนประจำทุกทีมควรถูกพิจารณาใหม่ตามสถานการณ์ของผลิตภัณฑ์และทีม
- หากมีงานด้านผลิตภัณฑ์จำนวนมากและทีมยังเป็นระดับจูเนียร์ ทีมหนึ่งอาจต้องมี PM แบบ dedicated
- ในทีมที่มีวิศวกรและดีไซเนอร์ที่มีประสบการณ์ บทบาท PM อาจไม่จำเป็นต้องเป็นงานเต็มเวลา หรืออาจไม่ควรเป็นเช่นนั้น
- ช่วงเวลาที่เหมาะสมในการจ้าง PM คนแรกในสตาร์ทอัพ คือเมื่อผู้ก่อตั้งเริ่มเข้าไปมีส่วนร่วมในการตัดสินใจสำคัญด้านผลิตภัณฑ์ทั้งหมดได้ยาก
- โดยทั่วไปใช้เกณฑ์เมื่อองค์กรมีขนาด 50~100 คน และมีทีมผลิตภัณฑ์ 3~5 ทีม
- กลยุทธ์ผลิตภัณฑ์โดยรวมควรชัดเจนอยู่แล้ว และ PM ควรเข้ามามีส่วนร่วมในการกำหนดทิศทางและการตัดสินใจในระดับที่ย่อยลงจากกลยุทธ์นั้น
- PM คนแรกควรเป็น Senior PM มากกว่า Junior PM หรือ CPO
- ผู้สมัครอาจเติบโตไปทำหน้าที่ CPO ได้เมื่อองค์กรขยายตัว แต่ผู้ก่อตั้งยังควรทำหน้าที่เป็นผู้รับผิดชอบผลิตภัณฑ์โดยพฤตินัยต่อไป
วิธีปฏิบัติในการสร้างทีมที่เน้นผลิตภัณฑ์
- ความรับผิดชอบต่อผลิตภัณฑ์ไม่ควรรวมอยู่ที่ PM เพียงคนเดียว และ Design กับ Engineering ก็ต้องเข้าใจผู้ใช้และบริบทของผลิตภัณฑ์โดยตรงด้วย
- ดีไซเนอร์และวิศวกรควรมีส่วนร่วมอย่างแข็งขันในการก่อรูปผลิตภัณฑ์ และนำการถกเถียงรายละเอียดด้านผลิตภัณฑ์
- PM ไม่ควรเป็นผู้รับผิดชอบแต่เพียงผู้เดียวด้าน UX, wireframe, การติดตามความคืบหน้า, การรัน standup, หรือการเขียน PRD/สเปก
- จุดโฟกัสของ PM คือการสื่อสารวิสัยทัศน์ผลิตภัณฑ์ การเลือกปัญหาที่ถูกต้อง การรักษาทิศทางผลิตภัณฑ์ และการปรับให้สอดคล้องกับความต้องการทางธุรกิจ
- “Guide to product development” ของ Michael Seibel เชื่อมโยงกับกรณีการนำแนวทางนี้ไปใช้ที่ Social Cam
- ทีมควรแชร์บริบทและเหตุผลในการตัดสินใจอย่างแข็งขัน
- Design และ Engineering ก็ควรเข้าถึง feedback จากผู้ใช้ได้เช่นกัน
- การแก้ปัญหาไม่ควรมี PM เป็นศูนย์กลาง แต่ควรเป็น การทำงานร่วมกัน ของ Product, Design และ Engineering
- วิธีปฏิบัติในการสร้างทีมที่มุ่งเน้นผลิตภัณฑ์สรุปได้เป็น 4 ข้อ
- เริ่มต้นร่วมกัน: ก่อนเขียน ticket หรือสเปก ก่อนกำหนดวิธีแก้ปัญหา ให้ Design, Engineering และ Product/ผู้ก่อตั้งหารือร่วมกันเพื่อปรับวิธีดำเนินงานและแผนให้ตรงกัน
- ให้ทุกคนได้สัมผัสผู้ใช้: ให้เข้าร่วม user research และ usability test โดยตรง หรือให้ดูภาพการใช้งานผลิตภัณฑ์ของผู้ใช้ผ่านวิดีโอสตรีมมิงหรือเครื่องมืออย่าง Lookback
- ระวังวิธีบริหารทีม: หากวัดผลงานด้วยจำนวน ticket ที่ปิดได้หรือ story point ทีมจะขับเคลื่อนไปตามการจัดการ ticket ไม่ใช่การสร้างผลิตภัณฑ์ที่ดี
- อย่าใช้เครื่องมือสำหรับ PM: หาก feedback จากผู้ใช้, insight, data, สเปก และโรดแมปถูกขังอยู่ในเครื่องมือสำหรับ PM แยกต่างหาก ทั้งทีมจะเข้าถึงบริบทของผลิตภัณฑ์ได้ยาก
- การพัฒนาผลิตภัณฑ์โดยธรรมชาติแล้วคาดการณ์ได้ยาก และสิ่งที่สำคัญกว่าการ deploy เองคือการ deploy สิ่งที่ถูกต้อง ซึ่งส่งผลต่อธุรกิจ
- ในบริษัทขนาดใหญ่ที่เน้นผลิตภัณฑ์ PM มีความสำคัญมาก แต่จำนวน PM ที่จำเป็นอาจถูกประเมินสูงเกินไปได้ง่าย และการเพิ่มจำนวน PM ไม่ได้หมายความว่าจะช่วยเพิ่มการโฟกัสที่ผลิตภัณฑ์โดยอัตโนมัติ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในฐานะผู้จัดการฝ่ายวิศวกรรมหรือหัวหน้าทีมตามสายงาน ผมเคยทำงานกับผู้จัดการผลิตภัณฑ์มาค่อนข้างนาน และยังเคยทำหน้าที่ PM ชั่วคราวให้ผลิตภัณฑ์ภายในของบริษัทเทคโนโลยีขนาดกลางด้วย
ผมมองว่า การจัดการผลิตภัณฑ์ เป็นหนึ่งในด้านที่สำคัญที่สุดของสิ่งที่บริษัททำ แต่เป็นงานที่ยากจริง ๆ และยิ่ง PM มีความสามารถไม่พอ ก็ยิ่งมีแนวโน้มจะหลุดห่างจากแก่นของงาน แล้วไหลไปสู่การ micromanage ทีมวิศวกรรมภายใต้ข้ออ้างว่า “นำ” ทีม หรือไม่ก็การเมืองภายในบริษัท
ในองค์กรที่ฝ่ายวิศวกรรมกับฝ่ายผลิตภัณฑ์แยกสายบังคับบัญชากัน ปัญหานี้รับมือได้ยาก และต่อให้ยกระดับปัญหาขึ้นไปข้างบน แบนด์วิดท์ของฝ่ายนั้นก็มักจำกัดมากโดยธรรมชาติ จากมุมของ EM แล้ว PM แบบนี้มักทำให้วิศวกรที่ดีที่สุดทุกข์ใจ และท้ายที่สุดก็มักลงเอยด้วยการที่พวกเขาลาออก
ตอนนี้ผมคิดว่าวิธีที่ดีที่สุดคือวาง PM ในรูปแบบ mini-CEO ไว้ในแต่ละทีม และถ้าความรู้ด้านเทคนิคยังไม่พอ ก็จับคู่กับ mini-CTO พื้นที่ให้การเมืองเข้ามาแทรกจะลดลงมาก และพื้นที่สำหรับการทำงานเป็นทีมจะเพิ่มขึ้นมาก
ทีมที่ประสบความสำเร็จที่สุดที่ผมเคยอยู่ไม่มีบทบาทผลิตภัณฑ์แบบเฉพาะทางเลย และการตัดสินใจทั้งหมดทำโดยนักพัฒนา
ตอนนี้ผมคิดว่าสิ่งที่ดีที่สุดคือกันคนที่ไม่ใช่สายเทคนิค รวมถึงคนที่พอรู้เทคนิคแบบครึ่ง ๆ กลาง ๆ ออกจากทางของนักพัฒนา เพื่อให้นักพัฒนาสร้างงานได้อย่างสงบ
สิ่งที่ผมเห็นคือผู้คนยืนยันทางเลือกของตัวเองและพยายามหาแรงสนับสนุน ผมไม่เคยเห็นการเมืองแบบที่ผู้คนบ่นกันเลย บางทีผมอาจแค่โชคดีก็ได้
การเมืองหมายถึงคนที่ในเชิงเทคนิคแล้วผิด แต่เสนอเหตุผลได้โน้มน้าวใจกว่าหรือเปล่า? “การเมือง” คืออะไร? หรือผมยังอยู่ตำแหน่งไม่สูงพอ แม้จะเป็น senior principal แล้วก็ตาม
บทความนี้และหลายคนที่พยายามวิเคราะห์หัวข้อนี้พลาดองค์ประกอบสำคัญอย่างหนึ่งไป นั่นคือ แรงจูงใจ
นักพัฒนาจำนวนมากมีแพสชันกับตัวเทคโนโลยีเองมากกว่า เช่น การเขียนโค้ด การแก้ปัญหาเทคนิคที่ซับซ้อน และการสร้างวิธีแก้ที่มีประสิทธิภาพ รางวัลอย่างเป็นทางการ เช่น การเลื่อนตำแหน่ง โบนัส และการยอมรับ ก็มักเชื่อมโยงกับความสำเร็จทางเทคนิคด้วย
หากนักพัฒนาใช้เวลา 40 ชั่วโมงไปกับการวิจัยลูกค้า พวกเขาอาจไม่ได้รับการยอมรับหรือรางวัลอย่างเป็นทางการเท่ากับผลงานทางเทคนิคอย่างการพัฒนาโซลูชันยืนยันตัวตนใหม่ที่ช่วยทั้งทีม
การเปลี่ยนพลวัตนี้ไม่ได้ทำได้แค่แนะนำให้นักพัฒนาใช้เวลากับการจัดการผลิตภัณฑ์มากขึ้น แต่ต้องมี การเปลี่ยนแปลงเชิงระบบ ว่าองค์กรให้คุณค่ากับอะไรและให้รางวัลอย่างไร
หากเปลี่ยนโครงสร้างแรงจูงใจจากเน้นเทคนิคไปเป็นเน้นผู้ใช้ จะส่งผลอย่างมากต่อบทบาทของผู้จัดการระดับกลางและระดับสูง การเปลี่ยนแปลงแบบนั้นสั่นคลอนฐานของบทบาทและความรับผิดชอบของพวกเขา และอาจนำไปสู่การสูญเสียอำนาจควบคุมและอิทธิพล
ดังนั้นการเปลี่ยนแปลงเช่นนี้จึงมีแนวโน้มจะเผชิญแรงต่อต้านที่เงียบแต่รุนแรงจากผู้จัดการระดับกลางและระดับสูง คนเหล่านี้มักมีอำนาจทางการเมืองและผลประโยชน์เดิมอยู่มากภายในองค์กร
งานช่างทุกอย่างเรียนรู้ได้จริงในจังหวะที่สัมผัสกับของจริง ผู้กำกับภาพยนตร์อาจดูหนังของตัวเองในห้องตัดต่อเป็นพันครั้ง แต่การดูพร้อมผู้ชมจริงครั้งแรกครั้งเดียวสอนอะไรได้มากกว่าพันชั่วโมงนั้น
ช่างไม้อาจมีความสุขกับการทำเฟอร์นิเจอร์ตลอดทั้งสัปดาห์ แต่ช่วงเวลาจริงมาถึงเมื่อเฟอร์นิเจอร์ชิ้นนั้นถูกวางไว้ในห้องของลูกค้า ซอฟต์แวร์ก็เหมือนกัน
ถ้าอยากให้วิศวกรซอฟต์แวร์ใส่ใจผู้ใช้ พวกเขาต้องได้รับ ฟีดแบ็กโดยตรง ว่าอะไรใช้ได้ดีและอะไรแย่มาก และถ้าเป็นไปได้ก็ควรได้เห็นด้วยตาตัวเอง
วิศวกรซอฟต์แวร์ที่ดีควรมีความภูมิใจในระดับหนึ่งกับการทำงานให้ดี หากความภูมิใจนั้นผูกอยู่กับโค้ด ประวัติ commit และแนวคิดนามธรรมอื่น ๆ เท่านั้น แต่ไม่เคยสัมผัสเลยว่างานนั้นถูกใช้เพื่อผู้ใช้จริงได้ดีแค่ไหน แล้วจะให้เขาเริ่มสนใจได้อย่างไรตั้งแต่แรก
แทบไม่เกี่ยวกับบทความนี้เท่าไร แต่เทรนด์สมัยนี้ที่ใช้ ภาพ AI เป็นภาพหลักของบล็อกโพสต์ทำให้ผมหงุดหงิดจริง ๆ
ถ้าตอนเขียนบทความไม่มีภาพหลักที่ชัดเจนผุดขึ้นมาในหัว ก็อย่าทำให้ผมเสียแบนด์วิดท์ไปโหลดความฝันเพี้ยน ๆ ของคอมพิวเตอร์เลย
ผมค่อนข้างเห็นด้วยกับภาพ AI เพราะมันเป็นเครื่องมือที่มีคุณค่ามาก แต่ถ้าจะใช้ภาพ AI เป็นภาพเดียวบนหน้าเว็บ ก็ควรมีเหตุผลที่สมควรจริง ๆ ไม่ใช่แค่เอามาเติมพื้นที่ว่าง
โดยเฉพาะอย่างยิ่งถ้ายัง curate ไม่ได้ด้วยซ้ำว่าทุกคนในภาพที่สร้างขึ้นมามีนิ้วครบถูกจำนวนหรือไม่
จุดประสงค์ของภาพคือการถ่ายทอด ความรู้สึก บางอย่าง ทำให้แนวคิดนามธรรมของบทความจับต้องได้ขึ้นเล็กน้อย
เมื่อก่อนผมหาภาพบนอินเทอร์เน็ตที่ตรงกับจุดประสงค์นั้นมาใช้ ตอนนี้ผมสร้างเองด้วย DALL-E ได้ และมักดีกว่ามาก
ภาพนี้ควรเสริมบทความ เหมือนที่ข้อความในบทความพยายามถ่ายทอดข้อมูล ความรู้สึก และแนวคิด ภาพก็ควรทำหน้าที่บางส่วนของสิ่งนั้นด้วย
ไม่มีใครอยากเห็นภาพแนว uncanny valley ของผู้คนจากกลุ่มเชื้อชาติหลัก ๆ ครบทุกกลุ่ม ยืนล้อมเป็นวงกลมแล้วยิ้มแปลก ๆ ให้กัน
กระแสภาพประกอบองค์กรที่ประหลาดและไร้วิญญาณแบบนี้เริ่มขึ้นก่อนที่การสร้างภาพด้วย AI จะฮิตระเบิดเสียอีก
อาจเป็นเพราะความเชื่อบางอย่างเกี่ยวกับการทำ SEO
พร้อมกันนั้นก็แค่ต้องดูดีด้วยเท่านั้น
แต่ตรงนี้ก็มีมุมที่ตลกอยู่ เทมเพลตบล็อกต้องการพื้นที่รูปภาพ คนก็เลยเติมอะไรบางอย่างเข้าไปโดยไม่คิดมาก ถ้ามันยากเกินไปก็ไปหาภาพสต็อกจืด ๆ และถ้านั่นยังยากอีก ก็สร้างภาพสต็อกจืด ๆ ขึ้นมาเองโดยตั้งใจ
ขยะ AI ที่ไร้แรงบันดาลใจและไร้รสนิยมคงกำลังจะกลืนทุกอย่างในไม่ช้า
ปัญหาส่วนใหญ่ของ PM อยู่ที่การไม่ลงพื้นที่ทำงานจริง PM ที่ดีต้องคอยเชื่อมช่องว่างระหว่างวิศวกรรมกับผู้ใช้อย่างต่อเนื่อง
ต้องทำ ลูปฟีดแบ็ก นี้ซ้ำไปเรื่อย ๆ
แต่คนส่วนใหญ่คิดว่าตนทำงานได้แค่ในโลกของเอกสาร ผลิตเอกสาร roadmap ออกมา แล้วพยายามรักษาการจัดแนวของผู้มีส่วนได้ส่วนเสียด้วยการ check-in และจู้จี้ไม่รู้จบ สุดท้ายก็กลายเป็นว่ากำลังทำงานแบบ “ผู้จัดการโครงการ” อยู่
ตั้งแต่การรวบรวม requirement, รับมือผู้ใช้ที่โกรธเรื่องบั๊ก, ประชุมสถานะรายสัปดาห์, ไปจนถึงการแจ้งข่าวร้ายเรื่องลำดับความสำคัญ ล้วนส่ง senior developer หรือ tech lead ไปหมด เจ้าตัวข้ามพิธีกรรม Agile ส่วนใหญ่โดยอ้างว่ายุ่ง ไม่เคยเขียนหรือแก้ JIRA ticket เลย และบอกว่านั่นเป็นเรื่องที่องค์กรเทคนิคต้องจัดการ อีกสองทีมเทคนิคก็มี PM แบบเดียวกัน
tech lead และ senior developer รู้ตั้งแต่สัปดาห์แรกแล้วว่า PM คนนั้นไม่ดี แต่เขาอยู่ได้นานกว่าพวกเราทุกคน และออกไปเพราะการลดคนหลังจากนั้น 4 ปี
ผู้บริหารที่หลงใหลใน ลัทธิบูชา Agile มักถูกคนแบบนี้ดึงดูดได้ง่าย และสามารถทำให้องค์กรหลุดรางไปได้หลายปี ตามทฤษฎีแล้ว ผู้มีส่วนได้ส่วนเสียของ PM คือผู้ใช้ แต่ในทางปฏิบัติกลับกลายเป็นงานเช็ดถูอัตตาของผู้บริหารระดับสูงที่จ้างตนมา
อาจเกิดลูปปิดที่เสริมตัวเองระหว่างผู้บริหารระดับสูง ที่ปรึกษา Agile และ PM ได้
ทั้งสองกรณีล้วนเป็นผลิตภัณฑ์ที่ไม่มีความสามารถในการแข่งขัน และมักมีแนวโน้มจะคงอยู่แบบนั้นจนกว่าจะถูกยุติ แต่บริษัทก็ยังมี PM กับ PO ตั้งโครงสร้างคล้าย SCRUM และทำตัวเหมือนกำลังสร้างผลิตภัณฑ์ปฏิวัติวงการ รวมถึงมีงานด่วนและแรงกดดันด้านผลลัพธ์ด้วย
ในสภาพแวดล้อมแบบนี้ PM และ PO มักไม่ค่อยสนใจผลิตภัณฑ์ที่ดีหรือใช้งานได้จริง แต่หมกมุ่นกับการเมืองเพื่อไต่บันไดเลื่อนตำแหน่งภายในบริษัท
ต่อให้สร้างผลิตภัณฑ์ที่กระจัดกระจายซึ่งในแง่ฟีเจอร์และการปรับปรุงดูเหมือน random walk พวกเขาก็จะลากโปรเจกต์ไปในทิศทางที่ทำให้ตัวเองดูดีต่อผู้บริหารหรือลูกค้า
ผมไม่ได้แก่พอจะรู้ว่าในยุค 60, 70, 80 เขาสร้างกันอย่างไร แต่คงไม่มี SCRUM/PM/PO เท่าไรนัก วาทกรรมเชิงมองร้ายที่ว่าผลิตภาพชะลอลงมากเมื่อเทียบกับหลายทศวรรษก่อน และทุกวันนี้โดยมากอาศัยสิ่งที่สร้างไว้ในอดีตนั้นค่อนข้างตรงกับการรับรู้ของผม
ช่วงหลังผมกำลัง mentor PM คนอื่น ๆ อยู่ มี roadmap ที่ถูกแชร์อย่างกว้างขวางก็จริง แต่ก็มีเอกสารและ spreadsheet จำนวนมากที่ไม่มีใครนอกจากผมกลับไปดูอีกเลย ผมรู้สึกว่ามันถูกสร้างขึ้นเพื่อแสดงว่ากำลังทำงานอยู่ และพยายามจะเลิกนิสัยแบบนั้น
เหตุผลที่ผมสนับสนุน technical product management อย่างหนักแน่น คือเมื่อทำให้ปัญหาง่ายลง ผมมองว่า PM บางคนติดอยู่ในระดับ abstraction ที่สูงเกินไป พวกเขาคุยรายละเอียดทางเทคนิคกับทีมทุกวันไม่ได้ สุดท้ายจึงค้างอยู่ในพื้นที่สีเทาแปลก ๆ ระหว่าง project management กับ product management
ตัวมันเองก็ไม่เป็นไร แต่ถ้ามี HIPPO syndrome จากคนที่อยากตัดสินใจเรื่องผลิตภัณฑ์ ก็จะต้องใช้เวลาส่วนใหญ่ไปกับการป้องกันตัวจากด้านหลังและบริหารขึ้นข้างบน
PM โดนโจมตีเยอะ และบางครั้งก็สมควรโดน แต่สุดท้ายหลายครั้งก็ต้องเล่นการเมืองภายในเพื่อทำให้งานเกิดขึ้นได้
PM ที่ยอดเยี่ยมไม่เพียงสร้างวิสัยทัศน์หรือแผน แต่ยังนำการลงมือทำและการวนปรับปรุงด้วย แผนเป็นแค่ 20% ของทั้งหมด
ผู้จัดการผลิตภัณฑ์ที่ดีที่สุดที่ผมเคยทำงานด้วย เป็นคนที่เก่งมากจริง ๆ เข้าใจความซับซ้อนของการ implementation และถ้าจำเป็นก็อาจลงมือทำเองได้ ขณะเดียวกันก็เข้าใจความต้องการทางธุรกิจ
เขาไม่ใช่ engineering manager แต่เป็นคนที่เพิ่มคุณค่าให้บริษัท
น่าเสียดายที่ผู้จัดการผลิตภัณฑ์ส่วนใหญ่เป็นแค่คนที่นั่งอยู่ในตำแหน่งนั้น เป็น gatekeeper ที่รับเครดิตหรือความรับผิดชอบไป และมักแทบไม่มีผลประโยชน์ของตัวเองผูกอยู่ด้วย
โดยรวมแล้ว ถ้ามีองค์กร product management แยกต่างหาก ผมมองว่ากำลังทำผิดทาง
ผลิตภัณฑ์ที่ดีที่สุดและประสบความสำเร็จที่สุดที่ผมเคยมีส่วนร่วม ล้วนเป็นผลิตภัณฑ์ที่ผู้ลงมือ implementation จริงเป็นเจ้าของผลิตภัณฑ์เอง เช่น วิศวกร ดีไซเนอร์ และทีม customer success
ในฐานะวิศวกร ผมชอบการเข้าเวร support เพราะมันช่วยปิด ช่องว่าง abstraction ระหว่างงานของผมกับคนจริง ๆ ที่ใช้มันทุกวินาที
เคยมีน้อยครั้งมากที่ผมได้ทำงานกับ PM ที่เพิ่มมูลค่าสุทธิจริง ๆ และทุกกรณีคนเหล่านั้นล้วนเป็นคนที่น่าจะเป็นวิศวกรที่ดีได้ด้วย
เหตุผลหลักคือ ถ้า PM หรือคนในทีมที่รับบทบาทนั้นรายงานขึ้นสายการจัดการวิศวกรรมเดียวกัน ทุกอย่างสุดท้ายจะเอนไปทางความต้องการของวิศวกรรม
งานฟีเจอร์ที่จำเป็นและมีแนวโน้มสูงว่าจะพาธุรกิจเดินหน้าได้ ก็จะถูกดันตกจากลำดับความสำคัญในที่สุด เพราะหนี้เทคนิคหรือโครงสร้างพื้นฐานมักขวางคนอยู่เสมอไม่ทางใดก็ทางหนึ่ง บางครั้งนั่นอาจเป็นทางเลือกที่ถูกต้องจริง ๆ แต่การตัดสินใจแบบนั้นจำเป็นต้องมีแรงตึงระหว่างสององค์กรที่มีที่นั่งเท่าเทียมกัน หากกลายเป็นส่วนหนึ่งของวิศวกรรม สิ่งนั้นมักไม่เกิดขึ้น
แน่นอน ความจริงที่น่าเศร้าของอุตสาหกรรมเราคือองค์กร PM แยกต่างหากมักมีอำนาจมากกว่าองค์กรวิศวกรรม เพราะเป็นเจ้าของ “สิ่งที่ดีต่อธุรกิจ” พอรวมกับ PM ที่ทำตามกระบวนการหรือ framework ได้ แต่ไม่เข้าใจผลิตภัณฑ์หรือผู้ใช้ของตัวเองจริง ๆ ก็กลายเป็นฝันร้าย
ผมคิดเป็น สัดส่วน
สัดส่วนระหว่างวิศวกรฟรอนต์เอนด์กับวิศวกรแบ็กเอนด์เป็นเท่าไร? สัดส่วนระหว่าง Engineering Manager กับ Individual Contributor ล่ะ? สัดส่วนระหว่างคนเขียนเอกสารเทคนิคกับวิศวกรทั้งหมดล่ะ? สัดส่วนระหว่าง Product Manager กับวิศวกรทั้งหมดล่ะ?
แล้วก็พยายามปรับสัดส่วนเหล่านี้อย่างละเอียด เพื่อเพิ่มผลกระทบให้มากที่สุด และลดการแทรกแซงกับการจู้จี้ระดับไมโครให้เหลือน้อยที่สุด
ตัวเลขจริงของสัดส่วนนี้คงต่างกันไปในแต่ละองค์กร แต่ถ้าเริ่มรู้สึกได้ถึงการแทรกแซง หรือถ้า “ทำอย่างไร” ไม่ได้ออกมาจากตัววิศวกรเองอย่างเพียงพอ ก็ต้องเปลี่ยนสัดส่วน
ต้องเพิ่มจำนวนวิศวกรต่อ People Manager หรือ Product Manager หนึ่งคน ทำให้พวกเขาไม่สามารถเข้ามายุ่งแบบนี้ได้ บังคับให้ต้องจัดลำดับความสำคัญของงานที่จะเข้าไปมีส่วนร่วม และถอยออกจากพื้นที่ระดับไมโครเพื่อคืนอิสระในการกำหนดวิธีการให้วิศวกร
QA, วิศวกรจูเนียร์, วิศวกรซีเนียร์, สถาปนิก, บุคลากร HR, รองประธาน และพนักงานขายก็เช่นกัน
ผมทำงานด้าน Product Management มานานกว่า 20 ปี และเห็นด้วยกับส่วนใหญ่ที่พูดไว้ตรงนี้ สัดส่วน สำคัญ
CPO สร้างอาณาจักรได้ง่ายด้วยการมี PM เป็นกองทัพ องค์กรจะกลายเป็นสภาพที่ PM แต่ละคนครอบครองชิ้นส่วนเล็ก ๆ ของประสบการณ์ลูกค้า เช่นหน้าเดียวหน้าใดหน้าหนึ่ง แล้วปรับแต่งอัตราการคลิกปุ่ม แต่ไม่ได้มีส่วนสำคัญต่อกลยุทธ์หรือวิสัยทัศน์ของผลิตภัณฑ์
การเป็น Product Manager โดยไม่ได้เป็นเจ้าของผลิตภัณฑ์นั้นทำได้ยาก
PM ควรโฟกัสเป้าหมายทางธุรกิจมากกว่าที่เป็นอยู่ในปัจจุบันอย่างมาก การแก้ปัญหาของผู้ใช้เป็นสิ่งจำเป็น แต่ยังไม่เพียงพอ การแก้ปัญหานั้นต้องนำไปสู่คุณค่าของบริษัทด้วย
เพื่อให้สิ่งนี้เป็นไปได้ จำเป็นต้องมีพาร์ตเนอร์ด้าน Engineering และ UX ที่มี Product Sense แข็งแรง
ที่แย่กว่านั้นคือ นักพัฒนาที่ “เปลี่ยนแทนได้ง่าย” มาจากบริษัทเอาต์ซอร์ส ตอนนี้จึงต้องแยกงานพัฒนาออกจากลูกค้าด้วยชั้นการจัดการที่มากขึ้น
เป็นวิธีที่ยอดเยี่ยมในการเพิ่ม GDP
ตัวอย่างเช่น ถ้าทำ ERP, Oracle Fusion Apps, WorkDay, SAP อะไรแบบนั้น PM คนเดียวไม่สามารถเป็นเจ้าของผลิตภัณฑ์ทั้งหมดได้ แต่จะรับผิดชอบหลายฟีเจอร์แทน และแต่ละฟีเจอร์เองก็ซับซ้อน อีกทั้งด้วยธรรมชาติของ ERP ก็มักรวมถึงการผสานรวมกับผลิตภัณฑ์อื่น ๆ หลายตัวด้วย
ถึงอย่างนั้นก็เห็นด้วยกับทิศทางใหญ่ที่ว่า PM ควรเป็นเจ้าของ บางสิ่งที่มีความหมาย
ในฐานะนักพัฒนาและ Development Manager, Product Manager ที่ดีที่สุดที่เคยทำงานด้วยแทบไม่เข้ามายุ่งกับ “ทำอย่างไร” เลย
แน่นอนว่าเขาอาจสร้างตั๋วระดับ Epic ใน backlog ได้ แต่ในระดับที่ต่ำกว่านั้น เขาเชื่อใจว่าคุณและคนที่รับผิดชอบโปรเจกต์จะทำงานให้เสร็จได้
ปัญหาคือองค์กรต้องสนับสนุนวิธีนี้ด้วย ในบริษัทส่วนใหญ่ งานที่ได้รับความสนใจมากที่สุดไม่ใช่งานที่ขับเคลื่อนด้วยวิสัยทัศน์หรือการเติบโต แต่เป็นงานที่เสียงดังที่สุด
และงานแบบนั้นก็มักขัดแย้งโดยตรงกับทิศทางที่หัวหน้าผลิตภัณฑ์หรือผู้จัดการต้องการ
PM ที่ไม่เข้าใจ “ทำอย่างไร” กล่าวคือ PM ที่ไม่รู้ว่าผลิตภัณฑ์ของตัวเองทำงานอย่างไร คือแบบที่แย่ที่สุด
PM ที่ดีที่สุดที่เคยร่วมงานด้วยมี พื้นฐานด้านเทคนิค
เมื่อคนพยายามเหยียบเข้าไปในอาณาเขตของคนอื่น มักจบด้วยหายนะเสมอ ทั้งสองทิศทาง วิศวกรมักคิดมากเกินไปจากมุม “ทำอย่างไร?” จึงไม่ถนัดกับ “ทำไม?” และ “อะไร?” และ Product Manager ก็ควรถอยออกจาก “ทำอย่างไร?” เว้นแต่เป็นไปเพื่อทำให้ “อะไร?” หรือ “ทำไม?” ชัดเจนขึ้น
ต้องมีความสมดุล PM/PO ก็จำเป็นต้องมี ความเข้าใจพื้นฐาน เช่นกัน ไม่ควรเป็นคนที่แทบใช้คอมพิวเตอร์ไม่เป็น
ต่อให้เป็น PM ที่ดี ก็อาจถูกผูกมัดได้มากถ้ารอบตัวมี PM ธรรมดา ๆ มากเกินไป
จากการทำงานกับบริษัท Fortune 500 หลายแห่ง ผมเห็นวัฒนธรรมที่พังมามาก
ในที่แบบนั้น PM แก้ปัญหาส่วนใหญ่ด้วยเครื่องมือเดียวที่ตัวเองมีคือ การประชุม แรงจูงใจในการเลื่อนตำแหน่งถูกออกแบบให้ยิ่งประชุมใหญ่เท่าไร ก็ยิ่งดูเหมือนเป็นคนสำคัญเท่านั้น
ผมเคยเข้าประชุมข้ามสายงานรวมกันหลายร้อยชั่วโมง คนที่ทำงานจริงมี 1–2 คน และโดยมาก PM จะพูดตลอดเวลา ส่วนอีก 10–20 คนปิดไมค์ไว้ แล้วค่อยอนุมัติท้ายประชุมราวกับพิสูจน์ว่าตัวเองมีตัวตน
ผลคือทีมวิศวกรหมดแรงจูงใจ ไม่มีเวลาทำงานเทคนิคจริง ๆ และถูกขอให้ประเมินหรือให้คำมั่นกันตรงนั้น โดยไม่มีการสำรวจหรือทำความเข้าใจโค้ด
ผมยังเคยเห็น PM ปฏิเสธดีไซน์ทางเทคนิคเพราะไม่ชอบตัวเลขหรือ “point” แล้ววิศวกรต้องเอาไอเดียเดิมไปจัดรูปแบบใหม่เป็น “ticket” อื่น เพื่อให้ถูกใจสุนทรียะบางอย่างของ PM ที่ไม่มีใครเข้าใจ
ทั้งโปรเจกต์ล่าช้าและหลุดทิศทางเพราะความไม่เข้าใจและพิธีกรรมโชว์สถานะที่ไร้ความหมาย
ในทางกลับกัน ผมก็เคยทำงานกับ PM ที่ยอดเยี่ยม คนแบบนั้นช่วยปกป้องทีมจากเรื่องไร้สาระเหล่านี้ และทำให้ทีมโฟกัสกับเป้าหมายที่ถูกต้อง คนแบบนั้นมีค่ามาก ส่วนคนแบบแรกก็เป็นอันตรายมากพอ ๆ กัน
เรื่องนี้ไม่ได้เกี่ยวกับจำนวน PM แต่เป็นเรื่องประเภทของ PM ที่ผมอยากร่วมงานด้วย
ผมเคยทำงานในบริษัทในอุตสาหกรรมนี้มา 4 แห่ง ตั้งแต่สตาร์ทอัพที่มีคนน้อยกว่า 40 คน ไปจนถึง JP Morgan Chase
ผมปฏิเสธความคิดที่ว่า คนที่ “สายเทคนิค” ฉลาดกว่าคนที่ “ไม่ใช่สายเทคนิค” อันที่จริง ในฐานะวิศวกร ผมมักจมกับรายละเอียดจนพลาดภาพใหญ่ และบ่อยครั้งก็ต้องให้ PM ช่วยดึงผมออกมา
แต่จากประสบการณ์ของผม ในฐานะวิศวกร PM ที่ทำงานด้วยง่ายที่สุดคือคนที่เคยสัมผัสโค้ดจริงมา แม้เพียงนิดเดียว
ไม่จำเป็นต้องเก่งกาจอะไร อาจเป็นแค่เคยทำเว็บไซต์ด้วย HTML กับ CSS เมื่อนานมาแล้ว เคยเขียนคิวรี SQL แบบเฉพาะกิจ หรือเคยเรียนคลาส Python ตอนเรียนปริญญาโท ก็พอแล้ว
ขอแค่มี อะไรสักอย่าง ที่ทำให้ PM เข้าใจว่าการเขียนโค้ดไม่ใช่วิทยาศาสตร์ที่แม่นยำเป๊ะ ๆ และก็ไม่ใช่เวทมนตร์ล้วน ๆ
PM แบบนี้จะช่วยสนับสนุนวิศวกรที่ทำงานด้วย หรืออย่างน้อยก็พยายามหาสมดุลระหว่างความต้องการทางธุรกิจกับความเป็นจริงของงานวิศวกรรม
คนที่มาเป็น PM โดยไม่เคยสัมผัสเทคโนโลยีเลย มีแนวโน้มจะ “เน้นธุรกิจ” มากกว่า ซึ่งในบางช่วงเวลาธุรกิจอาจต้องการแบบนั้นจริง ๆ แต่ก็ไม่ใช่เสมอไป ในฐานะวิศวกร ผมอยากทำงานกับคนที่เข้าใจมุมมองของผมได้ดีกว่าด้วย
ไม่ได้น้อยใจเลยสักนิดนะ :p