หลังจากที่ผู้เขียนได้มีโอกาสคุยกับหลายๆ คน ทั้งที่เป็นคนจบใหม่, คนที่อยากย้ายสายงานมาเป็น Product Manager หรือคนที่ได้เป็น PM แล้วแต่ย้ายมาจากสาย Business & Design จะมีชุดคำถามหรือความกังวลที่เราได้ยินบ่อยๆ ประมาณว่า

เป็น Product Manager จำเป็นต้องเข้าใจ Tech มั้ย?
เรียนสาย Business/ สายสังคมมาตลอดเลย รู้สึกกดดัน เพราะฟัง Dev คุยกันไม่รู้เรื่อง
ถ้าไม่มีพื้นฐาน Tech มาก่อน จะทำ Digital Product ได้รึเปล่า?

ซึ่งในบทความนี้ เราเองขอมาแชร์มุมมองรวมถึงไอเดียที่หวังว่าจะเอาไปใช้ต่อได้จริงให้กับผู้ที่ประสบปัญหาเหล่านี้ จากประสบการณ์ของเราล้วนๆ ตลอดการทำงาน Product Manager ที่ผ่านมา

หวังว่าบทความนี้จะได้เป็นส่วนหนึ่งของคำตอบสำหรับคำถามที่ค้างคาอยู่ในใจ และเป็นกำลังใจให้คนที่กำลังมีข้อกังวลเหล่านี้อยู่

อ่านจบแล้วก็ลองเอาไปย่อย ไปปรับใช้ในบริบทของตัวเองตามสมควรกันนะคะ 🙂 (มุมมองทั้งหมดนี้เป็นของข้าพเจ้าแต่เพียงผู้เดียว)

เป็น Product Manager ใน Digital Product จำเป็นต้องเข้าใจ Tech มั้ย?

สำหรับเราคือ “จำเป็น”

แต่ก่อนจะมาลงรายละเอียดสิ่งนี้ มาชวนคิดกันก่อนว่า “จำเป็นที่ความรู้และความเข้าใจประมาณไหน?”

ซูมออกมาดูตำแหน่ง “Product Manager”

จริงๆ ในไทยเอง ชื่อตำแหน่งนี้ถูกใช้กันแพร่หลายมาก แต่เนื้องานจริงๆ มันแล้วแต่บริบทของบริษัท

ในบางบริษัทเอง Product Manager แทบจะไม่ได้แตะอะไรในส่วนของ Development เลย คิด Strategy, ดู Profit & Loss, ดู Go-to-market ล้วนๆ (คิดว่าจะทำยังไงให้ Product นี้มันขายได้) หรือว่าโฟกัส Customer สุดๆ เน้น User ไปเลย ทำยังไงให้ User ชอบเรา ต้องมี Experience ยังไงบ้าง

ในบางบริษัทเอง Product Manager ทำงานใกล้ชิดกับทีม Development หรือบางที่มีตำแหน่งเรียก Product Owner หรือเน้น Technical หนักๆ แบบ Technical Product Manager ด้วยซ้ำ (ดูในส่วนของ Platform เช่น Authentication, Payment)

ซึ่งพอเล่ามาถึงตรงนี้ก็จะเริ่มเห็นภาพแล้วว่า จริงๆ ตำแหน่ง Product Manager ในแต่ละบริษัท ก็ล้วนแต่มีความลึกตื้นที่คาดหวังสำหรับ Tech Knowledge ต่างกัน หรือแม้กระทั่งในบริษัทเดียวกัน PM แต่ละคน ก็มีความลึกตื้นที่ต้องการต่างกัน (เพราะถือ Product คนละตัว)

ดังนั้น สิ่งที่อยากชวนทำก่อนคือ

ถ้าเป็นคนที่อยู่ในช่วงเริ่มต้นหางาน/ อยากย้ายสาย: เริ่มอ่านจาก Job Description ของบริษัทก่อน ถ้าบริษัทไหนเขียนละเอียดก็จะง่ายสำหรับเราหน่อย แต่อย่างไรก็ตาม หากเราได้มีโอกาสสัมภาษณ์กับหัวหน้าทีม ก็ให้ถามถึงเนื้องานและความคาดหวังของเขาไปเลยตรงๆ

ถ้าเป็นคนที่ได้เป็น Product Manager แล้ว หรือจับพลัดจับผลูโดนย้ายจาก Business/ Design team มาที่ตำแหน่งนี้พอดี: ลองประเมินคร่าวๆ จากบริบทของทีม หรือเราคุยกับทีมเลยตรงๆ ก็ได้ ว่าเขาคาดหวังให้เรามีความรู้เกี่ยวกับ Tech ประมาณไหนบ้าง ทีมเองมองว่า PM ที่ดีสำหรับเขาต้องเข้าใจอะไรบ้าง แล้วเราก็ค่อยๆ เติมตรงนั้นดูค่ะ

ซูมออกอีกนิด ให้เห็นภาพ “Development Team“

สมมติว่า อะ ไปศึกษาตามข้อบนมาละ คิดว่าจะได้ทำงานที่ต้องมีคุยกับทีม Dev แน่ๆ

ชวนซูมออกเพิ่มอีกให้เห็นภาพ จริงๆ แล้วใน Product Development Team เรามี Software Engineer (หรือ Developer) ที่เปรียบเสมือน Tech Expert ในทีมอยู่แล้ว ดังนั้นถามว่าต้องรู้ทุกระเบียดนิ้ว ระดับที่ต้อง Code เก่ง, รู้เทคนิค หรือ ต้องออกแบบ Architect ได้อย่างสวยหรูเลยมั้ย คำตอบสำหรับเราก็คือ ก็ไม่ต้องขนาดนั้น

เคยมีน้องที่บริษัทคนนึงมาปรึกษาว่า สมมติเขาอยากจะเริ่มศึกษาหาความรู้ต่อยอด เขาควรจะเลือกไปสาย Business & User, Data หรือเป็นสาย Technical ไปเลยดี?

สิ่งที่เราแนะนำก็คือ ให้นึกไว้เสมออย่างนึงว่า สุดท้ายแล้วคนที่ต้องตัดสินใจให้กับทีมว่า “อะไรคือ Priority” คือเราเองในฐานะ Product Manager นี่คือหน้าที่ของเราที่ต้องทำ ดังนั้นลองถามตัวเองว่า แล้วข้อมูลอะไรล่ะ ที่เราจำเป็นต้องมี เพื่อให้เราตัดสินใจมันได้ดีขึ้น

ก่อนจะรู้ Tech ต้องรู้จัก Product ให้ดีก่อน

แล้วต้องรู้ขนาดไหน?
จริงๆ แอบซ่อนคำตอบอยู่ใน Paragraph ที่แล้ว นั่นก็คือ

รู้แบบที่ทำให้เรามีข้อมูลมากพอในการตัดสินใจ รู้ให้เราทำงานได้

ยกตัวอย่างให้เห็นภาพกันมากขึ้น

#1 – รู้ว่า Product เราทำงานยังไงอยู่บ้าง? Logic เบื้องหลังของ Product เราคืออะไร?

เหตุผลที่ควรรู้: เพราะเราต้องทำงานกับมัน

จริงๆ แล้ว Logic เบื้องหลังของ Digital Product ก็มาจาก Business Logic นั่นแหละ สมมติเราไม่ใช่ PM คนแรกของ Product นี้ แต่เราต้องทำงานกับมันอยู่ดี เราก็ต้องเข้าใจให้ได้ว่า มันทำงานยังไง

เอาให้เห็นภาพ สมมติว่าเราเป็น PM ของเว็บไซต์ขายของ ถ้าวันนี้มีลูกค้าทักมาว่าใช้คูปองส่วนลดไม่ได้ อย่างน้อยเราต้องจินตนาการให้ออกว่า คูปองจะใช้ได้หรือไม่ได้นี่มัน Validate อะไรบ้าง เช่น วันหมดอายุ?, จำนวนสิทธิ์คงเหลือ? หรืออื่นๆ เพื่อที่เราจะได้ตรวจสอบเบื้องต้นได้

ถามว่าถ้าเราไม่รู้แล้วทำงานได้มั้ย คำตอบคือได้ ก็คือให้ Dev ช่วยเช็คให้ แต่แปลว่าคำถามทุกอย่างเรารอ Dev หมดเลย ซึ่งลูกค้าทุกคนไม่ได้รอเราเสมอไป และกลายเป็น Dev ต้องหยุดทำงานของตัวเอง เพื่อมา Investigate เคสเบื้องต้นให้เราอีก

เอาอีกตัวอย่าง สมมติว่าเราเป็น PM ของ App ธนาคาร วันนี้เรามีโจทย์ว่าอยากให้ลูกค้าสมัคร App เราง่ายขึ้น จริงอยู่ที่เราต้องเข้าใจ Pain point ของ User ว่ามันยากอะไร ติดตรงไหน แต่ก่อนถึงจุดนั้นเราก็ต้องเข้าใจก่อนว่า แล้ว Flow สมัครเราเป็นยังไงอยู่ ตอนนี้ขอข้อมูลอะไรบ้าง อะไรจำเป็นและไม่จำเป็นต้องใช้

*ตัวอย่างภาพ flowchart ของการ create order จาก github (natural programmer)*

#2 – รู้ว่า Product เราทำอะไรและทำอะไรไม่ได้บ้าง?

เหตุผลที่ควรรู้: สามารถคิดหา Quick win ให้กับ Product ของเราได้

งานที่ Product Manager ต้องทำกันอยู่เสมอ คือ ตั้งคำถามและหาคำตอบ ซึ่งมันจะมีประโยชน์สุดๆ ถ้าเรารู้ว่า Product เราทำอะไรได้อยู่แล้วบ้าง

สมมติว่าวันนี้เราเป็น PM ของ App Telemedicine (พบหมอทางออนไลน์) แล้วหัวหน้าทีมเดินมาถามว่า ถ้าอยากเพิ่ม Revenue ให้บริษัท คิดว่าเราควรทำ Service นัดหมอกายภาพดีมั้ย? สมมติว่าหัวหน้าไป Validate ในเชิง Business มาแล้วด้วยว่ามันน่าจะได้กำไร แค่ไม่รู้ว่ามี Demand รึเปล่า

ถ้าเราไม่รู้ว่า Product เราทำอะไรได้บ้าง

เราอาจหาคำตอบนั้นด้วยการทำ User Interview ซึ่งในความเป็นจริงสิ่งนี้มันลงทุนเยอะ โดยเฉพาะ “เวลา” (ต้องหาคน คัดคน นัดคน แล้วเอากี่คนด้วยถึงจะมั่นใจ)

ถ้าเรารู้เพิ่มว่า Product เราเก็บข้อมูล Email ของลูกค้าไว้ และขอ Consent เรียบร้อย

เราอาจมีตัวเลือกเพิ่ม เช่น สร้าง Survey Form ขึ้นมา แล้วส่งไปทาง Email ให้ลูกค้าตอบ และปกติ Average Survey Response Rate อยู่ที่ 6-16% (ที่มา) แปลว่าถ้าจะเอาสัก 100 response ก็ต้องส่งอย่างน้อยประมาณ 625 คน อาจรอคนมาตอบสักพัก คนตอบน้อยไปก็ต้องส่งเพิ่มอีก รวมถึงคำถามก็ต้องคิดดีๆ ระวัง User bias อีกต่างหาก

ถ้าเรารู้เพิ่มว่า Product ของเรา สามารถตั้ง Banner ได้เอง โดยไม่ต้องให้ Dev ทำให้

เราอาจมีตัวเลือกเพิ่มว่า งั้นเราตั้ง Banner ชวนคนที่สนใจมาลงทะเบียนก่อน แล้วลองดูว่า Click through rate & Registered rate ของโปรแกรมนี้เป็นเท่าไหร่

ยกตัวอย่างให้เข้มข้นขึ้นอีกนิด

สมมติ Demand check มันออกมาแล้วว่า User สนใจ คำถามต่อไปคือ แล้วเราจะทำยังไงให้มันออกสู่ตลาดได้เร็วที่สุดล่ะ?

ถ้าเราไม่รู้เลยว่า Product เราทำงานยังไงบ้าง

เราอาจบอกว่า งั้นเราก็สร้าง Product ใหม่ออกมาเลย สร้างระบบให้หมอกายภาพมาใส่ข้อมูล สร้างระบบการจอง สร้างระบบแจ้งเตือนหมอกายภาพ ฯลฯ

ถ้าเรารู้ว่า Tool ในการตั้งค่าโปรไฟล์ของคุณหมอ (Product เดิม) ทำงานยังไง

เราอาจมีตัวเลือกในการประยุกต์ใช้ Tool เดิม แล้วเพิ่มเติม Feature นิดหน่อยเพื่อตอบโจทย์ข้อมูลของหมอภายภาพ แล้วยังสามารถ Reuse พวกระบบการจองที่มีดั้งเดิมอยู่แล้วได้ด้วย (มีโอกาส Go to market เร็วขึ้น)

#3 – รู้ว่า Product ของเรามี Service อะไรที่เกี่ยวข้องบ้าง แต่ละ Service ทำหน้าที่อะไร?

เหตุผลที่ควรรู้: ทำ Impact Analysis ได้, คุยกับ Dev รู้เรื่อง

ต่อยอดจากรู้ที่แล้ว จากปัญหาที่ว่าลูกค้าใช้คูปองไม่ได้ สมมติว่าเราไปตรวจสอบมาแล้วแหละว่า ลูกค้าใส่โค้ดถูกต้อง การตั้งค่าคูปองทุกอย่างปกติ คูปองยังเหลืออยู่ ยังไม่หมดอายุด้วย สันนิษฐานได้ว่ามันน่าจะมาจาก Technical Issue นี่แหละ

ถ้าเรารู้ว่า Service ไหนเป็น Service ที่ถือ Logic ในการ Validate Coupon Condition เราก็สามารถ Troubleshoot ปัญหาให้ Team ที่ดูแล Service นั้นได้ โดยที่ไม่ต้องรอให้ส่งต่อ Issue กันเป็นทอดๆ

สำหรับผู้เขียนเอง ข้อนี้ถือว่าอาจยัง Optional สำหรับบริษัทขนาดเล็กที่มี Dev อยู่ทีมเดียว (เพราะเขาคุยกันเองอยู่แล้ว) หรือบริษัทที่มี Technical Project Manager/ Business Analyst ที่ทำหน้าที่ตรงนี้อยู่แล้ว

แต่ถ้า Product Manager คนไหนที่สามารถมองเห็นภาพได้ตั้งแต่ต้นจนจบว่าระบบมันทำงานอย่างไร (คิดภาพเป็นโรงงานผลิตรถยนต์แห่งหนึ่ง) ก็จะสามารถรู้ Gap, ทำ Analysis ได้, คุยกับ Dev รู้เรื่องง่ายมากขึ้นนั่นเอง (แต่ก็ต้องระวังว่าเราจะรู้จนเผลอไปคิด Solution แทน Software Engineer จนเกินไปนะ)

จากทั้งหมดที่เล่ามา จะเห็นว่าสำหรับงาน PM ผู้เขียนให้ความสำคัญกับการ “เข้าใจ Product” มากกว่า “เข้าใจ Tech” ซะอีก

พอเข้าใจ Product เบื้องต้นแล้ว ก็ไปเติมความรู้ Tech กัน!

สำหรับช่องทางการเติมความรู้ Tech จริงๆ ต้องบอกว่ามีหลายช่องทางมาก แล้วแต่สไตล์ของแต่ละคน อย่างเพื่อนของผู้เขียนก็มีสายชอบเรียนออนไลน์ ชอบลงมือทำเข้าใจถึงทฤษฎีไปเลยถึงแก่น ไม่ว่าจะ Take Online Course, ลง Bootcamp, ทำ Open Source Project ฯลฯ

อย่างผู้เขียนเองเป็นสายเรียนรู้จากหน้างาน เลยขอแชร์เรื่องราวการเรียนรู้จากประสบการณ์ของตัวเอง ดังนี้

Background: เราเริ่มเข้าสู่วงการ Product Management ครั้งแรกด้วยตำแหน่ง Business Analyst แล้วไปเป็น Assistant Product Owner ที่ MONIX -> ย้ายมาทำ Business Analyst ที่ LINEBK ต่อ แล้วก็ได้โอกาสเป็น Product Manager -> จากนั้นมาเป็น Product Manager ที่ NocNoc

เรียนรู้ยังไงบ้าง?

#1 – อ่าน Doc เข้าใจ Logic flow ทั้งหมด Service ไหนทำอะไร แล้วถามต่อยอดจากสิ่งที่สงสัย

ที่ได้อ่านอย่างเข้มข้นเลยคือตอนที่เป็น Business Analyst ที่ LINEBK เพราะตอนนั้นทีมงานชุดเก่าไม่อยู่แล้ว (ตอนแรกจ้าง Consult)ก็เลยไล่อ่านทุก Document ที่ Transfer มาให้ ไม่ว่าจะเป็น Business logic (ที่ระบุว่า Service ไหนเป็นคนทำงานสิ่งนี้), Configuration, High-level architecture, Sequence diagram (ในส่วนที่เราต้องทำงานด้วย)

ซึ่งตอนนั้นก็มีทั้งส่วนที่เข้าใจและไม่เข้าใจ (ฮ่าๆ) แต่พอเราไม่เข้าใจปุ๊ปเราก็ขวนขวายต่อ

ไปหาโอกาสคุยกับ Tech team ที่เขาดูมีความตั้งใจที่จะสอนเรา ไม่ว่าจะ Software Engineer (Dev, SA) หรือ QA แล้วก็จดตาม พยายามทำความเข้าใจ ยิ่งตอนที่คิดว่าทำให้ตัวเองจำได้ดีที่สุด ก็คือตอนที่เราไล่เขียน User story และได้รับ Feedback ก็จะยิ่งเห็น Gap ที่เรายังไม่รู้ และเติมความรู้ไปเรื่อยๆ นั่นเอง

สำคัญที่สุดก็คือ “กล้าลุย กล้าคิด กล้าถาม”

#2 – ไปลองทำงานในตำแหน่งเขาสักช่วงเวลานึง

ตอนทำงานที่ MONIX ช่วงนั้นเป็นช่วงบริษัทตั้งใหม่เลย (กำลังจะคลอด “ห้าให้มันนี่” ซึ่งปัจจุบันได้กลายเป็น “FINNIX” ไปแล้ว) ตอนนั้นบริษัทยังไม่มี QA ที่เป็นคนไทยที่จะมา Verify เลย เราก็ได้โอกาสจับพลัดจับผลูไปทำงานเป็น QA มือใหม่อยู่สักพักนึง (ประมาณ 5-6 เดือน)

ตอนนั้นไม่มีความรู้อะไรเลยเกี่ยวกับ QA คือปรึกษาพี่รอบตัว, ศึกษาข้อมูล Way of Working ของ QA เบื้องต้น ลองคิด Test matrix, Test scenario, Test case, วาง Test priority, เตรียม Test data ไปยัน Execution, วาง Flow การทำงานเพื่อแก้ไข Bug ร่วมกันระหว่าง Developer & QA (ซึ่งตอนนั้นผู้เขียน Cover แค่ Functional test แบบ Manual นะ ยังไม่ได้ไปถึง Automated test, Performance test, Penetration test อะไร)

เอาจริงๆ ตอนนั้นผู้เขียนยังใหม่มากๆ แอบเม้าท์ตัวเองด้วยว่ามีความงอแงกับหัวหน้าด้วยว่าอยากกลับไปจับงาน Product แต่จนมาถึงวันนี้ ก็ยังรู้สึกขอบคุณหัวหน้า (พี่หนึ่ง ถิรนันท์) เสมอมาที่ให้โอกาสเราไปทำตรงนั้น วันนี้ที่มารันทีม as a Product Manager มันทำให้เราเห็นภาพตั้งแต่ต้นน้ำยันปลายน้ำเลย

#3 – อย่าปล่อยให้คำถามเป็นคำถามตลอดไป

เคยสงสัยมั้ย ว่าทำไมเวลาโหลดหน้าเว็บไม่ขึ้น มันแสดง 404 Not Found

มันจะมีอยู่แล้วที่เวลา Dev คุยกันแล้วงงว่าคุยอะไรกันนะ ซึ่งผู้เขียนก็จะแนะนำว่า ถ้าเริ่มได้ยินบ่อยๆ ให้จดไว้ แล้วเอาไปศึกษาต่อ อย่างเช่นตอนนั้นผู้เขียนชอบได้ยิน Dev พูดว่า มัน Return 200, 400, 404, 500 เราก็มีความอยากเข้าใจอะ (5555555+) ก็เลยไปเสิร์จหาใน Google ซะเลย ก็ไปเจอบทความนี้ >> APIs 101 for Product Managers

เท่านั้นแหละ กระจ่างแจ้ง ได้เข้าใจ APIs มากกว่าเดิมอีก!

ซึ่งก็จะมีบทความหรือคำอธิบายเยอะแยะที่คนเขียนไว้ เราก็ไปตามอ่าน หรือบางเรื่องผู้เขียนลง short course ไปเลยก็มี แล้วถ้ายังไม่เข้าใจอีก ก็ลองไปชวนทีมคุยเวลาว่างๆ อย่างน้อยก็ทำการบ้านมาบ้างแล้วค่ะ 🙂

สุดท้ายนี้

จากที่ผู้เขียนเล่าไปทั้งหมดนี้ ก็หวังว่าจะได้ช่วยเป็นไอเดียและแรงบันดาลใจ ให้กับ Product Manager มือใหม่ที่อาจมีความกลัวว่าทำไม่ได้ ไม่เข้าใจ Tech ไปจนถึงกังวลว่าฉันคงจะเป็น PM ที่ดีไม่ได้

ถ้าวันนี้รู้สึกแบบนั้น และยังกลัวมันอยู่ ก็ขอให้ “ยินดีกับความกลัว”
จงมองมันเป็นสัญญาณแห่งความหวัง เพราะเราอยากทำให้ได้ดี เราถึงกลัว (กลัวจะออกมาไม่ดี)

และเราจะมาค่อยๆ ผ่านความกลัวไปด้วยกันในฐานะ “ผู้กล้า” ให้ได้ค่ะ

เขียนมาจนถึงตรงนี้ ผู้เขียนขอขอบคุณครูที่ดีทั้งหมดในชีวิตการทำงานที่ผ่านมา ตั้งแต่ที่ SCB10X, MONIX, LINEBK, NocNoc โดยเฉพาะพี่กะปิ, พี่หนึ่ง, พี่เอ็ด, พี่ไมกี้, พี่มอลลี่, พี่สาว, พี่นิน, พี่มิก, พี่โอ๊ค, พี่เป้ง, พี่อ๊อด, พี่เลน, พี่บอย, พี่เบล, พี่มาย และทีมงานทุกคนที่เซปทำงานด้วยแต่อาจไม่ได้กล่าวถึง

อย่างที่บอกว่าเซปเป็นคนเรียนรู้จากการลงมือทำมากๆ ถ้าไม่ได้พี่ๆ ก็น่าจะเหนื่อยกว่านี้แน่นอน และเซปก็ยังมีอีกหลายอย่างมากที่ยังต้องเรียนรู้ ยังไงก็ฝากตัวกับครูคนไหนที่เซปจะได้เจอในอนาคตด้วยนะคะ 🙂

และหากคุณชอบคอนเทนต์นี้ และอยากฟังเรื่องราวจาก Product People คนอื่น ๆ เพิ่มเติม อย่าลืมกดติดตาม PM Corner ผ่านช่องทางดังต่อไปนี้ได้เลย

Facebook Page: PM Corner Thailand
Website: PM Corner
Youtube: https://www.youtube.com/@pmcornerthailand (สำหรับรับชม live ย้อนหลัง)

เริ่มต้นเข้าใจ Product ยังไงดี ถ้าเป็น Product Manager ที่ไม่มีพื้นฐาน Tech มาก่อน?

Table of Contents