หนึ่งในงานหลักที่พวกเราชาว Product Team ต้องทำอยู่ทุกวันเลยคือ สร้าง Feature ใหม่ๆ เพื่อแก้ปัญหาให้ผู้ใช้งาน หรือปรับปรุงของที่มีอยู่เดิมให้ใช้ได้ง่าย และตอบโจทย์มากยิ่งขึ้น
แต่คำถามสำคัญ ที่เราต้องมีคำตอบให้กับทุกสิ่งที่ทำคือ
“เราจะรู้ได้ไง ว่าสิ่งที่ทำออกมา มันตอบโจทย์ผู้ใช้ หรือทำให้ชีวิตเค้าง่ายขึ้นได้จริงๆ”
เพราะงั้น การที่จะคลอดทุก Feature ออกมาได้ เราต้องกำหนด “ตัววัดผล” กันก่อนว่า ถ้าสมมติฐานเราถูกต้อง ต้องมีอะไรบางอย่างแสดงออกมาให้เห็นได้จาก “ตัววัดผล” เหล่านั้น
If you cannot measure it, you can’t improve it.
ชาว Product Team ที่ NocNoc เราเชื่อในเรื่องนี้มากๆ
ในทุกๆ Feature ที่มีผลต่อผู้ใช้งาน จึงต้องผ่านการทำ A/B testing เพื่อสรุปให้ได้ว่า “จริงๆ แล้ว สิ่งนี้ตอบสมมติฐานของเราจริงมั้ย” หรือ “เรากำลังมาถูกทางรึเปล่า”
เราเลยพยายามคิด Process ในเรื่องนี้ให้ทำได้ง่าย เพื่อช่วยให้ PM และทีมที่เกี่ยวข้องตัดสินใจเกี่ยวกับ product ของตัวเองได้เร็วที่สุด
วันนี้จะมาเล่าให้ฟังว่าเราทำอะไรไปบ้าง เพื่อให้ได้ข้อมูลพวกนั้นมาใช้ตัดสินใจได้รวดเร็วที่สุด
สมมติเรามีโจทย์อยู่ว่า
อยากรู้ว่า Design ของหน้ารวมสินค้า ระหว่างแบบเก่า (Variation A) กับแบบใหม่ (Variation B) แบบไหน ทำให้ลูกค้ากดเข้าไปดูสินค้าได้มากกว่ากัน
การวัดผล Feature ในช่วงแรกๆ
- เริ่มจากศึกษาเพื่อให้ได้ solution ร่วมกันในทีม
- PM เขียน Feature Requirement ส่งเข้า Sprint
- หน้ารวมสินค้าแบบใหม่ (Variation B) ขึ้นบน Production พร้อม A/B Testing กับแบบเดิม (Variation A)
- PM เขียน Requirement เพื่อให้ Data Analyst ช่วย Visualize Metric ที่ใช้วัดออกมา
- Data Analyst ขุดข้อมูล User Interaction ที่เก็บจากหน้าเว็บ เพื่อทำออกมาเป็น Dashboard ส่งให้ PM ใช้ตัดสินใจ
ซึ่งในกรณีที่เราโชคดี คือ User Interaction ที่ Developer ติดมาให้ ครบถ้วน ใช้งานได้ ก็จะใช้เวลาเฉลี่ยราวๆ 2–4 อาทิตย์ หลังจาก Feature ขึ้น Production (สมมติว่าไม่ต้องรอคิว Data Analyst ด้วยนะ)
แต่ถ้าโชคร้ายกว่านั้น คือเรามีข้อมูล User Interaction ไม่พอทำ Dashboard
เราต้องเขียน Requirement เพิ่มเติม เพื่อให้ Developer เก็บข้อมูลพวกนั้นเพิ่ม รอให้มีข้อมูล ใช้เวลาเพิ่มขึ้นมาเฉลี่ยก็ราวๆ อีก 2–4 อาทิตย์
แปลว่าถ้าเราโชคร้าย ข้อมูลมีไม่พร้อมหลัง Feature ขึ้น Production กว่าเราจะได้ Evaluate ผลของสิ่งที่เราทำขึ้นมา ก็อาจต้องใช้เวลาถึง 2 เดือนเลยทีเดียว
ไม่ไหว แบบนี้ไม่ทันกิน ยิ่งทีมใหญ่ขึ้น Feature มากขึ้น ตรงนี้จะกลายเป็นคอขวดในการตัดสินใจของทั้งทีมแน่ๆ
แล้วปัญหาจริงๆ มันอยู่ตรงไหนกัน
จากของเดิม จะเห็นว่าปัญหาหลักๆ มีอยู่ 2 ส่วนคือ
- คนใช้ข้อมูล (PM) ไม่สามารถ Visualize ข้อมูลดิบที่มีให้ตอบโจทย์สิ่งที่ตัวเองสนใจได้ เพราะข้อมูลถูกเก็บอย่างไม่เป็นระเบียบ หรือซับซ้อนเกินไป
- ข้อมูล (User Interaction) ไม่พร้อมใช้งาน (เก็บมาแบบผิดๆ หรือไม่ได้เก็บไว้เลย)
ต้องหาตัวช่วย — Product Analytic Tool
หลังจากที่เห็นปัญหา เราก็เริ่ม Research ว่าปกติคนอื่นเค้าทำกันยังไงนะ ประกอบกับได้คีย์เวิร์ดจากพี่นัท CPO ของพวกเรา
“Product Analytic”
(อ้อ จริงๆไม่ได้มาแค่คีย์เวิร์ดหรอก แต่พี่นัทบอกว่าอยากให้ลองหาดู แล้วลองสรุปผลให้ได้ด้วย ภายใน 2 อาทิตย์)
What… 2 อาทิตย์ ทำไมถึงรีบขนาดนี้ lol
สรุปว่าดูไปๆ มาๆ เจอทั้งหมด 3 เจ้า Mixpanel, Amplitude, Clevertap
ตัด Clevertap ทิ้งไป ไม่เข้าพวก
ลอง PoC สองตัวแรกได้สักพัก พวกเราก็ได้ข้อสรุปว่า
โอเค Mixpanel เนี่ยแหละ พระเอกตัวจริง
สิ่งที่มันทำได้คือมันเป็น Product Analytic ที่ตอบ Pain Point เราได้หมดเลยหลักๆ คือมันทำให้การ Visualize User Interaction ทำได้ง่ายมากๆ ระดับ Business User ก็สามารถทำเองได้
ข้อนี้ทำให้เราเคลียร์คอขวดที่ต้องรอ Data Analyst ไปได้เกือบทั้งหมด
และที่สำคัญ ข้อมูลพฤติกรรมการใช้งานในรูปแบบต่างๆ คนใช้ปุ่มนี้เยอะแค่ไหน หน้าตาแบบไหนทำให้คนไปต่อได้ง่ายกว่ากัน หรือตลอดทั้ง journey ผู้ใช้ของเราใช้เวลาตรงไหนเยอะเป็นพิเศษ พวกนี้กดแค่ไม่คลิกก็เห็นข้อมูลทันที!
และเราปรับ Process อีกนิดหน่อย เนื่องจากเราต้องเก็บ User Interaction ที่เราสนใจ ส่งเข้า Mixpanel เพื่อทำ Dashboard เราตกลงกันให้ PM เจ้าของ Feature เป็นคนกำหนดว่าเราสนใจ User Interaction จุดไหนบ้าง แล้วเขียนเป็น Requirement ให้ Developer พร้อมกับการทำ requirement ทุก Feature ไปเลย
ผลที่ออกมาคือเราได้ข้อมูลพร้อมทำ Dashboard พร้อมๆ กับที่ Feature Live บน Production ที่เหลือคือนั่งรอให้คนเข้ามาใช้งาน แล้วเก็บข้อมูลไป Visualize สรุปผลแค่นั้น
ทำให้เราสรุป Performance ของทุกๆ Feature ที่เราทำ เร็วขึ้นได้ทันทีอย่างน้อย 2–4 อาทิตย์
และ Data Analyst ยังได้ใช้เวลาของตัวเองไปทำอย่างอื่นที่ซับซ้อนมากกว่านี้ด้วย ส่วน PM ก็ทำ Dashboard ดูในมุมอื่นๆ ที่ตัวเองสนใจได้รัวๆ โดยไม่ต้องรอคิวให้ใครทำให้อีก
และยังไม่จบแค่ได้ Report เร็วขึ้น!
นอกจากเราใช้เพื่อประเมิน Performance ของ Feature ที่เราทำขึ้นมาแล้ว ทีมของเรายังใช้เพื่อขุดหาปัญหาหรือสิ่งที่น่าสนใจจากข้อมูลที่เราไม่ได้จาก User Interview อีกด้วย
ผลจากการที่เราตั้งใจเก็บ User Interaction ให้เป็นระเบียบ นอกจากเราจะหยิบเอามาใช้ทำ Dashboard ได้ง่ายแล้ว เรายังพบว่า
ข้อมูลพวกนี้ เอาไปใช้ทำ Machine Learning Model ได้(โคตร) ง่ายมากๆ
เราได้ลองใช้ข้อมูลพวกนี้ ไปสร้าง Product Recommendation Model ออกมาให้พร้อมขึ้น Production โดยเริ่มจากศูนย์ ปรากฎว่าใช้เวลาไม่ถึงเดือน โดยเวลาส่วนใหญ่ ใช้ไปกับการเตรียม Data Pipeline และเตรียม Integration โดยไม่ต้องมาปวดหัวกับเรื่อง Data Cleansing ให้เสียเวลา
รายละเอียดเรื่องนี้ เดี๋ยวไว้มาเล่าให้ฟังใน Blog หน้า
สรุป
จากการพยายามปรับ Process การวัดผล Feature จากเดิมที่ข้อมูลถูกเก็บไม่เป็นระเบียบ ใช้ยาก ไม่มีคนดูแล และการ Visualize ทำได้ยาก และใช้เวลานานมาก
ผ่านมา 6 เดือน ทำให้เรา
- Product team สร้าง report เพื่อวิเคราะห์ประสิทธิภาพของฟีเจอร์ต่างๆ หาจุดที่เราสามารถปรับปรุงได้ หาข้อมูลเพื่อสนับสนุนการตัดสินใจออกฟีเจอร์ใหม่ๆ หรือเลือกกลุ่มผู้ใช้งาน รวมๆ แล้วหลายร้อย report
- เห็น Performance ของ Feature ที่เราทำ ว่าถูกทางรึเปล่า ดีขึ้นกว่าเก่าจริงไหม และตัดสินใจได้ภายใน 2 อาทิตย์ จากเดิมที่เป็นไปได้ว่าเกือบ 2 เดือน คิดดูว่ามันทำให้เรา Iterate ได้เร็วขึ้นมากแค่ไหน!!
- Data Analyst ได้ใช้เวลาไปทำ Report อื่นที่ซับซ้อนกว่ามากๆ
- มีข้อมูลที่ (ค่อนข้าง) พร้อมใช้งาน เพื่อทำ Machine Learning Model
- ประหยัดเวลาการคุยกันไปๆ มาๆ ในกรณีที่ข้อมูลไม่พร้อมใช้ ต้องขอให้ Developer เก็บเพิ่ม หรือเก็บมาแล้วผิด ไม่เข้าใจ อันนี้ได้ประหยัดเวลาได้มหาศาล คิดคร่าวๆ แล้วเราน่าจะประหยัดเวลารวมๆ กันจากหลายทีมไปได้หลายร้อยชั่วโมงต่อเดือน
เขียนไปเขียนมา รู้สึกตัวเองเหมือนเป็นเซลขาย Mixpanel ซะงั้น 555 เอาเป็นว่า มันมีหลายตัวเลือกแหละ อันไหนก็ได้