productize.life
TH EN
Product · AI Skills

งานของ PM เหลืออะไร เมื่อ framework ทั้งวงการ เรียกใช้ได้ด้วยคำสั่งเดียว

อาทิตย์ก่อนไล่อ่าน repo รวม skill ของสายเขียนโค้ด แล้วไปเจออีกกลุ่มที่เงียบ ๆ แพ็กวิชา product management ทั้งกระบวนเป็น skill ให้ AI ใช้ สามตัวนี้มาจากคนละมุม แต่ชี้ไปที่ข้อสรุปเดียวกัน

Yim· เขียนด้วยกันกับ Dobby (AI Oracle)/2 ก.ค. 2026

อาทิตย์ก่อนเรานั่งไล่อ่าน repo ที่รวม skill ของสายเขียนโค้ดอยู่หลายตัว ทั้งของ Karpathy, Matt Pocock กับชุด superpowers เขียนรีวิวลงบล็อกไปหลายโพสต์ ทั้งหมดว่าด้วยการช่วยคนเขียนโค้ดให้ทำงานเป็นระบบขึ้น

แล้วก็ไปสะดุดกับอีกกลุ่มหนึ่ง ที่ไม่ได้แตะเรื่องเขียนโค้ดเลย แต่แพ็ก "งานของคนทำโปรดักต์" เข้าไปเป็น skill ทั้งดุ้น ตั้งแต่วางกลยุทธ์ ทำ discovery คุยลูกค้า เขียน PRD ไปจนถึงตรวจงานก่อนปล่อย

พอเปิดอ่านจริง สิ่งที่สะกิดใจไม่ใช่ว่ามันทำได้แค่ไหน แต่คือทั้งสามเจ้ามาจากคนละมุมกันสุด ๆ ประธาน YC คนหนึ่ง คนเขียนจดหมายข่าวสาย PM คนหนึ่ง กับ product lead อิสระอีกคน แต่พูดตรงกันเป๊ะเรื่องหนึ่ง เรื่องที่เปลี่ยนนิยามงาน PM ไปเลย

จะเล่าเป็นสามช่วง เริ่มจาก ของจริงสามตัวที่แพ็กวิชาเป็น skill ต่อด้วย จุดที่ทั้งสามพูดตรงกัน แล้วปิดด้วย คนทำโปรดักต์ควรขยับตัวยังไง

ช่วงที่ 1สาม repo ที่แพ็กวิชาเป็น skill

gstack ของ Garry Tan ทีมวิศวกรทั้งทีมในคนเดียว

Garry Tan ประธานและซีอีโอของ Y Combinator เปิดซอร์ส stack ที่เขาใช้เขียนงานเองทุกวัน ชื่อ gstack มันเปลี่ยน Claude Code ให้กลายเป็นทีมผู้เชี่ยวชาญ 20 กว่าคน มีทั้งคนที่มองงานแบบ CEO วิศวกร ดีไซเนอร์ QA เจ้าหน้าที่ความปลอดภัย จุดที่น่าสนใจไม่ใช่จำนวนหัว แต่คือเขาบังคับให้งานทุกชิ้นผ่านการรีวิวหลายมุมก่อนปล่อย มุม CEO ถามว่านี่ของ 10 ดาวจริง หรือ 3 ดาวแต่งหน้ามา มุมวิศวกรถามว่าสถาปัตยกรรมรับ edge case ไหวไหม มุมดีไซน์ถามว่ารู้ไหมว่า "ดี" หน้าตาเป็นยังไง

เขาเขียนไว้ตรง ๆ ใน ETHOS ของ gstack ว่า

"กำแพงด้านวิศวกรรมหายไปแล้ว สิ่งที่เหลือคือ taste วิจารณญาณ และความกล้าที่จะทำให้มันครบ"

นี่ไม่ใช่แค่ workflow มันคือการเอา taste กับลำดับความสำคัญของการตัดสินใจ มาเขียนฝังลงในซอฟต์แวร์ ทีมส่วนใหญ่ข้ามมุมพวกนี้ไป 3 ใน 4 คนทำงานเดี่ยวข้ามหมดเลย Garry เอามันกลับมาเป็นด่านบังคับ

pm-skills ของ Pawel Huryn วิชา PM ทั้งเล่ม เป็นปุ่มกด

Pawel Huryn คนทำจดหมายข่าวสาย product รวม skill ของงาน PM ไว้ราว 68 ตัว แบ่งเป็น 9 หมวด ตั้งแต่ strategy, discovery, market research, analytics, execution, go-to-market ยัน growth แต่ละ skill ไม่ใช่ prompt ลอย ๆ มันห่อframework จริงที่มีชื่อมีที่มา ทั้ง Teresa Torres, Marty Cagan, Alberto Savoia, Strategyzer พร้อมขั้นตอนใช้ทีละสเต็ป เขาเขียนโปรยไว้ว่า

"Generic AI ให้คุณได้แค่ตัวหนังสือ PM Skills ให้โครง"

อยากได้ SWOT, JTBD, RICE, pre-mortem, market sizing เรียกทีเดียวได้โครงพร้อมช่องให้เติม มีตัวหนึ่งที่สะดุดใจเป็นพิเศษชื่อ intended-vs-implemented มันตรวจ "ช่องว่างระหว่างสิ่งที่เอกสารบอกกับสิ่งที่โค้ดทำจริง" ซึ่งเป็นมุม PM ที่เกิดมาเพื่อยุคที่ AI เขียนโค้ดโดยเฉพาะ

product-discovery-skills ของ Else van der Berg discovery เป็นสายพาน

Else van der Berg เป็น product lead อิสระ เธอทำอีกแบบ แทนที่จะรวมทุกวิชา โฟกัสเรื่องเดียวคือ product discovery แล้วทำให้ลึก 6 skill ต่อกันเป็นสายพาน ตั้งแต่คัดว่าบทสัมภาษณ์ตรงกับลูกค้าเป้าหมายไหม ไปจนถึงจัดกลุ่มโอกาสข้ามหลายบทสัมภาษณ์ แล้วจัดลำดับความสำคัญ ทั้งหมดยึดวิธีคิด continuous discovery ของ Teresa Torres กฎที่เธอฝังไว้ในตัวจัดลำดับคมมาก

"อย่าไล่ตามโอกาสที่คะแนนความสำคัญต่ำกว่า 4 ต่อให้มีคนพูดถึงกี่คนก็ตาม ได้คนเดียวที่รักโปรดักต์จริง ดีกว่าสิบคนที่แค่เฉย ๆ แล้วไม่เคยใช้"

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

ช่วงที่ 2จุดที่ทั้งสามพูดตรงกัน

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

Garry พูดจากฝั่งวิศวกรรม เขาเคลมว่าปีนี้ปล่อยโค้ดได้เร็วกว่าตัวเองเมื่อ 13 ปีก่อนหลายร้อยเท่า (ตัวเลขนี้เป็นการวัดของเขาเอง ไม่ใช่ benchmark กลาง) แต่ประเด็นไม่ได้อยู่ที่ตัวเลข เขาสรุปว่ากำแพงวิศวกรรมพังแล้ว ของหายากใหม่คือ taste

Pawel พูดจากฝั่ง PM เขาแพ็ก framework 68 ตัวให้เรียกได้ในไม่กี่วินาที ซึ่งเท่ากับประกาศว่า การรู้ framework ไม่ใช่ความได้เปรียบอีกต่อไป framework พวกนี้กลายเป็นของสาธารณะ ใครก็หยิบได้เร็วเท่ากัน งานที่แทนไม่ได้เลื่อนไปอยู่ที่ เลือก framework ไหนให้ตรงกับธุรกิจนี้ จัดลำดับความสำคัญ (ไม่ใช่แค่คำนวณ) และดึงคนให้ไปทางเดียวกัน

Else พูดจากฝั่ง discovery กฎ "ความสำคัญต่ำกว่า 4 ไม่ไล่" ไม่ใช่สูตร มันคือวิจารณญาณที่เธอฝังลงไปให้ระบบคอยเตือนเรา ไม่ใช่ให้ระบบตัดสินแทน

พูดอีกแบบ ทั้งสามลงเอยที่ประโยคเดียวกัน ความรู้กลายเป็นของถูก วิจารณญาณกลายเป็นของหายาก framework, template, การผลิตเอกสาร ล้วนถูกบีบให้ถูกและเร็ว ส่วนที่ยังแพงคือ รู้ว่าควรทำอะไร กันไม่ให้ปล่อยของห่วย และรู้ว่าอันไหนเชื่อได้

แล้วยังมีอีกกฎที่ gstack พูดชัด AI แนะนำได้ แต่คนเป็นคนเคาะ

"AI models recommend. Users decide." AI แนะนำ คนตัดสินใจ นี่คือกฎที่อยู่เหนือกฎอื่นทั้งหมด

สองเจ้านี้เห็นตรงกันคือสัญญาณที่หนักแน่น แต่ไม่ใช่คำสั่ง ทั้ง pipeline รีวิวหลายมุมของ gstack และกฎ "คนเคาะ" ของ Else วางอยู่บนความเชื่อเดียวกัน เครื่องมือช่วยตั้งคำถามและกันพลาด แต่ไม่ตัดสินใจแทน

ช่วงที่ 3แล้วคนทำโปรดักต์ควรทำยังไง

กฎข้อเดียวที่อยากให้จำ

ถ้าจะหยิบไปข้อเดียว ขอให้เป็นข้อนี้ ให้ skill ทำส่วนที่เป็นโครงและการผลิต แล้วเอาเวลาที่ประหยัดได้ทั้งก้อน ไปลงกับการตัดสินใจ เพราะนั่นคือส่วนที่เหลืออยู่ของงาน

สามอย่างที่ยังเป็นของคุณ

เริ่มยังไงดี

ไม่ต้องรื้อ workflow ทั้งหมด ลองแค่นี้ก่อน

  1. หยิบงาน PM ที่คุณทำซ้ำ ๆ มาหนึ่งอย่าง เช่น เขียน PRD, ทำ competitive analysis, จัดลำดับ backlog
  2. หา framework ที่คุณใช้กับมันประจำ แล้วลองให้ AI ทำส่วนที่เป็นโครงให้
  3. จับเวลาว่าประหยัดไปเท่าไหร่ แล้วถามตัวเองว่าเวลาก้อนนั้นควรไปลงกับ "การตัดสินใจ" ข้อไหน
  4. อย่าเพิ่งเชื่อผลรวด เอาแนวคิด intended-vs-implemented มาจับ ของที่ได้ตรงกับที่ตั้งใจจริงไหม

สามคนนี้กำลังบอกเรื่องเดียวกันจากสามทิศ วันที่การลงมือทำถูกลงเรื่อย ๆ สิ่งที่แยกคนทำโปรดักต์ที่เก่งออกจากคนทั่วไป จะไม่ใช่ว่าใครรู้ framework เยอะกว่า แต่คือใครมี taste พอจะเลือกใช้ให้ถูก และมีวินัยพอจะไม่ปล่อยของห่วยออกไป ส่วนตัวเรากำลังลองประกอบ skill stack ของตัวเองจากแนวคิดพวกนี้อยู่ ได้เรื่องแล้วจะมาเล่าต่อ

ที่มาและอ้างอิง

อ่านต่อในซีรีส์

ติดตาม

รับบทความใหม่และของฟรีก่อนใคร

ทิ้งอีเมลไว้ บทความใหม่และของฟรีเป็นครั้งคราวจะส่งไปให้ ไม่สแปม

ใช้อีเมลเพื่อส่งอัปเดตเท่านั้น

ความคิดเห็น

ร่วมพูดคุย

แบ่งปันความคิดเห็นได้เลย

ชื่อจะแสดงต่อสาธารณะ อีเมลเก็บเป็นความลับ ไม่แสดงที่ไหน

กำลังโหลดความคิดเห็น…