7 บทเรียน Product Discovery จากอีเว้นท์ We All Fail (at some point)

สรุปอีเว้นท์ We All Fail at Some Point โดย PMCorner โดย 7 ผู้มากประสบการณ์ Product Discovery เมื่อวันที่ 31 มีนาคม 2024 ที่ผ่านมา ณ KLOUD by KBank

What is Product Discovery?

เราสามารถอธิบาย Product Discovery แบบง่ายๆ โดยการเทียบกับ Product Delivery
Product Discovery คือการตัดสินใจว่าจะสร้างอะไร
ส่วน Product Delivery คือการลงมือสร้างมัน

แต่ถ้าเรามองลึกลงไปอีกจริงๆ จะเห็นว่า Product Discovery นั้นมีอีกหลาย Layer และซับซ้อนมากกว่าแค่ตัดสินใจว่าจะสร้างอะไร จากเว็บไซต์ aktiasolutions Product Discovery สามารถแบ่งออกได้เป็น

• Strategy Discovery: Laying the groundwork with a clear vision and strategic direction.
• Business Discovery: Understanding the market, competition, and financials.
• Product Discovery: Crafting the product that meets customer needs and desires.
• Market Discovery: Finding your product’s place in the market and the best channels to reach your audience.
• Growth Discovery: Exploring opportunities for scaling and expanding your product’s impact.

Source: https://aktiasolutions.com

ทั้งนี้ทั้งนั้น Product Discovery ทั้ง 5 ประเภทนี้ ไม่ได้แยกขาดออกจากกัน แต่เป็นฟันเฟืองที่เชื่อมโยงและส่งผลถึงกัน

สำหรับเนื้อหาของเราในวันนี้ จะแบ่งประสบการณ์ออกเป็น 3 กลุ่ม ดังนี้

1. Business Discovery Lesson
2. Product Discovery Lesson
3. Product Delivery Lesson

ถ้าพร้อมกันแล้ว ไปเริ่มบทเรียนแรกกันเลย 🚀🧨

🔍 1. Business Discovery Lesson

บทที่ 1: Value ที่แท้จริงที่ลูกค้าได้รับ

ก่อนหน้าที่จะมารับตำแหน่ง Advanced Innovation Product Manager ประจำทำที่ MAKE (KASIKORN LABS) พี่แป๊ปเคยทำ Product ตัวหนึ่งที่เกี่ยวกับ Token มาก่อน

โดย Product นี้มาจากแนวคิดที่ว่า หากลูกค้าองค์กรอยากจะออก Token ของตัวเอง ก็จะมีความยุ่งยาก และใช้เวลามากมาย Product นี้จึงถือกำเนิดขึ้นเพื่อให้บริการระบบเสนอขายโทเคนดิจิตอล (ICO Portal) ลูกค้าองค์กรจะไม่ต้องสร้างระบบ/ดำเนินการทุกอย่างเอง ช่วยให้องค์กรประหยัดเวลาในการออก Token

อุปสรรคที่พบในตอนแรก คือ ด้วยความเป็นลูกค้า B2B ทำให้ส่วนมากใช้เวลา Lead Time นาน และบางครั้งรู้สึกว่าลูกค้าไม่เข้าใจสิ่งที่ทีมกำลังนำเสนอ พี่แป๊บจึงลองทำงานแบบ Small Size โดยทำ Onboarding ให้เร็วขึ้น ซึ่ง ผลลัพธ์จากการทำ คือ เวลาที่ใช้ในการพูดคุยลดจาก 2 เดือน เหลือ 2 สัปดาห์ ลูกค้าเข้าใจบริการมากขึ้น

แต่ท้ายที่สุดแล้วลูกค้าก็ไม่ไปต่ออยู่ดี เพราะลูกค้าไม่เข้าใจว่าได้คุณค่าอะไรจากการออก Token

🌟 จะเห็นว่า Value ในโจทย์นี้มี 2 ระดับ

1. Value จากการออก Token
2. Value จากการลด Effort ในการออก Token

เมื่อ User ไม่ได้ต้องการ Value ข้อ 1.
Value ในข้อ 2. ที่ Product มอบให้จึงหายไป 🌟

บทที่ 2: Product ที่ตอบโจทย์ แต่ลูกค้าไม่พร้อมจ่าย

บทเรียนที่ 2 มาจากพี่แก๊บ Finnomena รู้ไหมว่า ก่อนที่จะมาเป็น Platform ลงทุนในกองทุนรวมอย่างทุกวันนี้ Finnomena เอง ก็เคยทดลอง Business Model อื่นๆ มาก่อน

เริ่มแรกเลย Finnomena เคยอยากจะเป็น Netflix แห่งโลกการลงทุน เพราะเรามองว่า หากเนื้อหาการลงทุนของเรามีประโยชน์และหาเงินให้กับ User ของเราได้จริง เช่น ถ้า Content ความรู้เรื่องการลงทุนราคา 1,000 บาท แล้ว User นำความรู้ไปลงทุน ได้กำไร 10,000 บาท ทำไม User จะจ่ายเงินให้เราไม่ได้

ในช่วงแรก Finnomena ปล่อยเนื้อหาให้คนมา Subscribe แบบฟรีๆ ก็มีคนเข้ามาติดตามเยอะมาก แต่เมื่อทีมต้องการ Monetize ปรากฏว่าเก็บเงินไม่ได้

ซึ่ง Finnomena ก็ได้เรียนรู้และปรับเปลี่ยน Business Model จนมาเป็นอย่างปัจจุบัน

พี่แก๊บแชร์อีกประเด็นที่น่าสนใจ คือ
Idea ในการทำ Product มี 3 ระดับ

1. ระดับ Feature
2. ระดับ Product
3. ระดับ Business

Idea ระดับ Feature คือเป็นแค่ส่วนเสริมของ product
Idea ระดับ Product คือตอบโจทย์ความต้องการของผู้ใช้
Idea ระดับ Business คือทำให้เป็นธุรกิจที่ยั่งยืนได้

🌟 ดังนั้น As a Product Manager เราลองถามทบทวนกับตัวเองให้ดีว่าไอเดียที่เรากำลังคิดนั้นอยู่ในระดับไหน Feature/Product/Business และในเวลานี้เรากำลังมองหาไอเดียระดับใดกัน 🌟

บทที่ 3: หาก Product กับ Market อยู่คนละทิศ ก็หาเงินไม่ได้

บทเรียนสำคัญจากพี่อาร์ท ZWIZ.AI บริการ Chatbot ช่วยปิดการขาย ที่แรกเริ่มพี่อาร์ทตั้งกลุ่มเป้าหมายเป็นเพื่อน SME ที่เป็นสินค้าแฟชั่น ที่ขายตามร้าน Multi-Brand โดย Chatbot จะช่วยประหยัดเวลาของ User กลุ่มนี้

ซึ่งเมื่อทำของออกมาและนำไปขายจริง ปรากฏว่าลูกค้าของ ZWIZ.AI เป็นคนอีกกลุ่มนึง

กลุ่มเป้าหมายเริ่มแรกของพี่อาร์ทเป็นกลุ่มที่มีเงินอยู่แล้ว และไม่มีปัญหากับการขยาย Operation เพื่อตอบแชท ส่วนลูกค้าจริงๆ ที่ยอมจ่าย คือ ลูกค้าประเภท ขายคนเดียว เปิดเพจ Resell ยิงแอดขาย หรือ บริษัทที่มี 10 เพจ ขายอุปกรณ์นำเข้าจากจีน

ซึ่งความต้องการของลูกค้ากลุ่มนี้ก็แตกต่างจาก Offering ของ ZWIZ.AI ที่ทำไว้แล้ว
ลูกค้าตัวจริงต้องการ ‘เพิ่มยอดขาย ปิดการขาย ตามลูกค้า วัดผลแอดมิน’

ZWIZ.AI ก็ยอมปรับหลายๆ อย่าง ตาม Requirements ที่ได้จากลูกค้ากลุ่มนี้

และมีการปรับ Pricing จากเดิม 500 บาท ไม่มีคนซื้อ ก็ทำเป็น Freemium ใช้ฟรี แล้วมีคอร์สสอน ซื้อคอร์สสอน 5,000 บาท ได้ใช้ฟรี 1 ปี เอาสิ่งที่เราชอบ เราทำได้ดี มาทำ และหาเงินจากตรงนั้น ก็ทำให้ ZWIZ.AI อยู่รอดมาได้ 👏

ถ้ามองย้อนกลับไป จะบอกตัวเองว่า

🌟 จากบทเรียนนี้เราได้เรียนรู้ว่า User ที่เราคุยๆ และให้ Requirements กับเราอาจไม่ใช่กลุ่มลูกค้าของเราก็ได้ สิ่งที่เค้าพูดอาจจะเป็นแค่ Nice to Have ของเค้า ดังนั้นคำถามต่อมาคือ As a Product Manager เราจะหาคำตอบได้อย่างไรว่า User ของเรามีปัญหา และพร้อมจะจ่ายเงินให้กับ Solution ของเราจริงๆ 🌟

🌟 ระวัง Bias ในการพูดคุยกับ User ที่อยู่ใกล้เรา เราสามารถเข้าถึงได้ง่าย เพราะอาจจะมี User อื่นๆ ที่เป็นลูกค้าของเราแต่เรายังไม่ได้พูดคุยด้วยก็ได้ 🌟

PMCorner Book Rec. 📕 :

เราอาจไม่สามารถหาคำตอบให้กับทุกอย่างได้ 100% แต่ว่าเราสามารถถามคำถามที่ดีกว่าเดิม เพื่อให้ได้คำตอบที่เป็นความจริงจาก User ได้ The Mom Test เป็นหนังสือที่จะมาบอก How to have conversation with customers แบบใช้ได้จริง

📱 2. Product Discovery Lesson

บทที่ 4: สิ่งที่คิดว่า User จะเป็น ไม่เหมือนกับที่ User เป็นจริงๆ

บทเรียนที่ 4 มาจากพี่วิน CPO & CTO แห่ง R’Ket แอปลงทุนรูปแบบใหม่ที่พึ่งเปิดตัว และกำลังเปิด Alpha Version ให้ Early Seeker เข้าทดลองใช้อยู่ ณ ขณะนี้ Download R’Ket

ทีม R’Ket มีความเชื่อและรูปแบบการทำงานเป็น Product Led ที่ให้ความสำคัญกับการ User Research มากๆ มีการพูดคุยกับ User เยอะมาก

ในช่วงเดือนที่ 4 ของการพัฒนา ทีมคุยกับ User และเจอปัญหาว่า User อยากลงทุนในหุ้นต่างประเทศแต่ไม่กล้า เพราะรู้สึกว่าเป็นเรื่องไกลตัว เช่น เมื่อเทียบ ธนาคารกรุงเทพ กับ Starbucks ก็ยังรู้สึกว่ารู้จักธนาคารกรุงเทพมากกว่า หรือ เมื่อทดสอบแอปกับ User ที่สนใจ EV (Electric Vehicles) บนแอปมี Suggestion มากมาย แต่สุดท้าย User ก็กดที่ Tesla ตัวเดียว

ทีม R’Ket จึงคิด Solution ขึ้นมาโดยลองทำ Stock Suggestions เป็นหน้าตาคล้ายๆ Tinder ให้ User ปัดซ้ายปัดขวา ให้เขาสามารถ Discover เร็วๆ ตัดสินใจง่ายๆ ไว้สร้างเป็น Favorite List จากความเข้าใจว่า ‘คนรุ่นใหม่ชอบอะไรเร็วๆ’

แต่เมื่อนำไปทดลองกับ User ปุ๊ปก็ค่อนข้าง Fail เพราะว่า เมื่อ User เปิดเข้ามาเห็นหน้า Swipe คล้าย Tinder ก็กดปิดทิ้งทั้ง 20 คนที่ทดสอบเลย เพราะ User เขามีในใจอยู่แล้วว่าจะเข้ามาดูอะไร เขาอยากมาหาความรู้ แต่ไม่ได้ต้องการเป็นอะไรง่ายๆ Behavior คนละแบบเลย

🌟 ความล้มเหลวนี้บอกเราว่า Action ที่ User เคยใช้ ไม่ได้แปลว่าจะสามารถ Apply ได้กับทุก Use Case เพราะอาจมี Context และ Mental Model ที่แตกต่างกัน 🌟

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

จะทำยังไงให้รู้ได้ว่า Research ที่เก็บมานั้นจะ Work จริงไหม? จะรู้ได้ยังไงว่า End User ที่ทำ Research เป็นกลุ่มที่กำลังมองหา?

• ให้ Stakeholder เข้ามาอยู่ใน Development Loop เพื่อให้เห็นภาพรวมของทีมที่กำลังทำของอยู่
• Launch Product ออกไปก่อนเพื่อเก็บข้อมูล แต่ในฝั่งของ Stakeholder ก็ต้องยอมรับความเสี่ยงเพิ่มหาก Product ยังไม่เข้ากับกลุ่มลูกค้าในตลาด

🛸 3. Product Delivery Lesson

บทที่ 6: อย่าคิดแค่ Happy Path – มอง Worst Case ให้เห็นจริงๆ ว่า Worse แค่ไหน

บทเรียนที่ 6 จากพี่ฟรอส เหมียวจด (KASIKORN LABS) พี่ฟรอส แชร์ความผิดพลาดที่ครั้งหนึ่ง แอปที่คนใช้หลัก 8 ล้าน สูญเสีย User เหลือ 5 ล้าน จากเหตุการณ์ ย้ายระบบไปบน Cloud

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

ซึ่งในตอนนั้นบริษัทก็มีการเตรียมการที่หนาแน่นมากๆ โดยใช้เวลาเตรียมการนานถึง 6 เดือน มีการซักซ้อมทดสอบย้ายระบบไปสู่ระบบใหม่ ถึง 10 รอบ มีการจำลอง Environment เหมือนจริง และมีการซ้อม Functional ด้านอื่นๆ เพื่อให้มั่นใจมากที่สุด

ด้วยความที่ทีมซ้อมกันอย่างรัดกุมมากๆ ทำให้ค่อนข้างวางใจ และตัดสินใจบน User Journey ที่ราบรื่น

แต่เมื่อถึงเวลาที่ย้ายจริงทีมพบปัญหาที่ไม่คาดคิด คือระบบ Cloud มีปัญหาพอดี บวกกับการล้มของ Micro Service บางตัว ส่งผลให้ระบบที่ทำงานต่อเนื่องกันล้มเป็น Domino ในฝั่ง User เมื่อเข้าแอปมาก็จะเจอหน้าหมุนๆ แทนที่จะเป็นหน้าอัพเดทตามที่ทีมคาดการณ์ไว้

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

และด้วยระบบยืนยันตัวตนที่หนาแน่นกว่าเดิมในแอป Version ใหม่ หาก User ขาดข้อมูลไปบางส่วน หรือ ข้อมูลหมดอายุไป User จะต้องไปยืนยันตัวตนใหม่ที่สาขา

จากเหตุการณ์นี้ส่งผลให้จำนวน User ลดจาก 8 ล้าน เหลือ 5 ล้าน ใน 1 สัปดาห์ และสาขาต้องรองรับลูกค้าที่มายืนยันตัวตนที่สาขาจำนวนมากยาวนานหลายเดือน

หากมองย้อนกลับไป พี่ฟรอสบอกว่าคงพยายามอย่างถึงที่สุด ที่จะตรวจสอบข้อมูลที่ขาดอย่างละเอียด เพื่อประเมิน Worst Case ที่สุดที่เป็นไปได้ เพื่อประกอบการตัดสินใจ 🕵🏻‍♂️

บทที่ 7: ใครวางแผนทำ AI Product อย่าลืมเช็คว่า Data มีมั้ย!!

บทเรียนสุดท้าย จาก สายฟ้า AI Product Manager จาก Jackett ที่เคยมาแชร์ ประสบการณ์สร้าง product จาก Zero to One ของ AI Startup สิงคโปร์ กับ ‘Zaifa Thananat’ บน Blog ของเรา 🥳

พี่สายฟ้าได้แชร์ประสบการณ์ประเมินเวลาในการ Deliver AI Feature

Jackett เป็น Assessment Creation ช่วยคุณครูออกข้อสอบ ซึ่งมี Killer Requirement คือ ระบบจะต้องสามารถ Tag โจทย์ทุกข้อ ละเอียดสุด ๆ เช่น เป็นคำถามวิชาอะไร ประเภทไหน เช่น ทดสอบความจำ ทดสอบความเข้าใจ ทดสอบการประยุกต์ใช้ เพื่อนำไปออกข้อสอบให้ตรงกับ Requirement ของหลักสูตร

ซึ่งตามแผนในการพัฒนาเดิมคิดว่าใช้เวลาเพียง 2 เดือน โดยการ Scrape ดึงข้อมูลจาก Public Resource เว็บข้อสอบอื่นๆ แต่เมื่อลงมือทำจริง พบว่าข้อมูลบนเว็บเหล่านี้มีการ Tag ไม่ละเอียดเท่าที่ต้องการ ทำให้ทีมต้องตั้ง Operation Label Data มา Train Model ทำให้ใช้เวลาจริง 8-9 เดือน

และนี่ก็คือ 7 บทเรียนที่น่าสนใจจากประสบการณ์จริงของ Speakers ทั้ง 7
หวังว่าจะมีประโยชน์กับทุกคนนะคะ

…

หากคุณชอบคอนเทนท์นี้ อย่าลืมกดไลก์ กดแบ่งปันให้เพื่อนๆ หรือคอมเมนต์กับพวกเราได้นะคะ และสามารถติดตาม Content Update ใหม่ๆ จาก PMCorner ได้ทาง Facebook Page: PM Corner Thailand ได้เลยนะคะ 😀

🌻

Writer:
Onaraya Voravarachai (Onn)

Note takers:
Jeddirok Kaewborisut (Ae)
Chakrik Thaviyonchai (Mick)
Chatdanai Sriprasart (Rif)