Mở đầu — vì sao bài này quan trọng
Có một loại quyết định mà bạn sẽ gặp đi gặp lại trong suốt sự nghiệp Technical PM, và mỗi lần gặp đều khiến cả phòng họp căng thẳng: chúng ta tự xây (build) hay đi mua (buy)? Tự viết hệ thống thanh toán hay tích hợp Stripe? Tự dựng search engine hay mua Algolia? Tự làm CDP (Customer Data Platform) hay ký hợp đồng với một vendor? Tự xây dựng hệ thống gửi email hay dùng SendGrid?
Đây không phải là quyết định kỹ thuật thuần túy — và đó chính là lý do nó rơi vào tay PM chứ không phải chỉ riêng kỹ sư. Một kỹ sư giỏi có xu hướng muốn build, vì build thì thú vị, kiểm soát được, và "có vẻ không khó". Một CFO có xu hướng muốn buy nếu giá rẻ hơn lương kỹ sư. Còn bạn — Technical PM — là người duy nhất ở vị trí có thể nhìn cả ba chiều: giá trị kinh doanh, năng lực kỹ thuật, và chi phí dài hạn.
Quyết định sai ở đây không gây sập sản phẩm ngay, nhưng nó âm thầm bào mòn công ty trong nhiều năm. Build nhầm một thứ đáng lẽ nên mua, bạn đốt 6 tháng của 3 kỹ sư giỏi vào một bài toán đã được giải xong từ lâu. Buy nhầm một thứ đáng lẽ phải build, bạn trao đi chính cái lợi thế cạnh tranh (moat) khiến công ty bạn khác biệt. Bài này cho bạn một khung tư duy (framework) để ra quyết định này một cách có kỷ luật, thay vì dựa vào cảm tính hay người nói to nhất trong phòng họp.
Khái niệm cốt lõi
Build vs Buy về bản chất là câu hỏi về phân bổ nguồn lực khan hiếm. Nguồn lực khan hiếm nhất của một công ty công nghệ không phải là tiền — mà là thời gian và sự tập trung của đội kỹ sư. Mỗi thứ bạn quyết định tự build là một thứ bạn quyết định KHÔNG làm chỗ khác. Đây là khái niệm "opportunity cost" (chi phí cơ hội) mà bạn phải khắc vào đầu.
Câu hỏi 1: Đây có phải core competency không?
Đây là câu hỏi quan trọng nhất và phải hỏi đầu tiên. Tính năng này có phải là thứ tạo nên lợi thế cạnh tranh — cái "moat" — của sản phẩm bạn không, hay nó chỉ là một thứ tiện ích phổ thông (commodity) mà ai cũng cần và ai cũng có?
- Nếu nó là moat / differentiation: nghiêng về build. Đây là chỗ bạn không được phép phụ thuộc vào người khác, vì chính nó là lý do khách hàng chọn bạn.
- Nếu nó là commodity: nghiêng về buy. Việc tự build một thứ phổ thông không mang lại lợi thế nào, chỉ tốn nguồn lực.
Câu hỏi 2: Time-to-market — bạn cần ship nhanh đến mức nào?
Nếu cửa sổ thị trường đang mở và đối thủ đang chạy, sáu tháng tự build có thể đồng nghĩa với việc bạn ra mắt khi cuộc chơi đã kết thúc. Buy cho phép bạn ship trong vài tuần. Ngược lại, nếu đây là nền tảng dài hạn và không có áp lực thời gian gấp gáp, build có thể đáng đầu tư.
Một quy tắc hữu ích: nếu giải pháp mua sẵn giúp bạn validate (kiểm chứng) ý tưởng nhanh, hãy buy trước để học, rồi build sau khi đã chắc chắn về nhu cầu. Đừng build một thứ mà bạn còn chưa biết khách hàng có cần hay không.
Câu hỏi 3: Total Cost of Ownership (TCO) — chi phí thực sự là bao nhiêu?
Đây là chỗ hầu hết mọi người tính sai. Chi phí build KHÔNG phải chỉ là lương kỹ sư trong giai đoạn xây dựng. Nó bao gồm:
- Chi phí xây dựng ban đầu (lương nhân sự × thời gian).
- Chi phí bảo trì vĩnh viễn: sửa bug, vá lỗ hổng bảo mật, nâng cấp, trực vận hành. Phần này thường lớn hơn chi phí build ban đầu và kéo dài mãi mãi.
- Chi phí cơ hội: những tính năng tạo doanh thu mà đội kỹ sư KHÔNG làm vì đang bận bảo trì thứ tự build.
Câu hỏi 4: Mức độ tùy biến và kiểm soát
Giải pháp mua sẵn có đáp ứng được 80% nhu cầu không? Nếu có và 20% còn lại không quan trọng, hãy buy. Nhưng nếu nhu cầu của bạn quá đặc thù — về tuân thủ pháp lý, về luồng nghiệp vụ riêng, về tích hợp sâu — thì giải pháp mua sẵn sẽ liên tục cản trở bạn, và bạn sẽ tốn nhiều công "uốn" sản phẩm cho vừa với công cụ.
Một lựa chọn thứ ba: Buy-then-Build (hoặc Adopt)
Đừng quên rằng đây không phải lựa chọn nhị phân tuyệt đối. Có những con đường ở giữa: dùng mã nguồn mở (open source) rồi tự vận hành và tùy biến; mua nền tảng rồi build phần riêng lên trên; hoặc bắt đầu bằng buy để validate rồi build khi đã đạt quy mô đủ lớn để tự build rẻ hơn.
Tình huống thực tế
Tình huống 1: Một sàn TMĐT Việt Nam và bài toán Search
Hãy hình dung một sàn thương mại điện tử cỡ vừa tại Việt Nam, gọi là "ChợViệt", có khoảng 500.000 sản phẩm. Ban đầu họ dùng tính năng full-text search có sẵn của database (MySQL). Khi catalog lớn lên, tìm kiếm trở nên chậm và kết quả không liên quan — gõ "áo thun nam" mà ra cả áo nữ. Tỷ lệ chuyển đổi (conversion) từ tìm kiếm tụt thấy rõ.
Đội đứng trước hai lựa chọn: build một search engine riêng dựa trên Elasticsearch (tự host, tự tune), hay buy một dịch vụ như Algolia.
PM đặt bốn câu hỏi. Core competency? Tìm kiếm sản phẩm ở giai đoạn này là yếu tố sống còn cho trải nghiệm, nhưng thuật toán xếp hạng cơ bản thì chưa phải moat độc nhất của họ — họ chưa có dữ liệu hành vi đủ giàu để làm ranking thông minh hơn đối thủ. Time-to-market? Mùa sale lớn còn 3 tháng, phải có search tốt trước đó. TCO? Tự dựng Elasticsearch cần ít nhất 2 kỹ sư trong 2-3 tháng cộng chi phí vận hành cluster mãi về sau. Algolia tính theo số lượt search, ước tính khoảng vài nghìn USD/tháng ở quy mô hiện tại.
Quyết định: buy Algolia trước, để kịp mùa sale và giải phóng kỹ sư làm việc khác. Họ đặt một mốc tái đánh giá: nếu chi phí Algolia vượt một ngưỡng nhất định khi quy mô tăng, hoặc khi họ tích lũy đủ dữ liệu để build ranking riêng thành lợi thế, họ sẽ chuyển sang tự build.
Bài học: quyết định build/buy không phải vĩnh viễn. "Buy bây giờ để học và để nhanh, build sau khi quy mô và moat đã rõ" là một chiến lược hoàn toàn hợp lý — miễn là bạn đặt sẵn điều kiện kích hoạt việc tái đánh giá.
Tình huống 2: Fintech và hệ thống chấm điểm tín dụng
Một startup fintech cho vay tiêu dùng ở Đông Nam Á phải quyết định: dùng mô hình chấm điểm tín dụng (credit scoring) của một bên thứ ba, hay tự xây dựng mô hình riêng dựa trên dữ liệu của chính mình.
Áp khung tư duy: đây có phải core competency không? Câu trả lời là CÓ, tuyệt đối. Toàn bộ mô hình kinh doanh của họ phụ thuộc vào việc cho đúng người vay và từ chối đúng người rủi ro. Khả năng đánh giá rủi ro tốt hơn đối thủ — đặc biệt với nhóm khách hàng "thin file" chưa có lịch sử tín dụng tại ngân hàng truyền thống — chính là moat. Nếu họ buy mô hình của bên thứ ba, họ sẽ chấm điểm giống hệt mọi đối thủ dùng cùng nhà cung cấp đó, và không có lợi thế nào.
Quyết định: build, dù tốn kém và chậm. Nhưng họ làm thông minh: ở giai đoạn đầu, khi chưa có đủ dữ liệu để train mô hình tốt, họ tạm dùng quy tắc đơn giản kết hợp với dữ liệu mua ngoài, vừa cho vay vừa thu thập dữ liệu. Sau 12-18 tháng tích lũy dữ liệu thực, họ build mô hình riêng và nó trở thành tài sản cạnh tranh.
Bài học: với thứ thuộc về moat, gần như luôn phải build — kể cả khi đắt và chậm hơn. Và "build" không có nghĩa là build hoàn hảo ngay từ ngày đầu; bạn có thể dùng giải pháp tạm để khởi động trong khi xây dựng năng lực cốt lõi.
Tình huống 3: Tự dựng hệ thống gửi email transactional
Một SaaS B2B tại Việt Nam cần gửi email giao dịch (xác nhận đăng ký, đặt lại mật khẩu, hóa đơn). Một kỹ sư trong đội rất hào hứng tự dựng mail server riêng vì "tiết kiệm được phí SendGrid" và "không khó".
PM dừng lại và hỏi: gửi email có phải core competency của một SaaS B2B không? Tuyệt đối không — đây là commodity điển hình. Tự dựng mail server đồng nghĩa với việc bạn phải lo về deliverability (làm sao email không rơi vào spam), quản lý reputation của IP, tuân thủ SPF/DKIM/DMARC, xử lý bounce, và canh chừng bị blacklist — một lĩnh vực sâu mà các nhà cung cấp chuyên biệt đã đầu tư hàng năm trời. Phí SendGrid ở quy mô của họ chỉ vài chục USD/tháng, rẻ hơn nhiều so với một ngày công kỹ sư.
Quyết định: buy, không bàn cãi.
Bài học: cảnh giác với cái bẫy "không khó, tự làm cho rẻ". Sự hào hứng kỹ thuật của kỹ sư là tốt, nhưng việc của PM là hỏi: thời gian này nếu dồn vào tính năng cốt lõi thì tạo ra bao nhiêu giá trị? Phần "ẩn" của việc build (vận hành, deliverability, tuân thủ) thường lớn hơn nhiều so với phần "thú vị" mà kỹ sư nhìn thấy ban đầu.
Hướng dẫn từng bước
Khi bạn đối mặt với một quyết định build vs buy, hãy đi theo trình tự sau:
Bước 1 — Định nghĩa rõ bài toán và nhu cầu thực sự. Viết ra chính xác bạn cần giải quyết vấn đề gì, cho ai, và "đủ tốt" trông như thế nào. Phân biệt nhu cầu thật với mong muốn. Nhiều quyết định build sai bắt nguồn từ việc liệt kê một danh sách yêu cầu dài quá mức cần thiết, khiến không giải pháp mua sẵn nào "vừa".
Bước 2 — Trả lời câu hỏi core competency trước tiên. Đây là bộ lọc đầu tiên. Nếu là moat, mặc định nghiêng về build. Nếu là commodity, mặc định nghiêng về buy. Đa số quyết định được định hình ngay ở bước này.
Bước 3 — Khảo sát thị trường giải pháp mua sẵn. Trước khi quyết định build, hãy thực sự tìm hiểu: có sản phẩm nào đáp ứng được không? Nó đáp ứng bao nhiêu phần trăm nhu cầu? Giá ở quy mô hiện tại và quy mô tương lai là bao nhiêu? Đừng giả định "không có gì hợp" mà chưa tìm kỹ.
Bước 4 — Tính TCO cho cả hai phương án trong 3 năm. Với build: chi phí nhân sự xây dựng + chi phí bảo trì hàng năm + chi phí vận hành hạ tầng. Với buy: phí license + phí tích hợp + phí mở rộng theo quy mô. Quan trọng: cộng thêm chi phí cơ hội của việc build vào cột build.
Bước 5 — Đánh giá các yếu tố rủi ro phi tài chính. Vendor lock-in, độ ổn định của nhà cung cấp, khả năng tùy biến, tuân thủ pháp lý (ví dụ Nghị định 13 về bảo vệ dữ liệu cá nhân nếu vendor xử lý dữ liệu khách hàng), và rủi ro vận hành nếu tự build.
Bước 6 — Cân nhắc con đường lai. Có thể buy để validate rồi build sau? Có thể dùng open source tự host? Có thể build phần lõi và buy phần ngoại vi?
Bước 7 — Ra quyết định, ghi lại lý do, và đặt điểm tái đánh giá. Viết quyết định cùng các giả định vào một tài liệu ngắn. Đặt sẵn điều kiện kích hoạt việc xem lại (ví dụ: "khi chi phí vendor vượt X, hoặc khi đạt Y người dùng"). Quyết định build/buy nên được xem lại định kỳ, không phải đóng đinh một lần.
Lỗi thường gặp & mẹo
Lỗi 1 — Tính chi phí build chỉ bằng lương kỹ sư giai đoạn xây dựng. Đây là sai lầm phổ biến nhất. Chi phí bảo trì vĩnh viễn và chi phí cơ hội thường lớn hơn chi phí xây dựng ban đầu rất nhiều. Mẹo: luôn hỏi "ai sẽ bảo trì cái này trong 3 năm tới, và họ đáng lẽ đang làm gì khác?"
Lỗi 2 — Để cảm xúc kỹ thuật lấn át. "Not Invented Here syndrome" — xu hướng coi thường giải pháp của người khác và muốn tự làm — là cái bẫy với đội kỹ sư mạnh. Ngược lại, một số nơi lại mắc bệnh "buy everything" rồi đánh mất khả năng làm chủ công nghệ. Mẹo: tách bạch "thú vị về mặt kỹ thuật" khỏi "có giá trị về mặt kinh doanh".
Lỗi 3 — Quên chi phí tích hợp khi buy. Mua một công cụ tưởng nhanh, nhưng tích hợp nó vào hệ thống hiện có, migrate dữ liệu, và đào tạo đội có thể tốn nhiều tháng. Mẹo: hỏi các công ty khác đã tích hợp công cụ đó mất bao lâu thực tế.
Lỗi 4 — Bỏ qua vendor lock-in và rủi ro vendor. Buy một thứ cốt lõi từ một startup nhỏ có thể nguy hiểm nếu họ phá sản hoặc bị mua lại. Mẹo: với thứ quan trọng, ưu tiên vendor có khả năng export dữ liệu dễ dàng và có sẵn phương án thay thế.
Lỗi 5 — Coi quyết định là vĩnh viễn. Bối cảnh thay đổi: quy mô tăng, giá vendor đổi, năng lực đội thay đổi. Một quyết định buy đúng ở năm 1 có thể sai ở năm 3. Mẹo: luôn đặt điểm tái đánh giá.
Mẹo tổng quát: khi phân vân, hãy ưu tiên buy cho mọi thứ KHÔNG phải core, và dành toàn bộ năng lực build cho thứ thực sự tạo nên lợi thế cạnh tranh. Phần lớn công ty nên build ít hơn họ tưởng.
Bài tập thực hành
Bài tập 1 — Phân loại core vs commodity. Lấy sản phẩm bạn đang làm (hoặc một sản phẩm bạn quen thuộc). Liệt kê 8-10 thành phần kỹ thuật chính (ví dụ: hệ thống thanh toán, search, recommendation, gửi thông báo, phân tích dữ liệu, xác thực người dùng...). Với mỗi thành phần, đánh dấu nó là "core/moat" hay "commodity", và viết một câu giải thích. Bạn sẽ ngạc nhiên khi thấy phần lớn rơi vào commodity.
Bài tập 2 — Tính TCO 3 năm. Chọn một thành phần bạn đánh dấu là "có thể buy" ở bài 1. Lập một bảng so sánh đơn giản: cột build (chi phí xây dựng + bảo trì × 3 năm + chi phí cơ hội), cột buy (phí license + tích hợp + mở rộng × 3 năm). Dùng con số ước lượng hợp lý. Phương án nào rẻ hơn, và con số có khiến bạn bất ngờ không?
Bài tập 3 — Viết một quyết định. Soạn một tài liệu một trang cho một quyết định build/buy giả định: nêu bài toán, trả lời bốn câu hỏi cốt lõi, đưa ra quyết định kèm lý do, liệt kê các giả định, và xác định điểm tái đánh giá. Đây chính là dạng tài liệu bạn sẽ trình bày trong phòng họp thực tế.
Tóm tắt
Build vs Buy là quyết định về phân bổ nguồn lực khan hiếm nhất — thời gian và sự tập trung của đội kỹ sư — chứ không đơn thuần là so sánh giá. Hãy bắt đầu bằng câu hỏi quan trọng nhất: đây có phải core competency tạo nên moat không? Nếu là moat, nghiêng về build; nếu là commodity, nghiêng về buy. Sau đó cân nhắc time-to-market, tính TCO trọn vòng đời (bao gồm bảo trì vĩnh viễn và chi phí cơ hội — phần mà hầu hết mọi người tính thiếu), và đánh giá các rủi ro phi tài chính như vendor lock-in và tuân thủ pháp lý.
Đừng coi đây là lựa chọn nhị phân hay vĩnh viễn: buy để validate rồi build sau, hay dùng giải pháp tạm trong khi xây năng lực cốt lõi, đều là chiến lược hợp lý. Cảnh giác với cái bẫy "tự làm cho rẻ" của sự hào hứng kỹ thuật, và nhớ rằng phần lớn công ty nên build ít hơn họ tưởng. Việc của bạn — Technical PM — là người duy nhất nhìn được cả ba chiều kinh doanh, kỹ thuật và chi phí, và đưa ra quyết định có kỷ luật thay vì theo cảm tính.