เมื่อฟีเจอร์ที่เรารักกลายเป็นฟีเจอร์ที่ลูกค้าไม่แคร์

When a Feature We Love Becomes Difficult: Managing Features in Tech Systems

อ่านหัวข้อวันนี้แล้วอย่าเพิ่งเศร้ากัน ที่อยากคุยเรื่อง เมื่อฟีเจอร์ที่เรารักกลายเป็นเรื่องยาก เกิดจากเมื่อสัปดาห์ที่ผ่านมา ทาง CPO ของ PRIMO คุณพอล ภาวินท์ เพิ่งไปงานติดกันสองงาน —ทั้งงาน IRIS Practical Digital Design CoP  

และงาน Product Owner Meetup  จัดโดย Thailand Startup Association 
ทั้งสองงานมี panel และผู้ร่วมงานที่พูดถึงประเด็น คนซื้อไม่ได้ใช้ คนใช้ไม่ได้อยากใช้ 

ในฐานะคนทำฝั่ง tech ฟังแล้วโดนใจมาก เพราะเจอบ่อยว่า business ขอฟีเจอร์มาเยอะ เราก็พัฒนาตาม requirement ครบถ้วน แต่พอ launch ออกไป ลูกค้าใช้จริงๆ แค่ 20% ส่วนอีก 80% แทบไม่ถูกแตะ

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

1. Law of the Vital Few (Pareto Principle) 

โดยธรรมชาติ ผู้ใช้จะโฟกัสกับ 20% ของฟีเจอร์ที่ตอบ pain point หลักของเค้า ที่เหลือจะถูกมองเป็น “ของเสริม” แม้จะลงทุนทำเท่าไหร่ก็ตาม

2. Cognitive Load Limitation

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

3. Lack of Problem–Solution Fit

หลายฟีเจอร์เกิดจาก idea หรือแรงกดดันจากตลาด มากกว่าการ validate กับผู้ใช้จริง ทำให้สิ่งที่พัฒนามาแก้ “ปัญหาที่ไม่มีอยู่จริง”

4. Onboarding & Discoverability Issue

ฟีเจอร์อาจดีมาก แต่ถ้าผู้ใช้ไม่รู้ว่ามีอยู่ หรือไม่เข้าใจวิธีใช้ สุดท้าย Feature นั้นก็ตายไปในที่สุด

5. Behavioral Inertia

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

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

เมื่อฟีเจอร์ที่เรารักกลายเป็นเรื่องยาก: แนวทางแก้ไข

ดังนั้น เพื่อให้ลดการทำออกไปแล้วไม่มีคนใช้โดยที่ไม่เหนื่อยมาก 

  • Prioritize ด้วยหลัก impact/effort แทนการทำครบทุก request
  • Validate กับ business และผู้ใช้งานอย่างสม่ำเสมอว่ายังมี needs อยู่ และความต้องการจริงๆ คืออะไร
  • วาง onboarding flow ให้ผู้ใช้เจอและเข้าใจฟีเจอร์ใหม่เมื่อที่ต้องใช้

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

เพราะสุดท้ายยังไง “ระบบที่ใช้งานได้จริง” ก็ดีกว่า “ระบบที่ใช้ Technology ทันสมัย Design สวยงาม แต่ไม่มีคนใช้”

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

แต่ถ้าอยากทำ Product ให้ดีต้องเข้าใจผู้บริโภคอย่างแท้จริง >> อ่านเพิ่มเติม