เราอยู่ตรงไหนของแผนที่#

ขั้นที่ 1 จาก 5 คือ Requirements

ชิ้นจิ๊กซอว์ของตอนนี้คือเรื่องที่ 1 กับ 2 บนแผนที่ หาว่ามีใครอยากได้ (ตลาดและลูกค้า) กับทิศทางของสินค้าและเสียงลูกค้า อยู่ในวงบริษัท

ทำไมชิ้นนี้สำคัญ

เพราะทุกชิ้นหลังจากนี้ ทั้ง design, code, test, deploy ล้วนเชื่อว่าชิ้นนี้ถูก

ถ้าโจทย์ผิด ต่อให้สร้างออกมาดีแค่ไหนก็ยังเสียของ

บริษัทใหญ่มีคนดูแลชิ้นนี้โดยเฉพาะ เช่น PM กับ UX researcher

ต้นมีแค่ตัวเอง

ยุค agent เปลี่ยนอะไร#

เมื่อก่อนการสร้างช้าและแพง คนเลยถูกบังคับให้คิดก่อน

ตอนนี้ agent สร้างให้ได้ในคืนเดียว ตัวเบรกตัวนั้นหายไป

lauren เล่าถึงวงทำงานของเธอว่า ไมล์แรก คือ “figuring out what work you should even be doing at all”

@DavidOndrej1 พูดตรงกว่านั้น

“current AI models can build anything / but it’s up to YOU to know what to build / if you suck at Product, no agent will save you”

มีคนตอบในเธรดหนึ่งไว้ แบบนี้ (โพสต์เล็กๆ ผมยกมาเป็นภาพประกอบ)

“Claude will happily generate a flawless app nobody wants”

คืนเดียวได้แอป แต่ไม่มีใครใช้#

ต้นแปะแผนที่เสร็จ คืนนั้นสั่ง agent ทำแอปจองคิว

ก่อนเที่ยงคืนได้ prototype ที่ใช้ได้จริง

ส่งให้เพื่อนห้าคน มีคนเปิดสองคน ไม่มีใครกลับมาใช้ซ้ำเลย (ตัวอย่าง)

ต้นไม่ได้เขียน code พลาด

ต้นไม่เคยถามใครเลยว่าเขาจองคิวกันยังไงอยู่ตอนนี้

agent ตอบได้ว่าสร้างยังไง แต่ตอบไม่ได้ว่าควรสร้างอะไร

ใครเป็นคนตัดสินว่าจะสร้างอะไร#

ทีมใหญ่เรียกคนนี้ว่า Product Owner

บริษัทคนเดียว Product Owner คือต้น

agent ช่วยค้น ช่วยสรุป ช่วยร่างได้ แต่คนที่บอกว่า “ทำอันนี้ ไม่ทำอันนั้น” ต้องเป็นคน

ไม่ใช่เพราะ agent คิดไม่เป็น แต่เพราะต้นเป็นคนรับผลเมื่อเลือกผิด

คุยกับคนจริงแบบไหนถึงได้ของ?#

เรื่องนี้เป็นแนวที่ใช้กันทั่วไปในงาน user research ไม่ได้มีสูตรลับ

• ถามเรื่องที่เคยเกิดขึ้นจริง ไม่ถามว่า “ถ้ามีแอปนี้จะใช้มั้ย”
• ถามว่า “ครั้งล่าสุดที่เจอปัญหานี้ ทำยังไง”
• อย่าขายไอเดียระหว่างคุย พอขาย เขาจะตอบให้เราสบายใจ
• ฟังว่าตอนนี้เขาแก้ขัดกันยังไง กระดาษ LINE กลุ่ม หรือ Excel ถ้าวิธีแก้ขัดมีอยู่แล้ว แปลว่าปัญหามีจริง
• เริ่มที่ห้าคนก่อน (ตัวอย่าง) พอให้เห็นว่าคำตอบเริ่มซ้ำ

ต้นลองกับร้านตัดผมสามร้าน (ตัวอย่าง)

ร้านไม่ได้อยากได้แอป ร้านอยากให้ลูกค้าไม่หายไปเฉยๆ ตอนที่จองไว้

โจทย์เปลี่ยนตั้งแต่ยังไม่ได้เขียน code สักบรรทัด

ให้ agent อ่านแทน แต่อย่าให้คิดแทน#

agent อ่านเร็วกว่าคนมาก ตรงนี้คือจุดที่ควรใช้มัน

@Kaizen_SEO เล่าว่า ก่อนสร้างอะไรเขาไล่อ่าน Reddit, App Store reviews ของคู่แข่งสามเจ้า และ X search แล้วใช้ Claude Code รวมทั้งหมด “into one file I can read in ten minutes”

ประโยคที่ผมชอบคือ “read the repeated complaints, not the feature requests”

@ivanzamesin ทำ skill ที่ตอบไอเดียแอปเตือนรดน้ำต้นไม้ว่า ""Plant owners” is NOT a segment.” แล้วชี้ไปที่ร้านอาหารที่มีต้นไม้ 40 ต้นแทน

@EXM7777 เล่าว่า เขาให้ workflow ทำ “perfect ICP profiles with their exact language” จาก Reddit, YouTube และ TikTok ทุกคืน

@DanKornas แนะนำ repo ชื่อ Startup Idea Validation Agent ที่ให้ agent ช่วยกดดันไอเดียก่อนเขียน code

ข้อควรระวังคือ agent สรุปสิ่งที่ “ดัง” บนอินเทอร์เน็ต

ลูกค้าของต้นอาจไม่เคยโพสต์อะไรเลย เจ้าของร้านตัดผมไม่ได้บ่นใน Reddit

agent บอกได้ว่าควรไปถามอะไร แต่ไม่ได้ไปนั่งคุยแทนต้น

prototype ถูกๆ กับประตูหลอก#

คุยแล้วยังไม่พอ คำพูดกับการกระทำไม่เหมือนกัน

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

ต้นส่งลิงก์ไปให้ลูกค้าร้าน 20 คน กดปุ่มจริง 3 คน (ตัวอย่าง)

ตัวเลขน้อย แต่เป็นตัวเลขจากการกระทำ ไม่ใช่คำชม

lauren เองก็ คิดผ่าน code เธอเขียนว่า “i like to do my planning/brainstorming through code sketches as prototypes first rather than a detailed upfront spec”

ใน The Complete Guide to pstack Pt. 2 เธอเขียนว่า “abstract plans only give you the illusion of progress”

prototype ตรงนี้ไม่ใช่ของที่จะเอาไปขาย มันมีไว้ถามคำถามเดียว คือมีใครกดมั้ย

ยังเถียงกันอยู่#

lauren เล่าว่าทีมเธอ ไม่มี planning session ยาวๆ และ “open a PR not a PRD”

อีกฝั่งคือ @sol_wright7 ที่ เล่าว่า พอ agent เก่ง เขารีบกระโดดไป spec กับ build “just because I could” แล้วพบว่า “Doesn’t mean I should though” สุดท้ายกลับไปทำ discovery และ user research ก่อนเหมือนเดิม

ผมว่าสองคนนี้ไม่ได้ขัดกันขนาดนั้น

ทีมของ lauren รู้แล้วว่าลูกค้าคือใคร ต้นยังไม่รู้

ถ้ารู้แล้วว่าสร้างให้ใคร PR ถูกกว่า PRD

ถ้ายังไม่รู้ ต้องถามก่อน

มาตรฐานพูดว่าอะไร?#

ใน ISO/IEC 29110 Basic profile งานหลักแบ่งเป็นสอง process คือ Project Management กับ Software Implementation ตามที่เล่าไว้ตอนที่แล้ว

ผมยังไม่ได้อ่านรายละเอียดทีละ activity เองครบ เลยไม่ขอเล่าเกินกว่านี้ ใครอยากอ่านต่อ guide ฉบับนี้ เปิดอ่านฟรี

ฝั่งบริษัทใหญ่ 12207 มี process แยกไว้ในกลุ่ม Technical สำหรับวิเคราะห์ธุรกิจหรือภารกิจ (6.4.1) และกำหนดความต้องการของ stakeholder (6.4.2)

DORA ก็นับ user-centric focus เป็น capability หนึ่ง นิยามว่าคือ “the extent to which teams understand user needs, prioritize user experience, and leverage feedback to continuously reprioritize their work”

ทั้งสามแหล่งพูดเรื่องเดียวกัน ฟังลูกค้าก่อนสร้าง

ต้นไม่ต้องทำเอกสารหนาแบบบริษัทใหญ่ แต่ควรมีสักหน้า

เอกสารความต้องการหน้าเดียว#

ของต้นมีหกช่อง

1. ใครเจอปัญหา (segment ให้แคบที่สุด)
2. ตอนนี้เขาแก้ขัดยังไง
3. ทำไมวิธีเดิมไม่พอ
4. สิ่งที่จะลองสร้าง เขียนเป็นประโยคเดียว
5. วัดยังไงว่าใช่ เช่น กดจองจริงกี่คนจากกี่คน
6. สิ่งที่ยังไม่ทำรอบนี้

หน้านี้ใช้คุยกับคนได้ และใช้เป็น context ให้ agent ได้ด้วย

พอถึงตอนสร้าง agent จะรู้ว่าทำให้ใคร ไม่ใช่เดาเอาเอง

จิ๊กซอว์ชิ้นที่เติมแล้ว#

ชิ้น Requirements เติมแล้ว เรื่องที่ 1 กับ 2 บนแผนที่ ต้นรู้ว่าจะสร้างให้ใคร และมีเอกสารหน้าเดียวไว้ยึด

ชิ้นถัดไปบนแถบ 5 ขั้นคือ Design

สิ่งที่ผมได้จากตอนนี้#

ตอนต่อไป#

เพื่อนสามคนบอกว่าอยากได้ระบบจองคิวร้านตัดผม (ตัวอย่าง)

ต้นถาม X ว่าควรใช้ stack อะไร ได้สิบคำตอบ

ต้นให้ agent สองตัวลองทำช่องเลือกวันที่ ได้ออกมาสองแบบที่ไม่เหมือนกันเลย

ถึงเวลาออกแบบก่อน agent ทำ

คำถามที่พบบ่อย#

ต้องคุยกับกี่คนถึงจะพอ?

ไม่มีตัวเลขตายตัวครับ เริ่มที่ห้าคน (ตัวอย่าง) แล้วดูว่าคำตอบเริ่มซ้ำหรือยัง ถ้ายังไม่ซ้ำ ให้คุยต่อ

ให้ agent คุยกับลูกค้าแทนได้มั้ย?

ให้ agent อ่าน สรุป และร่างคำถามได้ แต่การคุยกับคนจริงยังต้องเป็นต้น เพราะคำตอบที่ได้จากการคุยเองมักไม่มีอยู่ในอินเทอร์เน็ต

ถ้าสร้างไว้ใช้เองคนเดียว ต้องทำขั้นนี้มั้ย?

ทำแบบสั้นครับ เขียนหน้าเดียวถามตัวเองว่าตอนนี้แก้ขัดยังไง ถ้าวิธีเดิมพอแล้ว อาจไม่ต้องสร้างเลย

คนบน X บอกไม่ตรงกัน เชื่อใคร?

ดูว่าเขาอยู่ในสถานการณ์ไหน ทีมที่รู้จักลูกค้าแล้วข้ามเอกสารได้ คนที่ยังไม่รู้จักลูกค้าข้ามไม่ได้

ต้องทำตาม 29110 ทุกข้อไหม?

ไม่ต้องครับ ผมใช้เป็น checklist ว่าบริษัทเล็กควรคิดเรื่องอะไรบ้าง

Next → ภาค 2 ตอนที่ 3: ออกแบบก่อน agent ทำ