ยุคที่เสกอะไรก็ได้ PM ยังจำเป็นไหม?

โจทย์ของคนทำงานด้าน product ในตอนนี้คือ ไม่ใช่คิด feature ไม่ออก แต่คือคิดออกมาเป็นล้าน แล้วดัน vibe code ออกมาได้เร็ว (เกินไปมาก ๆ)

ทีม finetunes อินเรื่องดนตรี เรื่องเสียง ไอเดียเลยมาเรื่อย ๆ ทั้ง feature หน้าบ้านหลังบ้าน (ส่วนใหญ่เป็น Delightful feature ทั้งนั้นแหละ ไม่ใช่ Critical Path) อยากใส่ (ยัด) feature เข้าไปให้หมด เลยต้องคอยปรามตัวเองว่า อันนี้ user อยากได้จริงรึเปล่า หรือเราอยากทำเอง . . .

Less is more และ Keep it lean เป็นสิ่งที่ผมบอกน้องในทีม และต้องคอยเตือนตัวเองอยู่เรื่อย ๆ เหมือนกัน (สอนคนอื่นน่ะง่าย ทำเองนี่อีกเรื่อง)

ยิ่งยุคนี้ที่ AI ทำให้ "Make it exist" ง่ายแบบแทบจะเสกได้ เรื่องนี้ยิ่งสำคัญ แล้วก็มีคำถามที่ได้ยินบ่อยขึ้นเรื่อย ๆ ว่า ในยุคที่เสกอะไรก็ได้ PM ยังจำเป็นอยู่ไหม?

PM ตามสั่ง

PM, Product Manager เป็นหนึ่ง role ที่ฮอตฮิต เพราะ tech world (แลดู) เป็นโลกที่เงินดี ดูน่าสนุก และงานน่าตื่นเต้น, PM เป็น non-tech role ที่เปิดให้คนที่ไม่มีพื้นฐานสายเทคเข้ามาทำงานได้ โดยไม่ต้องมี hard skill ด้าน technical ชัด ๆ เมื่อเทียบกับ developer, QA หรือ designer คน non-tech เลยกระโดดเข้ามาทำกันเยอะ

ถ้ามองภาพกว้างสุด ๆ งานใน classic software development cycle แบ่งเป็น

1. การวางแผน (requirements gathering and planning)
2. การออกแบบให้เห็นภาพและจับต้องได้ (design and prototyping)
3. การเขียนโค้ด ลงมือรังสรรค์สิ่งที่ใช้งานได้จริง (coding and development)

งานชิ้นเดียวกัน แต่ละขั้นตอนใช้ cost และ resource มากกว่าขั้นก่อนหน้า เลยต้อง sign off ก่อนส่งต่อ เพราะการดักจับข้อผิดพลาดหรือการเปลี่ยน scope ตั้งแต่เนิ่น ๆ ประหยัดทั้งต้นทุนและเวลา

การทำงานแบบนี้ทำให้คนลงมือทำอย่าง designer และ developer เป็นคอขวดของกระบวนการ ใน software house เลยมักมี Project Manager (ย้ำว่าคือ Project Manager นะ ไม่ใช่ Product Manager) หนึ่งคนดูแลหลาย ๆ project บางคนดูเป็น 10 project พร้อมกัน

ถ้าเป็น project ผมว่าเข้าใจได้ แต่ถ้าเป็น product ใน Product Company อันนี้ผมว่าไม่ควรเป็นอย่างยิ่ง เพราะเค้าไม่สามารถ focus ได้ และไม่มีเวลา obsess กับมันเพื่อผลักดันให้ product เติบโตได้ พอ Product Manager ถูกใช้งานแบบ Project Manager ดูทีละสิบ product นั่นแหละ PM ตามสั่ง แบบร้านอาหารตามสั่งเลย ลูกค้าสั่งอะไรก็ทำตามนั้น ไม่มีเวลาขุดว่า requirement นี้ควรมีอยู่จริงหรือเปล่า

เมื่อการสร้างไม่ใช่คอขวดอีกต่อไป

ช่วงนี้ generative AI เข้ามา disrupt งานทุก role สิ่งที่ AI ปลดล็อกให้เห็นชัดที่สุดคือทุกส่วนทำงานเร็วขึ้น อยากเสกอะไรก็ได้ ถ้าคนใช้เทพหน่อย ทำเป็นทุก skill ก็ครบจบได้ในคนเดียว เป็น one person business ได้เลยด้วยซ้ำ (แน่นอนว่า non-dev ที่ใช้ AI เขียนโค้ด ก็ยังสู้ dev ที่ใช้ AI เขียนโค้ดไม่ได้หรอก เพราะขาด fundamental ส่วน one person business ก็ไม่ได้ต้องเป็นเทพทุกเรื่อง แค่ต้อง know enough to be dangerous)

รูปแบบการทำงานหนึ่งใน tech team ณ สมัยนี้ คือ PM ทำ prototype ขึ้นมาเองเลย ส่งให้ dev ทำต่อ แล้ว designer ค่อยมาตามเก็บตาม polish (non-designer + AI ก็สู้ designer + AI ไม่ได้เหมือนกัน) ได้งานที่สมบูรณ์ใน cycle ที่สั้นมาก ๆ

ทีนี้มันกลับกัน คนเริ่มมองว่า role PM ยังจำเป็นไหม? เมื่อก่อนเราต้อง sign off ทีละขั้นตอน เพื่อไม่ให้ต้องไปแก้ scope ที่ปลายทางเพราะต้นทุนแพงมาก พอ AI เข้ามา ต้นทุนของการปรับ scope หรือการ iterate นั้นลดลงมาก ๆ ทำงานออกมาให้ดูได้หลาย ๆ version หรืออยากมี feature อะไรก็ใส่เข้าไปให้หมดได้เลย

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

เรื่องนี้ทำให้ผมนึกถึงสิ่งที่ Elon Musk เรียกว่า "The Algorithm" ห้าขั้นตอนที่เขาใช้สร้างของ (เล่าไว้ใน biography ฉบับ Walter Isaacson)

ลำดับสำคัญมาก Elon บอกว่าความผิดพลาดที่เจอบ่อยที่สุดของวิศวกรเก่ง ๆ คือการ optimize สิ่งที่ไม่ควรมีอยู่ตั้งแต่แรก AI ช่วยเราเรื่องขั้นที่ 3 ถึง 5 ได้เยอะมาก แต่ขั้นที่ 1 กับ 2 ยังเป็นของมนุษย์ และถ้าเราข้ามสองขั้นนี้ไป AI ก็จะช่วยให้เรา optimize สิ่งที่ไม่ควรมีอยู่ได้เร็วกว่าที่เคย

ขั้นที่ 1 กับ 2 นี่แหละคืองานของ PM วางแผน ออกแบบ และตัดสินใจว่า product ควรเป็นแบบไหน ต้องอาศัยทั้ง Product Taste ที่ดี การคุยกับลูกค้า การเก็บ feedback อย่างเป็นระบบ และการตีโจทย์ให้แหลมคม ซึ่ง PM ตามสั่งที่ดูสิบ product พร้อมกันคงไม่มีเวลาทำแน่ ๆ (ต่อให้มีเวลาก็ไม่มีพลังและ focus พอ)

Curator

ออกจาก tech world ไปวงการ art กันบ้าง (แบบ fine arts เลยนะ ไม่ใช่ designer ที่ทำตามโจทย์) เวลาเราไปเดิน gallery หรือ museum เราจะสังเกตว่าการจัดแสดงมีรูปแบบ มีความสอดคล้อง มีความสัมพันธ์ และเล่าเรื่องบางอย่างอยู่ ปกติมักจะมี theme (ถึงผมจะยัง appreciate งานศิลปะได้ไม่ลึกเท่าไหร่ ซึ่งเคยเขียนไว้แล้ว แต่อันนี้ยังพอดูออก)

ลองเปรียบ interaction และ feature เป็นชิ้นงานที่ถูกจับมาจัดแสดง ใน gallery ขนาดกลางที่ไม่ได้รวยอู้ฟู่หรือมีงบไม่จำกัด จะมีคนคนหนึ่งคอยจัดหา คัดเลือก และจัดวางชิ้นงานที่จะนำมาแสดง คนนั้นคือ "Curator"

Curator ต้องสรรหาและคัดเลือกชิ้นงานภายใต้ข้อจำกัดหลาย ๆ อย่าง แล้วเล่าเรื่องให้คนดูเข้าใจ และรู้สึกอะไรบางอย่างกลับไป ข้อจำกัดนี่แหละที่พิสูจน์ฝีมือ ว่าเลือกของมาได้ดีไหม ร้อยเรียงเข้าด้วยกันได้ดีหรือเปล่า PM ก็เช่นกัน ทำงานภายใต้ข้อจำกัด และคัดสรร feature กับ interaction มาให้ product

จริง ๆ แล้ว gallery ไม่ได้เอางานทั้งหมดที่มีออกมาแสดงด้วยซ้ำ งานส่วนใหญ่อยู่ในกรุหรือ archive ในแต่ละ exhibition Curator ต้องเลือกมาแค่หยิบมือเดียวเพื่อจัดแสดง (PM ก็มี backlog เป็นกรุของตัวเองเหมือนกัน)

อาจมีคนแย้งว่า Curator เลือกจากงานที่มีอยู่แล้ว แต่ PM ต้องสร้างของใหม่ ทั้งที่ feature ส่วนใหญ่ก็ remix มาจากของที่เคยมีทั้งนั้น (Nothing is new under the sun) ทั้งคู่เลยคือการเลือกจากทางเลือกมหาศาล แล้วร้อยเรียงให้เหมาะกับสถานที่ ผู้ชม และช่วงเวลา

Gallery ที่รวยเกินไป

พอมาในยุคนี้ ก็เหมือน gallery ถูกปลดล็อกข้อจำกัดเรื่องชิ้นงาน (Welcome to the SaaSpocalypse วันสิ้นโลกของ SaaS ตอนหุ้นซอฟต์แวร์ร่วงกันระนาวช่วงต้นปี 2569 เพราะคนเริ่มเชื่อว่าใครที่พอรู้เรื่องก็ใช้ AI กับ vibe coding สร้างซอฟต์แวร์ที่ต้องการขึ้นมาใช้เองได้)

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

แถมต่อให้ gallery รวยแค่ไหน ทุกชิ้นที่เอาเข้ามาก็ยังต้องมีคนดูแล feature ก็เช่นกัน การสร้างถูกลงก็จริง แต่ไม่ได้ดูแลถูกลงเลย ทุก feature ต้องมีคน maintain ต้องมีคน support และ user ก็ต้องเรียนรู้อีกด้วย

อีกเรื่องที่ลืมไม่ได้คือ การ vibe code แล้ว ship feature ออกมาได้เยอะ ๆ อาจทำให้เราลืมเรื่องโครงสร้างไป best practice กับ infrastructure ยังสำคัญเหมือนเดิม vibe code อาจได้ working prototype ที่ใช้งานได้ก็จริง แต่ถ้าไม่วาง infrastructure ดี ๆ ทุกอย่างจะพังตอนที่เราจะ scale (เหมือน gallery ที่ต่อเติมห้องไปเรื่อย ๆ โดยไม่ดูเสาเข็ม วันที่คนมาเยอะ ตึกก็ทรุด)

แล้วทำไมไม่ใส่ทุกอย่างลงไป แล้วให้ A/B test ตัดสินหละ? เรื่องนี้ดีอยู่แล้ว แต่การจะ test ได้ แปลว่าเราคิดและออกแบบแต่ละห้องมาเรียบร้อยแล้ว เอาห้อง A ไปเทียบกับห้อง B ซึ่งเป็นสิ่งที่ควรทำแน่นอน A/B test คือขั้นที่ 3 มันจะมีความหมายก็ต่อเมื่อเราผ่านขั้นที่ 1 กับ 2 มาแล้ว การสร้าง feature ได้ไม่จำกัดแล้วใส่ทุกอย่างลงไปเป็นอีกเรื่องหนึ่ง มันคือการเอาทุกชิ้นงานมากองไว้ในห้องเดียวกัน

ในยุคที่ AI ทำให้เราสร้าง feature แทบจะอะไรก็ได้ โจทย์ไม่ใช่การทำ feature ให้เยอะที่สุด แต่คือการเลือกสิ่งที่ใช่ แล้วร้อยเรียงให้เข้ากัน และสื่อสารความสัมพันธ์ของมันออกมาให้คนเข้าใจด้วย งานของ Curator ก็คือขั้นที่ 1 กับ 2 นั่นเอง Curator มีหลักการ และที่สำคัญคือมี Taste ในการเลือกชิ้นงาน PM ก็ต้องมี Product Taste ที่ดีเหมือนกัน

product ที่ตอบโจทย์ได้ทุกอย่าง แปลว่าไม่ตอบโจทย์อะไรเลย

ทำน้อยกว่า แต่ใช่กว่า

ตัวอย่างที่ผมชอบคือ Whoop ถ้าเทียบกัน feature ต่อ feature, Whoop แพ้ Apple Watch ขาดลอย เพราะ feature น้อยกว่า ไม่มีจอ ไม่มี notification จะดูเวลายังทำไม่ได้ แต่ Whoop ไม่ได้อยากเป็น smartwatch ตั้งแต่แรก Whoop ตั้งใจเป็นโค้ชสุขภาพที่ติดข้อมือเราตลอด 24 ชั่วโมง ตอบโจทย์เฉพาะคนที่ออกกำลังกายจริงจัง ว่าวันนี้ร่างกายพร้อมแค่ไหน ควรลุยหรือควรพัก การไม่มีจอเลยกลับกลายเป็นจุดแข็ง เพราะใส่ได้ทั้งวันทั้งคืน แบตอยู่ได้ยาว ๆ ไม่มีอะไรมารบกวน ช่วงที่ Apple Watch มาแรง Whoop โดนกดดันให้เพิ่มจอ แต่ Whoop เลือกไม่ทำ ขั้นที่ 2 ของแท้ ตัดสิ่งที่ใคร ๆ ก็คิดว่า wearable ต้องมี

Whoop ทำได้น้อยกว่า และนั่นแหละคือเหตุผลที่คนที่ใช่เลือกมัน

Whoop ไม่ได้อยากเป็น Apple Watch ฉันใด finetunes ก็ไม่ได้อยากเป็น Spotify ฉันนั้น เราเลือกตั้งแต่แรกว่าจะทำเพลงสำหรับธุรกิจ ไม่ทำ personal use นี่คือจอที่เราตัดทิ้ง แต่ถึงจะตัดไปแล้ว ไอเดียก็ยังมาไม่หยุด อย่างการให้ user customize อะไรก็ได้ ฟังดูเจ๋ง แต่เราก็ยังต้องข่มใจตัวเองอยู่เรื่อย ๆ ไม่งั้น feature เราจะรกจนเจ้าของร้านใช้งานไม่ได้

Taste ฝึกได้

dev ต้องหัดเขียนโค้ด รู้จัก tools และเข้าใจหลักการ software architecture ฝั่ง designer ต้องหัดออกแบบ ตีโจทย์ และส่งมอบ UX/UI ส่วน PM ต้องรู้จักตลาด ตี requirement ให้แตก และฝึก Product Taste

แล้ว Product Taste คืออะไร? สำหรับผม มันคือการรู้ว่าเมื่อไหร่ควรพอ เข้าใจปัญหาของลูกค้ามากพอที่จะรู้ว่าควรหรือไม่ควรเพิ่ม feature ไหน ไม่ใช่ stakeholder บอกอะไรก็ใส่ทุกอย่างเข้าไปแบบกำปั้นทุบดิน รู้ว่าอะไรควรหรือไม่ควรอยู่ด้วยกัน เพราะบางอย่างหลักการขัดกันเอง และรู้ว่าจะ introduce feature ยังไงให้คนเข้าใจ Taste นี่แหละที่ทำให้เรารู้ว่าควรตั้งคำถามกับ requirement ไหน และกล้าตัดอะไรทิ้ง (สังเกตว่าผมใช้คำว่า stakeholder แทนคำว่าลูกค้า)

Taste เป็นทักษะที่ฝึกได้ นอกจากการอ่านตำราแล้ว มันมาจากการลอง การเล่น การเห็นเยอะ ๆ จนเริ่มจับได้ว่า combination ไหนเวิร์ค ไหนไม่เวิร์ค ที่ผมว่าช่วยฝึกได้มีประมาณนี้

• เล่น product ให้ครบ flow ไม่ใช่แค่โหลดมาเปิดดูหน้าแรก ลองสมัคร ลองจ่ายเงิน ลองยกเลิก คิดในมุม service design ทั้งเส้นทาง
• เทียบ flow เดียวกันข้ามแอป สิงอยู่ใน Mobbin ดูว่า onboarding ของแอปหมวดเดียวกันห้าแอปต่างกันยังไง แล้วถามว่าทำไม
• ดูแอปที่ไม่ใช่คู่แข่ง แอปข้าม industry ข้ามรูปแบบการใช้งาน ที่มี feature หรือ workflow น่าสนใจ แล้วหยิบ inspiration นั้นมาประยุกต์กับโจทย์ที่เรากำลังพยายามแก้อยู่
• ดูว่าเขาเลือกไม่ทำอะไร เจอ product ที่ชอบใน Product Hunt ลองดูว่ามันตัดอะไรออกไป บ่อยครั้งสิ่งที่ไม่มีบอกอะไรได้มากกว่าสิ่งที่มี
• อ่าน case study ให้หลากหลาย ทั้งที่รุ่งและที่ร่วง
• เอา Taste ไปชนกับลูกค้า Taste ที่ไม่เคยเจอลูกค้าจริงก็เป็นแค่รสนิยมส่วนตัว You are not your customer. Curator จัดนิทรรศการให้ผู้ชม ไม่ได้จัดให้ตัวเองดู

ตัวอย่างที่ผมทำจริงคือการดูแอปที่ไม่ใช่คู่แข่ง ตอนออกแบบ preboarding ของ finetunes แอปดนตรีส่วนใหญ่ตรงไปตรงมา เปิดมาก็เล่นเพลงได้เลย แต่ของเรา personalized เป็นพิเศษ journey เลยยาวกว่า music platform ทั่วไป เวลาทำการบ้านเราเลยไม่ได้ดูแค่แอปเพลง แต่ไปดู onboarding ของแอปหลากหลาย โดยเฉพาะ personalized fitness app ว่าเขาสื่อสารยังไงให้ชัด และทำยังไงไม่ให้คนหนีออกจากแอปไปก่อน

แล้ว dev ที่ Taste ดีหละ? มีแน่นอน แต่โดยธรรมชาติ สองทักษะนี้มักไม่ได้อยู่ในคนคนเดียวกัน dev คือ expert ในการสร้าง PM ถนัดการตีโจทย์และตัดสินใจ เหมือนสถาปนิกที่เป็นวิศวกรด้วยก็คงมี แต่ส่วนใหญ่ไม่ใช่คนเดียวกัน (ถ้าเจอคนแบบนั้น รีบจีบไว้เลย)

และการที่ PM มักเป็นคนนอกที่ไม่ได้มาจากสาย tech ก็มีข้อดีเหมือนกัน เพราะหลุดจากกรอบและข้อจำกัดแบบดั้งเดิมได้ง่ายกว่า (แต่ขอแบบเข้าใจ tech หน่อยนะ จะได้ต่องานกันได้) แต่ก็ต้องยอมรับว่าเส้นแบ่งของทุก role กำลังจางลง ทั้ง dev ทั้ง designer และ PM เอง จะจางไปถึงไหน ผมเองก็ยังไม่แน่ใจ

ลดยากกว่าเพิ่ม

ฟังดูง่ายนะ ตั้งคำถาม แล้วก็ตัด แต่ในชีวิตจริง ส่วนที่ยากที่สุดของขั้นที่ 2 ไม่ใช่การตัดสินใจ แต่คือการบอกคนที่อยากได้ว่า "ไม่"

ทุก feature มีคนอยากได้เสมอ ลูกค้ารายใหญ่ที่ขอมา ทีม sales ที่รับปากไว้แล้ว ผู้บริหารที่เห็นคู่แข่งมี หรือแม้แต่ทีมเราเองที่อยากทำเพราะมันเท่ (ใช่ ผมก็เป็นหนึ่งในนั้น ยุคนี้ใครไม่อยากแปะปุ่ม AI ไว้ทุกหน้าบ้าง) ใส่ให้ internal stakeholder ก็แฮปปี้ ตัดทิ้งก็ต้องมีคนงอน แต่ user ที่ใช้งานจริงไม่ได้แฮปปี้ด้วยนะ ของมันเยอะไปหมด เปลือง cognitive load แล้วสุดท้ายก็ไม่ใช้

แถม AI ยังทำให้พูดคำว่า "ไม่" ยากขึ้นอีก เมื่อก่อนเรายังพอบอกได้ว่า dev ไม่ว่าง ทำไม่ทันหรอก แต่ตอนนี้ใคร ๆ ก็รู้ว่าทำ prototype แป๊บเดียวก็เสร็จ ข้ออ้างนี้เลยใช้ไม่ได้แล้ว

แต่ทำเสร็จเร็ว ไม่ได้แปลว่าต้นทุนไม่เพิ่มนะ feature ที่ใส่เข้าไปแล้วต้องมีคนดูแลไปตลอด ทั้งเวลา ทั้งแรง ทั้ง focus ของทีม คนที่มาขอส่วนใหญ่มองไม่เห็นตรงนี้ เราเลยต้องอธิบายให้ได้ว่า ทำน่ะทำได้ แต่ไม่คุ้มที่จะดูแล หรือมันไม่เข้ากับ product เรา ซึ่งพูดยากกว่าบอกว่าทำไม่ทันเยอะ

นี่แหละที่แยก PM ตามสั่งออกจาก Curator ร้านตามสั่งไม่เคยปฏิเสธออเดอร์ แต่ Curator ปฏิเสธงานดี ๆ อยู่ทุกวัน เพราะมันไม่เข้ากับนิทรรศการ

การจะพูดว่า "ไม่" ได้โดยไม่กลายเป็นคนดื้อ ต้องมีของในมือ เข้าใจปัญหาของลูกค้ามากกว่าคนที่มาขอ มี feedback ที่เก็บมาอย่างเป็นระบบ และอธิบายได้ว่า feature นี้ขัดกับหลักการไหนของ product ไม่ใช่แค่ "ผมไม่ชอบ" (อันนั้นเรียกว่ารสนิยมส่วนตัว ไม่ใช่ Taste)

และ "ไม่" ก็ไม่จำเป็นต้องแปลว่าไม่ตลอดไป หลายครั้งมันแปลว่า "ยังไม่ใช่ตอนนี้" ตัดผิดบ้างก็ไม่เป็นไร Elon ยังบอกเลยว่า ถ้าตัดแล้วไม่ต้องเอากลับมาใส่คืนสักราว 10% แปลว่ายังตัดไม่พอ

เมนูพิเศษ

แล้วถ้า PM อยากลองอะไรที่ใหม่มาก ๆ หละ? ของที่ยังไม่ถูกพิสูจน์ ยังไม่รู้ว่าเพิ่ม value จริงมั้ย หรือคนต้องการจริงหรือเปล่า ถ้าจับมารวมกับ platform หลักเลย ทีมก็ทำงานยากขึ้น ดูแลยากขึ้น ส่วน user ก็เจอของเยอะขึ้นไปอีก ทั้งที่ยังไม่รู้เลยว่ามันมีประโยชน์จริงมั้ย

ลองนึกถึงตอนที่ร้านอาหารจะทดสอบเมนูใหม่ เค้าไม่ได้จู่ ๆ พิมพ์เมนูใหม่ทั้งเล่ม จัดเรียงใหม่ ถ่ายรูปใหม่หมด (ดักคอไว้ก่อน ต่อให้เป็น electronic menu สมัยนี้ ก็ยังต้องจัดเรียงและนำเสนออยู่ดีนะ) เค้าทำเป็นเมนูพิเศษขึ้นมาก่อน แล้วดูผลตอบรับ ถ้าโอเคและดีมาก ๆ ค่อยบรรจุเข้าเป็นเมนูหลัก

ตอนที่ Anthropic ปล่อย Claude Design ออกมาก็เหมือนกัน มันออกมาเป็น research preview ภายใต้ Anthropic Labs ไม่ได้ถูกรวมเข้าไปใน platform หลัก เท่าที่ผมใช้ มันแยกออกมาเลย ใช้แค่ authentication ร่วมกัน ถึง look and feel จะเหมือนกัน แต่จริง ๆ เป็นคนละ platform การส่งงานต่อกันก็ไม่ได้ seamless เป็นการ handover มากกว่า ซึ่งในมุม product development เรื่องนี้ make sense สุด ๆ

เมนูพิเศษคือการทดสอบสมมติฐาน โดยไม่ disrupt core product

ร้านที่คนยอมต่อคิว

แล้ว PM ยังจำเป็นอยู่ไหม? จำเป็นกว่าเดิมด้วยซ้ำ "Make it exist" ตอนนี้ง่ายมาก ๆ AI ทำขั้นที่ 3 ถึง 5 ให้เราเร็วกว่าที่เคย แต่ขั้นที่ 1 กับ 2 ยังต้องใช้คน PM อาจไม่ต้องมี hard skill ด้าน technical ก็จริง แต่ Taste เป็น hard skill มาตลอด ไม่ใช่ของใหม่เลย แค่วันนี้มันสำคัญกว่าที่เคย

ร้านอาหารตามสั่งก็ยังอยู่ได้นะ แต่ร้านที่คนยอมต่อคิว มักจะมีเมนูไม่กี่อย่าง และทำเมนูเหล่านั้นได้อร่อยมาก ๆ (ถ้าร้านไหนขายทั้งข้าวแกง พาสต้า ผัดกะเพรา ซูชิ พิซซ่า กิมจิ ฮอตดอก . . . หนีไปปปปปปปป)