Hành trình xây dựng công ty $100M

I. Mở đầu:

Sau một quảng thời gian có thể gọi là đủ dài ở vị trí công việc hiện tại. Mình thấy muốn chia sẻ lại những kinh nghiệm, trải nghiệm của mình cho các bạn trẻ. Cách đây vài năm mình có đi dạy đại học, nhưng lúc đó thời gian ít nên cũng không hướng dẫn được mấy khóa. Chắc vài hôm nữa cũng sẽ nghĩ cách để truyền đạt lại có thể là làm video, viết sách hoặc xin đi dạy lại.

Bài này sẽ viết tóm tắt về những cái chung nhất về khía cạnh kinh doanh quản lý, về khía cạnh kỹ thuật, quy trình, hệ phân tích hệ thống, mình sẽ cần viết nhiều bài chi tiết phía sau.

II. Cơ duyên với công việc:

Trước giờ mình đi làm theo tiêu chí, lựa chọn sếp chứ không lựa chọn công ty. Khi đi theo một người tài giỏi, thì mình ít nhiều gì cũng sẽ học hỏi được. Mỗi người mỗi vị trí đều rất đáng học hỏi. Vì vậy các bạn trẻ khi đi phỏng vấn hãy đòi gặp bằng được cấp trên của mình, người quản lý trực tiếp, nếu được thì cứ cấp cao nhất có thể nói chuyện. Không chỉ là công ty phỏng vấn các bạn đâu, mà chính các bạn cũng phỏng vấn lựa chọn người mình sẽ theo sau này.

Mình cũng may mắn được nhiều lần PV với cá Founder/CEO các startup ở VN. Như mình nhớ thì có Trusting Social, Elsa, WorldQuant đều nhận được offer, và trải nghiệm nói chuyện với các vị này cảm giác dễ chịu hơn phỏng vấn Facebook/Google/Amazon nhiều, chúng ta sẽ hiểu được cái chúng ta có thể đóng góp. Những gì có thể làm, định hướng tương lai phát triển của cả hai. Hơn chỉ là phỏng vấn những người giỏi nhất vào làm những việc bình thường nhất (Nhưng thật ra đây lại là bí quyết thành công)

Mình gặp sếp hiện tại thông qua trang Upwork, (làm sao để làm được và tìm được nhau trên đó thì có thể đọc qua những bài cũ của mình), thông qua một dự án side project nhỏ nhỏ. Nói thật cũng không nhớ lúc đó làm gì. Nhưng mình nhớ được là lúc đó chính sếp, (vẫn đang là CEO 1 công ty), tìm đến mình phỏng vấn và giao việc. Chỉ là side project mỗi tối thôi nhưng cảm nhận công việc làm cũng ổn, và khi công ty cũ của mình phải vào tình trạng cắt giảm biên chế thì mình lựa chọn thôi làm luôn remote xem thế nào. Một lựa chọn lúc đó cũng không ngờ không rõ ràng, vì thường những project mình làm freelance chỉ tầm 3 đến 6 tháng. Lúc đó vẫn nghĩ sẽ làm freelance rồi đi phỏng vấn các công ty khác để tìm việc làm ổn định. Nhưng ai ngờ làm tới giờ là 7 năm.

Bài học rút ra một startup nếu muốn thành công, thì ngay từ ban đầu lúc xây dựng team từ chưa có bao nhiêu người. Thì chính những người đi đầu phải trực tiếp tham gia vào quá trình này, chứ không thể trông chờ vào 1 bên thứ 3, headhunt hay chỉ thông qua nhân sự được. Tìm người mình muốn làm chung, và người ta sẽ làm chung mình trong 1 thời gian dài không đơn giản, phải mất ít nhất tầm cỡ 5 năm để một sản phẩm xây định hình mà có thể gặt hái được chút thành quả, nếu trong quá trình này biến động nhân sự lớn sẽ rất khó để xây dựng được một đội ngủ bền vững.

III. Làm những điều đơn giản nhất một cách tốt nhất

Này là triết lý kinh doanh, chứ chẳng đơn giản phần mềm. Đó là lí do tại sao những big tech luôn tuyển những người giỏi nhất vào, bởi vì họ có thể. Họ cần người làm những thứ đơn giản nhất bởi những người giỏi nhất. Thậm chí nhiều người sẽ mất động lực vì điều đó. Tại sao bởi 1 khi một thứ đã làm xong, thay đổi nó sẽ mất gấp đôi thời gian là ít, thậm chí có khi chi phí để sửa chữa sai lầm cũ là gấp 10 lần. Các bạn trẻ khi đi học chắc nghĩ những bài học đơn giản về trang Login, những xử lý nút nhấn, khi chưa có kinh nghiệm sẽ làm qua loa đơn giản, nhưng nó lại ảnh hưởng rất nhiều về vấn đề bảo mật về trải nghiệm đầu tiên của sản phẩm, về những pipeline phía sau.

Chắc chắn sau này khi làm một sản phẩm đã chạy 1 thời gian và ngày càng phát triển. Câu nói giá như lúc trước làm khác hơn. Lúc trước có thêm nhiều thời gian, lúc trước đã kiểm tra, lúc trước dùng thứ này thứ khác. Sẽ là câu cửa miệng, và nó nằm trong technical debt. Những món nợ phải trả từ từ. Tuy nhiên lý do tại sao có những món nợ đó, phải vay phải trả mình sẽ chia sẻ ở phần sau. Cố gắng để làm sao ít phải vay nhất là một thứ phải làm từ đầu.

Vậy làm sao để tốt hơn, phải học hỏi từng ngày, phải đọc sách, phải đọc Internet, phải đi học, phải gặp mọi người, phải tham gia workshop, thập chí phải đi dạy. Nếu chỉ ì ạch làm 1 thứ ngày này qua tháng nọ, cho dù tốt nhưng cũng chỉ là tốt của quá khứ. Lý do tại sao nghề lập trình phải cày rất nhiều, không chỉ về công việc mà về kiến thức kỹ năng là thế. Không có khả năng nắm bắt năng động thì chuyện dừng lại không thể phát triển thêm cho cá nhân hoặc doanh nghiệp rất cao.

IV. Chấp nhận sai, chấp nhận thay đổi

Tại sao làm tốt nhất rồi lại phải sai phải thay đổi, nếu biết trước sao lại vay mà phải trả… Biết trước đã giàu, không vấp ngã làm sao mà đứng dậy. Sếp có nói đối thủ hiện tại của công ty chỉ có duy nhất 1 bên đó là AWS… Và lợi thế duy nhất của chúng ta đối với họ, là chúng ta thay đổi nhanh hơn, chấp nhận sai lầm và sửa chữa nó nhanh hơn. Một bộ máy cồng kềnh không bao giờ có được khả năng đó.

Mình vẫn còn nhớ những dòng code đầu tiên của mình trong dự án. Có cả những dòng code dầu tiên của sếp. Tới giờ này mình nói đùa trong công ty là lỗi hệ thống đều do dòng code đầu tiên của CEO đi mà bắt ổng sửa :D. Chính sếp lúc ban đầu đã là người đưa ra những ý tưởng đầu tiên, những hạt giống, những dòng code. Nhưng nếu chỉ dựa vào những hạt giống đơn giản đó thì chắc cây trái chỉ ra được một cái cây nhỏ nhỏ ở sân vườn chứ chẳng ra được gì to lớn. Vì biết cách nghĩ lớn làm lớn. Sếp đã chấp nhận sai lầm, thay đổi chiến lược, làm những cái to hơn, hơn là chấp nhận bán công ty cho AWS hồi xưa khi làm một cái tool cũng hay hay haha.

Đến thời điểm hiện tại theo mình nhớ, công ty đã hơn 3 lần thay đổi sản phẩm, chiến lược, mô hình sản phẩm. Mặc dù những sản phẩm ban đầu vẫn còn phần nền tảng vẫn như vậy. Tuy nhiên đó là những thứ legacy, đều bước đệm để có thể làm những thứ to hơn. Nếu không đi những bước dò đường đó thì chẳng bao giờ có thể tích lũy được mô hình để cho ngày hôm nay.

Một vài ví dụ về sản phẩm dịch vụ: làm sao để bán được hàng. Ban đầu tiên, ý nghĩ là mời khách hàng tới dùng thẻ tín dụng đăng kí trên Stripe… Số lượng khách hàng dùng là …. 0. Viết cho đã không ai mua. Bán gói subscription chỉ có thể với các doanh nghiệp vừa và nhỏ, tiền lẻ và ít. Nhưng thực tế là, bán hàng cho những công ty thế này khó khó hơn rất nhiều so với những ông to tiền. Lấy $100/ 1 tháng của 1 doanh nghiệp chi tiêu $10.000 1 tháng, khó hơn nhiều lần so với thu $1.000, của doanh nghiệp chi tiêu $100.000 :D. Rồi các hệ thống thẻ tín dụng + trừ tiền các kiểu rất phức tạp. Các gói subscription nó rất khó cho việc sale lẫn việc vận hành viết code chạy…

Cuối cùng mô hình thanh toán hiện tại đã chuyển sang được AWS Marketplace, một kênh phải nói là khách hàng nào cũng tin tưởng, chấp nhận. Quan trọng nhất là khi đưa vào chi phí kế toán tài chính thì nó là 1 khoản thêm của dịch vụ cloud chứ không phải 1 cái chi mới. Và với mô hình kinh doanh hiện tại thì công ty kiếm tiền dựa vào số tiền tiết kiệm được của khách hàng, thì ai cũng hài lòng cho khoản chi này, vì chi phí tổng sẽ thấp hơn. Vì vậy từng phương thức thanh toán từng kênh phân phối sẽ do một tập khách hàng cụ thể, nếu ko thể tìm ra được kênh phân phối đúng, và hợp lý, thì chẳng bao giờ bán được sản phẩm.

Về mặt kỹ thuật cũng có rất nhiều thứ NỢ mà đội kỹ thuật phải trả. Nhưng khi chủ nợ đòi thì quyết phải trả. Đã có những quyết định sai lầm. Ví dụ sử dụng OpenSearch cho việc lưu metadata, làm toán, làm aggregation mình là người đầu tiên phản đối cách làm như thế. Nhưng cuối cùng sau 2 năm mọi thứ chạy có vẻ ổn thì gặp vấn đề scale, cả năm trời không chạy được với khách hàng to. Và quyết định chuyển sang mô hình Druid, ok same problem different name :)), mình vẫn phản đối nói không phải là cách. Nhưng team cứ thích chuyển thì chuyển… Cuối cùng hiện tại mọi thứ ổn định lại khi quyết bán nợ cho bên thứ 3 là Imply họ gánh giúp. Trả tiền để họ phục vụ sướng lắm. Và cái kết là mình nhìn nhóm và mấy sếp cười khẩy khi nói “I TOLD YOU”

V. Bán sản phẩm trước khi hoàn thành:

Cái này chắc mọi người cũng nghe nhiều hiểu nhiều, với sale giỏi có thể bán cái không phải của mình. Còn sale siêu siêu giỏi, là bán cái thậm chí còn chưa tồn tại :D. Mấy sếp bán rất tốt, tìm được đội sale tốt. Và làm ra những sản phẩm để bán những gói sản phẩm còn trước khi đội kỹ thuật biết phải làm nó ra sao. Tìm được khách hàng, tìm được nhu cầu là cái mà startup cần có. Mình chỉ làm về kỹ thuật, nhưng về phần này sếp có một team phải nói là rất tuyệt. Nhiều lúc đội kỹ thuật còn phải năn nỉ sale bán ít ít lại để còn thở.

Nhưng bán cái người ta cần là điều phải làm. Chứ làm 1 sản phẩm thật tốt rồi bán chả ai mua thì vứt đổ sông đổ biển. Đó cũng là 1 nguyên nhân của việc tại sao có NỢ . Do lúc đầu chưa biết làm gì chưa biết bán gì ra sao, chúng ta xây dựng 1 thứ không phù hợp. Tới lúc sản phẩm dò hỏi bán ra được, thì chúng ta phải bắt Husky kéo xe chứ không mang ngựa hay tuần lộc ra kéo haha :)).

Dĩ nhiên do mình không được quyết định về chiến lược kinh doanh, nhưng với óc quan sát, thì việc thay đổi sản phẩm nhanh cũng như thay đổi hệ thống là điều cần phải làm trong kinh doanh. Nhiều startup ở VN mình quan sát thấy kháo nhau, chỉ cần làm gì đó fancy, hay, đẹp người ta sẽ tự dùng :D… Cái đó chắc chỉ là ăn may thôi. Cứ mạnh dạng đi bán trước đi bán được hẵng đi làm. Không đủ vốn không đủ sức để tiếp tục thay đổi thì Go home thôi.

VI. Bài toán tăng trưởng (Scaling) 0->100:

Bài này là vô lý, không thì nhân có bao nhiêu lần nó vẫn là 0. Vì vậy đầu tiên phải là cộng từ những bước nhỏ (sai lầm, bán sản phẩm), sau khi đã có một hướng nào đó bắt đầu phải tăng trưởng. Gồm nhiều thứ:

• Tăng trưởng nhân sự:

Một công ty có 5 nhân sự không khác rất nhiều 1 công ty có 10 nhân sự. Tuy nhiên tới 20 người thì mọi thứ đã khác. Đã có nhiều phòng ban, có nhiều nhóm. Đôi lúc còn không biết hết tên nhau khi làm chung. Nói gì là làm remote. Vì vậy việc tăng trưởng nhân sự, gắn kết nhân viên, là một điều rất cần. Ngay cả về kỹ thuật, một nhóm khá to – theo triết lí Pizza của AWS thì 1 nhóm chỉ nên ăn đủ 2 cái Pizza. (1 mình mình có thể ăn nửa cái nên team mình chừng 4 người :D). Cũng cần trao đổi liên lạc nhiều. Và khi có nhiều nhóm làm nhiều sản phẩm nhiều thứ với nhau, việc gắn kết các nhóm rất khó. Khi không còn họp chung, gọi điện thoại, nói chuyện chung hàng ngày. Và chuyện người này làm thì người kia không biết được nữa. Một vài phương pháp có thể làm gồm luân chuyển nhân sự, luôn có “work shadow”. Trong trường hợp hiện tại cái gì khó mới đều lôi đầu mình làm. Sau khi mình xây dựng ổn định thế là bắt buộc phải bàn giao phần đó cho nhóm khác vận hành, còn mình thì lại đi làm cái mới, không có được thời gian ngồi chơi xơi nước :)). Việc đào tạo nhân sự cũng là một phần của công việc. Một năm mà sếp muốn tăng gấp đôi nhân viên thì không biết làm sao mà quản hết.

Khi tăng trưởng nhân sự cũng sẽ gặp các tình trạng bất ổn, ví dụ người cũ sẽ không hài lòng, sẽ có thay đổi về nền tảng chung. Sẽ có những thứ phía quản lý cần phải chú ý. Thật sự mà nói theo nhận định của mình 1 business thành công, nó gồm nhân sự nhiều hơn là sản phẩm. Đó là lý do vì sao hiện tại nhiều công ty to về AI, thay vì mua lại công ty, họ chỉ đi mua chất xám, đi mua bằng sáng chế, mua bộ khung vận hành nhân sự, chứ ko bỏ tiền mua lại hết công ty, để lại công ty cũ chỉ còn một bộ xương khô…

Việc xây dựng một nhóm ăn ý làm việc được với nhau để xây dựng sản phẩm từ lúc ban đầu tới lúc tăng trưởng khá là quan trọng. Sẽ có những giai đoạn khó khăn, sẽ có những quyết định rất cần thiết. Nhưng đều phải làm. Ví dụ như trước khi công ty định hình được bộ khung hiện tại. Thì công ty đã trải qua biết bao nhiêu PM mình không nhớ hết. Chỉ là mình không thích làm việc với họ thì tầm 6 tháng là họ bay mất :D. Năn nỉ sếp hàng ngày tìm cho được 1 engineering manager ngon hơn, 1 product manager ổn hơn. Và cuối cùng khi 2 vị trí đó finalized thì sản phẩm mới tốt mà vận hành được.

• Tăng trưởng sản phẩm hệ thống:

Phần này khá quan trọng, bởi vì làm sản phẩm ra không chỉ số lượng sản phẩm mới, mà số lượng hệ thống, số lượng tải mọi thứ đều phải tăng, dĩ nhiên sẽ dẫn đến chi phí rất nhiều. May mắn là công ty làm trong lĩnh vực FinOps nên mấy vấn đề chi phí cũng có những phương pháp giải quyết. Nhưng về kỹ thuật thì chuyện đó rất nhiều thứ xảy ra. Nếu tìm ko được người đủ giỏi (như mình :D) để xử lý các vấn đề kỹ thuật này. Thì giữa chuyện làm hệ thống chạy được để bán, và bán được nhiều hoàn toàn khác. Nhiều lúc phải chấp nhận đập đi xây lại – thêm 1 lý do mang NỢ. Nếu không lường trước được tăng trưởng này và xây dựng kiến trúc hệ thống siêu tối không thể làm gì được. Thì chỉ có nước vứt đi thôi…

• Tăng trưởng về khách hàng:

Cuối cùng quan trọng là tăng trưởng khách hàng, như mình nói nhóm kinh doanh, marketing, CS phải hoạt động. Thì nhóm kỹ thuật cũng phải hỗ trợ rất nhiều, số lượng khách hàng tăng lên, nếu làm không ổn suốt ngày phải đi họp gặp khách mà không làm được việc gì. Phải cân đối được giữa khách hàng và sản phẩm. Phải đạt được mục tiêu về kinh tế. Nhiều khách hàng, tiền nhiều, chưa chắc là đã lợi nhuận nhiều. Tăng trưởng khách hàng gấp đôi hàng năm thì làm bao lâu mới giàu được…. Vì vậy nên sếp cứ đòi khách phải tăng gấp 10 trong 1 năm, mà nhân sự với hệ thống chỉ cho tăng gấp đôi. Sếp khôn quá :D.

Vấn đề scaling là vấn đề tối quan trọng của một doanh nghiệp. Nhìn gần ra ở VN thì có startup Vinfast có vẻ gặp vấn đề này. Và họ đang phải loay hoay rất nhiều, làm 1 sản phẩm xe Demo nó khác với làm con xe cho 10K người chạy khác với 100K người chạy và 1 triệu người chạy. Sản phẩm có bán được nhiều, mà càng bán càng lỗ thì chỉ có hết.

Tóm lại

Bài viết đều những thứ cơ bản hết. Chắc cũng không lạ gì với mọi người. Có vẻ đọc sách là có. Vâng có rất nhiều cuốn sách chỉ đông, chỉ tây, có rất nhiều người nói xanh sẽ thắng, đỏ sẽ thắng. Nhưng trên đây chỉ là tập hợp những kinh nghiệm chung nhất về hành trình của mình. Mỗi phần nhỏ mình sẽ viết thêm chi tiết một bài sau. Sẽ nhấn mạnh hơn về phần kiến trúc và kỹ thuật hệ thống.