หลายองค์กรมี discovery session มี brainstorm มี workshop แต่สุดท้ายไอเดียดีๆ ไม่ถูกนำไปใช้ Product ที่ออกมาไม่บรรลุเป้าหมาย และ Tech foundation ไม่ได้ถูกออกแบบให้รองรับการเติบโต
ปัญหาไม่ใช่ขาดไอเดีย — แต่คือ discovery ที่ไม่สะสมเป็นความรู้ขององค์กร
บางครั้ง product ก็ไปได้ดี แต่ทีมไม่รู้ว่าเกิดอะไรขึ้นจริงๆ
Discovery ที่ไม่สะสมเป็นความรู้ คือการลงทุนที่ไม่ได้ผลตอบแทน — ทุกครั้งที่ทำ ก็เหมือนเริ่มต้นใหม่ ต้นทุนสูงขึ้นเรื่อยๆ แต่ผลลัพธ์ไม่ดีขึ้น
Cost of Rework แพงกว่าที่คิด
สิ่งเหล่านี้ วัดเป็นตัวเลขได้ — และมักแพงกว่าค่าใช้จ่ายในการปรับปรุงกระบวนการ
"ไม่มีเวลา" "วัดผลไม่ได้" "เอาเวลาไปทำอย่างอื่นดีกว่า"
Discovery มักถูกมองว่าเป็นแค่ กิจกรรมหาไอเดียใหม่ — ไม่ใช่กระบวนการสร้างความรู้ขององค์กร
แต่ความจริงคือ: เวลาที่ใช้กับ discovery ที่มีคุณภาพ จะคืนกลับมาในรูปของ ไม่ต้อง rework, ไม่ต้องเถียงกันซ้ำๆ, ไม่ต้องสร้าง feature ที่ไม่มีคนใช้
การลงทุนเวลาตอนต้น ประหยัดเวลา (และเงิน) มากกว่าในระยะยาว
เมื่อ discovery ไม่มีกระบวนการที่ดี — เสียงรบกวนจะเข้ามาบดบังความต้องการที่แท้จริง ทั้งของลูกค้า ของทีม และขององค์กร
ไม่ชัดว่าตัวเองต้องการอะไรจริงๆ มี bias ที่ไม่รู้ตัว ความเชื่อเดิมที่ไม่เคยถูกตั้งคำถาม
→ ตัดสินใจโน้มเอียง ผลักดันสิ่งที่ไม่ใช่ priority จริง
Product ↔ Tech ↔ Business พูดคนละภาษา บางคนพูดดังเกินไป บางคนไม่กล้าพูด
→ ไม่เห็นมุมมองที่ต่าง ตัดสินใจจาก bias ของคนที่เสียงดังที่สุด
Politics หวงข้อมูล แข่งขันกันเอง แต่ละฝ่ายมีเป้าที่ไม่ตรงกัน
→ ไม่ align กับเป้าหมายใหญ่ Resource ถูกใช้ไปกับสิ่งที่ไม่สร้างคุณค่า
ฟังเพื่อยืนยัน assumption เดิม ไม่ได้ฟังลึกจริง ไม่เปิดรับสิ่งที่ไม่คาดคิด
→ สร้าง product ที่ไม่ตอบโจทย์ เสียเวลา dev ฟรี
เสียงรบกวนเหล่านี้คือ ปัญหาเชิงโครงสร้างและกระบวนการ ที่ทำให้ความต้องการที่แท้จริงของบริษัทถูกลดทอนลงไป — และมักจะแก้ไม่ได้ด้วยการ "พยายามมากขึ้น"
การเห็นชัดว่าเรากำลังทำอะไรอยู่ ทำไปเพื่ออะไร และอะไรคือสิ่งที่บดบังการมองเห็นของเรา — นี่คือจุดเริ่มต้นของการแก้ปัญหาที่แท้จริง
กระบวนการที่ช่วยให้ทีม Product และ Management สามารถเห็นภาพร่วมกัน — และเปลี่ยน discovery จาก "กิจกรรม" เป็น "กระบวนการที่สะสมความรู้"
รู้ว่ากำลังทำอะไร ทำไปเพื่ออะไร เห็น bias ของตัวเอง และยอมรับได้
Product ↔ Tech ↔ Business เข้าใจกัน พูดภาษาเดียวกัน เห็นเป้าร่วม
ไม่ต้องเริ่มจากศูนย์ทุกครั้ง ความรู้สะสมเป็นขององค์กร
ทำถูกตั้งแต่แรก ลดการทำแล้วรื้อ รื้อแล้วทำ
สิ่งนี้จะเป็นประตูเปิดสู่การค้นพบโอกาสใหม่ๆ อย่างแท้จริง — เพราะปัญหา มุมมอง และความต้องการได้ถูกสื่อสารแลกเปลี่ยนกันแล้ว
ข้อกังวลที่เข้าใจได้ — และคำตอบที่ตรงไปตรงมา
"จะส่งผลต่อธุรกิจได้จริงแค่ไหน?"
ตรงไปตรงมา: เราไม่ได้มาสัญญาว่าทุกอย่างจะดีขึ้นทันที — แต่เราจะ มาร่วมเรียนรู้ด้วยกัน เห็นการเปลี่ยนแปลงด้วยกัน และค่อยๆ สร้างกระบวนการที่เหมาะกับทีมของคุณ สิ่งที่จะเกิดขึ้นคือคุณค่าที่ค่อยๆ ซึมลงไปใน culture — ไม่ใช่ quick fix แต่เป็นการลงทุนที่สะสม
"เพิ่มภาระประชุมอีกแล้ว? เวลาเขียนโค้ดจะหายไปหรือเปล่า?"
ตรงไปตรงมา: เป้าหมายคือ ลดการประชุมที่ไม่จำเป็น ไม่ใช่เพิ่ม — เมื่อทุกคน align กันตั้งแต่แรก ไม่ต้องประชุมซ้ำเพื่อเถียงกันเรื่องเดิม และที่สำคัญ: นี่คือกระบวนการที่จะทำให้ เสียงของ Tech ดังขึ้นในฝั่ง Business — Technical Constraints จะถูกรับฟังตั้งแต่ต้น ไม่ใช่ถูกบอกว่า "ทำไปก่อน"
"บทบาทของเราจะทำงานร่วมกันยังไง?"
ตรงไปตรงมา: เราจะเป็น partner กัน ในการทำให้ discovery สำเร็จ — PM ยังคงเป็นคน lead product ตามเดิม keen มาช่วยในส่วนที่ต้องการมุมมองคนนอก เช่น การตั้งคำถามที่คนในไม่สะดวกถาม หรือช่วยให้การสื่อสารระหว่างฝ่ายราบรื่นขึ้น เป้าหมายคือทำให้งานของ PM ง่ายขึ้น ไม่ใช่เพิ่มภาระ
Discovery ไม่ใช่แค่ workshop ครั้งเดียว — แต่คือ habit ของการมองหาการเรียนรู้
ปรับเปลี่ยน และส่งมอบคุณค่าใหม่ๆ อยู่ตลอดเวลา
ไม่มีสูตรสำเร็จ — กระบวนการต้องสอดคล้องกับทีม กับองค์กร เปิดกว้างและเข้าใจปัญหาที่เผชิญอยู่
บริบทของแต่ละทีมแตกต่างกัน สิ่งที่ใช้ได้กับที่หนึ่ง อาจไม่ใช่คำตอบของอีกที่
ไม่ใช่การแทรกแซง แต่คือการ "ร่วมเดินทาง"
เราเข้าใจดีว่า การมี "คนนอก" เข้ามาในกระบวนการ discovery เป็นเรื่องที่ต้องใช้ความไว้วางใจ
การทำงานของ keen จึงไม่ใช่การเดินเข้าไปแล้วบอกว่า "พวกคุณต้องทำอะไร" — แต่เราเน้นกระบวนการที่ เคารพในบริบทของทีม เป็นที่ตั้ง
เราจะไม่กระโจนเข้าหา solution ในทันที — แต่จะใช้เวลาทำความเข้าใจว่าทีมเผชิญกับอะไรอยู่จริงๆ
กระบวนการจะถูกออกแบบร่วมกับทีม ไม่ใช่เอา template มาใส่
ข้อดีของการที่เราเป็นคนนอก คือเราไม่มีส่วนได้ส่วนเสียกับการเมืองภายใน — เราจึงสามารถตั้งคำถามที่คนในไม่สะดวกถาม
เป้าหมายคือให้ทีมทำต่อได้เอง — ไม่ใช่พึ่งพา Facilitator ตลอดไป
Awareness-Based Facilitation Team
กระบวนกรหลากหลายความเชี่ยวชาญจาก muse และเครือข่าย ALT
keen คือทีมพิเศษที่สามารถดึงกระบวนกรที่เหมาะสมเข้ามาเพื่อตอบโจทย์ของแต่ละทีม — ความหลากหลายทั้งด้านอายุ เพศ และความเชี่ยวชาญที่ลึกซึ้งของแต่ละคน ทำให้เราสามารถจับคู่กระบวนกรที่ "คลิก" กับทีมของคุณได้
ประสบการณ์รวมกันในวงการ digital/web กว่า 30 ปี ผ่านบทบาททั้งผู้ก่อตั้ง ผู้บริหาร และผู้ปฏิบัติงานจริง — ผสมผสานกับความเชี่ยวชาญด้าน Coaching, Organization Development, และ Mindfulness-based Approach
เราเคยอยู่ในวงจรของการ "สร้าง-ส่งมอบ-สร้างต่อ" ที่ไม่มีวันหยุด จนหมดไฟ จนสับสน จนไม่รู้ว่าทำไปเพื่ออะไร — และผ่านมาแล้ว วันนี้เราใช้กระบวนการ facilitation ช่วยทีม product และ management เห็นภาพร่วมกัน และสร้างกระบวนการ discovery ที่ยั่งยืน
Sira Sujjinanont
CTO & Co-founder, Fintech | Digital/Web ~30 ปี | เข้าใจทั้งมุม Tech, Product และ Business
[ชื่อจริง]
[ความเชี่ยวชาญ เช่น Organization Development, Executive Coaching]
[ชื่อจริง]
[ความเชี่ยวชาญ เช่น Mindfulness-based Facilitation, Team Coaching]
เราเชื่อว่ากระบวนกรที่ "ใช่" สำหรับทีมหนึ่ง อาจไม่ใช่คำตอบของอีกทีม — keen จึงมีกระบวนกรหลากหลายทั้งอายุ เพศ และความเชี่ยวชาญ เพื่อให้คุณได้คนที่ "คลิก" กับทีมของคุณจริงๆ
ตั้งแต่ผู้บริหารสูงสุด จนถึงคนปฏิบัติงานจริง เข้าใจความท้าทายของทุกระดับ
ไม่ใช่คนนอกมาบอกว่าต้องทำอะไร แต่คือทีมที่เคยอยู่ตรงนั้น เคยเห็น discovery ที่ไม่ไปไหน เคยเห็นทีมอ่อนล้า — และผ่านมาแล้ว
พูดภาษาของทั้งสามฝ่ายได้ ช่วยแปลความต้องการระหว่างกัน เป็นกันชนที่ยืดหยุ่น ปรับระยะเข้าออกได้ เพื่อให้ทีมขับเคลื่อนได้ดียิ่งขึ้น
จาก Startup ที่ขับเคลื่อนด้วย Founder สู่ Organization ที่ขับเคลื่อนด้วย System — ช่วงเวลานี้ต้องการกระบวนการที่รองรับการเติบโต
ก่อน: ทำ workshop หาไอเดีย → ได้ไอเดียเยอะ → ไม่มีใคร own → ไอเดียจมหาย → ทำซ้ำทุก quarter
หลัง: Facilitate ให้เห็นว่าใครต้องการอะไรจริง → Align priority → มีคน own ชัด → ไอเดียถูกนำไปทำ → บทเรียนถูกถอด
ก่อน: Product อยากได้ feature ใหม่ → Tech บอกทำไม่ได้ → เถียงกันไม่จบ → ออกมาแบบประนีประนอม → ไม่มีใครพอใจ
หลัง: Facilitate ให้ฟังกันจริงๆ → พบว่า Tech กังวลเรื่อง technical debt → Product ไม่เคยรู้ → ปรับ scope ร่วมกัน → ได้ผลลัพธ์ที่ดีกว่า
ก่อน: สัมภาษณ์ลูกค้า → ฟังเพื่อยืนยัน assumption เดิม → สร้าง feature ที่คิดว่าลูกค้าอยากได้ → ไม่มีคนใช้
หลัง: Facilitate ให้ฟังแบบเปิดกว้าง → พบ insight ที่ไม่คาดคิด → ปรับทิศทาง product → ตอบโจทย์จริง
Discovery ที่ดีวัดผลได้จาก: % ของไอเดียที่ถูกนำไปใช้จริง, จำนวน rework ที่ลดลง, time-to-market ที่เร็วขึ้น — สิ่งเหล่านี้วัดเป็นตัวเลขได้ และส่งผลต่อ bottom line โดยตรง
คำถามคือ: ไปเร็วแล้วต้องรื้อทำใหม่ กับไปช้าหน่อยแต่ทำถูกตั้งแต่แรก — อันไหนเร็วกว่ากันในระยะยาว? การลงทุนเวลากับกระบวนการที่ดีตอนต้น มักประหยัดเวลามากกว่าในท้ายที่สุด
คนในมักมี bias และ power dynamic ที่ทำให้ไม่เห็นบางมุม — คนนอกสามารถตั้งคำถามที่คนในไม่สะดวกถาม และเป็นพื้นที่ว่างให้ทุกเสียงออกมา โดย PM ยังคงเป็นคน lead product ตามเดิม
นั่นคือสิ่งที่เราต้องการหลีกเลี่ยงเช่นกัน — เป้าหมายคือการสร้าง "กระบวนการที่ยั่งยืน" ไม่ใช่แค่ "กิจกรรม" กระบวนการจะถูกออกแบบให้ทีมสามารถทำต่อได้เองหลังจากเราไป
ไม่ — และนั่นไม่ใช่เป้าหมาย เราไม่ได้มาบอกว่าคุณควรทำอะไร แต่มาช่วยให้ทีมเห็นในสิ่งที่อาจมองข้าม และช่วยให้การสื่อสารระหว่างฝ่ายราบรื่นขึ้น — คนที่รู้บริบทดีที่สุดคือทีมของคุณ
เปิดรับความเป็นไปได้ใหม่ๆ
การสร้างกระบวนการ discovery ที่ยั่งยืนไม่ได้เกิดขึ้นในวันเดียว — แต่มันเริ่มจากการยอมรับว่ามีบางอย่างที่เราอาจมองไม่เห็น
เชื่อมั่นว่าทีมมีความสามารถในการเรียนรู้ พัฒนาและเติบโตได้
และเมื่อทีมเติบโตแข็งแรง พวกเขาจะสร้าง impact กับบริษัทได้มากมายเพียงใด
เพราะกระบวนการที่ดีต้องเริ่มจากความเข้าใจ — บริบทของทีมคุณ
เราอยากชวนมาจิบกาแฟ หรือพูดคุยกันสั้นๆ สัก 30 นาที
ไม่ใช่เพื่อขายของ แต่เพื่อ:
• เล่าบริบทของทีมและความท้าทายที่เผชิญอยู่
• ลองดูว่าแนวทางของเราตอบโจทย์หรือไม่
• หรือเพียงแค่แลกเปลี่ยนมุมมองเรื่อง Product Discovery
ถ้าคุยแล้วไม่ใช่ ก็ไม่เป็นไรเลยครับ
อย่างน้อยเราก็ได้แลกเปลี่ยนเรียนรู้กัน