Mở đầu — vì sao bài này quan trọng
Hãy thành thật với nhau một điều: phần lớn nỗi đau của một Product Owner không nằm ở việc viết user story hay sắp xếp backlog. Nó nằm ở những cuộc trò chuyện như thế này:
> CEO nhắn trong group lúc 9 giờ tối: "Đối thủ vừa ra tính năng live chat. Tháng sau mình phải có. Khách hàng lớn đang hỏi."
Trong khi đó, Product Goal hiện tại của team bạn đang là "Giảm tỷ lệ rớt giỏ hàng ở bước thanh toán xuống dưới 20%" — một mục tiêu đã được thống nhất, đã có dữ liệu hậu thuẫn, và team đang đi được nửa đường.
Bạn có ba lựa chọn tệ: (1) nói "không" thẳng thừng và bị gắn mác "PO cứng đầu, không hiểu business"; (2) nói "vâng" ngay và đốt cháy Product Goal đang dang dở, kéo theo cả uy tín về dự đoán; hoặc (3) im lặng nhận về rồi để team gánh, dẫn đến cháy sprint và mất niềm tin từ Developers.
Đàm phán scope (negotiate scope) chính là kỹ năng giúp bạn thoát khỏi cái bẫy nhị phân "yes/no" này. Nó không phải là nghệ thuật từ chối khéo léo, cũng không phải kỹ năng "lươn lẹo" để né việc. Bản chất của nó là: biến một yêu cầu thành một cuộc trao đổi về giá trị, ràng buộc và đánh đổi (trade-off), để cuối cùng cả bạn và stakeholder cùng đưa ra quyết định tốt hơn quyết định ban đầu.
Đây cũng là một chủ đề mà bài thi PSPO I rất thích kiểm tra một cách gián tiếp: PO là người chịu trách nhiệm tối đa hóa giá trị của sản phẩm, nhưng đồng thời không ai được ép Developers làm việc theo yêu cầu của người khác, và PO có toàn quyền với nội dung lẫn thứ tự của Product Backlog. Đàm phán scope chính là nơi ba nguyên tắc này va vào nhau trong đời thực.
Khái niệm cốt lõi
Scope không phải là "danh sách việc", scope là "ranh giới của giá trị"
Sai lầm gốc rễ khiến đàm phán scope trở nên căng thẳng là khi cả hai bên coi scope như một danh sách tính năng cố định: hoặc làm, hoặc không làm. Một PO giỏi nhìn scope như một biến số có thể co giãn xoay quanh một mục tiêu (outcome). Khi CEO muốn "live chat", điều ông ấy thực sự muốn không phải là khung chat — đó là giữ chân khách hàng lớn và không thua đối thủ về mặt cảm nhận. Live chat chỉ là một giải pháp giả định cho vấn đề đó.
Khi bạn nâng cuộc trò chuyện từ "tính năng" lên "vấn đề cần giải quyết", scope tự nhiên trở nên đàm phán được. Bạn có thể đề xuất một phiên bản nhỏ hơn (một nút "Gọi lại cho tôi"), một giải pháp rẻ hơn (tích hợp một công cụ chat bên thứ ba như Tawk.to thay vì tự xây), hoặc một thời điểm khác (sau khi xong Product Goal hiện tại).
Bốn đòn bẩy đàm phán: Scope — Time — Quality — Cost
Trong mọi cuộc đàm phán scope, bạn luôn có bốn "núm vặn":
- Scope (phạm vi): làm bao nhiêu, làm những gì.
- Time (thời gian): khi nào có.
- Quality (chất lượng): mức độ hoàn thiện — và đây là núm mà PO không bao giờ nên vặn xuống, vì Definition of Done là cam kết chất lượng bất khả xâm phạm. Hạ chất lượng để kịp deadline chính là tạo nợ kỹ thuật (technical debt) một cách lén lút.
- Cost (nguồn lực): thêm người, thuê ngoài, mua giải pháp có sẵn.
Khung NUT: Need — Use — Time (lọc yêu cầu trước khi nói có)
Trước khi đàm phán, hãy đặt ba câu hỏi để hiểu yêu cầu thực sự:
- Need (Nhu cầu): Vấn đề gốc đằng sau yêu cầu này là gì? Ai đang đau? Đau cỡ nào? "Khách hàng lớn nào đang hỏi? Họ sẽ rời đi nếu không có nó chứ?"
- Use (Sử dụng): Nếu xây ra, ai dùng, dùng thế nào, tần suất ra sao? Yêu cầu này có thực sự được dùng hay chỉ là "cho yên tâm"?
- Time (Thời điểm): Deadline "tháng sau" đến từ đâu? Là ràng buộc thật (hợp đồng, sự kiện) hay chỉ là con số ước chừng? Rất nhiều deadline tan biến khi bạn hỏi "điều gì xảy ra nếu trễ hai tuần?"
Cost of Delay: ngôn ngữ chung với stakeholder
Đòn bẩy mạnh nhất khi đàm phán với người làm business là chi phí của sự trì hoãn (Cost of Delay) — tức là bạn mất bao nhiêu giá trị cho mỗi tuần một việc bị hoãn. Thay vì cãi nhau "việc của tôi quan trọng hơn việc của anh", bạn quy mọi thứ về cùng một thước đo: tiền và thời gian.
Nếu Product Goal "giảm rớt giỏ hàng" đang giúp tăng doanh thu khoảng 200 triệu/tháng, thì hoãn nó để chèn live chat là một quyết định có giá. Khi con số nằm trên bàn, cuộc tranh luận chuyển từ cảm tính sang lý trí — và đó luôn là sân nhà của một PO chuẩn bị tốt.
Tình huống thực tế
Tình huống 1 — Tiki và yêu cầu "live chat tháng sau"
Bối cảnh: Lan là PO của một đội sản phẩm thanh toán tại một sàn TMĐT lớn ở Việt Nam (gọi là sàn X cho tương tự Tiki). Product Goal đang chạy: giảm tỷ lệ rớt ở bước thanh toán từ 34% xuống 20%, ước tính tác động ~180 triệu doanh thu/tháng. Sprint thứ 3/5 đang diễn ra. CEO yêu cầu live chat trong 4 tuần vì một khách doanh nghiệp lớn vừa phàn nàn.
Diễn giải: Lan không nói "không", cũng không nói "vâng". Cô áp dụng NUT ngay trong cuộc họp:
- Need: "Khách lớn nào ạ, và họ đau ở đâu?" — hóa ra khách phàn nàn vì không liên hệ được CSKH khi đơn lỗi, chứ không phải thiếu khung chat. Vấn đề gốc là kênh hỗ trợ phản hồi chậm, không phải thiếu live chat.
- Use: Live chat tự xây cần đội trực 24/7 — mà công ty chưa có. Xây xong cũng không ai trực thì vô dụng.
- Time: "Tháng sau" đến từ buổi gặp với khách, không phải hợp đồng ràng buộc.
Bài học: Khi bạn đào tới vấn đề gốc, một yêu cầu "2 sprint" thường co lại thành một giải pháp "3 ngày" tốt hơn. Đàm phán scope giỏi nhất là khi stakeholder ra về với cảm giác được giải quyết vấn đề, chứ không phải bị từ chối tính năng.
Tình huống 2 — Startup fintech và "hội đồng tính năng" của Sales
Bối cảnh: Tại một startup ví điện tử ở TP.HCM (~25 người), đội Sales liên tục mang về các yêu cầu từ từng khách hàng doanh nghiệp: khách A muốn export Excel theo định dạng riêng, khách B muốn webhook custom, khách C muốn báo cáo theo chi nhánh. Mỗi yêu cầu đều đi kèm câu "deal này 500 triệu, không có là mất khách". PO tên Phúc bị kẹt giữa việc giữ doanh thu và việc giữ cho sản phẩm khỏi biến thành một mớ tính năng chắp vá.
Diễn giải: Phúc nhận ra mình đang đàm phán sai cấp độ — đàm phán từng yêu cầu một, lần nào cũng thua vì lần nào cũng có con số doanh thu áp lên. Anh nâng cuộc đàm phán lên cấp chiến lược chung với Giám đốc Sales và CEO. Anh đặt ra một nguyên tắc thỏa thuận chung (không phải một quyết định lẻ):
- Mọi yêu cầu riêng của một khách sẽ được tính điểm theo ba tiêu chí: doanh thu, khả năng tái sử dụng cho khách khác, và chi phí xây dựng.
- Capacity dành cho "yêu cầu khách lẻ" được khoanh vùng cố định: tối đa 20% mỗi sprint. Quá ngưỡng thì Sales phải tự xếp thứ tự ưu tiên với nhau và bảo vệ trước hội đồng.
Bài học: Khi bị "tấn công" bởi nhiều yêu cầu lẻ, đừng đàm phán từng cái — hãy đàm phán luật chơi. Một bộ tiêu chí thống nhất từ trước sẽ biến mỗi lần "nói không" thành việc áp dụng nguyên tắc chung, không còn là xung đột cá nhân. Đây cũng là cách PO bảo vệ quyền toàn quyền với thứ tự backlog mà không biến mình thành kẻ thù của Sales.
Tình huống 3 — Grab và deadline marketing không thể dời
Bối cảnh: Một đội tại một siêu ứng dụng (giả định kiểu Grab) chuẩn bị tính năng cho chiến dịch khuyến mãi Tết. Khác với hai tình huống trên, đây là deadline thật — chiến dịch đã chốt ngân sách marketing 5 tỷ, ngày lên sóng không thể dời vì đã book quảng cáo. PO tên Trang đối mặt với việc team không thể làm hết toàn bộ scope mơ ước trong thời gian còn lại.
Diễn giải: Vì Time bị cố định cứng và Quality không được hạ (DoD bất khả xâm phạm), Trang chỉ còn một núm để vặn: Scope. Cô tổ chức một buổi cùng stakeholder chia scope thành ba lớp theo kiểu MoSCoW:
- Must-have: hiển thị mã giảm giá + áp dụng được khi thanh toán. Không có cái này, cả chiến dịch vô nghĩa.
- Should-have: trang landing đếm ngược, thông báo đẩy.
- Could-have: hiệu ứng animation pháo hoa, chia sẻ mã cho bạn bè.
Bài học: Khi deadline là thật và không dời được, đàm phán scope chuyển thành đàm phán cái gì ra trước, cái gì ra sau. Việc phân lớp Must/Should/Could biến một lời hứa rủi ro thành một cam kết tối thiểu vững chắc cộng với phần dự báo trung thực — đúng tinh thần forecast over commitment của Scrum.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho gần như mọi cuộc đàm phán scope:
Bước 1 — Đừng phản ứng ngay, hãy mua thời gian. Khi nhận yêu cầu, câu nguy hiểm nhất là trả lời "yes/no" tại chỗ. Hãy nói: "Đây là yêu cầu quan trọng, để em hiểu rõ vấn đề và xem nó ảnh hưởng thế nào tới mục tiêu hiện tại, rồi quay lại với anh phương án trong hôm nay." Bạn vừa thể hiện sự nghiêm túc, vừa giành lại quyền chuẩn bị.
Bước 2 — Đào tới vấn đề gốc bằng NUT. Hỏi về Need, Use, Time. Tìm cho ra: ai đau, đau cỡ nào, deadline có thật không. Rất thường xuyên, yêu cầu sẽ tự thu nhỏ hoặc đổi hình dạng ở bước này.
Bước 3 — Định lượng cái đánh đổi. Tính Cost of Delay của việc bạn sẽ phải hoãn (thường là Product Goal hiện tại) và đặt nó cạnh giá trị kỳ vọng của yêu cầu mới. Đưa con số, đừng đưa cảm xúc.
Bước 4 — Chuẩn bị 2–3 phương án, không phải một câu trả lời. Ví dụ: (A) làm ngay, hoãn Product Goal, mất X; (B) phiên bản nhỏ/third-party trong vài ngày; (C) đưa vào backlog làm sau Product Goal. Trao quyền chọn cho stakeholder — đây là chìa khóa, vì người ta hiếm khi chống lại lựa chọn do chính mình đưa ra.
Bước 5 — Bảo vệ Quality và Developers. Dù chọn phương án nào, hai thứ không nằm trên bàn đàm phán: Definition of Done và việc không ép Developers cam kết một khối lượng phi thực tế. Bạn đàm phán scope và time, không đàm phán chất lượng.
Bước 6 — Chốt lại bằng văn bản và phản chiếu vào backlog. Sau đàm phán, cập nhật Product Backlog và xác nhận lại với stakeholder một câu ngắn gọn: "Thống nhất: làm phương án B tuần này, live chat đầy đủ đưa vào sau Product Goal hiện tại." Đàm phán không có dấu vết trên backlog là đàm phán dễ bị lật lại.
Lỗi thường gặp & mẹo
Lỗi 1 — Đàm phán bằng "yes/no". Đây là cái bẫy lớn nhất. Một PO non sẽ thấy mình chỉ có hai cửa. PO giỏi luôn mở ra cửa thứ ba: một phiên bản khác, một thời điểm khác, một giải pháp khác. Mẹo: trước mỗi cuộc họp khó, tự ép mình viết ra ít nhất ba phương án.
Lỗi 2 — Hạ Quality để kịp deadline. "Thôi làm tạm, refactor sau" là lời nói dối ngọt ngào nhất trong nghề. Nó tạo nợ kỹ thuật và phá vỡ Increment dùng được. Đàm phán scope đúng là cắt bớt việc, không phải làm ẩu hơn.
Lỗi 3 — Nói không mà không đưa giải pháp thay thế. "Không làm được đâu anh" khiến bạn trở thành rào cản. "Cái này em chưa xếp vào được vì đang dở Product Goal, nhưng em có hai cách giải quyết vấn đề của anh ngay tuần này" khiến bạn trở thành đối tác.
Lỗi 4 — Đàm phán từng yêu cầu lẻ thay vì luật chơi. Như tình huống fintech: nếu cứ đấu tay đôi từng tính năng, bạn sẽ kiệt sức và luôn thua khi đối phương có con số doanh thu. Hãy nâng lên cấp nguyên tắc chung.
Lỗi 5 — Quên rằng quyết định cuối cùng là của PO. Trong Scrum, PO chịu trách nhiệm tối đa hóa giá trị và toàn quyền với thứ tự backlog. Bạn lắng nghe, bạn cộng tác, nhưng bạn không phải nhân viên nhận lệnh. Mẹo thi PSPO I: khi đề bài hỏi "ai quyết định thứ tự backlog / nội dung backlog" — luôn là Product Owner, kể cả khi CEO hay stakeholder gây áp lực.
Mẹo vàng — Tách con người khỏi vấn đề. Mượn nguyên tắc kinh điển của Harvard ("getting to yes"): hãy cứng rắn với vấn đề nhưng mềm mỏng với con người. CEO không phải đối thủ của bạn; deadline phi lý mới là vấn đề chung hai bên cùng giải.
Bài tập thực hành
Bài tập 1 — Viết kịch bản ba phương án. Lấy chính tình huống "CEO muốn live chat tháng sau". Viết ra ba phương án (A/B/C) như Bước 4, mỗi phương án kèm: scope, thời gian ước lượng, ảnh hưởng tới Product Goal, và một câu giải thích bằng ngôn ngữ business. Đọc to và tự hỏi: phương án nào bạn sẽ khuyến nghị, vì sao?
Bài tập 2 — Thực hành NUT trên yêu cầu thật. Chọn một yêu cầu gần nhất mà bạn (hoặc team bạn quan sát) nhận được. Trả lời thật ba câu hỏi Need / Use / Time. Yêu cầu đó có còn cấp bách như ban đầu không? Vấn đề gốc thực sự là gì?
Bài tập 3 — Tính Cost of Delay. Lấy Product Goal hiện tại của một đội (thật hoặc giả định). Ước lượng giá trị nó tạo ra mỗi tuần. Sau đó tính: nếu chèn một yêu cầu mới làm hoãn Product Goal 2 tuần, cái giá là bao nhiêu? Bạn sẽ trình bày con số này với stakeholder ra sao trong một câu?
Bài tập 4 — Đóng vai. Nhờ một đồng nghiệp đóng vai stakeholder cứng đầu ("phải có, không bàn cãi"). Tập đi qua đủ 6 bước mà không một lần rơi vào "yes/no" và không một lần hạ Quality. Ghi lại câu nào khiến bạn lúng túng nhất để luyện thêm.
Tóm tắt
- Đàm phán scope không phải là nghệ thuật nói "không". Đó là kỹ năng biến một yêu cầu thành cuộc trao đổi về giá trị và đánh đổi, để đi tới quyết định tốt hơn cho cả hai bên.
- Thoát khỏi bẫy yes/no: luôn mở ra cửa thứ ba bằng cách điều chỉnh Scope, Time hoặc Cost — nhưng không bao giờ điều chỉnh Quality (DoD là bất khả xâm phạm).
- Dùng NUT (Need – Use – Time) để lọc yêu cầu và đào tới vấn đề gốc; phần lớn yêu cầu "khẩn cấp" sẽ tự co lại.
- Dùng Cost of Delay làm ngôn ngữ chung với business — đưa con số, không đưa cảm xúc.
- Khi bị bủa vây bởi nhiều yêu cầu lẻ, hãy đàm phán luật chơi (tiêu chí ưu tiên, capacity khoanh vùng) thay vì đấu từng tính năng.
- Khi deadline là thật, đàm phán scope chuyển thành phân lớp Must/Should/Could và cam kết tối thiểu cộng forecast trung thực.
- Luôn nhớ nguyên tắc Scrum nền tảng: PO chịu trách nhiệm tối đa hóa giá trị, có toàn quyền với nội dung và thứ tự Product Backlog, và không ai được ép Developers gánh khối lượng phi thực tế. Đàm phán scope chính là nơi bạn thực thi những trách nhiệm đó một cách trưởng thành.