“ศิลปะการปฏิเสธ user ของ PO/PM”
ในบริษัทขนาดใหญ่ที่มีการเอา framework scrum มาใช้ จะเกิดตำแหน่ง role ที่เป็นคนควบคุม requirement (backlog, story หรือ PBI) ที่จะทำ แต่หลายครั้งในโครงสร้างองค์กรใหญ่ที่ PO ไม่ได้มีอำนาจตัดสินใจทั้งหมด ต้องให้ User สั่งมา** เป็นต้น แม้มาเทียบ value ทางทฤษฏีไหนๆ อาจจะไม่ได้อยู่ใน theory นั้นเลย แต่ชีวิตจริง required เหล่านี้เราย่อมเจอการแทรก priority เสมอ
แต่ทุกอย่างถ้าตามทฤษฏีจะ MOSCOW, Stack ranking, WSJF, CoD เป็นต้นอาจจะช่วยในสถานการณ์นี้ไม่ได้ ดังนั้น ขออนุญาตุแชร์เป็นเคสๆ เผื่อมีประโยชน์ว่า
“บางทีเราปฏิเสธ/ignore แล้วเขาอาจจะมาขอบคุณเราทีหลัง” ก็ได้
1. “ให้จำไว้ไม่ใช่ user ทุกคนที่ควรให้ comment” (Know your target audiences) : จริงๆ เป็นเรื่องดีที่ users ในองค์กรสนใจ product คุณ และอยากจะช่วยนำเสนอว่าทำอันนั้นสิ อันนี้สิ…แต่ถ้า user คนนั้นไม่ได้เกี่ยวกับ ทั้งอำนาจตัดสินใจ หรืออยู่ใน personas เป้าหมายคุณ เลย เช่น คุณกำลังคุยเรื่องของหน้าจอระบบ backoffice ที่ใช้กับหน่วยงานจัดซื้อฯ แต่อยู่ๆ sale ที่ไม่ได้เกี่ยวเลย อยากเสนอหน้าความสวย อันนี้เราก็อาจจะ Noted ไว้ก่อนก็ได้ ถ้า users คนนั้นไม่ได้เกี่ยวกับ universe ของคุณโดยตรง
2. “ให้ระวัง user ที่บ่น หรือ complain ตลอดเวลา” : ในชีวิตคุณเคยเจอคนที่ติมันทุกอย่าง บ่นทุกอย่าง และต้องการตลอดเวลา (อาจจะมีแค่คน 1–2 คนจาก universe of users ทั้งหมดก็ได้) หลักการทำยังไงเหรอ? ก็ทำให้เขา “เงียบ” ก่อน…(ไม่ต้องรีบตอบ ถ้าไม่ใช่เรื่อง urgent คอขาดบาดตาย) เพราะถ้าคุณไปให้ความสำคัญกับ user ที่บ่น และต้องการตลอดเวลาคุณจะเจอปัญหา
* เอาเรื่องเล็กๆ น้อยมาทำ มาแก้ โดยที่คุณอาจไม่ให้เวลากับปัญหาใหญ่ หรือ user กลุ่มหลักเลย
* ถ้ามัวแต่ทำให้ user แบบนี้ demand จะไม่หยุด และเขาจะคิดว่าเข้าถึงคุณได้ตลอด สั่งคุณทำงาน เพื่อ serve เขาผู้เดียว
ดังนั้น คุณต้องมีกลยุทธ์แบ่งกลุ่ม user ในมือให้ชัด ให้กลยุทธ์ที่เหมาะสม ถ้าเราไม่ คิดมิตินี้เวลาที่คุณ priority สิ่งที่จะทำ คุณจะบิดเบี้ยว และคน “บ่น หรือ complain” เก่งจะได้ของเสมอ แม้มันอาจจะไม่ควรเป็น priority เลยด้วยซ้ำ
3. “สิ่งใหม่ หรือนวัตกรรมอาจไม่ได้เกิดจากการตกลงร่วมกันว่าต้องทำเสมอนะ” : เคยไหม ก็ชั้นทำตาม user ขอทุกอย่างแล้วนะ แต่ผลออกมาทำ product กากจัง? ดูเหมือนยำรวมมิตรออกมาเละ, หน้าจอเยิ่นเย้อ, feature หรือ process ซ้ำซ้อน…เพราะ user มีหลายแบบ ถ้าคุณทำ prpduct คุณต้องเห็นวิสัยทัศน์ หรือ benchmark ที่ดี แต่ถ้าคุณไม่รู้อะไรเลย ไปเชื่อ user โดยเฉพาะ operation user หมด เขาก็จะเอาเรื่องหน้างานเขา มา request ซึ่งการทำงานของ user ใน BU นั้นๆ มันอาจจะ process ไม่มีประสิทธิภาพก็ได้ แต่คุณก็ไปตามเขาหมด สุดท้าย product คุณก็แก้ไปเรื่อยๆ ไม่มีวันเป็น innovation product (สิ่งใหม่ที่ดีกว่าได้) เพราะคุณ คือ “Mr./Miss Yes” กับ user
ดังนั้นเวลาทำ product คุณจะมานั่งเป็น PO/PM ถ้ามัวแต่กลัวโดนด่าว่าไม่ได้สั่งให้ ทำ ต้องมารอ user บอกทั้งหมด ผมว่าองค์กรนั้นไม่ได้มี PO/PM จริงๆ นะ ควรเรียก Proxy หรือร่างทรงมากกว่า มาดูชื่อ product พวกนี้ ถ้าเขาทำตาม user request หมด เขาจะ break-through ได้ไหม?
AirBnB : ถ้าฟังเสียงบ่นว่าจะมีลูกค้าที่ไหน ยอมจ่ายเงินค่าไปพักให้สิ่งที่ไม่ใช่ โรงแรม แต่เป็นคนแปลกหน้าคนนึง?
Slack : การสื่อสารในช่องทางที่ทำงาน มันจะสะดวกเป็นส่วนตัวได้ยังไง?
iPhone : ประโยค classic ที่สุดของอดีตผู้บริหารดังที่บอกโทรศัพท์ไม่มี keyboard มันจะ work ได้ยังไง ยังคงเป็น meme ระดับโลกถึงทุกวันนี้แม้ผ่านมา เกือบ 2 ทศวรรษแล้ว
4. “คู่แข่งเรามี features นี้ เราต้องมีด้วยสิ??” : แล้วก็มีทีมการตลาดมาบอกต้องทำ เดี๋ยวมีไม่เหมือนเขานะ อันนี้เป็นเหตุผลที่ผมได้ยินมาตลอดชีวิตบ่อยมาก และสุดท้ายทำไป แทบไม่ได้ใช้ เพราะ โมเดล หรือ way ธุรกิจต่อให้เป็นคู่แข่งมันก็มีจุดเน้นไม่เหมือนกัน ดังนั้น ถ้าจะมาบอกทำเพราะคู่แข่งมี ลองถามกลับแล้วกลยุทธ์ที่จะให้มีตรงนั้น เอาไปใช้ต่อยังไง และผลจะเป็นยังไงด้วยครับ? ชวนกันคิด อย่าให้เหตุผลที่ว่า “เค้ามี เราก็ต้องมี” เป็นเรื่องที่ต้องทำเสมอ
5. “Users don’t know what they don’t know” : User โดยเฉพาะ operation จริงๆ แล้ว requirement เขาคือ สิ่งที่เขาเผชิญ หรือ interface ณ ตอนนั้นแหละ เขาจะไม่ได้มามอง total ways ที่จะช่วยชีวิตเขาจาก product นั้นอยู่แล้ว มันคือหน้าที่สำคัญของคนเป็น PO/PM ที่ต้องขยาย product vision ให้ถูก หา baseline/assumption ที่ถูกต้องในการทำ ดังนั้นให้ถามตัวเองว่าสิ่งที่เขา request นั้น “map เป็น values อะไรได้บ้าง?” อย่าเพียงแค่ “สั่งไรมาก็ทำให้หมด”
6. “เพิ่ม requirement/feature ให้แบบเงียบๆ” : คือขอมาทีละนิดๆ แต่ขอมาเรื่อยๆ ตามช่วงเวลา ไม่ได้มาแบบตูมเดียว แต่ขอไปเรื่อย…จนสุดท้าย เป็นเหมือนโรงงานผลิต feature ให้ user คนนั้น และที่เราไม่ต้องการที่สุดคือ สถานการณ์ที่ product เรากลายเป็นสิ่งที่เรียก “Feature bloat” คือ
1. ถ้ามี new user มาต้องมานั่ง training สอนใช้ หรือ onbarding นานมากๆ
2. ต้องมาเพิ่มภาระให้ user ปัจจุบันเอง เพราะ feature เยอะ ซ้ำซ้อนไม่เป็นระเบียบ บางทีต้องมาเปิดคู่มือมากมาย หรือขอ support ตลอดเวลาเพราะไม่รู้ feature นี้อยู่ไหน เพราะระบบเยอะจัด
3. สุดท้ายเป็นต้มยำ core value ของระบบคืออะไรก็ไม่รู้ (โดยมากมัก เอาคำว่า Super App มาใช้ แต่แค่ยำๆ feature รวมๆ กัน จริงๆ super app มันมีกลยุทธ์ที่ต้องวางไม่ใช่แค่ยำๆ กัน ไว้จะมาเขียนเล่าเรื่องนี้**)
4. High Development and maintenance cost** : แพงไปหมดตั้งแต่ทำ ยันต้องมารักษา
ดังนั้น หน้าที่ PO/PM ที่คุณต้องมี (ถ้าใครไม่มีไปขอให้มี และถ้าไม่มีไม่ได้ แปลว่า คุณลาออกจากที่นั่นเถอะ) คือ “ขอตัดสิ่งไม่จำเป็นออกได้” ไม่มีใครสุดท้ายอยากเป็น “Feature Factory”
7. “Product Vision สำคัญมาก” : มันจะหลงทางมากๆ ถ้า PO/PM ไม่มี product vision เป็นแกน rational ที่จะใช้วางแผน product roadmap หรือสื่อสาร the right thinking อาการ 6 ข้อแรกก็เป็นส่วนมากจากเรื่องนี้ ถ้าคุณมี product vision คุณจะรู้ “Core problems” ที่คุณจะแก้คือเรื่องไหน, ใครคือ user จริงๆ ของคุณ และ product vision จะเป็นสิ่งที่ valid คำถามเหล่านี้
1. สิ่งที่ user ขอมา ตอบหรือสอดคล้องกับ Product Vision ของเราหรือไม่?
2. สิ่งที่ user ขอมา มันเป็นส่วนหนึ่ง หรือทำให้เรา align กับ product roadmap หรือไม่?
3. สิ่งที่ user ขอมาสอดคล้องกับความเป็นแบรนด์ หรือ Value ขององค์กรไหม?
“ถ้าไม่” ไม่ต้องทำ…ถ้าปฏิเสธไม่ได้ ก็ escalate ขึ้นไป
8. “User ไม่ได้ถูกเสมอ” : เรามักถูกสอนมาว่า “The customer is always right” ซึ่งไม่จริงเสมอสำหรับเรื่อง Product Management เพราะบางที user ที่ขอเรื่องนั้นๆ ไม่ได้ขอแบบ business ขอด้วยซ้ำ และการขอของเขาหลายครั้งอาจจะไม่ได้ประเมินเช่น พวกเขาไม่ได้เข้าใจมิติของเทคโนโลยี (ขอสิ่งที่เกินจริง หรือมีวิธีการอื่นที่ต้นทุนต่ำกว่าที่ทำได้), ขอแบบเข้าใจแค่งานตัวเอง แต่ไม่ได้เข้าใจ trend ของเรื่องนั้นไปถึงไหนแล้ว, ขอแบบไม่เข้าใจขีดความสามารถของ product เราบางที product ที่เราทำอาจไม่ใช่ตัวใหญ่ แต่ user ขอ requirement ระดับ ERP ซึ่งงบประมาณคือคนละเรื่องเลย, และหนักกว่าถ้าเราไปขอ operation users เขาไม่เข้าใจ business model ซึ่งมีผลกับ product model/vision ที่เราทำด้วยซ้ำ เป็นต้น ดังนั้น การสื่อสารของ PO/PM สำคัญมาก ถ้าคุณเป็นฝ่ายรับ, ไม่เข้าใจ product vision, ไม่มีศิลปะการต่อรอง คุณแทบจะทำงานนี้ไม่ได้เลยด้วยซ้ำ
9. “Resource มีจำกัดเสมอ เขาถึงให้ต้อง priority” เคยไหมที่ถาม user อะไรสำคัญกว่า เขาบอกสำคัญหมด และต้องได้ในเวลาไล่ๆ หรือพร้อมกัน? แล้วจะหนักมาก ถ้า PO/PM คนนั้น ไม่ negotiate ใดๆ รับทำหมดทุกสิ่ง แล้วมา squeeze ทีมให้เผาทีมให้ทำให้ได้ จน user นั้นเคยชิน…”ใครทำแบบนั้นให้รู้ตัวเลยนะครับ ไม่รู้หน้าที่ของคนเป็น PO/PM เลย” การ negotiate ทั้ง “priority, metric ที่จะวัดผล, หรือ roadmap” คือหน้าที่ของ PO/PM เลย ถ้าทีมไหน ตกในสถานการณ์ที่ ต้อง burn ต้องทำให้ได้ทั้งหมดในเวลาเดียวกัน (นานๆ ครั้งเข้าใจได้) แต่เป็นประจำ…เราอาจต้องเปลี่ยน PO/PM ที่ทำงานกับคุณแล้วนะครับ
10. “เราต้องใจ use-case ของปัญหา ไม่ใช่จะเอา solution อย่างเดียว” : หลายครั้ง users เดินมาหาคุณเลยแล้วก็บอกเลยจะเอา solution “หน้าจอแบบนี้, report แบบนี้, feature แบบนี้ เป็นต้น” คนเป็น PO/PM ต้องชวนเค้าคิดกลับไปจริงๆ เค้าต้องการอะไรกันแน่? ให้ลองถามคำถามพวกนี้กับเขา
1. “Use-cases พี่เป็นยังไง?” (พยายามร่าง use-case ออกมา)
2. พยายามหา context ของเรื่องราวที่เขามาขอ solution นั้นว่า ปัญหาคืออะไร, ใครคือคนใช้, วัดผลได้ยังไง?, รอได้ไหม?, align กับ product roadmap/vision ไหม?, คุ้มที่จะทำไหม?)
3. Outcome หรือ metric ที่ทำนั้น วัดผลยังไง…ถ้าอยากขอขึ้น แล้วไม่ได้ เพิ่มประสิทธิภาพ vs ลดต้นทุน vs เพิ่มรายได้ vs เพิ่มความพอใจภาพรวม เป็นต้น ก็ไม่ใช่สิ่งน่าทำ
4. มันมี Feature ปัจจุบัน หรือระบบปัจจุบันอื่นเอาไปใช้แทนได้ไหม? แค่เปลี่ยนขั้นตอนทำงาน
5. หรือ เกี่ยวกับ product vision/goals หรือเป้าหมายองค์กร/ธุรกิจ/product นั้นไหม ถ้าทำแล้วจะเลื่อนภาพใหญ่ยังไง เป็นต้น
11. “ถ้าคุณเป็น inhouse สำหรับเค้า คุณไม่ใช่ outsource หรือ contractor” : User ในองค์กรใหญ่ มักคิดว่าแผนกไอที คือ คนใช้ส่วนตัว (personal development) บางทีก็มองพวกแกคือ cost center ชั้นสั่งอะไรพวกแกก็ทำไปเถอะ มาถามอะไรมากมาย จนบางทีแผนกไอทีก็กลัวก็ยอมทำตาม จน product มันซับซ้อน ยิ่งปีที่ทำนานมาก ก็ยิ่งทำให้ product นั้นเหมือนสปาเกตตี้บ้าง creep บ้าง แบบแกะปมไม่ออก เพราะ ในแต่ละช่วงเวลา user สั่งงานแบบ personal ตลอด ดังนั้น “ศิลปะการสื่อสาร หรือวาง positioning องค์กรตั้งแต่หัวหน้าหน่วยงานสำคัญมาก” ต้องเริ่มตั้งแต่
1. องค์กรต้องมี process/ทีม/ขั้นตอน ในการ valid “สิ่งที่เข้ามานั้นเป็นประโยชน์ในภาพรวมไหม” เช่น ในหลายหน่วยงานใหญ่จึงต้องให้ความสำคัญ กับ Project Management Office, Product Strategy เป็นต้น
2. กำหนดขั้นตอนช่วย user ให้ชัด อะไรเราจะ build ให้?, อะไรที่เราจะช่วยจ้าง outsource มาทำให้?, อะไรคือ workaround solutions เป็นต้น
3. ไม่อนุญาติให้ user ทุกคนมา request หน่วยงานไอทีตรงด้วยตัวเอง ต้องสร้างกระบวนการ ยิ่งองค์กรใหญ่ ต้องขอ “Gate users” หรือ users ที่จะเคาะได้ในเรื่องต่างๆ มา และเป็นตัวแทนหน่วยธุรกิจนั้นได้
4. ต้องไม่ทำให้องค์กรเป็น project-based (แปลว่าเปิดโครงการ ทำให้เสร็จๆ หนักกว่าคือนับความสำเร็จเป็น project) ต้องคิดเป็น product-based คือเราจะต่อยอด product เดิม หรือ code เดิมไปในทิศทางไหน และเรื่องที่เข้ามาต้องมี product strategy หรือคนจัดว่าอยู่ใน domain ไหน ไม่ทำเป็น project ไปเรื่อยๆ
5. “ปฏิเสธให้เป็น” การปฏิเสธจึงต้องมีตรรกะ และจะปฏิเสธได้คุณต้องที process ทั้งหมด ไม่งั้นไปปฏิเสธเลยคือหักหานน้ำใจ การปฏิเสธ คุณต้องบอก workaround ได้ หรือทางเลือกให้ user ได้เสมอ แต่คุณจะบอกไม่ได้ ถ้าคุณไม่มี กลยุทธ์ และกระบวนการรองรับไว้
12. “บางที user ก็จะลืมๆ ไปเอง” : เคยไหม เร่งทำให้แทบตาบ หรือทะเลาะกับคนเพื่อให้ได้คิว สุดท้าย user ไม่ให้ความสำคัญ ทำเสร็จแล้วไม่ได้ใช้ (อาจะเพราะตัวเองเปลี่ยนแผนเองด้วย) อาจเป็นไปได้จาก
1. Users ใน BUs นั้นไม่ได้มีคนมากวนละ เช่น ผู้ใหญ่อาจจะไม่ได้มาจี้เค้าละ หรือ business plan เปลี่ยนแล้ว เป็นต้น
2. Users นั้นไป workaround หรือ alternative (เช่น ไปซื้อ Software as a service มาก็ตอบโจทย์)
3. Priority ของ users เหล่านั้น shift ไปสู่ปัญหาใหม่
ดังนั้น ถ้าองค์กรโบราณทำเป็น project based เขียน timeline 3–6 เดือน หน่วยงาน ก็จะทำแล้วทิ้งเยอะมาก เป็นต้นทุนมหาศาล ไหนจะต้องมาดูแลอีกต่อไป เป็นบทเรียนว่าทำไมองค์กรต้องมองภาพ เป็น iteration สั้นๆ ให้มากขึ้น รวมถึง “ทุกๆ คำว่าด่วนเนี่ยด่วนจริงไหม?” ซึ่งเวลา คือ สิ่งมหัศจรรย์ทั้งเร่งคนทำ และสุดท้ายก็จะ บอกความจริงว่ามันด่วนหรือไม่ด่วนจริง
แชร์ประมาณนี้ สุดท้ายศิลปะการสื่อสาร, negotation, การสร้าง product vision/roadmap ที่สื่อสาร, มี process ที่โปร่งใส เป็นต้น จะเป็นสิ่งที่ช่วยเรื่องเหล่านี้ time-to-time…
การเป็น PO/PM ถ้าสื่อสาร หรือ soft-skills ไม่ดี สุดท้าย pains หนัก จึงเป็นทักษะที่จำเป็นอย่างยิ่งที่ทำให้คุณ “ปฏิเสธอย่างมีศิลปะ” (โดยเบื้องหลังศิลปะ ก็คือหลักการที่มีนั่นเอง)
#วันละเรื่องสองเรื่อง
