อาทิตย์ก่อนเรานั่งไล่อ่าน 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 ทำส่วนที่เป็นโครงและการผลิต แล้วเอาเวลาที่ประหยัดได้ทั้งก้อน ไปลงกับการตัดสินใจ เพราะนั่นคือส่วนที่เหลืออยู่ของงาน
สามอย่างที่ยังเป็นของคุณ
- เลือก framework ให้ตรงบริบท skill หยิบ OST หรือ SWOT มาให้ได้ในวินาที แต่มันไม่รู้ว่าปัญหาตรงหน้าควรใช้อันไหน อันนั้นคุณรู้
- ตรวจว่าผลลัพธ์ตรงกับที่ตั้งใจไหม นี่คือหัวใจของ skill อย่าง intended-vs-implemented เอกสารสวยไม่ได้แปลว่าของตรง คนต้องอ่านช่องว่างนั้นเอง
- เป็นคนเคาะเอง โดยเฉพาะตอนที่ AI สองตัวเห็นตรงกันจนน่าเชื่อ นั่นแหละคือจังหวะที่ต้องระวังที่สุด
เริ่มยังไงดี
ไม่ต้องรื้อ workflow ทั้งหมด ลองแค่นี้ก่อน
- หยิบงาน PM ที่คุณทำซ้ำ ๆ มาหนึ่งอย่าง เช่น เขียน PRD, ทำ competitive analysis, จัดลำดับ backlog
- หา framework ที่คุณใช้กับมันประจำ แล้วลองให้ AI ทำส่วนที่เป็นโครงให้
- จับเวลาว่าประหยัดไปเท่าไหร่ แล้วถามตัวเองว่าเวลาก้อนนั้นควรไปลงกับ "การตัดสินใจ" ข้อไหน
- อย่าเพิ่งเชื่อผลรวด เอาแนวคิด intended-vs-implemented มาจับ ของที่ได้ตรงกับที่ตั้งใจจริงไหม
สามคนนี้กำลังบอกเรื่องเดียวกันจากสามทิศ วันที่การลงมือทำถูกลงเรื่อย ๆ สิ่งที่แยกคนทำโปรดักต์ที่เก่งออกจากคนทั่วไป จะไม่ใช่ว่าใครรู้ framework เยอะกว่า แต่คือใครมี taste พอจะเลือกใช้ให้ถูก และมีวินัยพอจะไม่ปล่อยของห่วยออกไป ส่วนตัวเรากำลังลองประกอบ skill stack ของตัวเองจากแนวคิดพวกนี้อยู่ ได้เรื่องแล้วจะมาเล่าต่อ
ที่มาและอ้างอิง
- gstack โดย Garry Tan (github.com/garrytan/gstack) คำพูด "กำแพงด้านวิศวกรรมหายไปแล้ว…" และ "AI models recommend. Users decide." มาจากไฟล์ ETHOS.md ส่วนตัวเลข productivity เป็นการวัดของผู้เขียนเอง ไม่ใช่ benchmark กลาง
- pm-skills โดย Pawel Huryn (github.com/phuryn/pm-skills) คำพูด "Generic AI gives you text. PM Skills Marketplace gives you structure." มาจาก README
- product-discovery-skills โดย Else van der Berg (github.com/Elsevanderberg1/product-discovery-skills) กฎ "ความสำคัญต่ำกว่า 4 ไม่ไล่" มาจาก skill ชื่อ opportunity-sizer
อ่านต่อในซีรีส์
- GTM Strategist skills ของ Maja Voje ย่อยกลยุทธ์ go-to-market ทั้งชั้นให้ไล่ทำเป็นสเต็ป
- gstack ของ Garry Tan agentic coding ที่ยกเรื่อง taste ขึ้นเป็นด่านบังคับ
- product-discovery-skills ของ Else van der Berg continuous discovery สาย Teresa Torres ทำเป็นสายพาน
- pm-skills ของ Pawel Huryn รวมวิชา PM ราว 68 skill ให้เรียกได้ด้วยคำสั่งเดียว