คุณค่าสำหรับผู้ใช้

การให้ความสำคัญกับสิ่งที่ลูกค้าหรือผู้ใช้ต้องการนั้นเป็นเรื่องสำคัญ

แต่มันต้องมีลิมิต

ลูกค้าหรือผู้ใช้ไม่ใช่คนที่สำคัญที่สุดที่เราต้องเอาใจหรือทำให้แฮปปี้เสมอไป

การทำตามที่พวกเขาพูดหรือสั่งเป็นเรื่องอันตราย อันตรายอย่างยิ่ง

ความแพร่หลายและคุ้นเคยของแนวทางแบบนี้ …​ เราต้องคิดใหม่ทำใหม่กันมั้ย?

“ในฐานะผู้ใช้ ฉันต้องการส่งอีเมล์” … อะไรๆที่ขึ้นต้นด้วย As a user, I want to …

คำถามคือ “ฉันต้องการ …” — ฉันนี่คือใคร? ใครเป็นคนกำหนดความต้องการข้อนี้

ลูกค้ากับผู้ใช้ …​ หรือเราในฐานะคนที่กำลังสร้างโปรดักท์เพื่อแก้ปัญหาให้พวกเขา

คำถามคือ “ส่งอีเมล์ …” — จริงหรือ ทางแก้ด้วยการส่งอีเมล์นี้ใครเป็นคนคิด

ลูกค้ากับผู้ใช้ …​ หรือเราในฐานะคนที่มองเห็นและเข้าใจเทคโนโลยีและมีความเชี่ยวชาญเรื่องนี้มากกว่า

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

โปรดักท์ เมเนเจอร์มักมองว่าตัวเองเป็นกระบอกเสียงของลูกค้า

“ลูกค้าอยากได้แบบนี้นะ ต้องทำก่อน” — คุ้นๆมั้ย?

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

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

อย่าให้ลูกค้าหรือผู้ใช้มาเป็นเจ้านายของเรา

อย่าเริ่มต้นด้วยการกำหนดความต้องการ ให้กำหนดปัญหา … แบบนี้

“ฉันในฐานะลูกค้า ฉันไม่สามารถคำนวณค่าแรงของพนักงานได้ภายใน 2 นาที”

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

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

เมื่อปัญหามา เมื่อเริ่มมองเห็นแล้วว่าทางแก้ควรจะเป็นอย่างไรในเวอร์ชั่นแรก สิ่งที่เราต้องทำคือการตั้งคำถามว่า

“เราต้องทำหรือแก้ไขอะไรในโปรดักท์ของเราบ้างเพื่อจะแก้ปัญหานี้ให้ลูกค้าได้”

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

หยุดการท่องคาถาแบบมักง่ายที่ว่า “ลูกค้าอยากได้แบบนี้นะ” ได้แล้ว