✍🏼 เลือกทำฟีเจอร์ไหนดีกับโปรดักท์เวอร์ชั่นแรก?

มีคำถามที่น่าสนใจจากโปรดักท์ เมเนเจอร์น้องใหม่คนนึงมาฝากครับ

“เราควรมีหลักการในการคิดฟีเจอร์และจัดลำดับความสำคัญของมันยังไงอะครับ?”

ขออนุญาตแนะนำให้รู้จัก Kano Model ครับ

Kano Model ซึ่งถูกพัฒนาโดย Noriaki Kano นำเสนอหลักการการจัดแบ่งคุณสมบัติของสินค้าตามความสำคัญที่มีต่อลูกค้าและตามความพึงพอใจของลูกค้า Kano แบ่งกลุ่มของ Feature หรือ Requirement ออกเป็นสี่กลุ่มดังนี้

ยกตัวอย่างกรณีศึกษาจากการสร้างไอพอดรุ่นแรกเมื่อปี 2001 นะครับ (เก่ามากกกก)

🤩 1. ว้าว (Surprise and Delight)

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

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

🏋🏻‍♀️ 2. ยิ่งมากยิ่งดี (More Is Better)

ฟีเจอร์ในกลุ่มนี้โดยมากแล้วจะเป็นอะไรที่เกี่ยวกับแนวคิดที่ว่า “ใหญ่กว่า เร็วกว่า แข็งแรงกว่า” แต่ความท้าทายในการเขียนสโคปของฟีเจอร์ในกลุ่มนี้ก็คือเราจะรู้ได้อย่างไรว่าเมื่อไรถึงจะพอ เช่น ใหญ่กว่า…แล้วต้องใหญ่แค่ไหน? เร็วกว่า…แล้วต้องเร็วแค่ไหน เป็นต้นครับ การใช้คำที่ว่า ลดลง (Minimize) หรือ เพิ่มขึ้น (Maximize) เป็นการเขียนที่กำกวมซึ่งยากต่อการเอาไปพัฒนาต่อได้ ตัวอย่างเช่น ถ้าเราเขียนว่าต้อง Minimize search time ของระบบ Search Engine แบบนี้ดีเวลลอปเปอร์จะรู้ได้อย่างไรว่า Minimum time ที่ต่ำที่สุดของระบบ Search Engine ควรเป็นเท่าไร?

เป็นเรื่องท้าทายที่จะเขียนคำอธิบายฟีเจอร์ให้ได้ชัดเจนเพราะว่าการระบุตัวเลขที่ชัดเจนก็เป็นเรื่องยากมากเช่นกัน ตรงนี้กฎของ Diminishing Returns ในทฤษฎีทางเศรษฐศาสตร์จะเข้ามาเกี่ยวข้อง พูดง่ายๆคือความแตกต่างที่ลดลงเรื่อยๆเมื่อปัจจัยใดปัจจัยหนึ่งเพิ่มขึ้นหรือลดลง ผมขอยกตัวอย่างเป็น Search Engine นะ ประโยชน์ที่ลูกค้าได้รับจากการที่ Search Time เป็น 0.21 วินาทีกับ 0.11 วินาทีแทบจะไม่แตกต่างกันเลย ในอีกมุมหนึ่งถ้าเราอยากให้ลูกค้าได้ประโยชน์จากสินค้ามากขึ้น มันก็ต้องแลกมาด้วยค่าใช้จ่ายที่เพิ่มขึ้นด้วย

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

👏🏼 3. ต้องมี (Must Be)

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

ตัวอย่างจากไอพอดสิ่งที่ “ต้องมี” ในก็น่าจะเป็นความบาง กระทัดรัด และการออกแบบที่ทันสมัยของมัน รวมถึงความง่ายในการใช้งานเมนูต่างๆ ซึ่งข้อนี้ได้ฟีดแบ็คตรงมาจากสตีฟ จ๊อบส์เลย (ใครจะกล้าขัด?) … จ๊อบส์บอกกับทีมพัฒนาว่า “ผมต้องการเข้าถึงเพลงที่อยากฟังได้ด้วยการกดไม่เกิน 3 ปุ่ม” ชัดเจน

🙅🏼‍♂️ 4. ไม่มีดีกว่า (Better Not Be)

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

ยกตัวอย่างจากไอพอดเหมือนเดิม ถ้าลูกค้าบอกว่า “ไม่ชอบเลยที่ MP3 Player มีเนื้อที่เก็บเพลงน้อย” นี่เป็นที่มาของฟีเจอร์ “ต้องมี” ที่ว่า “ไอพอดต้องเก็บเพลงได้เยอะๆ” หรือ ถ้าลูกค้าบอกว่า “ไม่ชอบ Navigation ที่ใช้งานยาก เข้าใจยาก” ก็เลยเป็นที่มาของ “ว้าว” ที่ว่า “ไอพอดต้องสร้างรูปแบบใหม่ของ Navigation ขึ้นมาให้ได้” ก็ Nav Wheel นั่นไง

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

👩🏻‍🔬 การประยุกต์ใช้

การพัฒนาสินค้าของเราโดยอาศัยหลักการ Minimum Viable Product หรือ MVP นั้น เราสามารถประยุกต์ใช้ Kano Model ได้ด้วยการตอบคำถามเหล่านี้ตามลำดับ

• เรามีอะไรที่เป็น “ว้าว” เพื่อสร้างความแตกต่างให้กับสินค้าของเราหรือยัง? ผมให้ความสำคัญกับข้อนี้มากเพราะฟีเจอร์กลุ่มนี้ทำมาด้วยความเชื่อที่ว่าลูกค้าจะร้องว้าวซึ่งในทางกลับกันมันก็จะมีความเสี่ยงที่ลูกค้าจะร้องแหวะมาด้วยเช่นกัน การคิดถึงงานกลุ่มนี้ก่อนจะทำให้เราสามารถพิสูจน์สมมติฐานของเราได้อย่างรวดเร็ว … ล้มเหลวอย่างด่วน (Fail Fast) ครับ
• ฟีเจอร์ของสินค้าเวอร์ชั่นแรกมีสิ่งที่เป็น “ต้องมี” ครบแล้วหรือไม่? ข้อถัดมาคือลองพิจารณาดูว่าเรามีฟีเจอร์ที่จำเป็นครบมั้ย ซึ่งถ้าไม่ครบก็ไม่เป็นไรนะ เพราะการทำงานแข่งกับเวลา (Time To Market) นั้นเราสามารถตัดฟีเจอร์ที่ยังไม่จำเป็นมากในช่วงแรกได้
• เมื่อเราระบุ “ยิ่งมากยิ่งดี” ข้อมูลเหล่านั้นมีความกำกวม หรือเป็นไปไม่ได้ในทางปฏิบัติหรือไม่? สุดท้ายถ้ามีเรื่องนี้เข้ามา พิจารณาให้หนักครับว่าการลงทุนจะได้ผลตอบแทนที่คุ้มค่ามั้ย

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