ต่อยอดจากหนังสือ 1 หน้า กับการบอกเล่าประกอบเป็นข้อๆ ไปกับประสบการณ์ที่ผ่านมาไปด้วยสั้นๆ จากที่เคยทำมา
ถ้าใครเป็น Product Manager ที่ช่ำชองแล้ว บทความนี้อาจจะไม่เหมาะก็ได้นะครับ แต่ถ้าได้อ่าน ก็ถือว่าได้ทบทวนหรือ reflection ตัวเองก็ได้นะ เผื่อใครตอนนี้กับว้าวุ่นใจ(หรืองาน)กับตัวเองอยู่ 🙂
มีโอกาสได้อ่านหนังสือชื่อ The Product Book : How to become a great Product Manager ของ Product School คนถ่ายทอดก็มีสองคน คือ Josh Anon ลองคลิกไปอ่านประวัติได้เลย สั้นๆ คือคนนี้เป็น Instructor ใน Product School ส่วนอีกคน Carlos González de Villaumbrosia ก็ลองกดเข้าไปอ่านประวัติเต็มๆ ได้ คนนี้คือ Founder ของ Product School
พอดีหยิบมาอ่านบนรถไฟฟ้าระหว่างเดินทางไปทำงานตอนเช้า ยืนอ่านตัวไม่อยู่นิ่งเพราะรถไฟฟ้าก็เคลื่อนตัวไปเรื่อยๆ กอดกระเป๋าไว้ด้านหน้าแล้วถือหนังสือเล่มหนาประมาณ 2 ซม. กว่าๆ ก็พินิจกับเนื้อหาในช่วงแรกนิดนึง เนื่องด้วยมีคนรู้จักหลายคนชอบถามถึงว่า Product Manager วันๆ ทำอะไร ว่ากันตามตรงปัจจุบันก็มีบทความ, คลิปบน YouTube หรือแม้กระทั่ง TikTok ก็คงมีเล่าไปหมดแล้ว
เนื้อหาต่อไปนี้ไม่ได้แปลตรงๆ กับหนังสือ แต่ขอเล่าคาบเกี่ยวกับประสบการณ์เล็กๆ ที่เคยทำมาบ้างก็แล้วกัน หวังว่าจะเป็นประโยชน์ต่อคนอ่าน
PMs must understand both business strategy and execution.
แน่นอนว่าการสร้าง Product ก็ไม่ใช่ว่าผลิตเพื่อให้มีของหรือดัน feature ออกมาอย่างเดียว แต่ก็ต้องเข้าใจเรื่องลูกล่อลูกชนเชิงธุรกิจควบคู่กับการผลิตไปด้วย ทำของออกมาแต่ไม่มีคนใช้หรือซื้อก็อาจจะเสีย cost และ resource ไปโดยไม่ได้อะไรกลับมา บางครั้งอาจจะมีมุมมองว่า เป็นส่วนนึงของแผนก็ได้ใช่ไหม ว่าแต่แผนอะไร หน้าตาเป็นยังไง หรืออีกมุมมองนึง คืออย่างน้อยทีมก็เก่งขึ้น ไม่ก็เอาของที่สร้างแล้วไป reuse ได้เนอะ หวังว่านะ
They must first figure out who the customers are and what problems the customers have.
การสร้าง Product ก็คือการที่มีคนใช้งาน ไม่ว่าจะ B2B หรือ B2C ก็ตาม ก็คือมีคนใช้งานเสมอ (ถึงแม้ว่าบางครั้ง B2B จะเข้าคอนเซปว่า “คนซื้อไม่ได้ใช้ คนใช้ไม่ได้ซื้อก็ตาม”) เรื่องนี้ถ้าเติมเรื่อง UX เข้าไป ก็คือควรจะได้เจอและเข้าใจผู้ใช้งานหรือลูกค้าจริงๆ ถึงแม้ว่าบางครั้งคนทำงานจะเป็นผู้ใช้งานหรือลูกค้าก็ตาม แต่บางครั้งก็อาจจะมี bias ของธรรมชาติมนุษย์อยู่ก็ได้ หรือบางครั้งปัญหาของแต่ละคนอาจจะเบาหนักต่างกัน อีกทั้งถ้ายิ่งเป็นคนทำงาน ก็คงอาจจะมองข้ามไปได้ หรือเคยชินกับ task/flow นั่นแล้วเลยทำให้มองข้ามความยุ่งยากไป เลยมีคำกล่าวในกลุ่ม UX อยู่บ่อยๆ ว่า “You are not user” (จริงๆ ในเชิง UX จะมีคำว่า Cognitive Walkthrough โดยอาจจะใช้วิธีดึงเพื่อนร่วมงานนอกโปรเจคหรือนอก scope งานมา join ก็ได้นะ เสมือน quick/dirty testing แบบเบาๆ แต่ population อาจจะไม่ได้เยอะ ต้องลอง trade-off ดูนะครับ)
They must know how to set a vision, finding the right opportunities in a sea of possibilities, by using both data and intuition.
รู้วิธีการตั้ง Vision หรือวิสัยทัศน์ เพื่อหาโอกาสต่างๆ ในความเป็นไปได้ที่หลากหลาย (สังเกตว่าเค้าใช้ opportunities และ possibilities ด้วยนะ ไม่ใช่ opportunity กับ possibility เท่านั้น) และต้องใช้ data หรือข้อมูล (ที่ไม่ใช่แค่ตัวเลขนะ อาจจะเป็นการได้มาจากการพูดคุยซ้ำๆ กับ Research อย่างเป็นประจำ หรือจากเครื่องมือต่างๆ เช่นระบบ Customer Support) “and intuition” ไม่รู้ผมอาจจะคิดมากไปเอง คำดูเหมือนไม่มีอะไร แต่การใช้คำว่า “and” มันหมายถึงต้องควบคู่กันนะ และคำว่า “intuition” ถ้าแปลบน Google Translate เอาง่ายๆ แปลว่า “สัญชาตญาณ” ซึ่งสำหรับผมแล้ว การจะมีสัญชาตญาณได้ มันคือเกิดจากการลงมือทำซ้ำ จนเกิดเป็นความชำนาญ และความชำนาญที่สะสมมาเรื่อยๆ จนกลายเป็นสัญชาตญาณ (แต่ถ้าให้ขยายความจากความเห็นส่วนตัว ควรอธิบายความคิดเบื้องหลัง หรือ thought process กับคนอื่นหรือทีมงานด้วยว่าคิดจากอะไร เพื่อให้ทีมงานเข้าใจและขยายความสามารถในการพิจารณากับคนอื่นด้วย)
They must know how to define success, for the customer and the product, by prioritizing doing what is right over doing what is easy.
อะไรนะที่เป็นตัวบอกว่าสิ่งที่เราทำกับ Product มันบอกว่า “สำเร็จแล้วนะ” ลูกค้าทำอะไรหรอถึงเรียกว่า Product เราสำเร็จแล้ว ความสำเร็จมันหน้าตาเป็นยังไง การจัดลำดับความสำคัญเพื่อผลิต Product ไม่ใช่แค่ทำแต่เรื่องง่ายเสมอไป ส่วนตัวถ้าผู้อ่านอ่านมาถึงตรงนี้แล้วนึกไม่ออก ตอบ 3 ข้อบนก่อนหน้าหัวข้อนี้ได้ก็ถือว่าดีมากแล้ว ถ้าจะตั้งประเด็นคำว่า “Prioritize” อาจจะต้องกลับไปคิดกันต่อว่า เรามีเกณฑ์ หรือ Criteria อะไรบ้างนะ ที่บอกว่ามันสำคัญ เช่น Vision/Strategy Company, Roadmap, Issue, Legal หรืออะไรบ้าง แล้ว Criteria นี้ทำไมถึงยอมรับได้ ก็คงต้องคุยกันเยอะๆ อธิบายเยอะๆ เพราะทีมที่มี Expertise ที่หลากหลาย ก็จะตามมาด้วยมุมมองที่หลากหลายเช่นกัน
They must know how to work with engineers and designers to get the right product built, keeping it as simple as possible.
Product มันจะเกิดขึ้นจาก Product Manager ทั้งหมดก็คงเห็นจะยาก (น่าจะมีคนเถียงคอเป็นเอ็น พออ่านตรงนี้แล้วคงจะบอกว่า “ฉันนี่ไง!!”) แต่โดยทั่วไปแล้วสรรค์สร้าง Product ขึ้นมาในปัจจุบันก็ต้องประกอบไปด้วย Specialist หลัก คือ Engineer คนที่ทำให้ภาคเทคโนโลยีเกิดขึ้นได้ เช่น การเขียนโปรแกรม, การจัดการเรื่องระบบฐานข้อมูลหรือ Database และอีกหลากหลายย่อยที่ปัจจุบันนี้ฝั่งนี้ซับซ้อนมากขึ้นหรือหลากหลาย Role & Responsibilities เช่น Front-end, Bankend, DevOps, ML, และอื่นๆ ซึ่งอีกฟากนึงก็ไม่แพ้กัน ก็คือฝั่ง User หรือคนที่เข้าใจผู้ใช้งาน (แม้ว่าหัวข้อมันจะบอกว่า Designer ก็ตาม แต่ต้องมีคนไม่ยอมแน่นอน!) การจะเข้าใจและทำให้ผู้ใช้งาน Happy ก็มีคำหลักก็คือ UX และ UI ใครมาสายนี้หรือทำงาน Product ก็น่าจะทราบดีกว่าปัจจุบันมีความหลากหลายชั้นไปอีก เช่น UX Research, UX Write, Interaction Design, Information Architect, Qualitative Research, Quantitative Research, Usability Testing, และอีกมากมาย แต่ๆๆๆ จากประสบการณ์แล้ว ก็ต้องเข้าใจโจทย์และขอบเขตอีกด้วยว่า จะหยิบหรือเลือกใช้ยังไงให้เหมาะสมกับตอนนั้น รวมถึงเพื่อนร่วมทีมเราเข้าใจการ trade-off ครั้งนั้นมากน้อยแค่ไหน “get the right product built, keeping it as simple as possible.”
They must know how to work with marketing to explain to the customer how the product fills the customer’s need better that competitor’s product.
ข้อนี้น่าจะพูดเหมือนคล้ายๆ ข้อบนมาบ้างแล้ว แต่อาจจะขอขยายในส่วนของการตลาดหรือ Marketing ว่า Product Manager ต้องรู้วิธีการบอกเล่าตัว Product ให้กับลูกค้าว่ามันตอบโจทย์ยังไง ดีกว่าปัจจุบันที่เค้ากำลังใช้อยู่ยังไง ตอนสมัยที่เคยทำ PO แรกๆ ถูกเรียนรู้มาว่า “มันไม่ใช่ว่าเราไปบอกลูกค้าว่าเราทำอะไรได้ แต่เราต้องบอกเค้าได้ว่ามันไปช่วยชีวิตเค้าดีขึ้นได้ยังไง” และบางครั้งการพูดถึง Competitor หรือคู่แข่งอาจจะไม่เหมาะก็ได้ (โดยส่วนตัวคิดว่าแบบนั้นทุกครั้งน่าจะดีกว่า ไม่พูดถึงเลยกับลูกค้าน่าจะดีกว่า)
They must do whatever’s needed to help ship the product, finding solutions rather than excuses.
ประโยคนี้นี่มันสุ่มเสี่ยงจัง ฮ่าๆ คือการบอกว่า “do whatever’s needed to ship the product” อ่านแล้วแบบอุทาน “จะทำอะไรก็ได้หรออออ เอาจริงดิ” ข้อนี้คิดว่าใครอ่านน่าจะหลากหลายมุมมอง เพราะสุดท้ายมันก็คือการพูดถึงต่อว่า “finding solutions” ก็คือการหาวิธีการและประกอบด้วยการไม่ขัดกับเรื่องใดๆ ที่กล่าวไปแล้วบนๆ ด้วย (รวมถึงข้อล่างที่จะบอกด้วย นั่นก็คือเรื่องของทีม) ซึ่งมันก็น่าสนใจแหละที่จะบอกว่า “finding solutions rather than excuses.” ดูเป็นวลีปกติมากเมื่อลองไป search หาใน Google ก็มีประโยคจากในเว็บนึงว่า “Who always give excuses for their failures and wrongs, never go far in life.” ว้าววว
Sometimes, this even means a PM getting coffee for a team that’s working long hours to show appreciation.
สั้นๆ อันนี้ meaning ของผมมันคือการให้เวลากับทีม ใส่ใจทีม ดูแลทีมด้วย หรือถ้า sprint/iteration ไหนผ่านไปได้ด้วย ก็คือการ celebrate กับทีมนั่นแหละ เป็นเรื่องนึงที่ต้องให้ความสำคัญมากๆ ถ้าจะเล่าต่อยอดจากเรื่องการทำงานกับ Engineer หรือ UX ด้วยก็ตาม เป็นเรื่องนึงที่ช่วงแรกผมทำ PO ก็จะบอกเสมอว่า PO นอกจากดูแลภาพใกล้ ภาพไกลแล้ว อย่าลืมดูแลทีมด้วย มันไม่ใช่แค่การส่ง Requirement ให้ทีมผลิต ทำ อย่างเดียว แต่การให้เวลากับเรื่องสุขภาพ จิตใจ หรือ Empathy เพื่อนร่วมงานด้วยก็เป็นพื้นฐานชีวิตที่สำคัญด้วย อย่ารอให้วันที่ Product มัน success แล้วค่อยมาขอบคุณขอโทษกัน (ซึ่งหน้าตาความ success เป็นยังไงก็ไม่รู้) เพราะการทำงานไม่ใช่แค่เรื่องของผลลัพธ์ แต่เป็นเรื่องของระหว่างทางที่เกิดขึ้นด้วย 🙂
ประมาณนี้แล้วกัน หวังว่าจะเป็นประโยชน์ต่อผู้อ่านมาถึงตรงนี้นะครับ 🙂 ไว้อ่านเจออะไรดีๆ จะเอามาเล่าบวกกับประสบการณ์อีก ขอให้ทุกคนมีความสุขกับการสร้าง Product กันนะครับ