จงทำสิ่งที่ยังขยายสเกลไม่ได้ (2013)
(paulgraham.com)- Y Combinator แนะนำว่าในช่วงเริ่มต้นของการก่อตั้งสตาร์ทอัพ ควรลงมือทำ "สิ่งที่ยังไม่สามารถสเกลได้" อย่างจริงจัง
- สตาร์ทอัพที่ประสบความสำเร็จอย่าง Stripe และ Airbnb เลือกใช้แนวทางที่ตรงไปตรงมาและเชิงรุกในการ หาผู้ใช้กลุ่มแรก
- สตาร์ทอัพส่วนใหญ่ เปราะบางมากในระยะแรก และความทุ่มเทที่ผู้ก่อตั้งลงมือเองคือหัวใจของการเติบโต
- การมอบ ประสบการณ์ที่ยอดเยี่ยมและความพึงพอใจ ให้ผู้ใช้กลุ่มแรกมีความสำคัญต่อการเติบโตระยะยาว
- ในช่วงเริ่มต้น งานแบบแมนนวลแทนระบบอัตโนมัติ, การเจาะตลาดเฉพาะกลุ่ม, การให้คำปรึกษาโดยตรง ล้วนได้ผล
บทนำ: ความจริงของการเติบโตในสตาร์ทอัพ
- ผู้ก่อตั้งมือใหม่จำนวนมากคิดว่าสตาร์ทอัพจะเติบโตได้เอง แต่ในความเป็นจริง ผู้ก่อตั้งต้องออกหน้าจุดประกายการเติบโตด้วยตัวเอง
- เช่นเดียวกับมือหมุนสตาร์ตรถยนต์ในอดีต ช่วงแรกจำเป็นต้องผ่าน กระบวนการที่ใช้แรงงานเข้มข้น
ออกไปหาผู้ใช้ด้วยตัวเอง (Recruit)
- สตาร์ทอัพส่วนใหญ่ไม่ควร รอให้ผู้ใช้เดินเข้ามาเองแบบตั้งรับ แต่ต้องพยายามออกไปหาโดยตรง
- ในกรณีของ Stripe ช่วงแรกใช้วิธีที่เรียกว่า 'Collison installation' โดยเมื่ออีกฝ่ายได้รู้จักเวอร์ชันเบต้าแล้ว ก็ใช้กลยุทธ์หาผู้ใช้เชิงรุกด้วยการ รับโน้ตบุ๊กของอีกฝ่ายมาติดตั้งให้ถึงที่
- เหตุผลที่ผู้ก่อตั้งมักไม่อยากทำเรื่องแบบนี้คือ ความกลัวการถูกปฏิเสธ ความอับอาย และการมองว่าจำนวนผู้ใช้ที่น้อยยังไม่สำคัญ
- แต่ในความเป็นจริง ด้วย พลังของการเติบโตแบบทบต้น ต่อให้รักษาการเติบโต 10% ต่อสัปดาห์ได้ ก็อาจมีผู้ใช้นับล้านในอีก 2 ปี
- Airbnb ก็ เชิงรุกถึงขั้นออกไปพบโฮสต์ในนิวยอร์กด้วยตัวเองเพื่อช่วยลงทะเบียน
ความเปราะบางของสตาร์ทอัพระยะแรก (Fragile)
- สตาร์ทอัพแทบทั้งหมด ไม่มั่นคงอย่างมากในช่วงแรก และความพยายามโดยตรงในระยะสั้นอาจเป็นตัวแบ่งระหว่างความสำเร็จกับความล้มเหลว
- สิ่งที่อันตรายกว่าความเมินเฉยจากนักวิจารณ์ภายนอกหรือนักลงทุน คือ การที่ผู้ก่อตั้งประเมินคุณค่าธุรกิจของตัวเองต่ำเกินไป
- ในช่วงแรก คำถามที่ควรถามตัวเองไม่ใช่ "บริษัทนี้จะเปลี่ยนโลกไหม?" แต่คือ "ถ้าลงแรงอย่างถูกทาง มันจะเติบโตได้ไกลแค่ไหน?"
- ตัวอย่างเช่น ช่วงเริ่มต้นของ Microsoft และ Airbnb ดูเล็กน้อยมากจากภายนอก แต่ก็เป็นเส้นทางที่ดีที่สุดแล้ว
- ผู้ใช้ที่เหมาะสมควรเริ่มจาก คนที่คล้ายกับตัวผู้ก่อตั้งเอง หรือค้นหาว่าในบรรดาผู้ใช้ยุคแรก กลุ่มใดกระตือรือร้นที่สุด แล้วโฟกัสเจาะกลุ่มนั้น
ทำให้ผู้ใช้ปลื้มที่สุด (Delight)
- นอกจากการหาผู้ใช้แล้ว ยังต้องใช้ ความพยายามอย่างไม่ธรรมดาเพื่อมอบความพึงพอใจอย่างเต็มที่ให้ผู้ใช้ที่มีอยู่
- Wufoo สร้างความเชื่อมั่นในช่วงแรกด้วยบริการที่น่าประทับใจถึงขั้น ส่งจดหมายขอบคุณเขียนด้วยลายมือ ให้กับผู้สมัครใหม่ทุกคน
- อย่ายึดติดกับสามัญสำนึกแบบงานบริการลูกค้าของบริษัทใหญ่ แต่จงเน้น ประสบการณ์แบบเฉพาะบุคคล ที่มีได้เฉพาะในช่วงเริ่มต้น
- หาก งานที่ต้องทำเพื่อให้ผู้ใช้กลุ่มแรกมีความสุข มีมากเสียจนแทบรับมือไม่ไหว นั่นกลับเป็นสัญญาณการเติบโตที่น่าพอใจ
- การที่ผู้ก่อตั้งในระยะแรกขาดประสบการณ์ด้านบริการลูกค้า เป็นหนึ่งในเหตุผลที่ทำให้ ยังใช้ข้อได้เปรียบของบริษัทเล็กได้ไม่เต็มที่
หมกมุ่นกับประสบการณ์ผู้ใช้ (Experience)
- เช่นเดียวกับคำว่า 'Insanely great' (ยอดเยี่ยมอย่างถึงที่สุด) ของ Steve Jobs ช่วงแรกจำเป็นต้องหมกมุ่นกับประสบการณ์ผู้ใช้
- สิ่งที่สำคัญกว่าผลิตภัณฑ์ที่เสร็จสมบูรณ์ในระยะแรก คือ การปรับปรุงผ่านปฏิสัมพันธ์กับผู้ใช้ แม้ผลิตภัณฑ์จะยังไม่สมบูรณ์ก็ตาม
- ฟีดแบ็ก ที่ได้จากการสื่อสารกับผู้ใช้โดยตรงส่งผลต่อการเติบโตมากที่สุด
เริ่มจากตลาดเล็กให้แคบที่สุด (Fire)
- เช่นเดียวกับ Facebook และ Airbnb ควรใช้กลยุทธ์ เริ่มต้นอย่างจงใจจากตลาดเล็กมาก (เช่น นักศึกษาฮาร์วาร์ด) แล้วสร้างมวลวิกฤตภายในกลุ่มนั้น
- ในช่วงแรก การหากลุ่ม early adopters ที่ตอบสนองเร็วที่สุดมีประสิทธิภาพมากกว่า
- โปรแกรม accelerator อย่าง YC ก็เอื้อต่อ การเข้าตลาดโดยมองสตาร์ทอัพอื่นเป็นลูกค้า เช่นกัน
กลยุทธ์เฉพาะของฮาร์ดแวร์สตาร์ทอัพ (Meraki)
- ฮาร์ดแวร์สตาร์ทอัพมีต้นทุนการผลิตจำนวนมากในช่วงแรกสูง ดังนั้น ผู้ก่อตั้งจึงประกอบสินค้าด้วยตัวเอง เหมือนอย่าง Meraki และ Pebble
- การลงมือทำเองทำให้เกิด การเรียนรู้จากประสบการณ์ ทั้งด้านการปรับแบบให้เหมาะสมและวิธีจัดหาชิ้นส่วน
เข้าหาผู้ใช้แบบสุดทางในสไตล์ที่ปรึกษา (Consult)
- ผลิตภัณฑ์ B2B ควร สร้างแบบเฉพาะให้ลูกค้ารายหนึ่งราวกับทำงานที่ปรึกษา แล้วจึงค่อยขยายไปยังตลาดข้างเคียง
- เบาะแสของการเติบโตมักเกิดจาก กระบวนการปรับให้ตรงกับปัญหาที่ลูกค้าต้องการจริงอย่างสมบูรณ์
- ในช่วงแรก อาจใช้วิธี ใช้งานซอฟต์แวร์แทนลูกค้าโดยตรง หรือเพิ่มฟังก์ชันที่ต้องการให้ทันทีได้เช่นกัน
กลยุทธ์ทำทุกอย่างด้วยมือทั้งหมด (Manual)
- เมื่อจำนวนผู้ใช้ยังน้อย ก็สามารถ จัดการงานต่าง ๆ ด้วยมือ แล้วค่อยเปลี่ยนเป็นระบบอัตโนมัติอย่างค่อยเป็นค่อยไปภายหลัง
- Stripe เคยจัดการเรื่อง "เปิดบัญชีได้ทันที" แบบแมนนวล ในช่วงแรก เพื่อส่งมอบประสบการณ์ที่ต้องการแก่ผู้ใช้
- อย่าหมกมุ่นกับการทำระบบอัตโนมัติตั้งแต่แรก แต่ควร ใช้การทำงานด้วยมือเพื่อเข้าใจปัญหาที่แท้จริงของผลิตภัณฑ์และลูกค้า ก่อน
ความไร้ประสิทธิภาพของ "การเปิดตัวครั้งใหญ่" (Big)
- กลยุทธ์เปิดตัวครั้งใหญ่ในคราวเดียว หรือฝากการเติบโตไว้กับ พาร์ตเนอร์ชิพกับบริษัทใหญ่ มักล้มเหลวโดยส่วนมาก
- ในระยะแรกควรโฟกัสที่การได้ผู้ใช้จำนวนน้อยก่อน และ ความพยายามอย่างเข้มข้นกับวิธีตรงไปตรงมา สำคัญกว่า
- ความสนใจจากผู้ใช้จะค่อย ๆ เติบโต ผ่าน การดูแลอย่างใกล้ชิดและการมอบความพึงพอใจโดยตรง
มองไอเดียสตาร์ทอัพแบบสองมิติ (Vector)
- สตาร์ทอัพที่ประสบความสำเร็จควรคิดในรูปเวกเตอร์ของ ผลิตภัณฑ์ (จะสร้างอะไร) + กลยุทธ์ที่ยังสเกลไม่ได้ (ช่วงแรกจะลงมือทำอะไรเอง)
- การลงมือโดยตรงในช่วงต้นแบบนี้จะ ทิ้งอิทธิพลเชิงบวกไว้ใน DNA ของผลิตภัณฑ์
- ความพยายามโดยตรงในระยะแรก เมื่อเวลาผ่านไปจะเปลี่ยนเป็นตัวผลิตภัณฑ์และวัฒนธรรมองค์กร และกลายเป็น แรงขับของการเติบโตอย่างต่อเนื่อง
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
มีประโยคหนึ่งจากพอดแคสต์ที่เพิ่งฟังมาซึ่งโดนใจผมมาก: ปัญหาใหญ่ที่สุดของสตาร์ทอัปคือแรงเฉื่อย โลกไม่ได้ชอบเราเป็นพิเศษ และก็ไม่ได้รู้สึกว่าจำเป็นต้องมีเรา... เราต้องพลิกสิ่งนั้นให้ได้ ต้องสร้างโมเมนตัมขึ้นมาตั้งแต่ศูนย์ และงานที่สำคัญจริง ๆ ของผู้ก่อตั้งคือการทำสิ่งที่กลับทิศแรงเฉื่อย นี่เป็นเรื่องที่เกิดขึ้นจริงในเชิงฟิสิกส์ด้วย โลกอยู่ในสภาวะหยุดนิ่ง และเราต้องสร้างโมเมนตัมขึ้นมาเองเหมือนการสตาร์ตเครื่องครั้งแรก ถ้ามองแบบนี้ การทำสิ่งที่ยังขยายไม่ได้ในช่วงแรกก็ไม่ใช่เรื่องแปลก เพราะตอนนั้นคุณยังไม่ได้อยู่ในช่วงปรับแต่งเครื่องจักรที่เดินอยู่แล้ว แต่กำลังอยู่ในช่วงหมุนชิ้นส่วนทีละอย่างให้เครื่องยนต์เริ่มทำงาน ประเด็นของ Paul Graham คือ การเติบโตที่ขยายได้หรือระบบอัตโนมัติเป็นปัญหาของลำดับถัดไป คุณต้องพบผู้ใช้ทีละคนด้วยวิธีแบบแมนนวลก่อน ถึงจะได้เรียนรู้จริง ๆ ว่าอะไรเวิร์ก กระบวนการนี้คือการสะสมหลักฐานว่าผู้ใช้มองว่าคุณเป็นสิ่งจำเป็น และพิสูจน์ว่าอะไรคุ้มค่าพอจะขยายต่อ
สำหรับผม คุณค่าที่แท้จริงของการทำด้วยมือคือการได้เรียนรู้ด้วยตัวเอง ลูกค้าคนหนึ่งของผมเคยคัดเลือกข่าวการเงินและหลักทรัพย์สำคัญประจำสัปดาห์ด้วยตัวเอง แล้วส่งเป็นลิสต์แบบ curated เป็นนิชย่อยซ้อนอยู่ในนิชเล็ก ๆ อีกที แต่ผู้ใช้ชอบมาก ทว่าเมื่อถึงจุดหนึ่ง เขาพยายามทำให้ทุกอย่างเป็นอัตโนมัติทั้งหมด เนื้อหาก็เริ่มเยอะขึ้นแบบไม่ผ่านการคัดสรร ข้อมูลสแปมก็เพิ่มขึ้น มูลค่าของมันหายไป และสุดท้ายตัวโปรดักต์ก็เดินไปในทางเดียวกัน แม้จะมีข่าวมากขึ้น แต่พอไม่มีการคัดเลือกและเรียบเรียงด้วยมือ สัดส่วนสัญญาณต่อสัญญาณรบกวนก็แย่ลง ของที่ทำด้วยมือแม้ขอบเขตจำกัด กลับมีคุณค่ามากกว่าอย่างชัดเจน หลายบริษัทไม่เข้าใจจุดนี้และหมกมุ่นกับการทำอัตโนมัติเร็วเกินไป อีกตัวอย่างหนึ่งคือมีลูกค้ารายหนึ่งที่เช็กราคาคู่แข่งด้วยมือ เขาต้องการระบบอัตโนมัติ ผมเลยทำ scraper แบบง่ายที่ใช้ Excel ให้ ตอนแรกเขาพอใจ แต่ภายหลังก็รู้ว่าตัวเองกำลังพลาดโอกาสเรียนรู้สิ่งต่าง ๆ อย่างสินค้าใหม่ เทรนด์ของแค็ตตาล็อก และเรื่องอื่น ๆ ที่ได้จากการไล่ดูเว็บไซต์คู่แข่งด้วยตัวเอง สุดท้ายเขากลับไปสำรวจด้วยมืออีกครั้ง และใช้ scraper แค่สำหรับวิเคราะห์ราคาอย่างเดียว แต่ลูกค้าคนอื่น ๆ ของผมส่วนใหญ่ยังคงสนใจแต่การทำอัตโนมัติ มากกว่าจะสนใจตัวโปรดักต์และแก่นของปัญหา จึงพลาดโอกาสเรียนรู้สำคัญอยู่เรื่อย ๆ
นั่นจึงเป็นเหตุผลที่คำว่า “สร้างสิ่งที่ผู้คนต้องการ” กลายเป็นคำคมคลาสสิกของวงการสตาร์ทอัป
ผมชอบคำว่า “กลับทิศแรงเฉื่อย” มาก แต่แนวทางนี้ไม่ได้ใช้ได้กับทุกสตาร์ทอัป ตามเฟรมเวิร์ก Arc ของ Sequoia มีอยู่สามแบบ: Hair on Fire (ความเจ็บปวดเร่งด่วนที่โมเมนตัมสำคัญมาก), Hard Fact (มีปัญหาอยู่แต่ต้องเปลี่ยนพฤติกรรมเดิม), และ Future Vision (ผู้คนยังไม่เชื่อว่าสิ่งนั้นเป็นไปได้ จึงต้องสร้างความน่าเชื่อถือก่อน) การลงมือทำสิ่งที่ขยายไม่ได้ด้วยตัวเองเพื่อให้เกิดผลลัพธ์เป็นเรื่องจำเป็นในหมวด Hair on Fire แต่ในอีกสองแบบนั้น อาจต้องจัดระเบียบความจริงใหม่หรือสร้างความน่าเชื่อถือก่อน
ทฤษฎีของผมแบ่งได้เป็นสามช่วง: Not Scaling (ก่อนขยาย), Scaling (ขยาย), และ Antiscaling (ช่วงที่คนเริ่มไม่ชอบ) Not Scaling คือช่วงสร้างคูเมือง (moat) ของตัวเองในตลาด Scaling คือช่วงที่โปรดักต์ได้รับความนิยมพอจนลูกค้าเดิมดึงลูกค้าใหม่เข้ามา และคุณแค่ต้องรับมือกับดีมานด์ที่เพิ่มขึ้น เช่น แยกเซิร์ฟเวอร์หรือ shard ฐานข้อมูล ส่วน Antiscaling คือช่วงที่บริษัทเริ่มกลายเป็นปัญหาแบบที่เห็นในเว็บยุคใหม่ หน่วยข่าวกรองติดต่อมาเรื่องการใช้งานโดยผู้ก่อการร้าย และเทศบาลหรือรัฐบาลเริ่มออกใบอนุญาตหรือกฎหมายกำกับเพื่อเจาะจงคุณ ผู้ก่อตั้งดังจนกลายเป็นมีมและถูกติดตามตำแหน่งได้ คุณไม่จำเป็นต้องครองโลก แค่ทำเงินให้ได้ก็พอ คนที่บอกว่าจะเปลี่ยนโลกมักลงเอยด้วยผลลัพธ์ที่ไม่ได้ดีนัก ดังนั้นสิ่งสำคัญคือสร้างอะไรบางอย่างที่ใช้การได้
คำว่า "แค่ทำเงินให้ได้ก็พอ" ทำให้ผมนึกถึง Goodhart’s Law ที่บอกว่า เมื่อ metric ใด metric หนึ่ง (เช่น รายได้) กลายเป็นเป้าหมาย มันก็จะไม่ใช่เครื่องมือวัดที่ดีอีกต่อไป
ผมรู้สึกว่ามุมมองนี้มีอคติมากเกินไป มันไม่ได้พูดถึงความเฉยเมยสุดขั้วเวลาคุณสร้างสิ่งที่ไม่มีใครต้องการ และในความเป็นจริง สิ่งที่พบได้บ่อยกว่าคือความสำเร็จระดับกลาง ๆ แบบธรรมดา ๆ ไม่มีใครเกลียด แต่ก็ไม่มีใครรักแบบสุดตัว ทุกอย่างดูบวกนิดหน่อย แต่ไม่มีทั้งกระแส hype และความได้เปรียบเชิงผูกขาด จนไม่มีใครสนใจเป็นพิเศษ แบบนี้ต่างหากที่พบบ่อยที่สุด
ผมทิ้งลิงก์ข้างล่างไว้เพราะอยากรวบรวมกรณีตัวอย่างที่เกี่ยวข้องเพิ่มเติม
Ask HN: PG's 'Do Things That Don't Scale' manual examples? - Oct 2023 (316 ความคิดเห็น)
Do Things that Don't Scale (2013) - Feb 2021 (31 ความคิดเห็น)
PG: “Do Things that Don't Scale” – What are some examples? - Jan 2021 (2 ความคิดเห็น)
Ask HN: How did you 'do things that don't scale' for your B2B startup? - Sept 2017 (9 ความคิดเห็น)
Do Things That Don’t Scale (2013) - Aug 2017 (37 ความคิดเห็น)
Do Things that Don't Scale - July 2013 (207 ความคิดเห็น)
Show HN: A directory of startups that did things that don't scale - Sept 2024 (12 ความคิดเห็น), Ask HN: What are some hacks of real founders who did things that don't scale? - Nov 2018 (267 ความคิดเห็น), Why we're doing things that don't scale - July 2013 (34 ความคิดเห็น)
Scalability is overrated - Feb 2023 (232 ความคิดเห็น)
อยากแชร์เนื้อหานี้ให้ผู้ก่อตั้งระยะเริ่มต้นทุกคน รวมถึงพนักงานที่เข้าร่วมในช่วงต้นด้วย ตอนนี้เราโตเกิน 15 คนแล้ว แต่เรายังคงโทรหาผู้สมัครใหม่ทุกคนอยู่เสมอ เหตุผลคือ 1) อยากรู้ว่าพวกเขารู้จักเราจากไหน 2) อยากรู้ว่าพวกเขาต้องการความช่วยเหลือในการเริ่มใช้งานหรือไม่ 3) และในเชิงนัยคืออยากสื่อว่าทีมของเราใส่ใจด้วยตัวเอง ดูเหมือนว่าจะเวิร์กเป็นพิเศษเพราะบริการของเราเป็นแพลตฟอร์ม B2B และแม้กลุ่มเป้าหมายจะเป็นนักพัฒนา แต่พอลองโทรจริง ๆ หลังจากผ่านช่วงแรกที่ต้องบอกว่า “ไม่ใช่ครับ เราไม่ได้จะโทรมาขายของ” ไปแล้ว ก็มักจะได้บทสนทนาที่ตรงไปตรงมาและดีมาก
มีหลายเสียงที่วิจารณ์ Paul Graham แต่ตัวบทความนี้สรุปได้ว่าอย่าทำ premature optimization หรืออย่ารีบ optimize เร็วเกินไป กล่าวคืออย่าทำตัวเหมือนบริษัทใหญ่ หากผู้ก่อตั้งลงมือทำงานจริงด้วยตัวเอง แม้จะไม่มีประสิทธิภาพ แต่ก็จะได้ประสบการณ์ภาคสนามและ feedback สะสมไว้ อีกทั้งการไม่รีบนำโซลูชันที่ขยายได้เข้ามาเร็วเกินไป ยังทำให้รับ feedback ได้ไวขึ้นด้วย และยังมีประโยชน์ในการสร้างความแตกต่างของตัวเอง ผมคิดว่าควรจดจำคำว่า “จงทำสิ่งที่ขยายไม่ได้” แบบตรงตัวไว้เลย
หลายครั้งคนสร้างระบบที่ขยายได้เกินความจำเป็นตั้งแต่ช่วงที่ยังไม่จำเป็นจริง เพียงเพราะกังวลว่าบริการจะรับมือกับความนิยมเกินคาดหรือดีมานด์มหาศาลไม่ได้ แต่ผมรู้สึกว่าการขยายแนวตั้งกลับถูกประเมินค่าต่ำเกินไป แค่เติมทรัพยากรให้ monolithic backend เดิม คุณก็ยังพอมีเวลาทำความเข้าใจบริการของตัวเองได้ ที่สำคัญกว่านั้น มันทำให้คุณกลับมาคิดว่า “คุณค่าหลัก” ที่ผู้ใช้ชอบในโปรดักต์ของเราจริง ๆ คืออะไร อีกทั้งหากผู้ใช้รักโปรดักต์ของเราจริง ช่วงแรกพวกเขาก็พร้อมจะยอมรับประสิทธิภาพที่ยังไม่สมบูรณ์บ้างได้ สมัยแรกของ Twitter มี “fail whale” โผล่บ่อยมาก แต่ก็ยังเติบโตแบบระเบิด เพราะฟีเจอร์ที่คนต้องการมันทำงานได้จริง ในช่วงแรก สิ่งสำคัญทั้งหมดคือ feedback ที่เร็ว การทำซ้ำอย่างรวดเร็ว และความพึงพอใจของลูกค้า การทดลอง การสื่อสารกับผู้ใช้ และการสังเกต ต้องมาก่อนการขยาย และเมื่อถึงจุดที่ใช่จริง ๆ ค่อยกังวลเรื่องการขยาย ซึ่งจุดนั้นคาดเดาไม่ได้ เทคโนโลยีเป็นเพียงเครื่องมือเท่านั้น ต่อให้คุณมีไวโอลินชั้นยอด สิ่งสำคัญก่อนอื่นคือคุณต้องสร้าง “ดนตรีที่ดี” ให้ได้
ต้องจำไว้ว่าไม่ใช่ทุกธุรกิจที่ประสบความสำเร็จจะมีผู้ใช้เป็นหลักล้านหรือหลักพันล้าน ผมทำงานสร้าง internal tools ซึ่งสเกลของสภาพแวดล้อมเราถูกกำหนดไว้แล้ว ไม่ได้ไวต่อ performance มาก และไม่มีทราฟฟิกพุ่งไม่สม่ำเสมอ แต่มีคนในทีมคนหนึ่งหมกมุ่นกับการรื้อทั้งโค้ดเบสไปใช้ภาษาที่มีแต่เขาคนเดียวที่รู้จัก เพียงเพื่อรีดเวลาออกไม่กี่มิลลิวินาที ไม่มีใครสนใจ และสิ่งที่เขาสร้างไว้ก็เหลือไว้แค่ความเสี่ยงด้านการบำรุงรักษา พอเขาลาออก ผู้จัดการก็ตัดสินใจทิ้งทั้งหมด ถ้าเป็นดีไซน์ที่ง่ายกว่าและช้ากว่านี้ คนอื่นคงรับช่วงต่อได้ง่ายกว่ามาก
“premature optimization” กับ “Do Things That Don’t Scale” มีความต่างกันแบบละเอียดอ่อน อย่างแรกตั้งสมมติฐานว่าเวอร์ชันที่ขยายได้คือเวอร์ชันที่ ‘ดีที่สุด’ ส่วนอย่างหลังชี้ว่าบางทีวิธีที่ขยายไม่ได้อาจดีที่สุดอยู่แล้ว เช่น การให้ CEO ดูแลการติดต่อโดยตรงอาจดีกว่า shared inbox ที่ใช้จัดการทุกอย่าง วิธีที่ขยายได้ (เช่น ฟอร์มติดต่อ) ไม่ได้ถูก optimize ตั้งแต่แรก แต่จริง ๆ คือคุณภาพของกระบวนการที่ลดลง การทำ scaling ไม่ใช่ความชั่วร้ายในตัวมันเอง แต่ความซับซ้อนและระยะห่างจากลูกค้ามักตามมาด้วยอย่างหลีกเลี่ยงไม่ได้ เราต้องตระหนักว่ากระบวนการอาจแย่ลงได้ตามบริบท สำหรับผม ข้อความนี้ใกล้เคียงกับ “อย่าทำให้กระบวนการเสื่อมคุณภาพเร็วเกินไป” มากกว่า
สุดท้ายแล้วมันสรุปได้ว่า "อย่าพยายามแก้ปัญหาที่ยังไม่มีตั้งแต่เนิ่น ๆ"
คำแนะนำว่า “อย่าทำตัวเหมือนบริษัทใหญ่” พูดตรง ๆ คือใช้ได้กับทุกองค์กรไม่ว่าขนาดไหน ในฐานะคอนซัลแทนต์ ผมใช้เวลาไม่น้อยในการห้ามสตาร์ทอัปหรือ SME ไม่ให้พยายามนำกฎและนโยบายขององค์กรใหญ่เข้ามาใช้ เพียงเพราะตนเองเป็นนิติบุคคล นโยบายเหล่านั้นจำเป็นก็ต่อเมื่อมีคนระดับหลายร้อยคน แต่ในองค์กรเล็กกลับถ่วงความคล่องตัว ตัวอย่างเช่น k8s, nosql, หรือนโยบายความปลอดภัยที่เข้มงวดเกินความจำเป็น คู่มือวัฒนธรรมองค์กรของ Netflix ก็แสดงให้เห็นเรื่องนี้ได้ดี ถ้าเป็นองค์กรเล็ก และคุณเชื่อว่าจ้างคนมาดีแล้ว ก็ควรให้อำนาจจริง ให้แต่ละคนตัดสินใจได้เอง จนกว่าปัญหาหรือความเสี่ยงจะใหญ่ขึ้นจริง ๆ ก็ไม่จำเป็นต้องเอาทุกอย่างไปขังไว้ในกฎระเบียบ
Stripe เป็นหนึ่งในบริษัทที่ประสบความสำเร็จที่สุดในพอร์ตของ YC และปัญหาที่ Stripe แก้ก็เป็นปัญหาที่เร่งด่วนและสำคัญมาก ในสถานการณ์ที่ไม่มีใครน่าจะออกไปรอผู้ใช้ Stripe กลับมีชื่อเสียงเรื่องการหาผู้ใช้เชิงรุกอย่างมาก ตอนนั้นคือเมื่อ 12 ปีก่อน และผมไม่คิดเลยว่ามันจะเติบโตได้ใหญ่ขนาดนี้ ถ้าตอนนั้นได้ลงทุนก็คงดีมาก
แน่นอนว่ามี survivor bias อยู่จริง แต่ผมเห็นด้วยอย่างเต็มที่กับประเด็นที่ว่าช่วงเวลาที่ต้องลงมือทำเองโดยยังไม่ทำอัตโนมัตินั้นสำคัญมาก เพราะมันช่วยให้คุณจดจำภาพรวมของกระบวนการหรือระบบได้ละเอียดกว่ามาก ซึ่งสไลด์หรือเอกสารธรรมดาให้ไม่ได้ และถ้าพูดในภาษาปัจจุบัน มันคือช่วงเวลาของการสร้าง ‘taste’ คุณจะเริ่มรู้ด้วยตัวเองว่าอะไรคือของดี และเพราะอะไร ทำให้คุณมีมุมมองที่ชัดขึ้นในจุดตัดสินใจที่คนอื่นอาจไม่เคยนึกถึง ทุกวันนี้เพราะมี AI หลายที่จึงพยายามข้ามไปสู่การทำอัตโนมัติเร็วเกินไป แต่ที่ www.socratify.com เราก็ยังสร้างคอนเทนต์แบบทำมืออยู่ ทุกคนบอกว่าควรสร้างด้วย AI ทั้งหมด แต่เป้าหมายหลักของเราคือการคัดเลือกบริบทและคุณภาพให้เหมาะสม กระบวนการตรวจสอบบางส่วนอาจทำอัตโนมัติได้ในภายหลัง แต่จากประสบการณ์อ้อม ๆ ที่พบมาอย่างมาก เราคิดว่ายังยากที่จะแทนที่สมองและวิจารณญาณของมนุษย์ได้ทั้งหมด
YC เปลี่ยนเกมไปเลยด้วยการทำให้ seed funding เข้าถึงง่ายขึ้นมาก ผมมั่นใจว่า Paul Graham, Jessica Livingston และทีม YC มองเห็นปัญหาของระบบเดิมอย่างชัดเจนและแก้มันได้จริง ก่อนจะมี YC การระดมทุนรอบ seed แทบเป็นไปไม่ได้เลย มันไม่เท่าเทียม และให้ความรู้สึกเหมือนต้องไปพรีเซนต์ต่อหน้าพาร์ตเนอร์อารมณ์เสีย 8 คนในสำนักงานธนาคารเก่า ๆ ถ้าจะให้เครดิต ก็ต้องให้เครดิตพวกเขา เพราะคนที่แก้ตลาดนี้คือพวกเขา
ผมหวังว่าบริษัทใหญ่อย่าง OpenAI จะอ่าน “Do Things That Don’t Scale” อย่างจริงจังและนำไปใช้บ้าง ด้วยเงินทุนระดับนั้น พวกเขาน่าจะจ่ายค่าลิขสิทธิ์ข้อมูลที่จำเป็นอย่างถูกต้องได้ แต่พวกเขากลับเลือกแต่วิธีที่ขยายได้ (scraping, stealing) และดูเหมือนหวังว่าต่อให้หยิบไปใช้เยอะ ๆ คนก็จะไม่รู้ หรือกว่าจะมีคนทักท้วงก็คงช้าไปแล้ว เท่ากับหวังให้สถานการณ์ที่ผู้สร้างคอนเทนต์ในปัจจุบันไม่ได้รับค่าตอบแทนแม้แต่บาทเดียว ทั้งที่ผลงานของพวกเขาถูกใช้เป็นข้อมูลฝึก AI โดยไม่รู้ตัว ผ่านไปเฉย ๆ
บทความนี้เป็นโพสต์แรกที่ผมเคยเห็นบน Hacker News ทุกครั้งที่มันถูกขุดขึ้นมาใหม่เป็นครั้งคราว ก็ทำให้ความทรงจำเก่า ๆ กลับมามีชีวิตอีกครั้ง