Mở đầu — vì sao bài này quan trọng
Là một Product Owner ở cấp độ PSPO II, bạn không còn chỉ ngồi sắp xếp Product Backlog hay viết User Story nữa. Bạn ngày càng phải đứng trước những quyết định mang tính chiến lược về cách sản phẩm được tạo ra: liệu đội ngũ kỹ thuật của bạn nên tự xây (Build) một tính năng từ đầu, mua một giải pháp có sẵn (Buy), hay bắt tay với một bên thứ ba để cùng cung cấp (Partner)?
Đây là một trong những loại quyết định có sức ảnh hưởng lớn nhất mà một PO tham gia, vì nó định đoạt cách bạn tiêu tiền, tiêu thời gian và tiêu năng lực hiếm hoi của đội. Một quyết định "Build" sai có thể khiến cả nhóm đốt 6 tháng để tự viết lại một thứ mà thị trường đã có giá 200 USD/tháng. Ngược lại, một quyết định "Buy" sai có thể khiến bạn phụ thuộc vĩnh viễn vào một nhà cung cấp, đánh mất chính phần lõi tạo nên lợi thế cạnh tranh của sản phẩm.
Điều quan trọng cần hiểu: đây không phải quyết định thuần kỹ thuật để giao phó hoàn toàn cho Engineering, cũng không phải quyết định thuần tài chính để giao cho phòng mua sắm. Nó là quyết định sản phẩm — và PO là người phải dẫn dắt khung tư duy, bởi chỉ PO mới giữ được cái nhìn xuyên suốt giữa giá trị khách hàng, chiến lược sản phẩm và năng lực đội ngũ. Bài này trang bị cho bạn một khung quyết định rõ ràng để không còn quyết định theo cảm tính hay theo người nói to nhất trong phòng họp.
Khái niệm cốt lõi
Ba lựa chọn, ba bản chất khác nhau
Build (Tự xây) nghĩa là đội của bạn tự thiết kế, viết code và vận hành giải pháp. Bạn sở hữu hoàn toàn mã nguồn, dữ liệu, lộ trình phát triển. Đổi lại, bạn gánh toàn bộ chi phí phát triển ban đầu và chi phí bảo trì dài hạn.
Buy (Mua) nghĩa là bạn mua hoặc thuê (license/SaaS) một sản phẩm đã có sẵn trên thị trường và tích hợp vào hệ thống của mình. Ví dụ điển hình: dùng Stripe cho thanh toán, dùng Twilio/Stringee cho SMS, dùng Algolia cho tìm kiếm. Bạn đổi tiền lấy tốc độ và sự ổn định, nhưng nhường quyền kiểm soát lộ trình cho nhà cung cấp.
Partner (Hợp tác) nằm ở giữa: bạn cùng một bên thứ ba xây dựng hoặc cung cấp một phần giải pháp, thường qua hợp đồng chia sẻ doanh thu, tích hợp sâu, hoặc co-development. Khác với Buy ở chỗ Partner thường mang tính hai chiều và chiến lược — cả hai bên cùng có "skin in the game", cùng được lợi khi sản phẩm thành công.
Trục quyết định quan trọng nhất: đây có phải lợi thế cạnh tranh cốt lõi không?
Khung tư duy gốc của cả ngành xoay quanh một câu hỏi duy nhất, mượn ý từ Geoffrey Moore: phân biệt giữa hoạt động "core" (lõi) và "context" (bối cảnh).
- Core là phần tạo ra sự khác biệt, là lý do khách hàng chọn bạn thay vì đối thủ. Đây là "moat" — hào nước bảo vệ lâu đài của bạn.
- Context là mọi thứ cần thiết để vận hành nhưng không khiến khách hàng yêu bạn hơn. Khách hàng coi đó là điều đương nhiên (table stakes).
Lý do sâu xa là về phân bổ năng lực hiếm. Đội kỹ thuật giỏi là tài nguyên khan hiếm nhất của bạn. Mỗi giờ họ dành để tự viết lại một hệ thống gửi email (context) là một giờ họ không dành cho thuật toán gợi ý sản phẩm độc quyền của bạn (core). Tự xây phần context không tạo lợi thế — nó chỉ tạo ảo giác kiểm soát và một đống nợ kỹ thuật phải nuôi suốt đời.
Bảng khung quyết định
| Yếu tố | Nghiêng về Build | Nghiêng về Buy | Nghiêng về Partner |
|---|---|---|---|
| Có phải lợi thế cạnh tranh cốt lõi (moat)? | Có — đây là phần khác biệt hóa | Không — đây là context | Một phần, nhưng thiếu năng lực |
| Năng lực đội có sẵn không? | Có chuyên môn vững | Thiếu chuyên môn, tốn năm để có | Đối tác có chuyên môn ta thiếu |
| Áp lực thời gian ra thị trường (T2M) | Có thể chờ | Cần nhanh, mua là chạy ngay | Cần nhanh và cần cả mạng lưới của đối tác |
| Yêu cầu tùy biến/độc đáo | Rất cao, không giải pháp sẵn nào hợp | Nhu cầu chuẩn, giải pháp sẵn đáp ứng 80%+ | Cần tùy biến nhưng không muốn tự gánh |
| Chi phí tổng (TCO) dài hạn | Chấp nhận chi phí vận hành dài | Tổng chi phí license rẻ hơn tự nuôi | Chia sẻ chi phí và rủi ro |
| Rủi ro phụ thuộc (lock-in) | Không phụ thuộc ai | Chấp nhận phụ thuộc nhà cung cấp | Phụ thuộc lẫn nhau, có ràng buộc HĐ |
| Quy mô & độ chín thị trường | Thị trường non, chưa có giải pháp tốt | Thị trường chín, nhiều lựa chọn tốt | Cần kênh phân phối/khách hàng của đối tác |
TCO — Total Cost of Ownership, cái bẫy lớn nhất
Sai lầm phổ biến nhất khi so sánh là chỉ nhìn chi phí ban đầu. Khi tính chi phí Build, người ta hay quên: chi phí bảo trì, vá lỗi bảo mật, nâng cấp khi thư viện cũ ngừng hỗ trợ, chi phí cơ hội của đội kỹ thuật, và rủi ro khi người viết hệ thống đó nghỉ việc. Một hệ thống tự xây không bao giờ "xong" — nó là một con thú phải nuôi ăn mãi mãi. Khi so sánh, hãy luôn tính TCO trên một khung thời gian 3 năm, không phải chi phí của sprint đầu tiên.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán thanh toán (Buy, rồi Build có chọn lọc)
Hãy hình dung một sàn thương mại điện tử lớn ở Việt Nam như Tiki trong giai đoạn tăng trưởng nóng. Khi cần xử lý thanh toán, đội sản phẩm đứng trước lựa chọn: tự xây cổng thanh toán (Build) hay tích hợp các cổng có sẵn như VNPay, MoMo, ZaloPay (Buy/Partner).
Tự xây một cổng thanh toán đạt chuẩn bảo mật PCI-DSS, kết nối hàng chục ngân hàng, xử lý đối soát là một dự án khổng lồ — dễ tốn 18-24 tháng và một đội chuyên trách hàng chục người. Quan trọng hơn: khách hàng mua hàng trên Tiki không vì cổng thanh toán riêng của Tiki đẹp hơn. Thanh toán là context — phải có, phải mượt, nhưng không phải moat. Vì vậy quyết định đúng là tích hợp các nhà cung cấp có sẵn (Buy/Partner), để đội tập trung vào cái thực sự là core: logistics, tốc độ giao TikiNOW, và trải nghiệm tìm kiếm sản phẩm.
Nhưng có một lớp tinh tế: phần điều phối thanh toán (payment orchestration) — tức logic quyết định định tuyến giao dịch qua cổng nào để tối ưu tỷ lệ thành công và phí — thì đáng để tự xây, vì nó ảnh hưởng trực tiếp tới tỷ lệ chuyển đổi và biên lợi nhuận.
Bài học: Đừng quyết định Build/Buy cho cả một khối lớn. Hãy "xẻ" bài toán thành các lớp, và áp khung core/context cho từng lớp. Mua phần hạ tầng, tự xây phần mỏng tạo khác biệt nằm trên cùng.
Ví dụ 2 — Một startup SaaS B2B tự xây hệ thống xác thực (quyết định Build sai)
Một startup SaaS Việt làm phần mềm quản lý nhân sự cho doanh nghiệp vừa và nhỏ. Đội kỹ thuật 8 người. Khi xây sản phẩm, một bạn kỹ sư senior đề xuất tự viết hệ thống đăng nhập, phân quyền, single sign-on (SSO), quên mật khẩu, xác thực hai lớp — vì "không muốn phụ thuộc bên thứ ba" và "tự viết thì kiểm soát được".
Họ dành khoảng 3 tháng-người (~150 triệu đồng chi phí lương) để xây dựng. Sáu tháng sau, một lỗ hổng bảo mật trong cơ chế reset mật khẩu suýt làm lộ dữ liệu khách. Khi một khách hàng doanh nghiệp lớn yêu cầu SSO chuẩn SAML, đội phải bỏ thêm 2 tháng nữa. Trong khi đó, một giải pháp Buy như Auth0 hay AWS Cognito có thể đáp ứng tất cả với chi phí vài trăm USD/tháng và tích hợp trong vài ngày.
Vấn đề cốt lõi: xác thực người dùng là context kinh điển. Không một khách hàng nào chọn phần mềm HR vì cơ chế đăng nhập của nó. Tiền và thời gian đó lẽ ra nên đổ vào tính năng tính lương tự động theo luật lao động Việt Nam — thứ thực sự là moat với khách hàng nội địa.
Bài học: "Không muốn phụ thuộc bên thứ ba" và "muốn kiểm soát" là những cái bẫy cảm xúc, không phải lập luận chiến lược. Hãy hỏi: phần này có làm khách hàng chọn ta không? Nếu không, đừng tiêu năng lực hiếm vào đó.
Ví dụ 3 — Grab và Partner để vào thị trường thanh toán (Partner)
Khi Grab muốn mở rộng sang dịch vụ tài chính tại Việt Nam, họ không tự xin giấy phép ví điện tử từ đầu — một quá trình pháp lý dài và rủi ro — mà chọn Partner với Moca (một ví điện tử đã có giấy phép) trước khi tích hợp sâu thành GrabPay by Moca.
Đây là ví dụ kinh điển vì sao Partner tồn tại như một lựa chọn riêng. Build (tự xin giấy phép, xây hạ tầng ví) thì quá chậm và đầy rủi ro pháp lý. Buy thuần (chỉ mua dịch vụ) thì không giải quyết được vấn đề giấy phép và mối quan hệ với ngân hàng. Partner cho phép Grab tận dụng giấy phép, quan hệ ngân hàng và năng lực tuân thủ của Moca, đổi lại Moca có được lượng người dùng khổng lồ từ hệ sinh thái Grab. Cả hai bên đều có "skin in the game".
Bài học: Khi rào cản không phải là tiền hay code mà là giấy phép, quan hệ, kênh phân phối hoặc một năng lực ta không thể mua đứt, thì Partner thường là con đường nhanh và khôn ngoan nhất. Partner đặc biệt mạnh khi yếu tố thời gian ra thị trường (Time to Market) là sống còn.
Hướng dẫn từng bước
Khi đứng trước một quyết định Build vs Buy vs Partner, hãy đi theo trình tự sau:
- Định nghĩa rõ vấn đề và kết quả mong muốn (outcome). Trước khi hỏi "xây hay mua", hãy chắc chắn bạn hiểu mình đang giải bài toán gì cho khách hàng. Đừng quyết định giải pháp khi chưa rõ vấn đề.
- Phân loại core hay context. Hỏi thẳng: phần này có phải lý do khách hàng chọn ta không? Nó có nằm trong chiến lược và Product Goal không? Đây là bước có trọng số lớn nhất. Nếu là core thật sự — nghiêng mạnh về Build.
- "Xẻ" bài toán thành các lớp. Hiếm khi cả một khối nên cùng một quyết định. Tách phần hạ tầng (context) khỏi phần mỏng tạo khác biệt (core). Mua phần dưới, tự xây phần trên.
- Đánh giá năng lực đội thực tế. Đội có chuyên môn để xây và duy trì phần này dài hạn không? Năng lực không chỉ là viết được lần đầu, mà là nuôi được trong 3 năm.
- Khảo sát thị trường giải pháp. Có sản phẩm Buy nào đáp ứng được 80%+ nhu cầu không? Đối tác tiềm năng nào mạnh ở chỗ ta yếu? Đừng quyết định Build khi chưa thực sự tìm hiểu thị trường.
- Tính TCO trên 3 năm cho từng phương án. Với Build, cộng cả chi phí bảo trì, bảo mật, chi phí cơ hội. Với Buy, cộng cả phí license tăng theo quy mô và chi phí tích hợp/di chuyển. Với Partner, tính cả phần chia sẻ doanh thu.
- Đánh giá rủi ro lock-in và lối thoát. Nếu Buy/Partner, ta có thể đổi nhà cung cấp không? Dữ liệu có lấy ra được không? Đảm bảo luôn có đường lui.
- Đề xuất và ghi lại quyết định kèm lý do. Viết một bản ghi ngắn (decision record): chọn gì, vì sao, giả định nào, điều kiện nào sẽ khiến ta xem lại quyết định. Điều này cực kỳ quý khi nhìn lại sau 1 năm.
Lỗi thường gặp & mẹo
Lỗi 1 — "Not Invented Here" syndrome. Khuynh hướng của kỹ sư là muốn tự xây mọi thứ vì cho rằng tự xây thì tốt hơn, kiểm soát hơn. Hãy tôn trọng đam mê đó nhưng kéo cuộc tranh luận về câu hỏi chiến lược: phần này có là core không?
Lỗi 2 — Chỉ so sánh chi phí ban đầu. Build luôn trông rẻ ở sprint đầu và đắt khủng khiếp ở năm thứ hai, thứ ba. Luôn so sánh bằng TCO 3 năm.
Lỗi 3 — Build cái context vì "rồi sau này sẽ cần tùy biến". Đây là lập luận đầu cơ tương lai. Đa số tùy biến tưởng tượng đó không bao giờ xảy ra. Hãy giải bài toán của hôm nay; khi nhu cầu tùy biến thật sự xuất hiện và đủ lớn, lúc đó hãy xem lại quyết định.
Lỗi 4 — Buy mà không có lối thoát. Khóa chặt vào một nhà cung cấp không có khả năng di chuyển dữ liệu là tự đặt mình vào thế bị động về giá và lộ trình. Luôn hỏi về data portability và chi phí chuyển đổi trước khi ký.
Lỗi 5 — Nhầm Partner với Buy. Partner thật sự cần cả hai bên có lợi ích gắn kết. Nếu chỉ là trả tiền lấy dịch vụ một chiều, đó là Buy — đừng gọi nó là "đối tác chiến lược" để rồi kỳ vọng sai.
Mẹo: Khi mua một giải pháp context, hãy bọc nó sau một lớp trừu tượng (abstraction layer/adapter) trong kiến trúc của bạn. Điều này giúp việc thay nhà cung cấp sau này rẻ hơn nhiều, và biến quyết định Buy thành một quyết định có thể đảo ngược.
Mẹo: Coi mọi quyết định Buy/Partner như một giả thuyết có thể kiểm chứng. Bắt đầu nhỏ, thử nghiệm tích hợp với một phần lưu lượng trước khi cam kết toàn bộ.
Bài tập thực hành
Bài tập 1 — Phân loại core/context. Lấy chính sản phẩm bạn đang làm. Liệt kê 8-10 thành phần lớn (ví dụ: tìm kiếm, thanh toán, đăng nhập, gợi ý sản phẩm, gửi thông báo, báo cáo...). Với mỗi thành phần, đánh dấu core hay context, kèm một câu lý do "khách hàng có chọn ta vì cái này không?". Bạn sẽ ngạc nhiên khi thấy bao nhiêu thứ đội đang tự xây thực ra là context.
Bài tập 2 — Dựng bảng so sánh TCO. Chọn một tính năng sắp tới mà đội đang phân vân Build hay Buy. Dựng bảng TCO 3 năm cho cả hai phương án, gồm: chi phí phát triển ban đầu, chi phí bảo trì hằng năm, chi phí license/đối tác, và một dòng "chi phí cơ hội" (đội sẽ không làm được gì khác nếu chọn Build). So sánh con số cuối cùng.
Bài tập 3 — Viết Decision Record. Dựa trên hai bài trên, viết một bản ghi quyết định dài nửa trang cho một tính năng cụ thể: chọn Build/Buy/Partner, ba lý do chính, giả định quan trọng, và "điều kiện sẽ khiến tôi xem lại quyết định này". Mang bản này ra thảo luận với một kỹ sư senior để kiểm chứng lập luận.
Tóm tắt
Build vs Buy vs Partner là một quyết định sản phẩm mang tính chiến lược mà PSPO II PO phải dẫn dắt, không phó mặc cho kỹ thuật hay tài chính. Trục quyết định quan trọng nhất là phân biệt core (phần tạo lợi thế cạnh tranh, đáng để Build) và context (phần cần có nhưng không khác biệt hóa, nên Buy hoặc Partner). Hãy "xẻ" bài toán thành các lớp thay vì quyết định cho cả khối, luôn so sánh bằng TCO 3 năm chứ không phải chi phí ban đầu, và đề phòng các cái bẫy cảm xúc như "không muốn phụ thuộc" hay "Not Invented Here". Partner là lựa chọn mạnh khi rào cản là giấy phép, quan hệ hoặc kênh phân phối, và khi thời gian ra thị trường là sống còn. Cuối cùng, hãy giữ mọi quyết định Buy/Partner có đường lui: bọc sau lớp trừu tượng, đảm bảo lấy được dữ liệu ra, và ghi lại lý do để tương lai còn xem xét lại được.