เรื่องของความ Minimum for MVP
KJ’s leadership series #4
วันก่อนเข้าประชุมแล้วจำได้ว่าเราคุยกันเรื่อง “Minimum” คืออะไรในมุมของ MVP มันคือ “น้อยที่สุดที่เราสามารถสร้างได้ในตอนนี้” หรือ “น้อยที่สุดที่ลูกค้าจะได้รับคุณค่า” Minimum Viable Product หรือ MVP เป็น Agile concept ที่เราเอามาใช้ในการสร้าง/build product ให้ลูกค้า สำหรับ Software developer หรือทีมที่กำลังทำเรื่อง Feature design อยู่อาจจะคิดว่ามันเป็นการเลือก features ที่จะทำ จริงๆแล้วมันเป็นเรื่องของการเลือกว่า Underserved needs อันไหนหรือปัญหาไหนของลูกค้าที่เราจำเป็นต้องตอบก่อนเพื่อส่งมอบคุณค่าให้เร็วที่สุดเพราะเราอยากให้ลูกค้าได้ทดลองใช้จริงเพื่อที่เราจะได้มีโอกาสเก็บข้อมูลป้อนกลับมาที่ทีมให้ปรับและพัฒนา Product ให้ตอบโจทย์ลูกค้าได้รวดเร็วและแม่นยำ
การหา Underserved needs เนี่ยมันมีหลายวิธี ทีมต้องสวมหมวกนักสืบเพื่อไปพูดคุย ถามคำถามเพื่อทำให้เราเข้าใจว่าจริงๆแล้ว Users ต้องการอะไร เพราะอะไร หรืออะไรกันแน่ที่เป็นปัญหาจริงๆของลูกค้า (Insights) เหมือนการค่อยๆปลอกหอมหัวใหญ่ออกไปทีละชั้นๆจนกว่าเราจะสามารถนำเสนอ Elegant and Simple Solution ตามที่ Steve Job ได้กล่าวไว้ ไปอ่านรายละเอียดกันในหนังสือต่อแล้วกันนะคะ พี่ทำสรุปไว้ให้ตามรูปด้านบน :)
มาคุยเรื่อง Minimum กันต่อ… จะเห็นว่าใน Process ของการพยายามช่วยให้ users แก้ปัญหาของเขา เราต้อง “เรียนรู้ ปรับ Product อย่างรวดเร็วก่อนเค้าจะหงุดหงิด” วันก่อนจูนทีม MC เอาตัวอย่างข้างล่างมาให้ดู พี่คิดว่ามันเข้าใจง่ายดี สมมุติว่าปัญหาของลูกค้าคือต้องการที่จะพาตัวเองเดินทางจากจุด A ไปจุด B การทำ MVP คือการพยายามหา “Underserved need” นี้ให้เจอว่าจริงๆแล้วเขาไปไม่ได้เพราะอะไร แล้วอะไรจะทำให้เขาทำได้ เช่น ถ้าต้องเดินจาก A ไป B คงเหนื่อยมากลูกค้าน่าจะต้องการ “เครื่องมือเพื่อช่วยทุ่นแรงในการเดินทาง” ถ้านี่เป็นปัญหาของการขาดเครื่องทุ่นแรงในการเดินทาง เราต้องพยายามที่จะไม่ assump ว่า “อ๋อ เธออยากได้รถยนตร์หละสิ” ความหวังดีในการสร้างรถยนตร์ซึ่ง (สำหรับเรา)เป็นเครื่องมือที่สะดวกที่สุดในการเดินทางอาจจะไม่ใช่ solution ที่ตรงกับปัญหาของลูกค้าที่สุด หรือรวดเร็วที่สุดที่เราทำได้ เพราะถ้าเราปักธงว่ามันต้องเป็นรถยนตร์ เราอาจจะเริ่มจากการสร้างล้อก่อนแล้วค่อยไปสร้างระบบคานและส่วนประกอบต่างๆอีกเป็นร้อยๆชิ้น ซึ่งในระหว่างนั้นสิ่งเดียวที่ลูกค้าทำได้คือต้องรอ รอ รอ (ถ้าเขายอมรอเรานะ)…. ในระหว่างการรอคอยให้เราสร้าง Product ชิ้นใหญ่และซับซ้อนให้เสร็จนี้ เราจะไม่ได้มีโอกาส Interact หรือได้รับ Feedback ใดๆกลับจากลูกค้าเลยว่าจริงๆที่เขาอยากได้คือรถยนต์ใช่หรือไม่ การพยายามหา solutions มาตอบปัญหานี้ของลูกค้าอาจจะง่ายกว่า เร็วกว่าและทำให้เราได้เรียนรู้เข้าใจลูกค้าได้ทันต่อความต้องการมากกว่า เช่น จริงๆแล้วลูกค้าอาจจะอยากได้จักรยานเพราะพวกเขาอยากออกกำลังกายไปด้วย หรือพวกเขาอาจจะอยากได้ Motorbike เพราะว่าจาก A ไป B เนี่ยรถติดมากพวกเขาจะ Happy กว่าถ้าได้อะไรที่เร็วและคล่องตัวกว่ารถยนตร์ในราคาที่ไม่แพงมาก
การสร้าง Solutions แบบ Progressive นี้สามารถเกิดได้ถ้าเราใช้ Concept MVP เข้ามาเป็นวิธีคิด เมื่อได้ Problem ที่ยังไม่มี Solution ของลูกค้ามาแล้วต้องช่วยกันจัด Priority ว่าเราจะสร้างอะไรออกไปก่อนเพื่อเป็น Solution ให้กับปัญหานี้ให้เร็วและตรงกับความต้องการที่สุด แล้วเราค่อยพัฒนาและทดลองเอาออกไปให้ลูกค้าได้ลองใช้ รวมถึงแก้ไขปรับปรุงเพื่อออก New version ของ Productให้ถี่ขึ้น ซึ่งการเรียนรู้จากการที่ลูกค้าได้ใช้งาน Solution ของเราจริงๆนี้ จะทำให้เรามั่นใจได้ว่าเรามาถูกทางหรือเปล่า เราจะได้ไม่ต้องเสียเวลาสร้าง Solution ที่ไม่ใช่แต่เราไม่รู้ ส่วนลูกค้าก็จะได้ประโยชน์จากเวลาและแรงงานที่เราลงไปกับการพัฒนา product อย่างรวดเร็วและตรงจุดนี้ตั้งแต่แรก
Henrik Kniberg เป็น Spotify coach พูดไว้ว่า MVP เป็นการสร้าง “Smallest possible things …build to fulfil the basic narrative and delight the user” แปลว่าเราต้องเลือกให้ถูกว่า Narative (problem/story/need) ไหนเราจะทำ แล้วทำให้น้อยที่สุดเพื่อตอบแค่ Narative นั้นที่พอจะทำให้ลูกค้า ได้รับคุณค่าและHappy แปลว่า MVP ต้องสร้างมาให้มีกลุ่ม Features ที่ตอบโจทย์ 1-Must have, 2 Performance, 3 Delight ของ Narative ที่เราเลือก Henrik บอกว่ามันน่าจะเรียกว่า Minimum Lovable Product มากว่า ถ้าพวกเราเคยเห็นปิรามิตนี้ของ Jussi Pasanen ที่พี่ใส่ไว้ด้านล่าง เราจะเข้าใจว่าเวลาเราบอกว่าเรา “Build a slice across, instead of one layer at a time” มันคือรูปนี้เลย
อย่าลืมว่า Customers don’t care about our solutions. They care about their problems. ที่เราต้องเข้าใจคือลูกค้าส่วนมากอาจจะไม่ได้รู้ตั้งแต่แรกว่าตัวเองต้องการอะไร หรืออะไรเป็นปัญหาหลักที่เขากำลังเจอ เป็นหน้าที่ของทีมที่ต้องเข้าไปดึงความต้องการเหล่านี้ออกมาชัดๆหรือเข้าไป “Define the problem space” ให้ได้ ในขณะเดียวกันลูกค้าจะสามารถให้ข้อมูลป้อนกลับได้ก็ต่อเมื่อพวกเขาเห็น Solutions ซึ่งจะทำให้เขาตอบได้ว่ามันช่วยหรือไม่ช่วยพวกเขาหรือไม่ อย่างไร ชอบหรือไม่ชอบ แบบไหนจะดีกว่า จะเห็นว่า Feedback ที่ได้จากการเก็บข้อมูลใน Solution Space จะถูกเอาไปใช้ปรับปรุงสมมุติฐานของเราใน Problem Space เพื่อให้เราทำ Product ให้ตอบโจทย์ที่ตรงและให้คุณค่ามากขึ้นต่อไป
References:
Jez Humble (2015), Lean Enterprise: How High Performance Organizations Innovate at Scale, Joanne Molesky & Barry O’Reilly
Dan Olsen (2015), The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback (2015) Print ISBN:9781118960875 |Online ISBN:9781119154822 |DOI:10.1002/9781119154822
