Anthropic Labs ทีมเล็กในบริษัท frontier AI ขนาดใหญ่ เปิดตัว Claude Design ใน Research Preview ครบ 1 เดือนพอดี บนเวที Anthropic Code with Claude Conference, Dan Carey ซึ่งเป็น Product Manager ของทีม เล่าว่าผลิตภัณฑ์นี้สร้างเสร็จภายใน 10 สัปดาห์ ทีมหลักมีเพียง 3 คนตลอดช่วงพัฒนา ก่อนขยายเป็น 5 คนก่อนเปิดตัว ตัวเลขนี้ไม่ใช่จุดขาย แต่สะท้อนวิธีคิดที่ Anthropic Labs ใช้กับทุกผลิตภัณฑ์จากทีมเดียวกัน ไม่ว่าจะเป็น Claude Code, MCP, Skills, Claude in Chrome หรือ hands-free audio
Dan เล่าว่าทีมรัน loop "ship-watch-learn" ระหว่าง 50 ถึง 100 รอบในช่วง 10 สัปดาห์นั้น ไม่มี PRD ไม่มี vision doc ไม่มี KR meeting ไม่มี H1 staffing plan และไม่มี press release ล่วงหน้า จุดเริ่มต้นจริงคือ prototype หนึ่งตัวที่ designer ในทีมชื่อ Nate แฮกขึ้นในสุดสัปดาห์เดียวจาก Agent SDK บวกกับ IDE wrapper บางมาก บทความนี้สรุปแนวคิดและขั้นตอนทั้งหมดที่ Dan แชร์ พร้อมเสริมมุมที่นักสร้าง product ในไทยน่าจะหยิบไปใช้กับวงรอบงานของตัวเองได้จริง
Note: Anthropic Labs เรียกตัวเองว่า "bet factory" หมายถึงโครงสร้างที่ปล่อยทีมเล็กกระจายไปทดลอง bet หลายตัวพร้อมกัน แล้ว double down ตัวที่เวิร์ก ปิดตัวที่ไม่เวิร์ก bet ส่วนใหญ่ไม่ได้เดินไปถึงจุดเปิดตัว และ Dan ย้ำว่านี่เป็นเรื่องปกติของระบบ
1. ทำไม Anthropic Labs ถึงเริ่มสร้าง Claude Design
ตามที่ Dan นำเสนอ ปัญหาที่ทำให้ทีมเริ่มทำ Claude Design ไม่ได้มาจากการตั้งวิสัยทัศน์ระยะยาว แต่มาจากผลข้างเคียงของ Claude Code เอง Dan ระบุว่าเมื่อ Claude Code ทำให้ engineer ทำงานเร็วขึ้นมาก timeline ของการพัฒนาฟีเจอร์จึงเลื่อนจาก 6 เดือนเหลือ 1 เดือน เหลือ 1 สัปดาห์ และบางงานเหลือ 1 วัน bottleneck จึงย้ายจาก "การ build ฟีเจอร์" ไปอยู่ที่ "การหาว่าอะไรคือสิ่งที่ควร build" ซึ่งเป็นงานของ designer และ PM โดยตรง
Dan ชี้ว่าทางเลือกบนโต๊ะมีแค่สองทาง ทางแรกคือข้ามขั้น discovery แล้วตัดสินใจเร็วๆ ซึ่งเสี่ยงที่จะ build ของผิดเร็วกว่าเดิม ทางที่สองคือหาวิธีให้ designer และ PM เร่งวงรอบของตัวเองให้ทันกับ engineer ทีม Anthropic Labs เลือกทางที่สอง Nate ซึ่งเคยเป็น designer ของ Claude Code มาก่อน จึงหยิบ Agent SDK บวกกับ skill ที่ใช้กับ Claude Code อยู่แล้ว มาประกอบเป็น prototype หยาบๆ ภายในสุดสัปดาห์เดียว แล้วโพสต์ screen recording ลง Slack ของบริษัท ก่อนที่คนอื่นจะเข้ามาคอมเมนต์ทั้งจุดที่น่าสนใจและจุดที่ยังพังอยู่
ในบริบทของทีมไทย จุดที่หยิบไปใช้ได้คือมุมมองว่า bottleneck ของทีมไม่ได้อยู่ที่เดิมอีกแล้ว เมื่อ AI coding tool ทำให้การ implement เร็วขึ้น สิ่งที่ขาดคือคำตอบของคำถามว่า "ของที่ควร build คืออะไร" งานนี้เป็นคนละชุดกับ engineering และต้องใช้เครื่องมือคนละชุด การคิดเรื่องนี้ก่อนเร่งทีมเขียนโค้ดจึงเป็นการลงทุนที่ตรงจุดกว่า
2. แทน PRD ด้วย prototype: เหตุผลและกลไก
Anthropic Labs สรุปว่าเอกสารประเภท PRD มีปัญหาเชิงโครงสร้าง Dan อธิบายว่าคนสองคนอ่าน PRD ฉบับเดียวกัน มักจินตนาการเป็นผลิตภัณฑ์คนละชิ้น และทั้งสองภาพก็มักไม่ตรงกับสิ่งที่ผู้เขียนเอกสารคิดไว้ด้วยซ้ำ เอกสารจึงเป็น artifact ที่ "imprecise" โดยธรรมชาติ ส่วน prototype เป็น artifact ที่จับต้องได้ ใช้งานได้ และทำให้ทุกคนในทีมรู้สึกถึงผลิตภัณฑ์จริงพร้อมกัน
Dan ระบุในคลิปว่ารอบการสร้าง prototype ของทีมลดลงเหลือ "ไม่กี่นาที" ขั้นตอนที่ทีมใช้คือคุยกับเพื่อนในทีมหนึ่งคน บันทึกเสียง แล้วแปลงเป็นข้อความด้วยเครื่องมือ transcribe ใดก็ได้ ทีมไม่เน้นว่าฟีเจอร์มีปุ่มอะไรบ้าง แต่เน้นว่าปัญหาคืออะไร solution ที่ดีควรมีคุณสมบัติแบบไหน และทำไมถึงต้องแก้ปัญหานี้ จากนั้นนำ transcript ไปป้อนให้ Claude Design สร้าง variation ของ prototype ออกมา 3 ตัวเลือก Dan เล่าว่ากระบวนการนี้แทน PRD ของเขาทั้งหมด ทั้งที่เขียน PRD มาเกือบ 20 ปี
Dan ยังเล่าถึง "pitch-off" พิธีกรรมที่ทีม Anthropic Labs มารวมตัวกันเพื่อ "nerd snipe" เพื่อนร่วมงานให้มาช่วยทำ bet ของตัวเอง pitch-off ครั้งแรกที่ใช้ Claude Design คือจุดที่ทีมเชื่อว่ามีของจริงในมือ เพราะภายในครึ่งหลังของ session มี 100% ของ pitch ถูกสร้างเป็น prototype หรือสไลด์ด้วย Claude Design สดๆ ในห้อง
Tip: หลักการที่ Dan แชร์คือ เวลาคุยให้ Claude Design ออกแบบ prototype ห้ามพูดถึง "ปุ่ม" หรือ "หน้าจอ" ก่อน ให้คุยว่าปัญหาคืออะไร solution ที่ดีควรมีคุณสมบัติแบบไหน และทำไมถึงต้องแก้ จากนั้นปล่อยให้ Claude เสนอรูปร่างของฟีเจอร์ออกมาเอง
ในมุมของทีมไทย การแทน PRD ด้วย prototype ไม่ต้องรอ Claude Design ก็เริ่มได้ทันที สิ่งที่ต้องเปลี่ยนคือลำดับของขั้นตอน จากเดิมที่เขียนเอกสารยาวก่อนเขียนโค้ด ให้กลับด้านเป็น "คุยเสียง 10 นาที → transcribe → ป้อนให้ Claude Code หรือ Claude Design สร้าง prototype 3 variation → เลือก variation ที่ใกล้ที่สุด → ส่งให้ทีมลองจริงในวันเดียวกัน" รอบนี้ใช้คนทำงานชุดเดิม แต่เปลี่ยนจาก artifact ที่ตีความได้หลายแบบ ให้กลายเป็น artifact ที่ทุกคนเห็นตรงกัน
3. ทีม 3 คน บทบาทละลายเข้าหากัน
Anthropic Labs สรุปว่า bet เกือบทุกตัวของทีมเริ่มต้นด้วยคนเดียว Dan ยกตัวอย่างว่าในช่วงสำรวจเริ่มต้น คนคนนั้นนั่งอยู่กับ Claude เป็นเพื่อนคู่หู เพื่อมองหา "little hint of heat" หรือสัญญาณว่าไอเดียมีแววจริง ระยะนี้ใช้เวลาแค่ชั่วโมงถึงไม่กี่วันสำหรับ bet ส่วนใหญ่ และ bet ส่วนใหญ่ก็จบลงตรงนี้โดยไม่ได้ไปต่อ Dan ระบุว่านี่เป็นเรื่องปกติของระบบ bet factory
เมื่อพบสัญญาณที่ใช่ ทีมจะ scale up "ถึง 300%" ซึ่ง Dan บอกเล่นๆ ว่าหมายถึงขยายเป็น 3 คน เหตุผลของขนาดทีมนี้คือต้องการกลุ่มที่กระชับมาก และมี collaboration overhead ต่ำที่สุด ถ้า bet พิสูจน์ตัวเองได้แล้ว ทีมอาจขยายเป็น 5 คนก่อนเปิดตัว สำหรับ Claude Design ระยะการพัฒนาหลักใช้แค่ 3 คนทำงานร่วมกับ Claude ตลอด
Dan อธิบายต่อว่าสิ่งที่ทำให้ทีม 3 คนทำงานในระดับนี้ได้คือ "ทุกคนทำได้ทุกอย่าง" engineer คุยกับ user, PM เขียนโค้ด, designer ทำ data analysis เส้นแบ่งระหว่างบทบาท "ละลาย" ไปแล้วในทางปฏิบัติ แต่แต่ละคนยังรักษา specialization และมุมมองเฉพาะของตัวเองไว้ Dan ระบุว่าไม่ว่าจะอยู่ช่วงไหน คนใดคนหนึ่งในทีมก็สามารถคุยกับ user 10 คน ตกผลึกปัญหา ออกแบบ solution, ship ลง production และอ่าน feedback ต่อได้ด้วยตัวเองโดยไม่ต้องเรียก meeting
ถ้าจำเป็นต้องคุยกันทั้งทีมจริงๆ Dan บอกว่ามักหมายถึงการหันไปคุยกับคนซ้ายและคนขวาเท่านั้น ไม่ใช่การจัดประชุม alignment ผลคือ coordination overhead ของทีมต่ำมาก เมื่อรวมกับการเลิกใช้ PRD จึงเป็นเหตุผลที่ Anthropic Labs ทำงาน 10 สัปดาห์ได้เท่ากับทีมขนาดใหญ่ทำงานหลายไตรมาส
ในบริบทของทีมไทย ประเด็นที่ใช้ได้ทันทีคือการตั้งคำถามกับขอบเขตของบทบาทในทีมตัวเอง นี่ไม่ได้แปลว่าทุกคนต้องทำทุกอย่างตั้งแต่วันแรก แต่ถ้า engineer ในทีมยังไม่เคยคุยกับ user ตรงๆ หรือ designer ยังไม่เคยเปิด analytics ดู usage ของฟีเจอร์ที่ออกแบบเอง พื้นที่ตรงนั้นคือจุดที่ AI tool ยุคนี้ช่วยให้ข้ามฝั่งได้โดยไม่ต้องเรียนรู้ใหม่ทั้งหมด การลดเส้นแบ่งของบทบาทจึงเป็นสิ่งที่ปลดล็อก loop ของทีม Anthropic Labs ให้รันได้ในความถี่ระดับวัน
4. The loop: talk to users, design, ship, read feedback แล้ววนซ้ำในความถี่ระดับวัน
Dan ระบุว่า loop ของทีมไม่ได้ซับซ้อน มีเพียง 4 ขั้นตอนคือ "talk to users → design features → ship code → read feedback" แล้ววนซ้ำ ประเด็นไม่ได้อยู่ที่ขั้นตอนเหล่านี้ แต่อยู่ที่ความเร็วของการรัน loop และการตั้งคำถามซ้ำๆ ว่า "ทำไมยังทำขั้นนี้เอง ทั้งที่ Claude ทำให้ได้?" Dan ย้ำว่าทุกการปรับ loop เพื่อลด friction แม้เพียงเล็กน้อย จะให้ผลตอบแทนเป็นเท่าตัวเมื่อ loop ถูกรันซ้ำ 50-100 รอบในโครงการเดียว
Talk to users ทุกวัน
Dan บอกว่าหัวใจของ loop คือการคุยกับ user ทุกวัน เคล็ดของทีมคือทำให้ "talk to users" เป็นสิ่งที่ง่ายที่สุดในโลกของวันทำงาน เพราะคนเรามักทำสิ่งที่ง่ายและเลี่ยงสิ่งที่ยาก วิธีที่ใช้คือเปิด Slack channel ร่วมกับ user ทุกคนของผลิตภัณฑ์ และ dog-fooding ภายในอย่างหนัก จากนั้นใส่ Claude เข้าไปในบทสนทนาเหล่านั้น เพื่อให้ Claude มองหา commonality ระหว่างบทสนทนาหลายสาย ทีมไม่ได้ปล่อยให้ Claude ยืนคั่นระหว่างทีมกับ user แต่ให้ Claude ทำ analysis รอบแรกที่ทีมต้องทำอยู่แล้วโดยอัตโนมัติ
Design features ด้วยเครื่องมือของตัวเอง
ในช่วงแรกทีมยังไม่มี Claude Design ใช้ ทีมจึง prototype ด้วย Claude Code แล้ว share ผ่าน video recording หรือ branch ที่ pull down มาลองเอง Dan เล่าว่าทีม "ใช้ Claude Design มาออกแบบ Claude Design" ทันทีที่ผลิตภัณฑ์ใช้งานได้พอ ฟีเจอร์เด่นหลายอย่างของผลิตภัณฑ์ในวันนี้ เช่น multiplayer และ handoff ไปยัง Claude Code เกิดขึ้นเพราะเป็น friction ในวงรอบการทำงานของทีมเอง พอเปิดให้ user ลอง คำขอแรกที่ได้รับก็คือฟีเจอร์เดียวกันที่ทีมเพิ่งสร้างให้ตัวเองใช้
Ship code ลด friction ของ handoff
Dan เล่าว่าก่อนจะมี handoff ระหว่าง Claude Design และ Claude Code ทีมต้อง export ไฟล์ออกมา แล้ว import เข้า Claude Code พร้อมพิมพ์ context ที่เคยคุยกับ Claude Design ทั้งหมดซ้ำใหม่ทุกครั้ง ขั้นตอนนี้ช้ามาก ทีมจึง build ฟีเจอร์ handoff ขึ้นมาแก้ปัญหาของตัวเองก่อน แล้วฟีเจอร์นั้นก็กลายเป็นคำขออันดับสองของ user หลังเปิดตัว ต่อจาก multiplayer
Read feedback ด้วย clustering tool ที่สร้างเองในบ่ายเดียว
หลังเปิดตัว feedback ที่เข้ามามีมากเกินกว่าคนเดียวจะอ่านไหว ทีมจึงสร้าง feedback clustering tool ใช้เอง "ใช้เวลาบ่ายเดียว" และไม่รอเครื่องมือสำเร็จรูปใดๆ ในระบบนี้ Claude จะอ่าน feedback ทั้งหมดที่เข้ามา จับคู่กับ system monitor และ trace ค้นหา trend วิเคราะห์เบื้องต้นว่า feedback ใดดูเป็น bug แล้วเสนอวิธีแก้ ก่อนให้ทีมกดปุ่มเดียวเพื่อโยนเข้า development tooling ต่อ
ในมุมของทีมไทย loop 4 ขั้นนี้คือ checklist ของ friction ที่ตัดได้ ขั้นแรกคือดูว่า "talk to users" ในทีมตัวเองยากแค่ไหน ถ้ายังต้องนัดประชุม หรือผ่าน CRM หลายชั้น แปลว่ามี friction ที่กินเวลาทีมทุกวัน ขั้นต่อมาคือดูว่าระหว่าง prototype กับ production มี handoff ที่ต้องพิมพ์ context ใหม่หรือไม่ ขั้นสุดท้ายคือดูว่า feedback ที่กองเข้ามาในแต่ละสัปดาห์ยังต้อง cluster ด้วยมือ หรือยังไม่มีใครจัดเลย ทุกขั้นที่มี friction คือพื้นที่ที่ Claude หรือ AI agent ทำแทนได้ในระยะเวลาบ่ายเดียว เหมือนที่ทีม Anthropic Labs ทำกับตัวเอง
5. ผิดทางได้ แต่ผิดไม่นาน: บทเรียนเรื่อง "advanced controls"
Anthropic Labs สรุปว่าความเร็วไม่ได้แปลว่าทำถูกเสมอ Dan ยกตัวอย่างฟีเจอร์ที่ทีมสร้างผิดทางในช่วงแรก คือชุด advanced controls ที่ให้ user คุมทุก pixel ในระดับละเอียดมาก ทีมได้ feedback บวกจาก power user กลุ่มเล็กที่ใช้งานหนักและพูดเสียงดัง แต่เมื่อดูจาก usage จริง ทีมพบว่า user ส่วนใหญ่ "เกลียด" ฟีเจอร์ชุดนี้ ไม่ใช่แค่ไม่ชอบ แต่ทั้งงงและรู้สึกว่าฟีเจอร์ทำให้ผลิตภัณฑ์แย่ลง
ทีมจึงตัดสินใจถอดฟีเจอร์ชุดนี้ออกทั้งหมด ใช้เวลารวมประมาณ 1 สัปดาห์ตั้งแต่ตัดสินใจถึง ship Dan ชี้ว่าถ้าทีมทำงานในรอบรายไตรมาส การเดินผิดทางครั้งนี้จะเท่ากับเสียทั้งไตรมาส เมื่อเทียบกับทั้งโครงการของ Claude Design ที่ใช้เวลาน้อยกว่า 1 ไตรมาส ความเสียหายจะหนักมาก สาระของบทเรียนจึงไม่ใช่ "ห้ามผิด" แต่เป็น "รอบของการทำงานต้องเล็กพอที่จะรู้เร็วว่าผิด"
Dan สรุปบทเรียนสองข้อ ข้อแรกคือเครื่องมือควรยกระดับ craft ของคนทั่วไป ไม่ใช่ยกเพดานให้ power user เพียงกลุ่มเดียว ข้อสองคือเครื่องมือควรเปิดมากที่สุดเท่าที่จะทำได้ เพราะจะมี user เฉพาะกลุ่มที่ทีมไม่เคยรู้จัก และทีมไม่มีทางครอบคลุมความต้องการของเขาได้หมด บทเรียนนี้จึงอธิบายว่าทำไม Claude Design ถึงให้ export เป็น HTML/CSS/JavaScript และทีมจะเปิด integration ผ่าน MCP ของเครื่องมือออกแบบอื่นๆ ในเร็วๆ นี้
ในบริบทของทีมไทย ประเด็นที่นำมาใช้ได้ตรงๆ คือการแยกระหว่าง "เสียงดัง" กับ "เป็นตัวแทนของผู้ใช้ส่วนใหญ่" feedback ที่ได้จาก power user ไม่ใช่ feedback ที่ผิด แต่ต้องจับคู่กับ usage data เสมอ ก่อนจะตัดสินใจ double down บนทิศทางใดทิศทางหนึ่ง และที่สำคัญคือเมื่อรู้ว่าผิดแล้ว ต้องถอดออกให้ไว ไม่ใช่ยื้อไว้เพื่อรักษาหน้า
6. "Work on the thing that almost works": แนวคิดที่สวนทางสามัญสำนึก
หนึ่งในข้อสรุปที่ Dan ระบุว่า "counterintuitive" ที่สุดของการทำงานใน Anthropic Labs คือทีม "ไม่อยาก" ทำงานบนสิ่งที่ทำงานได้แล้ว แต่อยากทำ prototype ของสิ่งที่ "เกือบจะทำงาน" เหตุผลคือโมเดล AI พัฒนาเร็วมาก ปัญหาหลายข้อที่ทีมแก้ไม่ได้ด้วย engineering อาจแก้ได้ด้วย model release รอบถัดไป Dan ระบุว่า Claude Design มีปัญหาหลายข้อในช่วง prototype ต้น ทีมไม่ได้แก้ด้วยวิศวกรรมที่ฉลาด แต่ Opus 4.7 ช่วยแก้ให้เมื่อเปิดตัว
Dan สรุปว่าในช่วงสำรวจเริ่มต้น สิ่งที่ทีมมองหาไม่ใช่ผลิตภัณฑ์ที่สมบูรณ์ ไม่ใช่ผลิตภัณฑ์ที่จัดการ edge case ทุกตัวได้ แต่เป็นเพียง "hint of magic" หรือสัญญาณว่าผลิตภัณฑ์มีรูปร่างที่ใช่ เพราะรูปร่างของผลิตภัณฑ์คือสิ่งที่ทีมมักพลาดในรอบแรก และต้องวนซ้ำหลายรอบกว่าจะได้รูปร่างที่ถูก
ในมุมของทีมไทย แนวคิดนี้กลับด้านกับการ scoping แบบเดิมที่นิยมตัดฟีเจอร์ที่ยังไม่ stable ออกจาก roadmap การลงทุนกับ prototype ของสิ่งที่ยังไม่เสถียรในวันนี้ คือการเตรียมตำแหน่งให้ทีมเก็บ value ทันทีที่ model รุ่นใหม่ออก แทนที่จะรอ model ออกก่อนแล้วค่อยเริ่ม prototype จุดที่ต้องระวังคือให้หยุดที่ prototype ไม่ใช่ ship production เพราะของที่ "เกือบจะทำงาน" ในวันนี้ยังไม่พร้อมรับ user ตรงๆ
7. ตัวเลขที่เล่าเอง: 62 improvements ในสุดสัปดาห์เปิดตัว
เพื่อให้เห็นภาพ scale ของการ iterate ที่ทีมทำ Dan ยกตัวเลขขึ้นมา คือหลัง Claude Design เปิดตัววันศุกร์ ภายในวันจันทร์ถัดมาทีม ship improvement ไปแล้ว 62 รายการ ครอบคลุมทั้งการลด token consumption การจัดการรูปให้ดีขึ้น การ explore code base ให้เร็วขึ้น และการทำให้ export เกือบทั้งหมดเป็นแบบ instant Dan ย้ำว่านี่ไม่ใช่ Herculean effort ของทีม ไม่ใช่ all-nighter ของใคร แต่เป็นจังหวะปกติของทีมที่ฝึกการ iterate มา 10 สัปดาห์เต็ม
Anthropic Labs ระบุว่า ณ วันที่ Dan พูดบนเวที ผลิตภัณฑ์เพิ่งเข้าสู่ Research Preview ครบ 1 เดือน และในคืนก่อนหน้า ทีมเพิ่งประกาศ double token limit ของผลิตภัณฑ์ทุก subscription plan โดยเป็นการตอบสนองตรงๆ ต่อ feedback ที่ว่า user ชอบของและอยากใช้มากขึ้น
จุดที่นำไปใช้ได้คือมุมมองว่าผลิตภัณฑ์ที่ "เสร็จแล้ว" ในวันเปิดตัว ไม่ใช่ผลิตภัณฑ์ที่จบที่ launch day แต่เป็นจุดเริ่มต้นของ feedback loop ที่ใหญ่กว่า ดังนั้นการวางทีมและ infrastructure ของการ ship ให้รองรับการเปลี่ยน 60 อย่างในสามวันเปิดตัว จึงเป็นการลงทุนที่ Anthropic Labs ทำมาก่อน launch ไม่ใช่หลัง launch
8. สามสิ่งที่ Dan แนะนำให้ทำพรุ่งนี้
ก่อนจบ talk Dan สรุปสามสิ่งที่ผู้ฟังสามารถนำไปทดลองได้ภายในวันรุ่งขึ้น โดยแนะนำให้ทำทีละข้อ ไม่ใช่ทั้งสามข้อพร้อมกัน เพราะแต่ละข้อสอนสิ่งที่ต่างกัน
ข้อหนึ่ง ครั้งหน้าที่ตั้งใจจะเขียน PRD ให้ข้ามทันที แทนที่จะเขียน ให้คุยกับเพื่อนในทีมเรื่อง "ปัญหา" และ "คุณสมบัติของ solution ที่ดี" บันทึกเป็น transcript แล้วป้อนให้ Claude หรือ Claude Design สร้าง prototype 3 variation ออกมาแทน
ข้อสอง หยิบเครื่องมือภายในที่ทีมรอมานานสักตัว แล้วใช้ afternoon เดียว build เลย Dan บอกว่าคนมักรอเครื่องมือสำเร็จรูป ทั้งที่ในยุคนี้การ build internal tooling เร็วมากแล้ว ตัวเขายกตัวอย่าง feedback clustering tool ของทีม Claude Design ที่ใช้บ่ายเดียวสร้าง
ข้อสาม Dan บอกว่าทำยากที่สุด คือหยิบ feature request จริงจาก user มาหนึ่งข้อ ที่ไม่ใช่แค่ bug fix หรือปรับ padding แต่เป็น feature request เนื้อๆ จากนั้น turn around ใน 24 ชั่วโมง ส่งให้ user ลอง และตามต่อด้วย feedback การทำครั้งแรกจะเปิดให้ทีมเห็น roadblock ในกระบวนการของตัวเอง ไม่ว่าจะเป็นวิธี deploy หรือวิธี review โค้ดของทีม Dan เน้นว่าจุดประสงค์ไม่ใช่ "เร็วเพื่อเร็ว" แต่เพื่อให้เห็นว่า process ปัจจุบันของทีมมี friction อยู่ตรงไหน
ในบริบทของทีมไทย คำแนะนำสามข้อนี้นำไปใช้ได้ทันทีโดยไม่ต้องเปลี่ยน stack หรือเปลี่ยนทีม ทั้งสามข้อมีไว้ทำให้ friction ของกระบวนการทำงานปัจจุบันโผล่ชัดขึ้น ไม่ใช่เร่ง output โดยตรง นี่คือวิธีคิดที่ Anthropic Labs ใช้ตลอดทั้ง 10 สัปดาห์ของ Claude Design
สรุป
Anthropic Labs สร้าง Claude Design ใน 10 สัปดาห์ ด้วยทีม 3 คน โดยรัน loop "talk to users, design, ship, read feedback" ระหว่าง 50 ถึง 100 รอบ ทีมเลิกใช้ PRD แล้วแทนด้วย prototype เลิกประชุม alignment แล้วใช้การคุยกับคนข้างซ้ายและขวาแทน ทุกคนในทีมทำได้ทุกบทบาท: engineer คุย user, PM เขียนโค้ด, designer ทำ data analysis ฟีเจอร์ที่ผิดทางถูกถอดออกใน 1 สัปดาห์ และฟีเจอร์ที่ใช่ก็ถูก double down อย่างรวดเร็ว ในคืนเปิดตัว ทีม ship 62 improvements ใน 3 วัน และในเดือนแรกเพิ่ม token limit อีกเท่าตัว
Dan สรุปว่าสิ่งที่ทีมมองหาในช่วง prototype ต้นคือ "hint of magic" ไม่ใช่ผลิตภัณฑ์ที่สมบูรณ์ และเลือกทำ prototype ของสิ่งที่ "เกือบจะทำงาน" เสมอ เพราะ model รุ่นถัดไปอาจปิด gap ที่วิศวกรรมแก้ไม่ได้ เหมือนที่ Opus 4.7 ช่วยปิด gap หลายข้อใน Claude Design
สำหรับนักสร้าง product ในไทย playbook นี้ไม่ได้ต้องการ infrastructure ของ Anthropic หรือทีมระดับ frontier lab สิ่งที่ต้องเปลี่ยนมีเพียงสามอย่าง: ลำดับของขั้นตอน (prototype ก่อนเอกสาร) ขอบเขตของบทบาท (ละลายเส้นแบ่ง engineer/PM/designer ในงานที่ละลายได้) และความเร็วของวงรอบ (ship ทุกวันสองวันแทนทุกสัปดาห์สองสัปดาห์) ทั้งสามอย่างเริ่มได้พรุ่งนี้ตามที่ Dan ระบุไว้ในตอนท้ายของ talk
Question: ถ้าวงรอบของทีมปัจจุบันยาว 2 สัปดาห์ การพยายามรัน 1 รอบใน 24 ชั่วโมงตามที่ Dan แนะนำ จะเจอ friction ตรงไหนก่อน deploy pipeline, code review หรือ tooling ในการคุยกับ user คำตอบของคำถามนี้คือ roadmap ที่ทีม Anthropic Labs ใช้ลด friction ของ loop ตัวเองมาตลอด 10 สัปดาห์
ที่มา: Designing with Claude: From prompt to production, Anthropic Code with Claude Conference โดย Dan Carey, Product Manager, Anthropic Labs
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!