สรุปจากคลิป ดูคลิปต้นฉบับ

AI ทำให้ส่งงานไวขึ้น แต่ทำไมซอฟต์แวร์อาจแย่ลงกว่าเดิม

ประเด็นที่น่าสนใจที่สุดจากคลิปของช่อง AI Engineer ที่คุยกับ Tuomas Artman CTO และผู้ร่วมก่อตั้ง Linear คือเรื่องที่หลายบริษัทกำลังมองข้ามไปพร้อมกัน นั่นคือ AI ทำให้ “สร้างได้เร็ว” แต่ไม่ได้แปลว่า “สร้างสิ่งที่ควรสร้าง” ได้ดีขึ้นเสมอไป

สิ่งที่ Tuomas พูดชัดมากคือ เมื่อเครื่องมือใหม่ทำให้ทีมส่ง feature ได้แทบจะทันที ความเสี่ยงใหม่จึงไม่ใช่ทำช้าเกินไป แต่คือ “ตอบรับทุกอย่าง” จน product ค่อยๆ รก สับสน และเสียคุณภาพโดยไม่รู้ตัว สำหรับเจ้าของธุรกิจและคนทำงาน นี่ไม่ใช่เรื่องของ developer อย่างเดียว แต่คือเรื่องของการตัดสินใจว่าเราจะใช้ AI เพื่อเร่งการเติบโต หรือเร่งความยุ่งยากให้ลูกค้า

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

สารบัญ

• Step 1: เริ่มจากยอมรับก่อนว่า AI ไม่ได้ทำให้ทุกอย่างดีขึ้นอัตโนมัติ
• Step 2: แยกให้ออกระหว่าง “สร้างได้” กับ “ควรสร้าง”
• Step 3: ใช้ AI กับงานที่ไม่ต้องพึ่ง “รสนิยม” ก่อน
• Step 4: เข้าใจให้ชัดว่า “คุณภาพ” วัดยาก แต่สำคัญมาก
• Step 5: สร้างวัฒนธรรมที่ทำให้คน “มองเห็น” คุณภาพ
• Step 6: เลิกดองปัญหา ด้วยแนวคิด Zero Bug Policy
• Step 7: อย่าคาดหวังว่า AI จะมี “taste” แทนคนได้แล้ว
• Step 8: เปลี่ยนทีมให้ใกล้ลูกค้ามากขึ้น เพราะระยะถัดไปคนทำงานต้องเป็น product-minded
• Step 9: ถ้าเราไม่ใช่ developer จะเอาแนวคิดนี้ไปใช้ยังไง
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เริ่มจากยอมรับก่อนว่า AI ไม่ได้ทำให้ทุกอย่างดีขึ้นอัตโนมัติ

แก่นของบทสนทนานี้คือแนวโน้มที่กำลัง “ไปผิดทาง” เพราะเมื่อ AI agent ทำงานได้เก่งขึ้น บริษัทจะเริ่มมีแรงจูงใจให้ส่งสิ่งต่างๆ ออกไปทันที ไม่ว่าจะเป็น feature request จากลูกค้า หรือไอเดียที่เพิ่งผุดขึ้นในหัว

ปัญหาคือ product ที่ดีไม่เคยเกิดจากการตอบรับทุกอย่าง Steve Jobs เคยพูดว่าผลิตภัณฑ์ที่ดีเกิดจากการตอบ “ไม่” กับ 999 เรื่อง แล้วตอบ “ใช่” กับเรื่องเดียว แนวคิดนี้ยิ่งสำคัญกว่าเดิมในวันที่ต้นทุนการลงมือทำลดลงมาก

ถ้าแปลเป็นภาษาธุรกิจง่ายๆ AI ทำให้ “ต้นทุนการสร้าง” ลดลง แต่ไม่ได้ลด “ต้นทุนของการตัดสินใจผิด” เลยแม้แต่น้อย บางกรณีต้นทุนยิ่งสูงขึ้นด้วยซ้ำ เพราะเราสามารถปล่อยของที่ไม่ควรมีออกไปได้เร็วกว่าเดิม

สำหรับธุรกิจไทย ภาพนี้เห็นได้ชัดมาก เช่น บริษัทที่รีบใส่ chatbot, dashboard, automation, ระบบแจ้งเตือน หรือฟังก์ชัน AI assistant เข้าไปทุกหน้าจอ เพราะคิดว่าลูกค้าต้องชอบ สุดท้ายลูกค้ากลับงง ใช้งานยากขึ้น และทีมภายในต้องคอยอธิบายวิธีใช้มากกว่าเดิม

Step 2: แยกให้ออกระหว่าง “สร้างได้” กับ “ควรสร้าง”

Tuomas ชี้ประเด็นสำคัญมากว่า ที่ผ่านมาโลกซอฟต์แวร์มีตัวกรองตามธรรมชาติอยู่แล้ว คือการพัฒนาระบบเคยใช้เวลานานและเปลืองแรงมาก ทีมจึงต้องคิดก่อนทำ แต่เมื่อ AI ลดภาระฝั่ง engineering ลง ตัวกรองนี้หายไป

ผลคือหลายทีมจะเผลอข้ามขั้นตอนที่สำคัญที่สุดไป นั่นคือการทำความเข้าใจปัญหาจริงของลูกค้า

ที่ Linear แม้จะใช้ AI และส่งงานได้เร็วขึ้น แต่แนวทางไม่ได้เปลี่ยนเป็น “ขออะไรมาก็ทำ” ทีมยังคงบอกปัดคำขอจำนวนมากเหมือนเดิม เพราะสิ่งที่ต้องทำก่อนคือ:

• เก็บ feedback จากลูกค้าหลายแหล่ง
• หาว่าแต่ละคำขอสะท้อน “ปัญหาอะไร”
• จัดกลุ่มคำขอที่จริงๆ แล้วมีรากปัญหาเดียวกัน
• ออกแบบทางแก้ที่เหมาะกับทั้งกลุ่ม ไม่ใช่ตอบสนองเป็นรายคำขอ

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

ตัวอย่างเช่น ลูกค้าอาจบอกว่าอยากได้รายงานเพิ่มอีก 10 แบบ แต่ปัญหาจริงคือเขาหาข้อมูลสำคัญไม่เจอใน 30 วินาทีแรก ถ้าเรารีบเพิ่มรายงาน เราอาจแก้ปลายเหตุและทำให้ระบบซับซ้อนกว่าเดิม

Step 3: ใช้ AI กับงานที่ไม่ต้องพึ่ง “รสนิยม” ก่อน

อีกมุมที่น่าสนใจคือ Tuomas ไม่ได้ปฏิเสธ AI ตรงกันข้าม เขายอมรับชัดว่าบางส่วนของงานพัฒนาเร็วขึ้นมาก โดยเฉพาะการแก้บั๊ก

ที่ Linear มีบั๊กประมาณ 10% ที่ AI สามารถรับเรื่อง สร้าง pull request และปล่อยใช้งานได้โดยแทบไม่ต้องมีคนแตะเลย และเขาเชื่อว่าสัดส่วนนี้จะเพิ่มขึ้นเรื่อยๆ ในอีกไม่กี่ปี

นี่เป็นจุดที่ธุรกิจควรคิดแบบเดียวกัน คืออย่าใช้ AI แบบเหวี่ยงแห แต่ให้แยกงานออกเป็น 2 กอง

• กองที่ AI ช่วยได้ดี เช่น งานซ้ำๆ งานตามแพตเทิร์น งานแก้ปัญหาเฉพาะจุด งานสรุปข้อมูล งานตอบคำถามเบื้องต้น
• กองที่ยังต้องใช้คนตัดสิน เช่น การกำหนดทิศทาง product การออกแบบประสบการณ์ลูกค้า การเลือกว่าจะไม่ทำอะไร การวางลำดับความสำคัญ

หลายองค์กรไทยกำลังพลาดตรงนี้ เพราะพยายามให้ AI เข้าไปทำงานระดับ “ตัดสินใจแทน” เร็วเกินไป ทั้งที่จุดคุ้มค่าจริงมักอยู่ที่การเอา AI ไปจัดการงานที่น่าเบื่อ งานหลังบ้าน และงานที่ไม่ต้องใช้ judgment สูง

Step 4: เข้าใจให้ชัดว่า “คุณภาพ” วัดยาก แต่สำคัญมาก

ช่วงที่น่าสนใจมากของบทสนทนาคือเรื่องการวัดคุณภาพ Tuomas ยกตัวอย่างจากประสบการณ์ที่ Uber ซึ่งในช่วงเติบโตหนัก บริษัทมีตัวชี้วัดหลักอย่างรายได้ จำนวนเที่ยว และตัวเลขทางธุรกิจอื่นๆ ที่ทุกคนจับตา

ปัญหาคือสิ่งเหล่านี้ไม่ได้สะท้อนคุณภาพของประสบการณ์ใช้งานเสมอไป

ถ้าบริษัทส่ง feature ใหม่ที่ทำให้รายได้เพิ่ม ตัวเลขก็ดูสวย แต่ไม่มี metric ตัวไหนตอบชัดว่าประสบการณ์ใช้งานนั้น “ลื่นกว่า” “สบายกว่า” หรือ “น่าใช้กว่า” เดิมหรือไม่ และนี่คือกับดักที่อันตรายมาก เพราะคุณภาพมักไม่พังทันที มันค่อยๆ เสื่อม

มุมนี้ใช้ได้กับแทบทุกธุรกิจ ไม่ใช่แค่ซอฟต์แวร์ เช่น

• ร้านค้าออนไลน์อาจวัดแค่ยอดขาย แต่ไม่วัดว่าหน้า checkout ใช้งานลำบากขึ้นหรือไม่
• โรงพยาบาลอาจวัดจำนวนเคส แต่ไม่วัดว่าคนไข้หาข้อมูลยากขึ้นหรือเปล่า
• ธุรกิจบริการอาจวัดจำนวน lead แต่ไม่วัดว่าขั้นตอนหลังบ้านทำให้ลูกค้าหงุดหงิดหรือไม่

Tuomas เสนอภาพที่คมมาก คือคุณภาพไม่ได้กระทบรายได้ทันที “จนกว่าจะกระทบ” และเมื่อถึงวันนั้นมักสายเกินไป เพราะคู่แข่งที่ให้ประสบการณ์ดีกว่าจะค่อยๆ แย่งลูกค้าไปทีละนิด

ถ้าสินค้าคล้ายกัน ราคาใกล้กัน สุดท้ายลูกค้ามักไหลไปหาประสบการณ์ที่ดีกว่า

Step 5: สร้างวัฒนธรรมที่ทำให้คน “มองเห็น” คุณภาพ

หนึ่งในสิ่งที่โดดเด่นที่สุดของ Linear คือสิ่งที่เรียกว่า Quality Wednesdays เป็นการประชุมสั้นทุกสัปดาห์ที่ให้วิศวกรแต่ละคนโชว์ quality fix ที่ตัวเองทำมา

ฟังดูเล็ก แต่จริงๆ เป็นแนวคิดด้านวัฒนธรรมที่ทรงพลังมาก เพราะเป้าหมายไม่ใช่แค่แก้จุดเล็กๆ แต่คือการฝึกให้ทั้งทีมมี “สายตา” ต่อรายละเอียด

จุดเริ่มต้นมาจากเรื่องเล็กมาก เช่น เวลาเอาเมาส์ชี้แล้ว element ควรตอบสนองทันที แต่ตอนเอาเมาส์ออกควรเฟดอย่างนุ่มๆ ราว 150 มิลลิวินาที เพื่อให้ระบบรู้สึกทั้งเร็วและลื่น ถ้าไม่ตั้งใจมอง รายละเอียดแบบนี้จะหายไปง่ายมาก

เมื่อทีมมาช่วยกันส่องจุดเล็กๆ ในหน้าจอเดียว กลับพบปัญหาถึง 35 จุด จากพื้นที่เล็กนิดเดียว นั่นทำให้เห็นว่าถ้า UI เล็กๆ ยังมีจุดหลุดมากขนาดนี้ ทั้ง product ก็น่าจะมีปัญหาเล็กๆ ซ่อนอยู่อีกเป็นพัน

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

สำหรับธุรกิจทั่วไป เราอาจไม่ต้องทำ Quality Wednesdays แบบเดิมเป๊ะ แต่เอาแนวคิดไปใช้ได้ เช่น

• ให้ทีมหน้าร้านลองสวมบทลูกค้าแล้วหาจุดติดขัดทุกสัปดาห์
• ให้ทีมเซลส์และแอดมินแชร์ปัญหาเล็กๆ ใน workflow ที่ทำให้งานสะดุด
• ให้ทีมบริการลูกค้ารวบรวม “ความหงุดหงิดเล็กๆ” ที่ลูกค้าเจอบ่อย

สิ่งเล็กเหล่านี้รวมกันเป็นภาพจำของแบรนด์ได้มากกว่าที่คิด

Step 6: เลิกดองปัญหา ด้วยแนวคิด Zero Bug Policy

อีกหลักคิดที่น่าหยิบไปใช้มากคือ Zero Bug Policy ของ Linear ซึ่งตีความแบบง่ายๆ คือ ถ้ามีบั๊กเข้ามา ต้องมีคนรับผิดชอบทันที และต้องตัดสินใจทันทีว่าจะซ่อม หรือจะไม่ซ่อม

จุดสำคัญไม่ใช่การบังคับให้ทุกบั๊กต้องถูกแก้ แต่คือห้ามปล่อยให้ปัญหาค้างเป็นกองใน backlog

เหตุผลของ Tuomas คมมาก เขามองว่าอัตราการเกิดบั๊กเป็นเรื่องคงที่ของทุกบริษัทอยู่แล้ว ถ้าปล่อยให้ค้าง 2 เดือน สุดท้ายวันหนึ่งเราก็ต้องกลับมาแก้ทั้งหมดอยู่ดี งั้นทำไมไม่แก้ตอนที่ปัญหายังสดและรู้ต้นตอง่ายกว่า

ที่ Linear เคยหยุดทำ feature ใหม่ประมาณ 3 สัปดาห์ เพื่อเคลียร์บั๊กให้เหลือศูนย์ จากนั้นยึดกติกาว่าบั๊กทุกอันต้องถูกจัดการภายใน 7 วัน และส่วนใหญ่เสร็จในไม่กี่ชั่วโมง

มุมนี้ใช้กับธุรกิจนอกสายเทคได้เหมือนกันมาก เช่น

• คอมเมนต์ลูกค้าที่บอกว่าระบบจ่ายเงินติดขัด
• งานเอกสารที่ผิดรูปแบบซ้ำๆ
• ขั้นตอนอนุมัติที่ทำให้ลูกค้าต้องรอนาน
• คำถามเดิมที่ทีม support ต้องตอบซ้ำทุกวัน

ทั้งหมดนี้คือ “บั๊กของธุรกิจ” ถ้าเราปล่อยค้างเพราะมัวแต่ทำของใหม่ วันหนึ่งมันจะพอกเป็นต้นทุนแฝง ทั้งในรูปเวลาคนทำงาน ความหงุดหงิดของลูกค้า และโอกาสที่เสียไป

Step 7: อย่าคาดหวังว่า AI จะมี “taste” แทนคนได้แล้ว

ช่วงที่ชัดเจนและตรงไปตรงมาที่สุดในบทสนทนาคือ Tuomas บอกว่า AI ยัง “ไม่รู้สึก” และ “ไม่มีรสนิยม” นี่อาจเป็นประโยคที่หลายคนไม่อยากได้ยิน เพราะตลาดตอนนี้ชอบขายภาพว่า AI จะออกแบบ เขียนโค้ด และสร้างประสบการณ์ใช้งานได้ครบวงจร

แต่ข้อโต้แย้งของเขาน่าสนใจมาก AI อาจทำทุกขั้นตอนเชิงกลไกได้ เช่น สร้าง animation, วาง UI, เขียน unit test, ปรับ code structure แต่ยังไม่เข้าใจว่าผู้ใช้ “รู้สึก” ยังไงเมื่อระบบตอบสนองช้าไป 2 วินาที หรือ animation ดูแข็ง ดูแปลก ดูไม่เป็นธรรมชาติ

พูดอีกแบบ AI รู้ข้อมูล แต่ยังไม่รู้ความรู้สึกของประสบการณ์

นี่สำคัญกับเจ้าของธุรกิจมาก เพราะหลายครั้งเราอาจเผลอคิดว่า ถ้า AI สร้าง landing page, โฆษณา, บทสนทนา, หน้าเว็บ, หรือ flow บริการได้เร็ว ก็แปลว่าพร้อมใช้แล้ว แต่ของที่ “ดูครบ” ไม่ได้แปลว่า “ดูดี” และของที่ “ใช้งานได้” ไม่ได้แปลว่า “น่าใช้”

มุมที่เห็นต่างเล็กน้อยคือ แม้ AI ยังไม่มี taste แบบมนุษย์ แต่ก็ไม่ได้แปลว่าใช้กับงานประสบการณ์ลูกค้าไม่ได้เลย หากใช้ในบทบาทผู้ช่วยสร้าง draft, ช่วยเปรียบเทียบทางเลือก, ช่วยเร่ง iteration มันยังมีประโยชน์มาก เพียงแต่ขั้นตอนตัดสินสุดท้ายยังควรเป็นหน้าที่ของคนที่เข้าใจลูกค้าจริง

Step 8: เปลี่ยนทีมให้ใกล้ลูกค้ามากขึ้น เพราะระยะถัดไปคนทำงานต้องเป็น product-minded

Tuomas มองไปข้างหน้าว่า เมื่อ AI เก่งขึ้น งานเชิงเทคนิคที่เป็นการ “ต่อท่อ” หรือทำงานตามรูปแบบเดิมๆ จะถูกลดความสำคัญลง คนทำงานจึงต้องขยับมาเป็น product engineer มากขึ้น คือเข้าใจลูกค้า เข้าใจปัญหา และตัดสินใจได้ว่าอะไรคือประสบการณ์ที่ดี

แม้คำนี้จะมาจากโลกซอฟต์แวร์ แต่สำหรับธุรกิจทั่วไป ความหมายแทบไม่ต่างกัน นั่นคือคนทำงานทุกฝ่ายควรเข้าใจลูกค้าให้มากกว่าเดิม ไม่ใช่ทำงานแค่ตามที่หัวหน้าสั่ง หรือทำตาม checklist เดิม

ที่ Linear มีการออกแบบวัฒนธรรมให้เรื่องนี้เกิดขึ้นจริง เช่น

• จ้างคนที่ใส่ใจคุณภาพตั้งแต่ต้น
• ให้ผู้สมัครทำงานทดลองจริงเป็นสัปดาห์ เพื่อดูวิธีคิดตั้งแต่ต้นจนจบ
• เปิดให้ทีมเข้าถึง feedback ของลูกค้าโดยตรง
• บันทึกการคุยกับลูกค้าและทำให้ค้นหาย้อนหลังได้

นี่เป็นประเด็นที่หลายองค์กรไทยน่าคิดมาก เพราะปัญหาคลาสสิกคือคนทำงานอยู่ไกลจากลูกค้าเกินไป ฝ่ายปฏิบัติการไม่เคยฟังลูกค้าจริง ฝ่ายการตลาดไม่เห็นปัญหาหลังบ้าน ฝ่ายบริหารเห็นแค่รายงานสรุป เมื่อเป็นแบบนี้ AI จะยิ่งทำให้ทุกอย่างเร็วขึ้นบนความเข้าใจที่ผิด

ถ้าอยากใช้ AI ให้เกิดผลดีจริง องค์กรต้องทำให้คนในทีมสัมผัสเสียงของลูกค้าโดยตรงมากขึ้นก่อน

Step 9: ถ้าเราไม่ใช่ developer จะเอาแนวคิดนี้ไปใช้ยังไง

แม้บทสนทนานี้จะมาจากโลกของ CTO และ product team แต่เนื้อแท้ของมันคือเรื่องการบริหารงาน การออกแบบบริการ และการตัดสินใจในองค์กร ซึ่งใช้ได้กับแทบทุกธุรกิจ

สรุปออกมาเป็นภาษาคนทำงานทั่วไปได้แบบนี้

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

ถ้าให้สรุปเป็น POV เดียวจากคลิปนี้ มันคือประโยคนี้เลย: AI ทำให้ความเร็วกลายเป็นของที่หาได้ทั่วไป แต่รสนิยม การตัดสินใจ และความใส่ใจรายละเอียด จะกลายเป็นความได้เปรียบใหม่

Actionable Insights

• อย่าทำทุกอย่างที่ AI ทำได้ แยกก่อนว่างานไหนควรเร่ง และงานไหนต้องคิดให้ลึกก่อนลงมือ
• เปลี่ยนคำขอของลูกค้าให้เป็นการค้นหาปัญหาจริง ก่อนเพิ่ม feature หรือ workflow ใหม่ทุกครั้ง
• ตั้งรอบตรวจ “จุดหงุดหงิดเล็กๆ” ทุกสัปดาห์ ไม่ว่าจะเป็นหน้าเว็บ ระบบขาย หรือขั้นตอนบริการ
• หยุดดองปัญหา ถ้ามีเรื่องเดิมที่ทีมต้องแก้ซ้ำ แปลว่าควรรีบจัดการ ไม่ใช่รอให้ว่างก่อน
• ให้ทีมได้ยินเสียงลูกค้าโดยตรง ต่อให้ใช้ AI มากแค่ไหน ถ้าไม่เข้าใจลูกค้า งานที่ออกมาก็มีโอกาสหลงทิศ

Troubleshooting

ปัญหา: ใช้ AI แล้วงานออกมาเร็ว แต่ลูกค้าบอกว่าใช้งานยากขึ้น

สาเหตุ: รีบเพิ่มสิ่งที่ลูกค้าขอ โดยไม่หาปัญหาจริงที่อยู่ข้างใต้

วิธีแก้: รวบรวมคำขอที่คล้ายกัน จัดกลุ่มปัญหา แล้วค่อยออกแบบทางแก้ที่ตอบโจทย์ร่วม

ปัญหา: ทีมมัวแต่ทำของใหม่จนปัญหาเก่าค้างเต็มไปหมด

สาเหตุ: ไม่มีระบบจัดลำดับความสำคัญให้เรื่องผิดพลาดถูกแก้ทันที

วิธีแก้: ตั้งกติกาว่าปัญหาที่กระทบลูกค้าต้องมี owner ภายในวันเดียว และต้องตัดสินใจทันทีว่าจะซ่อมหรือปิดเหตุผลไว้ชัดเจน

ปัญหา: วัดแต่ยอดขายหรือ output แล้วคิดว่าทุกอย่างโอเค

สาเหตุ: ตัวเลขธุรกิจไม่ได้บอกว่าประสบการณ์ลูกค้ากำลังแย่ลงหรือไม่

วิธีแก้: เพิ่มการติดตามเสียงลูกค้า เช่น ข้อร้องเรียนซ้ำๆ เวลาที่ใช้ต่อขั้นตอน และจุดที่ลูกค้าหลุดบ่อย

ปัญหา: ทีมใช้ AI ช่วยสร้างงาน แต่คุณภาพไม่สม่ำเสมอ

สาเหตุ: AI ทำงานตามรูปแบบได้ แต่ยังไม่ตัดสินเรื่องความลื่น ความสวย และความเป็นธรรมชาติได้ดีพอ

วิธีแก้: ให้ AI ทำ draft หรือ first pass แล้วให้คนรีวิวขั้นสุดท้าย โดยเฉพาะงานที่ลูกค้าสัมผัสโดยตรง

ปัญหา: คนในทีมไม่เข้าใจลูกค้า แม้มีข้อมูลเยอะ

สาเหตุ: feedback ถูกกองอยู่กับบางฝ่าย และไม่ไหลไปถึงคนที่ลงมือทำงาน

วิธีแก้: ทำระบบแชร์ feedback แบบเปิด อ่านง่าย ค้นง่าย และหยิบมาใช้ประกอบการตัดสินใจประจำสัปดาห์

การต่อยอด

• ทดลองทำ “Quality Hour” รายสัปดาห์ในทีมของเรา ไม่จำเป็นต้องเป็นสายเทค แค่ให้ทุกคนหาจุดสะดุดในประสบการณ์ลูกค้าแล้วเสนอวิธีแก้
• ทำแผนที่ customer journey ใหม่ โดยวงจุดที่ AI ควรช่วย และจุดที่คนยังต้องเป็นผู้ตัดสินหลัก
• สร้าง backlog แบบใหม่ แยก “ของใหม่ที่อยากทำ” ออกจาก “ปัญหาที่ลูกค้าเจอจริง” เพื่อไม่ให้เรื่องสำคัญถูกกลบ

สรุป Checklist ทั้งหมด

• ☐ ยอมรับก่อนว่า AI เพิ่มความเร็ว แต่ไม่ได้เพิ่ม judgment ให้อัตโนมัติ
• ☐ แยกให้ออกระหว่างสิ่งที่ “ทำได้” กับสิ่งที่ “ควรทำ”
• ☐ ใช้ AI กับงานซ้ำๆ และงานแก้ปัญหาเฉพาะจุดก่อน
• ☐ อย่าวัดแค่ตัวเลขธุรกิจ ให้มองคุณภาพประสบการณ์ลูกค้าควบคู่กัน
• ☐ สร้างรอบตรวจจุดสะดุดเล็กๆ เป็นประจำ
• ☐ เลิกดองปัญหาและตั้ง owner ให้เรื่องที่กระทบลูกค้าทันที
• ☐ อย่าคาดหวังว่า AI จะมี taste แทนคนได้แล้ว
• ☐ ทำให้ทีมได้ยินเสียงลูกค้าโดยตรงมากขึ้น
• ☐ ฝึกคนในทีมให้คิดแบบ product-minded ไม่ใช่ทำตามคำสั่งอย่างเดียว
• ☐ ทบทวนทุกครั้งว่าเราใช้ AI เพื่อสร้างคุณค่า หรือแค่สร้างของได้มากขึ้น

ท้ายที่สุด สิ่งที่บทสนทนาระหว่าง AI Engineer, Tuomas Artman และ Gergely Orosz สะท้อนออกมาชัดมากคือ ระยะถัดไปไม่ได้เป็นของทีมที่ทำได้เร็วที่สุดเพียงอย่างเดียว แต่เป็นของทีมที่ยังรักษามาตรฐานการเลือก การออกแบบ และการใส่ใจลูกค้าไว้ได้ แม้เครื่องมือจะเร่งทุกอย่างให้เร็วขึ้นก็ตาม

ในวันที่ AI ทำให้ “การลงมือทำ” กลายเป็นของง่าย สิ่งที่มีค่ากว่าเดิมคือ “รสนิยมในการตัดสินใจ” และนี่อาจเป็นความต่างระหว่างธุรกิจที่โตแบบยั่งยืน กับธุรกิจที่เต็มไปด้วย feature แต่ลูกค้าไม่อยากกลับมาใช้อีก