สองในสามของงานดีพลอยของเราตอนนี้ทำโดยอัตโนมัติด้วยผลิตภัณฑ์ของเราเอง (ผ่าน Duet
โพสต์นี้พูดถึงว่าทำไมถึงเป็นแบบนั้น ปรัชญาของเราในการสร้างผลิตภัณฑ์ + ขบวนการดีพลอย และมันวิวัฒนาการมาอย่างไร
สิ่งที่เราเคยดูถูก ตอนนี้กลายเป็นคำตอบเริ่มต้น
"Forward deployed engineer" กลายเป็นคำตอบของเกือบทุกคำถามยากในการนำ AI ออกสู่ตลาด ดีพลอยยากไหม? จ้าง FDE สิ ลูกค้าช่วยตัวเองไม่ได้? FDE สิ สินค้ายังไม่พร้อม? FDE สิ ทั้ง Anthropic และ OpenAI ต่างตั้งทีมดีพลอยระดับองค์กรโดยจำลองมาจาก Palantir และแทบทุกบริษัทซีดสเตจที่ผมคุยด้วยตอนนี้มีประกาศรับสมัคร FDE ว่ากันว่าจำนวนประกาศรับสมัครตำแหน่งนี้เพิ่มขึ้นหลายร้อยเปอร์เซ็นต์ในปีที่ผ่านมา
ที่แปลกคือ จนกระทั่งเมื่อไม่นานมานี้ สิ่งนี้คือสิ่งที่คุณถูกวิพากษ์วิจารณ์ การส่งวิศวกรไปประจำที่ลูกค้าถูกมองว่าเป็นสัญญาณว่าคุณไม่มีผลิตภัณฑ์จริง รายได้ของคุณมีคุณภาพต่ำกว่า และมาร์จินของคุณถูกจำกัดโดยโครงสร้าง ไม่มีอะไรเปลี่ยนไปในเชิงเศรษฐศาสตร์พื้นฐาน
หัวใจของ FDE คือพวกเขาส่งมอบผลลัพธ์ (outcomes) ซึ่งเจ๋งมากในยุค AI เพราะองค์กรอาจไม่แน่ใจว่าเส้นทางไปสู่ผลลัพธ์คืออะไร แต่ชัดเจนว่า AI ให้ผลลัพธ์ที่น่าสนใจ
ในเวลาเดียวกัน บทบาทนี้เริ่มถูกใช้มากเกินไป และไม่ควรเป็นไม้ค้ำยันเพื่อซ่อนปัญหาเชิงโครงสร้าง
"FDE กินความเจ็บปวดแล้วขับถ่ายออกมาเป็นผลิตภัณฑ์"
Palantir (ที่ @AshwinSreenivas เพื่อนผู้ร่วมก่อตั้งของผมมาจากที่นั่น) ทำให้บทบาทนี้เป็นที่นิยมในช่วงกลางยุค 2000 จากการขาย Gotham ให้ CIA, NSA และหน่วยข่าวกรองกองทัพบก และพวกเขาก็แบกรับคำวิจารณ์มานาน Joe Lonsdale หนึ่งในผู้ร่วมก่อตั้ง เขียนไว้ว่า ตลอดเกือบสองทศวรรษ มุมมองหลักของคนส่วนใหญ่ต่อ Palantir คือมันเป็นแค่บริษัทที่ปรึกษาเก๋ๆ ไม่ใช่บริษัทเทคโนโลยีจริง และมุมมองนั้นมีพื้นฐานมาจากข้อเท็จจริง นั่นคือวิศวกรจำนวนมากของพวกเขาใช้เวลาส่วนใหญ่นั่งอยู่กับลูกค้า
แต่ Shyam Sankar CTO ของ Palantir มีประโยคที่เขาพูดซ้ำๆ ตลอด: FDE กินความเจ็บปวดแล้วขับถ่ายออกมาเป็นผลิตภัณฑ์
การดีพลอย Gotham ในยุคแรกของ Palantir เป็นงานเฉพาะกิจอย่างลึกซึ้ง สร้างขึ้นเพื่อตอบคำถามด้านข่าวกรองข้อเดียวสำหรับหน่วยเดียว Palantir แปลงปัญหาที่พวกเขาเห็นเป็นพรีมิทีฟของแพลตฟอร์ม: ontology, object models, การกำหนดสิทธิ์, workflow engines, การติดตามที่มา (provenance tracking) พรีมิทีฟเหล่านั้นกลายเป็น Foundry และ Foundry กลายเป็นสิ่งที่ขายเชิงพาณิชย์ได้ Apollo และ AIP เดินตามเส้นทางเดียวกัน
ไม่มีอะไรเกิดขึ้นได้เลย หากวิศวกรไม่กินความเจ็บปวดในสนามก่อน ความเจ็บปวดคืออินพุตของผลิตภัณฑ์ ไม่ใช่ต้นทุนการขาย
เมื่อ Foundry เติบโตเต็มที่ การดีพลอยมาตรฐานลดความจำเป็นของงานเฉพาะทางลงอย่างมาก มาร์จินขั้นต้นไต่ขึ้นไปถึงช่วง 80% และ Palantir เปลี่ยนจากกลไกที่นำโดย FDE ไปสู่การขายแบบบัญชี (account-based selling) FDE จำนวนมากย้ายไปทำงานวิศวกรรมหลัก พวกเขายังมีชื่อเสียงเรื่องการปฏิเสธสัญญาที่ลูกค้าแค่อยากได้ Accenture ที่มีซอฟต์แวร์ดีขึ้น
ทีม FDE ไม่ใช่โมเดลธุรกิจ มันคือหนทางในการสร้างผลิตภัณฑ์ที่ใช่
ทำไม AI สตาร์ทอัพบางแห่งถึงต้องการ FDE จริงๆ ตอนนี้
ถ้าคุณกำลังสร้าง SaaS CRM ในปี 2015 คุณไม่จำเป็นต้องค้นพบเวิร์กโฟลว์ เพราะผู้คนอีก 20 ปีคิดกันไปแล้วว่าไปป์ไลน์คืออะไร สเตจคืออะไร การส่งต่อลีดหน้าตาเป็นยังไง
ถ้าคุณกำลังสร้าง AI agent ด้านบัญชีในปี 2026 ไม่มีเวิร์กโฟลว์ที่ถูกกำหนดไว้ เพราะไม่มีใครเคยใช้ของแบบนี้มาก่อนจริงๆ ไม่มีใครรู้ว่าการเดินทางของผู้ใช้ (user journey) หน้าตาเป็นยังไง — ไม่ใช่คุณ และที่สำคัญ ไม่ใช่ลูกค้าของคุณด้วย พวกเขาบอกคุณไม่ได้ว่าต้องการอะไร เพราะสิ่งที่พวกเขาอยากได้ยังไม่มีรูปร่าง
นั่นคือสถานการณ์เดียวกับที่ Palantir เริ่มต้น Lonsdale ให้กรอบไว้ว่าพวกเขาทำ forward-deployed เพราะความจำเป็น: พวกเขามีเทคโนโลยีที่แข็งแกร่ง แต่ไม่มีความคิดว่าลูกค้าด้านกลาโหมและข่าวกรองยุคแรกๆ ทำงานยังไงจริงๆ
ดังนั้น ใช่ ส่งวิศวกรไป นั่งอยู่ในห้อง ดูสิ่งที่คุณสร้างพังในแบบที่เทสต์ของคุณไม่เคยจินตนาการ ในหมวดหมู่ที่ใหม่อย่างแท้จริง ไมล์สุดท้ายไม่ใช่ปัญหาเรื่องการส่งมอบ แต่เป็นปัญหาเรื่องการค้นพบ และไม่มีอะไรทดแทนการไปอยู่ตรงนั้นได้
กับดักไม่ใช่การเริ่มต้น แต่คือการไม่หยุด
เมื่อคุณรู้แล้วว่าการเดินทางของผู้ใช้จริงๆ คืออะไร คุณควรเริ่มดึง FDE ออกมา
คุณจะไม่อยากทำ ไม่ใช่เพราะมีใครตัดสินใจผิด แต่เพราะการเก็บพวกเขาไว้นั้นง่ายกว่าในทุกๆ สปรินต์
FDE ทำให้คุณเลี่ยงการตัดสินใจยากๆ ด้านผลิตภัณฑ์ได้ทุกครั้ง คุณไม่ต้องตัดสินใจว่าผลิตภัณฑ์ทำอะไร คำขอลูกค้าสองรายไหนชนะ หรือพื้นผิวการคอนฟิกจบตรงไหน มันรู้สึกเหมือนฟรี ไม่มีใครต้องปฏิเสธใคร ไม่มีการตัดสินใจเชิงสถาปัตยกรรมที่เจ็บปวด ลูกค้าประทับใจ
และตอนนี้คุณได้ข้อเสียทุกอย่างของโมเดลนี้ โดยไม่มีประโยชน์ด้านการค้นพบเลย ต้นทุนการให้บริการไม่ลดลง มาร์จินยังถูกจำกัด การเติบโตถูกจำกัดด้วยการจ้างคน ทุกการแก้เฉพาะกิจที่หน้างานคือการตัดสินใจด้านผลิตภัณฑ์ที่คุณเลือกที่จะไม่ทำ ทุกการดีพลอยควรทำให้ครั้งถัดไปง่ายขึ้น
ยิ่งไปกว่านั้น มีสตาร์ทอัพน้อยมากที่ปิดดีลระดับ 8 หลักแบบที่ Palantir ทำได้ตั้งแต่แรก ซึ่งทำให้เศรษฐศาสตร์ยิ่งยากที่จะยั่งยืน
อีกหนึ่งสิ่งที่อย่าสับสน
FDE ก็ไม่เหมือนกับการ implementation "สร้างอินทิเกรชันนี้เข้ากับระบบ ticketing ของพวกเขา" เป็นงานจริงที่จำเป็น แต่มันคือการทำงานตามสเปกที่รู้อยู่แล้ว ไม่ใช่การค้นพบสเปกที่ไม่รู้ การรวมสองสิ่งนี้ไว้ใต้ตำแหน่งเดียวคือวิธีที่บริษัทต่างๆ โน้มน้าวตัวเองว่าองค์กรบริการที่โตขึ้นคือการลงทุนด้านผลิตภัณฑ์
โมเดลเขียนโค้ดเก่งพอแล้วในตอนนี้ ที่ทำให้สิ่งที่ทีม implementation ทำในปี 2023 จำนวนมากกลายเป็นสิ่งที่ผลิตภัณฑ์ทำเองได้ ในที่สุด คุณจะสามารถสร้าง agent ที่ทำงานไมล์สุดท้ายทั้งหมดได้แบบ end-to-end มันสามารถสังเกตเวิร์กโฟลว์และแม้แต่สัมภาษณ์ลูกค้าได้
สิ่งที่เราทำแทน
ในกรณีเฉพาะของเรากับ @DecagonAI เราเชื่อพื้นฐานว่าแนวทางที่ขับเคลื่อนด้วยผลิตภัณฑ์คือคำตอบ มากกว่าแนวทางที่ขับเคลื่อนด้วยบริการหรือ FDE ฝ่ายบริการลูกค้าเป็นงานที่มีปริมาณสูง ทำซ้ำได้ และแยกส่วนได้ และเมื่อเราคุยกับองค์กรใหญ่ มีสองสิ่งที่เหมือนเดิมเสมอ:
- ความเร็วในการทำซ้ำคือกุญแจสำคัญ การส่ง AI agent ไม่ใช่เรื่องที่ทำครั้งเดียวจบ มันต้องถูกปรับแต่งและอัปเดตอยู่ตลอดเวลา หากการปรับแต่ละครั้งต้องพึ่งวิศวกร มันจะช้าเกินไปและแพงเกินไปที่จะสเกล
- Vendor lock-in และความเป็นเจ้าของข้อมูล จากประสบการณ์ขององค์กรต่างๆ กับ SaaS ไม่มีใครอยากถูกผูกติดกับเวนเดอร์รายใดและต้องพึ่งพาทรัพยากรของพวกเขา
ในช่วงแรกๆ Ashwin และผมจะลงมือสร้างสิ่งที่ลูกค้าขอด้วยตัวเองจริงๆ เมื่อผลิตภัณฑ์เริ่มไปได้ดี เราตัดสินใจอย่างชัดเจนว่าคุณค่าหลัก (core value prop) ของเราคือการมีผลิตภัณฑ์ที่ดีที่สุด
ขอพูดให้ชัด เรายังคงจับมือกับลูกค้าเพื่อส่งมอบผลลัพธ์แบบ end-to-end อย่างไรก็ตาม แม้ในกระบวนการนั้น เรารับผิดชอบงานสร้างเอง ขณะที่ทำให้ทีมของพวกเขาใช้งานผลิตภัณฑ์เราได้ และมอบกุญแจให้พวกเขา เมื่อผลิตภัณฑ์โตเต็มที่ งานเฉพาะลูกค้าที่ทีมวิศวกรของเราทำลดลงอย่างมาก
การตัดสินใจนั้นมีข้อแลกเปลี่ยน มันหมายถึงการไม่แฮกอะไรคร่าวๆ ที่หน้างานแม้จะเร็วกว่า มันหมายถึงการรับ escalation แล้วเปลี่ยนเป็น requirement แทนที่จะเป็น patch ซึ่งใช้เวลามากขึ้นในระยะสั้น
ผลลัพธ์ที่ได้:
- สองในสามของงานดีพลอยตอนนี้เกิดขึ้นอัตโนมัติผ่าน Duet: การคอนฟิก การทำซ้ำ และลองเทลของการปรับแต่งที่เคยต้องมีคนอยู่ในลูป (human in the loop)
- ตอนนี้ใช้เวลาเฉลี่ยเพียงไม่กี่วันในการเปิดตัว AOP แรก แม้แต่สำหรับธนาคารใหญ่ สายการบิน ผู้ให้บริการโทรคมนาคม ฯลฯ
ยังมีงานอีกมากที่ต้องทำ แต่เรากำลังเดินทางอยู่
แล้ว: จะ FDE หรือไม่ FDE?
ไป forward-deployed ตั้งแต่เนิ่นๆ เก็บสัญญาณ (signal) ให้วิศวกรของคุณอยู่กับลูกค้าตลอดไป
แล้วตั้งคำถามจริงๆ ความเฉพาะตัว (bespokeness) อยู่ในสภาพแวดล้อมของลูกค้า หรืออยู่ในช่องโหว่ของผลิตภัณฑ์คุณเอง? ไมล์สุดท้ายเป็นสิ่งที่ลดไม่ได้จริงๆ หรือแค่ยังไม่ได้สร้าง? FDE ของคุณกำลังค้นพบอะไรบางอย่าง หรือกำลังกลืนอะไรบางอย่าง? และครั้งที่แล้วที่มีคนกลับมาจากสนาม อะไรถูกสร้างเข้าสู่ผลิตภัณฑ์บ้าง?
ใช้ FDE เพื่อหาว่าอะไรที่ต้องมีอยู่ในผลิตภัณฑ์ FDE กินความเจ็บปวดแล้วขับถ่ายออกมาเป็นผลิตภัณฑ์ ถ้าทีมของคุณกินความเจ็บปวดแล้วขับถ่ายความเจ็บปวดออกมา นั่นไม่ใช่ทีม FDE นั่นคือธุรกิจบริการ
