กับดัก Scope Creep: วิธีปฏิเสธฟีเจอร์ที่ฟังดูดีแต่จริงๆ แล้วไม่ดี

คุณสร้างอะไรบางอย่างที่ผู้ใช้รัก ตอนนี้พวกเขาอยากได้ฟีเจอร์ที่ฟังดูสมเหตุสมผล แต่จะพาแอปไปสิบทิศทาง นี่คือวิธีตัดสินใจว่าคำขอไหนควรสร้าง และคำขอไหนควรปฏิเสธอย่างสุภาพ

คุณปล่อยแอปออกไป ผู้ใช้เข้ามา และตอนนี้กล่องข้อความของคุณก็เต็มไปด้วยคำขอฟีเจอร์ที่ฟังดูเป็นไอเดียดีๆ ไปหมด

“เพิ่มการ export เป็น Excel ได้ไหม?” สมเหตุสมผล “ส่งใบแจ้งหนี้อัตโนมัติได้ไหม?” ก็เข้าท่า “เชื่อมกับ Stripe ได้ไหม?” นั่นแหละที่เงินจริงอยู่ “เพิ่มแอปมือถือได้ไหม?” ใครๆ ก็ขอ “ทำเป็น white-label ให้ลูกค้าของเราเองได้ไหม?” โอ้ ทีนี้มีโมเดลธุรกิจแล้ว

แต่ละคำขอฟังดูฉลาดเมื่อพิจารณาทีละอัน แต่พอรวมกันแล้ว มันฟังดูเหมือนคุณกำลังสร้างผลิตภัณฑ์ห้าตัวที่ต่างกัน

นี่คือ scope creep และมันฆ่าแอปเล็กๆ ที่สร้างด้วย AI มากกว่าปัญหาทางเทคนิคจะทำได้เสียอีก ไม่ใช่เพราะคุณสร้างฟีเจอร์เหล่านั้น — แต่เพราะคุณหมดเวลา หมดเงิน หรือหมดสติพยายามจะสร้างมัน

scope creep ฆ่าแอปที่ใช้งานได้ดีอย่างไร

นี่คือสิ่งที่เกิดขึ้น คุณตอบตกลงสามคำขอแรกเพราะมันดูสมเหตุสมผล คุณขอให้ AI builder ของคุณเพิ่มมันเข้าไป มันใช้เวลาสองสัปดาห์แทนที่จะเป็นหนึ่ง เพราะแต่ละฟีเจอร์ใหม่ไปชนกับโค้ดที่มีอยู่เดิม ตอนนี้คุณมีแอปที่ทำได้ห้าอย่าง ทำได้ดีสามอย่าง และทำได้พอใช้อีกสองอย่าง

แล้วคำขอที่สี่ก็มาถึง: “มีระดับสิทธิ์ที่ต่างกันได้ไหม?” จู่ๆ คุณก็ต้องคิดใหม่ว่าใครเห็นอะไรได้บ้างในทุกหน้าจอ นั่นไม่ใช่ฟีเจอร์ แต่เป็นการเปลี่ยนสถาปัตยกรรม คุณขอให้ AI builder ของคุณทำ มันไปแตะทุกอย่าง สองสัปดาห์กลายเป็นสาม แอปช้าลงเพราะคุณเพิ่มตรรกะเข้าไปในทุกมุมมอง

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

คุณสร้างอะไรที่ใช้งานได้ดี แล้วทำมันพังเพราะพยายามจะเป็นทุกอย่าง

กรอบการตัดสินใจ

คุณต้องมีด่านกั้น ทุกคำขอฟีเจอร์ต้องผ่านสามคำถามนี้:

คำถามที่ 1: สิ่งนี้ควรอยู่ในแอปนี้ หรือว่ามันเป็นอีกแอปหนึ่ง?

แอปแรกของคุณทำงานหนึ่งอย่างได้ดีเยี่ยม แอปจัดตารางก็จัดตาราง แอปทำใบแจ้งหนี้ก็ทำใบแจ้งหนี้ มันเป็นคนละแอปกัน ถ้ามีคนขอให้แอปจัดตารางของคุณออกใบแจ้งหนี้ คุณไม่ได้กำลังเพิ่มฟีเจอร์ — คุณกำลังขอให้แอปจัดตารางทำงานบัญชี นั่นคือผลิตภัณฑ์คนละตัว

ทดสอบดูง่ายๆ: “ถ้าฉันเอาฟีเจอร์นี้ไปปล่อยขายแบบเดี่ยวๆ คนจะอยากซื้อไหม?” ถ้าใช่ มันก็คงควรอยู่ในแอปอื่น ถ้าคำตอบคือ “ไม่ มันมีความหมายก็ต่อเมื่อเป็นส่วนหนึ่งของสิ่งที่ใหญ่กว่า” คุณก็กำลังสร้างในขอบเขตที่ถูกต้องแล้ว

คุณจะได้คำขอแบบ “เชื่อมกับ CRM ของเรา” ซึ่งจริงๆ แล้วมันหมายความว่า “เป็น CRM ของตัวเองซะ” นั่นคืออีกแอปหนึ่ง คุณเชื่อมต่อกับ CRM ทีหลังได้ แต่คุณเพิ่มฟีเจอร์เท่ากับ CRM ทั้งตัวเข้ามาไม่ได้ โดยไม่กลายเป็น CRM เสียเอง

คำถามที่ 2: สิ่งนี้แก้ปัญหาให้ผู้ใช้ส่วนใหญ่ของคุณ หรือแค่คนคนเดียวนี้?

ลูกค้าคนหนึ่งรักแอปของคุณและมีไอเดียฟีเจอร์ มันคือปัญหาจริงที่เขามี และมันก็เป็นปัญหาจริงที่มีแค่เขาคนเดียว

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

นี่คือคำถามที่อันตราย เพราะลูกค้าคนเดียวที่ขอนั้นอาจเป็นลูกค้าที่สำคัญที่สุดของคุณก็ได้ คุณอาจจำเป็นต้องทำให้เขาพอใจ นั่นคือการตัดสินใจทางธุรกิจ ไม่ใช่การตัดสินใจเรื่องผลิตภัณฑ์ แต่จงเข้าไปแบบตาสว่าง: ถ้าคุณสร้างอะไรให้ลูกค้าคนเดียว คุณไม่ได้กำลังขยายแอปของคุณ แต่คุณกำลังสร้างธุรกิจรับให้คำปรึกษา

คำถามที่ 3: สิ่งนี้มีต้นทุนเท่าไหร่ และมีต้นทุนอะไรต่อไอเดียดั้งเดิม?

ทุกอย่างมีต้นทุน การ export เป็น Excel มีต้นทุนเป็นเวลางานวิศวกรรมของคุณ มีต้นทุนเป็นความซับซ้อนของแอป มีต้นทุนเป็นโฟกัส สร้างมันแทนที่จะปรับปรุงประสิทธิภาพที่ผู้ใช้ของคุณบ่นทุกวัน คุณก็ได้เลือกแล้ว

ถามให้เป็นรูปธรรม: “ถ้าฉันสร้างสิ่งนี้ ฉันจะ ไม่ ได้สร้างอะไร?” ถ้าคำตอบคือ “ไม่มี เรามีเวลาไม่จำกัด” คุณก็ไม่ได้กำลังซื่อสัตย์ เราไม่มี เวลามันจำกัด

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

ตัวอย่างจริง: ฟอร์มรับข้อมูล

มีคนสร้างฟอร์มรับข้อมูลลูกค้าง่ายๆ ขึ้นมา ลูกค้ากรอกฟอร์ม โค้ชตรวจดู แล้วนัดเวลากัน นั่นแหละคือแอป

คำขอที่หนึ่ง: “ทำเครื่องหมายฟอร์มที่เร่งด่วนได้ไหม?” ได้ นั่นเป็นรูปแบบหนึ่งของเวิร์กโฟลว์หลัก สร้างเลย

คำขอที่สอง: “export ฟอร์มเป็น Excel ไว้เก็บเป็นบันทึกของฉันได้ไหม?” นี่เป็นฟีเจอร์เกี่ยวกับเอกสาร มันไม่ใช่หน้าที่ของแอป ข้อมูลฟอร์มอยู่ในแอป ถ้าเขาต้องการ Excel ก็ copy-paste เอาได้ แต่ก็โอเค การ export อาจสมเหตุสมผลในฐานะความสะดวก สร้างเลย

คำขอที่สาม: “ให้ฟอร์มสร้างกิจกรรมในปฏิทินอัตโนมัติได้ไหม?” ทีนี้คุณกำลังทำเรื่องจัดตารางแล้ว แอปนี้สร้างมาเพื่อรับข้อมูล ไม่ใช่จัดตาราง ถ้าใครต้องการทั้งสองอย่าง เขาก็คงต้องการระบบจัดตารางจริงๆ ไม่ใช่การแฮ็กที่เอามาแปะติด ปฏิเสธอย่างสุภาพ

คำขอที่สี่: “ให้โค้ชส่งการติดตามผลฟอร์มทาง SMS ได้ไหม?” ทีนี้คุณกลายเป็นระบบสื่อสารแล้ว ไม่

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

วิธีปฏิเสธ

ส่วนที่ยากที่สุดคือการพูดมันออกมาจริงๆ คุณไม่อยากทำให้ผู้ใช้ของคุณหงุดหงิด

จงซื่อสัตย์: “เป็นไอเดียที่เยี่ยมมากเลย แต่มันเป็นผลิตภัณฑ์คนละตัวกับที่เรากำลังสร้างอยู่ตรงนี้ สิ่งที่เรากำลังสร้างคือ [งานหนึ่งอย่างของคุณ] ถ้าเราพยายามทำทั้งเรื่องจัดตาราง ทำใบแจ้งหนี้ หรือเรื่อง CRM เราก็จะทำได้แค่พอใช้กับทุกอย่าง และไม่เก่งสักอย่างเลย”

บ่อยครั้งลูกค้าจะเข้าใจ พวกเขาถามเพราะไอเดียผุดขึ้นมาในหัว ไม่ใช่เพราะกำลังทดสอบคุณ

บางครั้งพวกเขาก็จะโต้กลับ “แต่ฉันต้องการทั้งสองอย่าง” นั่นคือตอนที่คุณแนะนำ: ใช้แอปจัดตารางตัวจริง ใช้แอปทำใบแจ้งหนี้ตัวจริง ใช้ CRM ตัวจริง แล้วใช้แอปนี้สำหรับสิ่งที่มันทำได้ดี นั่นคือคำตอบที่ซื่อสัตย์

สิ่งล่อใจให้เป็นทุกอย่าง

ส่วนที่ยากที่สุดของการสร้างผลิตภัณฑ์เล็กๆ คือการปฏิเสธ การปฏิเสธรู้สึกเหมือนกำลังทิ้งเงินไว้บนโต๊ะ แล้วถ้าลูกค้าคนนั้นยอมจ่ายเพื่อทั้งสองอย่างจริงๆ ล่ะ? แล้วถ้าฟีเจอร์นั้นทำให้คุณใหญ่ขึ้นสิบเท่าล่ะ?

ก็อาจจะ แต่คุณไม่ได้เป็นผลิตภัณฑ์ที่ใหญ่ขึ้นสิบเท่าถ้าคุณไม่ปล่อยมันออกมา คุณเป็นผลิตภัณฑ์ที่ทำเสร็จครึ่งๆ กลางๆ ที่ทำได้ห้าอย่างแบบแย่ๆ คนที่รักแกนหลักก็หงุดหงิด คนที่อยากได้ฟีเจอร์ใหม่ก็หงุดหงิด และคุณก็ต้อนตัวเองเข้ามุมจนถึงจุดที่การเพิ่มอะไรใหม่หมายถึงต้องไปรื้อของเก่าห้าอย่างก่อน

ผลิตภัณฑ์ที่เติบโตคือผลิตภัณฑ์ที่ทำงานหนึ่งอย่าง ได้ดีจริงๆ แล้วค่อยเพิ่มอย่างระมัดระวัง พวกเขาไม่ได้พยายามเป็น Salesforce ตั้งแต่วันแรก พวกเขาคือแอปที่คุณคว้ามาใช้เมื่อต้องการทำสิ่งนั้นสิ่งหนึ่ง และเป็นแอปที่คุณวางใจว่าจะเร็วและเชื่อถือได้เมื่อคุณใช้มัน

จงปฏิเสธ ปกป้องแกนหลัก ทำแบบนั้น แล้วคุณจะสร้างอะไรบางอย่างที่ผู้คนอยากใช้จริงๆ