Forward Deployment: บทบาท ความเชื่อ และตำนาน

@viks_rum
อังกฤษ4 สัปดาห์ที่ผ่านมา · 11 ก.ค. 2569
128K
23
1
0
22

TL;DR

Vikram Aditya เจาะลึกบทบาทสำคัญของ Forward Deployment ใน Enterprise AI พร้อมอธิบายวิธีเชื่อมช่องว่างระหว่างผลิตภัณฑ์และเวิร์กโฟลว์ของลูกค้าผ่านการทำซ้ำและการสร้างผลลัพธ์แบบทวีคูณ

กว่า 1 ปีที่แล้ว ผมใช้เวลาหนึ่งชั่วโมงในการพูดคุยทางโทรศัพท์กับคนที่ทำงานด้าน forward deployment มานานกว่าทศวรรษในบริษัทที่เป็นผู้บัญญัติคำนี้ขึ้นมา ตลอด 12 เดือนที่ผ่านมา ผมได้ร่วมงานกับผู้คนมากมายในรูปแบบที่แตกต่างกันไปในการสร้างกลไก forward deployment ของพวกเขา ผมยังคงรู้สึกว่าไม่มีเนื้อหาชิ้นไหนที่จะอธิบายทุกสิ่งที่เกี่ยวข้องกับ forward deployment ได้อย่างครอบคลุม

เมื่อผมพูดคุยกับเพื่อนของผม ผมถามว่ากระบวนการค้นพบอันโด่งดังนั้นทำงานอย่างไรจริงๆ คำตอบที่ได้คือมันเป็นเรื่องที่จับต้องได้อย่างน่าอาย อย่างน้อยก็ในตอนแรกเมื่อคุณมองแค่เพียงผิวเผิน คุณบินไปที่นั่น คุณใช้เวลาสองวันพบปะกับทุกคนที่เกี่ยวข้องกับปัญหา ผู้จัดการระบบ ERP จะสอนทฤษฎีเกี่ยวกับใบสั่งซื้อให้คุณ จากนั้นพวกเขาจะพาคุณไปที่หน้างานเพื่อให้คุณได้เห็นว่าทฤษฎีนั้นละเว้นอะไรไว้บ้าง จากนั้นคุณจะใช้เวลาสามสัปดาห์ถามคำถามพวกเขาวันละข้อขณะที่คุณกำลังเชื่อมต่อข้อมูล ผมถามว่ามีสูตรสำเร็จไหม เขาบอกว่าสูตรสำเร็จคือการได้ใช้เวลากับคนที่รู้เรื่องมากที่สุดให้มากที่สุด ผ่านมาสิบปี สิ่งนั้นก็ไม่เคยเปลี่ยนแปลง

อย่างไรก็ตาม สิ่งนี้อาจทำให้เข้าใจผิดได้หากคุณไม่ลงลึกไปกว่านั้น ใช่แล้ว พวกเขาใช้เวลากับลูกค้าเป็นอย่างมาก อย่างไรก็ตาม กลไก forward deployment ที่ดีจะสร้างแบบจำลองไว้ล่วงหน้า วิศวกร deployment และนักยุทธศาสตร์ deployment ที่เก่งจะตระหนักว่าพวกเขาจะไม่เข้าใจทุกอย่าง แต่พวกเขาสร้างสิ่งต่างๆ และปรับปรุงร่วมกับลูกค้าได้อย่างรวดเร็ว เวิร์กโฟลว์แรกคือเป้าหมายทันที ออนโทโลจีถูกใช้เป็นวิธีการขยายเครื่องมือนั้นไปสู่ระบบปฏิบัติการอย่างค่อยเป็นค่อยไป จุดที่กลไก forward deployment ที่ดี shine คือความจริงที่ว่าบริบทส่วนใหญ่มาจากทีม จากผู้เชี่ยวชาญเฉพาะด้าน และพวกเขาจะร้อยเรียงทุกอย่างเข้าด้วยกันเป็นส่วนใหญ่ก่อนที่จะพบลูกค้าเป็นครั้งแรกด้วยซ้ำ ส่วนนั้นพัฒนาไปตามกาลเวลาและเป็นเหตุผลที่แท้จริงว่าทำไมบางกลไกจึงทวีคูณและบางกลไกไม่ทวีคูณ

ผมมีความคิดสองอย่างทันที คุณอาจจะมีความคิดเหมือนกันถ้าคุณยังไม่ได้ใส่ใจว่าจริงๆ แล้ว forward deployment ที่ดีคืออะไร ดังนั้นผมขอแนะนำให้คุณอ่านต่อ

ความคิดแรกของผมคือจะเกิดอะไรขึ้นเมื่อคุณไม่มีความคิดใดๆ เกี่ยวกับเวิร์กโฟลว์ของลูกค้า? คุณจะเริ่มจากการสัมภาษณ์มากมายใช่ไหม? เพื่อนของผมบอกว่าไม่ เพราะไม่มีใครชอบถูกสัมภาษณ์ แต่เขาเล่าเรื่องหนึ่งให้ฟัง ทีมของเขาเคยสร้างระบบกำหนดเส้นทาง (routing engine) ให้กับบริษัทโลจิสติกส์แห่งหนึ่ง ซึ่งมีพนักงานจัดส่ง (dispatchers) ที่ต้องจัดสรรตั๋วงานประจำวันให้กับพนักงานขับรถหรือเส้นทางโดยอาศัยการตัดสินใจด้วยตนเองและดูแผนที่ ระยะทาง ที่ตั้งของหลุมฝังกลบ และข้อจำกัดในการปฏิบัติงานอื่นๆ เพื่อนของฉันสร้างเครื่องมือที่ให้คำแนะนำแก่พนักงานจัดส่ง แต่ปัญหาแรกคือพนักงานจัดส่งมักจะปฏิเสธคำแนะนำตามสัญชาตญาณและไม่สามารถอธิบายเหตุผลได้ชัดเจน เพื่อจัดการกับปัญหานี้ ทีมของเขาต้องแสดงการจัดเรียงที่เป็นไปได้ทั้งหมด จากนั้นพวกเขาใช้ความสามารถในการมองเห็นนั้นเพื่อเปรียบเทียบการตัดสินใจของมนุษย์กับผลลัพธ์จากการจำลอง นี่เป็นครั้งแรกที่มีคนแสดงการจัดเร شناساییทั้งหมดบนหน้าจอ และด้วยเหตุนี้จึงเป็นครั้งแรกที่ผู้คนมีโอกาสได้สะท้อนว่าการตัดสินใจที่พวกเขาทำโดยสัญชาตญาณนั้นมีข้อมูลสนับสนุนในระดับใหญ่หรือไม่ มันทำให้ทีมงานที่บริษัทโลจิสติกส์สามารถตรวจสอบเวิร์กโฟลว์ได้ด้วยตนเอง เข้าใจว่าตรรกะของกระบวนการนั้นถูกต้องหรือไม่ และปรับแต่ง digital twin ให้ตรงกับการดำเนินธุรกิจในทางปฏิบัติมากขึ้น พวกเขายังสนุกกับกระบวนการนี้เพราะมันไม่เคยรู้สึกเหมือนเป็นการสัมภาษณ์ แต่กลับเป็นการเปิดโอกาสให้พวกเขาได้เห็นชิ้นส่วนปริศนาทั้งหมดบนกระดานเดียวกันเป็นครั้งแรก

ความคิดต่อมาของผมคือการเพิ่ม agent เข้ามาเปลี่ยนแปลงกระบวนการทั้งหมดในปัจจุบันจากเมื่อสองสามปีก่อนได้อย่างไร? คำตอบที่เพื่อนของผมให้คือมันหมายความว่าเราสามารถพัฒนาได้เร็วขึ้นมากโดยใช้ agent และมีบริบทมากขึ้นในชั้นความรู้ของชนเผ่า (tribal knowledge layer) แต่นั่นเป็นเพียงส่วนหนึ่งของปริศนา เขาบอกว่าสูตรลับในโมเดล FDE ของพวกเขาเมื่อพูดถึงการทดลองเหล่านี้ ไม่ใช่สิ่งที่ยิ่งใหญ่อะไรนัก ในบางกรณี แม้กระทั่งตอนนี้ ขณะที่พวกเขาทำการทดลอง พวกเขาก็แค่ฟังขั้นตอนและผลลัพธ์ จับคู่คำกริยา (verb-mapping) และให้ทีมงานห้าคนแก่ลูกค้าเพื่อเป็นวิศวกรโดยเฉพาะ วิศวกรเหล่านี้จะแปลงทุกอย่างเป็นโค้ด และจากนั้นพวกเขาก็สามารถหายไปได้ และลูกค้าสามารถใช้โซลูชันต่อไปได้ agent ช่วยในแง่ที่ว่ามันเร่งและทำให้กระบวนการแปลงเป็นโค้ดลึกซึ้งยิ่งขึ้น โดยทำให้ง่ายต่อการรวมบริบทและความรู้ของชนเผ่าจากระบบต่างๆ ของลูกค้า agent กลายเป็นวิธีที่จะก้าวไปไกลกว่าแค่คำติชมจากผู้ใช้โดยตรง และสามารถดึงบริบททางประวัติศาสตร์และการดำเนินงานเข้ามาได้ เช่น อีเมล การเปลี่ยนแปลงกระบวนการขาย การเปลี่ยนแปลงสถานะในระบบเช่น Salesforce และร่องรอยอื่นๆ ว่าองค์กรทำงานอย่างไรเมื่อเวลาผ่านไป สิ่งนี้ทำให้การสร้างแบบจำลองเวิร์กโฟลว์ของลูกค้ามีความสมบูรณ์ยิ่งขึ้น เชื่อมต่อแหล่งความรู้ที่กระจัดกระจายเข้าด้วยกัน และสร้างระบบที่ไม่เพียงแค่เป็นตัวแทนของธุรกิจผ่าน digital twin แต่ยังช่วยทำให้การตัดสินใจที่ผู้คนทำด้วยตนเองในปัจจุบันเป็นอัตโนมัติหรือสนับสนุนอีกด้วย

ผมมีข้อความสองสามย่อหน้าจากการถอดเทปโทรศัพท์กับเขา

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

เมื่อลูกค้าแชร์ข้อมูลมา เราจะไปที่กระดานวาดภาพและพูดว่า โอเค มาลองตัด ontology เวอร์ชันหนึ่ง สร้างแอปพลิเคชันเวอร์ชันหนึ่งภายในเวลาประมาณหนึ่งสัปดาห์แล้วลองทดสอบดู ดังนั้นมันจึงคล้ายมากกับ รู้ไหม เหมือนกับการสร้างสตาร์ทอัพ เรามักจะพบว่า พวกเขาอาจจะนึกถึงไอเดียของ use case หนึ่งขึ้นมา แต่ในขณะที่พวกเขากำลังพูด เราจะค้นพบ use case ที่เป็นไปได้อีกอย่างหนึ่งที่เราสามารถแก้ไขได้ และเราก็จะสร้างสิ่งนั้นขึ้นมา แม้ว่าพวกเขาจะคิดว่าพวกเขาต้องการอย่างอื่นก็ตาม ท้ายที่สุดแล้ว เราพยายามปรับให้เข้ากับปัญหาที่ใหญ่ที่สุดที่พวกเขาต้องการให้แก้ไข

เราจะสร้างบางอย่างเพื่อแก้ปัญหานั้นอย่างรวดเร็ว และสร้างวัตถุห้าชิ้นในแง่ของ ontology ถ้าเรากำลังทำอะไรที่เกี่ยวข้องกับระบบ ERP ซึ่งอาจซับซ้อนมาก แม้หลังจากที่ทำการผสานรวมเสร็จแล้ว เราก็จะติดต่อผู้เชี่ยวชาญ ERP นั้น สองสามครั้งเพื่อประชุมระดมสมองแบบหนึ่งชั่วโมง หรือประชุมแบบกะทันหันครึ่งชั่วโมงระหว่างสัปดาห์ แล้วเมื่อเราพิสูจน์ตัวเองได้แล้ว ก็ค่อยมองหา use case ที่สอง สาม สี่ จนถึงจุดที่เราสามารถสร้างระบบปฏิบัติการสำหรับองค์กร (enterprise OS) สำหรับทั้งบริษัทของพวกเขาได้

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

แนวคิดหลักในการสนทนาคือการแปลงเป็นโค้ด (codification) เกิดขึ้นผ่านการทำซ้ำ (iteration) ไม่ใช่ผ่านเอกสารจำนวนมาก ทีมงานสร้าง "digital twin" ของบริษัทโดยตรงในโค้ด โดยใช้การผสานรวมข้อมูล บริบทการดำเนินงาน และข้อมูลจากผู้เชี่ยวชาญเฉพาะด้านเพื่อแสดงให้เห็นว่าองค์กรทำงานอย่างไรในทางปฏิบัติ แต่โมเดลข้อมูลเพียงอย่างเดียวนั้นไม่เพียงพอ ชั้นที่ยากและมีคุณค่ามากกว่าคือตรรกะทางธุรกิจ (business logic) - ความเข้าใจว่าการแทรกแซงมีความสำคัญตรงไหน ควรแนะนำการดำเนินการใด และผู้ปฏิบัติงานที่มีประสบการณ์ตัดสินใจอย่างไร ทั้งหมดนี้ไม่ใช่แค่การแสดงข้อมูล แต่ช่วยให้ผู้ใช้ประเมินข้อแลกเปลี่ยน ตรวจสอบเวิร์กโฟลว์ และท้ายที่สุดคือการเข้ารหัสการสนับสนุนการตัดสินใจลงในตัวผลิตภัณฑ์

ส่วนที่เหลือของการสนทนาของผมเจาะลึกว่างานนี้ไม่ได้ขึ้นอยู่กับการมีผู้เชี่ยวชาญเฉพาะด้านที่ฝังตัวตั้งแต่เริ่มต้น ความคาดหวังคือวิศวกรแบบ forward-deployed สามารถเข้าสู่สภาพแวดล้อมที่ไม่คุ้นเคย เรียนรู้ได้อย่างรวดเร็ว และสร้างความน่าเชื่อถือด้วยการผลิตระบบที่มีประโยชน์อย่างรวดเร็ว การมีส่วนร่วมในช่วงแรกมักเริ่มต้นด้วยการอบรมระยะสั้น ซึ่งสนับสนุนโดยต้นแบบที่สร้างไว้ล่วงหน้าและตัวอย่างข้อมูล ที่ออกแบบมาเพื่อแสดงคุณค่าได้อย่างรวดเร็วและได้รับสิทธิ์ในการปรับใช้ที่ลึกซึ้งยิ่งขึ้น จากนั้น ความสัมพันธ์สามารถขยายจาก use case เดียวไปสู่ระบบปฏิบัติการที่กว้างขึ้นสำหรับลูกค้า โดยมีเป้าหมายระยะยาวในการแปลงเวิร์กโฟลว์เป็นโค้ดอย่างมีประสิทธิภาพ จนกระทั่งทีมสามารถถอยออกมาได้ในที่สุด ในขณะที่ลูกค้ายังคงใช้โซลูชันต่อไป

นี่คือคู่มือที่มีความเกี่ยวข้องอย่างมากสำหรับกิจการใหม่ที่กำลังถูกสร้างขึ้น นี่คือ forward deployment อย่างอื่นเป็นเพียงการตกแต่ง

กฎแห่งการทบต้น (The law of compounding)

Forward deployment มีราคาแพง ใช้เวลานานจึงจะเห็นผลในอัตรากำไรขั้นต้น และยากต่อการวางแผนอย่างเป็นระเบียบ ผู้ก่อตั้งรู้สึกถึงสิ่งนี้และเริ่มตั้งคำถามว่าความพยายามนั้นคุ้มค่ากับการปลดล็อคหรือไม่ ในที่สุดผู้นำบางคนก็พูดออกมาดังๆ ว่า เราทุ่มเทความพยายามเป็น 2 เท่า แต่ได้ผลลัพธ์เป็น 2 เท่า

ประโยคนั้นเป็นสัญญาณอันตรายสำหรับบางอุตสาหกรรม ถ้ามันบ่งบอกว่า forward deployment ไม่ใช่โมเดลที่ถูกต้อง ผมเข้าใจความใจร้อนของผู้ก่อตั้งเพราะผมเคยเป็นมาก่อน แต่เส้นแบ่งระหว่างความไร้เดียงสาและความใจร้อนนั้นบางมาก สำหรับธุรกิจที่ทำงานได้ดีกว่ากับกลไก forward deployment ใครก็ตามที่คิดเลขแบบคูณนี้ยังไม่เข้าใจงาน ถ้าความพยายาม 2 เท่าซื้อผลลัพธ์ 2 เท่า แสดงว่าคุณจ้างที่ปรึกษาและแต่งตัวให้พวกเขาเป็นวิศวกร คุณจะเพิ่มคนตามรายได้ไปตลอดกาล อัตรากำไรของคุณจะไม่มีวันหลุดพ้น และชื่อที่ซื่อสัตย์สำหรับสิ่งที่คุณสร้างขึ้นคือบริษัทจัดหาพนักงานที่ส่งโค้ดหรือให้การสนับสนุน คนที่ไม่ชัดเจนว่ากำลังสร้างอะไร มักจะจบลงด้วยผลลัพธ์ที่ mediocre และความสับสนนี้จะทบต้นสวนทางกับคุณ

Forward deployment จะสมเหตุสมผลก็ต่อเมื่อคณิตศาสตร์เปลี่ยนไป การ deploy ครั้งแรกอาจจะยุ่งเหยิง ทำด้วยมือ และไม่สมเหตุสมผลในเชิงเศรษฐศาสตร์ งานของมันคือการสอน การ deploy ครั้งที่สองต้องถูกกว่า เพราะการ deploy ครั้งแรกทิ้งเทมเพลต การผสานรวม รูปแบบที่มีการบันทึกไว้ และชิ้นส่วนของแพลตฟอร์มไว้เบื้องหลัง เมื่อถึงการ deploy ครั้งที่สิบ สิ่งที่ทีมแรกทำด้วยมือส่วนใหญ่ควรจะเกิดขึ้นผ่านการกำหนดค่า และมนุษย์ควรจะขยับขึ้นไปอีกระดับ แก้ปัญหาที่ไม่มีอยู่จริงเมื่อปีที่แล้ว แม้แต่ในสายตาของลูกค้า ระยะห่างระหว่างตัวเลขสองตัวนั้นในเดือนที่ 1 และเดือนที่ n คือการทบต้น และเส้นโค้งนั้นคือสิ่งที่คุณกำลังซื้อจริงๆ เมื่อคุณให้ทุนสนับสนุนทีม forward deployed การทบต้นคือประเด็นทั้งหมด การเรียกตัวเองว่า forward deployed โดยไม่มีกลไกที่ทบต้นนั้นโง่เขลา

วิศวกรซอฟต์แวร์และวิศวกร forward deployed แตกต่างกันโดยหลักแล้วตามปริมาณเวลาที่ SWE ใช้ในการเขียนโค้ดเพื่อบำรุงรักษา สนับสนุน หรือสร้างสิ่งต่างๆ ตามโรดแมป เทียบกับสิ่งที่ FDE ใช้ในการค้นพบสิ่งที่มักจะไม่อยู่ในโรดแมป แต่ปลดล็อคคุณค่าของลูกค้า นำไปใช้ และส่งต่อไปยังผลิตภัณฑ์เมื่อรูปแบบเริ่มเกิดขึ้นซ้ำกับลูกค้าหลายราย

คำที่ทุกคนใช้ แต่แทบไม่มีใครหมายถึงจริงๆ

แนวคิดนี้มีที่มาเฉพาะเจาะจง เมื่อสองทศวรรษที่แล้ว ผู้ก่อตั้งคนหนึ่งถามว่าทำไมร้านอาหารฝรั่งเศสชั้นดีถึงดี และคำตอบก็คือพนักงานเสิร์ฟ ในร้านอาหารชั้นดี พนักงานเสิร์ฟเป็นส่วนหนึ่งของห้องครัว ดังนั้นเมื่อพวกเขาแนะนำอะไรบางอย่าง มันคือเสียงของห้องครัว Palantir สร้างเวอร์ชันวิศวกรรมของสิ่งนั้นและตั้งชื่อให้กับบทบาทนี้ตามชื่อทางการทหาร เพราะลูกค้าของพวกเขาคือกองทัพ ชื่อนี้ทำให้งานภาคสนามมีสถานะที่สมควร และก็สมควรแล้ว มันจ่ายดีมากจนยี่สิบปีต่อมาทุกคนต้องการชื่อนี้ แต่ผมไม่แน่ใจว่ามีกี่คนที่เข้าใจงานนี้

ในแง่หนึ่ง ทีม forward deployment ต้องทำในสิ่งที่ผู้ก่อตั้งต้องทำในระยะ 0-1 คุณมักจะค้นพบว่าคุณสามารถส่งอะไรออกไปได้บ้างที่จะไม่เพียงแค่ยกตัววัดที่ไร้สาระ (vanity metric) แต่จะช่วยให้ลูกค้าของคุณเติบโตทางธุรกิจได้จริง นี่เป็นอีกตัวอย่างจริงจากการสนทนาของเพื่อนผม ทีมของเขาถูกจ้างโดยผู้ผลิตเครื่องชาร์จ EV ที่ต้องการเพิ่มการผลิตประมาณ 10 เท่า นั่นคือข้อกำหนดสั้นๆ คุณเดาผลลัพธ์ได้ไหม เพราะมันไม่ใช่สไลด์กลยุทธ์อย่างแน่นอน เป้าหมายของบริษัทนั้นเรียบง่ายเมื่อมองผิวเผิน: เพิ่มผลผลิตเครื่องชาร์จ EV ขึ้น 10 เท่า สิ่งที่ทีม forward deployment ทำจริงๆ คือไปที่ไซต์งานและเรียนรู้การดำเนินงานจากหลายระดับของธุรกิจ พวกเขาใช้เวลากับเจ้าของระบบ ERP เพื่อทำความเข้าใจระบบบันทึกข้อมูล ใบสั่งซื้อ ใบสั่งงาน อุปทาน และอุปสงค์ จากนั้นพวกเขาไปที่หน้างานเพื่อดูว่าการผลิตเกิดขึ้นจริงในทางปฏิบัติอย่างไร ในเวลาเดียวกัน พวกเขาพูดคุยกับผู้บริหารเพื่อทำความเข้าใจปัญหาในเชิงกลยุทธ์ เพราะสิ่งที่ผู้ปฏิบัติงานแนวหน้าบอกว่าผิดหรือเร่งด่วนนั้นอาจไม่ตรงกับสิ่งที่ผู้นำมองว่าเป็นข้อจำกัดที่สำคัญที่สุดเสมอไป งานนั้นจึงไม่ใช่การสร้างสายการผลิตใหม่โดยตรง อย่างน้อยก็ไม่ใช่จากสิ่งที่พูดในการประชุม แต่มันคือการสร้าง digital twin ของการดำเนินงาน จากนั้นจึงระบุว่าซอฟต์แวร์สามารถแทรกแซงในเวิร์กโฟลว์ได้ตรงไหน เช่น ปัญหาเกี่ยวกับการขาดแคลนชิ้นส่วนสำคัญ ช่วงเวลาของใบสั่งซื้อ สต็อกสินค้าเพื่อความปลอดภัย และการตัดสินใจในการปฏิบัติงานอื่นๆ ผลลัพธ์ที่อธิบายไว้คือระบบที่สามารถเปิดเผยความเสี่ยงได้เร็วขึ้นและแนะนำการดำเนินการ แทนที่จะเป็นการเปลี่ยนแปลงทางกายภาพต่อการผลิตเอง ผมหวังว่าสิ่งนี้จะอธิบายสิ่งที่ผมหมายถึงเมื่อผมบอกว่าอดีตผู้ก่อตั้งสามารถเป็นบุคลากร forward deployment ที่ยอดเยี่ยมได้

มองดูภายใต้ประสบการณ์การทำงานในปัจจุบัน (ไม่ใช่คำบรรยายลักษณะงาน) แล้วคุณจะพบวิศวกรที่เขียนโค้ดสำหรับการผลิตภายในระบบของลูกค้าและเป็นเจ้าของสิ่งที่เกิดขึ้นหลัง go-live รวมถึงการสนับสนุน ที่เหลือคือวิศวกรฝ่ายขายที่มีนามบัตรดีกว่า ถูกตัดสินจากเดโม บวกกับบทบาทระบบอัตโนมัติภายในที่ยืมคำนี้มาเพราะมันเป็นแฟชั่น ความสับสนที่เกี่ยวข้องว่า forward deployment คืออะไรนั้นแย่ยิ่งกว่า การเรียกใช้เครือข่ายผู้เชี่ยวชาญผ่านการสัมภาษณ์เชิงลึกนับร้อยครั้งคือการวิจัย แต่นั่นไม่ใช่ forward deployment เมื่อบริษัทไพรเวทอิควิตี้รวบรวมบริษัทต่างๆ และส่งทีมปรับเปลี่ยนองค์กรเข้าไป มันมีประโยชน์ บางครั้งก็ยอดเยี่ยม แต่ก็ไม่จำเป็นต้องเป็น forward deployment ผมพูดแบบนี้เพราะไม่มีใครในสองกรณีนั้นที่เป็นเจ้าของสิ่งที่ผมเรียกว่า work-closure

Work-closure คือหน่วยที่ระเบียบวินัยทั้งหมดนี้วัดค่า ไม่ใช่ฟีเจอร์ที่ส่งมอบ ไม่ใช่ ticket ที่แก้ไข แต่เป็นชิ้นส่วนของงานของลูกค้า ที่ถูกดำเนินการตั้งแต่ความกังวลที่ยังคงอยู่ ไปจนถึงสิ่งที่ไม่มีใครคิดถึงอีกต่อไป การลงนามในสัญญาคือเส้นแบ่งระหว่างอาชีพที่มักสับสนกันที่นี่ วิศวกรฝ่ายขายทำงานจนถึงจุดนั้น ทีม forward deployment เริ่มต้นที่จุดนั้น เพราะการเห็นพ้องว่าบางสิ่งควรจะทำงานนั้นไม่เหมือนกับว่ามันทำงานจริง ถ้าคนๆ นั้นมีโควตาการขาย คุณกำลังมองหางานขาย ถ้าคนๆ นั้นยังคงอยู่ในระบบ log ของลูกค้าสามเดือนหลังเปิดตัว คุณกำลังมองหา forward deployment บริษัทที่ขายผลิตภัณฑ์การตลาดจะส่งวิศวกรฝ่ายขายไปเพื่อให้ได้ข้อตกลงและเพื่อปรับใช้และกำหนดค่าสิ่งต่างๆ FDE ที่แท้จริงอาจสรุปได้ว่าไม่มีเวิร์กโฟลว์ใดที่ผลิตภัณฑ์รองรับที่จะช่วยลูกค้ารายนั้นได้เลย และสิ่งใหม่ทั้งหมดจะส่งผลกระทบโดยตรงต่อรายได้หรือกำไร และจากนั้นพวกเขาก็สร้างเวิร์กโฟลว์นั้นขึ้นมา สิ่งนี้ต้องเป็นผู้เชี่ยวชาญใน Mom's test (อ่านหนังสือเล่มนั้น) เข้าใจว่าลูกค้าไม่สนใจฟีเจอร์ของคุณ แต่สนใจว่าพวกเขาจะทำธุรกิจได้ดีขึ้นอย่างไร เข้าใจว่าผลิตภัณฑ์ของคุณสามารถทำอะไรได้บ้าง และส่งมอบด้วยความเร็วที่รวดเร็วเพื่อให้คุณสามารถปรับปรุงซ้ำกับลูกค้าในเวิร์กโฟลว์จริงได้

ดังนั้น นี่คือคำจำกัดความที่ผมจะติดไว้บนผนัง Forward deployment คือการยืนอยู่ในระยะห่างระหว่างสิ่งที่คุณส่งมอบกับสิ่งที่ลูกค้าต้องการ การปิดระยะห่างนั้นด้วยมือของคุณเอง ภายในโลกของพวกเขา ในลักษณะที่สอนให้ผลิตภัณฑ์ของคุณปิดระยะห่างนั้นได้ด้วยตัวเองในครั้งต่อไป

ครึ่งหลังของประโยคนั้นคือจุดที่เกือบทุกคนล้มเหลว

ทำไมจู่ๆ ถึงมีอยู่ทั่วไป

เป็นเวลาเจ็ดสิบปีที่ซอฟต์แวร์ช่วยให้ผู้คนทำงาน ตอนนี้มันเริ่มที่จะทำงานแทน นั่นพลิกสมมติฐานที่ซ่อนอยู่ เครื่องมือสามารถที่จะถูกนำมาใช้อย่างช้าๆ ได้ แต่คนงานไม่สามารถ ทันทีที่คุณขายผลลัพธ์แทนที่จะขายที่นั่ง บางคนต้องทำให้ผลลัพธ์นั้นเกิดขึ้นจริงภายในบริษัทที่ไม่มีพฤติกรรมเหมือนสภาพแวดล้อมเดโมของคุณ

โมเดลต่างๆ หยุดเป็นข้อจำกัดเมื่อประมาณสองปีที่แล้ว การปรับใช้กลายเป็นข้อจำกัด การศึกษาที่ถูกอ้างถึงมากที่สุดเกี่ยวกับการทดลอง AI ในองค์กรพบว่าประมาณ 19 ใน 20 รายการไม่ก่อให้เกิดผลกระทบต่อ P&L ที่วัดได้ และการชันสูตรพลิกศพแทบจะไม่ใช่คุณภาพของโมเดลเลย มันเป็นซอฟต์แวร์ที่ไม่เคยเรียนรู้เวิร์กโฟลว์ กระบวนการที่บันทึกไว้มีสี่ขั้นตอน แต่กระบวนการจริงมีเก้าขั้นตอน และห้าขั้นตอนที่หายไปนั้นอยู่ในความทรงจำของผู้หญิงคนหนึ่ง ในตัวติดตามส่วนตัวที่เธอสร้างขึ้นเมื่อหลายปีก่อน และในความช่วยเหลือที่เธอแลกเปลี่ยนกับผู้หญิงอีกคนในอีกอาคารหนึ่ง ในอุตสาหกรรมเก่าแก่ งานดำเนินการผ่านระบบที่ติดตั้งก่อนที่วิศวกรของคุณจะเกิด ยึดติดกันด้วยเครื่องแฟกซ์และการโทรศัพท์ ไม่มีอะไรมี API ในแหล่งน้ำมัน บางคนเอาหูแนบกับแท่นขุดเจาะเพื่อประเมินว่าเสียงนั้นบ่งบอกถึงสิ่งที่พวกเขาควรกังวลหรือไม่ บนเรือที่ขนส่งปลาหมึกจากอินเดียไปยังสหรัฐอเมริกา โดยแวะที่ลอนดอน อัตราและราคาจะถูกตัดสินโดยอาศัยการเดา ข้อมูลสภาพอากาศที่จำกัด และสิ่งที่ปรากฏให้เห็นว่าเป็นคุณภาพของสต็อก ความรู้ของชนเผ่า (Tribal knowledge) คือชั้นรับน้ำหนักของทุกบริษัท และไม่มีใครเคยส่ง SDK สำหรับมัน สุสานของแพลตฟอร์มอุตสาหกรรมในทศวรรษที่ผ่านมาได้สอนบทเรียนนี้ด้วยเงินหลายพันล้านดอลลาร์ การเปลี่ยนแปลงไม่ได้ตายที่สถาปัตยกรรม พวกมันตายที่การนำไปใช้

เงินสังเกตเห็นแล้ว Microsoft ทุ่มเงินสองพันห้าร้อยล้านดอลลาร์และคนหกพันคนเพื่อฝังผู้เชี่ยวชาญไว้ภายในลูกค้า AWS ทุ่มเงินหนึ่งพันล้านดอลลาร์ให้กับแนวคิดเดียวกันนี้ก่อนหน้านั้นไม่กี่สัปดาห์ OpenAI และ Anthropic ต่างก็ตั้งบริษัท deployment โดยเฉพาะโดยมีนักลงทุนรายใหญ่ที่สุดในโลกบางรายสนับสนุน คุณสามารถเรียกสิ่งนี้ว่าแฟชั่นได้ ทุนในระดับนี้แทบจะไม่ใช่เครื่องแต่งกาย ห้องปฏิบัติการประเมินราคาท่อส่งของตัวเองและค้นพบว่าผู้ซื้อไม่เคยขาดแคลนสติปัญญา ผู้ซื้อขาดแคลนมือ ความล้มเหลวอยู่ในไมล์สุดท้าย และไมล์สุดท้ายคือที่ที่คูเมืองถูกขุดขึ้นมา ต้องใช้เวลาทำงานหนักถึง 10 ปีกับ LLMs เพื่อมาถึงจุดที่เราอยู่ตอนนี้ อาจต้องใช้เวลาอีกมากกว่านี้ถ้าเราจะให้โมเดลเหล่านี้มีความเข้าใจเกี่ยวกับเวิร์กโฟลว์และกรอบการตัดสินใจของมนุษย์

ทำไมคุณถึงต้องการคนธุรกิจในทีมนั้น

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

คนธุรกิจมีอยู่เพราะปัญหาที่ยากที่สุดในการ deployment ไม่ใช่เรื่องทางเทคนิค และการแสร้งทำเป็นอย่างอื่นคือวิธีที่ทีมเทคนิคล้มเหลว ใครสักคนต้องค้นหาว่างานจริงๆ คืออะไรก่อนที่ใครจะทำให้เป็นอัตโนมัติ ใครสักคนต้องตัดสินใจว่าสามในยี่สิบเรื่องที่ถูกยกระดับนั้นเรื่องไหนสำคัญ เวิร์กโฟลว์ของใครคือคอขวดจริงๆ ความเงียบของผู้บริหารคนไหนจะฆ่าการนำไปใช้ และผลลัพธ์ใดที่จะพิสูจน์การมีส่วนร่วมทั้งหมด ใครสักคนต้องเก่งในการอ่านว่าลูกค้ากำลังลังเลเมื่อไหร่ และเมื่อไหร่ที่พวกเขาพูดเพียงเพื่อสุภาพ ใครสักคนต้องจัดการอินเทอร์เฟซที่ละเอียดอ่อนที่สุดใน enterprise AI ซึ่งก็คืออินเทอร์เฟซระหว่างสิ่งที่ผลิตภัณฑ์ของคุณทำได้ในวันนี้กับสิ่งที่คุณขายว่าหลีกเลี่ยงไม่ได้ในอีกหกเดือนข้างหน้า ผมคิดว่านักยุทธศาสตร์การ deployment (deployment strategist) เป็นแผนกซื้อขายล่วงหน้า (futures desk) ของบริษัท พวกเขาขายสิ่งที่ผลิตภัณฑ์จะกลายเป็น ในราคาที่ความสัมพันธ์จะอยู่รอดได้ และพวกเขาทำให้แน่ใจว่าตำแหน่งนั้นจะไม่ผิดนัดชำระหนี้ ข้อตกลงที่มีเดิมพันสูงจะชนะบนโต๊ะนั้น และจะพังทลายหากไม่มีมัน

รูปแบบความล้มเหลวบอกคุณว่าคุณขาดบทบาทไหน ข้อตกลงที่หยุดชะงักเพราะผลิตภัณฑ์จะไม่ทำงานในโลกของลูกค้า หรือสถานการณ์ที่ผลิตภัณฑ์รองรับเฉพาะเวิร์กโฟลว์ที่มีอยู่ภายในผลิตภัณฑ์ หมายความว่าคุณขาดวิศวกร วิศวกรที่ส่งมอบฟีเจอร์ตามที่ร้องขอและยุ่งอยู่ แต่รายได้ไม่เพิ่มขึ้นมากนัก หรือสถานการณ์ที่ FDE ได้โทรศัพท์ไปมากกว่า 100 สาย แต่รายได้ตามสัญญายังคงสูงกว่ารายได้ที่เกิดขึ้นจริงเป็นลำดับความสำคัญ หรือไซโลของเวิร์กโฟลว์ที่กำหนดเองซึ่งไม่ได้ปรับปรุงระบบ หมายความว่าคุณขาดนักยุทธศาสตร์

ในทีมที่ดีที่สุด บทบาททั้งสองจะเบลอ และความเบลอคือประเด็น วิศวกรพัฒนาสัญชาตญาณทางธุรกิจ นักยุทธศาสตร์เรียนรู้ที่จะอ่าน schema และสิ่งที่คุณได้คือสิ่งที่ใกล้เคียงที่สุดที่บริษัทจะจ้างให้เป็นผู้ก่อตั้ง Forward deployment คือสิ่งที่ผู้ก่อตั้งทุกคนทำเป็นเวลาหลายปีก่อนที่ผังองค์กรจะซ่อนมันไว้ นั่งอยู่ในความยุ่งเหยิงของลูกค้า ปิดงานด้วยสิ่งที่อยู่ใกล้มือ ปล่อยให้สิ่งที่เรียนรู้ไปวาดผลิตภัณฑ์ใหม่ บทบาทนี้คือสัปดาห์ของผู้ก่อตั้งในตาราง cap table ของคนอื่น มันเป็นเหตุผลว่าทำไมทีมเหล่านี้จึงผลิตผู้ก่อตั้งในอัตราที่ทำให้บริษัทเทคยักษ์ใหญ่อาย ถ้าคุณดูแลทีม FDE คุณควรเตรียมพร้อมกับการวางแผนสืบทอดตำแหน่งตั้งแต่วันแรก เพราะโอกาสที่ผู้ก่อตั้งที่สร้าง公司在สิบปีต่อมาล้วนเคยเป็น FDE ในชีวิตที่แล้ว ซึ่งกำลังเกิดขึ้นในวันนี้

จะรู้ได้อย่างไรว่าคุณมีจริงๆ

คุณไม่สามารถตัดสินทีม forward deployment ได้จากภาพรวมในช่วงเวลาใดเวลาหนึ่ง เพราะในวันใดวันหนึ่ง ทีมที่ยอดเยี่ยมและทีมปลอมดูเหมือนกัน: คนฉลาดบินไปหาลูกค้าและส่งมอบผลงานที่กล้าหาญ ห้าข้อตรวจสอบจะเปิดโปงมัน

#1 ความพยายามต่อลูกค้า ทีมที่ให้บริการลูกค้าห้ารายเมื่อปีที่แล้วและให้บริการห้ารายในปีนี้กำลังทบต้นอะไรไม่ได้เลย ทีมที่ตอนนี้ให้บริการสิบห้ารายกำลังป้อนผลิตภัณฑ์ที่ซึมซับสิ่งที่ภาคสนามเรียนรู้ ทุกครั้งที่มีลูกค้าใหม่ ภายในทีมของคุณควรพัฒนาความเชี่ยวชาญเฉพาะด้าน

#2 ความแปลกใหม่ของงาน ถ้าการ deploy ครั้งที่สี่ซ้ำกับการ deploy ครั้งที่สาม แสดงว่าไม่มีใครเป็นเจ้าของท่อส่งจากภาคสนามไปยังแพลตฟอร์ม ต้องมีคนที่ได้รับค่าจ้างให้ล่าสัตว์หาความซ้ำซ้อนในบัญชีต่างๆ เพราะความซ้ำซ้อนคือโรดแมปที่เขียนตัวเอง

#3 รูปร่างของการ deploy ครั้งที่สองในกลุ่มลูกค้า ถ้าลูกค้าคนที่สิบมีต้นทุนเท่ากับลูกค้าคนแรก แสดงว่าคุณไม่ได้ขยายขนาดผลิตภัณฑ์ คุณกำลังแฟรนไชส์โปรเจกต์

#4 สายการรายงาน ภายในฝ่ายผลิตภัณฑ์หรือวิศวกรรม วงจรสามารถปิดได้ ภายในไซโลฝ่ายขายหรือบริการ บทเรียนจะหายไปในรายงานการเดินทางที่ไม่มีใครอ่าน และทีมจะกลายเป็นส่วนต่างของกำไรอย่างเงียบๆ

#5 คะแนนของลูกค้าเอง กิจกรรมเป็นเพียงการแสดง ตัวเลขการใช้งานอาจดูสวยงามในขณะที่ไม่มีอะไรดีขึ้นในขั้นตอนถัดไป การวัดผลเดียวที่รอดพ้นจากการตรวจสอบของ CFO คือการประเมินที่ลูกค้าช่วยเขียน โดยให้คะแนนงานตามผลลัพธ์ของพวกเขาจากข้อมูลของพวกเขา สร้างขึ้นในสัปดาห์แรกและติดตามอย่างเปิดเผย เก็บการทดสอบของมนุษย์ไว้ข้างๆ ด้วย เมื่อมีอะไรผิดพลาดในธุรกิจของพวกเขาที่ไม่เกี่ยวข้องกับผลิตภัณฑ์ของคุณ คุณคือคนแรกที่พวกเขาโทรหาใช่ไหม? แดชบอร์ดทุกอันที่เคยสร้างขึ้นคือความพยายามที่จะประมาณการโทรศัพท์นั้น

และจับตาดูรูปแบบที่มืดมน เพราะมันมีอยู่ทั่วไปในตอนนี้ ในบางบริษัท ทีม forward deployment ไม่ใช่กลไกการเรียนรู้ แต่เป็นเครื่องปกปิด ผลิตภัณฑ์ทำงานไม่ได้ดีนัก ดังนั้นมนุษย์จึงถูกประจำการทุกจุดที่มีช่องว่าง เพราะมนุษย์กล้าหาญ ช่องว่างจึงไม่เคยไปถึงโรดแมป เพราะช่องว่างไม่เคยไปถึงโรดแมป ผลิตภัณฑ์ก็ไม่เคยดีขึ้น และมนุษย์ก็ไม่สามารถจากไปได้ ผลิตภัณฑ์ไม่รู้สึกกดดันเพราะภาคสนามยังคงรับมือได้ ภาคสนามไม่เขียนอะไรลงไปเพราะมันยุ่งเกินไปที่จะรักษาบัญชีลูกค้า ใบแจ้งหนี้ยังคงมาถึงเพราะลูกค้าได้รับบริการจริง เครื่องจักรอยู่ในสมดุล และสมดุลคือปัญหา บริษัทต่างๆ อยู่ภายในนั้นเป็นเวลาหลายปี เพิ่มจำนวนบุคลากรภาคสนามให้เร็วเท่ากับจำนวนลูกค้า และเรียกมันว่า forward deployment มันไม่ใช่ มันคือการไม่มีผลิตภัณฑ์ คิดเงินรายเดือน และมันเป็นเหตุผลว่าทำไมคนที่มีความสามารถมากมายในตำแหน่งเหล่านี้รู้สึกว่าพวกเขากำลังล้มเหลว พวกเขาถูกจ้างมาเพื่อทบต้น แต่ถูกจัดให้มาปกปิด

หน้าตาเป็นอย่างไรในแต่ละขั้นตอน

Stage 0 (Pre-seed / Idea) – ยังไม่มีทีม forward deployment คุณมีผลิตภัณฑ์และสมมติฐานเกี่ยวกับผู้ใช้ที่ต้องการมัน การทดสอบสมมติฐานนี้ทำได้ดีที่สุดโดยการนั่งกับผู้ใช้ที่มีศักยภาพและสังเกตเวิร์กโฟลว์ของพวกเขาโดยตรง ไม่ใช่แค่ถามพวกเขา

Stage 1 (First customer / Pilot) – คุณ (ผู้ก่อตั้ง) คือทีม forward deployment คุณบินไป เรียนรู้ สร้าง digital twin อย่างรวดเร็ว และส่งมอบบางอย่างที่สร้างมูลค่า นี่คือการ deploy ครั้งแรกที่ "น่าเกลียด" งานของคุณคือการเรียนรู้และพิสูจน์ว่าผลิตภัณฑ์ของคุณสามารถแก้ปัญหาจริงได้

Stage 2 (Early repeatability / 2-5 customers) – คุณเริ่มสังเกตเห็นรูปแบบ ความซ้ำซ้อนในการ deploy ครั้งแรกเริ่มชัดเจน คุณอาจจ้าง FDE คนแรก (ไม่ใช่ผู้ก่อตั้ง) งานของคุณคือเริ่มสร้างเทมเพลต การผสานรวม และเอกสารเพื่อให้การ deploy ครั้งต่อไปถูกกว่าและเร็วกว่า การ deploy ครั้งที่สองในกลุ่มลูกค้าเดียวกันควรมีลักษณะที่แตกต่างจากการ deploy ครั้งแรก

Stage 3 (Scaling / 5-20+ customers) – ทีม FDE กำลังเติบโต คุณมีนักยุทธศาสตร์การ deployment อย่างน้อยหนึ่งคนที่คอยมองหาความซ้ำซ้อนข้ามบัญชีลูกค้า และผลักดันให้รูปแบบต่างๆ กลับไปสู่โรดแมปของผลิตภัณฑ์ การ deploy ครั้งที่สิบควรใช้การกำหนดค่าเป็นส่วนใหญ่ ไม่ใช่การทำด้วยมือ ทีม FDE กำลังพัฒนาความเชี่ยวชาญเฉพาะด้านในอุตสาหกรรมหรือโดเมนนั้นๆ เส้นโค้งการทบต้นควรเริ่มชัดเจน: ต้นทุนต่อการ deploy ลดลง ในขณะที่มูลค่าที่ส่งมอบเพิ่มขึ้น

Stage 4 (Platform / OS) – ผลิตภัณฑ์ได้ซึมซับบทเรียนจากภาคสนามมากมายจนกลายเป็นระบบปฏิบัติการสำหรับเวิร์กโฟลว์ประเภทนั้น การ deploy ใหม่สำหรับลูกค้าส่วนใหญ่เป็นเรื่องของการกำหนดค่าและการปรับแต่งเล็กน้อย ทีม FDE ขยับขึ้นไปอีกระดับ แก้ปัญหาที่ซับซ้อนมากขึ้นซึ่งไม่มีอยู่เมื่อหนึ่งปีก่อน พวกเขากำลังสร้าง use case ใหม่และขยายขอบเขตของสิ่งที่ผลิตภัณฑ์สามารถทำได้ ณ จุดนี้ ทีม FDE ควรจะสามารถถอยออกมาได้ ลูกค้าควรจะสามารถใช้โซลูชันได้อย่างต่อเนื่องโดยไม่ต้องพึ่งพาทีม FDE อย่างหนัก วงจรการเรียนรู้จากภาคสนามไปยังผลิตภัณฑ์ควรจะปิดสนิทและรวดเร็ว

ระยะเริ่มต้น อย่าจ้างคนให้ทำ จงลงมือทำด้วยตัวเอง ผู้ก่อตั้งคือทีมปฏิบัติการ前线 และสิ่งที่แย่ที่สุดที่คุณสามารถทำได้กับความเข้าใจอันจำกัดของคุณคือการมอบหมายให้คนอื่นไปทำความเข้าใจแทน ออกเดินทางสองวันด้วยตัวเอง นั่งคุยกับผู้จัดส่งสินค้า เมื่อคุณจ้างคนในที่สุด จ้างคนที่ช่วยให้คุณปิดงานได้เร็วขึ้น ไม่ใช่คนที่มายืนขวางระหว่างคุณกับลูกค้า

ระยะเติบโตคือช่วงที่การปฏิบัติการ前线ถูกมองผิด เพราะจากภายนอกมันดูเหมือนการชะลอตัวลง คณะกรรมการของคุณเฝ้าดูวิศวกรใช้เวลาหลายสัปดาห์อยู่กับลูกค้ารายเดียว ขณะที่คู่แข่งประกาศฟีเจอร์ใหม่ทุกสัปดาห์ ระบบบัญชีทำให้เรื่องแย่ลงไปอีก ค่าใช้จ่ายในการปฏิบัติการ前线ถูกจัดอยู่ในต้นทุนรายได้ ทั้งที่งานนี้มีลักษณะเหมือน R&D ยิ่งคุณเรียนรู้ได้ดีเท่าไหร่ ตัวเลขก็ยิ่งดูแย่มากขึ้นเท่านั้น จงยึดถือความจริงทั้งสองด้านโดยไม่บิดเบือนไปทางใดทางหนึ่ง ในบัญชีมันคือต้นทุน ในเชิงกลยุทธ์มันคือการวิจัย ทางออกไม่ใช่การเล่าเรื่อง แต่เป็นแนวป้องกันที่บังคับให้การวิจัยต้องสร้างผลตอบแทน กำหนดกรอบเวลาสำหรับแต่ละโครงการ เชื่อมโยงแต่ละโครงการเข้ากับผลลัพธ์ทางธุรกิจที่ชัดเจนหนึ่งอย่าง เก็บเกี่ยวผลลัพธ์ทุกไตรมาส หมายความว่าทุกไตรมาส สิ่งที่ทีมภาคสนามสร้างขึ้นด้วยมือจะกลายเป็นสิ่งที่แพลตฟอร์มทำได้โดยอัตโนมัติ ประโยคที่ว่า "เราจะทำให้เป็นผลิตภัณฑ์ในภายหลัง" คือสิ่งที่ฆ่าบริษัทในระยะนี้ เพราะ "ภายหลัง" ไม่มีเจ้าของ

เมื่อถึงขนาดใหญ่ คำถามก็เปลี่ยนรูปร่าง คุณมีลูกค้าหลายร้อยรายที่จ่ายเงินเป็นล้าน และคุณมีที่ปรึกษาโซลูชัน ทีมติดตั้งimplement บริการจัดการ ผู้จัดการลูกค้าสัมพันธ์ ทีมดูแลความสำเร็จของลูกค้าอยู่แล้ว ผู้นำในระยะนี้ไม่รู้จริงๆ ว่าทีมปฏิบัติการ前线ควรอยู่ตรงไหน มันเลยถูกเพิ่มเข้าไปเป็นระดับที่สี่ของการสนับสนุน และตายเพราะปริมาณคำขอที่ท่วมท้น คำตอบคือ ทุกฟังก์ชันที่มีอยู่แล้วมี playbook ของตัวเอง และทีมปฏิบัติการ前线จะอยู่ตรงที่ไม่มี playbook เท่านั้น ลูกค้าที่มีความทะเยอทะยานที่สุดสิบราย ตลาดแนวตั้งใหม่ เวิร์กโฟลว์ที่ทั้งอุตสาหกรรมบอกว่าไม่สามารถทำให้เป็นอัตโนมัติได้ แต่คุณรู้สึกว่าคุณสามารถทำให้เป็นอัตโนมัติได้ มันรายงานตรงต่อฝ่ายผลิตภัณฑ์ มีภารกิจทำให้งานของตัวเองไม่จำเป็นอีกต่อไป และส่งต่อทุกแพทเทิร์นที่แก้ไขได้ให้กับทีมที่ดูแล playbook ซึ่งนั่นคือวิธีที่ทำให้ playbook ยังมีชีวิตอยู่ เวอร์ชันของ Uber เรื่องนี้เป็นบทเรียนที่ดี พวกเขาจับคู่วิศวกรที่เชี่ยวชาญด้าน AI ที่สุดกับผู้เชี่ยวชาญเฉพาะด้านจากฝ่ายการเงิน กฎหมาย และสนับสนุน ให้แต่ละคู่มีเวลาสองสัปดาห์ และกำหนดให้ต้องสร้างระบบไปพร้อมกับคนที่เป็นเจ้าของเวิร์กโฟลว์ แทนที่จะนำเสนอให้พวกเขาดู สองวันสำหรับการสังเกตการณ์ หนึ่งวันสำหรับเลือกเป้าหมาย ใช้งานได้จริงภายในวันที่สิบ สิบหกทีม (pod) ปรับเปลี่ยนการทำงานสิบหกฟังก์ชันในสองเดือน และรายงานที่เคยใช้เวลาสองวัน ตอนนี้ใช้เวลาเพียงสิบนาที หน่วยของระบบอัตโนมัติไม่เคยเป็นงานเดี่ยวๆ มันคือเวิร์กโฟลว์ และเวิร์กโฟลว์จะเผยตัวต่อคนที่นั่งอยู่ในนั้นเท่านั้น

งานเดียวกัน แต่สวมชุดที่แตกต่างกันในทุกอุตสาหกรรม

ในด้านการป้องกันประเทศและรัฐบาล การมีตัวตนคือตัวผลิตภัณฑ์ การรักษาความปลอดภัย เครือข่ายที่ตัดขาดจากโลกภายนอก ห้องที่แล็ปท็อปของคุณนำออกไปไม่ได้ ในด้านการดูแลสุขภาพ งานคือการขุดค้นทางโบราณคดีของเวิร์กโฟลว์ กระบวนการจริงทำงานผ่านระบบบันทึกที่มีอายุยี่สิบปี โดยมีเครื่องแฟกซ์และสายโทรศัพท์ที่ยังคงรับผิดชอบกรณีพิเศษ ทุกสถานที่ดำเนินการตามรูปแบบที่ไม่ได้เขียนไว้เป็นของตัวเอง ทีมที่คิดว่าทุกอย่างเป็นมาตรฐานจะเสียเวลาไปหนึ่งปี ในด้านบริการทางการเงิน ลูกค้าซื้อการตัดสินใจภายใต้การปฏิบัติตามกฎระเบียบ สิ่งที่ส่งมอบมักจะเป็นรายงานที่ผู้ตรวจสอบสามารถอ่านได้ และความกังวลที่ลึกที่สุดไม่ใช่การรั่วไหลของข้อมูล แต่เป็นการรั่วไหลของการตัดสินใจ รูปแบบการตัดสินใจของคนที่ดีที่สุดของพวกเขาไหลเข้าไปในโมเดลของคนอื่น ในด้านการผลิตและโลจิสติกส์ ความจริงอยู่ที่หน้างาน และข้อจำกัดเป็นเรื่องทางกายภาพ ซึ่งเป็นเหตุผลว่าทำไมการค้นพบจึงไม่สามารถเกิดขึ้นผ่านวิดีโอได้ และระบบบันทึกนั้นล้าสมัย ซับซ้อนอย่างเห็นได้ชัด และมักจะไม่เชื่อมต่อกับคลาวด์ ในธุรกิจที่เน้นผู้บริโภค วงจรทำงานในหน่วยวันแทนที่จะเป็นไตรมาส และทักษะที่หายากคือรสนิยม การรู้ว่าแบรนด์ควรมีเสียงเป็นอย่างไร และเมื่อไหร่ที่เครื่องควรหยุดพูด และดินแดนใหม่ล่าสุดคือบริษัทของคุณเอง ทีม (pod) เดียวกัน ถูกส่งไปในฝ่ายการเงิน กฎหมาย และสนับสนุนของคุณเอง เพราะช่องว่างระหว่างสิ่งที่ AI ทำได้กับสิ่งที่องค์กรของคุณทำจริงนั้นเป็นช่องว่างเดียวกัน ห่างกันแค่อาคารเดียว

ภูมิประเทศกำหนดยุทธวิธี และยุทธวิธีนั้นต่อรองได้ แต่ลำดับขั้นตอนไม่ใช่ นั่งลงกับงาน ปิดงาน ป้อนข้อมูลให้กับผลิตภัณฑ์

ใครเก่งเรื่องนี้จริงๆ

บรรพบุรุษ Palantir ยังคงรันเวอร์ชันที่ลึกที่สุด และรายละเอียดที่ทุกคนลืมคือ โมเดลนี้เกิดขึ้นก่อนผลิตภัณฑ์ ในตอนแรกไม่มีอะไรให้กำหนดค่า มีเพียงเดิมพันว่าถ้าคุณนั่งอยู่ในสถาบันที่พังทลายนานพอ ผลิตภัณฑ์จะเผยตัวออกมาเอง มันก็เป็นอย่างนั้น และวันนี้บริษัทเดียวกันนี้รันการมีส่วนร่วมที่สั้นลงและเป็นแม่แบบมากขึ้น เพราะเมื่อผลิตภัณฑ์มีอยู่แล้ว การทบต้นคือศาสนา

คนรุ่นใหม่เห็นได้ง่ายที่สุดในบริษัทที่ให้บริการตัวแทนลูกค้าสัมพันธ์ Sierra รันฟังก์ชันภาคสนามของตนในฐานะวิศวกรตัวแทน (agent engineers) และวงจรนี้ตั้งใจไว้ แก้ปัญหาให้ลูกค้าหนึ่งราย เผยแพร่สิ่งที่ใช้ได้ผลภายในบริษัท จากนั้นเลื่อนระดับผู้ชนะขึ้นไปสู่แพลตฟอร์ม เพื่อให้ลูกค้าทุกคนได้รับประโยชน์ เมื่อวิศวกรของพวกเขาเรียนรู้ จากการใช้งานหลายสิบครั้ง ว่าตัวแทนควรหยุดลองใหม่และส่งต่อลูกค้าให้คนเมื่อไหร่ การตัดสินใจนั้นกลายเป็นส่วนประกอบที่ใช้ซ้ำได้ จากนั้นพวกเขาก็สร้าง Ghostwriter ตัวแทนที่ทำหน้าที่สร้าง โดยป้อนข้อมูลจากบทสนทนาการโทร SOP และรูปถ่ายไวท์บอร์ด ทำงานบนแพลตฟอร์มที่พวกเขาออกแบบใหม่เพื่อให้ตัวแทนสามารถใช้งานได้โดยตรง การเดิมพันใน Sierra คือการเดิมพันว่าทีมภาคสนามของมันจะยังคงค้นพบเวิร์กโฟลว์ที่ไม่มีใครเคยเห็น Decagon ใช้เส้นทางด้านระบบ ตรวจสอบการใช้งานของตนเพื่อหางานที่ไม่มีเหตุผลที่จะต้องทำแบบเฉพาะเจาะจง ลดวิศวกรรมที่กำหนดเองเบื้องหลังตัวแทนแต่ละตัวลงแปดสิบเปอร์เซ็นต์ จากนั้นก็พูดความจริงที่เงียบขรึมออกมาว่า การส่งมอบ ไม่ใช่ผลิตภัณฑ์ กำลังกลายเป็นคูเมือง Ramp จัดทีมภาคสนามด้วยอดีตผู้ก่อตั้งเป็นส่วนใหญ่ ชี้เป้าไปที่วงจรชีวิตลูกค้าทั้งหมด ตั้งแต่การติดต่อครั้งแรกไปจนถึงการสนับสนุนระยะยาว และฝึกฝนนิสัยหนึ่งข้อเหนือสิ่งอื่นใด นั่นคือตั้งคำถามกับความต้องการก่อนที่จะสร้างมัน เพราะคำขอที่ระบุไว้มักจะเป็นอาการ ไม่ใช่โรค

เมื่อคุณรู้รูปทรงแล้ว คุณจะเห็นมันในทุกตลาดแนวตั้งที่จริงจัง Harvey ส่งทนายความที่เคยปฏิบัติงานจริงไปยังสำนักงานกฎหมาย พิสูจน์ว่าคนที่ถูกส่งไปประจำการไม่จำเป็นต้องเป็นวิศวกรเลย ขอแค่ต้องรับผิดชอบเท่านั้น ในด้านการเงิน Rogo จัดพนักงานเกือบครึ่งบริษัทเป็นอดีตนายธนาคารที่ถูกส่งไปยังสถาบันที่พวกเขามาจาก ในขณะที่ Hebbia ส่งวิศวกรไปสร้างขั้นตอนสุดท้ายภายในผู้จัดการสินทรัพย์ที่ใหญ่ที่สุดในโลก Abridge กำลังจัดตั้งทีมปฏิบัติการ (deployment pods) ร่วมกับระบบโรงพยาบาล เพราะการนำ AI scribe ไปให้แพทย์หนึ่งหมื่นสองพันคนไม่ใช่การติดตั้ง มันคือการรณรงค์ HappyRobot ฝังตัวกับนายหน้าขนส่งสินค้า Gecko Robotics ส่งช่างก่อสร้างไปยังเรือรบ Applied Intuition นั่งอยู่ภายในผู้ผลิตรถยนต์รายใหญ่ส่วนใหญ่ของโลก และ Cursor (SpaceX) รันทีมปฏิบัติการ前线ที่เชื่อมต่อเครื่องมือที่วิศวกรของคุณรักอยู่แล้ว เข้ากับธนาคารและบริษัทโทรคมนาคม

รูปร่างต่างกัน ฟิสิกส์เดียวกัน ภาคสนามหล่อเลี้ยงโรงงาน มิฉะนั้นมันก็ไม่ใช่การปฏิบัติการ前线

ข้อโต้แย้งที่แข็งแกร่งที่สุด (เพราะมันสมควรได้รับ)

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

จงจริงจังกับเรื่องนี้ เพราะสำหรับผู้ขายหลายราย มันเป็นเรื่องจริง การทดสอบที่แยกสายพันธุ์คือสิ่งเดียวกับที่บทความนี้พูดซ้ำแล้วซ้ำเล่า ถ้ามนุษย์ที่อยู่ตรงช่องว่างนั้นเป็นแบบถาวร ข้อโต้แย้งก็ชนะ และคุณกำลังเช่าชิ้นส่วน ถ้ามนุษย์ที่อยู่ตรงช่องว่างนั้นกำลังทบต้น ปิดงานในลักษณะที่ขจัดความจำเป็นในการมีตัวเอง ข้อโต้แย้งก็ตายในการใช้งานครั้งที่สอง สิ่งที่มันพลาดไปคืองานส่วนใหญ่ไม่เคยเป็นการตกแต่งผลิตภัณฑ์ มันคือการได้มาซึ่งบริบท ห้าขั้นตอนที่ไม่ได้บันทึกไว้ สัญชาตญาณที่ไม่ได้พูดของผู้จัดส่ง ความช่วยเหลือที่แลกเปลี่ยนกันข้ามอาคาร ไม่มีผลิตภัณฑ์ที่เสร็จสมบูรณ์จะมาพร้อมกับสิ่งเหล่านั้น เพราะมันแตกต่างกันในทุกบริษัท ใครสักคนต้องไปหามันมา คำถามเดียวที่สำคัญคือ สิ่งที่พวกเขาได้มานั้นทบต้นเป็นสินทรัพย์ หรือระเหยไปเป็นใบแจ้งหนี้

อนาคตจะเป็นอย่างไร

การเปลี่ยนแปลงสี่อย่างกำลังเกิดขึ้นแล้ว

บริบทกลายเป็นสินทรัพย์ สิ่งที่ทีมปฏิบัติการสร้างขึ้นจริงๆ ที่ลูกค้าแต่ละรายคือแบบจำลองการทำงานว่าบริษัทนั้นดำเนินการอย่างไร อภิปรัชญา (ontology) คู่แฝด (twin) แผนที่ว่าใครตัดสินใจอะไรและทำไม นักลงทุนเริ่มเรียกมันว่าสมองของบริษัท และชื่อนี้กำลังติด เพราะทุกบริษัทกำลังจะต้องการมัน มากกว่าที่คนคิดสามารถเริ่มต้นได้ก่อนที่ใครจะขึ้นเครื่องบิน เพราะลูกค้ารั่วไหลความจริงของพวกเขาอยู่ตลอดเวลา ในคำขอบริการสนับสนุน บทสนทนาการโทร อีเมล เธรดการยกระดับปัญหา เริ่มต้นที่นั่น แต่ชั้นที่ลึกที่สุด ความรู้ที่คนไม่สามารถพูดออกมาเป็นคำพูด ยังคงต้องการการมีตัวตนและกระจกเงา เครื่องมือที่ให้คนวงในตรวจสอบสัญชาตญาณของตัวเองจนกว่ามันจะกลายเป็นตรรกะ ใครก็ตามที่ถือแผนที่นั้น จะถือบัญชีนั้น ซึ่งทำให้เกิดคำถามที่ CEO ทุกคนกำลังจะถามผู้ขาย AI ทุกราย "ฉันกำลังเช่าความฉลาด แต่ใครเป็นเจ้าของการเรียนรู้?" ถ้าโมเดลที่ใช้ร่วมกันหนึ่งตัวดูดซับการตัดสินใจด้านเครดิตจากผู้ให้กู้ทุกรายในตลาด ผู้รับประกันภัยที่เฉียบคมที่สุดในกลุ่มนั้นกำลังฝึกฝนคู่แข่งของเธอและจ่ายเงินเพื่อสิทธิพิเศษนั้น มีการทดสอบที่ CFO ทุกคนสามารถทำได้ เปลี่ยนผู้ขายโมเดลพรุ่งนี้ ในทางทฤษฎี และตรวจสอบว่าทุกสิ่งที่คุณสอนระบบนั้นเดินออกไปพร้อมกับมันหรือไม่ คาดหวังว่าสัญญา ทีม และในที่สุดบริษัท จะถูกจัดระเบียบใหม่รอบบรรทัดเดียว "เช่าความฉลาด เป็นเจ้าของการเรียนรู้"

ตัวแทน (Agent) เข้าร่วมทีม ตัวแทนปฏิบัติการ前线มีอยู่แล้วในรูปแบบเริ่มต้น ตัวแทนสำหรับการเริ่มต้นใช้งานที่บีบอัดงาน Integration ในช่วงบ่ายให้เหลือไม่กี่นาที ตัวแทนสำหรับการปรับใช้ที่อ่าน Transcript ของตัวเองในชั่วข้ามคืนและเสนอการปรับปรุงให้กับทักษะของตัวเอง ดูว่าสิ่งนี้ทำอะไรกับบทบาทของมนุษย์ การแทรกแซงด้วยตนเองทุกครั้งจะหยุดเป็นงานและกลายเป็นสัญญาณสำหรับการฝึกอบรม และงานของทีมจะกลับด้าน จากการทำการปรับใช้เป็นการรันโรงงานที่ทำการปรับใช้ แบบจำลองการจัดหาพนักงานในแบบที่ผู้จัดการจัดหาคน เขียนการประเมินในแบบที่ผู้จัดการเขียนรีวิว การกลับด้านที่ลึกกว่านั้นคือในเรื่องของผู้ใช้ ผลิตภัณฑ์กำลังถูกสร้างขึ้นใหม่เพื่อให้ตัวแทนสามารถใช้งานได้โดยตรง และคำถามการค้นพบแรกที่ลูกค้ากำลังเปลี่ยนจาก "ทีมของคุณต้องการอะไร" เป็น "ตัวแทนของคุณต้องการอะไร" การพลิกกลับเดียวกันกำลังกระทบฝั่งรายได้ โดยที่คนคนเดียวที่มีฝูงตัวแทนตอนนี้รัน Pipeline ที่แต่ก่อนต้องใช้คนทั้งชั้น และซอฟต์แวร์หลังการขายกำลังเปลี่ยนชื่อตัวเองจากเครื่องมือเป็นบริการที่รับผิดชอบผลลัพธ์ การรักษาลูกค้าเป็นบริการวันนี้ การขยายธุรกิจเป็นบริการวันพรุ่งนี้ และเมื่อตัวแทนของลูกค้าคุณเริ่มเจรจากับตัวแทนของคุณ มนุษย์ที่เหลืออยู่ทั้งสองฝั่งของโต๊ะจะทำสองสิ่งที่ Loop ไม่สามารถปิดได้ด้วยตัวเอง นั่นคือตัดสินใจว่าสิ่งใดควรค่าแก่การต้องการ และรับรองว่ามันเกิดขึ้นจริง

พื้นถูกลดระดับลง การปรับใช้ที่เคยต้องใช้เงินห้าล้านดอลลาร์และวิศวกรรมระดับสูงเมื่อไม่กี่ปีก่อน ตอนนี้ใช้เงินเพียงไม่กี่แสนดอลลาร์และนักทั่วไปที่เฉียบคมพร้อมตัวแทนที่ดี และราคาก็ยังคงลดลงเรื่อยๆ การปฏิบัติการ前线หยุดเป็นสินค้าฟุ่มเฟือยของ Fortune 500 และกลายเป็นวิธีที่ซอฟต์แวร์ขายให้กับตลาดกลาง ข้อจำกัดหยุดเป็นอุปทานวิศวกรรมและกลายเป็นอุปทานการตัดสินใจ

ตำแหน่งงานสลายตัว วิศวกรทุกคนในบริษัทที่จริงจังกำลังกลายเป็นส่วนหนึ่งของทีมปฏิบัติการ前线 วิศวกรแบ็กเอนด์นั่งอยู่ในสายลูกค้า วิศวกรผลิตภัณฑ์ทำงานโดยใช้ Transcript การโทร ในไม่ช้า เปอร์เซ็นต์ของเวลาที่เผชิญหน้ากับลูกค้าจะเป็นข้อแตกต่างเพียงอย่างเดียวระหว่าง FDE และวิศวกรซอฟต์แวร์ และตำแหน่งงานจะหยุดแสร้งทำเป็นอย่างอื่น ซึ่งมาพร้อมกับคำเตือนที่ไม่มีใครพิมพ์ในประกาศรับสมัครงาน งานนี้เปลี่ยนผู้สร้างให้เป็นนักการทูต และวิศวกรที่เก่งหลายคนเลือกที่จะสร้างเพราะห้องที่เต็มไปด้วยคนแปลกหน้าทำให้พวกเขาหมดแรง เคารพคนเก็บตัวโดยไม่ส่งพวกเขาไปปฏิบัติการ และเคารพบทบาทนี้โดยไม่ใช้มันเป็นที่เก็บวิศวกรที่ mediocre ในการเป็นวิศวกร มันตรงกันข้าม มันคือที่ที่คุณส่งคนที่คุณไว้ใจให้ไปก่อตั้งอะไรสักอย่าง

งานที่เก่าแก่ที่สุดในบริษัท

ลอกศัพท์เทคนิคออกไป การปฏิบัติการ前线คือท่าทางดั้งเดิมของผู้ก่อตั้ง ที่ถูกเก็บรักษาไว้ภายในบริษัทที่เติบโตใหญ่พอที่จะลืมมัน นั่งตรงที่งานอยู่ ปิดงาน ปล่อยให้สิ่งที่คุณเรียนรู้เปลี่ยนสิ่งที่คุณสร้าง ทุกบริษัทที่ endure ทำสิ่งนี้ก่อนที่มันจะมีชื่อเรียก บริษัทส่วนใหญ่หยุดทำสิ่งนี้ในวันที่พวกเขาสามารถจ่ายได้

ดังนั้นคำถามที่แท้จริงไม่เคยใช่ "จะจ้างวิศวกรปฏิบัติการ前线หรือไม่" มันคือ "คุณเต็มใจที่จะรันบริษัทที่คนที่ใกล้ชิดกับความจริงที่สุดมีอำนาจจริงๆ หรือไม่ ที่ซึ่งความพยายามถูกตัดสินจากความลาดชันของมัน และที่ซึ่งไม่มีสิ่งที่เรียนรู้ในภาคสนามได้รับอนุญาตให้ตายอยู่ที่นั่น" สร้างสิ่งนั้น แล้วตำแหน่งงานจะดูแลตัวเอง

ชิ้นงานสุดท้ายที่ทีมของคุณปิดอย่างสมบูรณ์จนลูกค้าหยุดคิดถึงมันคืออะไร? ครั้งสุดท้ายที่ลูกค้าต่ออายุสัญญา ไม่ใช่เพราะพวกเขาได้รับคุณค่าจากชุดผลิตภัณฑ์ของคุณ แต่เพราะพวกเขารู้ว่าคุณจะสร้างสิ่งที่พวกเขาไม่รู้ด้วยซ้ำว่าต้องการเพื่อเติบโตธุรกิจของพวกเขา? เริ่มนับจากตรงนั้น

บันทึกในคลิกเดียว

อ่านบทความไวรัลเชิงลึกด้วย AI ใน YouMind

บันทึกแหล่งที่มา ถามคำถามที่ตรงประเด็น สรุปข้อโต้แย้ง และเปลี่ยนบทความไวรัลให้เป็นโน้ตที่นำกลับมาใช้ได้ใน AI เวิร์กสเปซเดียว

สำรวจ YouMind
สำหรับครีเอเตอร์

เปลี่ยน Markdown ของคุณให้เป็นบทความ 𝕏 ที่สะอาดตา

เวลาคุณเผยแพร่งานเขียนยาวของตัวเอง การจัดรูปแบบรูปภาพ ตาราง และบล็อกโค้ดให้เข้ากับ 𝕏 นั้นน่าปวดหัว YouMind เปลี่ยนร่าง Markdown ทั้งฉบับให้เป็นบทความ 𝕏 ที่สะอาดตาและพร้อมโพสต์ทันที

ลอง Markdown เป็น 𝕏

แพตเทิร์นให้ถอดรหัสเพิ่มเติม

บทความไวรัลล่าสุด

สำรวจบทความไวรัลเพิ่มเติม