Mở đầu — vì sao bài này quan trọng
Có một niềm tin sai lầm phổ biến trong giới PM: rằng đàm phán là chuyện của sales, của procurement, của legal — chứ không phải việc của người làm sản phẩm. Sự thật thì ngược lại hoàn toàn. Mỗi ngày bạn đi làm, bạn đang đàm phán liên tục mà có thể không nhận ra: đàm phán với engineering về scope của sprint tới, đàm phán với sếp về timeline launch, đàm phán với một team khác để mượn hai developer trong ba tuần, đàm phán với khách hàng lớn về việc có làm cái tính năng họ đòi hay không.
Vấn đề là phần lớn PM đàm phán theo bản năng — và bản năng thường dẫn họ vào một trong hai cái bẫy. Bẫy thứ nhất: nhượng bộ quá sớm vì sợ làm hỏng quan hệ, để rồi commit một roadmap không thể giao được. Bẫy thứ hai: cố thắng bằng mọi giá, đẩy đối phương vào chân tường, thắng được trận này nhưng phá vỡ niềm tin cho mười trận sau.
Bài học này trang bị cho bạn hai khái niệm nền tảng nhất của lý thuyết đàm phán hiện đại, đến từ chương trình Harvard Negotiation Project: BATNA và ZOPA. Đây không phải lý thuyết hàn lâm. Đây là hai công cụ tư duy giúp bạn biết chính xác mình mạnh đến đâu, đối phương mạnh đến đâu, và một thỏa thuận tốt thực sự nằm ở vùng nào. Khi bạn nắm được hai khái niệm này, bạn sẽ ngừng đàm phán bằng cảm xúc và bắt đầu đàm phán bằng cấu trúc.
Khái niệm cốt lõi
BATNA — Best Alternative To a Negotiated Agreement
BATNA là phương án tốt nhất bạn sẽ làm nếu cuộc đàm phán này thất bại — nói cách khác, là kế hoạch B tốt nhất của bạn khi deal không xảy ra. Đây chính là nguồn sức mạnh thật sự trong mọi cuộc đàm phán, và là khái niệm bị hiểu lầm nhiều nhất.
Hãy hình dung thế này. Bạn đang đàm phán với một team backend để họ làm API cho tính năng của bạn trong quý này. Sức mạnh của bạn trên bàn đàm phán không đến từ việc bạn nói hay đến mức nào, hay bạn có dễ thương hay không. Nó đến từ câu hỏi: nếu họ từ chối, bạn sẽ làm gì? Nếu câu trả lời là "tôi chẳng làm được gì, tính năng sẽ chết" — bạn yếu. Nếu câu trả lời là "tôi đã có một team platform khác sẵn sàng nhận, hoặc tôi có thể dùng một giải pháp third-party tạm thời" — bạn mạnh, vì bạn không cần deal này bằng mọi giá.
Điểm mấu chốt: BATNA của bạn là giới hạn dưới (walk-away point) của bạn. Bạn không bao giờ nên chấp nhận một thỏa thuận tệ hơn BATNA của mình, vì nếu thế, thà bỏ đi còn hơn. BATNA càng mạnh, bạn càng đàm phán được điều khoản tốt. BATNA càng yếu, bạn càng phải phụ thuộc vào thiện chí của đối phương.
Có một hệ quả quan trọng: muốn mạnh hơn trong đàm phán, đôi khi điều tốt nhất bạn làm không phải ở trên bàn đàm phán, mà là cải thiện BATNA của mình trước khi ngồi xuống. Tìm một nhà cung cấp thay thế, chuẩn bị một phương án kỹ thuật dự phòng, tạo thêm lựa chọn — mỗi cái đó đều nâng giới hạn dưới của bạn lên.
Hiểu BATNA của đối phương
Đàm phán không phải trò chơi một chiều. Đối phương cũng có BATNA của họ, và việc của bạn là ước lượng nó. Nếu bạn biết đối phương sẽ rất khó tìm phương án thay thế nếu không có bạn, bạn biết bạn đang ở thế mạnh. Ngược lại, nếu họ có hàng tá lựa chọn khác, bạn cần khiêm tốn hơn.
Một PM giỏi luôn vào cuộc đàm phán với hai con số trong đầu: BATNA của mình, và ước lượng BATNA của đối phương. Khoảng cách giữa hai cái đó quyết định ai có đòn bẩy.
ZOPA — Zone Of Possible Agreement
ZOPA là vùng thỏa thuận khả thi — khoảng giữa giới hạn dưới của bạn và giới hạn dưới của đối phương, nơi mà cả hai bên đều thấy thỏa thuận tốt hơn là bỏ đi.
Hãy cụ thể hóa. Giả sử bạn đang đàm phán deadline cho một dự án với engineering lead.
- Bạn (PM) cần launch chậm nhất là cuối tháng 9 để kịp mùa mua sắm. Đó là giới hạn của bạn — muộn hơn thì thà hoãn cả chiến dịch.
- Engineering lead nói team chỉ có thể giao sớm nhất là giữa tháng 9 nếu cắt một số tính năng phụ. Sớm hơn nữa là không khả thi về mặt kỹ thuật.
Nhưng nếu engineering nói sớm nhất là tháng 11, còn bạn cần chậm nhất tháng 9 — thì không có ZOPA. Hai vùng không giao nhau. Khi không có ZOPA, không có thỏa thuận nào làm cả hai hài lòng, và bạn có ba lựa chọn: thay đổi điều kiện (cắt scope để kéo deadline engineering về sớm), mở rộng chiếc bánh (thêm nguồn lực để rút ngắn thời gian), hoặc chấp nhận đi theo BATNA của mình (hoãn chiến dịch).
Hiểu được có ZOPA hay không ngay từ đầu giúp bạn tiết kiệm hàng giờ tranh cãi vô ích về một thỏa thuận vốn không tồn tại.
Anchor và mối liên hệ với ZOPA
Trong vùng ZOPA, vị trí cuối cùng của thỏa thuận thường bị ảnh hưởng mạnh bởi con số được đưa ra đầu tiên — gọi là anchor. Người đưa ra đề nghị đầu tiên một cách hợp lý thường kéo kết quả về phía mình. Bài này chỉ giới thiệu khái niệm; kỹ thuật anchoring và framing sẽ được đào sâu ở bài sau. Điều cần nhớ bây giờ: anchor chỉ hiệu quả khi nó nằm gần rìa ZOPA, chứ không phải một con số phi thực tế nằm ngoài vùng khả thi — vì cái đó chỉ khiến đối phương mất niềm tin và rời bàn.
Tình huống thực tế
Ví dụ 1: PM Tiki đàm phán nguồn lực engineering
Lan là PM tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là sàn X cho dễ hình dung). Cô cần tính năng "mua trước trả sau" (BNPL) lên production trước Tết. Vấn đề: team payment đang ngập việc, engineering manager của họ nói thẳng "quý này không nhận thêm".
PM trung bình sẽ nài nỉ, hoặc leo lên sếp than phiền. Lan làm khác. Trước cuộc họp, cô xây dựng BATNA cho mình. Cô tìm hiểu và phát hiện có một nhà cung cấp BNPL bên ngoài (giả định: một fintech tên Kredivo) cung cấp SDK tích hợp sẵn, chỉ cần 3 tuần frontend work mà không động đến team payment. Cô cũng tính ra chi phí: phí giao dịch cao hơn 0,8% nhưng triển khai nhanh hơn hai tháng.
Khi vào họp, Lan không đe dọa. Cô chỉ trình bày: "Mình rất muốn team payment làm cái này vì làm in-house sẽ rẻ hơn về dài hạn. Nhưng nếu quý này không khả thi, mình sẽ đi với phương án Kredivo để kịp Tết." Đây chính là BATNA được nói ra một cách điềm tĩnh.
Kết quả thú vị: engineering manager, vốn nghĩ Lan kẹt cứng và phụ thuộc hoàn toàn vào team mình, bỗng nhận ra cô có lối thoát. Ông không muốn mất quyền kiểm soát một phần quan trọng của hệ thống thanh toán vào tay third-party. Hai bên cuối cùng đạt thỏa thuận: team payment giao phần core trong 6 tuần, Lan giảm scope đợt một xuống còn một phương thức trả góp.
Bài học: Sức mạnh của Lan không đến từ giọng điệu hay chức danh, mà từ việc cô đã chuẩn bị BATNA trước khi ngồi xuống. Một BATNA tốt được nói ra đúng cách không phải là lời đe dọa — nó là sự thật khiến đối phương phải tính lại bài toán của họ.
Ví dụ 2: ZOPA trong đàm phán với khách hàng enterprise
Minh là PM của một công ty SaaS B2B ở Singapore phục vụ thị trường Đông Nam Á. Một khách hàng lớn — một ngân hàng ở Việt Nam — yêu cầu một tính năng tùy chỉnh (custom SSO theo chuẩn nội bộ của họ) và dọa sẽ không gia hạn hợp đồng 200.000 USD/năm nếu không có.
Minh ngồi xuống vẽ ZOPA. Phía khách hàng: họ cần SSO này để qua được vòng audit bảo mật nội bộ — không có nó, họ thật sự không gia hạn được, đây là điều kiện cứng. BATNA của khách hàng (đổi sang nhà cung cấp khác) rất tốn kém vì họ đã tích hợp sâu, ước tính mất 6 tháng migration. Phía Minh: chi phí xây SSO này khoảng 4 tuần engineering, và nó có thể tái sử dụng cho ba khách hàng ngân hàng khác trong pipeline.
Khi vẽ ra, Minh thấy rõ ZOPA rất rộng: khách hàng sẵn lòng trả thêm hoặc cam kết hợp đồng dài hơn để có tính năng; còn chi phí của Minh thấp và còn tạo giá trị tái sử dụng. Thay vì miễn phí làm (nhượng bộ) hay từ chối thẳng (đẩy ra ngoài ZOPA), Minh đề xuất: làm SSO, đổi lại khách ký hợp đồng 2 năm thay vì 1 năm, và đồng ý làm reference customer cho mảng ngân hàng. Khách đồng ý ngay.
Bài học: Khi bạn lập bản đồ ZOPA — biết giới hạn thật của mỗi bên và chi phí/giá trị thực — bạn ngừng nghĩ "thắng hay thua" và bắt đầu tìm điểm trong vùng giao thoa nơi cả hai cùng được. Minh không chỉ giữ được 200.000 USD, mà còn mở rộng được chiếc bánh.
Ví dụ 3: Khi không có ZOPA — và biết khi nào nên bỏ đi
Hùng là PM tại một startup logistics ở Hà Nội. Một đối tác vận chuyển lớn đề nghị tích hợp độc quyền: họ sẽ là carrier duy nhất trên nền tảng, đổi lại giá cước rẻ hơn 15%. Nghe hấp dẫn về chi phí ngắn hạn.
Nhưng Hùng tính BATNA và giới hạn của mình. Walk-away point của anh: nền tảng không thể phụ thuộc một carrier duy nhất, vì như thế là tự trao toàn bộ đòn bẩy giá cho đối tác trong tương lai — một rủi ro chiến lược. Đây là lằn ranh đỏ. Phía đối tác thì khăng khăng: độc quyền hoặc không có ưu đãi gì cả. Hai vùng không giao nhau — không có ZOPA.
Hùng nhận ra cố gắng tìm thỏa thuận ở đây là vô ích, và quan trọng hơn, BATNA của anh (giữ mô hình đa carrier với giá cước hiện tại) thật ra vẫn tốt hơn việc nhận deal độc quyền. Anh lịch sự từ chối.
Bài học: Một kỹ năng đàm phán bị xem nhẹ là biết khi nào không có thỏa thuận nào đáng ký. Nếu mọi đề nghị khả thi đều tệ hơn BATNA của bạn, thì việc rời bàn không phải là thất bại — nó là quyết định đúng. BATNA tồn tại chính là để bảo vệ bạn khỏi những deal trông hấp dẫn nhưng làm bạn yếu đi.
Hướng dẫn từng bước
Trước mỗi cuộc đàm phán quan trọng, hãy chạy qua quy trình 6 bước sau. Mất 20 phút chuẩn bị, tiết kiệm hàng giờ tranh cãi.
- Xác định BATNA của bạn. Tự hỏi: "Nếu deal này không xảy ra, điều tốt nhất tôi có thể làm là gì?" Viết ra cụ thể, kèm chi phí và thời gian. Đừng để mơ hồ — "tôi sẽ tìm cách khác" không phải BATNA; "tôi dùng SDK của bên Y, mất 3 tuần frontend" mới là BATNA.
- Cải thiện BATNA nếu có thể. Trước khi đàm phán, dành công sức tạo thêm lựa chọn. Một BATNA mạnh hơn ở hậu trường còn giá trị hơn mọi mẹo nói chuyện ở bàn đàm phán.
- Xác định walk-away point của bạn. Đây là điều khoản tệ nhất bạn vẫn chấp nhận — bằng đúng với giá trị BATNA. Dưới mức này, bạn bỏ đi.
- Ước lượng BATNA và walk-away point của đối phương. Họ sẽ làm gì nếu không có bạn? Việc đó tốn kém với họ đến đâu? Càng tốn kém, đòn bẩy của bạn càng lớn.
- Vẽ ZOPA. Đặt walk-away point của hai bên cạnh nhau. Chúng có giao nhau không? Nếu có, vùng giao là ZOPA — mục tiêu của bạn là đạt thỏa thuận trong vùng đó, càng về phía mình càng tốt. Nếu không giao, bạn phải thay đổi điều kiện (cắt scope, thêm nguồn lực, đổi biến số) hoặc chuẩn bị đi theo BATNA.
- Tìm cách mở rộng chiếc bánh. Trước khi tranh giành phần bánh, hỏi: có biến số nào khác ngoài cái đang tranh cãi không? Thời gian, scope, hợp đồng dài hạn, sự đánh đổi giữa các tính năng — thường có những trao đổi mà một bên định giá cao còn bên kia định giá thấp. Đó là nơi tạo ra giá trị cho cả hai.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm BATNA với mong muốn. BATNA không phải là điều bạn muốn đạt được, mà là điều bạn thực sự sẽ làm nếu không có deal. Đừng tự huyễn hoặc một BATNA mạnh hơn thực tế — nó sẽ khiến bạn quá cứng và làm hỏng những thỏa thuận tốt.
Lỗi 2: Không bao giờ ước lượng BATNA của đối phương. Nhiều PM chỉ chăm chăm vào thế của mình mà quên hỏi đối phương sẽ ra sao nếu không có mình. Đây là nửa còn lại của bức tranh đòn bẩy.
Lỗi 3: Tiết lộ walk-away point quá sớm. Walk-away point của bạn là thông tin nhạy cảm. Nói ra sớm là tự cắt vùng thương lượng của mình. Bạn có thể ám chỉ BATNA mạnh để tạo đòn bẩy, nhưng không cần phơi bày con số giới hạn chính xác.
Lỗi 4: Cố đàm phán khi không có ZOPA. Nếu các giới hạn không giao nhau, không có lời lẽ nào tạo ra thỏa thuận tốt. Đừng phí thời gian; hãy thay đổi các biến số (mở rộng bánh) hoặc rút lui một cách tôn trọng.
Lỗi 5: Coi đàm phán là zero-sum. Bẫy lớn nhất với PM. Hầu hết đàm phán nội bộ không phải trò chơi tổng bằng không — vẫn còn scope để cắt, timeline để dịch, ưu tiên để đổi. Tìm những biến số mà mỗi bên định giá khác nhau.
Mẹo: Luôn giữ quan hệ tốt ngay cả khi đàm phán cứng rắn. Trong môi trường PM, bạn sẽ gặp lại đối phương ở cả trăm cuộc đàm phán sau. Thắng một deal mà phá vỡ niềm tin là một thương vụ lỗ. Phong cách phù hợp với văn hóa Việt Nam và Đông Nam Á: cứng về vấn đề (substance), mềm về con người (relationship) — tách bạch hai thứ này.
Mẹo: Khi bí, hãy hỏi "điều gì sẽ khiến chuyện này khả thi với anh/chị?" Câu hỏi này thường hé lộ giới hạn thật và biến số ẩn của đối phương, giúp bạn nhìn ra ZOPA mà trước đó không thấy.
Bài tập thực hành
- Lập bản đồ một cuộc đàm phán sắp tới. Chọn một tình huống thật bạn sẽ gặp trong hai tuần tới (xin nguồn lực, đàm phán scope, thuyết phục một team). Viết ra: BATNA của bạn (cụ thể, kèm chi phí), walk-away point của bạn, ước lượng BATNA của đối phương, và vẽ ZOPA. Có giao nhau không?
- Bài tập cải thiện BATNA. Với cùng tình huống trên, liệt kê ba việc bạn có thể làm trước khi đàm phán để nâng BATNA của mình lên. Chọn một việc khả thi nhất và thực hiện nó.
- Phân tích một deal đã qua. Nhớ lại một lần đàm phán bạn cảm thấy mình thua thiệt. Nhìn lại: lúc đó BATNA thật của bạn là gì? Bạn có chấp nhận điều khoản tệ hơn BATNA của mình không? Nếu có, tại sao — vì sợ làm hỏng quan hệ, hay vì không biết BATNA của mình?
- Tìm biến số mở rộng bánh. Với tình huống ở bài 1, liệt kê ít nhất ba biến số ngoài thứ chính đang tranh cãi (ví dụ: thời gian, scope, cam kết dài hạn, sự đánh đổi tính năng). Với mỗi biến, bên nào định giá nó cao hơn? Đó là nơi tạo thỏa thuận đôi bên cùng có lợi.
Tóm tắt
Đàm phán không phải là tài năng bẩm sinh hay khả năng nói khéo — nó là một kỷ luật có cấu trúc, và hai trụ cột của cấu trúc đó là BATNA và ZOPA.
BATNA (phương án thay thế tốt nhất nếu deal thất bại) là nguồn sức mạnh thật sự của bạn. Nó định ra walk-away point — ranh giới mà dưới đó bạn nên bỏ đi. Muốn mạnh hơn ở bàn đàm phán, hãy cải thiện BATNA trước khi ngồi xuống, và luôn ước lượng BATNA của đối phương để biết ai cầm đòn bẩy.
ZOPA (vùng thỏa thuận khả thi) là khoảng giao giữa giới hạn của hai bên — nơi mọi thỏa thuận tốt phải nằm trong đó. Nếu có ZOPA, việc của bạn là đạt thỏa thuận trong vùng đó, càng nghiêng về phía mình càng tốt. Nếu không có ZOPA, đừng phí sức tranh cãi — hãy thay đổi biến số để tạo ra nó, hoặc tôn trọng BATNA của mình mà rời đi.
Và quan trọng nhất với một PM: đàm phán hiếm khi là zero-sum. Trước khi tranh giành phần bánh, hãy tìm cách làm chiếc bánh to ra — những biến số mà mỗi bên định giá khác nhau chính là mỏ vàng của thỏa thuận đôi bên cùng thắng. Cứng về vấn đề, mềm về con người, và luôn nhớ rằng đối phương hôm nay sẽ là đối tác đàm phán của bạn ngày mai.