Product Discovery คืออะไร ทำไมทีม Product ไม่ควรเริ่มจาก Feature
ทำความเข้าใจ Product Discovery หรือการค้นหาโจทย์ผลิตภัณฑ์ ตั้งแต่การมองปัญหาของผู้ใช้ ตรวจสมมติฐาน ไปจนถึงการตัดสินใจว่าจะลงทุนทำอะไร
Product Discovery คือช่วงที่ทีม Product พยายามทำความเข้าใจว่าควรแก้ปัญหาใดให้ใคร และมีหลักฐานเพียงพอแค่ไหนก่อนลงทุนสร้างคำตอบ การเริ่มจาก Feature หรือฟังก์ชันที่อยากทำทันทีอาจทำให้ทีมส่งมอบงานได้เร็ว แต่ยังไม่แน่ใจว่ากำลังแก้ปัญหาที่สำคัญจริงหรือไม่
แยกคำขอ Feature ออกจากปัญหาที่อยู่ข้างใต้
Feature คือความสามารถหรือฟังก์ชันที่มีคนเสนอให้สร้าง ส่วนปัญหาคือสิ่งที่ผู้ใช้หรือธุรกิจกำลังติดขัด คำขอเดียวกันอาจเป็นคำตอบของหลายปัญหา และปัญหาเดียวกันอาจมีทางเลือกที่ไม่ต้องสร้าง Feature ใหม่เลย
ทีมจึงควรถามต่อว่าคำขอนี้เกิดในบริบทใด ใครกำลังเจออุปสรรค ผลกระทบเป็นอย่างไร และวันนี้เขาใช้วิธีใดแก้ปัญหาอยู่ การถามอย่างมีโครงสร้างช่วยให้ทีมไม่ปฏิเสธไอเดียเร็วเกินไปและไม่รับทุกคำขอมาเป็น roadmap โดยอัตโนมัติ
- ใครเจอปัญหาและเกิดขึ้นในขั้นตอนไหน
- ปัญหาส่งผลต่อเป้าหมายหรือประสบการณ์อย่างไร
- ทางแก้ที่ใช้อยู่มีข้อจำกัดอะไร
จัดกรอบโจทย์ให้ทีมมองเห็นผู้ใช้ร่วมกัน
การค้นหาโจทย์ที่ดีทำให้ Product, Design, Technology และฝ่ายธุรกิจเห็นภาพเดียวกันว่าใครคือผู้ได้รับผลกระทบ งานที่เขาพยายามทำคืออะไร และข้อจำกัดใดต้องเคารพ การมีกรอบร่วมช่วยลดการถกเถียงจากความชอบส่วนตัวและทำให้ทีมพูดถึงสมมติฐานที่ตรวจสอบได้
ไม่จำเป็นต้องสร้างเอกสารยาวตั้งแต่ต้น ใช้แผนผังโอกาส ตารางสมมติฐาน หรือสรุปบทสนทนากับผู้ใช้ขนาดเล็กก็ได้ ตารางสมมติฐานควรแยกสิ่งที่รู้ สิ่งที่เชื่อ และวิธีตรวจสอบออกจากกัน ขอเพียงทำให้รู้ว่าข้อสรุปมาจากหลักฐานใดและยังมีสิ่งใดที่ไม่รู้
- ผู้ใช้และงานที่ต้องทำถูกระบุชัด
- สมมติฐานแยกจากข้อเท็จจริง
- ทีมเห็นข้อจำกัดและคำถามที่ต้องหาคำตอบต่อ
ทดสอบความเสี่ยงก่อนลงทุนเต็มรูปแบบ
ก่อนสร้างผลิตภัณฑ์เต็มชุด ทีมอาจทดสอบความเสี่ยงหลายด้าน เช่น ผู้ใช้มีปัญหานี้จริงหรือไม่ แนวคิดนี้ช่วยแก้ได้หรือไม่ และองค์กรสามารถส่งมอบหรือดูแลคำตอบนี้ได้หรือไม่ วิธีทดสอบอาจเป็น prototype, การทดลองแบบ manual, การทบทวนข้อมูล หรือการสนทนาที่ออกแบบคำถามอย่างระมัดระวัง
เป้าหมายของการทดลองไม่ใช่พิสูจน์ว่าไอเดียที่ชอบถูกต้อง แต่คือการเรียนรู้ให้เร็วพอที่จะตัดสินใจว่าจะเดินหน้า ปรับกรอบโจทย์ หรือหยุดลงทุน การกำหนดเกณฑ์ก่อนทดลองช่วยลดการเลือกหลักฐานเฉพาะที่สนับสนุนความเชื่อเดิม
- ความเสี่ยงใดถ้าผิดแล้วต้นทุนสูง
- การทดลองแบบเล็กที่สุดที่ให้ข้อมูลได้คืออะไร
- เกณฑ์ใดบอกว่าควรเดินหน้า ปรับ หรือหยุด
เชื่อม Discovery กับการส่งมอบงาน
Product Discovery ไม่ใช่ช่วงที่แยกขาดจากการพัฒนา แต่เป็นวงจรที่ช่วยให้ทีมตัดสินใจเรื่องลำดับความสำคัญและขอบเขตการส่งมอบได้ดีขึ้น เมื่อมีหลักฐานเพียงพอ ทีมควรแปลงโจทย์เป็นชิ้นงานที่เล็กพอจะเรียนรู้และส่งมอบได้ พร้อมระบุสิ่งที่ยังต้องตรวจต่อ
การทบทวนหลังส่งมอบก็เป็นส่วนหนึ่งของการค้นหาโจทย์เช่นกัน เพราะข้อมูลจากการใช้งานจริงอาจทำให้ทีมเห็นปัญหาใหม่หรือพบว่าสมมติฐานเดิมไม่ครบ การทำให้ Discovery และ Delivery เชื่อมกันช่วยให้ roadmap เป็นเครื่องมือเรียนรู้ ไม่ใช่เพียงรายการ Feature ที่ล็อกไว้ล่วงหน้า
- ชิ้นงานส่งมอบเชื่อมกับสมมติฐานใด
- ทีมจะเรียนรู้อะไรจากการปล่อยแต่ละช่วง
- ข้อมูลหลังส่งมอบจะย้อนกลับมาปรับทิศทางอย่างไร
บทความนี้ให้กรอบคิดทั่วไป การออกแบบโปรแกรมจริงควรพิจารณาบริบท นโยบายข้อมูล และผู้มีส่วนได้ส่วนเสียขององค์กร