PM Tips : 8 เคล็ดไม่ลับ มัดใจ Business Unit แบบ Product-led Company
เกริ่นนำ
การทำ Product ให้ประสบความสำเร็จต้องอาศัยการทำงานร่วมกันอย่างสมัครสมานสามัคคี ของทั้งในทีม Product เอง และนอกทีม Product เช่น Marketing, Sales, Operation, Legal and Finance, และ อื่น ๆ (ต่อไปขอเรียกรวมกันว่า Business Unit หรือ BU นะครับ) แต่คนเยอะก็ตามมาด้วยเรื่องที่แยะ และความคาดหวังที่ยิ่งใหญ่ จะทำยังไงให้ทุกคนเข้าใจ Product Manager ตัวเล็ก ๆ อย่างเรา และเดินหน้าสร้าง Impactful product & business ไปด้วยกัน 💙
บทความนี้เหมาะกับคุณหาก
- คุณเป็น Product Manager ที่กำลังมีปัญหากับการร่วมงานกับทีม BU
- คุณเป็น Product Manager ที่หัวไฟลุกทุกครั้งเวลาได้ยินทีมอื่น ๆ ขออะไรก็ไม่รู้ที่ไม่มีที่มาที่ไป ไม่มีหลักฐานสนับสนุน → ใจเย็นก่อน แล้วลองอ่านบทความนี้ครับ
- คุณเป็น Product Manager ที่ไม่ได้มีประสบการณ์หรือคลุกคลีกับทีม BU มากนัก อาจจะไม่เคยทำงานใน BU มาก่อน หรือเติบโตมาจากสาย Technical/Developer/Software Engineer
💪🏼 Product Manager วัน ๆ ทำอะไรบ้าง
PM อย่างเรา มักมีสิ่งที่เหมือน ๆ กันในแต่ละวัน แต่ละสัปดาห์ก็คือการประชุม ประชุมได้ทั้งวี่ทั้งวัน ต่างกรรมต่างวาระ ชั่วโมงนี้เรื่องนึง ต่ออีกชั่วโมงด้วยอีกเรื่องไปเลย ทุกประชุมก็เพื่อคุยกับทุกภาคส่วนที่เกี่ยวข้องกับ Product ของเรา ไม่ว่าจะเป็น ใน Squad (Designer, Engineer, Product Ops, QA), นอก Squad (Direct Report, Dependent areas, Tech Lead, Designer Lead), และที่สำคัญก็คือ Business Unit ที่ได้เกริ่นไว้ตอนต้นครับ ซึ่งทุกการคุยมักประกอบด้วย Agenda ทั้งที่เขียนอยู่ และแบบลับ ๆ ทำให้ PM เป็นตำแหน่งที่ไม่สามารถหลีกเลี่ยงข้อขัดแย้ง หรือการเจรจาต่อรองได้อย่างแน่นอน
ยิ่ง PM ใน Product-led Company แล้วด้วย นั่นหมายความเรา PM เป็นหนี่งในคนสำคัญในการกำหนดแนวทางของ Product ซึ่งอาจจะต่างจากองค์กรส่วนใหญ่ที่ BU จะบอกมาเลยว่าลูกค้าต้องการอะไร ผู้ใช้งานต้องการฟีเจอร์ไหน นั่นยิ่งทำให้เราจะเจอคำถามที่มากขึ้นจาก BU ที่มากขึ้น ตัวอย่างเช่น
ทำไมถึงไม่ทำอันนี้ให้ ถ้าไม่ทำให้ก็ทำอะไรต่อไม่ได้แล้วนะ
ช่วยรีบทำเรื่องนี้ให้หน่อยได้ไหม มันโดน KPI ทีมพี่
สิ่งนี้สำคัญมาก ๆ เลยนะ แต่อีกอันก็สำคัญมากเหมือนกัน ให้เลือกก็เลือกไม่ได้หรอก
ฟีเจอร์ที่บอกว่าจะทำ ตอนนี้ใช้ได้หรือยัง
อันนี้ลัดคิวให้ก่อนได้ไหม ลูกค้าด่าจะแย่แล้ว
ทำไมใน roadmap ไม่มีสิ่งนั้นล่ะ ที่เราคุยกันไว้ไม่ได้เป็นตามนั้นหรอ
สารพัดคำที่เราจะได้พบเจอในแต่ละวัน แถมยังวนมาหลายครั้งด้วย เดือนละครั้งบ้าง สองอาทิตย์ครั้งบ้าง หลังไมค์ส่วนตัวมาบ้าง วนเวียนไปไม่รู้จบ
สิ่งที่อยู่ในใจเป็นหมื่นล้านคำของ PM เช่น…
ถามหาเหตุผล หรือ use case ไปตั้งหลายทีแล้ว ยังไม่ได้อะไรเลย
Yes ไป 80, No ไป 20 แต่ทำไมจำแต่ No นะ
เอาผลการทดสอบสมมติฐานมาบอกก็แล้วว่าไม่คุ้มที่จะทำก็แล้ว
ทำไม่ทันเพราะ Resource มีจำกัดก็บอกแล้ว
😵 เราว่าเราก็อธิบายในส่วนของเราไปหมดแล้วนะ ทำไมสิ่งที่ยังได้ยิน หรือที่ยังต้องตอบ มันยังเป็นเรื่องเดิม ๆ ไม่รู้จะทำไงแล้ว
งั้นเรามาลองเขียน Vision statement ตามสไตล์ PM กันหน่อย 🖋️
การมีอยู่ของ PM ใน Product-led Company
Vision (วิสัยทัศน์) → PM จะช่วย company สร้าง product ที่ให้ BU ไป drive business impact ได้อย่างเต็มที่
Mission (เป้าหมาย) → PM อยากทำงานร่วมกันกับ BU อย่างเข้าอกเข้าใจ
Metric (ตัวชี้วัด) → เราไม่ควรจะมี personal conflict ต่อกัน → มีแต่ healthy discussion ให้ได้มากที่สุด
Target group → ทุก Business Unit
Strategy → ถึงจุดสำคัญละ ว่าเราจะเลือกใช้วิธีไหนในการให้ได้มาซึ่ง Mission ของเรา (ทำงานด้วยกันอย่างเข้าอกเข้าใจ)
ทีนี้ ผมอยากแทรกหลักคิดส่วนตัวไปเข้าไปอีก 4 ข้อ ก่อนที่เราจะไปต่อกัน
1. ทุกคนจากทุกทีมก็กำลังตั้งใจทำงานเต็มที่
ความคิดที่อันตรายคือการคิดว่าคนอื่นกำลังทำงานไม่เท่าเรา ขอให้เราเน้นไปที่การทำงานในส่วนของเราอย่างดีที่สุดก็พอ blame culture เป็นสิ่งที่ไม่ควรเกิดขึ้นในองค์กร ทำให้วัฒนธรรมองค์กรและขั้นตอนการคัดเลือกพนักงานที่ดีเป็นพื้นฐานที่สำคัญมากครับ
2. PM ไม่ได้เก่งไปกว่า หรือฉลาดกว่า BU
สิ่งที่มาพร้อม sense of ownership ที่สูงตามความเป็น PM ก็คือความมั่นใจว่าเราจะเข้าใจ user(ผู้ใช้งาน) ดีที่สุด แต่เชื่อเถอะว่าคนที่จะ ‘รู้ดี’ จริงๆ ก็คือเหล่าทีม BU ต่างหากครับ
Sales, Marketing : นำ Product เราไปขาย ไปโฆษณา หารายได้ เอามาจ่ายเงินเดือนทุกคนในองค์กร
Operation : ดูแลผู้ใช้งาน รับ feedback จากการใช้งาน Product เรา (ซึ่งส่วนใหญ่ต้องเป็นคำบ่น คำติ คำด่า มากกว่าชมแน่นอน)
Legal : ดูแลความถูกต้องของการสร้าง Product ให้ทุกอย่างถูกต้องตามกฎระเบียบต่าง ๆ
แต่ละคนมีความสำคัญต่อ PM อย่างมาก ที่เราต้องฟัง และพวกเขาคือคนที่อยู่หน้างาน และต้องรับมือกับสิ่งที่เราจะปรับ หรือจะเปลี่ยนแปลงบน Product ทุก ๆ ครั้งที่เราต้องตัดสินใจ
งั้นมีเราทำไม ถ้า BU รู้ดีกว่า งั้นให้ BU มาทำ Product เลยไหม? → สิ่งที่เรามีความสามารถก็คือ การมอง ‘ปัญหา’ และ ‘ความต้องการ’ นั้น แปลงให้ออกมาเป็นจริงด้วยเทคโนโลยีและดีไซน์เข้ามาแทนที่นั่นเอง เพราะมีเรา จึงสามารถนำปัญหาจาก BU มาสร้างสรรค์ให้กลายเป็นสิ่งที่ user จะรักได้
3. BU ไม่ได้เข้าใจ Product Management Process เท่าเรา
ถ้าสิ่งที่ BU พูดมา ดันเป็นการขอ feature นู้น feature นี้ อย่าเพิ่งไปตีเค้าว่าทำไมไม่มาเป็น problem statement หรือทำไมเค้าไม่เข้าใจ ว่า feature เล็ก ๆ อันเดียวต้องเป็นเดือน ๆ ถึงจะได้ อย่าเพิ่งอารมณ์เสียว่าทำไมไม่เข้าใจ อย่าลืมว่าเค้าไม่ได้เป็นเรา เหมือนกับที่เราก็ไม่ได้รู้เนื้องานเค้าอย่างละเอียดเหมือนกัน เพราะฉะนั้น อยากให้มีเมตตาต่อความไม่รู้ของกันและกันครับ
4. การเอาชนะอาจไม่ใช่ทางออกที่ดีที่สุดในการทำงานเป็นทีม (โดยเฉพาะทีมขนาดใหญ่)
การถกเถียงหลายครั้ง ยิ่งเป็นในเรื่องงานด้วยแล้ว ตามสัญชาตญาณแล้วไม่แปลกเลยที่เราจะพยายามอธิบายทุกวิถีทางเพื่อเอาชนะในการถกเถียง หรือไล่ต้อนอีกฝ่ายจนเถียงไม่ออก แม้ว่าการประชุมจะจบลงไป แต่ที่หลงเหลือหลังจากนั้น อาจสร้างรอยร้าวระหว่างทีมได้ เช่นไม่อยากให้ความร่วมมืออีกแล้ว ไม่อยากคุยด้วยแล้ว เก่งก็เอาไปทำเองเลย ไม่ขออะไรแล้วต่อจากนี้ เดี๋ยวหาทางดิ้นรนเอง ซึ่งนั่นจะนำพาไปสู่หายนะในการทำงานอย่างแน่นอน
อยากให้คิดไว้เสมอว่า ยังไงทุกคนก็คือคน ที่มีความรู้สึก มีสมอง มีหัวใจ อย่าห่วงแต่จะเอาชนะ จนลืมนึกถึงความรู้สึกกันนะครับ → ถอดหัวโขนเรื่องงานออก เราก็คือคนที่ร่วมสังคมกันคนนึง
ถ้าเราเข้าใจ 4 ข้อนี้เหมือนกันแล้ว
อยากจะพาทุกคนไปต่อ กับ Strategy ที่จะเอาชนะใจ BU ได้ และเป็นสิ่งที่ผมใช้มาตลอด ตั้งแต่สมัยตัวเองเป็น BU → ขยับมาอยู่ระหว่างกลางของหลาย BU → เป็น PM ที่ต้องคุยกับทุก BU
1. มั่นใจว่าการตัดสินใจที่เลือกเป็นตัวเลือกที่ดีที่สุด
หมั่นเช็คการตัดสินใจของเราอย่างละเอียดทุกครั้ง ว่า
- เรากำลังตัดสินใจบนข้อมูลใช่หรือไม่
- Impact ของการตัดสินใจนั้น เป็นผลกระทบเชิงบวกที่สูงสุดแล้วในทางเลือกทั้งหมดที่มี
- Metric หรือตัวชี้วัดการตัดสินใจนั้น สอดคล้องไปกับแนวทางของบริษัท
ตัวอย่างเช่น เราอยากทำ feature A ขึ้นมา โดยคาดหวังว่าจะช่วยเพิ่ม MAU ได้ 10% แต่สิ่งนั้นอาจจะกระทบ top funnel traffic -10% ซึ่งกระทบโดยตรงกับทีม Sales & Marketing คำถามคือ เราพิสูจน์ได้ไหมว่า MAU +10% จะสร้าง business impact ได้มากกว่า top funnel traffic ที่หายไป ส่งผลกระทบระยะสั้นหรือระยะยาว วิธีที่ผมชอบทำคือลองทำ P&L projection (ร่างงบกำไรขาดทุน) มาดูก่อนไว ๆ เพื่อให้เห็นภาพว่าการทำ product หรือ feature นี้ จะคุ้มค่าในแง่การใช้ทรัพยากรของบริษัท และเราสามารถใช้สิ่งเดียวกันนี้อธิบายกับ BU ได้เช่นกันครับ
2. ฟังเพื่อเข้าใจ ไม่ใช่ฟังเพื่อตอบโต้
การฟังเพื่อเข้าใจสำคัญมาก และการฟัง BU ก็ไม่ได้ต่างกับตอนเราฟัง user ของเราเลย หลายคนมีความพยายามจะเข้าใจ user สูงมาก แต่กลับไม่ค่อยพยายามเข้าใจ BU ทั้งที่ในหลาย ๆ product เค้าก็เป็น user ของเราเหมือนกัน แนะนำให้ใจเย็นลง และใช้วิธีในการตะล่อมถามหา use case, need, และ insight ของเค้าให้ได้เหมือนกัน แล้วสรุปออกมาว่ามันเป็นยังไง เสร็จแล้วบอก Process ต่ออีกนิด ว่าเราคิดยังไง สิ่งที่ขอมามี business impact ไหม แล้วเราจะทดสอบยังไงก่อนที่จะเริ่มสร้างจริง ๆ ครั้งต่อไปเค้าจะเข้าใจและทำการบ้านมากขึ้นก่อนมาคุยกันนั่นเอง
3. Say Probably first, then strong Yes or reasonable No.
ต่อจากข้อก่อนหน้า หากเรายังไม่มั่นใจ หรือยังไม่แน่ใจว่าข้อสรุปที่ได้ในการประชุมเป็น the best choice ผมมักจะจบด้วยข้อสรุปปลายเปิด ว่า ยังไม่รับปาก, แบ่งกันไปทำการบ้านเพิ่มในสิ่งที่ไม่แน่ใจ แล้วค่อยกลับมาตอบอีกครั้ง ว่าเราจะทำ หรือไม่ทำ เพราะอะไร
หลายครั้งต้องบอกว่า ในใจเราคิดแล้วแหละ ว่าสิ่งที่เค้าขอมา เราไม่ทำแน่ ๆ แต่เราต้องสังเกต BU นิดนึง ว่าตอนนั้นเราควรตอบ No ไปเลยไหม หรือเรารับปากมาก่อนก็ได้ พร้อมกับบอกเหตุผลที่เราอาจจะตอบ No นะ ผ่านไป 2–3 วัน เราอาจจะค่อยตอบเข้าใปใน loop นั้น ว่าสรุปเราตัดสินใจจะไม่ทำนะ เหตุผลเพราะว่า 1, 2, 3 วิธีนี้มักได้ผลดีกว่าตอบ No แสกหน้ากลางประชุมนั้นเลย เป็นวิธีการจัดการอารมณ์อีกวิธีนึงครับ
4. สร้างความรู้สึกเป็นพวกเดียวกัน ฉันทีมเดียวกับเธอนะ!
สิ่งที่สำคัญมากในการทำงานร่วมกันให้สำเร็จ คือความรู้สึกเป็นทีมเดียวกัน พูดเหมือนจะง่ายนะครับ แต่จากประสบการณ์แล้วเห็นน้อยคนที่จะทำได้จริง ๆ ในการประชุมต้องเริ่มต้นด้วยวัตถุประสงค์เดียวกัน แม้จะมาจากต่างแผนก แต่เราก็คือคนที่กำลังทำเพื่อบริษัทเหมือนกัน เพราะฉะนั้นเราคือทีมเดียวกัน ที่ทำคนละหน้าที่เพื่อให้ได้สิ่งที่เราต้องการ การรับฟังกันเมื่อมี feedback หรือความเห็น ต้องระวังอย่า treat ให้เป็นการ attack ระหว่าง Product vs BU แต่มันคือความเห็นบนสิ่งที่เรากำลังจะตกลงทำร่วมกันมากกว่า
5. Commit your AMBITION, not your ROADMAP.
เรารู้กันอยู่แล้วว่า Product roadmap always delays ด้วยบัคเอย dependency เอย และอะไรต่อมิอะไรเกินคาดคิดเกิดขึ้นได้เสมอ จึงค้นพบว่าจริง ๆ แล้ว ในวันที่เราจะต้องสื่อสาร Product Roadmap ของเรา สิ่งที่สำคัญคือการแสดงความตั้งใจที่จะพยายามอย่างเต็มที่ในการส่งมอบสิ่งที่สัญญาให้ตามเวลาให้ได้
จากประสบการณ์ถ้าเกิด BU ก็เห็นแล้วแหละ ว่าเราพยายามสุด ๆ ในการทำแล้ว พอถึงวันจะ delay จริง ๆ เค้าก็จะเข้าใจเรามากขึ้น → effort ในการต้องพยายามอธิบายสาเหตุของการ delay ก็จะน้อยลงไปด้วยครับ
6. อัปเดทเสมอ เมื่อมีอะไรที่เริ่มจะไม่ตรงแผน
เรื่องง่าย ๆ ที่มักถูกลืมไปในหลาย ๆ ครั้ง ซึ่งการไม่ตรงแผนนี้อาจจะทั้ง มีของบางอย่างจะออกช้าไป มีของบางอย่างจะออกไวขึ้น ของบางอย่างจะไม่ทำแล้ว และบางอย่างจะเกิดขึ้น หรือมีการปรับเปลี่ยนกะทันหัน อย่าลืมอัปเดทเสมอกับ BU ที่เกี่ยวข้อง ท่องเอาไว้ว่า ยิ่งไวเท่าไหร่ยิ่งดี
สเต็ปที่ผมใช้ในการอัปเดท
เมื่อรู้ว่าจะมีการเปลี่ยนแปลงและ แต่ยังไม่ฟันรายละเอียด → แจ้งทุกส่วนทันทีว่ามีเปลี่ยน แต่เดี๋ยวนัดไปเล่ารายละเอียดให้ฟังนะ
รายละเอียด สโคปการเปลี่ยนชัด สามารถคาดเดาได้ว่าแต่ละทีมต้องปรับอะไร → แจ้งสิ่งที่ปรับเปลี่ยนเป็นลายลักษณ์อักษรกับทุกทีมก่อน แล้วค่อยนัดคุยตามไปทีหลัง ให้ทีมมีโอกาสทำการบ้าน เมื่อนัดประชุมก็จะได้คุยกันต่อได้ทันทีเลย
7. คุยเล่นกันเรื่องอื่นบ้าง เชื่อมสัมพันธไมตรี
ปกติผมมักจะใช้เวลาประมาณ 3–5 นาทีแรก หรือช่วงที่รอคนเข้าประชุมมาครบ ในการถามไถ่สารทุกข์สุกดิบเค้าบ้าง งานในแผนกเค้าตอนนี้เป็นไง หนักไหม ถามเล่น ๆ ว่ามีอะไรอยากให้ช่วยไหม หรือถามเรื่องทั่วไป ให้ได้รู้จักกันบ้าง
เราอาจจะไม่จำเป็นต้องเป็นเพื่อนกับคนที่ทำงาน แต่เราจำเป็นที่จะต้องมีความสัมพันธ์อันดีกับคนที่ทำงานครับ
เชื่อเถอะว่าความเป็นมิตรไม่เคยให้ผลเสีย ในหลายครั้ง งานไฟไหม้ งานด่วนงานร้อน ก็รอดเพราะเรารู้จักกัน และอยากช่วยเหลือกันนี่แหละ 😄
8. เมื่อ Product สำเร็จ อย่าลืมให้เครดิต
เรื่องนี้อาจจะเป็น common sense ที่ควรทำอยู่แล้ว แต่อยากจะย้ำอีกครั้งว่าการให้เครดิตสำคัญมาก ทุกคนที่จะช่วยให้ Product เราออกมาได้ เกิดจากคนหลายคน หลายทีม หลายภาคส่วนมาก อย่าลืมให้เครดิตกับทุก ๆ feedback, idea, opinion, assumption ที่ได้มาจากทุกคน เพราะวนกลับไปว่า ทุกคนก็กำลังตั้งใจทำงานเพื่อบริษัทอยู่เหมือนกันนะ
ทิ้งท้าย
เขียนไปเขียนมา ยาวเหมือนกันแฮะ ถ้าใครอ่านมาถึงตรงนี้ ขอบคุณมากจริง ๆ นะครับ ตั้งใจเขียนมาก ดีใจ 🥹
ทิ้งท้ายจริง ๆ
อ่าน ๆ ไปแล้วอาจจะคิดว่า ทำไมงาน Product Manager จะต้องแคร์ทีม แคร์คน แคร์อะไรเยอะขนาดนี้ แต่ผมอยากให้คิดว่า Process ด้านบนก็เป็นเครื่องมือที่จะทำให้ BU ได้เข้าใจ PM ตัวเล็ก ๆ อย่างเรามากขึ้นด้วยเหมือนกันครับ เปิดโอกาสให้เราได้มี empathy ต่อกัน ซึ่งผมเชื่อว่า ถ้าเราทำ Mission เรื่องความเข้าใจกันสำเร็จ Vision ที่เราตั้งไว้ ก็ไม่ได้ไกลเกินเอื้อมอย่างแน่นอนครับ ;)
ถ้าเห็นว่าบทความนี้มีประโยชน์ ฝากแชร์ด้วยนะครับ ส่วนใครอยากคุยกับผู้เขียน หรือมีอะไรอยากแลกเปลี่ยน จะเป็นคอมเม้นต์ในนี้ หรือ LinkedIn ที่นี่ ได้เลยครับ
