Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa nhận một dự án mới: xây dựng tính năng thanh toán trả góp cho một sàn thương mại điện tử. Bạn lao vào viết PRD, vẽ wireframe, lên timeline. Hai tuần sau, mọi thứ sụp đổ — không phải vì sản phẩm tệ, mà vì bạn quên mất rằng Giám đốc Tài chính phải duyệt mọi luồng tiền, đội Pháp chế cần review điều khoản lãi suất, và một anh Trưởng phòng Vận hành — người tưởng chừng chẳng liên quan — lại đang âm thầm phản đối vì sợ tăng tỷ lệ hoàn hàng. Dự án không chết vì code, nó chết vì bạn vẽ sai bản đồ con người.
Đây chính là lý do tồn tại của bài học này. Là một Product Manager, bạn hiếm khi có quyền ra lệnh cho ai. Quyền lực thực sự của bạn đến từ khả năng đọc được "địa hình chính trị" xung quanh dự án: ai có quyền, ai quan tâm, ai cần được giữ ấm, và ai có thể âm thầm chặn đứng mọi nỗ lực của bạn. Stakeholder Mapping — lập bản đồ các bên liên quan — là công cụ giúp bạn biến đám đông mơ hồ ấy thành một bức tranh rõ ràng, để bạn đầu tư đúng thời gian, đúng người, đúng cách.
Trong toàn bộ khóa học này, bài 17 dạy bạn cách gây ảnh hưởng khi không có quyền, bài 22 nói về việc xử lý sếp HiPPO, bài 23 về xây dựng liên minh. Nhưng tất cả những kỹ thuật đó đều vô dụng nếu bạn chưa biết ai là ai. Bài 21 này là tấm bản đồ nền móng — bạn phải vẽ được nó trước, rồi mới biết dùng vũ khí nào cho ai.
Khái niệm cốt lõi
Stakeholder là ai?
Stakeholder (bên liên quan) là bất kỳ cá nhân hoặc nhóm nào có thể ảnh hưởng đến dự án của bạn, hoặc bị dự án của bạn ảnh hưởng. Định nghĩa này rộng một cách có chủ đích. Stakeholder không chỉ là sếp và khách hàng — đó còn là đội Pháp chế, bộ phận Chăm sóc khách hàng (những người sẽ hứng phàn nàn nếu tính năng lỗi), đội Marketing, một PM khác mà tính năng của bạn đụng vào codebase của họ, thậm chí cả nhà cung cấp bên thứ ba.
Sai lầm phổ biến nhất của PM mới là chỉ nhìn thấy những người "rõ ràng" và bỏ sót những người đứng ở rìa nhưng có sức cản lớn. Bài học đầu tiên: hãy liệt kê thừa còn hơn thiếu.
Power-Interest Grid là gì?
Power-Interest Grid (lưới Quyền lực - Quan tâm), còn gọi là ma trận Mendelow, là một bảng 2x2 phân loại stakeholder theo hai trục:
- Power (Quyền lực): Người này có bao nhiêu khả năng tác động đến số phận dự án? Họ có thể phê duyệt hay phủ quyết ngân sách không? Họ có thể điều phối nguồn lực không? Họ có thể khiến dự án dừng lại bằng một câu nói trong cuộc họp không?
- Interest (Mức độ quan tâm): Người này quan tâm đến dự án ở mức nào? Kết quả của dự án ảnh hưởng trực tiếp đến công việc, KPI, hay lợi ích của họ ra sao? Họ có muốn theo dõi sát sao không, hay thấy nó chẳng liên quan gì đến mình?
Bốn ô và chiến lược tương ứng
Ô 1 — Quyền lực cao, Quan tâm cao → MANAGE CLOSELY (Quản lý sát sao). Đây là những người quan trọng nhất với bạn. Họ vừa có quyền quyết định số phận dự án, vừa thực sự để tâm đến nó. Ví dụ: Giám đốc sản phẩm trực tiếp, sponsor của dự án, khách hàng lớn trả tiền. Với nhóm này, bạn cần đầu tư nhiều thời gian nhất: cập nhật thường xuyên, lắng nghe phản hồi, đưa họ vào các quyết định lớn, làm cho họ cảm thấy được tham gia và sở hữu. Họ là đồng minh quyền lực nhất — nhưng nếu bị bỏ rơi, họ cũng là kẻ phá hoại nguy hiểm nhất.
Ô 2 — Quyền lực cao, Quan tâm thấp → KEEP SATISFIED (Giữ hài lòng). Đây là nhóm tinh tế và dễ gây tai họa nhất. Họ có quyền lực lớn (một Phó Tổng, một Giám đốc Tài chính) nhưng hiện tại chưa mấy quan tâm đến dự án. Sai lầm chết người là phớt lờ họ vì nghĩ "họ đâu có quan tâm". Vấn đề là nếu họ bỗng nhiên quan tâm — thường là khi có chuyện không hay — quyền lực của họ đủ để lật ngược ván cờ. Với nhóm này, hãy giữ họ hài lòng bằng những cập nhật ngắn gọn, ở mức tổng quan, không làm họ ngợp nhưng cũng không để họ bị bất ngờ. Mục tiêu: đừng để mức quan tâm của họ tăng vọt theo hướng tiêu cực.
Ô 3 — Quyền lực thấp, Quan tâm cao → KEEP INFORMED (Giữ thông tin). Đây là những người rất để tâm đến dự án nhưng không có nhiều quyền quyết định: đội ngũ chăm sóc khách hàng, các kỹ sư trong nhóm, người dùng nội bộ, cộng đồng beta. Họ là nguồn thông tin và phản hồi quý giá, và nếu được nuôi dưỡng, họ có thể trở thành những người ủng hộ nhiệt thành, lan tỏa tiếng nói tích cực. Hãy giữ họ được thông tin đầy đủ, lắng nghe góc nhìn vận hành của họ. Nhiều khi một liên minh từ nhóm này có thể "đẩy" tiếng nói lên các ô quyền lực cao hơn.
Ô 4 — Quyền lực thấp, Quan tâm thấp → MONITOR (Theo dõi). Nhóm cần ít công sức nhất. Bạn chỉ cần để mắt định kỳ, giao tiếp tối thiểu. Đừng lãng phí thời gian quý báu vào đây. Tuy nhiên, hãy theo dõi vì vị trí của một stakeholder không cố định — họ có thể dịch chuyển sang ô khác khi bối cảnh thay đổi.
Bản đồ là động, không phải tĩnh
Điểm cốt lõi mà PM giỏi luôn nhớ: vị trí của mỗi stakeholder thay đổi theo thời gian và theo từng giai đoạn dự án. Một người ở ô "Monitor" lúc khởi động có thể nhảy thẳng lên "Manage Closely" khi dự án chạm vào lĩnh vực của họ. Bản đồ stakeholder không phải tài liệu vẽ một lần rồi cất tủ — nó là công cụ sống, cần được cập nhật mỗi khi bối cảnh chuyển động.
Tình huống thực tế
Tình huống 1: Tính năng ví điện tử tại một startup fintech Việt Nam
Lan là PM tại một ví điện tử đang lên ở TP.HCM (gọi là PayViet). Cô được giao xây dựng tính năng "Đầu tư tích lũy" — cho phép người dùng để tiền nhàn rỗi sinh lời. Lan vẽ Power-Interest Grid như sau:
- Manage Closely: CEO (sponsor dự án, cực kỳ tâm huyết) và Giám đốc Tài chính (kiểm soát mọi sản phẩm liên quan đến tiền).
- Keep Satisfied: Trưởng phòng Pháp chế — quyền lực rất cao vì có thể chặn tính năng nếu vi phạm quy định của Ngân hàng Nhà nước, nhưng ban đầu chị này tỏ ra thờ ơ, nghĩ đây "chỉ là một feature nhỏ".
- Keep Informed: Đội Chăm sóc khách hàng và 3 kỹ sư backend.
- Monitor: Đội Marketing (chưa tới giai đoạn truyền thông).
Bài học rút ra: Stakeholder quyền lực cao nhưng quan tâm thấp là quả bom hẹn giờ. "Giữ hài lòng" không phải là làm hài lòng họ — mà là không để họ bị bất ngờ.
Tình huống 2: Grab và bài toán xếp nhầm ô
Hãy lấy một ví dụ giả định nhưng sát thực tế trong môi trường công ty công nghệ lớn ở Đông Nam Á như Grab. Minh, một PM, phụ trách thay đổi thuật toán phân bổ đơn hàng cho tài xế. Anh xếp đội ngũ Vận hành tài xế khu vực vào ô "Keep Informed" — nghĩ rằng họ chỉ là người thực thi, quyền lực thấp.
Đây là một đánh giá sai về trục Power. Trên giấy tờ, đội Vận hành không "phê duyệt" sản phẩm. Nhưng trong thực tế, họ là người duy nhất nắm dữ liệu mặt đất về phản ứng của tài xế, và họ có một đường dây báo cáo trực tiếp lên Giám đốc khu vực. Khi thuật toán mới khiến thu nhập một nhóm tài xế giảm, đội Vận hành leo thang vấn đề lên cấp cao chỉ trong 48 giờ, và dự án của Minh bị tạm dừng để rà soát.
Minh đã nhầm "quyền lực chính thức" (formal authority) với "quyền lực thực tế" (informal influence). Đội Vận hành đáng lẽ phải nằm ở ô "Manage Closely".
Bài học rút ra: Khi đánh giá trục Power, đừng chỉ nhìn chức danh. Hãy hỏi: "Người này có thể khiến dự án dừng lại bằng cách nào, kể cả gián tiếp?" Quyền lực phi chính thức thường nguy hiểm hơn vì nó vô hình trên sơ đồ tổ chức.
Tình huống 3: Vẽ lại bản đồ giữa chừng dự án
Trang là PM tại một công ty SaaS B2B. Đầu dự án nâng cấp hệ thống báo cáo, cô xếp đội Sales vào ô "Monitor" — vì tính năng còn ở giai đoạn kỹ thuật. Hợp lý ở thời điểm đó.
Nhưng đến tháng thứ hai, một khách hàng doanh nghiệp lớn (chiếm 20% doanh thu) ngỏ ý muốn dùng đúng tính năng này như điều kiện gia hạn hợp đồng. Ngay lập tức, đội Sales — và đặc biệt là Giám đốc Kinh doanh — nhảy từ ô "Monitor" thẳng lên "Manage Closely". Trang nhận ra điều này nhờ thói quen rà soát bản đồ stakeholder hai tuần một lần. Cô chủ động kéo Giám đốc Kinh doanh vào các buổi review, điều chỉnh roadmap để ưu tiên đúng phần khách hàng cần.
Bài học rút ra: Bản đồ stakeholder là tài liệu sống. Một sự kiện bên ngoài — một hợp đồng, một đối thủ ra mắt, một thay đổi nhân sự cấp cao — có thể tái sắp xếp toàn bộ bản đồ chỉ sau một đêm. PM giỏi rà soát bản đồ định kỳ chứ không vẽ một lần rồi quên.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay cho dự án hiện tại:
Bước 1 — Brainstorm danh sách stakeholder (liệt kê thừa còn hơn thiếu). Dành 20 phút viết ra mọi cá nhân và nhóm có thể ảnh hưởng hoặc bị ảnh hưởng. Tự hỏi: Ai duyệt ngân sách? Ai cung cấp nguồn lực? Ai dùng sản phẩm? Ai chịu hậu quả nếu nó lỗi? Ai có thể phản đối? Đừng tự kiểm duyệt ở bước này.
Bước 2 — Chấm điểm Power cho từng người. Với mỗi stakeholder, cho điểm quyền lực từ 1 đến 5. Câu hỏi định hướng: "Người này có thể khiến dự án dừng, chậm, hoặc đổi hướng đến mức nào — bằng cả quyền chính thức lẫn ảnh hưởng phi chính thức?" Nhớ bài học từ tình huống Grab: đừng chỉ nhìn chức danh.
Bước 3 — Chấm điểm Interest cho từng người. Cho điểm mức quan tâm từ 1 đến 5: "Kết quả dự án ảnh hưởng đến công việc, KPI, lợi ích của họ ra sao? Họ muốn theo sát đến mức nào?" Lưu ý phân biệt: quan tâm hiện tại và quan tâm tiềm năng (sẽ tăng vọt nếu có chuyện).
Bước 4 — Đặt mỗi người vào một trong bốn ô. Vẽ lưới 2x2 (có thể dùng Miro, FigJam, hay chỉ một tờ giấy). Đặt từng cái tên vào ô tương ứng. Khi nhìn tổng thể, bạn sẽ thấy ngay nhóm nào cần đầu tư nhiều nhất.
Bước 5 — Gắn chiến lược giao tiếp cụ thể cho từng ô. Đừng dừng ở việc phân loại. Hãy viết ra hành động: Manage Closely → họp 1-1 hàng tuần. Keep Satisfied → email tóm tắt 5 dòng định kỳ. Keep Informed → mời vào kênh Slack cập nhật, demo sprint. Monitor → cập nhật trong newsletter chung.
Bước 6 — Rà soát định kỳ. Đặt lịch xem lại bản đồ mỗi 2 tuần hoặc tại mỗi cột mốc lớn. Hỏi: "Ai vừa dịch chuyển ô? Có stakeholder mới xuất hiện không?"
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm quyền lực chính thức với ảnh hưởng thực tế. Như tình huống Grab, một người không có chức danh "duyệt" vẫn có thể giết dự án qua đường dây phi chính thức. Mẹo: với mỗi stakeholder điểm quan tâm cao, hãy hỏi "ai là người họ có thể gọi điện than phiền?"
Lỗi 2 — Bỏ rơi ô "Keep Satisfied". Đây là lỗi đắt giá nhất. Vì họ "không quan tâm", PM phớt lờ — rồi bị phủ quyết phút chót. Mẹo: với mỗi người quyền lực cao, mặc định gửi cập nhật ngắn ngay cả khi họ chưa hỏi.
Lỗi 3 — Quá tải thông tin cho người sai. Gửi PRD 30 trang cho một Phó Tổng chỉ muốn biết "có on-track không" sẽ phản tác dụng — nó làm tăng mức quan tâm theo hướng tiêu cực. Mẹo: điều chỉnh độ chi tiết theo ô, không phải gửi mọi thứ cho mọi người.
Lỗi 4 — Coi bản đồ là tài liệu tĩnh. Vẽ một lần đầu dự án rồi quên. Mẹo: đặt một reminder lặp lại, và luôn rà soát lại sau mỗi sự kiện lớn (thay đổi nhân sự, hợp đồng mới, đối thủ).
Lỗi 5 — Giữ bản đồ công khai cho mọi người xem. Việc ghi "anh A: quyền lực thấp, quan tâm thấp" mà để lộ ra ngoài có thể gây tổn thương và mâu thuẫn. Mẹo: đây là tài liệu làm việc cá nhân của bạn, giữ riêng tư.
Mẹo nâng cao: Sau khi xếp ô, hãy thêm một cột "thái độ" (ủng hộ / trung lập / phản đối) cho từng stakeholder. Power-Interest cho bạn biết đầu tư bao nhiêu, còn thái độ cho bạn biết theo hướng nào — cần thuyết phục ai và cần dựa vào ai.
Bài tập thực hành
Chọn một dự án bạn đang làm (hoặc một dự án giả định nếu bạn chưa đi làm), rồi thực hiện:
- Liệt kê ít nhất 10 stakeholder của dự án — ép mình nghĩ ra cả những người ở rìa.
- Chấm điểm Power (1–5) và Interest (1–5) cho từng người. Với mỗi điểm Power, viết một câu lý giải "người này có thể tác động bằng cách nào".
- Vẽ lưới 2x2 và đặt cả 10 cái tên vào ô.
- Viết chiến lược giao tiếp một dòng cho mỗi ô (tần suất + độ chi tiết + kênh).
- Bài kiểm tra phản tư: Tìm ít nhất một người bạn đang xếp ở ô "Monitor" hoặc "Keep Informed" nhưng có khả năng nhảy lên ô quyền lực cao khi có biến. Viết ra điều kiện kích hoạt sự dịch chuyển đó.
Tóm tắt
Stakeholder Mapping với Power-Interest Grid là tấm bản đồ nền móng cho mọi nỗ lực gây ảnh hưởng của PM. Hãy nhớ những điểm cốt lõi:
- Hai trục: Power (khả năng tác động đến dự án) và Interest (mức độ quan tâm). Kết hợp lại thành bốn ô.
- Bốn chiến lược: Manage Closely (quyền cao, quan tâm cao — đầu tư nhiều nhất), Keep Satisfied (quyền cao, quan tâm thấp — đừng để bất ngờ), Keep Informed (quyền thấp, quan tâm cao — nuôi dưỡng đồng minh), Monitor (cả hai thấp — công sức tối thiểu).
- Cạm bẫy lớn nhất: bỏ rơi ô "Keep Satisfied", và nhầm quyền lực chính thức với ảnh hưởng phi chính thức.
- Bản đồ là động: rà soát định kỳ, vì một sự kiện bên ngoài có thể tái sắp xếp toàn bộ chỉ sau một đêm.