Mở đầu — vì sao bài này quan trọng
Có một nghịch lý mà gần như mọi Product Manager đều va phải trong năm đầu tiên làm nghề: bạn chịu trách nhiệm cho kết quả của sản phẩm, nhưng bạn lại không quản lý bất kỳ ai làm ra sản phẩm đó. Engineer không report cho bạn. Designer không report cho bạn. Sales, marketing, legal, data — không ai trong số họ phải nghe lời bạn. Thế nhưng nếu tính năng ra trễ, nếu metric không lên, nếu khách hàng phàn nàn, người bị gọi vào phòng họp để giải trình lại chính là bạn.
Đây không phải lỗi thiết kế của tổ chức. Đây là bản chất của nghề PM. Marty Cagan từng nói PM là người "lãnh đạo bằng ảnh hưởng, không phải bằng thẩm quyền". Nhưng "ảnh hưởng" nghe thì hay, làm thì khó. Khi bạn không có quyền ra lệnh, bạn lấy gì để khiến một senior engineer đang bận ba dự án dừng lại và ưu tiên cái bạn cần? Lấy gì để thuyết phục một sales director bỏ thời gian giúp bạn validate một insight?
Câu trả lời nằm ở một mô hình kinh điển: Influence Without Authority của Allan Cohen và David Bradford, hai giáo sư tại Babson College và Stanford. Cốt lõi của mô hình rất giản dị nhưng cực kỳ mạnh: ảnh hưởng thực chất là trao đổi — một hình thức "trao đổi tiền tệ" (currencies) giữa hai bên dựa trên nguyên tắc có đi có lại (reciprocity). Bạn không bắt ai làm gì cả; bạn tìm ra thứ họ thực sự coi trọng và trao nó cho họ, để đổi lại sự hợp tác.
Bài này sẽ cho bạn một khung tư duy có cấu trúc để biến "ảnh hưởng" từ một kỹ năng mơ hồ thành một quy trình bạn có thể luyện tập và áp dụng được ngay tuần sau.
Khái niệm cốt lõi
Nguyên lý nền tảng: Reciprocity (Có đi có lại)
Cohen và Bradford xây mô hình trên một quan sát về tâm lý xã hội: con người vận hành theo nguyên tắc có đi có lại. Khi ai đó làm điều tốt cho ta, ta cảm thấy "mắc nợ" và muốn đáp lại. Đây không phải mánh khóe — nó là chất keo gắn kết mọi mối quan hệ làm việc lành mạnh.
Điều này nghĩa là: ảnh hưởng không phải là việc bạn ép buộc hay van xin. Ảnh hưởng là một giao dịch trao đổi giá trị. Bạn muốn engineer ưu tiên task của mình? Vậy bạn đang trao lại cho họ điều gì? Nếu câu trả lời là "không gì cả, đây là việc của họ mà", thì bạn đang tiêu vào một tài khoản mà bạn chưa hề nạp tiền.
"Currencies" — Các loại "tiền tệ" của ảnh hưởng
Đóng góp lớn nhất của Cohen-Bradford là khái niệm currencies — những thứ có giá trị mà người ta có thể trao đổi với nhau trong tổ chức. Tiền lương không phải currency duy nhất, thậm chí thường không phải currency quan trọng nhất. Họ phân thành năm nhóm:
1. Inspiration-related currencies (Liên quan đến cảm hứng):
- Vision — cảm giác được góp phần vào điều gì đó lớn lao, có ý nghĩa.
- Excellence — cơ hội làm việc thật giỏi, thật chất lượng.
- Moral/Ethical correctness — cảm giác đang làm điều đúng đắn.
- Resources — ngân sách, người, công cụ, thời gian.
- Assistance — được giúp đỡ trực tiếp trong công việc hiện tại.
- Information — dữ liệu, kiến thức, bối cảnh mà họ cần.
- Cooperation — sự phối hợp để công việc của họ trôi chảy.
- Recognition — được ghi nhận công lao trước người khác.
- Visibility — được "lọt vào mắt" của lãnh đạo cấp cao.
- Reputation — danh tiếng được củng cố.
- Contacts/Network — kết nối với người có giá trị.
- Acceptance/Belonging — cảm giác được chấp nhận, thuộc về.
- Understanding — được lắng nghe, được thấu hiểu.
- Personal support — sự ủng hộ ở mức cá nhân.
- Gratitude — lòng biết ơn chân thành.
- Ownership — quyền tự chủ, làm chủ một mảng việc.
- Self-concept — cảm giác sống đúng với giá trị bản thân.
- Comfort — tránh được rắc rối, phiền toái.
Bốn nguyên tắc của Cohen-Bradford
Mô hình được vận hành qua một tư duy gồm bốn nguyên tắc nền:
- Coi đối phương là đối tác tiềm năng, không phải đối thủ hay vật cản. Ngay cả người đang chặn bạn cũng là một potential ally nếu bạn hiểu họ.
- Hiểu rõ thế giới của họ. Họ đang chịu áp lực gì? KPI của họ là gì? Sếp họ đang ép họ điều gì? Currency họ thiếu là gì?
- Ý thức về currencies của chính bạn. Bạn đang có gì trong tay để trao đi — kể cả những thứ vô hình như thông tin, sự ghi nhận, hay đơn giản là làm cho công việc của họ dễ hơn.
- Trao đổi để cả hai cùng thắng. Mục tiêu không phải "moi" được việc, mà là tạo một mối quan hệ mà cả hai đều thấy có lợi để tiếp tục.
Tình huống thực tế
Tình huống 1: PM tại một fintech ở TP.HCM và vị tech lead "khó tính"
Linh là PM tại một ví điện tử có khoảng 8 triệu người dùng ở Việt Nam. Cô cần đẩy một tính năng "chia hóa đơn nhóm" (split bill) ra trước Tết — thời điểm người ta đi ăn nhóm nhiều nhất. Vấn đề: Đức, tech lead của squad payments, liên tục đẩy task này xuống cuối backlog. Mỗi lần Linh nhắc, Đức trả lời gọn lỏn "cái đó không khẩn, hệ thống core đang nợ kỹ thuật nặng hơn".
Phản xạ đầu tiên của Linh là leo thang lên Engineering Manager để ép Đức. Nhưng cô dừng lại và áp dụng tư duy Cohen-Bradford: Đức thực sự coi trọng currency gì? Quan sát kỹ, cô nhận ra Đức là người ám ảnh với excellence và reputation kỹ thuật — anh ấy ghét nhất là bị xem như người "code ẩu chạy theo deadline". Nợ kỹ thuật của hệ thống core khiến anh mất ngủ vì nó đe dọa danh tiếng đó.
Thay vì ép, Linh đề nghị một trao đổi: cô sẽ dùng vị thế PM của mình để bảo vệ trước ban lãnh đạo một sprint dành riêng cho việc trả nợ kỹ thuật core (currency: resources + moral correctness + bảo vệ reputation của Đức), đổi lại Đức ưu tiên split bill ngay sprint kế. Cô còn chủ động viết một đoạn ngắn trong báo cáo gửi CPO ghi nhận rằng "đội payments đang chủ động xử lý nợ kỹ thuật để đảm bảo độ tin cậy" — trao currency recognition và visibility cho Đức.
Kết quả: Đức không những nhận task mà còn tự đề xuất một thiết kế gọn hơn để kịp Tết. Bài học: thứ chặn đường bạn thường không phải sự cứng đầu, mà là một currency chưa được đáp ứng. Tìm ra nó, bạn mở được nút thắt mà quyền lực không mở nổi.
Tình huống 2: Influence "ngang" với một PM khác tại Grab
Minh là PM của mảng GrabFood, cần đội của Tâm — PM mảng GrabPay — tích hợp một luồng thanh toán mới để giảm số bước checkout. Nhưng roadmap của Tâm đã kín, và quan trọng hơn, dự án này gần như chẳng đóng góp gì vào OKR của GrabPay — nó chỉ làm GrabFood đẹp số.
Đây là tình huống influence khó nhất: ảnh hưởng ngang hàng (lateral) với người có ưu tiên xung đột. Minh không có chút thẩm quyền nào với Tâm, và cũng không có "sếp chung" gần để leo thang nhanh.
Áp dụng Cohen-Bradford, Minh tự hỏi: GrabPay đang thiếu currency gì mà GrabFood có thể trao? Anh nhận ra GrabPay đang bị áp lực tăng tỷ lệ giao dịch thành công (payment success rate) — một KPI cốt lõi của họ. Mà luồng checkout mới, nếu thiết kế đúng, sẽ giảm drop-off và trực tiếp nâng success rate cho GrabPay chứ không chỉ cho GrabFood. Minh chuẩn bị một phân tích nhanh: ước tính tích hợp này có thể nâng success rate của giao dịch food lên khoảng 2–3 điểm phần trăm, tương đương một lượng giao dịch đáng kể chảy qua GrabPay.
Anh đến gặp Tâm không phải để "xin", mà để trình bày: "Đây không phải dự án của riêng GrabFood, đây là cách giúp em đạt KPI success rate của GrabPay." Currency được trao ở đây là task accomplishment (giúp Tâm đạt mục tiêu của chính cô) cộng information (dữ liệu phân tích cô có thể dùng để bảo vệ trước sếp mình). Tâm đồng ý đưa vào sprint.
Bài học: với ảnh hưởng ngang hàng, đừng bao giờ trình bày yêu cầu dưới góc nhìn lợi ích của bạn. Hãy dịch nó sang ngôn ngữ KPI và currency của họ. Người ta hành động vì mục tiêu của họ, không vì mục tiêu của bạn.
Tình huống 3: Sai lầm "trao nhầm currency" của một PM mới vào nghề
Một câu chuyện ngược, để thấy mô hình này dễ hỏng ở đâu. Hà, PM mới được tuyển vào một startup SaaS, cần một senior backend engineer tên Quang hỗ trợ xây một prototype để demo cho nhà đầu tư. Học được rằng "phải trao currency", Hà hứa với Quang: "Anh giúp em cái này thì em sẽ cho anh present trực tiếp trước nhà đầu tư, exposure lớn lắm!"
Vấn đề: Quang là kiểu kỹ sư hướng nội điển hình, ghét đứng trước đám đông, và thứ anh thiếu không phải visibility mà là thời gian không bị quấy rầy (currency: comfort + autonomy). Lời hứa "present trước investor" với anh không phải phần thưởng — nó là một gánh nặng. Quang lịch sự từ chối.
Sau khi nhận ra, Hà đổi cách tiếp cận: cô đề nghị tự mình viết toàn bộ phần tài liệu kỹ thuật và dọn sạch các ticket lặt vặt đang ngốn thời gian của Quang, để anh có một buổi chiều "không bị ai làm phiền" tập trung vào prototype. Lần này Quang nhận lời ngay. Bài học: trao currency sai còn tệ hơn không trao gì, vì nó cho thấy bạn không thực sự hiểu người đối diện. Currency chỉ có giá trị trong mắt người nhận, không phải trong mắt bạn.
Hướng dẫn từng bước
Đây là quy trình sáu bước để áp dụng Cohen-Bradford cho một tình huống ảnh hưởng cụ thể:
Bước 1 — Định nghĩa rõ mục tiêu và xác định người bạn cần ảnh hưởng. Viết ra chính xác bạn cần ai làm gì. "Tôi cần Đức đưa split bill vào sprint tới" cụ thể hơn nhiều so với "tôi cần engineering hợp tác hơn". Càng rõ, càng dễ tìm currency phù hợp.
Bước 2 — Đặt mình vào thế giới của họ. Trả lời ba câu: KPI/mục tiêu của họ là gì? Họ đang chịu áp lực hoặc thiếu thốn điều gì? Sếp họ đang đo lường họ bằng cái gì? Nếu chưa biết, đừng đoán — hãy đi hỏi, đi quan sát một vài cuộc họp, hoặc trò chuyện 1-1 để tìm hiểu.
Bước 3 — Lập danh sách currencies họ có thể coi trọng. Dùng năm nhóm currency ở trên như một checklist. Khoanh tròn 2–3 currency khả năng cao nhất với người này. Lưu ý: currency của họ có thể thay đổi theo thời điểm — một người mới thăng chức sẽ "đói" recognition khác với lúc họ đang sợ mất việc.
Bước 4 — Kiểm kê currencies của chính bạn. Bạn đang có gì để trao? PM thường giàu hơn mình nghĩ: thông tin từ khách hàng, dữ liệu, quyền tiếp cận lãnh đạo, khả năng ghi nhận công khai, khả năng gỡ rào cản cho người khác, khả năng "che chắn" để họ tập trung. Liệt kê hết.
Bước 5 — Thiết kế cuộc trao đổi. Ghép currency bạn có với currency họ cần. Hãy đóng khung đề nghị dưới góc nhìn lợi ích của họ trước, lợi ích của bạn sau. Nếu trao đổi quá lệch về phía bạn, hãy bổ sung thêm để cán cân công bằng — quan hệ bền cần cảm giác đôi bên cùng thắng.
Bước 6 — Đầu tư vào quan hệ trước khi cần. Đây là bước nhiều người bỏ qua. Đừng đợi đến lúc cần mới đi "giao dịch". Hãy gửi đi currency một cách hào phóng từ sớm — giúp đỡ, ghi nhận, chia sẻ thông tin — để khi bạn cần, "tài khoản reciprocity" đã có số dư.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm ảnh hưởng với thao túng. Cohen-Bradford không phải nghệ thuật "lừa" người khác làm việc cho bạn. Sự khác biệt nằm ở tính minh bạch và win-win: thao túng là khi chỉ một bên thắng và bên kia không biết mình đang bị dùng. Nếu bạn thấy ngại khi nói thẳng cuộc trao đổi ra, đó là dấu hiệu bạn đang trượt sang thao túng.
Lỗi 2 — Bỏ qua việc đầu tư quan hệ, chỉ "rút tiền" lúc cần. PM hay xuất hiện chỉ khi cần gì đó. Người ta nhận ra ngay. Mẹo: mỗi tuần dành thời gian "nạp tiền" vào ít nhất một mối quan hệ mà bạn chưa cần gì cả.
Lỗi 3 — Mặc định mọi người coi trọng cùng currency như mình. PM coi trọng impact và visibility nên dễ giả định ai cũng vậy. Nhiều engineer coi trọng craft và autonomy hơn nhiều. Mẹo: hãy hỏi thẳng trong 1-1 — "Điều gì khiến một dự án trở nên đáng làm với anh/em?"
Lỗi 4 — Leo thang lên cấp trên quá sớm. Mỗi lần bạn nhờ sếp ép người khác, bạn đốt một phần vốn quan hệ và tự gắn nhãn "PM không tự giải quyết được". Hãy coi việc leo thang là phương án cuối, sau khi trao đổi trực tiếp đã thất bại.
Mẹo lớn: Currency mạnh nhất mà PM thường đánh giá thấp là làm cho công việc của người khác dễ hơn. Một tài liệu rõ ràng, một spec không mơ hồ, một quyết định dứt khoát để họ khỏi chờ — đó là currency mà engineer và designer cực kỳ trân trọng, và nó hoàn toàn trong tầm tay bạn.
Bài tập thực hành
Bài 1 — Lập bản đồ currency (15 phút): Chọn một người bạn đang cần ảnh hưởng nhưng không có thẩm quyền với họ. Viết ra: (a) mục tiêu cụ thể bạn cần, (b) ba câu trả lời về thế giới của họ (KPI, áp lực, thước đo), (c) 2–3 currency họ có thể coi trọng, (d) 2–3 currency bạn đang có để trao. Đối chiếu và ghép cặp.
Bài 2 — Kiểm toán tài khoản reciprocity (10 phút): Liệt kê năm người bạn phụ thuộc nhất trong công việc. Với mỗi người, tự chấm: lần gần nhất bạn trao cho họ một currency là khi nào? Nếu với ai đó bạn chỉ toàn "rút" mà chưa "nạp", hãy lên kế hoạch một hành động nạp trong tuần này.
Bài 3 — Tái khung một yêu cầu (10 phút): Lấy một email/tin nhắn bạn đã gửi để nhờ vả ai đó. Viết lại nó sao cho mở đầu bằng lợi ích của họ và currency bạn trao, thay vì bắt đầu bằng nhu cầu của bạn. So sánh hai phiên bản.
Bài 4 — Thực chiến: Trong hai tuần tới, chọn một tình huống ảnh hưởng thật, áp dụng đủ sáu bước, rồi ghi lại: currency nào bạn đoán đúng, đoán sai? Điều gì bạn sẽ làm khác lần sau?
Tóm tắt
- PM lãnh đạo bằng ảnh hưởng, không phải thẩm quyền — đây là bản chất nghề, không phải khiếm khuyết tổ chức.
- Mô hình Cohen-Bradford đặt nền trên nguyên tắc reciprocity: ảnh hưởng là một cuộc trao đổi currency, không phải ép buộc hay van xin.
- Có năm nhóm currencies: inspiration, task, position, relationship, personal. Mỗi người coi trọng những currency khác nhau, và trao nhầm còn tệ hơn không trao.
- Quy trình sáu bước: làm rõ mục tiêu → hiểu thế giới của họ → liệt kê currency họ cần → kiểm kê currency bạn có → thiết kế trao đổi win-win → đầu tư quan hệ trước khi cần.
- Phân biệt rạch ròi giữa ảnh hưởng (minh bạch, win-win) và thao túng (một chiều, che giấu).
- Currency bị đánh giá thấp nhất mà PM luôn có sẵn: làm cho công việc của người khác dễ hơn.