Mở đầu — vì sao bài này quan trọng
Hãy hình dung một tình huống mà bất kỳ Product Owner nào cũng từng trải qua: đội Sales vừa ký được hợp đồng với một khách hàng lớn, và để chốt deal họ đã hứa rằng tính năng X sẽ có mặt trong tháng tới. Cùng lúc đó, đội Engineering nhìn vào backlog và lắc đầu — tính năng X cần ít nhất ba tháng, chưa kể nó sẽ phá vỡ kiến trúc hiện tại. Hai bên nhìn về phía bạn. Sales nói: "Anh phải ưu tiên cái này, không thì mất khách." Engineering nói: "Nếu làm gấp, hệ thống sẽ sập và lúc đó còn tệ hơn."
Đây chính là bản chất công việc của Product Owner: bạn đứng ở điểm giao của rất nhiều lợi ích đối nghịch. Một PO giỏi về kỹ thuật viết User Story nhưng dở trong việc xử lý xung đột giữa các bên liên quan thường thất bại — không phải vì sản phẩm tồi, mà vì họ bị các bên kéo về nhiều hướng cho đến khi sản phẩm mất phương hướng, đội phát triển kiệt sức, và niềm tin tan vỡ.
Xung đột giữa stakeholder không phải là dấu hiệu của một tổ chức rối loạn. Ngược lại, xung đột là bình thường và lành mạnh khi nhiều người cùng quan tâm tới một sản phẩm có giá trị. Vấn đề không nằm ở việc có xung đột hay không, mà ở chỗ bạn xử lý nó như thế nào: né tránh để nó âm ỉ, hay đối diện và biến nó thành quyết định tốt hơn. Bài này tập trung hoàn toàn vào kỹ năng giải quyết xung đột — khác với bài "Stakeholder Management — Mapping & Strategy" (lập bản đồ ai có quyền lực, ai cần được chăm sóc) và bài "Stakeholder Communication — Cadence và format" (nhịp độ giao tiếp). Ở đây, chúng ta học cách bước vào giữa hai bên đang căng thẳng và đưa họ ra khỏi đó.
Khái niệm cốt lõi
Xung đột không phải về con người, mà về lợi ích
Sai lầm phổ biến nhất là coi xung đột như chuyện "ông A khó tính" hay "đội B bảo thủ". Thực tế, mỗi stakeholder đang bảo vệ một lợi ích chính đáng xuất phát từ vai trò của họ. Sales bị đo bằng doanh số nên họ tối ưu cho việc chốt deal. Engineering bị đo bằng độ ổn định hệ thống nên họ tối ưu cho tính bền vững. Customer Support bị đo bằng số ticket nên họ ưu tiên sửa bug. Marketing bị đo bằng lượng lead nên họ muốn các tính năng "ăn ảnh". Không ai sai cả — họ chỉ đang nhìn sản phẩm qua lăng kính chỉ số (metric) của riêng mình.
Khi bạn hiểu điều này, công việc của bạn chuyển từ "phân xử ai đúng ai sai" sang "tìm điểm mà các lợi ích này có thể cùng tồn tại". Đây là tư duy nền tảng.
Vị thế (Position) và lợi ích thật (Interest)
Một khái niệm kinh điển từ phương pháp đàm phán Harvard (cuốn Getting to Yes): hãy phân biệt position — điều người ta nói họ muốn — với interest — điều người ta thật sự cần.
Khi Sales nói "Phải có tính năng X trong tháng tới" (position), interest thật của họ có thể là "Tôi cần một thứ gì đó đủ thuyết phục để giữ chân khách hàng này." Hai điều này rất khác nhau. Nếu bạn chỉ tranh cãi quanh position, bạn rơi vào thế thắng-thua. Nếu bạn đào tới interest, bạn có thể thấy rằng một bản demo trước, một cam kết lộ trình, hoặc một giải pháp tạm thời (workaround) cũng đáp ứng được interest của Sales mà không cần đảo lộn cả backlog.
Năm phong cách xử lý xung đột (Thomas-Kilmann)
Mô hình Thomas-Kilmann mô tả năm cách con người phản ứng với xung đột, đặt trên hai trục: mức độ quyết đoán (theo đuổi lợi ích của mình) và mức độ hợp tác (quan tâm lợi ích người khác):
- Competing (Cạnh tranh): thắng bằng mọi giá. Dùng khi cần quyết định nhanh trong khủng hoảng.
- Accommodating (Nhường nhịn): chiều theo bên kia. Dùng khi vấn đề quan trọng với họ hơn với bạn.
- Avoiding (Né tránh): lờ đi. Hiếm khi tốt, nhưng đôi khi hữu ích để hạ nhiệt.
- Compromising (Thỏa hiệp): mỗi bên nhường một nửa. Nhanh nhưng thường chẳng ai hài lòng hoàn toàn.
- Collaborating (Hợp tác): tìm giải pháp win-win mở rộng chiếc bánh. Tốn công nhất nhưng cho kết quả bền nhất.
Dữ liệu là trọng tài trung lập
Trong môi trường Scrum, PO có một vũ khí mạnh để giải quyết xung đột: dữ liệu và sự minh bạch. Thay vì để hai bên đấu khẩu bằng cảm tính, hãy đưa xung đột về một sân chơi chung — Product Backlog đã được ordering rõ ràng, các kỹ thuật định lượng giá trị như Cost of Delay hay WSJF, và Product Goal. Khi mọi người cùng nhìn vào một bảng số liệu, cảm xúc hạ xuống và lý trí lên tiếng.
Tình huống thực tế
Ví dụ 1 — Tiki: Sales hứa, Engineering không kịp
Tại một sàn thương mại điện tử lớn ở Việt Nam (gọi là sàn TM-Việt cho dễ hình dung, mô phỏng theo bối cảnh Tiki/Sendo), đội B2B Sales chốt một hợp đồng trị giá 4 tỷ đồng/năm với một chuỗi siêu thị. Để chốt, Giám đốc Sales hứa rằng tính năng "đồng bộ tồn kho theo thời gian thực giữa kho của khách và sàn" sẽ live trong 6 tuần.
PO nhận tin này trong một cuộc họp căng thẳng. Engineering Lead phản ứng ngay: tính năng cần tích hợp với hệ thống ERP của khách qua API chưa từng có tài liệu, ước tính 4 tháng. Không khí đông cứng.
Diễn giải: Thay vì chọn phe, PO làm ba việc. Thứ nhất, anh tách position khỏi interest — hỏi riêng Sales: "Khách thật sự cần đồng bộ real-time, hay họ chỉ sợ tồn kho lệch dẫn tới bán hàng quá số lượng?" Hóa ra interest thật là "không để xảy ra oversell". Thứ hai, anh đưa Engineering và Sales vào cùng một bàn với một bản WSJF đơn giản, cho thấy nếu nhồi tính năng này vào, ba tính năng đang dở dang cho 200 khách hàng hiện hữu sẽ bị trễ — Cost of Delay tổng cộng lớn hơn hợp đồng mới. Thứ ba, anh đề xuất một giải pháp trung gian: đồng bộ tồn kho theo lô (batch) mỗi 15 phút thay vì real-time, làm được trong 5 tuần, đủ ngăn oversell.
Khách hàng chấp nhận giải pháp batch. Hợp đồng được giữ, Engineering không phải đập kiến trúc, và các khách hàng cũ không bị bỏ rơi.
Bài học: Khi đào tới interest thật và đưa dữ liệu lên bàn, một xung đột tưởng như win-lose biến thành win-win. PO không nói "không" với Sales, cũng không ép Engineering — anh mở rộng không gian giải pháp.
Ví dụ 2 — Grab: Marketing và Engineering tranh nhau Sprint
Tại một công ty công nghệ gọi xe khu vực Đông Nam Á, đội Marketing muốn ra mắt một chiến dịch khuyến mãi lớn dịp Tết với tính năng "vòng quay may mắn" trong app, hạn chót cứng vì đã book quảng cáo. Engineering thì đang giữa một đợt trả nợ kỹ thuật (tech debt) quan trọng để chống quá tải dịp cao điểm — chính dịp Tết. Hai bên đều đúng, và cả hai đều cần đúng Sprint đó.
PO đối mặt với áp lực từ Giám đốc Marketing, người có ảnh hưởng lớn và đe dọa "leo thang lên CEO".
Diễn giải: PO không né tránh và cũng không nhường vô điều kiện. Cô tổ chức một buổi làm việc 60 phút, mời cả hai bên cùng Scrum Master. Cô đặt lại khung vấn đề: "Mục tiêu chung của chúng ta dịp Tết là gì?" — câu trả lời thống nhất là "tăng trưởng đơn hàng mà không sập app". Từ đó, hai yêu cầu không còn đối nghịch mà cùng phục vụ một Product Goal. Cô dùng kỹ thuật chia nhỏ: tính năng vòng quay được cắt thành phiên bản tối giản (chỉ một loại phần thưởng, không cá nhân hóa), giảm 70% khối lượng. Phần tech debt được ưu tiên những hạng mục liên quan trực tiếp tới khả năng chịu tải, hoãn phần còn lại. Cả hai cùng vào Sprint.
Khi Giám đốc Marketing vẫn muốn nhiều hơn, PO dùng sự minh bạch: cô cho ông xem capacity thực của đội và hỏi "Nếu anh là người chịu trách nhiệm cuối cùng khi app sập đúng đêm Giao thừa, anh sẽ chọn gì?" Câu hỏi đặt ông vào vị trí của người ra quyết định, không phải người đòi hỏi.
Bài học: Đưa các bên trở về mục tiêu chung cao hơn (Product Goal) là cách mạnh nhất để hòa giải. Khi không thể đáp ứng tất cả, hãy minh bạch về sự đánh đổi và để stakeholder cùng gánh trách nhiệm chọn lựa.
Ví dụ 3 — Xung đột âm ỉ giữa hai Product Owner
Tại một ngân hàng số ở Việt Nam đang scale, có hai đội cùng làm trên một sản phẩm: đội Onboarding và đội Payments. Hai PO ngầm tranh giành nguồn lực của đội Platform dùng chung. Không ai nói thẳng; thay vào đó mỗi người âm thầm gây áp lực riêng lên Platform Lead, khiến đội này quá tải và bắt đầu trễ cả hai bên. Xung đột "ngầm" này nguy hiểm hơn xung đột công khai vì nó ăn mòn niềm tin mà không ai nhận ra nguyên nhân.
Diễn giải: Khi nhận ra triệu chứng (Platform liên tục trễ, hai PO đổ lỗi cho nhau sau lưng), một PO chủ động phá vỡ sự né tránh. Anh đề nghị một cuộc trao đổi thẳng thắn ba bên với Platform Lead, đặt mọi yêu cầu lên một backlog chung và ordering công khai theo giá trị kinh doanh. Lần đầu tiên, cả hai đội thấy được bức tranh toàn cảnh và nhận ra họ đang tự bắn vào chân nhau. Họ thống nhất một cơ chế: mỗi hai tuần, hai PO cùng Platform Lead họp 30 phút để ordering lại danh sách yêu cầu chung.
Bài học: Xung đột nguy hiểm nhất là loại không được nói ra. Nhiệm vụ của PO là đưa nó ra ánh sáng. Né tránh không làm xung đột biến mất — nó chỉ chuyển chi phí sang nơi khó nhìn thấy hơn.
Hướng dẫn từng bước
Dưới đây là một quy trình bảy bước bạn có thể áp dụng cho hầu hết xung đột stakeholder:
Bước 1 — Hạ nhiệt và tách bạch. Khi xung đột đang nóng, đừng cố giải quyết ngay tại chỗ trước đám đông. Ghi nhận: "Tôi nghe thấy đây là vấn đề quan trọng với cả hai bên. Hãy cho tôi sắp xếp một buổi để chúng ta giải quyết tử tế." Tách cảm xúc khỏi nội dung.
Bước 2 — Lắng nghe để hiểu interest, không phải position. Gặp riêng từng bên nếu cần. Hỏi câu hỏi "tại sao" nhiều lớp: "Vì sao tính năng này quan trọng? Điều gì xảy ra nếu không có nó? Nó giải quyết nỗi đau gì cho khách?" Mục tiêu là tìm interest thật ẩn sau lời đòi hỏi.
Bước 3 — Tái khung về mục tiêu chung. Đưa các bên trở về Product Goal hoặc mục tiêu kinh doanh cấp cao. "Tất cả chúng ta đều muốn X. Câu hỏi là làm thế nào đạt X tốt nhất với nguồn lực hiện có." Điều này biến đối thủ thành đồng đội cùng giải một bài toán.
Bước 4 — Đưa dữ liệu lên bàn. Dùng Product Backlog minh bạch, Cost of Delay, WSJF, dữ liệu sử dụng sản phẩm, capacity của đội. Dữ liệu chuyển cuộc tranh luận từ "ai to tiếng hơn" sang "đâu là quyết định tốt nhất".
Bước 5 — Mở rộng không gian giải pháp. Đừng dừng ở hai lựa chọn ban đầu. Chia nhỏ tính năng, đề xuất giải pháp tạm thời, điều chỉnh phạm vi, đề nghị thử nghiệm có giới hạn. Thường tồn tại phương án thứ ba mà chưa ai nghĩ tới.
Bước 6 — Quyết định và làm rõ quyền quyết định. Là PO, bạn nắm accountability về ordering Product Backlog — đó là quyền và trách nhiệm chính thức của bạn theo Scrum Guide. Sau khi lắng nghe, hãy quyết và nói rõ lý do. Stakeholder có thể không hài lòng, nhưng họ sẽ tôn trọng một quyết định minh bạch hơn là sự lưỡng lự.
Bước 7 — Ghi lại và theo dõi. Ghi lại quyết định, lý do, và những đánh đổi đã chấp nhận. Khi cảm xúc nguội đi, một bản ghi rõ ràng ngăn xung đột bùng lại và xây dựng niềm tin rằng quá trình là công bằng.
Lỗi thường gặp & mẹo
Lỗi 1 — Làm người đưa tin thụ động. Nhiều PO chỉ chuyển yêu cầu từ stakeholder xuống đội mà không lọc, không phân xử. Họ trở thành "proxy" thay vì người ra quyết định. Hậu quả: backlog phình to, đội bị kéo mọi hướng. Mẹo: Hãy nhớ ordering là quyền của bạn. Bạn được phép nói "chưa phải bây giờ".
Lỗi 2 — Né tránh để giữ hòa khí. Vì sợ mất lòng, PO trì hoãn đối diện xung đột. Nó âm ỉ rồi bùng nổ lớn hơn. Mẹo: Đối diện sớm khi xung đột còn nhỏ. Xung đột giống vết rò nước — bịt sớm rẻ hơn nhiều.
Lỗi 3 — Để xung đột thành chuyện cá nhân. Khi bạn nói "đội Engineering lúc nào cũng bi quan", bạn đã biến vấn đề lợi ích thành công kích con người. Mẹo: Luôn tách con người khỏi vấn đề. Tấn công bài toán, không tấn công người.
Lỗi 4 — Nhường người to tiếng nhất (HiPPO). HiPPO — Highest Paid Person's Opinion — ý kiến của người lương cao nhất. Chiều theo sếp to tiếng dù dữ liệu nói khác là cách nhanh nhất đánh mất uy tín. Mẹo: Dùng dữ liệu và câu hỏi để mời chính người đó nhìn lại, thay vì đối đầu trực diện.
Lỗi 5 — Thỏa hiệp nửa vời theo phản xạ. "Chia đôi" nghe công bằng nhưng thường tạo ra giải pháp mà không bên nào thật sự dùng được. Mẹo: Trước khi thỏa hiệp, hãy thử hợp tác để mở rộng chiếc bánh.
Mẹo về leo thang (escalation): Đôi khi bạn không đủ thẩm quyền quyết. Leo thang không phải thất bại — nó là công cụ. Nhưng hãy leo thang đúng cách: trình bày vấn đề, các phương án, đề xuất của bạn, và xin một quyết định cụ thể, thay vì đẩy mâu thuẫn thô lên cho cấp trên xử lý.
Mẹo văn hóa Việt Nam: Trong môi trường làm việc Việt Nam, yếu tố "giữ thể diện" rất mạnh. Phê phán công khai một stakeholder lớn tuổi hoặc cấp cao trong cuộc họp có thể phản tác dụng nặng nề. Hãy ưu tiên trao đổi 1-1 trước, để người đó "lùi" một cách có thể diện, rồi mới chốt công khai. Đây là kỹ năng mềm quan trọng mà các framework phương Tây ít nhắc tới.
Bài tập thực hành
Bài tập 1 — Tách position khỏi interest. Lấy một yêu cầu xung đột gần đây bạn từng gặp (hoặc giả định). Viết ra: (a) position — điều stakeholder nói họ muốn; (b) ba interest có thể ẩn sau đó; (c) ít nhất hai giải pháp thay thế đáp ứng interest mà không cần làm đúng position ban đầu.
Bài tập 2 — Đóng vai (role-play). Cùng một đồng nghiệp, dựng lại tình huống "Sales hứa, Engineering không kịp". Một người đóng Sales kiên quyết, một người đóng PO. PO phải áp dụng quy trình bảy bước. Sau 15 phút, đổi vai. Ghi lại: bước nào khó nhất với bạn và vì sao.
Bài tập 3 — Chọn phong cách Thomas-Kilmann. Liệt kê năm xung đột khác nhau (ví dụ: khủng hoảng production cần quyết ngay; bất đồng nhỏ về màu nút bấm; tranh chấp nguồn lực dài hạn giữa hai đội...). Với mỗi tình huống, chọn phong cách phù hợp nhất trong năm phong cách và giải thích lý do. Mục tiêu là rèn phản xạ chọn công cụ đúng cho ngữ cảnh.
Bài tập 4 — Soạn một escalation. Viết một email/tin nhắn leo thang dài tối đa 150 từ cho một xung đột bạn không tự quyết được. Phải có đủ: bối cảnh ngắn gọn, các phương án, đánh đổi của từng phương án, đề xuất của bạn, và yêu cầu quyết định cụ thể kèm hạn chót.
Tóm tắt
Xung đột giữa các bên liên quan là một phần tất yếu — và lành mạnh — của công việc Product Owner. Mỗi stakeholder đang bảo vệ một lợi ích chính đáng xuất phát từ vai trò và chỉ số đo lường của họ; nhiệm vụ của bạn không phải phân xử ai đúng ai sai, mà là tìm điểm các lợi ích đó cùng tồn tại. Chìa khóa nằm ở việc phân biệt position (điều người ta nói muốn) với interest (điều người ta thật sự cần), rồi mở rộng không gian giải pháp thay vì mắc kẹt trong thế thắng-thua.
Hãy ghi nhớ ba trụ cột: lắng nghe để hiểu interest, tái khung về mục tiêu chung (Product Goal), và đưa dữ liệu lên bàn để biến cảm xúc thành quyết định lý trí. Áp dụng quy trình bảy bước một cách linh hoạt, chọn phong cách xử lý phù hợp với từng ngữ cảnh, và đừng bao giờ né tránh — xung đột âm ỉ là loại nguy hiểm nhất. Cuối cùng, hãy dùng quyền ordering Product Backlog của bạn một cách minh bạch và can đảm: một quyết định rõ ràng kèm lý do luôn xây dựng niềm tin tốt hơn sự lưỡng lự. Một PO giải quyết xung đột tốt không phải người làm hài lòng tất cả mọi người — mà là người giúp cả tổ chức cùng tiến tới sản phẩm có giá trị nhất.