Bài 22 — Build vs Buy vs Partner

Mở đầu — vì sao bài này quan trọng

Là một product leader, bạn sẽ liên tục đối mặt với một câu hỏi tưởng đơn giản nhưng quyết định sống còn: "Năng lực này, công cụ này, mảng tính năng này — chúng ta nên tự xây (Build), mua/thuê (Buy), hay bắt tay với đối tác (Partner)?"

Đây không phải câu hỏi kỹ thuật. Đây là câu hỏi chiến lược về nơi bạn đặt vốn, thời gian và tài năng đắt giá nhất của tổ chức. Một quyết định Build sai có thể đốt 18 tháng và hàng chục kỹ sư vào một thứ mà thị trường đã có sẵn với giá vài nghìn đô một tháng. Một quyết định Buy sai có thể khoá bạn vào một nhà cung cấp mà sau này trở thành điểm nghẽn cạnh tranh. Một quyết định Partner sai có thể khiến đối thủ chính của bạn nắm được chính cái "ruột" sản phẩm bạn dựa vào.

Điều khiến bài này quan trọng với một senior leader — chứ không phải một PM thông thường — là: bạn phải biện minh được lựa chọn này trước ban lãnh đạo, trước hội đồng quản trị, và trước chính đội ngũ của mình. Bạn không thể nói "tôi thấy tự làm hay hơn". Bạn phải có một khung quyết định rõ ràng, lặp lại được, và đứng vững dưới áp lực. Đó chính là thứ bài này trao cho bạn.

Khái niệm cốt lõi

Ba lựa chọn — và bản chất thật của chúng

Build (Tự xây): Bạn dùng chính đội ngũ của mình để tạo ra năng lực đó từ đầu. Bạn sở hữu hoàn toàn mã nguồn, dữ liệu, lộ trình và trải nghiệm. Đổi lại, bạn gánh toàn bộ chi phí phát triển và chi phí vận hành, bảo trì, nâng cấp trong suốt vòng đời.

Buy (Mua/Thuê): Bạn trả tiền cho một giải pháp có sẵn — thường là SaaS, license phần mềm, hoặc một module thương mại. Bạn đổi tiền lấy tốc độ và sự chắc chắn. Đổi lại, bạn chấp nhận sản phẩm không được "may đo" hoàn hảo, và bạn phụ thuộc vào lộ trình của nhà cung cấp.

Partner (Hợp tác): Bạn liên minh với một bên thứ ba để cùng tạo ra giá trị — qua tích hợp sâu, chia sẻ doanh thu, white-label, hoặc co-development. Đây là vùng xám giữa Build và Buy: bạn không sở hữu, nhưng cũng không chỉ là khách hàng. Bạn có đòn bẩy nhưng cũng có ràng buộc.

Khung quyết định nền tảng

Hãy bắt đầu từ bảng mà ghi chú gốc của bài đã mở ra, và mở rộng đầy đủ:

Bốn trục đánh giá mà senior leader phải cân

Đừng quyết định bằng cảm tính. Hãy chấm điểm mỗi lựa chọn trên bốn trục:

• Tính chiến lược (Strategic differentiation): Năng lực này có phải là lý do khách hàng chọn ta không? Nếu có — nghiêng về Build. Nếu không — đừng phí tài năng kỹ sư giỏi nhất vào đó. Đây là trục quan trọng nhất. Quy tắc của Marc Andreessen và nhiều người khác gói gọn: "Build what differentiates you, buy what doesn't."

• Năng lực thực thi (Capability & capacity): Đội bạn có thật sự làm được không, và làm được mà không hy sinh các ưu tiên khác? Nhiều leader đánh giá quá cao năng lực của đội mình và quá thấp độ phức tạp của thứ họ định xây.

• Thời gian ra thị trường (Time-to-market): Mỗi tháng chậm trễ có chi phí cơ hội. Buy/Partner thường nhanh hơn Build nhiều lần.

• Tổng chi phí sở hữu (Total Cost of Ownership): Đây là chỗ leader hay sai nhất. Chi phí Build không chỉ là chi phí xây lần đầu. Nó gồm cả bảo trì, on-call, vá lỗi bảo mật, nâng cấp, và chi phí cơ hội của việc đội ngũ không làm việc khác. Một quy tắc kinh nghiệm: chi phí vận hành dài hạn thường gấp 2–4 lần chi phí xây ban đầu.

"Build vs Buy" không phải quyết định một lần — nó là quyết định theo thời gian

Một điểm tinh tế mà senior leader cần nắm: lựa chọn đúng hôm nay có thể sai vào năm sau. Bạn có thể Buy để vào thị trường nhanh, rồi Build khi nó trở thành lợi thế cốt lõi. Hoặc ngược lại, bạn tự xây một thứ vì lúc đó chưa có giải pháp, rồi chuyển sang Buy khi thị trường trưởng thành để giải phóng đội ngũ. Quyết định này nên được xem xét lại định kỳ, không phải khắc vào đá.

Tình huống thực tế

Tình huống 1 — Một ví Việt Nam và bài toán định danh eKYC (Build vs Buy)

Hãy hình dung một ví điện tử Việt Nam đang tăng trưởng nhanh, gọi là "ViPay" (giả định). Để mở tài khoản, người dùng phải qua bước eKYC — xác thực danh tính bằng chụp CCCD và đối chiếu khuôn mặt. Đội product đứng trước câu hỏi: tự xây engine nhận dạng giấy tờ và đối chiếu khuôn mặt, hay mua từ một nhà cung cấp như VNPT, FPT.AI, hay một vendor quốc tế?

CPO của ViPay chấm điểm theo bốn trục. Về tính chiến lược: người dùng không chọn ViPay vì công nghệ eKYC — họ chọn vì ví dễ dùng, nhiều ưu đãi, liên kết ngân hàng tốt. eKYC là điều kiện cần, không phải điểm khác biệt. Về năng lực: xây OCR tiếng Việt và face-matching đạt chuẩn ngân hàng nhà nước cần đội ML chuyên sâu mà ViPay không có. Về thời gian: tự xây mất ít nhất 9–12 tháng để đạt độ chính xác chấp nhận được. Về TCO: mua eKYC API rơi vào khoảng vài trăm đồng tới vài nghìn đồng mỗi lượt xác thực — rẻ hơn nhiều so với nuôi một đội ML.

Kết luận: Buy. ViPay tích hợp API eKYC của một vendor nội địa, lên thị trường sau 6 tuần thay vì gần một năm.

Bài học rút ra: Đừng để cái cám dỗ "kỹ thuật hay" che mất câu hỏi chiến lược. eKYC khó và "ngầu" về mặt kỹ thuật, nhưng nó không phải thứ khách hàng chọn bạn vì nó. Tài năng kỹ sư giỏi nhất của ViPay nên dồn vào trải nghiệm thanh toán — chỗ thật sự tạo khác biệt.

Tình huống 2 — Shopee và logistics: từ Partner đến Build (Partner → Build)

Khi các sàn TMĐT lớn vào Đông Nam Á, không ai tự xây mạng lưới giao hàng ngay từ đầu — điều đó là bất khả thi về vốn và thời gian. Họ Partner: bắt tay với các đơn vị vận chuyển bên thứ ba (3PL) như GHN, GHTK, J&T, Viettel Post để giao hàng. Đây là lựa chọn đúng ở giai đoạn đầu: logistics cần mạng lưới vật lý khổng lồ mà một sàn non trẻ không thể tái tạo nhanh.

Nhưng khi quy mô đơn hàng tăng theo cấp số nhân, hai vấn đề lộ ra. Thứ nhất, giao hàng trở thành một phần cốt lõi của trải nghiệm — thời gian giao, khả năng theo dõi đơn, chi phí ship là thứ khách hàng cảm nhận trực tiếp và là điểm cạnh tranh. Thứ hai, phụ thuộc hoàn toàn vào 3PL bên ngoài khiến sàn mất kiểm soát chất lượng và chi phí. Vì thế các sàn lớn dần Build năng lực logistics nội bộ (ví dụ mô hình Shopee Express) — vừa tự vận hành một phần, vừa giữ đối tác cho phần còn lại.

Bài học rút ra: Đây là minh hoạ kinh điển cho việc quyết định Build/Buy/Partner dịch chuyển theo thời gian. Khi một năng lực đi từ "điều kiện cần" sang "lợi thế cạnh tranh cốt lõi" và đạt quy mô đủ lớn để tự vận hành hiệu quả, đó là lúc cân nhắc chuyển từ Partner sang Build. Một senior leader giỏi không cố định lựa chọn — họ đặt lịch xem xét lại.

Tình huống 3 — Một startup SaaS B2B và bài toán xác thực đăng nhập (Partner/Buy, không Build)

Một startup SaaS B2B Việt Nam phục vụ doanh nghiệp lớn cần tính năng đăng nhập một lần (SSO) và phân quyền tích hợp với hệ thống của khách hàng (SAML, OAuth, Active Directory). Đội kỹ sư rất giỏi và muốn tự xây — họ tự tin làm được.

CPO can thiệp với một câu hỏi đơn giản: "Nếu ta tự xây auth, mỗi khi có một CVE bảo mật mới về SAML, ai trực để vá trong đêm? Và khách hàng có chọn ta vì hệ thống auth của ta không?" Câu trả lời cho cả hai đều bất lợi cho Build. Auth là mảng commodity nhưng rủi ro cao — sai một lỗi bảo mật là mất khách hàng doanh nghiệp ngay lập tức. Họ chọn tích hợp một nền tảng identity chuyên dụng (kiểu Auth0/WorkOS): nhà cung cấp gánh toàn bộ gánh nặng tuân thủ, bảo mật, và cập nhật chuẩn mới.

Chi phí: vài nghìn đô một tháng. So với chi phí một đội tự xây và duy trì auth cấp doanh nghiệp — rẻ hơn nhiều lần, và quan trọng hơn, an toàn hơn nhiều.

Bài học rút ra: Có những mảng mà Build sai không chỉ vì tốn kém, mà vì rủi ro vận hành dài hạn quá lớn so với giá trị khác biệt nó tạo ra. "Đội tôi làm được" không phải lý do để Build. Câu hỏi đúng là "đội tôi nên dồn sức vào đây không?".

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng cho bất kỳ quyết định Build/Buy/Partner nào:

Bước 1 — Xác định rõ năng lực đang bàn. Viết một câu mô tả chính xác bạn cần gì. Không phải "ta cần làm AI", mà "ta cần phân loại ticket hỗ trợ khách thành 8 nhóm với độ chính xác >85%". Phạm vi mơ hồ là gốc rễ của quyết định sai.

Bước 2 — Trả lời câu hỏi chiến lược trước tiên. Năng lực này có phải lý do khách hàng chọn ta không? Nó có tạo lợi thế cạnh tranh phòng thủ được (defensible moat) không? Nếu có → thiên về Build. Nếu không → loại Build khỏi bàn cân ngay, trừ khi có lý do đặc biệt.

Bước 3 — Khảo sát thị trường giải pháp. Có vendor nào đủ tốt không? Họ trưởng thành đến đâu? Khoá nhà cung cấp (vendor lock-in) ra sao? Có đối tác nào sẵn sàng tích hợp sâu/chia sẻ doanh thu không? Nếu thị trường trống → Build có thể là lựa chọn duy nhất.

Bước 4 — Đánh giá trung thực năng lực và năng lực dư của đội. Đội có kỹ năng không, và quan trọng hơn, có thời gian rảnh không? Build thứ này nghĩa là không làm gì khác? Hãy hỏi cả engineering leadership, đừng tự trả lời một mình.

Bước 5 — Tính TCO 3 năm cho từng phương án. Với Build: chi phí xây + vận hành + bảo trì + chi phí cơ hội. Với Buy: phí license + tích hợp + rủi ro tăng giá. Với Partner: chi phí tích hợp + chia sẻ doanh thu + rủi ro phụ thuộc. Quy ra con số, đừng so sánh cảm tính.

Bước 6 — Chấm điểm trên ma trận và ra quyết định có điều kiện. Tổng hợp bốn trục, ra quyết định, và viết kèm điều kiện xem xét lại: "Buy hôm nay; xem xét chuyển Build nếu chi phí vendor vượt X hoặc nếu mảng này trở thành differentiator."

Bước 7 — Ghi lại quyết định và truyền đạt. Viết một trang one-pager nêu rõ lựa chọn, lý do, và điều kiện đảo ngược. Đây là tài liệu bạn dùng để báo cáo lên trên và để đội ngũ đồng thuận.

Lỗi thường gặp & mẹo

Lỗi 1 — Hội chứng "Not Invented Here". Đội kỹ sư mặc định muốn tự xây vì nó thú vị và họ tự tin. Senior leader phải tách mong muốn khỏi lợi ích kinh doanh. Mẹo: luôn buộc đội trình bày phương án Buy/Partner một cách công bằng trước khi chốt Build.

Lỗi 2 — Đánh giá thấp chi phí vận hành dài hạn. Người ta hay chỉ tính chi phí xây lần đầu rồi quên rằng phần mềm cần nuôi suốt đời. Mẹo: luôn nhân chi phí xây ước tính với hệ số vận hành (2–4 lần) khi so sánh.

Lỗi 3 — Build cái commodity, Buy cái differentiator. Đây là sai lầm đảo ngược chí mạng: tự xây thứ ai cũng có (như auth, email, billing cơ bản) trong khi lại đi mua/outsource chính cái tạo nên lợi thế cạnh tranh. Mẹo: vẽ bản đồ năng lực, tô màu cái nào là "core" — chỉ Build phần lõi đỏ.

Lỗi 4 — Quên rủi ro Partner với đối thủ. Khi Partner, hãy hỏi: đối tác này có thể trở thành đối thủ không? Họ có nắm dữ liệu/khách hàng của ta không? Mẹo: trong hợp đồng partnership, làm rõ quyền sở hữu dữ liệu và điều khoản thoát (exit clause).

Lỗi 5 — Coi đây là quyết định một lần. Mẹo: gắn mỗi quyết định lớn với một lịch xem xét lại (review trigger) — theo thời gian hoặc theo cột mốc doanh thu/quy mô.

Mẹo tổng quát: Khi phân vân giữa Build và Buy ở giai đoạn sớm, hãy ưu tiên Buy/Partner để học nhanh về nhu cầu thực, rồi Build sau khi đã chắc đây là mảng đáng đầu tư. Tốc độ học thường quan trọng hơn quyền sở hữu ở giai đoạn đầu.

Bài tập thực hành

• Lập bản đồ năng lực: Liệt kê 8–10 năng lực/tính năng chính trong sản phẩm của bạn. Với mỗi cái, phân loại thành "Core differentiator" (khách chọn ta vì nó) hay "Commodity" (điều kiện cần). Bạn đang Build hay Buy mỗi cái? Có cái nào Build sai chỗ không?

• Tính TCO một quyết định: Chọn một năng lực bạn đang cân nhắc Build. Lập bảng so sánh TCO 3 năm giữa Build, Buy, và Partner — gồm cả chi phí cơ hội của đội ngũ. Con số nói gì?

• Viết one-pager quyết định: Cho một trường hợp thật trong công ty bạn, viết một trang gồm: năng lực cần, câu trả lời chiến lược, ba phương án, lựa chọn cuối, và điều kiện đảo ngược quyết định.

• Phân tích một Partner→Build: Tìm một ví dụ trong ngành của bạn (hoặc dùng Shopee Express) nơi một công ty chuyển từ Partner sang Build. Đâu là dấu hiệu cho thấy đã đến lúc chuyển? Bạn có dấu hiệu tương tự trong sản phẩm mình không?

Tóm tắt

• Build / Buy / Partner là quyết định chiến lược về phân bổ nguồn lực, không phải quyết định kỹ thuật. Nó định nghĩa nơi bạn đặt tài năng đắt giá nhất.
• Build khi đó là lợi thế cạnh tranh cốt lõi và bạn có năng lực. Buy khi đó là commodity và tốc độ/chi phí quan trọng hơn khác biệt. Partner khi cần nhanh và sâu nhưng không thể (hoặc không nên) tự xây.
• Đánh giá trên bốn trục: tính chiến lược, năng lực thực thi, thời gian ra thị trường, và tổng chi phí sở hữu (TCO) — trong đó tính chiến lược là trục quyết định nhất.
• Quy tắc vàng: Build what differentiates you, buy what doesn't. Đừng phí kỹ sư giỏi nhất vào commodity; đừng outsource chính cái moat của bạn.
• Đây không phải quyết định một lần — hãy đặt lịch xem xét lại. Mảng có thể đi từ Partner sang Build khi nó trở thành cốt lõi và đạt quy mô (như logistics của các sàn TMĐT).
• Tránh năm cái bẫy: hội chứng "Not Invented Here", đánh giá thấp chi phí vận hành, Build/Buy đảo ngược chiến lược, quên rủi ro đối tác, và coi quyết định là vĩnh viễn.