Lúa hóa kiến thức
Chọn đúng nền văn minh - Phần 2.2: IAP & SaaS – Cả đàn nuôi voi
🕔 22 thg 4, 2025
🧑🎓 Ông Giáo
Ở phần trước, mình nói về mô hình "Cá đẻ trứng" – nơi sản phẩm được tung ra liên tục để test số, app nào sống được thì giữ lại nuôi tiếp. Cách làm này rất đặc trưng của môi trường IAP – In-App Purchase, nhưng cũng có điểm giao với cách làm của nhiều team tăng trưởng ngắn hạn khác.
Còn trong phần này, sẽ chuyển hẳn sang một nhịp khác: làm ít, chăm kỹ, sống lâu. Trước mình gọi là "Khỉ chăm con", nhưng sau khi suy nghĩ lại thì thấy chưa đủ – vì khỉ vẫn đẻ nhiều. Nên giờ đổi thành hình ảnh "Cả đàn nuôi voi": đầu tư lâu dài, tốn tài nguyên, nhưng nếu thành công thì có giá trị bền vững.
Tuy gọi theo tên IAP, nhưng vòng đời sản phẩm và cách tổ chức team trong bài này không chỉ đúng với app trả phí. Nó còn đúng với rất nhiều mô hình SaaS, các sản phẩm phục vụ thị trường chuyên biệt, hoặc các công ty đặt trọng tâm vào việc xây dựng giá trị dài hạn thay vì chạy theo trend ngắn hạn.
Đây là kiểu môi trường mình yêu thích nhất: nơi sản phẩm được thiết kế với niềm tin lâu dài, có vision rõ, và cả team chấp nhận đi chậm – để đi xa.
Ở những công ty theo hướng nuôi voi, sản phẩm vẫn là một thử nghiệm – nhưng là thử nghiệm xoay quanh một niềm tin dài hạn. Flow có thể sai, tính năng có thể chưa đúng, nhưng team tin rằng có một nhu cầu thật sự chưa được giải quyết đúng cách – và nếu tìm ra được giải pháp đủ hay, đây sẽ là sản phẩm đáng để theo đuổi trong nhiều năm.
Ví dụ như Notion – thời đầu là một editor nặng nề, thiếu ổn định, chưa mượt. Nhưng team không làm lại từ đầu, cũng không rẽ hướng sang một sản phẩm dễ kiếm tiền hơn. Họ tiếp tục đào sâu trên một niềm tin duy nhất: người dùng đang phải sống với quá nhiều công cụ rời rạc – và xứng đáng có một không gian làm việc duy nhất, nơi mọi thứ được tổ chức theo cách của riêng mình. Giải pháp có thể phải làm lại nhiều lần, nhưng trục giá trị ấy chưa từng đổi.
Với nhiều công ty khác, niềm tin này có thể đến từ việc nhìn thấy một khoảng trống thị trường. Có thể là một hành vi mới đang hình thành mà chưa ai hỗ trợ tốt. Có thể là một nhóm người dùng thường bị bỏ qua. Niềm tin không cần phải lớn lao, nhưng phải thật – và đủ mạnh để giữ team lại với sản phẩm, ngay cả khi mọi thứ chưa thuận.
Không có con voi nào lớn chỉ sau một đêm. Một sản phẩm nuôi dài thường đi qua 6 giai đoạn – mỗi giai đoạn có một logic riêng về cách phát triển, ra quyết định, và giữ được nhịp sống.
Introduction – Giai đoạn chuẩn bịSản phẩm còn mơ hồ, có thể chưa ra store hoặc chỉ soft launch nhỏ. Làm MVP không phải để test số, mà để kiểm chứng niềm tin: vấn đề có thật không, giải pháp có ai cần không.Chỉ cần vài tín hiệu đúng là đủ lý do để nuôi tiếp.
Growth – Giai đoạn tăng trưởng
Bắt đầu có user thật, có feedback, có người quay lại. Team thử nghiệm paywall, gói giá, onboarding… Nếu chỉ số ổn thì mở rộng tiếp, nếu không thì rất dễ dậm chân tại chỗ.
Maturity – Giai đoạn trưởng thành
User ổn định, LTV tăng, sản phẩm bước vào giai đoạn tinh chỉnh. Không còn làm mới quá nhiều, mà tập trung tối ưu hành trình chính, xử lý nợ thiết kế, và phối hợp chặt hơn với các team khác.
Saturation – Giai đoạn bão hoà
Tăng trưởng chững lại, user mới giảm. Team thử mở nhánh mới: cá nhân hoá, nội dung nâng cao, tính năng phụ… để giữ sản phẩm tiếp tục sống ổn định.
Decline – Giai đoạn suy giảm
Churn tăng, user rời đi, feedback tiêu cực nhiều hơn tích cực. Đây là lúc team phải tự hỏi: còn nên cứu không? Nếu có – cần pivot ở đâu? Nếu không – nên sống gọn lại hay gộp vào sản phẩm khác?
Revival – Giai đoạn tái sinh
Có khi phải làm lại gần như từ đầu: đập bỏ feature cũ, thay đổi luồng, định vị lại user. Không để quay về như cũ, mà để tìm một cách sống mới – thường bắt đầu từ nhóm user chưa từng nhắm tới, với mô hình kinh doanh khác.
Từng giai đoạn có một nhịp riêng. Lúc đầu cần chậm để hiểu. Giữa chặng phải tăng để sống. Về sau cần giữ để không rơi. Không ai mong đến đoạn tái sinh, nhưng cũng không ai chắc sẽ mãi ở đoạn trưởng thành. Team nào biết mình đang ở đâu – sẽ nuôi được sản phẩm lâu hơn.
Ứng với nhu cầu phát triển của 6 giai đoạn sản phẩm, có thể chia cách tổ chức team Product ra làm 3 loại:
1️⃣ Team nhỏ – khám phá: Introduction + đầu Growth
Team Product
Sản phẩm còn mơ hồ, team rất gọn nhẹ, ít phân vai. Founder trực tiếp tham gia vào gần như mọi quyết định. Tất cả mọi người cùng làm bất cứ việc gì cần thiết để nhanh chóng xác định đúng vấn đề và giải pháp, từ thử nghiệm nhanh với người dùng đến hỗ trợ cả công việc vận hành.
Product Design: Làm tất - không cần quá tinh chỉnh.
Designer lúc này gần như là người biến ý tưởng ban đầu thành sản phẩm đầu tiên có thể dùng được. Công việc bao gồm: vẽ flow cơ bản, dựng UI nhanh, làm prototype vừa đủ để team cùng test. Không cần hoàn hảo, mà ưu tiên nhanh để lấy phản hồi từ người dùng thật càng sớm càng tốt.
Nghiên cứu người dùng lúc này rất tự phát nhưng thiết thực: gọi video call nhanh với user, theo dõi log hoặc screen recording để hiểu người dùng gặp vấn đề ở đâu, đọc kỹ từng dòng review trên App Store, hoặc trực tiếp trao đổi với người phụ trách support để nắm vấn đề.
Ngoài công việc thiết kế, Designer thường hỗ trợ luôn cả copywriting ngắn, dựng landing page, test nhanh tính năng vừa dev xong, hoặc những việc cần thiết khác giúp sản phẩm chạy được. Designer được kỳ vọng có tính chủ động cao, phản ứng nhanh trước tín hiệu sớm từ người dùng, linh hoạt điều chỉnh và không ngại bỏ đi những thiết kế chưa hiệu quả.
2️⃣ Team đầy đủ – vận hành ổn định: Cuối Growth + Maturity + đầu Saturation
Team Product:
Sản phẩm tăng trưởng ổn định, user tăng nhanh và đều. Team được mở rộng đáng kể, các vai trò phân chia rõ ràng: PM, Dev, Data, Growth, CS, và Design. Mỗi người phụ trách chuyên sâu một mảng. Quy trình làm việc rõ ràng hơn, nhiều bên liên quan hơn, quyết định được đưa ra chậm hơn nhưng chắc chắn và chất lượng hơn nhờ có nhiều góc nhìn phản biện.
Product Design: Công việc ít lại - chất lượng sâu hơn.
Designer lúc này không còn làm đa nhiệm mà tập trung vào chiều sâu chuyên môn: tối ưu hóa hành trình quan trọng (onboarding, đăng ký, thanh toán), đo đạc hiệu quả từng phiên bản thiết kế qua A/B test, và liên tục phối hợp chặt chẽ với PM, Growth, Data để ra quyết định thiết kế dựa trên dữ liệu rõ ràng.
Phương pháp UX research trở nên bài bản hơn, như usability testing kỹ càng, user interview sâu với kịch bản cụ thể, phân tích phản hồi người dùng một cách có hệ thống.
Bên cạnh kỹ năng chuyên môn sâu, Designer cũng cần tư duy hệ thống tốt để xây dựng và duy trì design system, đảm bảo sự đồng nhất về trải nghiệm xuyên suốt sản phẩm. Kỹ năng giao tiếp và trình bày thiết kế quan trọng hơn bao giờ hết để bảo vệ quyết định với nhiều bên liên quan. Các vai trò chuyên môn như UX Researcher, UX Writer, DesignOps xuất hiện rõ ràng trong giai đoạn này, giúp team vận hành bài bản và hiệu quả hơn.
Giai đoạn này đặc biệt phù hợp với những designer thích phát triển chuyên môn sâu, làm việc bài bản và theo quy trình rõ ràng.
3️⃣ Team tinh gọn – điều chỉnh hoặc tái định hướng: Cuối Saturation + Decline + Revival
Team Product:
Sản phẩm qua giai đoạn tăng trưởng nóng, đang gặp khó khăn hoặc chững lại. Team được thu gọn, chỉ giữ lại các thành viên chủ chốt am hiểu sản phẩm sâu sắc. Quyết định lúc này quan trọng và khó khăn hơn nhiều, như cắt bỏ tính năng lớn, thay đổi hoàn toàn định hướng kinh doanh, pivot sang nhóm người dùng mới hoặc điều chỉnh chiến lược monetization. Team ưu tiên linh hoạt, quyết định nhanh, và sẵn sàng thử nghiệm táo bạo hơn.
Product Design: Lại làm tất
Designer trở lại trạng thái làm nhiều thứ cùng lúc, nhưng lần này mỗi thứ đều đòi hỏi chiều sâu nhất định. Công việc gồm rà soát toàn bộ trải nghiệm để cắt giảm hoặc tối ưu hóa những phần không hiệu quả, thử nghiệm ý tưởng mới nhỏ gọn nhưng tác động lớn, và liên tục điều chỉnh UX/UI để tìm cơ hội phục hồi.
Designer lúc này thường xuyên tự thực hiện nghiên cứu người dùng nhanh và thực tế như: phỏng vấn ngắn với nhóm người dùng quan trọng, gửi quick-survey để tìm hiểu vấn đề, hoặc tự đọc hàng loạt support tickets để rút ra insight trực tiếp từ user.
Kỹ năng đặc biệt quan trọng lúc này là tư duy business và khả năng xử lý trade-off tốt. Designer phải liên tục đánh giá xem thứ gì cần giữ để duy trì user cũ, thứ gì cần mạnh dạn bỏ đi để đón user mới, làm sao cân bằng các quyết định mà không gây ra xáo trộn quá lớn.
Thay vì tạo ra thứ hoàn hảo, Designer lúc này tập trung làm thứ thực dụng, nhanh, đo được tác động rõ ràng, và có thể điều chỉnh ngay dựa trên tín hiệu thực tế. Ưu tiên lớn nhất không còn là làm "thiết kế đẹp nhất", mà là giúp sản phẩm sống được và phát triển tiếp được trong tương lai.
Lời nhắn
Tổng kết lại, mỗi cách tổ chức team Product sẽ dẫn tới cách làm Product Design rất khác nhau. Không có cách nào tuyệt đối tốt hơn cách nào – chỉ có cách phù hợp nhất với bối cảnh sản phẩm, với kỳ vọng từ founder, và với chính định hướng nghề nghiệp của mỗi người.
Chọn đúng môi trường làm việc cũng quan trọng như chọn đúng sản phẩm để xây dựng. Mỗi lựa chọn đều có cái giá riêng – nhưng nếu hiểu rõ mình hợp với kiểu nào, thì cơ hội phát triển và tạo ảnh hưởng lên sản phẩm cũng sẽ rõ ràng hơn rất nhiều.
Mọi người muốn tìm hiểu về môi trường nào tiếp theo không?
Trên đây là những ý kiến chủ quan của mình. Mình đang cùng team thực hiện một dự án nghiên cứu “UX Map - Công việc của Product Designer tại Việt Nam” để có thể nhiều góc nhìn đa dạng và khách quan hơn. Nếu thấy nội dung này hữu ích, bạn hãy cùng tham gia để trả lời Survey nhé!
Ông Giáo
22/04/2025.
