- Quesma เป็นสตาร์ทอัปด้าน database proxy ที่มีทั้งคุณค่าที่นำเสนออย่างชัดเจน ได้รับเงินลงทุนจาก VC มีไพลอตกับบริษัทดัง และมีทีมที่แข็งแกร่ง แต่ภายใน 1 ปีกลับขายสินทรัพย์ด้านเทคโนโลยีและพิวอต
- ปัจจัยหลักคือปัญหาระหว่างผู้ร่วมก่อตั้ง, ข้อจำกัดของการตรวจสอบกับลูกค้า, การหยุดชะงักในขั้นไพลอต, และ ความไม่สอดคล้องระหว่างผลิตภัณฑ์กับตลาด
- ควรเลิกยึดติดกับภาพจำเรื่อง “ความเสี่ยงของผู้ก่อตั้งเดี่ยว” และโครงสร้างที่ ให้หุ้นสูงกับทีมแกนหลัก กลับมีประสิทธิภาพมากกว่า
- แต่ก็ได้บทเรียนว่า ผลิตภัณฑ์ที่ช่วยสร้างรายได้โน้มน้าวตลาดได้ง่ายกว่าผลิตภัณฑ์ที่เน้นลดต้นทุน
- สุดท้ายเทคโนโลยีถูกขายให้ Hydrolix และมองความล้มเหลวครั้งนี้เป็น “ความล้มเหลวที่ดี” พร้อม เปลี่ยนไปสู่ภารกิจการพิวอตครั้งใหม่
ที่มาของการก่อตั้งและการนิยามปัญหา
- CEO Jacek Migdal ทำงานที่ Sumo Logic มา 10 ปี และผ่านประสบการณ์ตั้งแต่ทีม 20 คนจนถึง IPO
- เขาอยากทำโปรเจกต์ใหม่ จึงสัมภาษณ์ลูกค้ามากกว่า 80 ครั้งในช่วง 9 เดือน และค้นพบว่าการเปลี่ยนฐานข้อมูลเป็นปัญหาที่ยากมาก
- proxy เดิมอย่าง PgBouncer มุ่งเน้นเพียงเป้าหมายเฉพาะทาง จึงตัดสินใจสร้าง database gateway ที่ใช้งานได้ทั่วไปมากกว่า
ปัญหาผู้ร่วมก่อตั้ง
- เพราะได้ยินคำพูดว่า “ผู้ก่อตั้งเดี่ยวคือสาเหตุอันดับหนึ่งของความล้มเหลว” จึงชวนอดีตเพื่อนร่วมงานมาเป็นผู้ร่วมก่อตั้ง แต่กลับเกิด ความขัดแย้งจากความแตกต่างด้านความเป็นผู้ประกอบการ
- ผู้ร่วมก่อตั้งที่มาจากบริษัทใหญ่ไม่มี DNA แบบผู้ประกอบการสตาร์ทอัปช่วง ‘Zero-to-One’ และสุดท้ายก็แยกทางกันภายใน 1 ปี
- หลังจากนั้นจึงเปลี่ยนมาเป็นผู้นำเดี่ยว และปรับโครงสร้างทีมใหม่โดย ให้หุ้นในสัดส่วนสูงกับวิศวกรหลัก
- บทเรียน #1: “แทนที่จะฝืนความสัมพันธ์แบบผู้ร่วมก่อตั้งที่เท่าเทียมกัน การมีสมาชิกทีมช่วงแรกที่มีความเป็นเจ้าของสำคัญกว่า”
การระดมทุนช่วงแรกและการสร้างทีม
- ด้วยประสบการณ์จาก Sumo Logic ทำให้นักลงทุนเชื่อมั่น และระดมทุนรอบ seed ได้ 2.5 ล้านดอลลาร์
- สร้างทีมอย่างรวดเร็วในขนาด ‘Two-pizza team’ (ราว 6 คน) และเริ่มพัฒนา MVP
- รีแบรนด์จาก RefactorDB เป็น Quesma และโฟกัสกับการพัฒนา proxy-based MVP ที่แปลง ElasticSearch query เป็น ClickHouse SQL
- บทเรียน #2: “ก่อนจะถึง product-market fit ขนาดทีมแบบ two-pizza team คือขนาดที่เหมาะที่สุด”
คำพูดกับการกระทำ: เมื่อการตรวจสอบอย่างเดียวไม่เพียงพอ
- แม้จะมีลูกค้าที่มีศักยภาพจำนวนมาก แต่ยังขาด การตรวจสอบจากพฤติกรรมจริง
- ลูกค้าองค์กรใหญ่ยอมรับว่าปัญหานี้มีอยู่จริง แต่ไม่กระตือรือร้นที่จะใช้งานผลิตภัณฑ์จริง
- database proxy เป็นเรื่องที่ยาก
- เดิมคาดว่า MVP จะเสร็จใน 5 เดือน แต่ใช้เวลาเพิ่มอีก 4 เดือน และตลาดเริ่มต้นก็แคบกว่าที่คาด
- บริษัทจำนวนมากที่ใช้ ELK stack ได้ย้ายไปใช้สแตกอื่นแล้ว
- บทเรียน #3: “ต้องขอให้ลูกค้าแสดงพฤติกรรมจริงมากกว่าฟังแค่คำพูด เช่น ให้รันสคริปต์ เพื่อยืนยันความตั้งใจที่แท้จริง”
- บทเรียน #4: “โซลูชันที่สร้างรายได้ใหม่ถูกนำไปใช้ได้ง่ายกว่าโซลูชันที่เน้นลดต้นทุน”
ติดอยู่ในนรกของไพลอตตลอดไป (Forever in pilot purgatory)
- แม้ลูกค้าระดับโปรไฟล์สูงจะสนใจมาก แต่การเปลี่ยนไปสู่การติดตั้งหรือใช้งานจริงมีอัตราต่ำ
- มีการทำไพลอตกับหลายบริษัท รวมถึงบริษัทใน Fortune 500 แต่ การใช้งานต่อเนื่องไม่เกิดขึ้น
- การออกบูทในคอนเฟอเรนซ์ก็ไม่ได้มีประสิทธิภาพเช่นกัน
- บทเรียน #5: “ก่อนถึง PMF (product-market fit) วงจรการเรียนรู้ที่รวดเร็วสำคัญกว่าการออกบูทในคอนเฟอเรนซ์”
ความขัดแย้ง การแยกทาง และการเปลี่ยนทิศทาง
- ความร่วมมือพังลงจาก ความขัดแย้งด้านบทบาท และปัญหาการสื่อสารกับผู้ร่วมก่อตั้ง
- หลังจากนั้นแม้จะเปลี่ยนมาเป็นบริษัทที่มีผู้ก่อตั้งเดี่ยว แต่ก็พลาดสัญญาหลัก (ARR ระดับ 6 หลัก)
- หลายบริษัทประเมินว่าปัญหานี้มี “ความสำคัญแค่อันดับ 12” จึงไม่ถูกจัดเป็นลำดับต้นในการนำไปใช้
- ไม่เคยติด 3 อันดับแรกเลย และบริษัทต่าง ๆ ทำได้จริงเพียง 2-3 เรื่องสำคัญต่อไตรมาส
- เมื่อเครื่องมือเขียนโค้ด AI พัฒนาเร็วขึ้น การทำ DB migration แบบอัตโนมัติ ก็เร็วขึ้นตามไปด้วย ทำให้ความจำเป็นของผลิตภัณฑ์ลดลง
- บทเรียน #6: “ต้องตัดสินให้ได้ว่าโซลูชันของเราเป็นผลิตภัณฑ์เดี่ยวจริง ๆ หรือเป็นเพียงฟีเจอร์หนึ่งของผลิตภัณฑ์ที่มีอยู่แล้ว”
การขายกิจการและการพิวอต
- IP ของ Quesma ถูกขายให้ Hydrolix ซึ่งเป็นลูกค้ารายใหญ่ที่สุด และถูกรวมเข้าไปในฟีเจอร์ความเข้ากันได้กับ Kibana
- เงินจากการขายถูกนำไปใช้เป็นทุนสำหรับการพิวอตครั้งถัดไป และช่วยให้ยังรักษาทีมไว้ได้
- ผู้ก่อตั้งหลายคนอาจวางเรื่องนี้ให้เป็น “เรื่องราวความสำเร็จ” แต่สำหรับเขา มันคือ ประสบการณ์การเรียนรู้เพื่อสร้างสิ่งที่ใหญ่กว่าเดิม
- ตอนนี้กำลังกลับมาลุยภารกิจใหม่อีกครั้งพร้อมกับทีม
ยังไม่มีความคิดเห็น