Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được thăng chức làm Growth PM tại một startup fintech ở TP.HCM. Đội ngũ của bạn đang chạy khoảng 5 thí nghiệm A/B mỗi tháng, nhưng mọi thứ vẫn đang được "chắp vá": logic phân nhóm người dùng nằm rải rác trong code, kết quả được tính tay trên Google Sheets, và mỗi lần muốn biết một thí nghiệm có ý nghĩa thống kê hay không thì phải nhờ một anh data analyst chạy query thủ công. Đến một ngày, CEO hỏi bạn: "Mình nên tự xây một hệ thống thí nghiệm riêng, hay đi mua của bên thứ ba?"
Đây là một trong những quyết định hạ tầng (infrastructure decision) quan trọng nhất mà một tổ chức làm growth phải đối mặt. Nó không đơn thuần là câu hỏi kỹ thuật, mà là quyết định chiến lược ảnh hưởng đến tốc độ học hỏi của cả công ty trong 2-3 năm tới. Chọn sai có thể khiến bạn đốt 6-12 tháng engineering vào một thứ mà lẽ ra chỉ cần trả vài nghìn đô mỗi tháng là có ngay; hoặc ngược lại, khóa chặt công ty vào một vendor đắt đỏ và cứng nhắc khi bạn lẽ ra cần sự linh hoạt tối đa.
Trong các bài sau (Bài 21-25), chúng ta sẽ đi sâu vào từng nền tảng cụ thể như LaunchDarkly, Statsig, Eppo, GrowthBook. Còn bài này tập trung vào khung tư duy ra quyết định: làm sao để bạn — với tư cách Growth PM — đánh giá đúng đắn nên build (tự xây) hay buy (đi mua), và làm sao trình bày quyết định đó một cách thuyết phục với cả engineering lẫn ban lãnh đạo.
Khái niệm cốt lõi
Một experimentation platform thật ra gồm những gì?
Trước khi quyết định build hay buy, bạn phải hiểu rõ mình đang nói về cái gì. Một nền tảng thí nghiệm hoàn chỉnh không chỉ là "công cụ bật/tắt A/B test". Nó gồm nhiều lớp:
- Feature flagging / assignment: cơ chế quyết định người dùng nào vào nhóm nào (control hay variant), đảm bảo phân bổ ngẫu nhiên, ổn định (một người luôn thấy cùng một phiên bản), và có thể nhắm mục tiêu theo phân khúc.
- SDK và tích hợp: thư viện nhúng vào web, mobile, backend để đọc trạng thái flag và ghi nhận sự kiện (events).
- Event tracking / data pipeline: thu thập dữ liệu hành vi, gắn với danh tính người dùng và nhóm thí nghiệm.
- Statistics engine: bộ tính toán ý nghĩa thống kê — tính p-value, confidence interval, sample size, xử lý các vấn đề như peeking, CUPED (giảm phương sai)...
- Reporting / dashboard: giao diện để PM, designer, analyst đọc kết quả mà không cần biết code.
- Governance: quản lý vòng đời thí nghiệm, lưu trữ kết quả, phân quyền, audit.
Build — ưu điểm
Tùy biến hoàn toàn theo stack của bạn. Nếu công ty bạn có kiến trúc dữ liệu đặc thù — ví dụ một sàn TMĐT với mô hình marketplace phức tạp, nơi một thí nghiệm phải tính đến cả phía người mua lẫn người bán (network effects) — thì một nền tảng đóng gói sẵn có thể không mô hình hóa được. Tự build cho bạn quyền kiểm soát từng dòng logic.
Không bị vendor lock-in. Dữ liệu thí nghiệm là tài sản chiến lược. Khi tự build, dữ liệu nằm trong data warehouse của bạn (BigQuery, Snowflake...), bạn không phụ thuộc vào định dạng, giá cả hay sự tồn tại của một công ty bên ngoài.
Rẻ hơn ở quy mô lớn. Đây là lý do then chốt khiến các gã khổng lồ như Booking.com, Airbnb, Microsoft đều tự xây. Khi bạn chạy hàng nghìn thí nghiệm đồng thời với hàng trăm triệu người dùng, chi phí license tính theo MTU (monthly tracked users) hoặc theo số sự kiện của vendor sẽ trở nên khổng lồ — có thể lên đến hàng triệu đô một năm. Ở quy mô đó, một đội platform nội bộ trở nên rẻ hơn nhiều.
Build — nhược điểm
Tốn 6-12 tháng để có engine đầu tiên. Và đó chỉ là phiên bản tối thiểu. Một statistics engine đúng đắn — xử lý được sequential testing, variance reduction, sample ratio mismatch — cần kiến thức chuyên sâu mà hầu hết đội ngũ không có sẵn.
Chi phí bảo trì vĩnh viễn. Build không phải là dự án "làm xong rồi thôi". Bạn cần một đội (thường 3-8 kỹ sư + data scientist) duy trì, sửa lỗi, nâng cấp mãi mãi. Đây là chi phí cơ hội rất lớn: những kỹ sư đó lẽ ra có thể làm tính năng tạo ra doanh thu.
Rủi ro về tính đúng đắn thống kê. Một bug trong engine tính p-value có thể khiến công ty ra quyết định sai trong nhiều tháng mà không ai biết. Vendor chuyên nghiệp đã có hàng nghìn khách hàng "test hộ" độ chính xác của họ.
Buy — ưu điểm
Có ngay trong vài tuần. Bạn ký hợp đồng, tích hợp SDK, và chạy thí nghiệm đầu tiên trong vòng một tháng. Tốc độ time-to-value cực nhanh.
Best practices được tích hợp sẵn. Các nền tảng hiện đại (Statsig, Eppo) đã nhúng sẵn các phương pháp tiên tiến: CUPED, sequential testing, automated sanity checks. Bạn được hưởng trí tuệ của cả ngành mà không cần tự nghĩ ra.
Có người chịu trách nhiệm. Khi engine sai, có một công ty với đội ngũ PhD thống kê để bạn gọi điện. Trách nhiệm về độ chính xác được chuyển sang vendor.
Buy — nhược điểm
Chi phí leo thang theo quy mô. Giá thường tăng theo lượng người dùng/sự kiện. Một startup nhỏ trả vài nghìn đô, nhưng khi scale lên có thể thành vài trăm nghìn đô/năm.
Vendor lock-in và giới hạn linh hoạt. Bạn bị ràng buộc vào mô hình dữ liệu, định dạng, và roadmap của họ. Nếu cần một loại phân tích đặc thù mà họ không hỗ trợ, bạn phải chờ hoặc không bao giờ có được.
Lo ngại về dữ liệu. Với fintech hay y tế ở Việt Nam, việc gửi dữ liệu hành vi người dùng sang server nước ngoài có thể vướng vấn đề tuân thủ (compliance) theo Nghị định về bảo vệ dữ liệu cá nhân.
Con đường thứ ba: Hybrid và Open-source
Đừng nghĩ build/buy là lựa chọn nhị phân. Có một dải phổ ở giữa:
- Buy lớp khó, build lớp dễ: dùng vendor cho statistics engine nhưng tự viết logic assignment để tích hợp sâu vào hệ thống.
- Warehouse-native tools (như Eppo, GrowthBook): công cụ chạy phân tích ngay trên data warehouse của bạn — dữ liệu không rời khỏi nhà bạn, nhưng phần thống kê và dashboard do vendor lo. Đây là điểm cân bằng rất hấp dẫn về cả lock-in lẫn compliance.
- Open-source (như GrowthBook): bạn "buy" về mặt không phải viết từ đầu, nhưng "build" về mặt tự host, tự kiểm soát. Phù hợp khi bạn có đội kỹ thuật giỏi nhưng ngân sách hạn chế.
Tình huống thực tế
Ví dụ 1 — Startup SaaS B2B ở Hà Nội: chọn Buy là quyết định đúng
Một startup SaaS quản lý nhân sự với khoảng 40 nhân viên, trong đó có 12 kỹ sư, đang phục vụ 8.000 doanh nghiệp khách hàng. CTO ban đầu rất muốn tự build vì "feature flag thì có gì khó, làm một tuần là xong". Growth PM đã ngồi lại làm một bài toán đơn giản:
- Tự build MVP feature flag: ~3 tuần (đúng như CTO nói).
- Nhưng statistics engine đúng đắn + dashboard cho PM/marketing đọc được: ước tính 4-6 tháng của 2 kỹ sư = khoảng 1,2 tỷ đồng chi phí nhân sự, chưa kể chi phí cơ hội của việc không làm tính năng sản phẩm.
- Mua một nền tảng warehouse-native: khoảng 1.000-1.500 USD/tháng ở quy mô hiện tại = ~400 triệu đồng/năm.
Ví dụ 2 — Booking.com: vì sao gã khổng lồ phải tự build
Booking.com nổi tiếng là tổ chức thí nghiệm bậc nhất thế giới, chạy hơn 1.000 thí nghiệm đồng thời tại mọi thời điểm (chúng ta sẽ phân tích sâu trường hợp này ở Bài 40). Ở quy mô đó, không một vendor nào trên thị trường đủ sức đáp ứng:
- Lượng sự kiện hàng tỷ mỗi ngày khiến chi phí license của vendor trở nên vô lý — dễ dàng vượt 5-10 triệu USD/năm.
- Họ cần thí nghiệm gắn chặt vào mọi ngóc ngách sản phẩm, với những loại phân tích đặc thù mà không công cụ đóng gói nào có.
- Văn hóa "mọi thay đổi đều phải qua thí nghiệm" đòi hỏi platform phải là một phần ADN kỹ thuật, không thể outsource.
Ví dụ 3 — Sàn TMĐT khu vực Đông Nam Á: con đường Hybrid
Một sàn TMĐT cỡ trung ở khu vực (khoảng 5 triệu người dùng hoạt động hàng tháng) gặp tình huống lưng chừng. Họ đã dùng một vendor SaaS được 2 năm, nhưng đụng hai vấn đề: chi phí license đã leo lên gần 300.000 USD/năm, và vendor không mô hình hóa được network effects giữa người mua - người bán trong các thí nghiệm về phí ship.
Thay vì build lại từ đầu, họ chọn con đường hybrid: giữ vendor cho phần feature flagging và assignment (phần ổn định, không cần tùy biến), nhưng chuyển toàn bộ phần phân tích thống kê sang chạy trên data warehouse nội bộ với một công cụ open-source. Nhờ vậy họ vừa kiểm soát được loại phân tích đặc thù, vừa cắt giảm đáng kể chi phí license, mà không phải tự viết engine assignment phức tạp.
Bài học rút ra: quyết định build vs buy không cố định mãi mãi. Nó nên được xem lại theo từng giai đoạn tăng trưởng. Cái đúng ở 100.000 người dùng có thể sai ở 5 triệu người dùng. Và bạn có thể build một phần, buy một phần — không nhất thiết phải all-in.
Hướng dẫn từng bước
Đây là khung 6 bước để bạn ra quyết định một cách có hệ thống, thay vì quyết theo cảm tính hay theo lời "build dễ lắm" của một kỹ sư hào hứng.
Bước 1 — Định lượng nhu cầu thí nghiệm hiện tại và 12 tháng tới. Bạn đang chạy bao nhiêu thí nghiệm/tháng? Sẽ là bao nhiêu trong một năm nữa? Dưới 10/tháng thì gần như chắc chắn nên buy. Trên 100/tháng thì cán cân bắt đầu nghiêng về build/hybrid.
Bước 2 — Liệt kê yêu cầu phải-có vs muốn-có. Phân biệt rõ "must-have" (ví dụ: dữ liệu phải nằm trong nước vì compliance) và "nice-to-have" (ví dụ: giao diện đẹp). Yêu cầu must-have sẽ loại bỏ nhanh nhiều lựa chọn.
Bước 3 — Tính tổng chi phí sở hữu (TCO) cho cả hai phương án trong 3 năm. Với build: lương đội ngũ × thời gian × hệ số bảo trì + chi phí cơ hội. Với buy: license theo lộ trình tăng trưởng + chi phí tích hợp. Hãy tính cho 3 năm, không phải 1 năm — vì chi phí build dồn về đầu, chi phí buy dồn về sau.
Bước 4 — Đánh giá năng lực đội ngũ một cách trung thực. Bạn có data scientist hiểu sequential testing và variance reduction không? Nếu không, build statistics engine là công thức dẫn đến kết quả sai mà không ai phát hiện.
Bước 5 — Xem xét con đường hybrid trước khi quyết all-in. Hỏi: phần nào thực sự cần tùy biến (thường là assignment hoặc loại phân tích đặc thù)? Phần nào là hàng hóa phổ thông có thể mua? Đa số tổ chức tìm được điểm cân bằng ở đây.
Bước 6 — Quyết định có điều kiện rút lui và mốc đánh giá lại. Đừng coi đây là quyết định một chiều. Đặt sẵn mốc: "Chúng ta dùng vendor X, và sẽ đánh giá lại khi đạt 1 triệu MTU hoặc khi license vượt 200.000 USD/năm." Điều này giúp tránh lock-in về tâm lý.
Lỗi thường gặp & mẹo
Lỗi 1 — Đánh giá thấp độ khó của statistics engine. Sai lầm phổ biến nhất. Feature flag thì dễ, nhưng làm thống kê đúng thì khó kinh khủng. Nhiều đội build xong một engine "trông có vẻ chạy" nhưng âm thầm tính sai ý nghĩa thống kê suốt nhiều tháng. Mẹo: nếu phải build, hãy chạy A/A test (Bài 36) liên tục để kiểm tra engine của bạn không tự "tìm ra" kết quả giả.
Lỗi 2 — So sánh chi phí build vs buy chỉ trong năm đầu. Build có vẻ "rẻ" vì bạn chỉ tính lương vài tháng. Nhưng chi phí bảo trì vĩnh viễn và chi phí cơ hội mới là phần lớn. Mẹo: luôn dùng TCO 3 năm.
Lỗi 3 — Để kỹ sư quyết định một mình vì "đây là vấn đề kỹ thuật". Đây là quyết định chiến lược về growth, không phải chỉ kỹ thuật. Kỹ sư thường thiên về build vì đó là việc thú vị. Growth PM phải là người đặt câu hỏi về chi phí cơ hội và tốc độ học hỏi của tổ chức.
Lỗi 4 — Quên yếu tố con người dùng platform. Một nền tảng mạnh về kỹ thuật nhưng PM, marketer, designer không tự đọc được kết quả thì vô dụng — mọi phân tích lại tắc ở data team. Mẹo: ưu tiên trải nghiệm self-service cho người không biết code.
Lỗi 5 — Bỏ qua compliance dữ liệu ở bối cảnh Việt Nam. Với fintech, y tế, hay khách hàng doanh nghiệp lớn, việc dữ liệu rời khỏi hạ tầng của bạn có thể là điểm chặn. Mẹo: ưu tiên các giải pháp warehouse-native hoặc self-hosted nếu compliance là must-have.
Bài tập thực hành
- Lập bảng TCO 3 năm. Chọn công ty bạn đang làm (hoặc một công ty giả định: startup edtech Việt Nam, 500.000 người dùng, 6 kỹ sư). Tính tổng chi phí build và buy trong 3 năm, gồm cả chi phí cơ hội của engineering. Kết luận của bạn nghiêng về đâu?
- Viết "must-have list". Liệt kê 5 yêu cầu phải-có cho platform thí nghiệm của tổ chức bạn, trong đó ít nhất 1 yêu cầu liên quan đến compliance dữ liệu. Yêu cầu nào sẽ loại bỏ phương án nào?
- Thiết kế quyết định hybrid. Giả sử bạn không được all-in build cũng không all-in buy. Hãy vẽ ra: phần nào bạn build, phần nào bạn buy, và lý do cho mỗi lựa chọn.
- Viết một đoạn 150 từ thuyết phục CEO. Đóng vai Growth PM, trình bày quyết định build/buy/hybrid của bạn cho CEO không rành kỹ thuật. Tập trung vào tốc độ học hỏi và chi phí cơ hội, không sa vào thuật ngữ.
Tóm tắt
Quyết định build vs buy cho experimentation platform là một quyết định chiến lược, không chỉ kỹ thuật, và nó định hình tốc độ học hỏi của cả tổ chức trong nhiều năm. Build cho bạn tùy biến hoàn toàn, không lock-in, và rẻ hơn ở quy mô cực lớn — nhưng tốn 6-12 tháng dựng engine, chi phí bảo trì vĩnh viễn, và rủi ro sai sót thống kê. Buy cho bạn time-to-value nhanh, best practices có sẵn, và có người chịu trách nhiệm — nhưng chi phí leo thang theo quy mô và ràng buộc bạn vào vendor.
Quy tắc thực dụng: phần lớn công ty Việt Nam ở giai đoạn đầu nên buy (hoặc dùng open-source self-hosted), vì chi phí cơ hội của engineering luôn cao hơn license. Chỉ những tổ chức ở quy mô rất lớn như Booking.com mới thực sự nên build. Và đừng quên con đường hybrid — build phần cần tùy biến, buy phần là hàng hóa phổ thông — thường là điểm cân bằng tốt nhất. Cuối cùng, hãy luôn coi đây là quyết định có thể xem lại theo từng giai đoạn tăng trưởng, với mốc đánh giá rõ ràng. Dùng TCO 3 năm, đánh giá trung thực năng lực đội ngũ, và đừng để một mình kỹ sư quyết định — vì đây là câu chuyện về tốc độ growth của cả công ty.