Standish Group ศึกษาโปรเจกต์ซอฟต์แวร์ที่เสร็จสมบูรณ์จำนวนหนึ่ง และรายงานตัวเลขที่ยังทำให้เจ้าของผลิตภัณฑ์สะดุ้ง นั่นคือ 64% ของฟีเจอร์ทั้งหมดแทบไม่เคยหรือไม่เคยถูกใช้เลย เมื่อแยกย่อย: 45% ไม่เคยถูกแตะเลย, 19% ถูกใช้น้อยมาก และมีเพียง 17% เท่านั้นที่ถูกใช้เป็นประจำ พูดอีกอย่างคือ ราวสองในสามของทุกสิ่งที่ทีมทั่วไปสร้างขึ้น ในมุมมองของผู้ใช้แล้ว เป็นเพียงของประดับ
ข้อค้นพบนี้ (นำเสนอครั้งแรกโดย Jim Johnson ประธาน Standish ในงานประชุม XP 2002) มีอายุกว่าสองทศวรรษแล้ว และสิ่งที่ทำให้อึดอัดคือ ข้อมูลใหม่ ๆ ก็ยืนยันตรงกัน ความสูญเปล่านี้ไม่ใช่ความผิดพลาดของทีมใดทีมหนึ่ง แต่มันคือผลลัพธ์ตามปกติของการสร้างเยอะ ก่อนที่จะได้เรียนรู้อะไรเลย
สิ่งที่คุณสร้างส่วนใหญ่จะไม่มีวันถูกใช้
การวิเคราะห์ข้อมูลสมัยใหม่เล่าเรื่องเดียวกันด้วยตัวอย่างที่ใหญ่ขึ้น แพลตฟอร์มผลิตภัณฑ์ Pendo ซึ่งดูข้อมูลการใช้งานแบบไม่ระบุตัวตนจากแอปพลิเคชันหลายร้อยตัว พบว่าราว 80% ของฟีเจอร์แทบไม่เคยหรือไม่เคยถูกใช้ และราว 12% ของฟีเจอร์ขับเคลื่อนการใช้งานประจำวันถึง 80% พวกเขายังตีราคาความสูญเปล่านี้ด้วยว่า บริษัทคลาวด์มหาชนใช้จ่ายราว 29,500 ล้านดอลลาร์ต่อปีไปกับฟีเจอร์ที่ลูกค้าแทบไม่แตะ
ให้มองว่านี่คือข้อจำกัดในการวางแผน ไม่ใช่ความล้มเหลวทางศีลธรรม ก่อนเปิดตัว ไม่มีใคร (รวมถึงตัวคุณเอง) รู้แน่ชัดว่าฟีเจอร์ 17% ไหนจะสำคัญ คุณกำลังเดา คำถามคือคุณจะใช้เวลาสิบสองเดือนทำตามการเดานั้น หรือสิบสองสัปดาห์เพื่อทดสอบมัน
ต้นทุนของการสร้างสิ่งที่ไม่มีใครต้องการ
ข้อมูลเรื่องฟีเจอร์เป็นเรื่องความสูญเปล่าภายในผลิตภัณฑ์ที่อย่างน้อยก็หาตลาดเจอแล้ว แต่ตัวเลขที่โหดร้ายกว่าคือเรื่องผลิตภัณฑ์ที่หาตลาดไม่เจอ ในงานวิเคราะห์บทเรียนจากสตาร์ทอัพที่ล้มเหลวของ CB Insights เหตุผลที่พบบ่อยที่สุดคือ การสร้างสิ่งที่ไม่มีใครต้องการ โดย 42% ของสตาร์ทอัพที่ล้มเหลวระบุว่า "ตลาดไม่มีความต้องการ"
นี่คือเหตุผลทั้งหมดของ MVP สรุปในสถิติเดียว ความเสี่ยงที่ใหญ่ที่สุดของผลิตภัณฑ์ใหม่แทบไม่เคยเป็น "เราสร้างมันได้ไหม?" แต่เป็น "มีใครต้องการมันไหม?" ทุกฟีเจอร์ที่คุณปล่อยเพิ่มก่อนตอบคำถามที่สองนี้ ยิ่งทวีคูณต้นทุนของการคิดผิด โดยไม่ได้เพิ่มโอกาสที่จะคิดถูกเลย
วิธีตัดสินใจระหว่าง must-have กับ nice-to-have
คนมักเข้าใจ "MVP" ผิดว่าเป็น "ของถูกที่ทำเสร็จครึ่งเดียว" ซึ่งไม่ใช่ทั้งสองอย่าง MVP ที่แท้จริงคือสิ่งที่เล็กที่สุดที่ส่งมอบคุณค่าหลักได้ และทำให้คุณเรียนรู้จากผู้ใช้จริง วินัยอยู่ที่การตัดทิ้ง คำถามไม่กี่ข้อที่ช่วยตัดให้คุณ:
- มันตอบโจทย์หลักหนึ่งเดียวหรือไม่? ระบุงานหนึ่งเดียวที่ผู้ใช้จ้างผลิตภัณฑ์ของคุณให้ทำ ถ้าฟีเจอร์ไม่ได้สนับสนุนงานนั้นโดยตรง มันคือสิ่งที่ควรตัด ไม่ใช่สิ่งที่ควรสร้าง
- ถ้าไม่มีมัน จะเปิดตัวไม่ได้หรือไม่? ถ้าคำตอบคือไม่ มันคือ nice-to-have ซึ่งไม่ใช่ไอเดียที่แย่ แต่เป็นไอเดียดีที่ยังไม่มีหลักฐานยืนยัน
- มันสอนอะไรคุณ? เลือกสิ่งที่ให้สัญญาณชัดเจน (คนใช้มันไหม? เขายอมจ่ายไหม?) มากกว่าสิ่งที่แค่เพิ่มผลิตภัณฑ์ให้ใหญ่ขึ้น
- มันรอคำขอจริงได้หรือไม่? ฟีเจอร์ "จำเป็น" หลายตัวรอดมาได้เพราะไม่เคยมีผู้ใช้คนไหนขอให้มันพิสูจน์ตัวเอง ปล่อยให้ตลาดดึงฟีเจอร์ออกมาจากคุณ
ตัดให้เด็ดขาด ปล่อยแกนหลักออกไป แล้วให้ข้อมูลการใช้งานจริง ไม่ใช่ความเห็นในห้องประชุม เป็นตัวบอกว่าควรสร้างอะไรต่อไป
มุมมองของเราที่ True Dev
เราสร้างซอฟต์แวร์มาตั้งแต่ปี 1997 และสิ่งที่มีค่าที่สุดที่เราทำให้ลูกค้าบ่อยครั้งคือ การพูดให้เขาเลิกสร้างฟีเจอร์ที่ไม่จำเป็น เราคิดในเชิงผลิตภัณฑ์ ไม่ใช่แค่โค้ด นั่นหมายความว่าเราจะช่วยคุณหาโจทย์หลัก กำหนดขอบเขตการเปิดตัวที่คุณปล่อยได้จริง และออกแบบให้สัปดาห์แรก ๆ ของการใช้งานจริงสอนอะไรคุณบางอย่าง เป้าหมายไม่ใช่การเขียนซอฟต์แวร์ให้น้อยลงเพื่อความน้อย แต่คือการใช้งบของคุณไปกับ 17% ที่สำคัญจริง และค้นพบส่วนที่เหลือจากผู้ใช้ แทนที่จะเดาเอา
ถ้าคุณมีไอเดียผลิตภัณฑ์ ความผิดพลาดที่ถูกที่สุดคือสิ่งที่คุณจับได้ก่อนลงมือสร้าง เริ่มโปรเจกต์กับเรา แล้วเราจะช่วยคุณกำหนดขอบเขตการเปิดตัวที่เล็กที่สุดที่พิสูจน์ไอเดียได้ หรือดู บริการของเรา เพื่อดูวิธีการทำงานของเรา
