Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm discovery cho một sản phẩm tiêu dùng (B2C) rồi chuyển sang B2B hoặc enterprise, bạn sẽ nhanh chóng nhận ra: gần như mọi giả định cũ của bạn đều sai. Trong B2C, người dùng và người trả tiền thường là một. Bạn phỏng vấn 10 người dùng, bạn hiểu khá rõ vấn đề. Còn trong B2B, người dùng sản phẩm có khi không bao giờ là người quyết định mua, và người ký hợp đồng có khi cả đời chưa từng đăng nhập vào sản phẩm của bạn.
Đây chính là lý do bài này quan trọng. Rất nhiều PM giỏi ở mảng tiêu dùng "vỡ trận" khi làm discovery cho enterprise, không phải vì họ kém kỹ năng phỏng vấn, mà vì họ áp dụng đúng kỹ thuật vào sai bối cảnh. Họ phỏng vấn end-user rất sâu, hiểu nỗi đau của end-user rất rõ — rồi xây một tính năng tuyệt vời mà... không ai mua, vì người ký ngân sách có một bộ "job" hoàn toàn khác.
Discovery cho B2B/enterprise không khó hơn về mặt kỹ thuật, nhưng nó phức tạp hơn về mặt bản đồ con người. Bạn phải hiểu một hệ sinh thái nhiều bên liên quan, một chu kỳ quyết định dài, và một tầng procurement (mua sắm) mà B2C gần như không có. Bài học này sẽ trang bị cho bạn cách lập bản đồ đó, cách phỏng vấn đúng người với đúng câu hỏi, và cách tránh những cái bẫy đặc thù chỉ có ở B2B.
Khái niệm cốt lõi
Nhiều persona, nhiều "job" chồng lên nhau
Điểm khác biệt lớn nhất của discovery B2B là bạn không có một khách hàng, mà có một buying group (nhóm ra quyết định mua). Gartner ước tính một quyết định mua phần mềm B2B điển hình có 6 đến 10 người tham gia. Mỗi người là một persona với một "job-to-be-done" riêng, đôi khi mâu thuẫn nhau:
- End-user (người dùng cuối): người trực tiếp dùng sản phẩm hằng ngày. "Job" của họ thường mang tính chức năng và cảm xúc: làm việc nhanh hơn, đỡ bực mình, trông giỏi hơn trước mặt sếp.
- Champion (người vô địch nội bộ): thường là một trưởng nhóm hoặc quản lý cấp trung, người tin vào sản phẩm và sẽ "bán" nó nội bộ thay bạn. "Job" của họ là giải quyết một vấn đề của phòng ban và ghi điểm với cấp trên.
- Economic buyer (người nắm ngân sách): giám đốc, phó tổng, CFO — người ký duyệt chi tiền. "Job" của họ thường là ROI, giảm rủi ro, đạt mục tiêu kinh doanh. Họ ít quan tâm tính năng, quan tâm con số.
- Admin / IT / Security: người chịu trách nhiệm triển khai, tích hợp, bảo mật. "Job" của họ là không để xảy ra sự cố. Họ là người có quyền phủ quyết (veto) — họ không làm thương vụ thành công, nhưng có thể làm nó chết.
- Gác cổng procurement / pháp chế: kiểm soát hợp đồng, điều khoản, tuân thủ. "Job" của họ là bảo vệ công ty khỏi rủi ro pháp lý và tài chính.
Chu kỳ quyết định dài (3–12 tháng)
Khác với B2C nơi quyết định có thể diễn ra trong vài phút, một thương vụ enterprise kéo dài từ 3 đến 12 tháng, đôi khi lâu hơn. Điều này ảnh hưởng trực tiếp đến discovery:
- Nỗi đau bạn nghe được hôm nay có thể đã thay đổi khi sản phẩm ra mắt 9 tháng sau.
- "Trigger" (yếu tố kích hoạt) khiến công ty bắt đầu tìm giải pháp thường là một sự kiện lớn: thay lãnh đạo, vòng gọi vốn, một sự cố nghiêm trọng, một quy định mới của nhà nước.
- Quyết định không phải một khoảnh khắc mà là một chuỗi các cửa ải: nhận biết vấn đề → tập hợp nhóm đánh giá → shortlist nhà cung cấp → pilot → đàm phán → ký. Discovery của bạn phải hiểu được toàn bộ chuỗi này, không chỉ một điểm.
Procurement — tầng mà B2C không có
Procurement là quá trình mua sắm chính thức của doanh nghiệp. Đây là nơi nhiều PM B2C bị bất ngờ nhất. Một sản phẩm có thể được end-user yêu thích, champion ủng hộ, CFO đồng ý về giá — rồi mắc kẹt 3 tháng ở khâu procurement vì thiếu chứng chỉ bảo mật ISO 27001, vì điều khoản hợp đồng không chấp nhận điều khoản trách nhiệm, hay vì công ty yêu cầu hóa đơn VAT theo chuẩn riêng. Discovery B2B phải bao gồm cả việc hiểu quy trình mua chứ không chỉ nhu cầu dùng.
Tình huống thực tế
Ví dụ 1: Startup SaaS quản lý kho bán cho chuỗi bán lẻ Việt Nam
Một startup giả định tên KhoSmart xây phần mềm quản lý tồn kho, nhắm tới các chuỗi bán lẻ vừa (20–80 cửa hàng) tại Việt Nam. Ban đầu PM của họ phỏng vấn rất kỹ các nhân viên kho — và xây một giao diện quét mã vạch cực mượt, được nhân viên kho khen hết lời trong buổi demo.
Nhưng sau 4 tháng, không chuỗi nào ký hợp đồng. Khi PM mở rộng discovery sang giám đốc vận hành (economic buyer), họ phát hiện ra "job" thật của người quyết định không phải là "quét mã nhanh hơn", mà là "giảm thất thoát tồn kho cuối tháng từ 4% xuống dưới 2% để báo cáo đẹp với hội đồng quản trị". Giao diện quét mã đẹp không trả lời câu hỏi đó. Cái họ cần thấy là báo cáo chênh lệch tồn kho theo thời gian thực và cảnh báo thất thoát.
Bài học: Discovery chỉ với end-user khiến bạn xây đúng thứ cho sai người. KhoSmart phải làm lại discovery với chân dung economic buyer, đặt câu hỏi xoay quanh chỉ số kinh doanh (thất thoát, ROI), rồi mới reframe sản phẩm. Sau khi bổ sung dashboard thất thoát, họ chốt được 3 chuỗi trong quý kế tiếp.
Ví dụ 2: Khâu IT/Security giết chết thương vụ phút chót
Một công ty fintech B2B (gọi là PayFlow) bán giải pháp đối soát thanh toán cho các ngân hàng và ví điện tử tại Đông Nam Á. Champion là trưởng phòng vận hành của một ngân hàng đã rất nhiệt tình, end-user thử nghiệm hài lòng, và giá đã được duyệt sơ bộ.
Đến vòng cuối, đội bảo mật của ngân hàng vào cuộc và đặt một loạt câu hỏi mà PayFlow không hề chuẩn bị trong discovery: dữ liệu lưu ở đâu, có on-premise được không, có đạt PCI-DSS không, log truy cập lưu bao lâu. PayFlow chỉ host trên cloud nước ngoài và không có chứng chỉ phù hợp. Thương vụ chết sau 7 tháng theo đuổi.
Bài học: Persona "veto" (IT/Security/pháp chế) phải được đưa vào discovery từ sớm, không phải để bán mà để hiểu các điều kiện loại trừ. Nếu PayFlow phỏng vấn một chuyên gia bảo mật ngân hàng ngay từ giai đoạn đầu, họ đã biết "không đạt PCI-DSS = không có cửa" và có thể quyết định đầu tư chứng chỉ sớm, hoặc chọn phân khúc khách hàng khác. Discovery B2B phải săn tìm các điều kiện loại trừ (dealbreakers) chứ không chỉ các nhu cầu.
Ví dụ 3: Phỏng vấn "switch story" ở cấp tổ chức
Một công ty SaaS HR (giả định tên NhanLuc.io) muốn hiểu vì sao các doanh nghiệp 200–500 nhân sự chuyển từ chấm công bằng Excel sang phần mềm. Họ phỏng vấn theo kiểu switch story, nhưng ở cấp tổ chức, "câu chuyện chuyển đổi" trải dài qua nhiều người.
Họ phát hiện trigger thật sự không phải nỗi đau hằng ngày của HR, mà là một sự kiện: công ty bị thanh tra lao động và bị phạt vì hồ sơ chấm công không khớp. Sau sự cố đó, CEO ra lệnh "phải có hệ thống chuẩn trong 2 tháng". Champion (trưởng phòng HR) được giao nhiệm vụ, IT vào kiểm tra tích hợp với hệ thống lương, và CFO duyệt ngân sách vì so với mức phạt thì chi phí phần mềm là rẻ.
Bài học: Trong B2B, một "switch story" hoàn chỉnh cần ghép từ nhiều cuộc phỏng vấn của nhiều persona. Trigger ở cấp tổ chức thường là sự kiện rủi ro hoặc tuân thủ, không phải sự khó chịu cá nhân. Hiểu được điều này giúp NhanLuc.io định vị thông điệp bán hàng quanh "tránh rủi ro thanh tra" thay vì "tiết kiệm thời gian HR".
Hướng dẫn từng bước
Bước 1 — Lập bản đồ buying group trước khi phỏng vấn. Trước mỗi tài khoản hoặc phân khúc, vẽ ra sơ đồ các persona: end-user, champion, economic buyer, IT/security, procurement. Với mỗi persona, ghi giả thuyết về "job" của họ. Đây là kim chỉ nam để bạn biết cần phỏng vấn ai.
Bước 2 — Phỏng vấn theo từng persona với bộ câu hỏi riêng. Đừng dùng cùng một kịch bản cho mọi người. Với end-user, hỏi về quy trình hằng ngày và nỗi bực mình. Với economic buyer, hỏi về mục tiêu kinh doanh, chỉ số, cách họ đánh giá ROI. Với IT/security, hỏi về điều kiện loại trừ, tiêu chuẩn bắt buộc, quy trình phê duyệt kỹ thuật.
Bước 3 — Tái dựng toàn bộ chuỗi quyết định. Hỏi rõ: ai phát hiện vấn đề đầu tiên, sự kiện nào kích hoạt, ai được giao đánh giá, những nhà cung cấp nào lọt shortlist, ai có quyền phủ quyết, mất bao lâu từ lúc nhận biết đến lúc ký. Mục tiêu là vẽ được "bản đồ hành trình mua" của tổ chức.
Bước 4 — Săn tìm các điều kiện loại trừ (dealbreakers). Hỏi thẳng: "Có điều gì khiến công ty anh chị loại bỏ một nhà cung cấp ngay lập tức không?" Câu trả lời (chứng chỉ, on-premise, hợp đồng tiếng Việt, hỗ trợ giờ Việt Nam) có thể quan trọng hơn cả danh sách tính năng.
Bước 5 — Phỏng vấn cả thương vụ thắng và thua. Nếu có thể, nói chuyện với những công ty đã từ chối mua hoặc bỏ dở sau pilot. Lý do họ không mua thường tiết lộ sự thật sâu sắc hơn lý do người ta mua.
Bước 6 — Tam giác hóa (triangulate) thông tin giữa các persona. Khi champion nói một đằng và IT nói một nẻo, đó không phải nhiễu — đó là insight. Khoảng cách giữa các persona chính là nơi thương vụ thường mắc kẹt, và là cơ hội cho sản phẩm của bạn giải quyết.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ phỏng vấn champion hoặc người dễ tiếp cận nhất. Champion luôn nhiệt tình và dễ hẹn, nên PM lười tìm tới economic buyer và IT. Hậu quả là bạn có một bức tranh đẹp nhưng thiếu hai mảnh quan trọng nhất quyết định việc ký hợp đồng. Mẹo: dùng chính champion làm cầu nối để xin được giới thiệu tới các persona khác — "Anh có thể giúp em gặp người duyệt ngân sách để hiểu rõ tiêu chí đánh giá không?"
Lỗi 2 — Nhầm sự phấn khích của end-user với tín hiệu mua. End-user khen sản phẩm không có nghĩa công ty sẽ mua. Trong B2B, lời khen rẻ tiền nhất đến từ người không kiểm soát ngân sách. Mẹo: luôn truy ngược về câu hỏi "ai trả tiền, và họ đo lường thành công bằng gì?"
Lỗi 3 — Bỏ qua procurement và pháp chế cho tới khi quá muộn. Đây là cái chết phổ biến nhất của startup bán cho enterprise. Mẹo: đưa câu hỏi về quy trình mua sắm vào discovery từ đầu — thời gian duyệt, yêu cầu hồ sơ, ai ký cuối cùng.
Lỗi 4 — Áp con số mẫu của B2C. Trong B2B, 8–12 cuộc phỏng vấn sâu trải đều trên các persona thường có giá trị hơn 50 cuộc cùng một loại người. Đừng chạy theo số lượng; hãy chạy theo độ phủ persona.
Lỗi 5 — Quên yếu tố chính trị nội bộ. Quyết định B2B mang đậm màu sắc quyền lực và lợi ích cá nhân. Một giám đốc có thể chặn dự án chỉ vì nó "không phải ý tưởng của họ". Mẹo: hỏi gián tiếp về động lực cá nhân: "Việc dự án này thành công ảnh hưởng thế nào tới anh chị?"
Mẹo bối cảnh Việt Nam: Nhiều doanh nghiệp Việt vẫn coi trọng quan hệ và sự tin cậy cá nhân hơn hợp đồng. Discovery nên khám phá cả khía cạnh "ai giới thiệu", "đã dùng ở đâu chưa", "có hỗ trợ tiếng Việt và hóa đơn VAT không" — những yếu tố tưởng nhỏ nhưng thường là dealbreaker thật sự ở thị trường nội địa.
Bài tập thực hành
- Vẽ bản đồ buying group. Chọn một sản phẩm B2B bạn đang làm hoặc quan tâm. Liệt kê tối thiểu 4 persona (end-user, champion, economic buyer, IT/procurement). Với mỗi persona, viết một câu mô tả "job-to-be-done" và một câu mô tả "điều gì khiến họ nói không".
- Soạn ba kịch bản phỏng vấn khác nhau. Viết 5 câu hỏi cho end-user, 5 câu cho economic buyer, và 5 câu cho IT/security. Đảm bảo các câu hỏi cho economic buyer xoay quanh chỉ số kinh doanh, còn câu cho IT xoay quanh điều kiện loại trừ.
- Tái dựng một chuỗi quyết định. Phỏng vấn một người bạn làm ở doanh nghiệp về một phần mềm công ty họ mới mua. Hãy ghép lại toàn bộ hành trình: trigger là gì, ai tham gia, mất bao lâu, ai suýt phủ quyết. So sánh với giả thuyết ban đầu của bạn xem lệch ở đâu.
- Tìm dealbreaker. Trong cuộc phỏng vấn trên, xác định ít nhất hai điều kiện loại trừ mà nếu nhà cung cấp không đáp ứng thì thương vụ sẽ chết ngay. Đây là bài tập rèn phản xạ "săn dealbreaker" thay vì chỉ "săn tính năng".
Tóm tắt
Discovery cho B2B/enterprise không phải là discovery B2C làm to hơn — nó là một trò chơi khác về bản chất. Bạn không có một khách hàng mà có một nhóm ra quyết định gồm nhiều persona, mỗi người mang một "job" riêng và đôi khi mâu thuẫn: end-user muốn tiện lợi, champion muốn ghi điểm, economic buyer muốn ROI, IT/security muốn an toàn, procurement muốn ít rủi ro pháp lý.
Ba đặc thù cốt lõi bạn phải luôn ghi nhớ: (1) nhiều persona nên phải làm discovery riêng cho từng người; (2) chu kỳ quyết định dài 3–12 tháng nên bạn phải tái dựng cả chuỗi quyết định và tìm đúng trigger cấp tổ chức; (3) procurement và các persona veto có thể giết thương vụ phút chót, nên phải đưa họ vào discovery từ sớm để săn tìm dealbreaker.
Nguyên tắc vàng để mang theo: trong B2B, lời khen của end-user là rẻ nhất, còn câu trả lời cho "ai trả tiền và họ đo thành công bằng gì" mới là đắt giá nhất. Hãy luôn lập bản đồ con người trước khi cắm đầu vào phỏng vấn, và đừng để sự phấn khích của một persona che mất bức tranh toàn cảnh của cả nhóm mua.