Mở đầu — vì sao bài này quan trọng
Trong rất nhiều buổi coaching cho Product Owner mới, mình thường hỏi một câu đơn giản: "Ai là người bạn đang xây sản phẩm cho?" Và bạn biết câu trả lời phổ biến nhất là gì không? "Dạ, cho khách hàng." Nghe thì hợp lý, nhưng nó lại là một câu trả lời mơ hồ đến mức nguy hiểm. Bởi vì trong một sản phẩm thực tế, "khách hàng" có thể không phải là người chạm vào sản phẩm, và người chạm vào sản phẩm nhiều nhất có thể chẳng có một đồng nào trong túi để trả tiền cho bạn.
Đây chính là lý do Bài 41 tồn tại. Ba khái niệm Stakeholder (bên liên quan), Customer (khách hàng) và User (người dùng) nghe có vẻ giống nhau, thậm chí trong giao tiếp hằng ngày người ta dùng lẫn lộn. Nhưng với một Product Owner, việc phân biệt rạch ròi ba nhóm này là kỹ năng nền tảng. Nó ảnh hưởng trực tiếp đến cách bạn ưu tiên Product Backlog, cách bạn nói chuyện với từng nhóm, và cách bạn quyết định "value" (giá trị) thực sự nằm ở đâu.
Trong kỳ thi PSPO I, bạn sẽ gặp những câu hỏi đánh thẳng vào sự nhầm lẫn này. Scrum Guide nói Product Owner chịu trách nhiệm "maximizing the value of the product" — nhưng giá trị cho ai? Cho người trả tiền hay cho người dùng? Nếu bạn không phân biệt được, bạn sẽ chọn sai đáp án. Và quan trọng hơn cả kỳ thi: trong công việc thật, nhầm lẫn ba nhóm này khiến bạn xây ra những sản phẩm mà ban lãnh đạo hài lòng nhưng người dùng ghét, hoặc người dùng thích mà công ty không thu được tiền. Cả hai đều là thất bại.
Khái niệm cốt lõi
User — người tương tác trực tiếp với sản phẩm
User là người trực tiếp sử dụng, chạm vào, thao tác trên sản phẩm của bạn. Họ mở app lên, bấm nút, điền form, đọc nội dung, hoàn thành một công việc nào đó nhờ sản phẩm. Trải nghiệm của họ — nhanh hay chậm, dễ hay khó, vui hay bực — chính là thước đo trực tiếp nhất cho chất lượng sản phẩm.
Điều quan trọng cần nhớ: User quan tâm đến việc của họ được giải quyết tốt đến đâu, chứ không quan tâm sản phẩm mang về bao nhiêu doanh thu cho công ty bạn. Một nhân viên kho dùng phần mềm quản lý hàng tồn không hề bận tâm đến margin lợi nhuận của nhà cung cấp phần mềm — họ chỉ muốn quét mã vạch xong trong 2 giây thay vì 10 giây.
Customer — người trả tiền (quyết định mua)
Customer là người ra quyết định mua và trả tiền cho sản phẩm. Họ là người nắm ngân sách, ký hợp đồng, bấm nút thanh toán. Customer quan tâm đến giá trị kinh doanh: chi phí, ROI (lợi tức đầu tư), sản phẩm này giúp tổ chức của họ tiết kiệm hay kiếm thêm được bao nhiêu.
Điểm mấu chốt: Customer có thể không phải là User. Trong các sản phẩm B2B (bán cho doanh nghiệp), điều này gần như là quy luật. Giám đốc IT của một ngân hàng quyết định mua phần mềm chấm công cho 5.000 nhân viên — ông ấy là Customer, nhưng người dùng phần mềm đó hằng ngày là 5.000 nhân viên kia, những User. Ông giám đốc IT có thể chưa từng mở app chấm công lên trong đời.
Stakeholder — bất kỳ ai có "phần lợi ích" trong sản phẩm
Stakeholder là khái niệm rộng nhất: bất kỳ cá nhân hay nhóm nào có lợi ích, có ảnh hưởng, hoặc bị tác động bởi sản phẩm. Từ "stake" trong tiếng Anh nghĩa là "phần đặt cược, phần lợi ích". Stakeholder là người có "phần" trong cuộc chơi.
Stakeholder là một cái ô lớn bao trùm lên cả Customer lẫn User, cộng thêm rất nhiều nhóm khác nữa. Hãy hình dung danh sách stakeholder điển hình của một Product Owner:
- Customer và User (như đã nói ở trên — họ cũng là stakeholder).
- Ban lãnh đạo / Sponsor — người cấp ngân sách dự án, kỳ vọng kết quả kinh doanh.
- Bộ phận Sales và Marketing — cần tính năng để bán, cần thông điệp để truyền thông.
- Bộ phận Pháp lý / Compliance — quan tâm sản phẩm có tuân thủ luật, ví dụ Nghị định 13/2023 về bảo vệ dữ liệu cá nhân ở Việt Nam.
- Bộ phận Vận hành / Chăm sóc khách hàng — người hứng chịu hậu quả khi sản phẩm lỗi.
- Đối tác bên ngoài — nhà cung cấp tích hợp, cổng thanh toán như VNPay, MoMo.
Mối quan hệ ba lớp — hình dung bằng vòng tròn
Cách dễ nhớ nhất là hình dung ba vòng tròn lồng nhau:
- Vòng ngoài cùng (lớn nhất): Stakeholder — tất cả những ai có lợi ích.
- Vòng giữa: Customer — tập con của stakeholder, là những người trả tiền.
- Vòng trong: User — những người dùng trực tiếp.
Một lưu ý dành riêng cho kỳ thi PSPO I: Scrum Guide 2020 không định nghĩa chi tiết ba thuật ngữ này, mà dùng thuật ngữ chung là "stakeholders". Trong Scrum, Product Owner là người đại diện tiếng nói của tất cả stakeholder và đặc biệt phải hiểu sâu nhu cầu của User để tối đa hóa giá trị. Đừng nhầm rằng PO chỉ phục vụ người trả tiền.
Tình huống thực tế
Ví dụ 1: Phần mềm quản lý trường học EduNext — khi Customer và User là hai thế giới khác nhau
Giả sử có một startup edtech Việt Nam tên EduNext, bán phần mềm quản lý cho các trường tư thục. Hợp đồng tiêu biểu: một hệ thống trường liên cấp ở TP.HCM ký mua gói 250 triệu đồng/năm cho 30 cơ sở.
Người ký hợp đồng và trả tiền là bà Hiệu trưởng kiêm Chủ tịch hội đồng quản trị — đây là Customer. Bà quan tâm: phần mềm có giúp giảm chi phí vận hành không, có báo cáo tổng hợp cho hội đồng quản trị không, có "sang" để PR với phụ huynh không.
Nhưng người dùng phần mềm hằng ngày là ai? Là hơn 400 giáo viên điểm danh, nhập điểm, gửi thông báo; là nhân viên kế toán thu học phí; là phụ huynh tra cứu điểm con qua app. Đó là các nhóm User khác nhau, mỗi nhóm có nhu cầu riêng.
Product Owner của EduNext đã mắc một sai lầm kinh điển: trong 3 Sprint đầu, anh chỉ gặp bà Hiệu trưởng và xây toàn bộ tính năng dashboard báo cáo đẹp lung linh cho ban giám hiệu. Kết quả? Bà Hiệu trưởng rất ưng. Nhưng giáo viên thì phải mất 12 thao tác chỉ để điểm danh một lớp, app load chậm trên điện thoại cũ. Sau 2 tháng, tỷ lệ giáo viên dùng app thực tế chỉ 35%. Dữ liệu đầu vào không có thì dashboard đẹp cũng vô nghĩa — vì không có ai nhập liệu cho nó. Đến kỳ gia hạn, trường dọa không tái ký vì "phần mềm không ai dùng được".
Bài học: Customer trả tiền, nhưng nếu User không dùng được thì giá trị sụp đổ. Một PO giỏi phải cân bằng tiếng nói của cả hai. Tiền đến từ Customer, nhưng tiền ở lại nhờ User hài lòng (đặc biệt với mô hình subscription tái ký hằng năm).
Ví dụ 2: Grab — phân biệt User để ưu tiên Backlog cho đúng
Lấy ví dụ một nền tảng quen thuộc kiểu Grab. Ở đây bức tranh stakeholder cực kỳ rõ và là minh họa kinh điển cho mô hình hai mặt (two-sided marketplace).
- User của ứng dụng đặt xe: hành khách — họ chạm vào app để gọi xe.
- User của ứng dụng tài xế: bác tài — họ chạm vào app khác để nhận cuốc.
- Customer: trong nhiều cuốc xe, ai trả tiền cũng là hành khách (Customer trùng User). Nhưng với mảng GrabForBusiness, công ty trả tiền cho nhân viên đi công tác — lúc này Customer là phòng hành chính của doanh nghiệp, còn User là nhân viên đi xe.
- Stakeholder khác: nhà hàng đối tác (mảng GrabFood), cổng thanh toán, cơ quan quản lý giao thông, nhà đầu tư.
Bài học: Trong sản phẩm có nhiều nhóm User và Customer, PO phải đặt tên rõ ràng từng nhóm trước khi ưu tiên Backlog. Một quyết định luôn có người được lợi và người chịu thiệt. Vẽ ra bản đồ stakeholder giúp bạn nhìn thấy "ai trả giá cho tính năng này" trước khi đẩy nó lên đầu Backlog.
Ví dụ 3: App ngân hàng nội bộ — khi User không hề là Customer
Một ngân hàng tại Việt Nam thuê đội phát triển nội bộ xây một ứng dụng phê duyệt khoản vay cho nhân viên tín dụng dùng. Ở đây không có ai "mua" sản phẩm theo nghĩa truyền thống.
- User: 800 nhân viên tín dụng tại các chi nhánh — họ nhập hồ sơ, chấm điểm tín dụng, trình duyệt.
- Customer / Sponsor: Khối Quản trị rủi ro cấp ngân sách 8 tỷ đồng cho dự án, kỳ vọng giảm thời gian duyệt vay từ 5 ngày xuống 2 ngày.
- Stakeholder khác: Khối Công nghệ thông tin (lo vận hành, bảo mật), bộ phận Tuân thủ (lo đúng quy định Ngân hàng Nhà nước), và gián tiếp là khách hàng cuối của ngân hàng — người đi vay, dù họ không bao giờ chạm vào app này.
Bài học: Có những stakeholder không bao giờ là User, không bao giờ là Customer, nhưng quyền lực phủ quyết (veto) của họ rất lớn — như bộ phận Pháp lý, Tuân thủ. PO bỏ qua họ là tự đào hố cho mình.
Hướng dẫn từng bước
Đây là quy trình mình khuyên các PO áp dụng để phân biệt và quản lý ba nhóm này trong thực tế:
Bước 1 — Lập danh sách stakeholder đầy đủ. Ngồi xuống và liệt kê tất cả những ai có lợi ích hoặc bị ảnh hưởng bởi sản phẩm. Đừng tự kiểm duyệt sớm — cứ ghi ra hết, kể cả những nhóm "ít quan trọng". Bạn sẽ bất ngờ vì danh sách thường dài hơn dự đoán.
Bước 2 — Gắn nhãn cho từng nhóm. Với mỗi cái tên trong danh sách, tự hỏi ba câu: Họ có trực tiếp dùng sản phẩm không? (→ User). Họ có trả tiền / ra quyết định mua không? (→ Customer). Họ chỉ có lợi ích/ảnh hưởng nhưng không thuộc hai nhóm trên? (→ Stakeholder thuần). Một người có thể mang nhiều nhãn cùng lúc — điều đó hoàn toàn bình thường.
Bước 3 — Xác định nhóm User cụ thể (personas). "User" hiếm khi là một khối đồng nhất. Hãy tách thành các persona riêng: ở ví dụ EduNext là giáo viên, kế toán, phụ huynh. Mỗi persona có nhu cầu và nỗi đau khác nhau.
Bước 4 — Vẽ Stakeholder Map theo trục Quyền lực × Quan tâm. Đây là công cụ kinh điển: trục dọc là mức độ quyền lực/ảnh hưởng, trục ngang là mức độ quan tâm. Bạn sẽ có 4 nhóm: quyền lực cao + quan tâm cao (quản lý sát sao), quyền lực cao + quan tâm thấp (giữ hài lòng), quyền lực thấp + quan tâm cao (cập nhật thường xuyên), quyền lực thấp + quan tâm thấp (theo dõi nhẹ).
Bước 5 — Định nghĩa "value" cho từng nhóm. Giá trị với Customer là ROI/chi phí; với User là trải nghiệm và công việc được hoàn thành; với stakeholder khác là tuân thủ, ổn định vận hành... Khi viết Product Goal và sắp xếp Backlog, hãy ý thức bạn đang phục vụ giá trị nào cho ai.
Bước 6 — Thiết kế kênh giao tiếp riêng. Bạn không nói chuyện với ông giám đốc tài chính giống cách nói với người dùng cuối. Customer cần con số ROI; User cần được phỏng vấn, quan sát, test thử. Sprint Review là nơi tuyệt vời để mời đại diện cả ba nhóm cùng vào.
Lỗi thường gặp & mẹo
Lỗi 1 — Đánh đồng "khách hàng" với "người dùng". Đây là lỗi phổ biến nhất, đặc biệt trong B2B. PO chỉ gặp người ký hợp đồng, xây theo ý họ, rồi bỏ quên người thật sự dùng. Hậu quả như EduNext: sản phẩm "bán được" nhưng "không dùng được". Mẹo: mỗi Sprint, tự hỏi "Sprint này mình đã nói chuyện với User thật chưa, hay chỉ nghe Customer?"
Lỗi 2 — Coi tất cả stakeholder ngang nhau. Nếu ai yêu cầu gì bạn cũng nhận, Backlog của bạn sẽ thành cái thùng rác. Không phải mọi stakeholder đều có tiếng nói ngang nhau trong việc định hình sản phẩm. Mẹo: dùng Stakeholder Map để biết ai cần lắng nghe sâu, ai chỉ cần thông báo.
Lỗi 3 — Để stakeholder ra lệnh trực tiếp cho Developers. Trong Scrum, Product Owner là điểm tiếp nhận duy nhất cho các yêu cầu vào Product Backlog. Nếu sếp nhảy vào bảo Dev làm tính năng X, trật tự ưu tiên sụp đổ. Mẹo: lịch sự nhưng kiên quyết kéo mọi yêu cầu về Backlog, để bạn cân nhắc thứ tự.
Lỗi 4 — Nhầm trong phòng thi PSPO I. Khi đề bài nói "ai chịu trách nhiệm hiểu nhu cầu khách hàng và người dùng" → đáp án là Product Owner, không phải Scrum Master hay nhóm Sales. Khi đề hỏi "PO tối đa hóa giá trị cho ai" → nghĩ tới tất cả stakeholder, không chỉ người trả tiền. Mẹo: đọc kỹ xem câu hỏi đang nói về "user", "customer" hay "stakeholder" — Scrum dùng từ "stakeholder" làm thuật ngữ chính.
Lỗi 5 — Quên các stakeholder "vô hình". Pháp lý, bảo mật, vận hành — những người không lên tiếng cho đến khi có sự cố. Mẹo: chủ động mời họ vào sớm, đừng đợi đến lúc ra mắt mới phát hiện vi phạm Nghị định 13.
Bài tập thực hành
Hãy chọn một sản phẩm bạn đang làm hoặc quen thuộc (nếu chưa có, dùng một app bạn dùng hằng ngày như ví ZaloPay hoặc app gọi đồ ăn).
- Liệt kê stakeholder. Viết ra tối thiểu 8 nhóm cá nhân/tổ chức có lợi ích trong sản phẩm đó.
- Gắn nhãn. Với mỗi nhóm, đánh dấu họ là User, Customer, hay Stakeholder thuần (hoặc nhiều nhãn). Tìm ít nhất một trường hợp Customer ≠ User và giải thích vì sao.
- Tách persona User. Liệt kê ít nhất 3 nhóm User khác nhau và viết một câu mô tả "việc cần làm" (job-to-be-done) của mỗi nhóm.
- Vẽ Stakeholder Map. Xếp các nhóm vào lưới Quyền lực × Quan tâm 2×2. Ghi rõ chiến lược giao tiếp cho từng ô.
- Tình huống xung đột. Tự nghĩ ra một yêu cầu tính năng mà làm lợi cho Customer nhưng hại cho User (hoặc ngược lại). Nếu là PO, bạn sẽ xử lý thế nào? Viết 3-4 câu lập luận.
Tóm tắt
- User là người trực tiếp tương tác với sản phẩm; họ quan tâm trải nghiệm và việc của họ được giải quyết tốt đến đâu.
- Customer là người ra quyết định mua và trả tiền; họ quan tâm giá trị kinh doanh, ROI, chi phí. Trong B2B, Customer thường không trùng với User.
- Stakeholder là cái ô lớn nhất: bất kỳ ai có lợi ích, ảnh hưởng hoặc bị tác động — bao gồm cả Customer, User, lẫn ban lãnh đạo, pháp lý, vận hành, đối tác.
- Hình dung ba vòng tròn lồng nhau: Stakeholder bọc ngoài, Customer ở giữa, User bên trong; User và Customer có thể trùng nhưng thường thì không.
- Product Owner phải đại diện tiếng nói của tất cả stakeholder, đặc biệt hiểu sâu User để tối đa hóa giá trị — chứ không chỉ phục vụ người trả tiền.
- Công cụ thực chiến: lập danh sách stakeholder, gắn nhãn ba nhóm, tách persona User, vẽ Stakeholder Map theo trục Quyền lực × Quan tâm, và định nghĩa "value" riêng cho từng nhóm.
- Trong PSPO I: Scrum Guide dùng thuật ngữ "stakeholders"; khi gặp câu hỏi về hiểu nhu cầu khách hàng/người dùng, người chịu trách nhiệm luôn là Product Owner.