How to say no to your manager and stakeholders

A 9 p.m. message from the CEO

Sunday evening, the CEO posts in the project group chat: “Get the team to build a flash sale page for the 11/11 campaign, the competitor already has one.” There are three days left. This sprint the team is fixing a bug that leaves some orders stuck at the payment step, something you promised customer support last week.

This is an illustrative situation, set in a fictional online homeware shop. Many new POs will still recognise the feeling. You know the team cannot do both properly. You also know that typing “no” to the CEO, in front of the whole group, is very hard.

This article does not teach you to argue with your boss. It offers a way to say no while keeping the relationship: replace a flat “no” with three answers that carry a reason and a condition, handle the case where the request comes from your direct manager or CEO, and know when to let someone with more authority decide. The earlier step, finding the real problem behind a request, is covered in the article on handling feature requests.

• Read: How a new PO handles feature requests

Why is saying no to your manager so hard in many Vietnamese workplaces?

In many Vietnamese teams, the hard part is not the argument. You may know exactly why something should wait and still be unable to say it. A few reasons come up again and again:

• Clear hierarchy. When someone older or higher in rank speaks, juniors answer “dạ” (a polite “yes”). A direct refusal can come across as disrespectful, even when you do not mean it that way.
• “Dạ vâng” does not mean agreement. Many people say it to acknowledge the request, then quietly take on the work. The requester hears “dạ” and assumes it is settled.
• Face. Pushing back in a group chat or a crowded meeting makes the requester lose face, even if you are right.
• A PO is usually nobody's boss. You do not manage the developers or the sales team. Your influence comes from people trusting how you prioritise, not from your title.
• Fear of looking unhelpful, especially in the first months of a new role.

The Scrum Guide says that for Product Owners to succeed, the whole organisation must respect their decisions, and anyone who wants to change the Product Backlog does so by convincing the Product Owner. That is the right principle. In a small company, though, the CEO can still override at any time. So your practical goal is not to win the argument. It is to make sure every decision is made with its cost in plain view.

Not saying no has a cost too. The team takes on both pieces of work and both slip. Or the flash sale page is rushed, the payment bug stays, and on the busiest day customers get stuck at checkout. The person who loses the most goodwill is then you, because you said “dạ”.

How to say no to a stakeholder: four steps

A stakeholder is anyone with an interest in or influence over the product: your manager, the CEO, department heads, large clients. Whoever is asking, you can follow the same path.

Step 1: do not answer while you are caught off guard. A line such as “Got it, I'll check the plan and come back to you before 10 tomorrow morning” buys time without looking evasive. Then restate the requester's goal. In the situation above, the CEO's goal is revenue during 11/11. The flash sale page is just one way to get there.

Step 2: make the cost concrete. Not “the team is busy”, but the name of the current work, its expected finish date, and who is affected if it slips. Mountain Goat Software suggests two things worth remembering here: explain the consequences of saying yes, and give only your strongest reason. Give five reasons and people tend to argue with the weakest one.

Before you mention any timeline, ask the developers. An estimate you guess and say in front of your manager easily becomes the whole team's promise.

Step 3 is the core, covered in the next section. Step 4 is the one most often skipped: after a call or meeting, send a few lines summarising the decision, who made it, and when it will be reviewed. Where “dạ vâng” can mean several things, that summary makes sure everyone understood the same thing.

Three ways to say no instead of a flat “no”

A bare “no” only tells people you will not do it. The three answers below also tell them why, until when, and what choices they still have.

What matters most is that people can tell “no” from “not yet”. Mountain Goat Software stresses this: be clear whether it is a no or a not now, and if it is not now, set a specific time to revisit. Without that clarity, people tend to keep asking, or go to someone else.

The third answer is not really a refusal. You are not saying “we won't do it”, you are putting a price on the request. They may still choose to go ahead, but now they choose knowing what gets pushed back. A common variant is “yes, but smaller”: instead of a new page, a banner and a discount code on the existing one.

All three answers need a clear order of priorities to weigh against. If your backlog is a list where everything is “urgent”, sort that out first.

• Read: Prioritising the backlog when everything is urgent

When the person asking is your direct manager or CEO

With your direct manager or CEO, you rarely say “no” outright. You offer choices with their costs, state your recommendation, and let them decide. This is not only about politeness. Your manager may know things you do not: a commitment to a partner, a fundraising plan, pressure on the quarter's sales. Your job is to make the cost visible, not to take the decision away from them.

• Reply privately, not in the group chat. In the group, all you need is: “Got it, I'll message you the options directly.”
• Start from your manager's goal, not the team's difficulties. “I understand you want more revenue during 11/11” lands far better than “the team is overloaded”.
• Offer two, at most three, options. For each, say what you gain and what you lose.
• State your recommendation. Many managers want a PO with a view, not just a menu.
• If your manager picks a different option, accept it, write it down, and tell the people affected that the decision is settled. You do not need to hide it or look unhappy about it.

Keep the forms of address your team already uses, such as “dạ”, “em”, “anh/chị” in Vietnamese. Politeness lives in how you say it. The content still has to be clear. “I think that might be a bit hard” is polite and vague, and your manager will hear that it can be done. “If we build the new page, the payment fix slips past 11/11” is just as polite, and nobody can misread it.

When should you escalate instead of saying no?

To escalate is to take a decision to someone with more authority, usually your direct manager. Many new POs avoid it because they fear looking like a tattletale or unable to cope. In fact, escalating is the right move when the decision is beyond your authority.

When you escalate, tell the requester first. Never go behind their back. Something like “This is beyond what I can decide, so I'd like to take it to my manager to settle, and I'll copy you in” keeps respect on both sides. Bring a short summary: what was asked, what it conflicts with, the options, their costs, and your recommendation.

If the requester is the CEO, there is usually nobody left to escalate to. Then step 4 is what protects you: the decision is written down, the cost was stated, and everyone knows who chose.

Example: talking to the CEO about the flash sale page

Back to Sunday's message. In the group chat, the PO only replies: “Got it, I'll message you the options tomorrow morning.” That evening the PO quickly checks two approaches with the developers. This is the illustrative conversation the next morning, in a private chat.

Throughout the conversation, the PO never says “no”. The PO starts from the CEO's goal, shows what would slip, offers two options with gains and losses, states a recommendation, and lets the CEO decide. The “about a day” comes from the developers, not a PO guess. Finally, the decision goes into the group chat, so the whole team knows why there is no separate flash sale page.

Small everyday phrases follow the same principle. The table below compares a few lines that tend to cause offence with better alternatives.

Message templates for saying no at each level

The first three templates match the three ways to say no, ordered by recipient from peer to manager. The fourth is for escalating. Copy them and adjust to the way your team addresses each other.

Thanks for suggesting [idea]. I can see how it would save [user group] from [problem].
I've decided not to put this in the plan for [this quarter], because [one strong reason tied to the shared goal].
This is a decision not to do it during [period], not a “later” that gets forgotten.
Instead, you could [workaround or smaller version].
If [specific condition] changes, let me know and I'll look at it again.

Hi [name], I've looked at the request for [request].
My understanding is that the goal is [their goal, in their words].
The team is currently working on [work A] to reach [goal B], expected to finish on [date].
I suggest we start on yours from [date], once A is done.
If this has to be ready before [date], I'd like us to ask [priority owner] together to choose between A and this.
Does that work for you?

I've gone through the plan for [request] with the team.
My understanding is that the goal is [goal].
Option 1: [do exactly what was asked]. Gain: [benefit]. Cost: [current work] slips to [date].
Option 2: [smaller version or another approach]. Gain: [benefit]. Cost: [limitation].
I recommend option [number], because [one reason].
Could you choose by [time, date] so the team can plan?

To the requester:
Hi [name], this is beyond what I can decide, so I'd like to take it to [decision maker] to settle. Here is the summary I'll send; please check I have it right.

To [decision maker]:
- Request: [who needs what, by when].
- Conflicts with: [other work or request, and whose].
- Option 1: [description], cost: [what slips, what risk].
- Option 2: [description], cost: [what slips, what risk].
- My recommendation: [option], because [reason].
- Decision needed by: [date].

After sending, do not forget the last part: record the decision where the team can see it, and come back on the date you promised. A “not yet” that is kept on time makes the next “not yet” much easier to accept.

Common mistakes when saying no to stakeholders

• Saying “dạ” and then going quiet. The requester thinks it is settled, the team does not know the work exists. On the deadline, both sides are surprised.
• Giving too many reasons. People will argue with the weakest. Pick your strongest reason and tie it to the shared goal.
• Blaming the team: “The developers won't do it.” Prioritisation is your decision. Blaming developers costs you trust on both sides.
• Hiding behind your manager: “The boss said no” when the boss said nothing. The Scrum.org article also lists using hierarchy to force a no among the approaches to avoid.
• Promising an alternative you do not intend to deliver. Only offer a workaround you will actually follow through on.
• Estimating on the spot in front of your manager. Ask the developers first, then give a number.
• Turning someone down in the group chat. Being right while making someone lose face still damages the relationship.
• Missing the review date. One missed date makes every later “not yet” sound like “never”.

Summary

• The goal is not to win the argument but to make every decision with its cost in plain view.
• Follow four steps: acknowledge and restate the goal, put it on the scale, choose your answer, confirm in writing.
• Replace a flat “no” with three answers: no because of one clear reason, not yet until a specific point, yes if something else is dropped.
• With your direct manager or CEO: reply privately, start from their goal, offer two options with costs, recommend one, let them choose.
• Escalate when the decision is beyond your authority, when priorities conflict, or when the risk is high. Always tell the requester first.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

• Get new articles by email

Frequently asked questions

Can a Product Owner say no to their manager?

Yes, but with your direct manager or CEO it usually works better to offer two or three options with the cost of each, state your recommendation, and let them choose. The PO is accountable for ordering the backlog, while the manager may hold business context the PO does not have.

How do you turn down a request without upsetting the person?

Restate their goal in their own words, give one strong reason tied to a shared goal, say clearly whether it is a no or a not yet, and offer a workaround or a smaller version. Have the conversation privately rather than pushing back in a group chat.

When should a PO escalate instead of saying no?

When the decision is beyond your authority, when two stakeholders want conflicting priorities, or when a wrong call could create legal, customer data or financial risk. Talk to the requester first and tell them you are taking it up.

Sources to check

• 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

Related articles

• What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
• What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
• Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
• What is sprint planning? What a PO should prepare: A prep checklist for the day or two before sprint planning, how to run the “what” conversation, and how to write a Sprint Goal, with templates to use straight away.