ทีมเล็กแค่ 3 คนสร้างโปรดักต์ที่ใช้ได้จริง ตั้งแต่ศูนย์จนถึงวันเปิดตัวภายในราว 10 สัปดาห์ได้อย่างไร คำตอบอยู่ใน talk ชื่อ "Designing with Claude: From prompt to production" โดย Dan Cary จาก Anthropic Labs ที่งาน Code w/ Claude กรุงลอนดอน และเผยแพร่บนช่อง Claude (Anthropic) โปรดักต์นั้นคือ Claude Design เครื่องมือที่ให้คนทำงานคุยกับ Claude เพื่อสร้างงานออกแบบ · prototype (ต้นแบบที่กดเล่นได้จริง) · สไลด์ · one-pager ให้ออกมาเป็นรูปธรรม แต่สิ่งที่น่าสนใจกว่าตัวโปรดักต์คือ "วิธีทำงาน" ของทีมเล็กๆ ที่ปั้นของชิ้นนี้ออกมาได้เร็วขนาดนี้ dev · เจ้าของกิจการ · PM · ฟรีแลนซ์ · ครีเอเตอร์ หรือแม้แต่คนทำธุรกิจเล็กๆ ก็หยิบไปใช้ได้ จุดที่น่าเชื่อถือที่สุดคือ Dan ยืนยันเองว่าไม่มีสูตรลับอะไร และหลายอย่างในนี้เริ่มลงมือได้ตั้งแต่พรุ่งนี้
Anthropic Labs ที่ Dan สังกัดคือทีมทดลองเล็กๆ ภายใน Anthropic ทำหน้าที่ลองว่าโมเดลทำอะไรได้บ้าง แล้วดูว่าไอเดียไหนน่าเดิมพัน อันไหนเวิร์กก็ทุ่มต่อ อันไหนไม่เวิร์กก็พับเก็บ ทีมเล็กๆ ราวสิบกว่าทีมทำงานคู่ขนานกันตลอดเวลา Dan เปรียบที่นี่เป็น "โรงงานปั้นการเดิมพัน" ที่ทดลองเยอะ แต่ปล่อยของจริงออกมาไม่กี่ชิ้น โปรดักต์หลายตัวที่คนรู้จักก็ออกมาจากที่นี่ ทั้ง Claude Code (เครื่องมือ AI สำหรับเขียนและแก้โค้ดผ่าน terminal) · MCP · Skills · Claude for Chrome รวมถึง Claude Design ที่เป็นตัวเอกของ talk นี้
คอขวดของงานย้ายที่แล้ว จากการ "สร้าง" ไปเป็นการ "หาว่าควรสร้างอะไร"
จุดเริ่มต้นของ Claude Design มาจากข้อสังเกตหนึ่งของทีม นั่นคือเมื่อ Claude Code ทำให้วิศวกรเขียนโปรแกรมได้เร็วขึ้นมาก คนส่วนที่เหลือของทีมก็ต้องวิ่งตามให้ทัน ส่งผลให้ timeline ของการทำโปรดักต์หดสั้นลงเรื่อยๆ จากที่เคยใช้เวลาราว 6 เดือน เหลือเป็นหลักเดือน หลักสัปดาห์ และสุดท้ายเป็นหลักวัน
Dan ชี้ว่าเมื่อการ "สร้าง" เร็วขึ้นขนาดนี้ คอขวดของงานก็ย้ายที่ จากเดิมที่ตันอยู่ตรง "สร้างฟีเจอร์ให้เสร็จ" กลายเป็น "หาให้เจอว่าควรสร้างอะไรกันแน่" นี่คือเหตุผลที่ทีมต้องมีเครื่องมืออย่าง Claude Design เพราะคนออกแบบและ PM ต้องขยับให้เร็วทันวิศวกร ไม่ใช่กลายเป็นคอขวดเสียเอง
ที่น่าสนใจคือ Claude Design ไม่ได้เริ่มจากการประชุมวางแผนใหญ่โต แต่เริ่มจาก Nate ดีไซเนอร์คนหนึ่งที่เคยอยู่ทีม Claude Code เขาแฮกต้นแบบขึ้นมาภายในสุดสัปดาห์เดียว ระหว่างที่กำลังทำการเดิมพันอีกอันอยู่ โดยเอา Agent SDK ของ Anthropic มาต่อกับ IDE wrapper บางๆ บวกกับ skill (ชุดความสามารถสำเร็จรูป) ตัวเดิมที่ใช้อยู่ใน Claude Code แล้วโพสต์ลง Slack ให้คนในทีมช่วยกันดูว่าอะไรมีแวว อะไรพัง และอะไรควรแก้ Dan เล่าว่าเธรดนั้นเองที่กลายเป็น roadmap ของสองสามสัปดาห์แรกไปเลย
สิ่งที่ทีมนี้ "ไม่ทำ" สำคัญพอๆ กับสิ่งที่ทำ Dan เล่าว่าพวกเขาไม่เขียน PRD (Product Requirements Document คือเอกสารสเปกโปรดักต์ที่ทีมมักเขียนกันก่อนลงมือสร้าง) ไว้ล่วงหน้า ไม่มีเอกสารวิสัยทัศน์ ไม่มีประชุมตั้ง OKR ไม่มีแผนกำลังคนรายปี ไม่มีเอกสารวางแผนสองปีข้างหน้า และไม่ได้ร่าง press release ไว้ก่อนด้วยซ้ำ คำพูดของ Dan ที่สรุปได้ตรงที่สุดคือ ทีมไม่ได้รู้แน่ชัดว่ากำลังสร้างอะไร รู้แค่ว่ามี "ประกาย" บางอย่างที่น่าตามต่อ
prototype แทนที่ PRD ได้จริง เพราะเอกสารมันคลุมเครือเกินไป
ประเด็นที่ Dan ย้ำหนักแน่นที่สุดคือ prototype ที่จับต้องได้เอาชนะเอกสารสเปกได้ในเกือบทุกสถานการณ์ เพราะเอกสารคลุมเครือโดยธรรมชาติ คนสองคนอ่านเอกสารฉบับเดียวกัน แต่อาจจินตนาการโปรดักต์ออกมาคนละแบบ และบ่อยครั้งทั้งสองภาพก็ไม่ตรงกับสิ่งที่คนเขียนตั้งใจไว้ตั้งแต่แรก ส่วน prototype เป็นรูปธรรม กดเล่นได้ และให้ความรู้สึกจริงกว่า
จุดที่ทำให้วิธีนี้ใช้ได้จริงคือทีมย่อรอบการทำ prototype ลงเหลือแค่ "ไม่กี่นาที" เมื่อทำต้นแบบได้เร็วระดับนี้ การถกเถียงกันบนเอกสารนามธรรมก็แทบไม่จำเป็นอีกต่อไป แทนที่จะเถียงกันว่าควรเป็นแบบไหน ทีมทำของจริงออกมาดูกันเลย
สูตรที่ Dan ใช้แทน PRD มีขั้นตอนชัดเจน เริ่มจากคุยกับเพื่อนร่วมทีมเรื่อง "ปัญหา" ไม่ใช่เรื่องหน้าตา เน้นว่าทำไมปัญหานี้ถึงสำคัญ และทางออกที่ดีควรมีคุณสมบัติอย่างไร แทนที่จะคุยว่าปุ่มไหนควรอยู่ตรงไหน จากนั้นอัดเสียงการคุย ถอดเทปออกมาเป็น transcript แล้วส่ง transcript ให้ Claude Design พร้อมสั่งว่าขอทางเลือกสัก 2-3 แบบ Dan เป็น PM ที่เขียน PRD มาเกือบสองทศวรรษ และบอกว่าวิธีนี้แทนที่ PRD ในงานของเขาได้จริง
Tip: ความต่างสำคัญอยู่ที่การคุยเรื่อง "ทำไม" และ "ทางออกที่ดีหน้าตาเป็นยังไง" แทนการสั่งว่า "เอาปุ่มนี้ไว้ตรงนี้" เพราะการสั่งรายละเอียดหน้าตาตั้งแต่ยังไม่เห็นของจริง เป็นต้นตอที่ทำให้เอกสารกับภาพในหัวของแต่ละคนเพี้ยนกันไปคนละทาง
วิธีนี้ไม่ได้อยู่แค่บนกระดาษ Dan ยกตัวอย่างพิธีกรรมที่ทีมเรียกว่า pitch-off ทุกคนจะมารวมตัวกัน ระดมไอเดีย แล้วพยายามดึงคนอื่นให้มาร่วมไอเดียของตัวเอง ครั้งแรกที่ทีมลองทำกิจกรรมนี้ด้วย Claude Design พอถึงครึ่งหลังของการประชุม ทุก pitch กลายเป็น prototype หรือสไลด์ที่ทำสดด้วย Claude Design ในห้องนั้น และกลายเป็นหลักฐานสำคัญที่ทำให้ทีมตัดสินใจทุ่มต่อกับโปรดักต์นี้
ทีมเล็กที่ทุกคนทำได้ทุกอย่าง และรอบที่เร็วชนะรอบที่สมบูรณ์
โครงสร้างทีมแบบ Anthropic Labs เริ่มต้นเล็กมาก การเดิมพันแต่ละอันเริ่มจากคนหนึ่งคนที่มี Claude เป็นเพื่อนคู่คิด ช่วงต้นทีมแค่มองหา "ประกายของความเป็นไปได้" หรือเค้าลางเล็กๆ ว่าไอเดียนี้มีอะไรน่าตามต่อ การเดิมพันส่วนใหญ่พับไปก่อนถึงจุดนี้ด้วยซ้ำ ซึ่ง Dan บอกว่าเป็นเรื่องปกติ ช่วงสำรวจตอนต้นใช้เวลาแค่หลักชั่วโมงถึงไม่กี่วัน พอเจอประกายที่ใช่จึงค่อยขยายทีม Dan แซวว่าขยายแบบ "300%" จากหนึ่งคนเป็นสามคน และอาจขยายถึงห้าคนก่อนเปิดตัว
เสน่ห์ของทีมเล็กคือ overhead ในการประสานงานต่ำมาก และเส้นแบ่งบทบาทแทบละลายหายไปเพราะมี Claude ช่วย วิศวกรไปคุยกับผู้ใช้เอง PM เขียนโค้ดเอง ดีไซเนอร์ลงมือวิเคราะห์ข้อมูลเอง คนเดียวสามารถคุยกับผู้ใช้สิบคน เห็นปัญหา ออกแบบทางออก ship ออกไป ฟังเสียงตอบกลับ แล้ววนทำซ้ำได้ด้วยตัวเองจนจบ งานฟีเจอร์ส่วนใหญ่จึงทำคนเดียวจบ ส่วนการประสานความเข้าใจก็ง่าย แค่หันไปคุยกับคนซ้ายมือขวามือก็เรียบร้อย
หัวใจของวิธีทำงานคือ loop ที่หมุนซ้ำไปเรื่อยๆ คุยกับผู้ใช้ ออกแบบฟีเจอร์ ship โค้ด อ่าน feedback แล้ววนกลับไปคุยกับผู้ใช้อีก ทีมนี้หมุน loop นี้ราว 50-100 รอบภายใน 10 สัปดาห์ จุดที่ Dan เน้นคือต้อง optimize "ทุกขั้น" ของ loop เพราะเวลาที่ประหยัดได้เล็กน้อยในแต่ละรอบจะคูณด้วยจำนวนรอบทั้ง 50-100 ครั้ง คำถามที่ทีมถามตัวเองตลอดคือ ทำไมยังทำงานที่ Claude ทำแทนได้อยู่ และทำไมยังไม่สร้างเครื่องมือของตัวเองขึ้นมาช่วย
แต่ละขั้นของ loop ทีมพยายามลดแรงเสียดทานอย่างจริงจัง ในขั้น "คุยกับผู้ใช้" ทีมเปิด Slack channel ร่วมกับทุกคนที่ใช้โปรดักต์ บวกกับการ dogfooding หนักๆ (คือทีมใช้โปรดักต์ของตัวเองทุกวันเพื่อเจอปัญหาก่อนผู้ใช้จริง) และดึง Claude เข้ามาช่วยอ่านบทสนทนากับลูกค้าทั้งหมด เพื่อหาจุดร่วม เช่น เวลาคนในทีมสองคนคุยกับผู้ใช้คนละกลุ่มแต่ได้ข้อเสนอแนะตรงกัน Claude จะช่วยวิเคราะห์รอบแรกให้ โดยที่คนยังอยู่ในบทสนทนาเอง ไม่ได้เอา Claude ไปขวางระหว่างทีมกับผู้ใช้
ในขั้น "ออกแบบฟีเจอร์" ทีมใช้ Claude Design ออกแบบ Claude Design เอง Dan บอกว่าการได้ใช้เครื่องมือของตัวเองมาปรับปรุงเครื่องมือของตัวเองคือสถานการณ์ที่ดีที่สุดในโลก ฟีเจอร์หลายอย่างเกิดจากการใช้จริงแบบนี้ ทั้งการสำรวจ code base · การเชื่อมต่อ GitHub และ multiplayer (ให้หลายคนแก้งานออกแบบชิ้นเดียวกันพร้อมกันแบบเรียลไทม์) ซึ่งบังเอิญเป็นสิ่งแรกที่ผู้ใช้ร้องขอด้วย ส่วนขั้น "ship โค้ด" ทีมสร้างระบบ handoff to Claude Code เพื่อส่งงานออกแบบต่อให้ Claude Code แปลงเป็นโค้ดขึ้น production เพราะก่อนหน้านี้ต้อง export ไฟล์แล้วพิมพ์บริบททั้งหมดใส่ Claude Code ใหม่ ทำให้ช้า พอมี multiplayer แล้ว คำขอถัดมาจากผู้ใช้ก็คือจะเอางานนี้ขึ้น production ได้ยังไง
ในขั้น "อ่าน feedback" ปริมาณเสียงตอบกลับมากเกินกว่าคนเดียวจะอ่านไหว ทีมจึงสร้างเครื่องมือจับกลุ่ม feedback ของตัวเองขึ้นมาภายในบ่ายเดียว Claude จะอ่าน feedback ทั้งหมด จับคู่กับข้อมูลการทำงานของระบบ หาแนวโน้ม วิเคราะห์เบื้องต้น ชี้จุดที่น่าจะเป็นบั๊ก เสนอวิธีแก้ และให้กดส่งเข้าระบบพัฒนาได้เลย
จุดที่ทำให้บทเรียนนี้คมคือเคสที่ทีม "ทำผิด" Dan เล่าว่าทีมเคยสร้างชุดควบคุมระดับ pixel แบบละเอียดให้ power user กลุ่มผู้ใช้ระดับเซียนที่เสียงดังกลุ่มนี้ชอบมาก แต่พอเจาะดูการใช้งานจริงกลับพบว่าคนที่เหลือเกลียดมัน เพราะมันทำให้สับสนและบั่นทอนตัวโปรดักต์ ทีมจึงรื้อมันทิ้งโดยใช้เวลารวมแค่หนึ่งสัปดาห์ Dan ชี้ว่าถ้าทีมทำงานเป็นรอบรายไตรมาส ความผิดพลาดแบบนี้จะกินเวลาไปทั้งไตรมาส ทั้งที่ตัวโปรดักต์ทั้งหมดใช้เวลาน้อยกว่าหนึ่งไตรมาสด้วยซ้ำ บทเรียนของเขาจึงไม่ใช่ว่าต้อง "เร็วตลอดเวลา" แต่คือ "รอบต้องสั้นพอที่จะรู้ตัวได้เร็วว่ากำลังเดินผิดทาง"
จากเคสนี้ Dan สรุปอีกสองบทเรียน หนึ่งคือเครื่องมือที่ดีควรยกระดับฝีมือของคนทั้งหมด ไม่ใช่แค่เปิดเพดานให้ power user กลุ่มเล็ก สองคือควรเปิดกว้างมากที่สุด เพราะจะมีผู้ใช้ที่ต้องการงานเฉพาะทางที่ทีมตอบไม่ได้เสมอ นี่คือเหตุผลที่ Claude Design export งานออกมาเป็น HTML/CSS/JS ธรรมดาๆ เพื่อให้เอาไปใช้ต่อที่ไหนก็ได้ และทีมประกาศว่าในไม่ช้าเครื่องมือออกแบบเจ้าไหนก็จะเชื่อมต่อกับ Claude Design ได้ผ่าน MCP ที่มีอยู่แล้ว
บทเรียนที่ขัดสามัญสำนึกที่สุด คือให้ prototype สิ่งที่ "เกือบ" เวิร์ก
ข้อที่ Dan บอกเองว่าขัดความรู้สึกคนมากที่สุดคือ อย่าไปเสียเวลากับสิ่งที่เวิร์กอยู่แล้ว แต่ให้ทำต้นแบบของสิ่งที่ "เกือบ" จะเวิร์ก เหตุผลคือโมเดล AI พัฒนาเร็วมากจนรุ่นถัดไปอาจแก้ปัญหาที่ทีมแก้ด้วย engineering ไม่ได้ให้เองเลย Dan ยกตัวอย่าง Claude Design ว่าบั๊กหลายอย่างในต้นแบบช่วงแรกไม่ได้แก้ด้วยความฉลาดหรือไหวพริบทาง engineering แต่ "แก้ได้เพราะ Opus 4.7 ออกมา" วลีที่เขาใช้สรุปคือ การปล่อยโมเดลรุ่นใหม่เหมือนน้ำขึ้นที่ยกเรือทุกลำขึ้นพร้อมกัน พอโมเดลพื้นฐานเก่งขึ้น ทุกอย่างที่สร้างทับอยู่บนนั้นก็ดีขึ้นตามไปด้วยโดยไม่ต้องลงแรงเพิ่ม
นั่นแปลว่าในช่วงต้น ทีมแค่มองหา "ประกายของเวทมนตร์" ไม่ใช่ของที่สมบูรณ์แบบและรับมือได้ทุกกรณี แต่เป็นของที่ "มีสิทธิ์จะกลายเป็นแบบนั้นได้" พอเจอประกายนั้นแล้วค่อยลงมือสำรวจ สร้าง และเอาไปให้ผู้ใช้จริงลองใช้ เพื่อหา "ทรง (shape)" ของโปรดักต์ให้เจอ Dan ย้ำว่าทรงนี่แหละคือสิ่งสำคัญที่สุด และเป็นจุดที่เกือบทุกคนพลาดตอนเริ่ม เพราะมัวแต่ไปจมกับรายละเอียดที่เดี๋ยวโมเดลรุ่นใหม่ก็แก้ให้เอง
คุณค่าของการวนซ้ำเห็นได้ชัดเมื่อเทียบเวอร์ชันแรกกับเวอร์ชันที่ตามมา ต้นแบบแรกของ Claude Design เป็นแค่ "terminal ในเบราว์เซอร์" ที่ยังไม่สวยงามอะไร แต่ของที่เปิดตัวจริงห่างไกลจากจุดเริ่มต้นมาก Dan ประเมินว่า 99% ของคุณค่ามาจาก 10 สัปดาห์ของการวนซ้ำ ship และคุยกับผู้ใช้ทุกวัน ไม่ใช่จากการรู้คำตอบล่วงหน้า
ภาพที่สะท้อนปริมาณการวนซ้ำได้ดีคือ Claude Design เปิดตัววันศุกร์ พอถึงวันจันทร์ถัดมาทีม ship การปรับปรุงไปแล้ว 62 รายการ ทั้งประหยัด token มากขึ้น จัดการรูปภาพได้ดีขึ้น สำรวจ code base เก่งขึ้น และ export ได้ทันที ทั้งหมดมาจาก feedback ของผู้ใช้ในวันเปิดตัว Dan บอกว่านี่ไม่ใช่การหักโหมอดหลับอดนอน แต่เป็นเรื่องธรรมชาติ เพราะทีมสร้างความเคยชินกับจังหวะแบบนี้มาตลอด 10 สัปดาห์ คืนก่อน talk นี้ทีมเพิ่งเพิ่ม token limit เป็นสองเท่าในทุกแพ็กเกจ หลังจากที่โปรดักต์อยู่ในช่วง research preview มาแล้วหนึ่งเดือน เพราะผู้ใช้ชอบและอยากใช้มากขึ้น
3 อย่างที่ลองทำได้ตั้งแต่พรุ่งนี้
Dan ปิด talk ด้วยสามสิ่งที่คนฟังเอาไปลงมือทำได้ทันที เขาย้ำว่าให้ค่อยๆ ทำทีละข้อ อย่าทำพร้อมกันทั้งสามอย่าง เพราะแต่ละข้อจะเผยให้เห็นกำแพงในกระบวนการเดิมคนละแบบ
ข้อ 1 ข้ามการเขียน PRD รอบหน้าไปเลย แทนที่จะนั่งเขียนสเปก ให้คุณคุยกับ Claude และเพื่อนร่วมทีมเรื่องปัญหา แล้วเก็บ transcript ของการคุยไว้ จุดสำคัญคืออย่าพูดว่าจะมีปุ่มอะไรอยู่ตรงไหน แต่ให้พูดว่าทำไมถึงต้องแก้ปัญหานี้ และทางออกที่ดีควรมีลักษณะอย่างไร จากนั้นส่ง transcript นั้นให้ Claude หรือ Claude Design สร้าง prototype มาให้สัก 3 แบบ
ข้อ 2 สร้างเครื่องมือที่รอมานานให้เสร็จในบ่ายเดียว เช่น เครื่องมือจับกลุ่ม feedback หรือเครื่องมือวิเคราะห์ข้อมูลที่อยากได้มานาน ยุคนี้การสร้าง internal tool ของตัวเองทำได้เร็วมาก การ "เกาตรงที่คันของตัวเอง" จึงคุ้มค่าเร็วกว่าที่คิด
ข้อ 3 (ยากที่สุด) หยิบ feature request จริงจากผู้ใช้มา 1 อัน แล้วทำให้เสร็จภายใน 24 ชั่วโมง ต้องเป็นของจริง ไม่ใช่บั๊กเล็กๆ หรือการขยับ padding จากนั้นเอาไปให้ผู้ใช้ดูพร้อมตามเก็บ feedback Dan บอกว่าจุดประสงค์ไม่ได้อยู่ที่ความเร็ว แต่อยู่ที่การลงมือทำครั้งแรก เพราะคุณจะเจอ "กำแพง" ในกระบวนการเดิมของตัวเอง ไม่ว่าจะเป็นวิธี deploy หรือวิธีขอ review โค้ด และการเจอกำแพงพวกนี้คือสิ่งที่มีค่าที่สุด
สิ่งที่ทำให้ทั้ง talk นี้มีน้ำหนักคือมันไม่ได้ขายว่าต้องเป็นทีมระดับ frontier lab เท่านั้นถึงจะทำแบบนี้ได้ แต่ชี้ว่าวิธีคิดเรื่องการย่อรอบให้สั้น การเลือกทำของที่จับต้องได้แทนเอกสาร และการให้ AI รับงานซ้ำๆ แทน คือชุดเครื่องมือที่ทีมเล็กทุกขนาดหยิบไปปรับใช้ได้ คุณค่าไม่ได้อยู่ที่การรู้คำตอบตั้งแต่วันแรก แต่อยู่ที่การลงมือทดลองให้เร็วพอจนเจอว่าควรสร้างอะไรกันแน่
ที่มา: Designing with Claude: From prompt to production · Dan Cary, Code w/ Claude (London) (YouTube · ช่อง Claude/Anthropic)
