#28 - Làm Startups thật ra là sử dụng ràng buộc
Hãy trở lại làm quiz này sau khi bạn đọc xong bài viết nhé!
Xu hướng thích gỡ bỏ ràng buộc
Khi làm Startups thì chúng ta có khá nhiều ràng buộc (constraints): không có tiền, không có nhân lực, hay không có chuyên môn kỹ thuật.
Rất dễ dàng để chúng ta nghĩ rằng càng gỡ bỏ nhiều ràng buộc thì sẽ càng tăng khả năng thành công. Nhiều Founders tìm đến VC để có thêm tiền, và khi có tiền rồi thì họ lại tuyển nhiều bộ phận như Marketing, Operations, Product, etc. Nhiều người sẽ tìm Co-Founders có nền tảng kỹ thuật để có thể triển khai các giải pháp phần mềm hiệu quả hơn. Đó đều là những nỗ lực để nới lỏng các ràng buộc mà Startups thường phải đối mặt.
Tuy nhiên, mình muốn trích dẫn một đoạn tweet của Paul Graham - nhà sáng lập của YCombinator:
"When people visit your startup, they should be surprised how few people you have. A visitor who walks around and is impressed by the magnitude of your operation is implicitly saying, "Did it really take all these people to make that crappy product?"
Tại sao nhà sáng lập của YCombinator - một tổ chức đã rót vốn cho những startups nổi tiếng nhất thế giới như Airbnb, Dropbox hay Reddit, lại nói như vậy, thay vì khuyến khích startups tuyển nhiều người để có thêm nhân lực và băng thông làm sản phẩm?
Mình nghĩ lý do là vì việc gỡ bỏ ràng buộc (constraints) không phải lúc nào cũng tốt.
Ràng buộc về mặt nhân lực
Một pattern mình thường thấy trong việc tuyển người để tăng băng thông mà mang lại kết quả không tốt, là khi các early-stage startups tuyển vị trí Product Manager đầu tiên.
Quan điểm của mình là trong giai đoạn early-stage, pre-Product-Market-Fit, mình nghĩ Founders phải là người làm các đầu việc của Product Management.
Họ phải thường xuyên tương tác với người dùng, nhúng tay vào các công việc định hình giải pháp và triển khai nó đến với người dùng như thế nào, cũng như trực tiếp quan sát feedback từ người dùng để có thể hình thành mental models trong đầu về những vấn đề, cơ hội hay hướng đi mới cho công ty.
Tuyển một người Product Manager riêng để làm chuyện đó trong giai đoạn mà định hướng hay traction của sản phẩm chưa rõ ràng là một công thức dẫn đến thất bại. Có quá nhiều sự bất định diễn ra, và rất nhiều quyết định phải phụ thuộc vào intuitions/convictions mà một người mới vào công ty hay domain đó sẽ không có (mình cũng có viết về trải nghiệm khi không có conviction ở bài này).
Nhìn chung thì việc tuyển thêm người cho startups, đặc biệt là PM, trong giai đoạn early-stage khá rủi ro và đòi hỏi nhiều sự cân nhắc.
Ngoài Product, ngay cả việc thêm những headcount như Marketing hay Operations cũng góp phần giảm sự tiếp xúc của Founders đối với những đầu việc mà gần như rất quan trọng để xây dựng được mental models về chính công ty, khách hàng và thị trường của bạn.
Mình không nói là không nên thêm người, nhưng bạn chỉ nên làm vậy khi đã xác định rõ rằng bottleneck trong startups của bạn là ở điểm nào. Nếu vấn đề là bạn không hiểu rõ được đối tượng người dùng của mình là ai, JTBDs của họ là gì, thì việc không attract được thêm leads mới khả năng cao là do bạn đang không marketing đúng ngôn ngữ resonate với thế giới quan của họ, hơn là do bạn thiếu nhân lực để chạy Marketing.
Ràng buộc về chuyên môn
Trong một bài viết trước mình có đề cập về câu chuyện Do Things That Don't Scale ở A Little Better.
Đại loại là tụi mình đã làm một sản phẩm cải thiện sức khỏe tâm lý thông qua thực hành biết ơn bền vững. Một trong những giả thuyết tụi mình muốn validate đó chính là:
Người dùng sẽ có động lực để thực hành biết ơn thường xuyên hơn khi họ nhận được sự giúp đỡ (dưới dạng những món quà như hình và lời nhắn) từ người khác
Thay vì ngồi implement một thuật toán matching người dùng với nhau mà có thể mất cả mấy tuần hoặc một tháng trời, tụi mình quyết định làm Unscalable Work - đó là mỗi người dùng sẽ có một virtual partner account mà chính Founders là tụi mình sẽ phải vào để gửi quà cho họ mỗi ngày.
Điều này có nghĩa là mỗi ngày tụi mình phải mở app lên, login vô từng virtual partner account cho mỗi users, và chọn quà để gửi. Sau một khoảng thời gian thử nghiệm thì mình thấy giả thuyết đã được kiểm chứng khi có nhiều người dùng hơn quay trở lại sử dụng, tuy nhiên theo thời gian tụi mình càng ngày càng có nhiều người dùng hơn.
Vì số lượng vẫn chưa đủ để phải implement một thuật toán matching, tụi mình vẫn quyết định tiếp tục làm Unscalable Work, nhưng cố gắng tối ưu hóa một chút bằng cách xây dựng một trang admin để cho tụi mình đỡ tốn công phải login vào từng virtual partner account.
Mình có background technical, tuy nhiên thế mạnh của mình là backend chứ không giỏi front-end, đồng nghĩa với việc xây dựng giao diện một trang admin nhìn "được" đối với mình cũng đã khá khó. Tuy rằng làm backend cho trang admin này thì rất nhanh, nhưng nghĩ đến chuyện phải tốn nhiều sức để code frontend cho tính năng mà chỉ tụi mình (Founders) sử dụng thì mình thấy khá là thiếu động lực.
Trong ràng buộc đó thì mình đã tìm đến một cái tool gọi là tldraw - có hỗ trợ AI chuyển đổi từ wireframe ra luôn hẳn frontend code. Việc mình tìm ra được công cụ này đã giảm thời gian phát triển trang admin từ 1 tuần xuống còn đúng 1 ngày. Chính vì mình không có chuyên môn về frontend, và mình không có nhiều động lực để học trong lúc này, nên mình đã tìm ra được một cách mà biến được thứ mình hình dung trong đầu ra thành code nhanh nhất có thể ở mức độ chất lượng chỉ cần tạm ổn.
Hãy sử dụng ràng buộc
Hy vọng thông qua bài viết này, mọi người có cái nhìn rõ hơn về chuyện sử dụng ràng buộc khi làm Startups. Takeaway thì mình nghĩ khá đơn giản thôi, đó là không phải ràng buộc nào cũng nên gỡ bỏ, và chuyện tập trung vào những giải pháp có thể fit vào trong các ràng buộc đó đôi khi sẽ là cách tiết kiệm thời gian chi phí cũng như rủi ro nhất cho một người làm Startups.
Một số tài liệu tham khảo
