Những điều tôi học được khi vận hành một doanh nghiệp trong thị trường SaaS cạnh tranh khốc liệt suốt 4 năm

xguru · 2025-04-14T11:01:01+09:00

OnlineOrNot do Max Rozen sáng lập đã bắt đầu trong một thị trường đã có hơn 200 sản phẩm cạnh tranh Ban đầu, nhiều sản phẩm rất khó dùng, sau đó vô số đối thủ khác xuất hiện rồi nhanh chóng biến mất Một số đối thủ nhận vốn VC và được các công ty lớn thâu tóm, khiến trải nghiệm người dùng ngày càng đi theo hướng tệ hơn OnlineOrNot hướng tới một doanh nghiệp bền vững dài hạn được vận hành bằng vốn tự có Tác giả vẫn duy trì công việc toàn thời gian và đều đặn phát triển SaaS Mỗi năm đều viết bài nhìn lại, và một số bài học từng rút ra trong quá khứ đã được chứng minh là sai theo thời gian Những nguyên tắc không thay đổi Dù đã học được rất nhiều điều về việc vận hành doanh nghiệp trong nhiều năm, vẫn có những nguyên tắc cốt lõi không thay đổi mà tôi tiếp tục giữ vững Dành 2 giờ vào mỗi ngày làm việc Trước cả khi bắt đầu OnlineOrNot, tôi đã dành 2 giờ mỗi sáng trước giờ làm để tập trung vào các dự án cá nhân Tôi đã dùng quãng thời gian đó để hoàn thành hàng trăm bài viết, một cuốn sách và nhiều dự án phần mềm Quan trọng hơn số giờ bạn bỏ ra trong một ngày là sự nỗ lực đều đặn mỗi ngày Để có được khoảng thời gian này, tôi dậy sớm hơn 2 tiếng và điều chỉnh lịch sinh hoạt Không làm side project khác Đúng như câu “đuổi theo hai con thỏ thì sẽ không bắt được con nào”, tôi chọn tập trung vào một thứ Một số cá nhân đặc biệt có thể thành công với nhiều dự án, nhưng tôi chấp nhận rằng mình không phải người như vậy Tôi cho rằng chặng đường từ $0 lên $500 MRR là khó nhất và không đáng để phải lặp lại Tôi tập trung vào mô hình đã hoạt động, và cũng chọn cách làm marketing theo cùng góc nhìn đó Ưu tiên giải quyết nỗi đau của khách hàng Khi người dùng đăng ký, tôi gửi email tự động hỏi: “Vì sao bạn đăng ký?” Tôi đọc tất cả email và tự trả lời, và đó trở thành nguồn insight cốt lõi để cải thiện sản phẩm Xác định điều gì đang khiến người dùng khó chịu, rồi thực sự giải quyết nó Kiên trì lặp lại và cải tiến Nếu có việc gì không thể triển khai trong vòng 2 giờ, tôi sẽ thu hẹp phạm vi và tung ra trước Không phải lúc nào cũng khớp hoàn hảo vào đúng 2 giờ, nhưng tôi thích cách phát hành nhanh phiên bản đầu tiên rồi mở rộng tính năng sau Nếu cố làm xong mọi thứ rồi mới phát hành, động lực dễ biến mất và sự tập trung cũng bị suy giảm Hoàn thiện dần tính năng phía sau feature flag hiệu quả hơn nhiều Những bài học đã rút ra Chỉ đọc vài cuốn sách rồi bắt tay vào làm ngay Khi bắt đầu, tôi đã đọc hàng chục cuốn sách kinh doanh để giảm thiểu sai lầm Nhưng cuối cùng tôi nhận ra rằng cách hiệu quả nhất vẫn là tự mắc lỗi rồi học từ đó Ví dụ: từng lên trang chủ Hacker News và có 6000 người truy cập, nhưng số người thực sự vào được tới ứng dụng chỉ ở mức một chữ số Chỉ riêng ở form đăng ký đã mất 75% người dùng → thêm một tùy chọn đăng nhập OAuth đã cải thiện tỷ lệ rơi xuống còn 50% Nếu bắt đầu lại, tôi sẽ chỉ đọc ba cuốn sau rồi triển khai ngay: The Mom Test (Rob Fitzpatrick) Deploy Empathy (Michele Hansen) Badass: Making Users Awesome (Kathy Sierra) Nếu cần thêm chi tiết thực chiến để vận hành SaaS, tôi cũng khuyên đọc The SaaS Playbook (Rob Walling) Giải quyết vấn đề quan trọng hơn bán subscription Mục tiêu của SaaS không phải là bán subscription mà là giải quyết nỗi đau của khách hàng Cần chuyển tư duy từ “cứ tiếp tục làm thêm tính năng rồi sẽ có người dùng” sang “hãy giải quyết vấn đề gây bực bội trong công việc của người dùng” SaaS chỉ là một cách để giải quyết vấn đề; ngoài ra còn có thể tiếp cận bằng screencast, tài liệu, bài viết, sách, workshop, code sample, v.v. Làm nhỏ và phát hành thường xuyên Người dùng thường đề xuất ý tưởng tính năng nhưng trên thực tế lại hiếm khi sử dụng chúng Người mới làm SaaS lần đầu rất dễ xúc động chỉ vì có ai đó chịu trò chuyện, rồi lao vào xây luôn tính năng Hãy hỏi họ sẽ dùng tính năng đó như thế nào, tìm hiểu cả cách những người dùng khác đang giải quyết vấn đề tương tự, rồi triển khai trước với mức tối thiểu có thể để xem phản ứng Quan trọng là phải tiếp cận một cách chiến lược để làm ra tính năng có nhiều người dùng, thay vì tạo “snowflake feature” chỉ có một người dùng Xóa một tính năng đã tốn vài giờ để làm thì đã đau, nhưng xóa một tính năng đã tốn vài tháng thì còn đau hơn nhiều Cứ phát hành trước, mở rộng để sau Phiên bản đầu của OnlineOrNot được ra mắt rất nhanh mà không tối ưu kiến trúc Trên thực tế, hệ thống có lỗi giới hạn số lượng check mà nó xử lý được ở khoảng 100, và khi có sự cố thì UI chỉ hiện đơn giản “Error!” nên còn rất dang dở Nhưng tôi chọn bị chê vì UI chưa hoàn thiện còn hơn làm thêm những tính năng không cần thiết Vì không có gì đảm bảo ngay từ đầu sẽ có hàng nghìn người dùng kéo tới, nên xác thực nhanh quan trọng hơn Tôi tạm thời nâng cấp database lên gói cao hơn để tăng sức chứa cho số lượng check Chỉ trong vài giờ, tôi đã refactor sang một cấu trúc có thể xử lý hàng triệu check và cũng cải thiện màn hình lỗi Vận hành chương trình early access Ở giai đoạn đầu phát triển sản phẩm, đa số người dùng khá bao dung với các tính năng chưa hoàn thiện Theo thời gian, ngày càng có nhiều người mong đợi một sản phẩm trưởng thành hơn Để giải quyết điều này, tôi thêm checkbox “tham gia chương trình early access” vào từng tài khoản người dùng Người tham gia sẽ được dùng trước các tính năng mới nhất còn chưa hoàn thiện và gửi phản hồi Đây là cách hữu ích để cân bằng giữa thử nghiệm và phản hồi Hãy đưa free trial vào càng sớm càng tốt Dạo này lời khuyên phổ biến là “free plan quá khó để cân bằng nên đừng làm” Nhưng ở giai đoạn đầu, free plan rất hiệu quả cho truyền miệng và thu hút người dùng Nhược điểm là nếu free plan khác biệt quá nhiều với tính năng trả phí, thì cần có cách để người dùng trải nghiệm những tính năng tốt Mãi tới 11 tháng sau khi bắt đầu, tôi mới thêm câu hỏi “Bạn có muốn bắt đầu free trial không?” vào quy trình onboarding Ý nghĩa thực tế của câu hỏi đó là: > “Bạn có muốn dùng thử các tính năng tốt trong 14 ngày rồi quyết định, hay muốn dùng vài tháng trong trạng thái bị giới hạn tính năng rồi cuối cùng thất vọng?” Sau đó tôi thử nghiệm việc mặc định cấp free trial cho mọi người dùng, và chỉ riêng thử nghiệm đó đã giúp tốc độ tăng trưởng hàng tháng tăng hơn gấp đôi Kết luận: thông điệp “Đây là dịch vụ trả phí. Bạn cần thông tin thanh toán để tiếp tục dùng các tính năng tốt” hiệu quả về mặt kinh doanh hơn nhiều so với “Đây là dịch vụ miễn phí. Có thể bạn sẽ phải trả tiền nếu dùng nhiều” Bản thân tài liệu cũng là sản phẩm Trước đây, câu “developer không đọc tài liệu” khá phổ biến, nhưng đó là một nhận định hoàn toàn sai Một số khách hàng lý tưởng đã khen tài liệu của OnlineOrNot, và từ đó tôi đầu tư nghiêm túc vào phần này Tôi cũng tự xây API docs để có thể kiểm soát hoàn toàn trải nghiệm người dùng Quan sát từ công cụ product analytics cho thấy: Khi người dùng gặp vấn đề trong UI, nếu họ xem tài liệu rồi tìm ra tính năng, họ sẽ tiếp tục dùng sản phẩm Nếu họ không tìm được thông tin mình cần, họ sẽ không tạo check và rời đi Chất lượng tài liệu gắn trực tiếp với tỷ lệ giữ chân người dùng Hãy thiết kế sản phẩm cho môi trường mobile Trái với suy nghĩ phổ biến, người dùng B2B SaaS cũng bắt đầu công việc trên smartphone Thực tế, khoảng 50% tổng số người dùng bắt đầu dùng sản phẩm trên mobile Họ tạo tài khoản, đăng ký vài trang, rồi quay lại kiểm tra trên PC Trong 6 tháng đầu, tôi không tính đến môi trường mobile, và phần lớn người đăng ký từ mobile đều rời bỏ Sau đó, khi áp dụng UI responsive, tỷ lệ giữ chân người dùng mobile tăng lên rõ rệt Hãy hỏi trực tiếp người dùng đến từ đâu Một trong những thay đổi code giá trị nhất tôi đưa vào giữa năm đầu tiên là thêm câu hỏi “Bạn biết đến OnlineOrNot từ đâu?” khi đăng ký Hiểu được các kênh thu hút người dùng là điều cực kỳ quan trọng để tối đa hiệu quả marketing Có hàng chục kênh marketing, nhưng nguồn lực để tập trung thì có hạn Khi xác định được kênh nào hoạt động tốt, hãy dồn lực vào kênh đó và tiếp tục cho tới khi hiệu quả giảm xuống Không dùng công cụ phân tích mang tính xâm nhập Ban đầu tôi cũng áp dụng session tracking và funnel analytics như các sản phẩm SaaS thông thường, nhưng hiệu quả không cao Nó có thể hữu ích với các đội lớn, nhưng với dịch vụ nhỏ thì rất dễ hiểu lầm những kết quả ngẫu nhiên Với tư cách solo founder chỉ có 2 tiếng mỗi sáng, thay vì phân tích một lượng dữ liệu khổng lồ, cách hiệu quả hơn là nhận ý kiến trực tiếp từ nhóm người dùng tin cậy (inner-circle) Tôi nhận phản hồi mang tính cảm nhận về tính năng hay vấn đề, rồi cải thiện sản phẩm dựa trên phán đoán giàu trực giác Hãy nói chuyện với khách hàng tiềm năng ngay cả khi chưa có tính năng Có lần tôi nhận được câu hỏi từ một CTO hỏi liệu tôi có hỗ trợ một tính năng cụ thể hay không Ban đầu tôi định chỉ kết thúc bằng câu “Xin lỗi, hiện chưa có”, nhưng rồi vì tò mò, tôi hỏi thêm về vấn đề họ đang gặp phải và mục tiêu họ muốn đạt được tôi cũng hỏi nhóm người dùng inner-circle xem họ có gặp vấn đề tương tự không và chia sẻ ý tưởng về cách tôi sẽ thiết kế tính năng đó Kết quả là CTO này đã trở thành khách hàng trả phí ngay ngày hôm sau, và đến giờ vẫn còn là khách hàng Tính năng đó cũng đang được những người dùng khác sử dụng tốt Tôi dành nhiều thời gian để xây nền tảng hơn là giải quyết vấn đề cốt lõi Trong 4 năm qua, hơn một nửa thời gian phát triển đã được dùng để xây dựng nền tảng SaaS mục tiêu ban đầu là “kiểm tra website có bị down hay không và gửi cảnh báo” chỉ là một phần nhỏ Những thứ thực sự cần có bao gồm: nhiều cơ chế xác thực và quản lý người dùng bản dùng thử, onboarding các tác vụ DB lặp lại, quản lý team, xử lý invoice email vòng đời người dùng, v.v. Một số phần tôi thuê ngoài qua các dịch vụ như Stripe, nhưng vẫn có rất nhiều chỗ phải tự xử lý hoặc cần cá nhân hóa nên cuối cùng phải tự xây Định giá thực sự rất khó Nếu giá quá cao, kỳ vọng sẽ tăng lên hoặc người dùng ngần ngại đăng ký ngay từ đầu Nếu giá quá thấp, có những người trả $9 nhưng lại đòi sửa toàn bộ ứng dụng theo ý họ Cách giải quyết: hoàn tiền và để những khách hàng khó tính đó rời đi tăng giá lên và bước tiếp đặc biệt ở giai đoạn đầu khi đang mở rộng tính năng, việc thử nghiệm giá liên tục là bắt buộc Đừng chỉ ám ảnh với MRR MRR (Monthly Recurring Revenue) có thể là một chỉ số không phù hợp để đo hiệu quả kinh doanh Vì những gì bạn làm vài tuần hoặc vài tháng trước ảnh hưởng đến MRR hiện tại, nên rất khó đo hiệu quả theo thời gian thực Với một số sản phẩm SaaS, từ lúc người dùng đăng ký đến lúc thanh toán thực tế có thể mất hơn 60 ngày Vì vậy cần dùng các chỉ số khác để biết sản phẩm có thực sự được sử dụng và có tạo ra giá trị hay không Ví dụ: số ảnh được tạo, số form được gửi, tức là các chỉ số thành công dựa trên hành vi Đừng bao giờ cung cấp “unlimited” Sẽ luôn có whale customer tận dụng “unlimited” tới mức tối đa Ví dụ: có khách chỉ trả $250/tháng nhưng dùng lượng tài nguyên khổng lồ Nếu đơn vị bạn cung cấp theo kiểu unlimited là thứ phát sinh chi phí, thì chắc chắn bạn sẽ lỗ Lời khuyên này cũng áp dụng cho lifetime deal Nếu hứa cho dùng trọn đời với giá $100, bạn có thể sẽ phải nhận các yêu cầu thêm tính năng trong nhiều năm tiếp theo Nếu bán qua marketplace bên thứ ba, thậm chí bạn có thể chỉ nhận được 30% số tiền đó Rốt cuộc, bạn đang mời gọi những người không phải khách hàng thật sự, mà là những người muốn lợi ích ngắn hạn và sẽ gắn chặt với bạn rất lâu Với tài nguyên trả phí, nhất định phải áp dụng rate limit Nếu bạn dùng các API mất phí như AI, SMS, gửi email, thì giới hạn mức sử dụng là bắt buộc “Họ là khách trả phí thì dùng unlimited cũng được chứ?” → có thể có ngoại lệ, nhưng trong đa số trường hợp, điều đó sẽ dẫn tới hóa đơn chi phí khổng lồ hoặc bị vendor gắn nhãn spam Ví dụ thực tế: một server host hàng trăm website WordPress bị lỗi do thiếu RAM kết quả là hàng nghìn cảnh báo SMS bị gửi tự động, tạo ra chi phí lớn Nếu là khách hàng thực sự cần dùng khối lượng lớn, họ sẽ chủ động liên hệ với bạn Đừng cố giải thích mọi thứ trong một trang > “Nếu bạn cố nói mọi thứ với tất cả mọi người, thì rốt cuộc bạn sẽ chẳng truyền đạt được gì với bất kỳ ai” Câu này đặc biệt đúng với copywriting cho landing page Mỗi khi OnlineOrNot có thêm tính năng, tôi lại tiếp tục thêm mô tả vào landing page chính, và kết quả là thông điệp trở nên rối rắm và người dùng cũng hiểu kém hơn ví dụ: thông báo Slack là tính năng thứ hai tôi xây, nhưng rất nhiều người thậm chí không biết nó tồn tại Giải pháp: tạo landing page riêng cho từng tính năng Trang chính: https://onlineornot.com/ Uptime monitoring: https://onlineornot.com/website-monitoring API monitoring: https://onlineornot.com/api-monitoring Status pages: https://onlineornot.com/status-pages Cron job monitoring: https://onlineornot.com/cron-job-monitoring Mỗi trang đều có đủ không gian để truyền đạt tính năng một cách rõ ràng Tăng traffic là việc khó, còn cải thiện conversion rate thì có thể làm ngay bây giờ Được internet chú ý là một cuộc chơi dài hạn và rất chậm kể cả khi liên tục làm content marketing chất lượng, cũng có thể mất nhiều tháng đến nhiều năm để từ 1–2 lượt truy cập tăng lên hàng trăm Bản thân việc tăng traffic không hề dễ Ngược lại, hành vi của những người đã vào rồi thì có thể thay đổi ngay lập tức ví dụ như thêm tùy chọn đăng nhập OAuth vào form đăng ký, những cải thiện có thể triển khai ngay hôm nay sẽ giúp tăng conversion rate Đối thủ không quan trọng đến vậy Lý do gần như không nói nhiều về đối thủ trong suốt bài viết này là vì họ thực sự không ảnh hưởng quá lớn Tất nhiên, bạn vẫn phải có những tính năng cơ bản để được khách hàng đưa vào danh sách cân nhắc, nhưng đối thủ thật sự là việc người dùng thậm chí còn không biết sản phẩm này tồn tại Quan trọng hơn tính năng chính là độ nhận biết và khả năng tiếp cận

(maxrozen.com)

74 điểm bởi xguru 2025-04-14 | 4 bình luận | Chia sẻ qua WhatsApp

OnlineOrNot do Max Rozen sáng lập đã bắt đầu trong một thị trường đã có hơn 200 sản phẩm cạnh tranh
Ban đầu, nhiều sản phẩm rất khó dùng, sau đó vô số đối thủ khác xuất hiện rồi nhanh chóng biến mất
Một số đối thủ nhận vốn VC và được các công ty lớn thâu tóm, khiến trải nghiệm người dùng ngày càng đi theo hướng tệ hơn
OnlineOrNot hướng tới một doanh nghiệp bền vững dài hạn được vận hành bằng vốn tự có
Tác giả vẫn duy trì công việc toàn thời gian và đều đặn phát triển SaaS
Mỗi năm đều viết bài nhìn lại, và một số bài học từng rút ra trong quá khứ đã được chứng minh là sai theo thời gian

Những nguyên tắc không thay đổi

Dù đã học được rất nhiều điều về việc vận hành doanh nghiệp trong nhiều năm, vẫn có những nguyên tắc cốt lõi không thay đổi mà tôi tiếp tục giữ vững

Dành 2 giờ vào mỗi ngày làm việc

Trước cả khi bắt đầu OnlineOrNot, tôi đã dành 2 giờ mỗi sáng trước giờ làm để tập trung vào các dự án cá nhân
Tôi đã dùng quãng thời gian đó để hoàn thành hàng trăm bài viết, một cuốn sách và nhiều dự án phần mềm
Quan trọng hơn số giờ bạn bỏ ra trong một ngày là sự nỗ lực đều đặn mỗi ngày
Để có được khoảng thời gian này, tôi dậy sớm hơn 2 tiếng và điều chỉnh lịch sinh hoạt

Không làm side project khác

Đúng như câu “đuổi theo hai con thỏ thì sẽ không bắt được con nào”, tôi chọn tập trung vào một thứ
Một số cá nhân đặc biệt có thể thành công với nhiều dự án, nhưng tôi chấp nhận rằng mình không phải người như vậy
Tôi cho rằng chặng đường từ $0 lên $500 MRR là khó nhất và không đáng để phải lặp lại
Tôi tập trung vào mô hình đã hoạt động, và cũng chọn cách làm marketing theo cùng góc nhìn đó

Ưu tiên giải quyết nỗi đau của khách hàng

Khi người dùng đăng ký, tôi gửi email tự động hỏi: “Vì sao bạn đăng ký?”
Tôi đọc tất cả email và tự trả lời, và đó trở thành nguồn insight cốt lõi để cải thiện sản phẩm
Xác định điều gì đang khiến người dùng khó chịu, rồi thực sự giải quyết nó

Kiên trì lặp lại và cải tiến

Nếu có việc gì không thể triển khai trong vòng 2 giờ, tôi sẽ thu hẹp phạm vi và tung ra trước
Không phải lúc nào cũng khớp hoàn hảo vào đúng 2 giờ, nhưng tôi thích cách phát hành nhanh phiên bản đầu tiên rồi mở rộng tính năng sau
Nếu cố làm xong mọi thứ rồi mới phát hành, động lực dễ biến mất và sự tập trung cũng bị suy giảm
Hoàn thiện dần tính năng phía sau feature flag hiệu quả hơn nhiều

Những bài học đã rút ra

Chỉ đọc vài cuốn sách rồi bắt tay vào làm ngay

Khi bắt đầu, tôi đã đọc hàng chục cuốn sách kinh doanh để giảm thiểu sai lầm
Nhưng cuối cùng tôi nhận ra rằng cách hiệu quả nhất vẫn là tự mắc lỗi rồi học từ đó
Ví dụ: từng lên trang chủ Hacker News và có 6000 người truy cập, nhưng số người thực sự vào được tới ứng dụng chỉ ở mức một chữ số
Chỉ riêng ở form đăng ký đã mất 75% người dùng → thêm một tùy chọn đăng nhập OAuth đã cải thiện tỷ lệ rơi xuống còn 50%
Nếu bắt đầu lại, tôi sẽ chỉ đọc ba cuốn sau rồi triển khai ngay:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- Nếu cần thêm chi tiết thực chiến để vận hành SaaS, tôi cũng khuyên đọc The SaaS Playbook (Rob Walling)

Giải quyết vấn đề quan trọng hơn bán subscription

Mục tiêu của SaaS không phải là bán subscription mà là giải quyết nỗi đau của khách hàng
Cần chuyển tư duy từ “cứ tiếp tục làm thêm tính năng rồi sẽ có người dùng” sang “hãy giải quyết vấn đề gây bực bội trong công việc của người dùng”
SaaS chỉ là một cách để giải quyết vấn đề; ngoài ra còn có thể tiếp cận bằng screencast, tài liệu, bài viết, sách, workshop, code sample, v.v.

Làm nhỏ và phát hành thường xuyên

Người dùng thường đề xuất ý tưởng tính năng nhưng trên thực tế lại hiếm khi sử dụng chúng
Người mới làm SaaS lần đầu rất dễ xúc động chỉ vì có ai đó chịu trò chuyện, rồi lao vào xây luôn tính năng
Hãy hỏi họ sẽ dùng tính năng đó như thế nào, tìm hiểu cả cách những người dùng khác đang giải quyết vấn đề tương tự, rồi
- triển khai trước với mức tối thiểu có thể để xem phản ứng
Quan trọng là phải tiếp cận một cách chiến lược để làm ra tính năng có nhiều người dùng, thay vì tạo “snowflake feature” chỉ có một người dùng
Xóa một tính năng đã tốn vài giờ để làm thì đã đau, nhưng xóa một tính năng đã tốn vài tháng thì còn đau hơn nhiều

Cứ phát hành trước, mở rộng để sau

Phiên bản đầu của OnlineOrNot được ra mắt rất nhanh mà không tối ưu kiến trúc
Trên thực tế, hệ thống có lỗi giới hạn số lượng check mà nó xử lý được ở khoảng 100, và
- khi có sự cố thì UI chỉ hiện đơn giản “Error!” nên còn rất dang dở
Nhưng tôi chọn bị chê vì UI chưa hoàn thiện còn hơn làm thêm những tính năng không cần thiết
Vì không có gì đảm bảo ngay từ đầu sẽ có hàng nghìn người dùng kéo tới, nên xác thực nhanh quan trọng hơn
Tôi tạm thời nâng cấp database lên gói cao hơn để tăng sức chứa cho số lượng check
Chỉ trong vài giờ, tôi đã refactor sang một cấu trúc có thể xử lý hàng triệu check và cũng cải thiện màn hình lỗi

Vận hành chương trình early access

Ở giai đoạn đầu phát triển sản phẩm, đa số người dùng khá bao dung với các tính năng chưa hoàn thiện
Theo thời gian, ngày càng có nhiều người mong đợi một sản phẩm trưởng thành hơn
Để giải quyết điều này, tôi thêm checkbox “tham gia chương trình early access” vào từng tài khoản người dùng
- Người tham gia sẽ được dùng trước các tính năng mới nhất còn chưa hoàn thiện và gửi phản hồi
Đây là cách hữu ích để cân bằng giữa thử nghiệm và phản hồi

Hãy đưa free trial vào càng sớm càng tốt

Dạo này lời khuyên phổ biến là “free plan quá khó để cân bằng nên đừng làm”
Nhưng ở giai đoạn đầu, free plan rất hiệu quả cho truyền miệng và thu hút người dùng
Nhược điểm là nếu free plan khác biệt quá nhiều với tính năng trả phí, thì cần có cách để người dùng trải nghiệm những tính năng tốt
Mãi tới 11 tháng sau khi bắt đầu, tôi mới thêm câu hỏi “Bạn có muốn bắt đầu free trial không?” vào quy trình onboarding
- Ý nghĩa thực tế của câu hỏi đó là:
  > “Bạn có muốn dùng thử các tính năng tốt trong 14 ngày rồi quyết định, hay muốn dùng vài tháng trong trạng thái bị giới hạn tính năng rồi cuối cùng thất vọng?”
Sau đó tôi thử nghiệm việc mặc định cấp free trial cho mọi người dùng, và
- chỉ riêng thử nghiệm đó đã giúp tốc độ tăng trưởng hàng tháng tăng hơn gấp đôi
Kết luận:
- thông điệp “Đây là dịch vụ trả phí. Bạn cần thông tin thanh toán để tiếp tục dùng các tính năng tốt”
- hiệu quả về mặt kinh doanh hơn nhiều so với “Đây là dịch vụ miễn phí. Có thể bạn sẽ phải trả tiền nếu dùng nhiều”

Bản thân tài liệu cũng là sản phẩm

Trước đây, câu “developer không đọc tài liệu” khá phổ biến, nhưng đó là một nhận định hoàn toàn sai
Một số khách hàng lý tưởng đã khen tài liệu của OnlineOrNot, và từ đó tôi đầu tư nghiêm túc vào phần này
Tôi cũng tự xây API docs để có thể kiểm soát hoàn toàn trải nghiệm người dùng
Quan sát từ công cụ product analytics cho thấy:
1. Khi người dùng gặp vấn đề trong UI, nếu họ xem tài liệu rồi tìm ra tính năng, họ sẽ tiếp tục dùng sản phẩm
2. Nếu họ không tìm được thông tin mình cần, họ sẽ không tạo check và rời đi
Chất lượng tài liệu gắn trực tiếp với tỷ lệ giữ chân người dùng

Hãy thiết kế sản phẩm cho môi trường mobile

Trái với suy nghĩ phổ biến, người dùng B2B SaaS cũng bắt đầu công việc trên smartphone
Thực tế, khoảng 50% tổng số người dùng bắt đầu dùng sản phẩm trên mobile
- Họ tạo tài khoản, đăng ký vài trang, rồi quay lại kiểm tra trên PC
Trong 6 tháng đầu, tôi không tính đến môi trường mobile, và phần lớn người đăng ký từ mobile đều rời bỏ
Sau đó, khi áp dụng UI responsive, tỷ lệ giữ chân người dùng mobile tăng lên rõ rệt

Hãy hỏi trực tiếp người dùng đến từ đâu

Một trong những thay đổi code giá trị nhất tôi đưa vào giữa năm đầu tiên là
- thêm câu hỏi “Bạn biết đến OnlineOrNot từ đâu?” khi đăng ký
Hiểu được các kênh thu hút người dùng là điều cực kỳ quan trọng để tối đa hiệu quả marketing
Có hàng chục kênh marketing, nhưng nguồn lực để tập trung thì có hạn
Khi xác định được kênh nào hoạt động tốt, hãy dồn lực vào kênh đó và tiếp tục cho tới khi hiệu quả giảm xuống

Không dùng công cụ phân tích mang tính xâm nhập

Ban đầu tôi cũng áp dụng session tracking và funnel analytics như các sản phẩm SaaS thông thường, nhưng hiệu quả không cao
Nó có thể hữu ích với các đội lớn, nhưng với dịch vụ nhỏ thì rất dễ hiểu lầm những kết quả ngẫu nhiên
Với tư cách solo founder chỉ có 2 tiếng mỗi sáng,
- thay vì phân tích một lượng dữ liệu khổng lồ, cách hiệu quả hơn là nhận ý kiến trực tiếp từ nhóm người dùng tin cậy (inner-circle)
Tôi nhận phản hồi mang tính cảm nhận về tính năng hay vấn đề, rồi cải thiện sản phẩm dựa trên phán đoán giàu trực giác

Hãy nói chuyện với khách hàng tiềm năng ngay cả khi chưa có tính năng

Có lần tôi nhận được câu hỏi từ một CTO hỏi liệu tôi có hỗ trợ một tính năng cụ thể hay không
Ban đầu tôi định chỉ kết thúc bằng câu “Xin lỗi, hiện chưa có”, nhưng rồi
- vì tò mò, tôi hỏi thêm về vấn đề họ đang gặp phải và mục tiêu họ muốn đạt được
- tôi cũng hỏi nhóm người dùng inner-circle xem họ có gặp vấn đề tương tự không
- và chia sẻ ý tưởng về cách tôi sẽ thiết kế tính năng đó
Kết quả là CTO này đã trở thành khách hàng trả phí ngay ngày hôm sau, và đến giờ vẫn còn là khách hàng
Tính năng đó cũng đang được những người dùng khác sử dụng tốt

Tôi dành nhiều thời gian để xây nền tảng hơn là giải quyết vấn đề cốt lõi

Trong 4 năm qua, hơn một nửa thời gian phát triển đã được dùng để xây dựng nền tảng SaaS
- mục tiêu ban đầu là “kiểm tra website có bị down hay không và gửi cảnh báo” chỉ là một phần nhỏ
Những thứ thực sự cần có bao gồm:
- nhiều cơ chế xác thực và quản lý người dùng
- bản dùng thử, onboarding
- các tác vụ DB lặp lại, quản lý team, xử lý invoice
- email vòng đời người dùng, v.v.
Một số phần tôi thuê ngoài qua các dịch vụ như Stripe, nhưng
- vẫn có rất nhiều chỗ phải tự xử lý hoặc cần cá nhân hóa nên cuối cùng phải tự xây

Định giá thực sự rất khó

Nếu giá quá cao, kỳ vọng sẽ tăng lên hoặc người dùng ngần ngại đăng ký ngay từ đầu
Nếu giá quá thấp, có những người trả $9 nhưng lại đòi sửa toàn bộ ứng dụng theo ý họ
Cách giải quyết:
- hoàn tiền và để những khách hàng khó tính đó rời đi
- tăng giá lên và bước tiếp
- đặc biệt ở giai đoạn đầu khi đang mở rộng tính năng, việc thử nghiệm giá liên tục là bắt buộc

Đừng chỉ ám ảnh với MRR

MRR (Monthly Recurring Revenue) có thể là một chỉ số không phù hợp để đo hiệu quả kinh doanh
Vì những gì bạn làm vài tuần hoặc vài tháng trước ảnh hưởng đến MRR hiện tại, nên rất khó đo hiệu quả theo thời gian thực
Với một số sản phẩm SaaS, từ lúc người dùng đăng ký đến lúc thanh toán thực tế có thể mất hơn 60 ngày
Vì vậy cần dùng các chỉ số khác để biết sản phẩm có thực sự được sử dụng và có tạo ra giá trị hay không
- Ví dụ: số ảnh được tạo, số form được gửi, tức là các chỉ số thành công dựa trên hành vi

Đừng bao giờ cung cấp “unlimited”

Sẽ luôn có whale customer tận dụng “unlimited” tới mức tối đa
Ví dụ: có khách chỉ trả $250/tháng nhưng dùng lượng tài nguyên khổng lồ
Nếu đơn vị bạn cung cấp theo kiểu unlimited là thứ phát sinh chi phí, thì chắc chắn bạn sẽ lỗ
Lời khuyên này cũng áp dụng cho lifetime deal
- Nếu hứa cho dùng trọn đời với giá $100, bạn có thể sẽ phải nhận các yêu cầu thêm tính năng trong nhiều năm tiếp theo
- Nếu bán qua marketplace bên thứ ba, thậm chí bạn có thể chỉ nhận được 30% số tiền đó
Rốt cuộc, bạn đang mời gọi những người không phải khách hàng thật sự, mà là những người muốn lợi ích ngắn hạn và sẽ gắn chặt với bạn rất lâu

Với tài nguyên trả phí, nhất định phải áp dụng rate limit

Nếu bạn dùng các API mất phí như AI, SMS, gửi email, thì giới hạn mức sử dụng là bắt buộc
“Họ là khách trả phí thì dùng unlimited cũng được chứ?” → có thể có ngoại lệ, nhưng
- trong đa số trường hợp, điều đó sẽ dẫn tới hóa đơn chi phí khổng lồ hoặc bị vendor gắn nhãn spam
Ví dụ thực tế:
- một server host hàng trăm website WordPress bị lỗi do thiếu RAM
- kết quả là hàng nghìn cảnh báo SMS bị gửi tự động, tạo ra chi phí lớn
Nếu là khách hàng thực sự cần dùng khối lượng lớn, họ sẽ chủ động liên hệ với bạn

Đừng cố giải thích mọi thứ trong một trang

> “Nếu bạn cố nói mọi thứ với tất cả mọi người, thì rốt cuộc bạn sẽ chẳng truyền đạt được gì với bất kỳ ai”

Câu này đặc biệt đúng với copywriting cho landing page
Mỗi khi OnlineOrNot có thêm tính năng, tôi lại tiếp tục thêm mô tả vào landing page chính, và kết quả là
- thông điệp trở nên rối rắm và người dùng cũng hiểu kém hơn
- ví dụ: thông báo Slack là tính năng thứ hai tôi xây, nhưng rất nhiều người thậm chí không biết nó tồn tại
Giải pháp: tạo landing page riêng cho từng tính năng
- Trang chính: https://onlineornot.com/
- Uptime monitoring: https://onlineornot.com/website-monitoring
- API monitoring: https://onlineornot.com/api-monitoring
- Status pages: https://onlineornot.com/status-pages
- Cron job monitoring: https://onlineornot.com/cron-job-monitoring
Mỗi trang đều có đủ không gian để truyền đạt tính năng một cách rõ ràng

Tăng traffic là việc khó, còn cải thiện conversion rate thì có thể làm ngay bây giờ

Được internet chú ý là một cuộc chơi dài hạn và rất chậm
- kể cả khi liên tục làm content marketing chất lượng, cũng có thể mất nhiều tháng đến nhiều năm để từ 1–2 lượt truy cập tăng lên hàng trăm
Bản thân việc tăng traffic không hề dễ
Ngược lại, hành vi của những người đã vào rồi thì có thể thay đổi ngay lập tức
- ví dụ như thêm tùy chọn đăng nhập OAuth vào form đăng ký, những cải thiện có thể triển khai ngay hôm nay sẽ giúp tăng conversion rate

Đối thủ không quan trọng đến vậy

Lý do gần như không nói nhiều về đối thủ trong suốt bài viết này là vì họ thực sự không ảnh hưởng quá lớn
Tất nhiên, bạn vẫn phải có những tính năng cơ bản để được khách hàng đưa vào danh sách cân nhắc, nhưng
- đối thủ thật sự là việc người dùng thậm chí còn không biết sản phẩm này tồn tại
Quan trọng hơn tính năng chính là độ nhận biết và khả năng tiếp cận

4 bình luận

thenewseason 2025-04-22

Ở góc độ vận hành dịch vụ, tôi thấy đồng cảm với rất nhiều điều.
Bản thân tôi cũng từng cắt giảm thời gian ngủ để phát triển sản phẩm, và sức khỏe đã xấu đi..

Điều tôi muốn hỏi những người từng có trải nghiệm tương tự là, liệu kiểu đầu tư thời gian này có khả thi khi đang nuôi con hay không.
Vì thời gian đi làm và đi về, thời gian ở công ty, cùng thời gian ở nhà với con cái đã chiếm gần như toàn bộ một ngày, nên để tạo ra và vận hành một dịch vụ như vậy thì sẽ phải từ bỏ một điều gì đó khác, và tôi hy vọng đó không phải là gia đình hay sức khỏe..

tsboard 2025-04-15

Đúng là một bài viết có rất nhiều điều để học hỏi. Dành ra 2 tiếng mỗi sáng để vừa viết bài vừa hoàn thành nhiều dự án khác nhau nữa chứ...!

ethanhur 2025-04-14

Đây là một bài viết có nhiều điều để học hỏi. Cuối cùng, không được quên rằng ngay cả SaaS cũng là một sản phẩm được khách hàng thuê để giải quyết vấn đề.

xguru 2025-04-14

Những điều tôi học được sau 1 năm tự mình vận hành SaaS
Đã 3 năm trôi qua rồi nhỉ haha. Hãy vừa so sánh những gì đã thay đổi vừa đọc nhé!