📖 Playbook

Startup POC Playbook

เนื้อหาทั้งหมดที่สอนในวันนี้ — อ่านทบทวนได้ตลอด

📑 สารบัญ
  1. Design Thinking Process
  2. POC vs MVP
  3. Problem Statement
  4. Fail Fast & Validation Ladder
  5. 5 Whys / Root Cause Analysis
  6. เทคนิค Validation: Wizard of Oz, Concierge, Fake Door
  7. จริยธรรมของ Fake Door
  8. กับดัก Problem ที่พบบ่อย

📐 1. Design Thinking Process

กระบวนการคิดเชิงออกแบบ 5 ขั้นตอน — ไม่ใช่เส้นตรง แต่เป็น วงวน

Empathize → Define → Ideate → Prototype → Test
↻ วนซ้ำ! Test แล้วกลับมา Prototype ใหม่

แต่ละขั้นตอน:

  • Empathize — ไปคุยกับคนจริงๆ ที่มีปัญหา ฟัง เข้าใจ อย่าเดา
  • Define — สรุปปัญหาให้ได้ 1 ประโยค ชัดเจน
  • Ideate — คิด solution หลายๆ แบบ ยังไม่ต้องเลือก
  • Prototype — ทำให้จับต้องได้ ไม่ต้องสมบูรณ์แบบ
  • Test — เอาไปให้คนอื่นลอง แล้วฟัง feedback
🔑 Key Message: "ทีมที่ชนะไม่ใช่ทีมที่ idea เจ๋งที่สุด แต่เป็นทีมที่ วน loop Prototype → Test เร็วที่สุด"

💡 2. POC vs MVP

POC (Proof of Concept) MVP (Minimum Viable Product)
คำถาม "ทำได้ไหม?" "มีคนอยากใช้ไหม?"
ทำเพื่อ ตัวเอง / ทีม User
ผ่าน = มันทำได้จริง คนใช้ซ้ำ + บอกต่อ
ระยะเวลาเข้าใจ ไม่จำกัด 30 วินาที
🎯 30-Second Test
"ถ้าใครเห็น prototype แล้วไม่เข้าใจใน 30 วินาที ว่ามันแก้ปัญหาอะไร → ยังไม่ผ่าน"

📝 3. Problem Statement

MVP ที่ดีเริ่มจาก Problem ที่ชัด:

"[กลุ่มเป้าหมาย] มีปัญหา [อะไร] เพราะ [สาเหตุ]"

❌ ตัวอย่างที่ไม่ดี:

  • "คนไทยมีปัญหาสุขภาพ" → กว้างเกินไป ไม่รู้จะทำอะไร
  • "เราจะสร้างแอปสุขภาพ" → เริ่มจาก solution ไม่ใช่ problem

✅ ตัวอย่างที่ดี:

  • "นักศึกษาหอพักกินข้าวไม่ตรงเวลาเพราะร้านอาหารปิดก่อน 2 ทุ่ม"
  • "ผู้สูงอายุในชนบทเข้าถึงแพทย์ช้าเพราะต้องเดินทางไกลกว่า 50 กม."
💡 Tips: ถ้าเขียน Problem กว้างเกินไป → ถามตัวเองว่า "ใครคือคนที่มีปัญหานี้มากที่สุด? คนคนเดียวเลย" → ช่วย focus

⚡ 4. Fail Fast & Validation Ladder

ล้มเร็ว เรียนรู้เร็ว — ราคาของความล้มเหลวขึ้นอยู่กับว่าล้มตรงขั้นไหน

💻
ขั้น 4: CODE
ต้นทุน ~500,000 บาท — "ถ้าล้มตรงนี้ เจ็บมาก"
🔧
ขั้น 3: MANUAL (มือหมุน)
ต้นทุน ~5,000 บาท — "ลองขายด้วย Line / Excel"
📄
ขั้น 2: PAPER
ต้นทุน ~5 บาท — "วาดให้ดู ถามว่าเก็ต?"
🗣️
ขั้น 1: TALK
ต้นทุน 0 บาท — "เล่าปากเปล่า ดูปฏิกิริยา"
🔴 Loop of Death (สิ่งที่ห้ามทำ)
Idea → Build App → Launch → Fail — เสียเงินและเวลาฟรี กระโดดข้ามจากขั้น 1 ไปขั้น 4 เลย!
🟢 Survival Loop (สิ่งที่ต้องทำ)
  1. Talk — เล่าปากเปล่า ถ้าเขาเมิน = จบ/เปลี่ยนไอเดียทันที
  2. Paper (Sketch) — วาดใส่กระดาษให้เห็นภาพ ถ้าเขาไม่เก็ต = วาดใหม่
  3. Manual (Lean Service) — ทำระบบ "มือหมุน" ที่รับเงินได้จริง ถ้าเขาไม่จ่าย = เลิกทำ
  4. MVP — ค่อยสร้างของจริงเมื่อผ่านข้อ 3 แล้วเท่านั้น
🔑 Mantra: "Code is the last thing you should write."
โค้ดคือสิ่งสุดท้ายที่ควรเขียน

🏠 Mini Case: "Uber for Maids" (แอปจองแม่บ้าน)

❌ Wrong Way (จ้าง Dev เขียนแอป)
จ้าง Dev เขียนแอป 6 เดือน + เชื่อม Payment Gateway + ทำระบบ GPS Tracking → Burn เงินไป 1 ล้านบาท โดยยังไม่มีลูกค้าสักคน
✅ Intust Style (The Lean Way)
  1. สร้าง Facebook Page ยิง Ads เจาะกลุ่มแม่บ้านคอนโด
  2. ปุ่ม "จองเลย" ลิงก์ไปที่ Line OA
  3. เมื่อลูกค้าทักแชท → เราตอบเอง (ตกลงราคา/นัดเวลา)
  4. ลูกค้าโอนเงิน → เข้าบัญชีธนาคารเราโดยตรง (ส่งสลิปในไลน์)
  5. ระบบหลังบ้าน → เราโทรศัพท์หาป้าแม่บ้าน ให้ไปตามนัด
💡 Key Takeaway: "เห็นไหมครับ ธุรกิจรันแล้ว ได้เงินแล้ว โดยไม่มีแอปสักตัว ถ้าทำแบบนี้แล้วรุ่ง ค่อยเอา AI มาสร้างทีหลังก็ยังทัน"

🔍 5. Five Whys / Root Cause Analysis

Root Cause (สาเหตุที่แท้จริง) คือ "ต้นตอ" ของปัญหา ไม่ใช่แค่ "อาการ" ที่มองเห็นภายนอก — ถ้าแก้ผิดจุด ก็เหมือนเกาไม่ถูกที่คัน

🧊 อาการ (Symptom) vs ต้นตอ (Root Cause)

อาการ (Symptom): สิ่งที่เรามองเห็น (เช่น มีไข้, ปวดหัว) → แก้ด้วยยาแก้ปวด (ชั่วคราว)
ต้นตอ (Root Cause): สาเหตุจริงๆ (เช่น ติดเชื้อแบคทีเรีย) → แก้ด้วยยาฆ่าเชื้อ (หายขาด)

🧊 ภูเขาน้ำแข็ง — "เด็กหอทิ้งขยะไม่ลงถัง"

❓ Why 1: ทำไมทิ้งขยะเกลื่อน? → เพราะเด็กขี้เกียจเดิน (อันนี้คือ "โทษ User" — ถ้าหยุดตรงนี้ Solution = ติดป้ายรณรงค์ ซึ่งไม่ได้ผล!)

❓ Why 2: ทำไมถึงขี้เกียจเดิน? → เพราะถังขยะอยู่ไกล ตั้งแค่ชั้นล่างสุด

❓ Why 3: ทำไมถังขยะต้องอยู่ชั้นล่าง? → เพราะแม่บ้านขี้เกียจขึ้นมาเก็บหลายชั้น

❓ Why 4: ทำไมแม่บ้านขี้เกียจขึ้นมาเก็บ? → เพราะลิฟต์ขนของเสียบ่อย / รถเข็นขยะหนักเกินเข้าลิฟต์ไม่ได้

🎯 Root Cause
ปัญหาไม่ใช่ "เด็กนิสัยไม่ดี" แต่คือ "Process การเก็บขยะของแม่บ้านมันยาก ทำให้ไม่มีถังวางตามชั้น"

✅ Solution ที่ถูกต้อง: ออกแบบรถเข็นเก็บขยะใหม่ที่เข้าลิฟต์ได้ หรือทำระบบท่อทิ้งขยะ (Chute) จากชั้นบนลงชั้นล่าง → พอมีที่ทิ้งใกล้ตัว เด็กก็เลิกทิ้งเกลื่อนเอง

ถ้า Root Cause ผิด → Prototype พัง

❌ ผิด: เด็กหอ มีปัญหา ขยะล้นห้อง เพราะ เป็นคนสกปรก
→ Prototype: แอปแจ้งเตือนให้รักความสะอาด (ไร้สาระ ไม่มีใครโหลด)
✅ ถูก: เด็กหอ มีปัญหา ขยะล้นห้อง เพราะ จุดทิ้งขยะอยู่ไกลเกิน 100 เมตร
→ Prototype: บริการรับฝากทิ้งขยะหน้าห้อง (Uber for Trash) หรือถังขยะอัจฉริยะหน้าลิฟต์ ← อันนี้ทำเงินได้
🔑 จำไว้: "Root Cause คือสาเหตุที่ถ้าเรากำจัดมันออกไปได้ ปัญหานั้นจะไม่เกิดขึ้นอีกเลย — อย่าโทษที่ 'คน' (User Error) ให้โทษที่ 'ระบบ/เครื่องมือ' (Design Error) แล้วเราจะเห็นโอกาสทำ Startup"

🧪 6. เทคนิค Validation

🎩 Wizard of Oz

หน้าบ้านดู High-tech (เหมือนมี AI/Automation) แต่หลังบ้านใช้คน (Human) ทำงานแทน

  • ความรู้สึกลูกค้า: ลูกค้าคิดว่า "กำลังใช้ระบบอัตโนมัติ" (แต่จริงๆ มีคนซ่อนอยู่หลังม่าน)
  • เป้าหมาย: เพื่อทดสอบ Feature/Flow ว่าถ้าระบบเสร็จจริง คนจะใช้ไหม
  • ตัวอย่าง: Santabox — ลูกค้ากรอกฟอร์มแล้วได้ SMS คิดว่าเป็นระบบ Auto (แต่จริงๆ คุณอินทัธนั่งพิมพ์เอง)
  • Keyword: "High Tech (Fake)" — แกล้งทำเป็นเทค

🤝 Concierge

บริการลูกค้าด้วยมือตัวเองแบบ VIP (Manual Service) เพื่อเรียนรู้พฤติกรรม

  • ความรู้สึกลูกค้า: ลูกค้ารู้ตัวว่า "กำลังคุยกับมนุษย์"
  • เป้าหมาย: เพื่อเรียนรู้ Insight เชิงลึก และสร้างความพึงพอใจสูงสุด
  • ตัวอย่าง: RE-invent — จ้างนิสิตไปยืนขายน้ำยาซักผ้าใต้หอ ข้อดีคือถามเขาได้เลยว่า "ทำไมเลือกกลิ่นนี้?" "ทำไมไม่เอาขวดมา?"
  • Keyword: "High Touch" — สัมผัสใจ

🎩🤝 ความต่างของ Concierge vs Wizard of Oz

น้องๆ มักจะงงว่า 2 อันนี้ "ก็ใช้คนทำเหมือนกันนี่นา?" จริงๆ มี Psychology ที่ต่างกันครับ

🤝 Concierge 🎩 Wizard of Oz
ลูกค้ารู้ไหม? รู้ว่าคุยกับคน คิดว่าเป็นระบบ Auto
เป้าหมาย เรียนรู้ Insight เชิงลึก ทดสอบ Feature/Flow
Keyword High Touch (สัมผัสใจ) High Tech (Fake)
ใช้เมื่อ อยากรู้เหตุผลว่า "ทำไม" ลูกค้าซื้อ อยากรู้ว่า "ระบบ" เวิร์คไหม
💡 "ถ้าอยากรู้เหตุผลว่า 'ทำไม' ลูกค้าถึงซื้อ ให้ใช้ Concierge (เดินไปถาม/ขายเอง)... แต่ถ้าอยากรู้ว่า 'ระบบ' เราเวิร์คไหม ให้ใช้ Wizard of Oz (แอบทำหลังบ้าน)"

🚪 Fake Door

แปะป้ายขายของที่ยังไม่มีจริง เพื่อวัดยอดคนกด (Click-through Rate)

  • สร้าง Landing Page สวยๆ ขาย "โปรแกรม AI ตรวจจับฝุ่น" ใส่ปุ่ม "ซื้อเลย 999 บาท"
  • พอลูกค้ากด → ขึ้นหน้าจอว่า "Coming Soon / สินค้าหมดชั่วคราว"
  • แล้วนับจำนวนคนที่กดปุ่มเพื่อ วัด Demand

⚖️ 7. จริยธรรมของ Fake Door

Fake Door ทรงพลังมาก แต่ถ้าทำไม่ดี แบรนด์จะเสียครับ:

⚠️ ความเสี่ยง
ถ้าลูกค้ากดซื้อ จ่ายเงินตัดบัตรไปแล้ว แล้วเราบอกว่า "ล้อเล่น ของยังไม่มี" → ลูกค้าด่าแน่นอน และแบรนด์พังทันที
✅
อย่าเพิ่งตัดเงิน
ปุ่มกดควรเป็น "Pre-order" หรือ "Join Waitlist" หรือ "Check Availability" — อย่าตัดเงินจริง
✅
ให้รางวัลปลอบใจ
ถ้าเขากดเข้ามาแล้วเจอว่าของหมด/ยังไม่มา ให้มอบ Discount Code หรือสิทธิพิเศษให้เขาแทนคำขอโทษ
❌
สิ่งที่ห้ามทำ
รับเงินจริงแล้วไม่ส่งของ / โฆษณาเกินจริงจนคนเข้าใจผิด → ได้ศัตรูแทนลูกค้า
🔑 "Fake Door เอาไว้ วัดความสนใจ ไม่ใช่เอาไว้หลอกเอาเงิน ถ้าเขากดเข้ามาแล้วรู้ความจริงว่าของไม่มี น้องต้อง 'รับผิดชอบความรู้สึก' เขาด้วย ไม่งั้นจะได้ศัตรูแทนลูกค้าครับ"

⚠️ 8. กับดัก Problem ที่พบบ่อย

🪤 กับดัก 1: Problem กว้างเกินไป
"คนไทยมีปัญหาจราจร" → ใครคือคนที่เจ็บปวดที่สุด? แม่ค้าที่ต้องส่งของตอนเช้า?
🪤 กับดัก 2: เริ่มจาก Solution
"เราอยากทำแอป X" → ต้องถามก่อนว่า Problem คืออะไร
🪤 กับดัก 3: โทษ User
"คนไม่ดูแลสุขภาพ" → Root Cause อาจเป็นเรื่องเวลา/เงิน/การเข้าถึง — "อย่าโทษที่ 'คน' ให้โทษที่ 'ระบบ'"
🪤 กับดัก 4: ไม่คุยกับ "คนจ่ายเงินตัวจริง"
Glurr Talk สอนภาษาเด็กมัธยม แต่ไม่ได้ถาม "ผู้ปกครอง" ว่าจ่ายเพื่ออะไร → Pivot
🪤 กับดัก 5: "Problem = Lack of My Solution"
นี่คือสิ่งที่เด็กวิศวะทำผิด 99%!
❌ ผิด: "ปัญหาคือ คนไทยยังไม่มีแอปเรียกรถเก็บขยะ" → นี่คือการยัดเยียด Solution เข้าไปในปัญหา
✅ ถูก: "ปัญหาคือ ขยะตามบ้านเหม็นเน่าและหนูขึ้น เพราะรถขยะมาเก็บไม่ตรงเวลา" → Solution อาจไม่ใช่แอป! อาจเป็น "ถังขยะสุญญากาศ" หรือ "ไลน์กลุ่มแจ้งเตือนรถขยะ" ซึ่งง่ายกว่า
🔑 จำไว้: "น้องครับ ห้ามเขียนปัญหาว่า 'ลูกค้าไม่มีแอปของผม' เด็ดขาด! เพราะก่อนที่น้องจะเกิดมาบนโลกนี้ ลูกค้าเขาก็อยู่ได้... ให้เขียนว่าเขาลำบากยังไง เจ็บปวดตรงไหน ไม่ใช่ขาดอะไร"
🚀 สรุปสุดท้าย: "ทำแล้วต้องเทสกับลูกค้าจริงๆ — ถ้าไม่มี Data ตัวเลขการเงินก็คือเรื่องมโน"