Mở đầu — vì sao bài này quan trọng
Nếu bạn từng viết PRD cho một sản phẩm tiêu dùng (B2C) và nghĩ rằng chỉ cần "copy công thức" đó sang một tính năng cho doanh nghiệp (B2B), thì bài này sẽ là một cú phanh gấp đáng giá. Tôi đã chứng kiến không ít PM giỏi viết spec rất chuẩn cho app gọi xe, app giao đồ ăn, nhưng khi chuyển sang làm tính năng cho một sản phẩm bán cho doanh nghiệp — kiểu phần mềm kế toán, CRM, HR, hay một nền tảng SaaS bán cho công ty — thì spec của họ "trượt" hàng loạt thứ mà sau này đội kỹ thuật và đội sales phải gánh chịu.
Lý do là vì B2B không phải B2C "to hơn". Nó là một thế giới với những ràng buộc khác về căn bản: người dùng không phải là người trả tiền, một tài khoản có thể có hàng nghìn người dùng với vai trò khác nhau, mỗi khách hàng lại muốn cấu hình riêng, và một câu hỏi của bộ phận pháp lý (legal) có thể giết chết cả tính năng trước khi nó kịp ship. Nếu spec của bạn không phản ánh được những thực tế này, bạn sẽ build ra một thứ "đúng kỹ thuật" nhưng "sai thị trường".
Bài này tập trung riêng vào những điểm đặc thù khi viết spec cho tính năng B2B/Enterprise — những thứ mà các bài khác trong khóa (về acceptance criteria, edge cases, permission, data schema...) sẽ không nhắc tới một cách có hệ thống. Sau bài này, bạn sẽ biết phải bổ sung những "lớp" nào vào PRD của mình khi đối tượng khách hàng là doanh nghiệp, chứ không phải người dùng cá nhân.
Khái niệm cốt lõi
1. User ≠ Buyer — người dùng không phải người mua
Đây là khác biệt nền tảng nhất. Trong B2C, người bấm nút "Mua" thường cũng chính là người dùng sản phẩm. Trong B2B, ba vai trò thường tách rời nhau:
- Buyer (người mua): thường là quản lý, giám đốc, người ký hợp đồng. Họ quan tâm ROI, chi phí, bảo mật, khả năng tích hợp.
- Admin (người quản trị): người cài đặt, cấu hình, phân quyền. Họ quan tâm việc setup có dễ không, quản lý người dùng có gọn không.
- End user (người dùng cuối): nhân viên thực sự dùng tính năng hằng ngày. Họ quan tâm trải nghiệm, tốc độ, có giúp họ làm việc nhanh hơn không.
2. Multi-tenancy — một sản phẩm, nhiều khách hàng cô lập
Sản phẩm B2B gần như luôn là multi-tenant: nhiều công ty (tenant) dùng chung một hệ thống nhưng dữ liệu phải cô lập tuyệt đối. Spec của bạn phải nói rõ:
- Tính năng này hoạt động ở phạm vi nào: toàn hệ thống, theo từng tenant, hay theo từng nhóm (team/workspace) bên trong tenant?
- Cấu hình của tenant A có rò rỉ sang tenant B không?
- Nếu có giới hạn (ví dụ "tối đa 50 dự án"), giới hạn đó áp theo tenant hay theo người dùng?
3. Roles & Permissions ở mức tổ chức (org-level)
B2C thường chỉ có "user" và "admin". B2B thì có cả một ma trận vai trò: Owner, Admin, Manager, Member, Guest, Billing-only... Spec phải đính kèm một bảng phân quyền (permission matrix): hàng là hành động, cột là vai trò, ô là Cho phép/Không. Bài về Permission & Auth Spec sẽ đi sâu kỹ thuật; ở đây bạn chỉ cần nhớ: với B2B, phần phân quyền không phải "phụ lục" mà là phần thân của spec.
4. Configurability — khách hàng muốn tùy biến
Doanh nghiệp ghét bị ép theo một cách làm cố định. Họ muốn bật/tắt tính năng, đổi nhãn, đặt quy tắc riêng. Spec B2B phải phân biệt rõ:
- Cái gì là hard-coded (cố định, mọi khách dùng như nhau).
- Cái gì là configurable (admin tự chỉnh trong giao diện).
- Cái gì là per-tenant customization cần đội triển khai làm tay (thường chỉ cho khách lớn).
5. Long sales cycle — chu kỳ bán dài và "feature signal"
Một thương vụ B2B có thể kéo dài 3–9 tháng. Trong quá trình đó, đội sales liên tục gặp câu hỏi "phần mềm của các anh có làm được X không?". Vì vậy mỗi tính năng B2B mang một tín hiệu bán hàng (sales signal): nó có giúp chốt deal, gỡ blocker, hay chỉ là "nice to have"? Spec nên có một dòng ghi rõ tính năng này gắn với deal nào, đối thủ nào, hay yêu cầu RFP nào — để team ưu tiên đúng.
6. Compliance, Security & Audit là bắt buộc, không phải tùy chọn
Khách doanh nghiệp, đặc biệt trong tài chính, y tế, viễn thông, sẽ hỏi về SOC 2, ISO 27001, GDPR, hoặc ở Việt Nam là Nghị định 13/2023 về bảo vệ dữ liệu cá nhân. Bất kỳ tính năng nào động đến dữ liệu người dùng đều cần phần spec về: ai xem được dữ liệu, lưu ở đâu, giữ bao lâu, và audit log (nhật ký ai-làm-gì-khi-nào). Đây là thứ B2C hiếm khi cần nhưng B2B gần như luôn cần.
7. SLA, hỗ trợ và migration
Khách hàng B2B trả tiền lớn nên kỳ vọng cam kết về uptime (SLA), kênh hỗ trợ riêng, và quan trọng nhất: khi bạn đổi tính năng, dữ liệu cũ của họ phải được di chuyển (migration) êm ái. Spec B2B phải luôn có mục "điều gì xảy ra với khách hàng hiện hữu" — không được bỏ ai lại phía sau.
Tình huống thực tế
Ví dụ 1 — Base.vn và tính năng phê duyệt đa cấp
Giả sử bạn là PM tại một nền tảng quản trị doanh nghiệp kiểu Base.vn, đang làm tính năng "Phê duyệt đề xuất chi phí". Ở bản B2C-thinking, bạn có thể viết: "Người dùng tạo đề xuất, quản lý bấm duyệt". Nhưng khách hàng thật là một chuỗi F&B 40 chi nhánh.
Khi spec qua tay đội sales và đội triển khai, hàng loạt câu hỏi nổ ra: Quy trình duyệt của chi nhánh có khác hội sở không? Đề xuất trên 50 triệu có cần thêm cấp duyệt của giám đốc tài chính không? Nếu người duyệt nghỉ phép thì ủy quyền cho ai? Kế toán có cần xem được toàn bộ lịch sử duyệt để đối soát không?
Bài học: tính năng tưởng đơn giản hóa ra cần luồng phê duyệt cấu hình được theo từng tenant (mỗi khách đặt ngưỡng và số cấp riêng), cần ủy quyền (delegation), và cần audit log đầy đủ. PM viết lại spec với permission matrix (Người tạo / Người duyệt cấp 1 / Người duyệt cấp 2 / Kế toán xem) và một bảng cấu hình ngưỡng theo tenant. Con số cụ thể: chỉ riêng việc bổ sung "duyệt đa cấp cấu hình được" đã giúp chốt được 3 deal chuỗi lớn mà trước đó sales phải từ chối vì "phần mềm chỉ duyệt 1 cấp".
Ví dụ 2 — Một startup SaaS HR ở Đông Nam Á và bài toán SSO
Một startup HR SaaS (giả định tên "PeopleHub", phục vụ thị trường Singapore và Việt Nam) có sản phẩm dùng tốt cho công ty 20–50 người, đăng nhập bằng email/mật khẩu. Khi họ tiếp cận một tập đoàn 2.000 nhân viên, bộ phận IT của khách hỏi ngay: "Các anh có hỗ trợ SSO qua Azure AD và SCIM để tự động cấp/thu hồi tài khoản không?".
Spec ban đầu của tính năng "đăng nhập" hoàn toàn không nhắc tới SSO hay SCIM, vì với khách nhỏ thì email/mật khẩu là đủ. PM nhận ra đây không phải edge case — đây là điều kiện cần để bán cho enterprise. Nếu nhân viên nghỉ việc mà tài khoản không tự động bị thu hồi, đó là lỗ hổng bảo mật mà IT không bao giờ chấp nhận.
Họ viết một spec riêng cho "Enterprise Authentication": hỗ trợ SAML/OIDC SSO, SCIM provisioning, và bật/tắt theo tenant. Quan trọng là họ đánh dấu rõ trong spec rằng đây là tính năng thuộc gói "Enterprise" — vừa giải bài toán kỹ thuật, vừa tạo cơ sở để bán gói cao hơn. Kết quả: deal 2.000 nhân viên (giá trị hợp đồng năm khoảng 180.000 USD) được mở khóa nhờ đúng một mục spec mà phiên bản B2C-thinking đã bỏ quên.
Ví dụ 3 — Tính năng xuất báo cáo và cái bẫy "một khách hàng đặc biệt"
Một công ty SaaS làm phần mềm quản lý kho cho các nhà phân phối. Một khách hàng lớn (chiếm 30% doanh thu) yêu cầu báo cáo tồn kho phải có thêm 4 cột riêng và xuất theo định dạng mà hệ thống ERP nội bộ của họ đọc được. Sales gật đầu ngay để giữ khách.
PM đứng trước cái bẫy kinh điển của B2B: build riêng cho một khách. Nếu spec ghi "thêm 4 cột cho khách X", thì sau này khách Y, Z mỗi người một kiểu, sản phẩm sẽ vỡ vụn thành hàng chục biến thể không thể bảo trì.
Cách PM xử lý: thay vì hard-code cho khách X, spec định nghĩa một cơ chế template báo cáo cấu hình được — admin tự chọn cột, tự đặt thứ tự, và chọn định dạng xuất (CSV/Excel/định dạng tùy biến). Khách X được phục vụ qua một template, nhưng tài sản tạo ra là một tính năng dùng được cho mọi khách. Bài học: với B2B, khi gặp yêu cầu cá biệt, nhiệm vụ của PM là trừu tượng hóa nó thành cấu hình, biến một đòi hỏi riêng lẻ thành năng lực sản phẩm chung — đồng thời ghi rõ trong spec ranh giới giữa "configurable cho mọi khách" và "tùy biến triển khai cho riêng khách lớn".
Hướng dẫn từng bước
Khi bắt tay viết spec cho một tính năng B2B/Enterprise, hãy đi qua các bước sau:
- Xác định các vai trò liên quan. Liệt kê buyer, admin, end user (và các vai trò con). Với mỗi vai trò, viết một câu: tính năng này tạo giá trị gì cho họ? Đây là phần bổ sung so với PRD B2C thông thường.
- Định vị tính năng trong chu kỳ bán. Ghi rõ: tính năng này là blocker để chốt deal, là lợi thế cạnh tranh, hay chỉ là cải thiện? Nếu được, gắn với deal/khách hàng cụ thể đang chờ. Điều này giúp ưu tiên và giúp leadership hiểu vì sao nên làm.
- Vẽ permission matrix. Lập bảng hành động × vai trò. Đánh dấu ô nào cho phép. Đây là phần thân, không phải phụ lục.
- Xác định phạm vi multi-tenancy. Tính năng chạy ở mức nào (hệ thống / tenant / team)? Cấu hình có cô lập giữa các tenant không? Giới hạn áp theo cấp nào?
- Phân loại tính năng: hard-coded / configurable / per-tenant custom. Vẽ rõ ranh giới. Mỗi thứ configurable đều có chi phí — chỉ mở những gì thật sự cần.
- Bổ sung lớp compliance, security & audit. Trả lời: dữ liệu lưu ở đâu, ai xem được, giữ bao lâu, có audit log không, có chạm tới yêu cầu pháp lý nào (Nghị định 13, GDPR, SOC 2) không?
- Spec phần migration & khách hàng hiện hữu. Điều gì xảy ra với khách đang dùng khi tính năng này lên? Dữ liệu cũ chuyển ra sao? Có cần thông báo trước, có cờ bật/tắt theo tenant không?
- Định nghĩa SLA & hỗ trợ liên quan. Tính năng có ảnh hưởng cam kết uptime không? Đội support cần biết gì để trả lời khách? (Phần readiness sẽ học kỹ ở bài Customer Support Readiness, nhưng B2B luôn cần nhắc tới ngay trong spec.)
- Gói hóa theo tier nếu phù hợp. Tính năng thuộc gói nào (Pro / Business / Enterprise)? Điều này gắn spec với chiến lược định giá.
Lỗi thường gặp & mẹo
- Viết spec như cho B2C. Quên mất buyer ≠ user, quên permission matrix, quên multi-tenancy. Mẹo: dùng một checklist B2B cố định (9 bước ở trên) và bắt buộc tự rà trước khi gửi review.
- Build riêng cho một khách hàng. Như ví dụ 3 — đây là con đường ngắn nhất tới một sản phẩm không thể bảo trì. Mẹo: mỗi khi nghe "khách X muốn riêng cái này", hãy hỏi "làm sao biến nó thành cấu hình cho mọi khách?".
- Over-configurability. Ngược lại với lỗi trên: mở quá nhiều tùy chọn cấu hình khiến chi phí build/test bùng nổ và giao diện admin rối loạn. Mẹo: chỉ mở configurable khi có ≥2 khách thật sự cần khác nhau; còn lại để hard-coded và mở dần sau.
- Bỏ quên compliance đến phút chót. Để legal/security review chen vào cuối cùng làm trễ cả launch. Mẹo: kéo họ vào từ giai đoạn spec, đặt sẵn mục "Compliance & Security" trong template.
- Không spec migration cho khách hiện hữu. Ship tính năng mới làm hỏng quy trình của khách đang trả tiền là cách nhanh nhất để mất hợp đồng. Mẹo: luôn có mục "Existing customers impact" và một chiến lược rollout theo tenant.
- Bỏ qua tín hiệu bán hàng. Làm tính năng "hay" nhưng không ai trong pipeline cần. Mẹo: trước khi viết spec, hỏi sales "deal nào đang chờ cái này?".
Bài tập thực hành
Chọn một tính năng B2B bất kỳ — ví dụ "Mời thành viên vào workspace" trong một SaaS quản lý dự án giả định phục vụ doanh nghiệp Việt Nam. Hãy viết một spec rút gọn (1–2 trang) bao gồm đầy đủ các lớp đặc thù B2B:
- Liệt kê 4 vai trò (Owner, Admin, Member, Guest) và một dòng giá trị cho mỗi vai trò.
- Vẽ permission matrix cho 5 hành động: mời thành viên, đổi vai trò, xóa thành viên, xem danh sách, sửa cài đặt workspace.
- Xác định phạm vi multi-tenancy: lời mời có cô lập theo tenant không? Có giới hạn số ghế (seats) theo gói không?
- Phân loại: phần nào hard-coded, phần nào admin cấu hình được (ví dụ: bật/tắt cho phép mời guest ngoài tổ chức).
- Viết mục "Compliance & Audit": cần ghi audit log những gì? Có ràng buộc nào theo Nghị định 13 khi mời người ngoài tổ chức không?
- Viết mục "Existing customers impact": với tenant đang có sẵn thành viên, tính năng mới ảnh hưởng gì?
- Thêm một dòng "Sales signal": deal/khách hàng nào đang cần tính năng này.
Tóm tắt
Spec cho tính năng B2B/Enterprise không phải là spec B2C "phóng to". Nó đòi hỏi bạn bổ sung những lớp mà B2C hiếm khi cần: tách bạch buyer–admin–end user, multi-tenancy, permission matrix ở mức tổ chức, ranh giới giữa hard-coded và configurable, lớp compliance–security–audit, chiến lược migration cho khách hiện hữu, và sự gắn kết với chu kỳ bán hàng dài. Hai cái bẫy lớn nhất là viết spec theo lối B2C và build riêng cho một khách hàng — cả hai đều khiến sản phẩm khó bảo trì và khó scale. Hãy ghi nhớ checklist 9 bước, luôn hỏi "tính năng này phục vụ vai trò nào và gỡ blocker cho deal nào", và biến mọi yêu cầu cá biệt thành năng lực cấu hình chung. Khi đó, spec của bạn không chỉ đúng kỹ thuật mà còn đúng thị trường — thứ giúp tính năng thật sự được khách doanh nghiệp mua và dùng.