Hãy làm những việc không thể mở rộng quy mô (2013)

 (paulgraham.com)
3 điểm bởi GN⁺ 2025-08-17 | 1 bình luận | Chia sẻ qua WhatsApp
  • Y Combinator khuyên rằng ở giai đoạn đầu khởi nghiệp, cần tích cực làm "những việc không thể mở rộng quy mô"
  • Các startup thành công như Stripe, Airbnb đã chọn cách tiếp cận trực tiếp và quyết liệt trong việc thu hút người dùng đầu tiên
  • Hầu hết startup rất mong manh ở giai đoạn đầu, và sự lăn xả trực tiếp của nhà sáng lập là yếu tố cốt lõi cho tăng trưởng
  • Việc mang lại cho người dùng đầu tiên trải nghiệm xuất sắc và sự hài lòng cao là điều quan trọng đối với tăng trưởng dài hạn
  • Ở giai đoạn khởi đầu, làm thủ công thay vì tự động hóa, tấn công thị trường ngách, tư vấn trực tiếp là những cách hiệu quả

Mở đầu: Thực tế của tăng trưởng startup

  • Nhiều nhà sáng lập tương lai nghĩ rằng startup sẽ tự tăng trưởng, nhưng trên thực tế nhà sáng lập phải trực tiếp nhóm lên tia lửa tăng trưởng
  • Giống như tay quay khởi động của ô tô ngày xưa, ở giai đoạn đầu quy trình thâm dụng lao động là điều không thể thiếu

Tự mình thu hút người dùng (Recruit)

  • Phần lớn startup không nên thụ động chờ người dùng tự tìm đến, mà cần chủ động đi tìm họ
  • Trường hợp của Stripe cũng vậy: thời kỳ đầu họ dùng một chiến lược thu hút người dùng rất quyết liệt gọi là 'Collison installation', tức là trực tiếp cầm lấy laptop của đối phương để cài bản beta sau khi giới thiệu sản phẩm
  • Lý do các nhà sáng lập ngại làm những việc này là vì sợ bị từ chối, thấy xấu hổ, và đánh giá thấp số lượng người dùng ít ỏi ban đầu
  • Thực tế, nhờ hiệu ứng tăng trưởng lãi kép, chỉ cần duy trì mức tăng 10% mỗi tuần thì sau 2 năm cũng có thể đạt tới hàng triệu người dùng
  • Airbnb cũng chủ động đến tận nơi tìm các host ở New York và giúp họ đăng ký

Sự mong manh của startup giai đoạn đầu (Fragile)

  • Gần như mọi startup đều rất bất ổn ở giai đoạn đầu, và thành bại được quyết định bởi những nỗ lực trực tiếp trong thời gian ngắn
  • So với sự thờ ơ của giới phê bình hay nhà đầu tư bên ngoài, việc chính bản thân nhà sáng lập tự đánh giá thấp giá trị doanh nghiệp của mình còn nguy hiểm hơn
  • Ở giai đoạn đầu, thay vì hỏi 'Công ty này có thay đổi thế giới không?', bạn nên tự hỏi 'Nếu mình làm đúng những nỗ lực cần thiết, nó có thể lớn đến đâu?'
  • Ví dụ, Microsoft và Airbnb trong giai đoạn sáng lập ban đầu thoạt nhìn đều rất nhỏ bé, nhưng đó vẫn là con đường tốt nhất
  • Người dùng phù hợp nên bắt đầu từ những người giống với chính bạn, hoặc cần xác định nhóm nhiệt thành nhất trong số người dùng đầu tiên rồi tập trung tấn công nhóm đó

Tối đa hóa niềm vui của người dùng (Delight)

  • Không chỉ thu hút người dùng, còn cần những nỗ lực phi thường để mang lại sự hài lòng đặc biệt cho người dùng hiện tại
  • Wufoo đã xây dựng niềm tin ban đầu bằng dịch vụ ấn tượng đến mức gửi thư cảm ơn viết tay cho từng người mới đăng ký
  • Đừng bị trói buộc bởi lối nghĩ thông thường của dịch vụ khách hàng ở các công ty lớn; hãy nhấn mạnh trải nghiệm cá nhân hóa mà chỉ startup giai đoạn đầu mới có thể cung cấp
  • Nếu khối lượng công việc để làm người dùng đầu tiên hài lòng trở nên quá nhiều đến mức khó gánh nổi, thì đó ngược lại còn là một tín hiệu tăng trưởng đáng mừng
  • Việc nhà sáng lập giai đoạn đầu thiếu kinh nghiệm chăm sóc khách hàng là một trong những lý do khiến họ không tận dụng hết lợi thế cạnh tranh của công ty nhỏ

Sự ám ảnh với trải nghiệm người dùng (Experience)

  • Giống như cách Steve Jobs gọi là 'Insanely great' (xuất sắc đến mức ám ảnh), ở giai đoạn đầu cần có sự ám ảnh với trải nghiệm người dùng
  • Quan trọng hơn một sản phẩm hoàn thiện ngay từ đầu là cải tiến thông qua tương tác với người dùng, dù sản phẩm còn chưa hoàn hảo
  • Phản hồi có được từ việc giao tiếp trực tiếp với người dùng là yếu tố ảnh hưởng lớn nhất đến tăng trưởng

Bắt đầu bằng một thị trường hẹp (Fire)

  • Giống như Facebook và Airbnb, hãy dùng chiến lược cố ý bắt đầu từ một thị trường cực nhỏ (ví dụ: sinh viên Harvard) để đạt khối lượng tới hạn trong chính nhóm đó
  • Ở giai đoạn đầu, việc tìm ra nhóm early adopter phản hồi nhanh nhất sẽ hiệu quả hơn
  • Những chương trình tăng tốc như YC cũng có lợi cho cách tiếp cận thị trường lấy các startup khác làm khách hàng

Chiến lược đặc thù cho startup phần cứng (Meraki)

  • Startup phần cứng có chi phí sản xuất hàng loạt ban đầu cao, nên như Meraki và Pebble, các nhà sáng lập thường tự tay lắp ráp sản phẩm
  • Trong quá trình tự làm, sẽ diễn ra học hỏi từ thực tế như tối ưu thiết kế hay cách thu mua linh kiện

Tiếp cận người dùng cực đoan theo kiểu tư vấn (Consult)

  • Với sản phẩm B2B, có thể tùy biến như đang làm tư vấn cho đúng một khách hàng cụ thể, rồi sau đó mở rộng sang thị trường lân cận
  • Manh mối tăng trưởng xuất hiện trong quá trình điều chỉnh hoàn toàn khớp với vấn đề mà khách hàng thực sự cần giải quyết
  • Ở giai đoạn đầu, cũng có thể trực tiếp dùng phần mềm thay cho khách hàng, hoặc phản ánh ngay những tính năng họ cần

Chiến lược làm hoàn toàn thủ công (Manual)

  • Khi số lượng người dùng còn ít, có thể xử lý công việc bằng tay, rồi dần dần chuyển sang tự động hóa về sau
  • Stripe thời kỳ đầu đã xử lý việc 'mở tài khoản ngay lập tức' bằng thủ công để mang lại trải nghiệm người dùng như mong muốn
  • Đừng ám ảnh với tự động hóa ngay từ đầu; ưu tiên trước hết là hiểu sản phẩm và vấn đề thực tế của khách hàng thông qua làm thủ công

Sự kém hiệu quả của 'ra mắt rầm rộ' (Big)

  • Chiến lược ra mắt hoành tráng một lần, hoặc giao tăng trưởng cho quan hệ đối tác với doanh nghiệp lớn, nhìn chung đều thất bại
  • Ở giai đoạn đầu cần tập trung vào việc giành được một số ít người dùng, và nỗ lực mãnh liệt cùng phương pháp trực tiếp mới quan trọng hơn
  • Sự quan tâm của người dùng tăng lên chậm rãi, thông qua quản lý trực tiếp và mang lại sự hài lòng

Cách tiếp cận hai chiều với ý tưởng startup (Vector)

  • Startup thành công cần được nhìn như một vector gồm sản phẩm (sẽ làm gì) + chiến lược phi quy mô hóa (ban đầu sẽ trực tiếp làm gì)
  • Những hành động trực tiếp ở giai đoạn đầu như vậy sẽ để lại ảnh hưởng tích cực lên DNA của sản phẩm
  • Nỗ lực trực tiếp ban đầu theo thời gian sẽ chuyển hóa thành sản phẩm và văn hóa tổ chức, trở thành động lực cho tăng trưởng bền vững

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-17
Ý kiến trên Hacker News

  • Gần đây tôi nghe một podcast có một ý rất đồng cảm: vấn đề lớn nhất của startup là quán tính. Thế giới không đặc biệt thích chúng ta, cũng không cảm thấy cần chúng ta... chúng ta phải đảo ngược điều đó. Phải tự tạo đà hoàn toàn từ con số 0, và việc thực sự quan trọng mà nhà sáng lập phải làm là hành động để đảo chiều quán tính. Điều này cũng đúng theo nghĩa vật lý. Thế giới đang đứng yên, còn chúng ta phải trực tiếp tạo ra động lượng như khi khởi động máy lần đầu. Nhìn từ góc độ đó, việc ban đầu làm những thứ không thể mở rộng cũng không có gì lạ. Đây chưa phải giai đoạn tối ưu một cỗ máy đang chạy, mà là giai đoạn phải tự tay xoay từng chút để động cơ bắt đầu chạy đúng cách. Ý của Paul Graham là tăng trưởng có thể mở rộng hay tự động hóa là vấn đề của bước sau. Chỉ khi tiếp cận thủ công, gặp từng người dùng một, bạn mới thực sự học được điều gì hiệu quả. Đó là quá trình tích lũy bằng chứng rằng người dùng xem mình là thứ họ cần, đồng thời chứng minh điều gì đáng để mở rộng

    • Theo tôi, giá trị thực sự của việc làm thủ công là bạn học được trực tiếp. Một khách hàng của tôi từng tự tay chọn lọc tin tài chính và chứng khoán quan trọng hàng tuần rồi cung cấp thành danh sách được tuyển chọn. Đó là một ngách nhỏ trong một ngách nhỏ hơn nữa, nhưng người dùng thực sự rất thích. Rồi đến lúc họ cố tự động hóa tất cả, nội dung trở nên quá nhiều, thiếu chọn lọc, thông tin kiểu spam cũng tăng lên, giá trị biến mất và cuối cùng sản phẩm cũng đi theo hướng đó. Có nhiều tin hơn, nhưng vì không còn tự tay chọn và biên tập nên tỷ lệ tín hiệu trên nhiễu tệ hơn. Trên thực tế, làm thủ công tuy phạm vi hạn chế nhưng giá trị cao hơn nhiều. Nhiều công ty không hiểu điều đó và quá ám ảnh với tự động hóa quá sớm. Một ví dụ khác là có khách hàng kiểm tra giá của đối thủ bằng tay. Họ muốn tự động hóa nên tôi làm một scraper đơn giản dựa trên Excel. Ban đầu họ hài lòng, nhưng sau đó mới nhận ra rằng khi không còn tự mình đi qua website đối thủ, họ đã bỏ lỡ cơ hội học về sản phẩm mới, xu hướng catalog và những thứ tương tự. Cuối cùng họ quay lại khám phá thủ công, còn scraper chỉ dùng cho phân tích giá đơn giản. Nhưng đa số khách hàng khác của tôi vẫn chỉ quan tâm đến tự động hóa hơn là bản chất của sản phẩm và vấn đề, nên cứ tiếp tục bỏ lỡ những cơ hội học tập quan trọng

    • Đó là lý do câu “hãy làm thứ mọi người muốn” trở thành châm ngôn của giới startup

    • Tôi rất thích cách diễn đạt “đảo ngược quán tính”, nhưng cách tiếp cận này không áp dụng cho mọi startup. Theo framework Arc của Sequoia thì có ba kiểu: Hair on Fire (nỗi đau cấp bách, động lượng là quan trọng), Hard Fact (có nỗi đau nhưng phải thay đổi thói quen), Future Vision (người ta còn chưa tin việc đó là khả thi nên phải xây dựng niềm tin trước). Tự mình làm những việc không thể mở rộng để tạo kết quả là điều bắt buộc trong nhóm Hair on Fire, nhưng với các nhóm còn lại thì phải tái cấu trúc chính thực tại hoặc xây dựng uy tín trước

  • Lý thuyết của tôi có thể chia thành ba giai đoạn: Not Scaling (trước khi mở rộng), Scaling (mở rộng), và Antiscaling (giai đoạn bị ghét). Not Scaling là giai đoạn xây dựng hào lũy riêng (moat) trên thị trường. Scaling là lúc sản phẩm đủ nổi để khách hàng kéo thêm khách hàng mới, và bạn chỉ cần xử lý nhu cầu tăng lên bằng cách tách server hay DB. Antiscaling là khi bạn trở thành kiểu công ty đại diện cho vấn đề của web hiện đại. Cơ quan tình báo gọi đến vì chuyện bị khủng bố lợi dụng, thành phố hay chính phủ trực tiếp làm giấy phép hoặc luật quản lý để nhắm vào bạn. Nhà sáng lập trở nên nổi tiếng đến mức bị làm meme và còn bị theo dõi vị trí. Không cần thống trị thế giới, chỉ cần kiếm tiền là được. Những người nói rằng họ sẽ thay đổi thế giới hiếm khi thực sự tạo ra kết quả tốt, nên điều quan trọng là cứ làm ra thứ gì đó hữu ích

    • Câu “chỉ cần kiếm tiền là được” khiến tôi nhớ đến Goodhart’s Law: khi một chỉ số nào đó (ví dụ doanh thu) trở thành mục tiêu, thì nó không còn là thước đo tốt nữa

    • Tôi cảm thấy góc nhìn này quá thiên lệch. Nó không nói đến sự thờ ơ cực độ khi bạn làm ra thứ không ai muốn. Và thực ra trường hợp phổ biến hơn là thành công ở mức rất bình thường. Không ai ghét, nhưng cũng chẳng ai yêu điên cuồng. Hơi tích cực một chút, nhưng không có hype hay lợi thế cạnh tranh mang tính độc quyền nên chẳng ai thực sự quan tâm, đó mới là trường hợp thường gặp nhất

  • Tôi để lại các link dưới đây vì muốn gom thêm những ví dụ liên quan

  • Tôi muốn chia sẻ điều này như một nội dung muốn giới thiệu cho mọi nhà sáng lập giai đoạn đầu và cả những nhân viên gia nhập ở giai đoạn sớm. Dù chúng tôi đã có hơn 15 người, mỗi khi có người đăng ký mới chúng tôi vẫn gọi điện trực tiếp. Lý do là 1) để hỏi họ biết đến chúng tôi bằng cách nào 2) xem họ có cần hỗ trợ trong lần dùng đầu tiên không 3) và (ngầm) truyền đạt rằng chính đội ngũ của chúng tôi đang trực tiếp quan tâm đến họ. Dịch vụ của chúng tôi là nền tảng B2B nên có vẻ cách này càng hiệu quả hơn, và dù đối tượng là developer, khi thực sự gọi điện thì chỉ cần qua được đoạn “không, đây không phải cuộc gọi bán hàng đâu” là sẽ nhận được rất nhiều chia sẻ chân thành và hữu ích

  • Có nhiều tiếng nói chỉ trích Paul Graham, nhưng bản thân bài này có thể tóm gọn là đừng tối ưu hóa quá sớm. Tức là đừng hành xử như một công ty lớn. Nếu nhà sáng lập tự mình làm việc vận hành, dù kém hiệu quả thì vẫn tích lũy được kinh nghiệm thực chiến và phản hồi; đồng thời, vì không vội áp dụng giải pháp có thể mở rộng ngay từ đầu nên cũng có thể nhận phản hồi sớm hơn. Và nó cũng hiệu quả trong việc tạo ra sự khác biệt riêng. Tôi nghĩ nên khắc sâu câu “hãy làm những việc không thể mở rộng” theo đúng nghĩa đen

    • Nhiều người xây dựng những hệ thống quá mức có thể mở rộng từ giai đoạn hoàn toàn chưa cần thiết, chỉ vì sợ dịch vụ sẽ sụp đổ nếu nổi tiếng hoặc có nhu cầu quá cao. Nhưng tôi thấy vertical scaling (cách chỉ thêm tài nguyên) đang bị đánh giá thấp quá mức. Chỉ cần bơm thêm tài nguyên vào monolithic backend hiện có cũng có thể mua thêm thời gian để hiểu đúng dịch vụ của mình. Quan trọng hơn, nó buộc bạn suy nghĩ lại “giá trị cốt lõi” mà người dùng thực sự thích ở sản phẩm. Và nếu người dùng thật sự yêu sản phẩm của bạn, họ sẽ chấp nhận việc hiệu năng ban đầu hơi kém. Hồi đầu Twitter thường xuyên hiện “fail whale”, nhưng vẫn tăng trưởng bùng nổ vì chức năng người ta muốn vẫn hoạt động đúng. Ở giai đoạn đầu, tất cả là phản hồi nhanh, lặp lại nhanh và làm khách hàng hài lòng. Trước tiên phải thử nghiệm, giao tiếp với người dùng và quan sát, chứ không phải mở rộng. Đến khi trực giác mách bảo thì lúc đó mới nghĩ đến chuyện scale, và thời điểm đó không thể dự đoán trước. Công nghệ chỉ là công cụ; dù có một cây violin hảo hạng thì trước hết vẫn phải tạo ra “âm nhạc hay”

    • Cũng cần nhớ rằng không phải mọi doanh nghiệp thành công đều nhắm tới hàng triệu hay hàng tỷ người dùng. Tôi làm việc xây dựng công cụ nội bộ, quy mô môi trường của chúng tôi đã cố định, không quá nhạy với hiệu năng và cũng không có lưu lượng thất thường. Thế mà từng có một người trong đội ám ảnh với việc viết lại toàn bộ code bằng một ngôn ngữ chỉ mình anh ta biết chỉ để giảm vài mili giây. Chẳng ai quan tâm, và thứ anh ta xây chỉ để lại rủi ro bảo trì. Khi anh ta nghỉ việc, quản lý quyết định bỏ sạch; nếu thiết kế đơn giản hơn và chậm hơn thì người khác đã dễ tiếp quản hơn nhiều

    • “Tối ưu hóa quá sớm” và “Do Things That Don’t Scale” khác nhau một cách tinh tế. Cái trước giả định phiên bản có thể scale là “tối ưu”, còn cái sau gợi ý rằng cách không thể scale đôi khi lại là tốt nhất. Ví dụ, CEO tự mình quản lý liên hệ có thể tốt hơn nhiều so với shared inbox xử lý mọi thứ. Cách có thể scale hơn (form liên hệ) không phải là tối ưu ngay từ đầu, mà trên thực tế là làm giảm chất lượng quy trình. Việc scale tự nó không phải cái ác, nhưng nó kéo theo sự phức tạp và khoảng cách với khách hàng gần như không thể tránh khỏi. Cần nhận thức rằng tùy tình huống, quy trình có thể trở nên tệ hơn. Theo tôi, thông điệp này gần với “tránh làm quy trình xuống cấp quá sớm” hơn

    • Cuối cùng có thể tóm lại là “đừng cố giải những vấn đề chưa tồn tại”

    • Lời khuyên “đừng hành xử như công ty lớn” thật ra áp dụng cho tổ chức ở mọi quy mô. Với vai trò consultant, tôi dành rất nhiều thời gian để ngăn các startup hay doanh nghiệp nhỏ áp dụng các quy tắc và chính sách của tổ chức cồng kềnh chỉ vì họ là pháp nhân. Những chính sách đó chỉ cần thiết ở quy mô hàng trăm người, còn với tổ chức nhỏ thì lại chỉ cản trở. Ví dụ như k8s, nosql, hay các chính sách bảo mật quá nghiêm ngặt hơn mức cần thiết. Bộ hướng dẫn văn hóa nội bộ của Netflix cũng cho thấy điều này rất rõ. Với tổ chức nhỏ, nếu giả định là bạn đã tuyển đúng người, thì nên trao quyền thực sự để mỗi thành viên tự phán đoán. Không cần nhốt mọi thứ vào quy định cho đến khi vấn đề hay rủi ro thực sự lớn lên

  • Stripe là một trong những công ty thành công nhất trong danh mục YC, và vấn đề Stripe giải quyết là một vấn đề thực sự cấp bách. Trong khi đáng lẽ nhiều người sẽ chọn cách ngồi chờ người dùng tìm đến, Stripe lại nổi tiếng vì tiếp cận người dùng rất quyết liệt. Chuyện đó là 12 năm trước, và khi ấy không ai ngờ họ sẽ tăng trưởng lớn đến vậy. Giá mà lúc đó có thể đầu tư thì tốt biết mấy

  • Tất nhiên đúng là có survivor bias. Nhưng tôi hoàn toàn đồng ý với điểm rằng giai đoạn tự mình làm việc, chưa tự động hóa, là rất quan trọng. Làm vậy mới thật sự khắc sâu toàn bộ quy trình hay hệ thống trong đầu, điều mà chỉ slide hay tài liệu đơn thuần không thể mang lại. Và theo cách nói bây giờ, đó là quá trình tích lũy “taste”. Bạn hình thành cảm giác trực tiếp về cái gì là tốt và vì sao, rồi phát triển quan điểm rõ ràng ở những điểm ra quyết định mà người khác còn chẳng buồn suy nghĩ tới. Giờ AI phổ biến nên nhiều nơi muốn nhảy sang tự động hóa quá nhanh, nhưng tại www.socratify.com chúng tôi vẫn tự tay làm nội dung. Ai cũng nói phải làm bằng AI, nhưng mục tiêu của chúng tôi là tuyển chọn ngữ cảnh và chất lượng cho đúng. Về sau có thể tự động hóa phần nào quy trình kiểm chứng, nhưng qua rất nhiều trải nghiệm gián tiếp, chúng tôi thấy việc thay thế hoàn toàn bộ não và insight của con người là điều rất khó

  • YC đã thay đổi cuộc chơi bằng cách khiến seed funding trở nên dễ tiếp cận hơn nhiều. Tôi tin chắc Paul Graham, Jessica Livingston và đội ngũ YC đã nhìn đúng vấn đề của hệ thống cũ và sửa nó. Trước khi YC xuất hiện, seed funding gần như khó tới mức bất khả thi. Nó bất bình đẳng và giống như phải thuyết trình trước 8 partner cáu kỉnh trong một văn phòng ngân hàng cũ kỹ. Nếu có công thì phải ghi nhận cho đúng, và chính họ là những người đã sửa thị trường này

    • Tôi nghĩ điểm này còn gây tranh cãi. Dù việc gọi vốn được mở ra cho nhiều người hơn, thực tế trước và sau YC thì seed vẫn luôn khó. Khác biệt là khi xuất hiện một người chơi lớn như YC, vị thế của các nhà sáng lập bootstrapping lại yếu đi hơn. Từ một thời điểm nào đó, nhà sáng lập không còn theo đuổi điều mình thực sự muốn nữa mà chạy theo những chủ đề YC chọn. Cơ hội để nhà sáng lập tự mình rèn luyện kỹ năng mình muốn thành thạo cũng ít đi

  • Tôi mong những công ty lớn như OpenAI sẽ nghiêm túc đọc “Do Things That Don’t Scale” và thực sự tham khảo nó. Với lượng vốn như thế, họ hoàn toàn có thể trả tiền đàng hoàng để mua license dữ liệu cần thiết. Nhưng họ chỉ chọn cách có thể scale (scraping, stealing), như thể hy vọng rằng nếu lấy thật nhiều một cách lén lút thì cuối cùng sẽ không ai biết, hoặc khiếu nại chỉ đến muộn. Tức là họ hy vọng cứ mặc kệ chuyện những người sáng tạo nội dung hiện nay bị dùng làm dữ liệu huấn luyện AI mà không hề được trả một đồng nào

    • Tôi cho rằng chuyện này liên quan đến lòng tham không muốn bỏ tiền trong chủ nghĩa tư bản hơn là vấn đề scale

  • Đây là bài viết đầu tiên tôi đọc trên Hacker News. Mỗi lần nó được đưa lên lại, những ký ức cũ lại sống dậy