< Back to insights
ทำ Product ใหม่ อย่าใช้คนเยอะ
Orange Cap Innovative
Noppon A.
Dec 21 2021
5 min read
Orange Cap Innovative
ทำ Product ใหม่ อย่าใช้คนเยอะ
เคยเจอไหม เวลาจะพัฒนา Product ใหม่ ๆ ต้องเข้าประชุมกับฝ่ายต่าง ๆ ไม่รู้ตั้งกี่ฝ่าย มีคนมาร่วมประชุมกันเต็มไปหมด บางทีแค่ประชุม ก็หมดเวลาทำงานแล้ว
สัญญาณแบบนี้ ถือเป็นจุดเริ่มต้นที่ไม่ค่อยดีสักเท่าไรในการพัฒนา Product ใหม่ ๆ
มากคน มากความ ถ้าเราลองย้อนมองดู Success Story ของ Product จาก Startup ต่าง ๆ เราจะพบว่าจุดเริ่มต้นของการพัฒนา Product ใหม่นั้น เกิดจากคนไม่กี่คน ซึ่งเป็นกลุ่มคนที่จำเป็นเท่านั้น ได้แก่ Sales & Marketing, Technology, Design สิ่งที่พูดคุยกันจะอยู่ในประเด็นไม่กี่เรื่องในมุมมองของแต่ละคนเท่านั้น ใช้เวลาในการประชุมไม่มาก
ดังนั้น เมื่อคนร่วมประชุมมาก ความคิดเห็นก็จะมากตามไปด้วย ยิ่งไปกว่านั้นความคิดเห็นอาจจะกระจัดกระจาย ไปตามวิธีการมองภาพที่แตกต่างกันของคนจากแต่ละแผนก เช่น แผนกกฎหมาย จะมีจินตนาการถึงแต่ในแง่มุมของกฎหมาย แผนกบัญชี มีจินตนาการในแง่มุมของการบันทึกบัญชี ทำให้ Product Manager ต้องคอยบริหารจัดการ Requirement และทำความเข้าใจกันเหนื่อยเลยทีเดียว
ความเกรงใจเป็นสมบัติของผู้ดี เมื่อต้องประชุมกับหลายแผนก เจอกับหลากหลายความคิดเห็น ความกังวล คำแนะนำ บางอันดีก็ต้องรับฟัง แต่บางอันอาจจะเกินขอบเขตไปหน่อย ก็ต้องมาหาทางปฏิเสธหรืออธิบายกันอีกยกใหญ่ จะปฏิเสธตรง ๆ ก็ลำบากใจ กลายเป็นไม่รับฟังข้อคิดเห็นไปเสียอย่างนั้น
ยากขึ้นไปอีกหน่อย เมื่อเจอกับคำว่า “ผู้ใหญ่เป็นห่วง” “ผู้ใหญ่ไม่เห็นด้วยกับ Feature นี้” "ผู้ใหญ่ขอมาให้มี Feature นี้ด้วย” (แม้จะไม่เกี่ยวข้องโดยตรงกับ Product นั้น ๆ ) หรือถ้าผู้ใหญ่อยู่ในที่ประชุมด้วย แบบนี้ก็ยิ่งลำบากขึ้นไปอีก ต้องทั้งรับฟัง หาทางอธิบายให้เข้าใจ เพราะถ้าผ่านด่านนี้ไปไม่ได้ Product Manager ที่อาวุโสน้อยกว่าก็คงต้องเกรงใจผู้ใหญ่และถอยให้ในที่สุด
ความเสี่ยงของเรา ไม่เท่ากัน สัจธรรมของการพัฒนา Product ใหม่ๆ คือ ความเสี่ยงเป็นสิ่งแน่นอน เช่น ความเสี่ยงที่จะไม่มีคนใช้งาน ความเสี่ยงที่จะขาดทุน ความเสี่ยงต่อการได้รับผลตอบรับที่ไม่ดี เป็นต้น นี่เป็นสิ่งที่ Product Manager มักจะคุ้นชินและเตรียมแนวทางรับความเสี่ยงไว้แล้ว แต่ก็นั่นล่ะฮะคุณผู้ชม การประเมินความเสี่ยงนั้นใช้จินตนาการ ทั้งในแง่ของ Case ที่จะเกิดขึ้นและ Impact ของ Case นั้น ๆ ขึ้นอยู่กับมุมมองของแต่ละฝ่าย
Product Manager บางคน อาจจะตั้งท่าเตรียมตัวมาอย่างดี มีข้อมูลสนับสนุนเต็มที่ พร้อมกับ User Feedback ที่เข้มข้น ยังไงก็ต้องผ่านแน่นอน แต่สุดท้ายต้องมาเจอกับคำว่า เรารับความเสี่ยงไม่ไหวหรอก ถ้ามันบานปลาย แล้วคุณจะทำอย่างไร คุณรับผิดชอบไหวเหรอ พอเจอกับสิ่งเหล่านี้ ถ้าใจไม่แข็งพอ ก็ต้องถอยเหมือนกัน
กว่าถั่วจะสุก งาก็ไหม้ การพัฒนา Product ในช่วงแรกนั้น มักมี Dynamic สูงมาก คือเปลี่ยนแปลง ปรับเปลี่ยน ล้มแผน ร่างใหม่ อย่างรวดเร็ว และนั่นคือสิ่งที่ Product Manager จะต้องตอบสนองและตัดสินใจอยู่เสมอ เช่น ลองพัฒนา Feature นี้ แล้วพบว่า ผู้ใช้งาน (User) ไม่ชอบ ก็ต้องมาตัดสินใจว่า จะเอาไว้หรือพัฒนาต่อ เป็นต้น
แต่พอหลากหลายฝ่ายเข้ามาเกี่ยวข้อง ก็ต้องคอยอัพเดทรายงานให้ครบถ้วน ก็ต้องคอยมานั่งทำ Presentation เพื่อสื่อสารให้กับแต่ละฝ่ายเข้าใจตรงกัน มิหนำซ้ำ บางทีอาจต้องอัพเดทจากความคิดเห็นของครั้งก่อนหน้าอีก พออัพเดทเสร็จ ก็มีการเปลี่ยน Feature อีกแล้วในสัปดาห์ถัดไป ยังไม่ทันไรเลย ทำ Presentation อีกแล้ว
ต้องบอกว่า ปัญหารูปแบบนี้ มักเกิดกับองค์กรขนาดใหญ่ ที่มีโครงสร้างองค์กรที่ซับซ้อน ซึ่งถูกออกแบบมาเพื่อให้แต่ละฝ่าย ทำงานในเรื่องนั้น ๆ เรื่องเดียว เช่น ฝ่ายกฎหมาย ก็เน้นเรื่องการรีวิวสัญญา การประเมินข้อกฎหมายต่าง ๆ เป็นต้น ในขณะที่การพัฒนา Product ใหม่ ๆ นั้น เป็นการทำเรื่องเล็ก ๆ หลาย ๆ เรื่องไปพร้อม ๆ กัน จึงทำให้แว่นในการมองของคนที่มาเข้าร่วมเป็นคนละเรื่องเดียวกัน
ปัญหาที่เกิดขึ้นทั้งหมดนี้ ทำให้ Product Manager หรือทีมพัฒนา ไม่ได้โฟกัสในสิ่งที่สำคัญที่สุด นั่นคือ User (ผู้ใช้งาน) แทนที่จะใช้เวลาส่วนใหญ่ไปกับการทำงานกับ User กลับต้องใช้เวลาในการสื่อสารกับฝ่ายต่าง ๆ หรือ แทนที่จะยึดความคิดเห็นของ User เป็นหลักในการพัฒนา กลับต้องคอยประนีประนอมกันบนโต๊ะประชุม ซึ่งไม่ใช่ผู้ใช้งานที่แท้จริง กลายเป็นลงเอยที่การพัฒนา Product เพื่อตอบสนองความสบายใจของคนในองค์กรแทน
สำหรับแนวทางที่จะหลีกเลี่ยงเรื่องเหล่านี้มีหลายวิธี แล้วจะมาแชร์ต่อในบทความถัดไปครับ