ทำไม AI Products ถึงไปไม่รอด? แล้วจะป้องกันยังไงได้บ้าง

แม้ในตอนนี้ Products จำนวนไม่น้อยในปัจจุบัน กำลังกลายเป็น “AI-based” products แต่ก็มีความจริงอันโหดร้ายว่าไม่มีอะไรสามารถมายืนยันได้เลยว่าโปรดักต์นั้นจะรอด

เราอยากชวนทุกคนมาถอดบทเรียนไปด้วยกันกับสองผู้เชี่ยวชาญด้าน AI จากตอนหนึ่งของ Lenny’s Podcast ที่ได้สัมภาษณ์สองผู้เชี่ยวชาญด้าน AI อย่าง Aishwarya Naresh Reganti อดีตนักวิจัย AI ยุคบุกเบิกที่ Alexa และ Microsoft และ Kiriti Badam จาก Kodex ที่ OpenAI และเป็นผู้อยู่เบื้องหลังการสร้าง AI และ ML infrastructure ที่ Google และ Kumo

เรียกได้ว่าทั้งคู่มีประสบการณ์โชกโชนในการนำทีมและซัพพอร์ตการ deploy โปรดักต์ AI มาแล้วมากกว่า 50 โปรดักต์ในบริษัทยักษ์ใหญ่อย่าง Amazon, Databricks, OpenAI, Google รวมไปถึงสตาร์ทอัพและองค์กรขนาดใหญ่อีกหลายแห่งด้วย!

เรามาดูกันว่าในมุมมองของทั้งสอง อะไรคือสาเหตุที่ AI Product ไปไม่รอด? แล้วเราจะสามารถป้องกันยังไงได้บ้าง?

Table of Contents

สาเหตุที่ AI Product ไปไม่รอด
- 1. กับดักความไม่แน่นอน
- 2. ใจร้อนให้อำนาจกับ AI เร็วเกินไป
เฟรมเวิร์ก CC/CD
อยากเป็น PM ที่เก่งในการทำ AI Products
ยกระดับคุณเป็น PM ตัวท็อปยุค AI ใน 3 เดือน

สาเหตุที่ AI Product ไปไม่รอด

Aishwarya และ Kiriti ชี้ให้เห็นว่าสาเหตุหลักที่ทำให้ AI Products ไปไม่รอด คือ

1. กับดักความไม่แน่นอน

ถ้าเปรียบเทียบกับซอฟต์แวร์แบบดั้งเดิม ซอฟต์แวร์แบบดั้งเดิมนั้นทำงานในลักษณะที่เราค่อนข้างจะคาดเดาได้ users เองก็โต้ตอบผ่านรูปแบบที่เราคุ้นเคย เช่น คลิกปุ่ม ส่งฟอร์ม และนำไปสู่ผลลัพธ์ที่คาดเดาได้ หรือที่เรียกว่า Deterministic system

แต่เมื่อตัดภาพกลับมาที่ AI Products มันมีความ non-deterministic เพิ่ม ‘ความไม่แน่นอน’ เข้ามาทั้งในฝั่ง users ที่ผู้ใช้เองก็สามารถพิมพ์หรือสั่งงานอะไรก็ได้ด้วยคำสั่งที่เปิดกว้างกว่า และฝั่งระบบเองที่แม้จะได้รับคำสั่งเดิม AI ก็อาจตอบสนองไม่เหมือนเดิมในแต่ละครั้ง

นี่เลยเป็นอะไรที่ท้าทายมาก ๆ เพราะเราไม่ออกแบบเพื่อ ‘user flow’ ที่มันแน่นอนคาดเดาได้อีกต่อไปแล้ว ดังนั้นหาก PM พยายามออกแบบประสบการณ์การใช้งานโดยฝืนใช้รูปแบบแบบเก่าทั้ง ๆ ที่มันไม่ได้เหมือนกัน ก็อาจนำไปสู่ความผิดพลาดต่าง ๆ ที่เราไม่สามารถควบคุมได้ และอาจไปทำลายความน่าเชื่อถือของผลิตภัณฑ์ด้วย

2. ใจร้อนให้อำนาจกับ AI เร็วเกินไป

นอกจากความไม่แน่นอนแล้ว อีกหนึ่งกับดักคือเรื่อง ‘Agency’ ในบริบทนี้มันคือว่าความสามารถของระบบ AI ในการ ลงมือทำ ตัดสินใจ หรือดำเนินงานแทนผู้ใช้

แต่ประเด็นที่เราอาจมองข้าม และต้องระมัดระวังคือ ‘ความใจร้อน’ ในการมอบอำนาจการตัดสินใจให้ AI เร็วเกินไป ไม่ว่าจะเป็นการที่ทีมรีบไปให้ระบบ AI มี agency สูงตั้งแต่แรก แต่ยังไม่เคยทดสอบก่อนเลยว่าจะเป็นยังไงถ้ามันทำพลาดขึ้นมา

ยิ่งถ้าเป็นระบบที่จะส่งคำตอบให้เองอัตโนมัติ หรือเกี่ยวข้องกับเรื่องที่มีความละเอียดอ่อนมาก ๆ เช่นเรื่องเงิน ถ้า AI ตัดสินใจผิดพลาดในเรื่องสำคัญ ๆ ความเสียหายนั้นก็อาจจะทำให้ users เราเข็ดขยาด เสียความเชื่อมั่นและไม่อยากใช้ Products เราอีกเลยก็ได้

Every time you give an AI system more agency, you give up some control.

เฟรมเวิร์ก CC/CD

The Continuous Calibration/Continuous Development framework | Skooldio

The Continuous Calibration/Continuous Development framework – AISHWARYA NARESH REGANTI AND KIRITI BADAM

เพื่อแก้ปัญหาต่าง ๆ เหล่านั้น Aishwarya และ Kiriti ก็ได้พัฒนาเฟรมเวิร์กหนึ่งที่มีชื่อว่า CC/CD (Continuous Calibration / Continuous Development) ขึ้นมา

CC/CD ถูกออกแบบมาเพื่อ ปิดรูรั่วของทั้งสองปัญหาที่เล่ามาด้านบน

ลดความไม่แน่นอนของระบบ (non-determinism) ผ่านการออกแบบ ติดตามเฝ้าดูระบบอย่างใกล้ชิด
ทำให้การที่ระบบจะมี agency เป็นการค่อย ๆ ได้มา ไม่ใช่มอบให้ระบบทั้งหมดในครั้งเดียว

หน้าตาของเฟรมเวิร์ก CC/CD ก็จะมีความคล้ายกับเลข 8 เหมือนสัญลักษณ์ Infinity ในเฟรมเวิร์กนี้คนสร้างโปรดักต์ก็จะทำงานเป็นลูปที่ต่อเนื่อง ทั้ง development (CD) และ calibration (CC)

โดยย่อแล้วเฟรมเวิร์กนี้ก็เริ่มจากการกำหนดขอบเขตของปัญหา, ออกแบบระบบ (design the architecture) และ ตั้งการประเมินผลเพื่อให้ non-determinism หรือ ความไม่แน่นอนนั้นยังถูกควบคุมดูแลอยู่

เราจะเริ่มจากฟีเจอร์ที่ low-agency และ high-control ก่อน แล้วค่อย ๆ ปรับเพิ่มขึ้นเมื่อเราเห็นและพิสูจน์ได้แล้วว่าระบบมันจะสามารถรับได้มากขึ้น จากนั้นค่อย deploy ซึ่งก็จะเป็นการ transtion ไปสู่ขั้นต่อไปด้วย

ทุกครั้งที่ทีมพัฒนาและปรับวนครบหนึ่งรอบ ระบบจะค่อย ๆ ได้รับอิสระในการตัดสินใจมากขึ้นทีละนิด ๆ

เมื่อทำแบบนี้ซ้ำไปเรื่อย ๆ วงจรนี้มันก็จะเริ่มทำงานเหมือน ‘flywheel’ ฟีดแบ็กกลับมาหาทีมเร็วขึ้น ความเชื่อมั่นเพิ่มขึ้น ตัวโปรดักต์เองก็จะแข็งแรงมากขึ้นในทุกเวอร์ชันที่ปล่อยออกมาด้วย

อยากเป็น PM ที่เก่งในการทำ AI Products

อีกสิ่งหนึ่งที่สำคัญไม่แพ้กันและส่งผลต่อการพัฒนาโปรดักต์ AI ให้สำเร็จก็หนีไม่พ้น ‘ตัวเราเอง’ แล้วถ้าเราอยากพัฒนาตัวเองให้เป็น Product Manager ที่เก่งขึ้น มีอะไรที่เราควรพัฒนาบ้าง?

นอกจากการมีความรู้เชิงเทคนิค ที่คุณอาจต้องมีความเข้าใจในเรื่อง Algorithms / Data Pipelines และ Machine Learning เพื่อสร้างโปรดักต์ AI ที่ดีแล้ว

Aishwarya มองว่าเรื่อง Design, Judgement และ Taste ในงานก็สำคัญ

ยิ่งในยุคนี้ที่ AI ทำให้การเขียนโค้ดหรือการสร้างฟีเจอร์กลายเป็นเรื่องง่ายและราคาถูกลง การเรียนรู้และการพัฒนาทักษะพื้นฐานเองก็ทำได้เร็วขึ้น เมื่อผ่านช่วงเริ่มต้นของการทำงานไป งานของทุกคนก็จะค่อย ๆ กลายมาเป็นเรื่องของรสนิยม การตัดสินใจ และมุมมองที่เป็นเอกลักษณ์ของแต่ละคนมากขึ้น ดังนั้นอีกสิ่งที่สำคัญจึงเป็นการทำความเข้าใจองค์ประกอบเหล่านั้นและคิดว่าเราจะนำมันเข้ามาช่วยสร้างคุณค่าให้กับงานหรือ Products ได้ยังไง

สุดท้ายนี้ สิ่งสำคัญที่สุดอาจไม่ใช่ทักษะทางเทคนิค แต่คือความอดทน หรือที่คุณ Kiriti ใช้คำว่า “pain is the new moat” การมีความอึดพอที่จะผ่านความเจ็บปวดของการเรียนรู้ การลงมือทำ การลองผิดลองถูก และการทำความเข้าใจว่าอะไรเวิร์ก อะไรไม่เวิร์ก

ระหว่างที่เราเผชิญกับความเจ็บปวด พยายามหา approach และแก้ปัญหามันก็จะกลายเป็นเหมือน moat หรือปราการของเรา ที่จะมีประโยชน์มากโดยเฉพาะสำหรับการสร้าง AI products ที่มันคาดเดาล่วงหน้าได้ยาก และ PM ต้องรับมือความท้าทายต่าง ๆ