TechCut — Lesson Learned · CH3+ OTT Platform Project
ย้อนกลับไปช่วงที่ Muze เริ่มทำงานกับ CH3+ โจทย์ของโปรเจกต์ดูเหมือนชัดเจน:
ทำ OTT Platform ให้ผู้ชมจากโลกทีวีสามารถย้ายมาสู่โลกออนไลน์ได้อย่างราบรื่น
แต่เมื่อเริ่มลงมือจริง เราพบว่าการ build OTT Platform ระดับประเทศไม่ได้มีความยากแค่การทำให้ “วิดีโอเล่นได้”
ความยากจริงอยู่ที่การทำให้ทั้ง platform ทำงานได้ในวันที่ผู้ใช้จำนวนมากเข้ามาพร้อมกัน ตั้งแต่เปิดแอป login กด campaign จ่ายเงิน เข้าร่วม fandom ไปจนถึงการดู content บนหลายอุปกรณ์
CH3+ เติบโตจากฐานผู้ใช้งานประมาณ 1 ล้านคน ไปสู่มากกว่า 12 ล้าน Monthly Active Users และรองรับผู้ชมพร้อมกันสูงสุดประมาณ 800,000 Concurrent Viewers
ถ้าย้อนเวลากลับไปได้ นี่คือ 4 บทเรียนที่เราอยากบอกตัวเองตั้งแต่วันแรก
(อ่านบทความอื่นใน series นี้: Technical Architecture · Product Strategy)
บทเรียนที่ 1: Peak Traffic ต้องออกแบบตั้งแต่ Day 1 ไม่ใช่รอให้ล่มแล้วค่อยแก้
ในหลาย digital product ทีมมักเริ่มจากการออกแบบระบบให้รองรับ average load ก่อน
วันธรรมดามีผู้ใช้เท่านี้ · request ต่อวินาทีประมาณนี้ · server น่าจะรับไหว · ถ้าโตขึ้นค่อย scale เพิ่ม
วิธีคิดนี้อาจพอใช้ได้กับบางระบบ แต่สำหรับ OTT Platform หรือ high-traffic platform ที่มี event-driven behavior วิธีคิดแบบนี้เสี่ยงมาก
เพราะ peak traffic ไม่ได้ค่อยๆ มา — มันมาพร้อมกัน
เช่น ละครตอนสำคัญออกอากาศ, live event เริ่ม, campaign เปิดให้กดสิทธิ์, ศิลปินหรือรายการบางอย่างสร้างกระแส หรือผู้ใช้จำนวนมากเข้ามาพร้อมกันใน prime time
ในช่วงเวลาเหล่านี้ ระบบไม่ได้ถูกทดสอบแค่เรื่อง video playback แต่ถูกทดสอบทั้ง user journey
- ผู้ใช้เปิดแอป เรียก home screen login กด campaign เข้าร่วม activity สมัครหรือจ่ายเงิน พร้อมกัน แล้วจึงไปถึงการดู video
- ถ้า streaming infrastructure พร้อม แต่ login ช้า → ผู้ใช้เข้าไม่ได้
- ถ้า player พร้อม แต่ campaign ล่ม → ผู้ใช้รู้สึกว่า platform ไม่เสถียร
- ถ้า payment flow สะดุด → revenue opportunity หายทันที
- ถ้า front-end เรียก API หนักเกินไป → backend รับโหลดเกินจำเป็น
นี่คือเหตุผลที่ Muze ให้ความสำคัญกับ front-end architecture, BFF, user-facing flow และระบบรอบๆ ที่รองรับ peak usage ตั้งแต่ต้น
คำถามสำคัญจึงไม่ใช่แค่ “ระบบทำงานได้ไหมในวันปกติ” แต่ต้องถามว่า
ในวันที่สำคัญที่สุดทางธุรกิจ ระบบทั้งเส้นทางยังลื่นอยู่หรือไม่
ถ้าทำใหม่ เราจะผลัก peak scenario ให้เป็นส่วนหนึ่งของการออกแบบตั้งแต่ต้น ไม่ใช่แค่ขั้นตอนทดสอบก่อน launch
เพราะ peak ไม่ใช่ edge case — สำหรับ OTT Platform peak คือ moment ที่ธุรกิจต้องการระบบมากที่สุด
บทเรียนที่ 2: Multi-Platform ไม่ใช่แค่ทำหลายเวอร์ชัน แต่คือหลายพฤติกรรมผู้ใช้
CH3+ ต้องรองรับ iOS, Android, Web, Apple TV, Android TV, Samsung TV และ Android Box
ถ้ามองผิวเผิน นี่อาจดูเหมือนการพัฒนา application หลาย version แต่ในความจริง แต่ละ platform ต่างกันไม่ใช่แค่ technology แต่คือ context การใช้งาน
- Mobile — ดูคนเดียว, touch screen, อยู่ระหว่างเดินทาง, สลับ network, คาดหวังความเร็วในการเปิดแอป
- Web — browser หลากหลาย environment, expectation เรื่อง responsiveness ต่างจาก mobile
- Smart TV — นั่งไกลจากจอ, remote control เป็น input หลัก, ไม่ scroll หรือ tap แบบมือถือ — ต้องคิดแบบ 10-foot experience
- Android Box — fragmentation ของ hardware และ performance ไม่สม่ำเสมอ บาง device มี resource จำกัดกว่าที่ทีมพัฒนาคาดไว้
นอกจากนี้ player behavior, DRM, playback policy และข้อจำกัดของแต่ละ ecosystem ยังต่างกันอีก — Apple ecosystem มีมาตรฐานของตัวเอง, Android มีความหลากหลายสูง, Smart TV แต่ละ brand มีข้อจำกัดเฉพาะ
ผู้ใช้ไม่ได้สนใจว่าปัญหาเกิดจาก device, OS, browser, DRM, network หรือ application layer — ถ้าดูไม่ได้ ก็คือดูไม่ได้
บทเรียนสำคัญคือ multi-platform strategy ต้องเริ่มจากการเข้าใจ behavior และ constraint ของแต่ละ platform ก่อน ไม่ใช่เริ่มจากการถามว่า “ต้องใช้เวลากี่เดือนในการ port ไปอีก device”
การ estimate งาน multi-platform จึงต้องคิดให้ครบว่า
- platform ไหนมี UX pattern เฉพาะ
- platform ไหนมี certification หรือ approval process
- platform ไหนมี hardware fragmentation สูง
- platform ไหนต้อง optimize player behavior มากเป็นพิเศษ
- และ platform ไหนมี risk ที่ควรทดสอบก่อน
ถ้าทำใหม่ เราจะวาง platform assessment ให้ชัดตั้งแต่ต้น โดยแยกทั้ง technical constraint, UX pattern, performance risk และ timeline risk ของแต่ละ platform
เพราะใน platform ระดับประเทศ assumption เล็กๆ บน device จริง อาจกลายเป็น delay ใหญ่ใน project ได้
บทเรียนที่ 3: Feature ที่ดีไม่ใช่ Feature ที่มีครบ แต่คือ Feature ที่ทำให้ผู้ใช้กลับมา
ในการสร้าง OTT Platform สิ่งที่ทีมมักถูกกดดันคือการทำ feature ให้ครบ — home, search, player, login, payment, campaign, profile, content catalog, notification, version สำหรับหลาย device
แต่เมื่อ product เริ่มใช้งานจริง คำถามสำคัญจะเปลี่ยนไป
ไม่ใช่แค่ว่า feature นี้มีหรือยัง แต่คือ feature นี้ทำให้ผู้ใช้กลับมาหรือไม่
สำหรับ CH3+ หนึ่งใน product direction สำคัญคือการสร้าง layer ที่เชื่อมผู้ชมกับศิลปิน รายการ และ community นั่นคือมุมของ Fandom
ดังที่พูดถึงในบทความก่อนหน้า — CH3 มี asset ที่แตกต่าง คือความสัมพันธ์ระหว่าง content, artist, audience และ fan community ดังนั้น feature อย่าง campaign, fandom activity, exclusive content หรือ event engagement จึงไม่ใช่แค่ nice-to-have แต่มันคือ product mechanism ที่ช่วยให้ platform มีเหตุผลให้ผู้ใช้กลับมา แม้ไม่มี episode ใหม่ในวันนั้น
บทเรียนคือ digital platform ที่ดีไม่ควรถูกวัดจากจำนวน feature ที่มี แต่ควรถูกวัดจาก behavior ที่ feature เหล่านั้นสร้างขึ้น
- ผู้ใช้กลับมาบ่อยขึ้นไหม
- session ยาวขึ้นไหม
- campaign ทำให้เกิด action จริงไหม
- fandom feature สร้าง community หรือเป็นแค่หน้า content อีกหน้า
ถ้า feature ไม่มี metric ที่ชัดเจน ทีมจะตัดสินใจยากมากว่าควรลงทุนต่อ ควรปรับ หรือควรหยุด และถ้าไม่มี feedback loop ที่ดี platform จะค่อยๆ เต็มไปด้วย feature ที่ “มีอยู่” แต่ไม่ได้สร้างผลลัพธ์จริง
ถ้าทำใหม่ เราจะตั้ง success metric ของแต่ละ major feature ให้ชัดกว่านี้ตั้งแต่ก่อน build — ไม่ใช่แค่ build ให้เสร็จตาม scope แต่ต้องรู้ว่า feature นี้ถูกสร้างมาเพื่อเปลี่ยนพฤติกรรมอะไรของผู้ใช้
บทเรียนที่ 4: Product Strategy กับ Architecture ต้องคุยกันตั้งแต่ต้น
แม้บทความนี้ตั้งชื่อว่า 3 บทเรียน แต่มีอีกบทเรียนหนึ่งที่สำคัญมากจนอยากเพิ่มเป็นข้อสุดท้าย
คือ product strategy และ system architecture แยกจากกันไม่ได้
ถ้า business strategy คือการสร้าง OTT Platform ที่มี fandom, campaign, exclusive content, payment และหลาย device — architecture ก็ต้องรองรับสิ่งเหล่านั้นจริง ไม่ใช่แค่ทำ feature ให้ครบใน backlog
- ถ้า campaign เป็นกลไกสำคัญในการดึง engagement → ระบบ campaign ต้องรองรับ peak ได้
- ถ้า payment เป็นส่วนสำคัญของ monetization flow → เส้นทาง payment ต้องเสถียรและลด friction
- ถ้า fandom เป็น product differentiator → ระบบต้องรองรับ interaction และ community behavior
- ถ้า multi-platform เป็น requirement หลัก → BFF และ front-end architecture ต้องลด complexity ของแต่ละ client
- ถ้า user journey สำคัญกว่าหน้าใดหน้าหนึ่ง → ระบบต้องถูกออกแบบให้ทั้ง flow ไม่สะดุด
นี่คือสิ่งที่ทำให้บทบาทของ Tech Partner แตกต่างจากทีม implement ทั่วไป
เพราะการ build platform ไม่ใช่แค่รับ requirement แล้วเขียน code แต่ต้องช่วยแปลง business strategy ให้กลายเป็น product experience และ system design ที่รองรับการใช้งานจริง
สรุป: สิ่งที่เราเรียนรู้จาก CH3+
การ build OTT Platform ระดับประเทศไม่มีสูตรสำเร็จที่ใช้ได้กับทุกธุรกิจ แต่จาก CH3+ มีบทเรียนที่ apply ได้กับ digital platform หลายประเภท ไม่ว่าจะเป็น streaming, e-commerce, campaign platform, super app หรือ enterprise platform ที่มีผู้ใช้จำนวนมาก
- ออกแบบสำหรับ peak ไม่ใช่ average — เพราะ peak คือช่วงที่ธุรกิจต้องการระบบมากที่สุด
- เข้าใจ constraint ของแต่ละ platform ก่อน commit timeline — เพราะ multi-platform ไม่ใช่แค่หลายหน้าจอ แต่คือหลายพฤติกรรม หลายข้อจำกัด และหลาย risk
- วัด feature จาก behavior ที่มันสร้าง ไม่ใช่แค่จำนวน feature ที่มี — เพราะ feature ที่ดีต้องทำให้ผู้ใช้กลับมา engage หรือสร้าง business outcome ได้จริง
- Product strategy ต้องแปลงเป็น architecture ได้ — เพราะ strategy ที่ดีแต่ระบบรองรับไม่ได้ จะไม่เกิดผลลัพธ์จริงในวันที่ traffic มา
CH3+ เติบโตจากผู้ใช้งานประมาณ 1 ล้านคนไปสู่มากกว่า 12 ล้าน Monthly Active Users และรองรับ Peak Concurrent Viewers ได้ประมาณ 800,000 คน
ตัวเลขเหล่านี้ไม่ได้เกิดจาก technology เพียงอย่างเดียว และไม่ได้เกิดจาก content เพียงอย่างเดียว แต่เกิดจากการผสมกันของ content strength, product direction, user experience และ platform architecture ที่รองรับการเติบโตจริง
สำหรับองค์กรที่กำลังสร้าง Digital Platform
ถ้าคุณกำลังสร้าง platform ที่ต้องรองรับผู้ใช้จำนวนมาก สิ่งสำคัญไม่ใช่แค่เลือก technology stack ให้ถูก แต่ต้องตอบให้ได้ว่า
- platform นี้ต้อง scale ในจุดไหน
- ผู้ใช้จะเข้ามาพร้อมกันเมื่อไหร่
- flow ไหนคือ business-critical flow
- feature ไหนทำให้ผู้ใช้กลับมา
- และ architecture แบบไหนที่จะรองรับ strategy นั้นได้จริง
Muze ช่วยองค์กรออกแบบและพัฒนา Digital Platform ที่เชื่อม Business Strategy, Product Experience และ Scalable Technology เข้าด้วยกัน เพื่อสร้างระบบที่ไม่ได้แค่ใช้งานได้ แต่เติบโตได้จริง