MVP & Clear assumption

Chris
Taskworld Tech
Published in
1 min readOct 8, 2017

ผมพบว่าในการทดลอง MVP หรือการทดสอบ Feature อะไรซักอย่างในตลาด สิ่งที่ผมพบว่ายากมากคือการอธิบายให้คนเข้าใจว่า เราควรตั้ง Assumption ที่เคลียร์

สมมติวันนี้เราบอกว่าเราออกฟีเจอร์ตัวนี้ออกไปเพื่อทดสอบตลาด เราควรมี Assumption ที่เคลียร์มากๆ เช่น

  • ฟีเจอร์นี้ถือว่าสำเร็จก็ต่อเมื่อ คนที่สมัครกับเรา 10 License ขึ้นไป ใช้ฟีเจอร์นี้อย่างน้อยสัปดาห์ละ 2 ครั้ง
  • ฟีเจอร์นี้จะสำเร็จก็ต่อเมื่อ เราได้รับความพึงพอใจใน NPS Survey เกิน x คะแนน

Assumption ควรจะตั้งไว้ให้ชัดเจนและตีผลอะไรไม่ได้นอกจาก “ผ่าน” หรือ “ไม่ผ่าน” เท่านั้น อย่างเช่นสองประโยคด้านบน

แต่ตรงข้าม ไม่ว่าผลที่ออกมาจะผ่านหรือไม่ผ่านก็ตาม การตีความนั้นตีความได้หลายแบบเสมอ

ที่ฟีเจอร์ไม่สำเร็จ เราอาจจะทำผิดคิดผิดแต่แรกเลยก็ได้ ไม่โดนใจเลยก็เป็นได้

ที่ฟีเจอร์ไม่สำเร็จ จริงๆ เราอาจจะทำโดนใจแล้ว แต่เราดีไซน์สีไม่สวยหรือเปล่า

ที่ฟีเจอร์ไม่สำเร็จ จริงๆ เราอาจจะทำโดนใจแล้ว แต่กระบวนการเก็บ NPS Survey มีปัญหาหรือเปล่า คะแนนเลยน้อย

พวกนี้มันตีความได้หลายอย่างมาก

ส่วนว่า Test result ผ่านมั้ย ไม่ผ่านก็คือไม่ผ่าน ไม่มีเร้าหรือ มีแค่ได้หรือไม่ได้เท่านั้น

ส่วนเหตุผลอะไรถึงไม่ผ่าน ยัง Open for interpretation เสมอ

ข้อสำคัญที่สุดเลยคือเราต้องไม่กลัวที่จะบอกว่า “ไม่ผ่าน”

ถ้าเรากลัวที่จะทดสอบไม่ผ่านมากๆ เราจะตั้งสมมติฐานที่ไม่เคลียร์

เช่น

“User กลุ่มนี้จะต้องชอบฟีเจอร์นี้”

แล้วเมื่อไหร่ถึงจะถือว่าชอบ เมื่อไหร่ถึงจะถือว่าไม่ชอบ

ถ้าคนชอบ 50.01% ถือว่าผ่านมั้ยนะ?

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

กระบวนการ MVP, Assumption testing, Lean จึงเกิดไม่ได้ในองค์กรที่ไม่ยอมให้ใครล้มเหลว ไม่ยอมให้มีคำว่า “ไม่ผ่าน” เกิดขึ้น

สิ่งที่ยากที่สุดสำหรับผมในกระประยุกต์กระบวนการพวกนี้ คือการอธิบายให้เข้าใจว่า

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

แล้วถ้าคนทำงานเขาไม่เชื่อว่า ไม่ผ่านได้ ไม่เป็นไร ค่อยว่ากันรอบหน้า

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

ซึ่งวิธีแบบนั้นมันไม่นำพา

ทางลงมันมีตอนตีผลข้อมูลตอนตีความ เวลาผลสุดท้ายสิ่งที่เราทำมันไม่ผ่าน Assumption ที่ตั้งไว้ มันไม่จำเป็นต้องตีความว่าที่ไม่ผ่านเพราะผลงานมันห่วยไม่ได้เรื่อง คนทำงานมันห่วยไม่ได้เรื่องเสมอไปนี่ครับซะที่ไหน

แต่ผลการทดสอบ ต้องชัดเจนที่สุดครับ

--

--

Chris
Taskworld Tech

I am a product builder who specializes in programming. Strongly believe in humanist.