Sergey Brin ยกตัวอย่าง Google Glass เพื่อเตือนผู้ก่อตั้งสตาร์ทอัพว่าอย่าเพิ่งปล่อยผลิตภัณฑ์ออกสู่ตลาดเร็วเกินไป ควรขัดเกลาคุณสมบัติหลักและคุณค่าที่แตกต่างให้ดีเสียก่อน เพื่อหลีกเลี่ยงการติดกับความเร็วและการวนลูปพัฒนาแบบผิดจุด
นี่คือการแบ่งปันเรื่องสตาร์ทอัพที่ตรงไปตรงมาและใช้งานได้จริงที่สุดที่ผม (ในฐานะผู้ก่อตั้ง) ได้เห็นในช่วงปีที่ผ่านมา: อย่า “Lean Startup”
ช่วงนี้ผมกำลังทำงานอยู่ 2 อย่างหลัก:
- ลงมือสำรวจและใช้งานผลิตภัณฑ์ AI จำนวนมาก เพื่อเข้าใจว่าการมี AI เพิ่มพลังให้ความสามารถของผู้ก่อตั้งที่ไม่มีพื้นฐานด้านการเขียนโค้ดเป็นอย่างไร และเพื่อทำความเข้าใจ “ขอบเขตความสามารถ” ของเครื่องมือ AI ในปัจจุบัน ผมได้สร้างเวิร์กโฟลว์ AI แบบครบชุด และพัฒนาขึ้นใช้งานจริง จนตอนนี้ผลิตภัณฑ์ SaaS ที่สร้างขึ้นสามารถทำเงินได้แล้ว ในช่วงใช้งานในวงจำกัด ตอนนี้ ผมคาดว่าจะอีกไม่กี่วันจะมาแนะนำให้ทุกคนรู้จัก
- สรุปประสบการณ์และบทเรียนจากการสตาร์ทอัพในช่วง 1 ปีที่ผ่านมา รวมกฎการสตาร์ทอัพที่ผมหวังว่าจะยึดถืออย่างต่อเนื่อง และหลีกเลี่ยงกับดักในอนาคตให้ได้มากที่สุด
ในบรรดากฎการสตาร์ทอัพที่ผมรู้สึกซาบซึ้งที่สุด คือกฎที่ผมหวังว่าจะยังคงยึดถือมาตลอด มาจากผู้ประกอบการชื่อดังคนหนึ่งในการแบ่งปันแบบสาธารณะเมื่อไม่นานนี้:
“อย่าเพิ่งประกาศปล่อยผลิตภัณฑ์ของคุณเร็วเกินไป”
นี่คือคำตอบจากผู้ก่อตั้ง Google ในงานกิจกรรมในมหาวิทยาลัย Stanford เมื่อเดือนธันวาคมปี 25
โดยประมาณบริบทคือ เดือนธันวาคมปี 2025 ในงานฉลองครบรอบ 100 ปีของ Stanford School of Engineering กิจกรรมสุดท้ายนี้ Sergey Brin ผู้ร่วมก่อตั้ง Google ได้รับเชิญให้กลับมาโรงเรียนเพื่อพูดคุยกัน หนึ่งในผู้ร่วมพูดคืออธิการบดี Stanford Jonathan Levin และคณบดีคณะวิศวกรรมศาสตร์ Jennifer Widom
มีนักศึกษาคนหนึ่งถามว่า “จะเริ่มต้นสตาร์ทอัพอย่างไรให้หลีกเลี่ยงกับดัก”
คำตอบสำคัญของ Brin คือ: อย่าโหมทำเรื่องใหญ่เพื่อเปิดตัวก่อนที่ผลิตภัณฑ์จะพร้อม—เขายกตัวอย่าง Google Glass โดยตรง โดยสรุปคือ: เมื่อคุณมีไอเดียฮาร์ดแวร์สุดเท่และน่าทึ่ง คุณต้องขัดเกลามันให้ “พร้อมและดีจริง” ก่อน แล้วค่อยไปทำกิจกรรมเปิดตัวสุดอลังการ เช่น การกระโดดร่มหรือเรือเหาะ
การแบ่งปันนี้ซื่อตรงมาก ส่วนใหญ่แล้วผู้ประกอบการในงานลักษณะนี้ มักจะพูดถึงมุมมองที่ถูกต้องทางการเมือง หรือคำพูดปลุกใจที่ฟังแล้วดูดีมาก แต่พอกลับมาคิดดูแล้วก็ไม่รู้จะต้องทำอะไรให้เป็นรูปธรรม อย่างไรก็ตาม Brin ให้มุมมองที่ “ลงมือใช้ได้จริง” มาก
ตลอดเวลาที่ผ่านมา เราใช้เวลาไปเยอะมาก ทำผิดพลาดไปเยอะมาก และจ่ายต้นทุนไปมาก เพื่อเข้าใจความสำคัญของคำพูดนี้
เพราะตลอดมามุมมองสตาร์ทอัพที่เราเชื่อกันคืออะไร เช่น Lean Startup, สตาร์ทอัพแบบสายฟ้าแลบ, ยึดผู้ใช้เป็นศูนย์กลาง, และอัปเดต/ปรับปรุงอย่างรวดเร็ว (iterate) ทันที
ทำไมเรื่องนี้อาจจะผิด? เรามาพูดถึง “แก่นที่เป็นฐานรองรับ” ของบลูอินก่อน: เพราะทันทีที่คุณปล่อยผลิตภัณฑ์ออกเร็วเกินไป คุณแทบจะแยกไม่ออกว่า คุณอยู่บนเส้นทาง “การทำ iteration ที่ถูกต้อง” หรือกำลังคอยอุดช่องว่างด้วยสิ่งที่เรียกว่า “ความต้องการของผู้ใช้” หลากหลายแบบ พอคุณเริ่มส่งสัญญาณออกไปภายนอกแล้ว ก็เหมือนกับ “ขึ้นเครื่องวิ่ง (run machine)” — คุณถูกผูกไว้กับไทม์ไลน์การส่งมอบบางอย่าง แต่คุณอาจไม่มีเวลาพอจะทำทุกอย่างที่ควรทำให้เสร็จได้จริง ความคาดหวังจากภายนอกกลับจะเหมือนลูกหิมะ กลิ้งโตขึ้นเรื่อย ๆ และคุณก็ไม่ได้ให้เวลาพอที่จะค่อย ๆ ย่อย ทำการประเมิน และจัดการกับความคาดหวังเหล่านี้
จากประสบการณ์สตาร์ทอัพส่วนตัวของผม ยังมีเหตุผลสำคัญอีกข้อคือ ตอนที่คุณปล่อยผลิตภัณฑ์ออกเร็วเกินไป บางทีคุณยังไม่ได้คิดคำถาม 2 ข้อนี้เลย:
- ตอนนี้ “สายนี้” อะไรเป็นตัวขับเคลื่อนการเกิดของผู้ชนะ: หรือยังมีโอกาสที่ “ขับเคลื่อนด้วยผลิตภัณฑ์” อยู่
- แล้วคุณก็ยิ่งคิดไม่ออกด้วยว่า คำถามถัดไปคืออะไร: ถ้าเป็นแบบ “ขับเคลื่อนด้วยผลิตภัณฑ์” แล้ว “ฟีเจอร์ สมรรถนะ หรือการออกแบบ” ส่วนไหนกันแน่ที่เป็นตัวขับเคลื่อนผลิตภัณฑ์จริง ๆ คืออะไร?
ยกตัวอย่าง UniversalX ที่เราทำ เรากลับ “ทำผิดแบบสุดโต่ง” ทั้งสองข้อผิดนั้น:
เรามองไม่ออกว่าที่จริงแล้วยังมีโอกาสแบบขับเคลื่อนด้วยผลิตภัณฑ์ในตลาด (แม้แต่ยังไม่ได้ประเมินความเป็นไปได้นี้) เราให้ความสำคัญกับสิ่งที่เรียกว่า “หน้าต่างเวลา (time window)” มากเกินไป และโดยแก่นแท้แล้วมันยังสะท้อนว่าเราเป็น “โอกาสเป็นหลัก” เกินไป และฐานของเราคือระบบที่ขี้เกียจเชิงกลยุทธ์ (volue) มากกว่าความเป็นระบบเชิงกลยุทธ์
พอเราไม่ได้ประเมินว่ามีโอกาสแบบขับเคลื่อนด้วยผลิตภัณฑ์อยู่หรือไม่ เราก็ย่อมไม่สามารถตัดสินใจได้ดีที่สุดเมื่อหาความสามารถหลักที่ทำให้เกิดการขับเคลื่อนด้วยผลิตภัณฑ์ ดังนั้น “จุดต่าง” ของเราจึงเป็น “มัลติครึ่ง (multi-chain)” ที่ต่อมาถูกพิสูจน์หักล้างได้ แต่สิ่งที่ตลาดพิสูจน์แล้วว่าผลิตภัณฑ์ที่เป็น trading terminal สามารถขับเคลื่อนได้จากฐานรากแค่เพียง: ความแตกต่างของข้อมูล (alpha อย่างน้อยให้ผู้ใช้รู้สึกว่ามี alpha) หรือความแตกต่างด้านเวลา (performance)
ความผิดพลาดนี้จนกระทั่ง Axiom ออกมา เราถึงเข้าใจจริง ๆ ตอนนั้นทำได้ด้วย “สมรรถนะของผลิตภัณฑ์” และแม้จะเป็นการออกมาช้ากว่า ในสภาพแวดล้อมการแข่งขันที่ดูเหมือนแดงเดือดอยู่แล้ว ก็ยังสามารถครองส่วนแบ่งตลาดได้มากที่สุดอย่างรวดเร็ว จนเราเข้าใจได้ถึง 80% ทำไมไม่ถึง 100% เพราะหลังจากนั้นเรายังทำผิดต่อไป เราไม่ได้ all in ที่ alpha และสมรรถนะ ยังคงแค่ปรับให้เข้าที่/ทำให้ครบ และเติมเต็มฟีเจอร์อยู่ และความผิดพลาดนี้จนถึงวันนี้เรายังคงต้องจ่ายต้นทุนให้มัน ใช่แล้ว เราเพิ่งจะกลับมาเสียเวลาไปกับการทำให้สมรรถนะสอดคล้อง (align performance) (ทั้งที่จากวันที่เราปล่อยผลิตภัณฑ์ออกมาแล้ว 1 ปี และผู้คน 90% ก็รู้สึกว่าธุรกิจ trading terminal ไม่มีความหมายแล้ว)
พูดง่าย ๆ ก็คือ: ตอนที่เราทำสตาร์ทอัพ เราง่ายเกินไปที่จะยก “เร็ว + อัปเดตแบบ iteration” ให้เป็นความจริงที่ไม่อาจหักล้างได้ เราไม่สนุกกับการคิดให้ชัดว่าจุดตัดสินชัยชนะของการแข่งขันในตลาดอยู่ตรงไหน และเราก็ง่ายเกินไปที่จะมองคำติชมใด ๆ จากผู้ใช้ในช่วงแรกเป็นแรงกระตุ้นเชิงบวก อันนี้ยิ่งทำให้ง่ายต่อการทำให้ทิศทางการ iteration วนหลุด (misalignment) และยิ่งเพิ่ม “ต้นทุนจม” ในการปรับธุรกิจให้เร็วขึ้นในภายหลัง (แม้กระทั่งปิดธุรกิจ) (เวลา + อารมณ์ความรู้สึก)
ในยุค AI ผมคิดว่ายิ่งเป็นเช่นนั้น เครื่องมือได้ทำให้ช่องว่างด้านความสามารถในการผลิต (productivity) เรียบลง และเสริมความเท่าเทียมของข้อมูล (information equity) นี่ทำให้ต้นทุนการผลิตของ “ผลิตภัณฑ์ที่พอดี ๆ” และของผลิตภัณฑ์ที่การออกแบบไม่ใช้ “เลเวอเรจ” (ไม่ใช้กลไกเร่งกำลัง) ลดลงแบบเส้นตรง ขณะที่คำว่า “ทำสตาร์ทอัพแบบโหม/แข่งขันกัน (volue startup)” ก็หมดความหมายไป
เหมือนกับประโยคหนึ่งว่า: ในเวลาที่มีตะเกียงวิเศษอยู่เต็มไปหมด การขอพรแบบไหนสำคัญยิ่งกว่า
หยุด Lean Startup หยุดสตาร์ทอัพแบบสายฟ้าแลบ ลองคิดให้ดีว่าความปรารถนาของผลิตภัณฑ์คุณคืออะไร
- บทความนี้ได้รับอนุญาตให้นำมาเผยแพร่ซ้ำจาก:《Foresight News》
- ชื่อบทความต้นฉบับ:《ในฐานะที่เป็น founder หนึ่งปีที่ผ่านมา ผมเห็นการแบ่งปันเรื่องสตาร์ทอัพที่ซื่อตรงที่สุด + ใช้ได้จริง: อย่าทำ Lean Startup》
- ผู้เขียนบทความต้นฉบับ: Pengyu Wang, Particle
