Cách nói không với sếp và stakeholder mà không mất lòng

Tin nhắn lúc chín giờ tối từ CEO

Tối Chủ nhật, CEO nhắn vào nhóm chat chung của dự án: “Em cho team làm thêm trang flash sale cho đợt 11/11 nhé, anh thấy bên kia làm rồi.” Còn đúng ba ngày. Sprint này team đang sửa lỗi khiến một số đơn bị treo ở bước thanh toán, việc bạn đã hứa với bộ phận chăm sóc khách hàng từ tuần trước.

Đây là tình huống minh họa, với một shop đồ gia dụng online giả định. Nhưng cảm giác này thì nhiều PO mới sẽ nhận ra. Bạn biết team không thể làm cả hai cho tử tế. Bạn cũng biết gõ chữ “không” gửi CEO, trước mặt cả nhóm, là việc rất khó.

Bài này không dạy bạn cãi sếp. Bài này đưa ra một cách nói không mà vẫn giữ được quan hệ: thay một chữ “không” bằng ba kiểu trả lời có lý do và có điều kiện, biết cách xử lý khi người hỏi là sếp trực tiếp hoặc CEO, và biết lúc nào nên để người có quyền cao hơn quyết. Phần trước đó, tức cách hỏi ra vấn đề thật phía sau một yêu cầu, đã có trong bài về xử lý feature request.

• Đọc bài: PO mới xử lý feature request thế nào

Vì sao nói không với sếp lại khó ở nhiều công ty Việt Nam?

Ở nhiều team Việt Nam, cái khó thường không nằm ở lý lẽ. Bạn có thể biết rất rõ vì sao chưa nên làm, nhưng vẫn không nói ra được. Có vài lý do hay gặp:

• Thứ bậc rõ ràng. Người lớn tuổi hơn, cấp cao hơn nói thì người dưới “dạ”. Từ chối thẳng dễ bị hiểu là thiếu lễ phép, dù bạn không có ý đó.
• “Dạ vâng” không có nghĩa là đồng ý. Nhiều người nói “dạ” để ghi nhận, rồi lặng lẽ ôm việc. Người yêu cầu nghe “dạ” thì tưởng mọi thứ đã xong.
• Giữ thể diện. Phản bác trong nhóm chat chung hay giữa cuộc họp đông người làm người yêu cầu mất mặt, kể cả khi bạn đúng.
• PO thường không phải sếp của ai. Bạn không quản lý dev, cũng không quản lý bộ phận kinh doanh. Tiếng nói của bạn đến từ việc mọi người tin vào cách bạn ưu tiên, không đến từ chức danh.
• Sợ bị xem là không được việc, nhất là trong vài tháng đầu ở vị trí mới.

Scrum Guide viết rằng để PO làm tốt, cả tổ chức phải tôn trọng quyết định của PO, và ai muốn thay đổi Product Backlog thì làm bằng cách thuyết phục PO. Đó là nguyên tắc đúng. Nhưng ở công ty nhỏ, CEO vẫn có thể ghi đè bất kỳ lúc nào. Vì vậy mục tiêu thực tế của bạn không phải là thắng cuộc tranh luận. Mục tiêu là để mỗi quyết định được đưa ra khi mọi người thấy rõ cái giá của nó.

Không dám nói không cũng có giá. Team ôm cả hai việc, cả hai cùng trễ. Hoặc trang flash sale được làm vội, lỗi thanh toán vẫn còn, và đúng ngày đông đơn nhất thì khách bị treo đơn. Lúc đó người mất lòng nhiều nhất lại là bạn, vì chính bạn đã “dạ”.

Cách nói không với stakeholder: bốn bước

Stakeholder là bất kỳ ai có quyền lợi hoặc ảnh hưởng tới sản phẩm: sếp, CEO, trưởng các bộ phận, khách hàng lớn. Dù người hỏi là ai, bạn có thể đi theo cùng một đường.

Bước 1: đừng trả lời ngay khi đang bị bất ngờ. Một câu như “Dạ em nhận rồi ạ, em xem lại kế hoạch và phản hồi anh trước 10 giờ sáng mai” cho bạn thời gian suy nghĩ mà không bị xem là né. Sau đó nhắc lại mục tiêu của người hỏi. Trong tình huống trên, mục tiêu của CEO là doanh thu đợt 11/11. Trang flash sale chỉ là một cách để đạt mục tiêu đó.

Bước 2: làm cho cái giá hiện ra cụ thể. Không phải “team đang bận”, mà là tên việc đang làm, ngày dự kiến xong, và ai bị ảnh hưởng nếu việc đó lùi lại. Mountain Goat Software gợi ý hai điều đáng nhớ ở bước này: giải thích hậu quả của việc nói có, và chỉ đưa ra một lý do mạnh nhất. Khi bạn đưa năm lý do, người nghe thường chọn lý do yếu nhất để bắt bẻ.

Trước khi nêu bất kỳ con số thời gian nào, hãy hỏi dev. Một ước lượng bạn tự đoán, nói trước mặt sếp, dễ biến thành lời hứa của cả team.

Bước 3 là phần chính, nằm ở mục ngay dưới. Bước 4 hay bị bỏ qua nhất: sau một cuộc gọi hay một buổi họp, gửi lại vài dòng tóm tắt quyết định, ai đã quyết, và ngày sẽ xem lại. Ở môi trường mà “dạ vâng” có thể mang nhiều nghĩa, dòng tóm tắt này giúp mọi người hiểu cùng một điều.

Ba cách nói không thay cho một chữ “không”

Một chữ “không” trơn chỉ cho người hỏi biết bạn không làm. Ba kiểu trả lời dưới đây cho họ biết vì sao, đến bao giờ, và họ còn lựa chọn gì.

Điều quan trọng là người nghe phân biệt được “không” và “chưa”. Mountain Goat Software nhấn mạnh điểm này: phải nói rõ đây là không, hay chỉ là chưa, và nếu là chưa thì hẹn một thời điểm cụ thể để xem lại. Nếu không rõ ràng, người yêu cầu dễ quay lại hỏi liên tục, hoặc đi nhờ người khác.

Cách thứ ba thật ra không phải từ chối. Bạn không nói “không làm”, bạn gắn giá vào yêu cầu. Người hỏi có thể vẫn chọn làm, nhưng lúc này họ chọn khi đã biết việc gì sẽ bị đẩy lùi. Một biến thể hay dùng là “có, nhưng nhỏ hơn”: thay vì một trang mới, làm một banner và mã giảm giá trên trang đang có.

Cả ba cách đều cần bạn có sẵn một thứ tự ưu tiên rõ ràng để đặt lên bàn cân. Nếu backlog của bạn đang là một danh sách việc nào cũng “gấp”, hãy xử lý phần đó trước.

• Đọc bài: Ưu tiên backlog khi việc nào cũng gấp

Khi người yêu cầu là sếp trực tiếp hoặc CEO

Với sếp trực tiếp hoặc CEO, bạn hiếm khi nói “không” thẳng. Bạn đưa ra lựa chọn kèm cái giá, nói đề xuất của mình, rồi để họ chọn. Lý do không chỉ là lễ phép. Sếp có thể đang nắm những thông tin bạn chưa có: một cam kết với đối tác, một kế hoạch gọi vốn, một áp lực doanh số của quý. Việc của bạn là làm cho cái giá hiện rõ, không phải giữ quyền quyết thay họ.

• Trả lời riêng, không phản bác trong nhóm chat chung. Trong nhóm, chỉ cần: “Dạ em nhận, em nhắn riêng anh phương án nhé.”
• Mở đầu bằng mục tiêu của sếp, không bằng khó khăn của team. “Em hiểu anh muốn tăng doanh thu đợt 11/11” dễ nghe hơn nhiều so với “Team đang quá tải”.
• Đưa hai, tối đa ba phương án. Mỗi phương án ghi rõ được gì và mất gì.
• Nói đề xuất của bạn. Nhiều người quản lý muốn PO có chính kiến, không chỉ đưa ra một menu.
• Nếu sếp chọn khác với đề xuất, hãy chấp nhận, ghi lại, và báo cho những người bị ảnh hưởng rằng đây là quyết định đã được chốt. Bạn không cần giấu, cũng không cần tỏ ra không vui.

Về xưng hô, cứ giữ cách team bạn vẫn dùng: “dạ”, “em”, “anh/chị”. Lễ phép nằm ở cách nói. Nội dung thì phải rõ. Một câu như “Em nghĩ chắc khó đó anh” vừa lễ phép vừa mơ hồ, và sếp sẽ hiểu là vẫn làm được. Một câu như “Nếu làm trang mới thì lỗi thanh toán lùi sang sau 11/11” cũng lễ phép, nhưng không ai hiểu sai.

Khi nào nên escalate thay vì tự từ chối?

Escalate là đưa quyết định lên người có quyền cao hơn, thường là sếp trực tiếp của bạn. Nhiều người mới ngại vì sợ bị xem là mách lẻo hoặc không tự xử lý được. Thật ra, escalate là cách làm đúng khi quyết định vượt khỏi quyền của bạn.

Khi escalate, hãy báo cho người yêu cầu biết trước, đừng làm sau lưng họ. Một câu như “Việc này vượt quyền quyết của em, em xin đưa lên anh [tên người quyết] để chốt, em gửi chị cùng đọc nhé” giữ được sự tôn trọng cho cả hai phía. Mang theo bản tóm tắt ngắn: yêu cầu là gì, đang xung đột với việc gì, các phương án, cái giá và đề xuất của bạn.

Nếu người yêu cầu chính là CEO, thường không còn ai để đưa lên nữa. Khi đó chỗ dựa của bạn là bước 4: quyết định được ghi lại, cái giá đã được nói ra, và mọi người biết ai đã chọn.

Ví dụ: trao đổi với CEO về trang flash sale

Quay lại tin nhắn tối Chủ nhật. Trong nhóm chung, PO chỉ trả lời: “Dạ em nhận, sáng mai em nhắn riêng anh phương án.” Tối đó PO hỏi nhanh dev về hai hướng làm. Đây là cuộc trao đổi minh họa sáng hôm sau, qua tin nhắn riêng.

Trong cả cuộc trao đổi, PO không nói chữ “không” lần nào. PO giữ mục tiêu của CEO làm điểm xuất phát, cho thấy việc gì sẽ bị đẩy lùi, đưa hai phương án có được có mất, nói đề xuất, và để CEO quyết. Con số “khoảng một ngày” là của dev, không phải PO tự đoán. Cuối cùng, quyết định được ghi vào nhóm chung, nên cả team biết vì sao không có trang flash sale riêng.

Những câu nói nhỏ hằng ngày cũng theo cùng nguyên tắc. Bảng dưới so sánh vài câu dễ gây mất lòng với câu nên dùng thay.

Mẫu tin nhắn nói không theo từng cấp

Ba mẫu đầu ứng với ba cách nói không, xếp theo người nhận từ ngang cấp tới sếp. Mẫu thứ tư dùng khi cần escalate. Bạn copy rồi sửa lại theo xưng hô quen dùng trong team, có team gọi nhau “anh/chị/em”, có team dùng “mình/bạn”.

Cảm ơn bạn đã đề xuất [ý tưởng], mình thấy rõ nó giúp [nhóm người dùng] đỡ [vấn đề].
Mình quyết định không đưa việc này vào kế hoạch [quý này], vì [một lý do mạnh nhất, gắn với mục tiêu chung].
Đây là quyết định không làm trong [thời gian], không phải để sau rồi quên.
Thay vào đó, bạn có thể [cách tạm hoặc phiên bản nhỏ hơn].
Nếu [điều kiện cụ thể] thay đổi, bạn báo mình để mình xem lại nhé.

Dạ em chào anh/chị [tên], em đã xem yêu cầu [tên yêu cầu] ạ.
Em hiểu mục tiêu là [mục tiêu của họ, theo lời họ].
Hiện team đang làm [việc A] để [mục tiêu B], dự kiến xong ngày [ngày].
Em đề xuất bắt đầu việc của anh/chị từ ngày [ngày], sau khi A xong.
Nếu việc này bắt buộc phải có trước [ngày], em xin cùng anh/chị hỏi [người quyết ưu tiên] để chọn giữa A và việc này.
Anh/chị thấy vậy được không ạ?

Dạ anh/chị, em đã xem lại kế hoạch cho [yêu cầu] cùng team ạ.
Em hiểu mục tiêu là [mục tiêu].
Phương án 1: [làm đúng theo yêu cầu]. Được: [lợi ích]. Mất: [việc đang làm] lùi tới [ngày].
Phương án 2: [phiên bản nhỏ hơn hoặc cách khác]. Được: [lợi ích]. Mất: [hạn chế].
Em đề xuất phương án [số], vì [một lý do].
Anh/chị chọn giúp em trước [giờ, ngày] để team kịp sắp xếp ạ.

Gửi người yêu cầu:
Dạ anh/chị [tên], việc này vượt quyền quyết của em, nên em xin đưa lên [người quyết] để chốt. Em gửi tóm tắt dưới đây, anh/chị xem giúp em có đúng ý không nhé.

Gửi [người quyết]:
- Yêu cầu: [ai cần gì, trước ngày nào].
- Đang xung đột với: [việc hoặc yêu cầu khác, của ai].
- Phương án 1: [mô tả], cái giá: [việc gì lùi, rủi ro gì].
- Phương án 2: [mô tả], cái giá: [việc gì lùi, rủi ro gì].
- Đề xuất của em: [phương án], vì [lý do].
- Cần anh/chị quyết trước: [ngày].

Sau khi gửi, đừng quên phần cuối: ghi quyết định vào nơi team cùng xem, và quay lại đúng ngày đã hẹn. Một lời “chưa” được giữ đúng hẹn sẽ làm lời “chưa” lần sau dễ được chấp nhận hơn.

Lỗi thường gặp khi từ chối stakeholder

• Nói “dạ” rồi im lặng. Người hỏi tưởng đã xong, team thì không biết có việc. Đến hạn, cả hai phía cùng bất ngờ.
• Đưa ra quá nhiều lý do. Người nghe sẽ bắt bẻ lý do yếu nhất. Chọn một lý do mạnh nhất, gắn với mục tiêu chung.
• Đổ cho team: “Dev không chịu làm.” Quyết định ưu tiên là của bạn. Đổ cho dev làm bạn mất niềm tin ở cả hai phía.
• Lấy cấp trên ra làm lá chắn: “Sếp bảo không làm” khi sếp chưa hề nói. Bài của Scrum.org cũng xếp việc dùng thứ bậc để ép một lời từ chối vào nhóm cách làm nên tránh.
• Hứa một phương án thay thế mà không định làm. Chỉ đưa ra cách tạm khi bạn thật sự sẽ làm theo.
• Tự ước lượng thời gian trước mặt sếp. Hỏi dev trước, rồi mới nói con số.
• Từ chối trong nhóm chat chung. Đúng lý mà làm người khác mất mặt thì vẫn mất lòng.
• Không quay lại vào ngày đã hẹn. Một lần lỡ hẹn làm mọi lời “chưa” về sau nghe như “không bao giờ”.

Tóm tắt

• Mục tiêu không phải là thắng tranh luận, mà là để mỗi quyết định được đưa ra khi cái giá đã rõ.
• Đi theo bốn bước: ghi nhận và nhắc lại mục tiêu, đặt lên bàn cân, chọn kiểu trả lời, chốt bằng chữ.
• Thay chữ “không” bằng ba cách: không vì một lý do rõ, chưa cho tới một mốc cụ thể, có nếu bỏ bớt việc khác.
• Với sếp trực tiếp hoặc CEO: trả lời riêng, mở đầu bằng mục tiêu của họ, đưa hai phương án kèm cái giá, nói đề xuất, để họ chọn.
• Escalate khi quyết định vượt quyền của bạn, khi các bên đòi ưu tiên trái nhau, hoặc khi rủi ro lớn. Luôn báo người yêu cầu trước.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Product Owner có được từ chối yêu cầu của sếp không?

Có, nhưng với sếp trực tiếp hoặc CEO, cách hiệu quả hơn là đưa ra hai hoặc ba phương án kèm cái giá của từng phương án, nói đề xuất của mình, rồi để họ chọn. PO chịu trách nhiệm sắp thứ tự backlog, còn sếp có thể đang nắm thông tin kinh doanh mà PO chưa biết.

Làm sao từ chối một yêu cầu mà không mất lòng người hỏi?

Nhắc lại mục tiêu của người yêu cầu bằng lời của họ, nêu một lý do mạnh nhất gắn với mục tiêu chung, nói rõ đây là không, hay chỉ là chưa, và đưa một cách tạm hoặc phiên bản nhỏ hơn. Nên trao đổi riêng thay vì phản bác trong nhóm chat chung.

Khi nào PO nên escalate thay vì tự từ chối?

Khi quyết định vượt quyền của bạn, khi hai stakeholder đòi hai ưu tiên trái nhau, hoặc khi quyết định sai có thể gây rủi ro về pháp lý, dữ liệu khách hay tiền. Hãy nói chuyện với người yêu cầu trước và báo cho họ biết bạn sẽ đưa việc này lên.

Nguồn kiểm tra

• Scrum Guide 2020: Product Owner
• Mountain Goat Software: Six Guidelines for Saying No to a Stakeholder
• Scrum.org: Saying No as a Product Owner or Product Manager

Bài liên quan

• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
• Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
• Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
• Sprint planning là gì? PO cần chuẩn bị gì trước buổi họp: Checklist chuẩn bị 1 đến 2 ngày trước sprint planning, cách dẫn phần “làm gì” và cách viết Sprint Goal, kèm mẫu dùng ngay.