What can, and should, a Product Owner / Product Manager do if the CEO has mandated that the team builds something which the Product Owner feels is not in the best interests of the customer?

Aside from presenting a case and aiming to influence the CEO's decision, should a Product Owner acquiesce if that fails? Or should they keep fighting their case?

  • 1
    Are we talking a product that's delivered to clients as-is? Or is the product custom built for one (or a handful of) specific clients, with no wider market?
    – Erik
    Commented Jan 23, 2021 at 10:21
  • 2
    Why does it seem reasonable to you to keep fighting your case? Put yourself in the shoes of a CEO. Say you've already made up your mind about the direction the company should go and you've made this clear. Would you then want a subordinate to keep telling you the company should go in a different direction? This isn't even unique to a CEO, it applies to anyone managing anyone else (although in some other cases you may be able to appeal to a higher authority if the issue is serious enough).
    – NotThatGuy
    Commented Jan 24, 2021 at 2:23
  • Lots of good comments. Simplifying a little, I have 2 further pieces of advice. 1) If you don't understand something (ie your CEO), generally you don't know the whole story. 2) You can't win an argument with your boss. Commented Jan 24, 2021 at 14:31
  • 3
    acquiesce, CEO is the boss and has made a decision.
    – crobar
    Commented Jan 25, 2021 at 14:20
  • 1
    PO is just a fancy scrum title for a person whose job is to gather requirements from the stakeholders (the CEO in this case) and communicate them to developers. Why in the world do you think what PO feels is relevant for anything?
    – Davor
    Commented Jan 25, 2021 at 15:02

10 Answers 10


The PO is the owner of the product, but that doesn't mean they can do watever they want with the product. At the end of the day, they represent the needs and the wants of all stakeholders.

Inevitably, you might end up in some situation where the PO has a different vision for the product than some of the stakeholders, but, like reasonable people, the PO and the stakeholders can discuss it and come to an agreement on how to proceed. This can only be either as the PO wants it, as the stakeholder wants it, or some other approach that comes up during the discussion.

During the discussion, besides arguments people bring to support their view of things, there will be other things interfering with the decision. The product is developed as part of some business need of the company, and the company can have certain business goals, certain budget, certain organizational culture or structure. These might need to be put in balance with doing what you think is good for the product (for ex, it might be good for the product, but bad for some other - more important - company goal).

A reasonable CEO will have the whole image in mind and needs to think about the larger context, not just the product of one PO. So if the CEO takes such a decision, the PO should support it, even if they disagree with it. And if the CEO is unreasonable, then you still need to support it, since as a PO you are lower in the company and the CEO is your hierarchical superior and can tell you what to do.

So if you haven't managed to convince the CEO to do what you want, then you just follow what you have been instructed to do.

  • 4
    The key is, "...larger context," parts of which the PO may not be privy. Great explanation. Commented Jan 22, 2021 at 18:13
  • 5
    If there is a 'larger context' then the CEO should explain it to the Product Owner. That is the difference between leadership and management. A good leader brings people along on the journey with them. Commented Jan 23, 2021 at 12:24
  • 1
    @barnaby golden, that's not possible all the time. There are a ton of reasons to keep strategy limited to a few and need to know basis. Commented Jan 24, 2021 at 13:31
  • I could envision this coming into play when a company has multiple products with only a handful being premium products. Many companies will "cripple" non-premium products.
    – paulj
    Commented Jan 25, 2021 at 14:30
  • @BarnabyGolden - that's a Linkedin meme that has nothing to do with reality. If CEO spent all his time explaining little details to underlings, why would he even need them? They wouldn't be worth to hire.
    – Davor
    Commented Jan 25, 2021 at 15:04

State your case, CEO decides, you execute decision like your job depends on it.

  • 2
    How do you "execute decision like your job depends on it" if you are told to do something impossible? (e.g. deliver a product to a customer two weeks when it would take 12 months to build it.)
    – alephzero
    Commented Jan 23, 2021 at 0:45
  • 7
    That wasn't the question. Commented Jan 23, 2021 at 1:17
  • 7
    @alephzero: if you are told to do the impossible and your job depends on it, spend the time looking for another job.
    – jmoreno
    Commented Jan 24, 2021 at 16:00
  • 1
    @alephzero If you are told to do something you cannot do, you commit to doing something you can do. If the CEO says "do X in Y time" you say "I cannot, but I can do Z in Q time". You never, ever accept an impossible assignment and you do your best to stick to what you promised but deliver as close to what was requested as you can. It's the CEO's job to figure out how to make what you can deliver work for the company. Commented Jan 25, 2021 at 3:59
  • @alephzero - deadlines are not functional requirements.
    – Davor
    Commented Jan 25, 2021 at 15:05

What can, and should, a Product Owner / Product Manager do if the CEO has mandated that the team builds something which the Product Owner feels is not in the best interests of the customer?

Build a case. Try and find metrics or measures that highlight the flaws in the suggested approach.

Aside from presenting a case and aiming to influence the CEO's decision, should a Product Owner acquiesce if that fails? Or should they keep fighting their case?

I would be looking to understand more about the CEO's case. For the Product Owner to be effective in their position they must be aligned around the product direction with the stakeholders. If this alignment is lacking, it is likely to impact on the Product Owner's ability to do their job well.

If there is no alignment then it is hard to see how the role is in any way a Product Owner.


CEO's and their yes-men are always going to use the excuse that "the company has larger goals that may not align with what is in the best interest of the customer" to justify their decisions that effectively screw the customer over in favor of the company.

But the reality IN REAL LIFE is that most businesses CANNOT continue making these decisions and stay alive, not for the long term.

Case in point - Microsoft charges ridiculous amounts for MS Office when run in shared mode on terminal server. In short, they decided their need of making money outweigh the customers need for saving money (by not buying dozens of individual PCs one for each employee) They ditched concurrent licensing in an attempt to force customers to get into O365. Result? SOME customers did capitulate and fork over the dough and O365 deployments skyrocketed - for a while. But then leveled off. And now, more and more companies just install Open Office on their terminal servers. That gives a competitive product a leg up - user familiarity - user acceptance - all leading to the eventual replacement or severe curtailment of the use of MS Office in that customer.

The truth in business is that there is NO HIGHER NEED THAN THE BUSINESS NEED -OF-THE-CUSTOMER- The Vendors "business need" is ALWAYS SUBORDINATE to that of the customer. The CEO's "vision" isn't important. The Product Owner's "vision" isn't important. The "other stakeholders" vision's aren't important. The CUSTOMER has the gold - he makes the rules. PERIOD.

All of the fancy words people use about alignment and strategy and vision and all that rubbish are just poor justifications for doing the stupid thing of putting the vendors needs in front of the needs of the customer.

Yes there's always SOME wiggle room because there are going to be WANTS of the customer that are NOT real NEEDS. In those cases - yes, if it turns out that supplying a WANT is at cross purposes to the vendor's internal strategic goals, then it's OK to override the customer. The easiest way is explaining to the customer that giving them their WANT is going to mean they cannot get a NEED fulfilled. Reasonable customers will accept that - unreasonable ones won't but you don't want them anyway - let them go and like as not they will come back later with their hat in their hand.

But, if you are a PO who is being overridden by the CEO to screw over your customer - then you have no choice but to do it - and at the same time, polish your Resume. Because your employer isn't going to be in that market much longer. And during your exit interview you can explain to them that the day you decided to look for another job was the day they stopped putting the customer #1 - and it was ALSO the day their customer started looking at the competition. Bonus points for being in an at-will state and going to work for that same competitor. Double-bonus points for taking the customer with you.



This is not an either/or situation. In a successful agile implementation, all parties collaborate on what product to build and how to validate that it's fit for purpose.

If instead you're positing a non-collaborative environment where product decisions are set by diktat rather than through active collaboration between the value consumer and the Scrum Team, then this isn't really a question about Scrum. Instead, it's a much more basic one about communication and career management.

Analysis & Recommendations

What can, and should, a Product Owner / Product Manager do if the CEO has mandated that the team builds something which the Product Owner feels is not in the best interests of the customer?

The Product Owner generally acts as the primary liaison with the customer (although high-performing agile teams often interface directly with customers), and functions as the "voice of the customer" in determining value when structuring the Product Backlog. However, the customer is not the only stakeholder: the CEO, CFO, and other internal stakeholders should also have input.

Pragmatically, a senior executive can certainly influence or override the decisions of a Product Owner either through diktat or via the budgeting process. However, doing so is generally a sign of one or more of the following:

  1. Lack of trust in the market savvy or prioritization skills of the Product Owner.
  2. Non-agile micromanagement at the top of the organization.
  3. Lack of faith in the collaboration process with the customer(s).
  4. Insufficient buy-in for the product/project management framework.
  5. Distrust (justified or not) of the team building or delivering the product.

With that said, the Product Owner's primary accountability is to be the sole arbiter of the Product Backlog. So, if senior management disagrees with the contents or priorities of the backlog, the Product Owner can:

  1. Influence the stakeholders to buy into the strategic vision for the product.
  2. Be influenced by the stakeholders to refactor the backlog, or even re-envision the product and the backlog's contents.

However, in a thoroughly non-collaborative, command-and-control environment where the Product Owner is neither empowered to fulfill the role nor able to successfully collaborate on the product vision, then the Scrum values of honesty and communication come into play. A Product Owner who truly doesn't believe in the product vision, or who is not truly empowered to fulfill the accountabilities of the Product Owner role, must have the integrity and courage to point that out to the Scrum Team and senior leadership.

Ultimately, an organization's leadership bears full responsibility for the outcome of any project. If the Product Owner has done the job of providing solid market analysis and product vision to senior leadership, the PO then needs to either align with leadership's vision or have the courage to walk away.

In practice, if you find yourself having to ask how to resolve a major disconnect with senior leadership, the communication failures and lack of collaboration may already be too far along to salvage. In that case, dust of your resume and prepare to move on, whether before or after the death march you're predicting. Otherwise, dust off your interpersonal skills and find a collaborative path through the disconnect that doesn't leave the Product Owner in the position of being responsible for the results of a product they lack authority to influence.

Responsibility without authority is a common problem in project management, and is generally a red flag. If you're sure that's what you're dealing with, prepare to exit stage left.


If it is a minor point, don't sweat it. But if it is a major point, in addition to the other answers, it might also be good to brush up your resume. Sometimes directors and executives don't make decisions for the good of the company, but so that they won't look bad. Sometimes it can also be for someone else to take the fall. If it is a director, document everything they tell you to do, with dates, if you need to defend what you did later. On the other hand, if it is the CEO, it might not matter, if they can just fire you at will anyway.


Most of the time, companies don't aim to build something that is good for the customers, they aim to build something that is good for the company, it just happens to go through the way of also adding value to the customer.

Take the example of addictive online games, it is not in the interest of the paying user, but it unfortunately is still a working business model.

If you have moral qualms with the direction the product is going, you might bring it up to see whether you can change your CEO's mind, but in the end you just might be a bad fit for the company.

In a different scenario the product might actually be bad for the customer and for the company, for example when user will realise that the product is not in their interest and they will not use it.

In that case you need to convince your CEO that her plan doesn't work. If well prepared argument, doesn't convince her, the best way to show that a plan doesn't work is to try to make it work in the best way possible.

Part of being a product owner is to do early validation of the core assumptions behind a product. Try your best to proof these assumptions right, as early as possible. If you are right about your doubts, you won't be able to (and nobody else will). Present your progress on the product together with these results and let your CEO make the decision whether she wants to continue on that path or not.


One approach to the Produce Owner role I have had success with is to treat them as the individual responsible for shielding the team from the real life business politics of software development. This includes customers are upper management. If they do their job, the team should not need to worry about such things.

However, it should be quite evident that this is not a one size fits all role. It must be adapted to the particular company. This is a business logic thing, not a Scrum logic thing.

Accordingly, one should expect that an individual entrusted to be "owner" of the product has sufficient business acumen to succeed in that role. They should understand the politics of their particular business enough to resolve such differences.

Failing to do so, the answer as to what happens is simple. The PO is the "owner" of the product, in a business sense. If someone is owner of something in a business, and they materially disagree with the direction upper management is taking, the result tends to be that they find another project to manage, and a new product owner is installed over your project.

I find this shield metaphor provides very clear direction. They should do what it takes to shield the team from the fallout of the disagreement. They should do what it takes to shield the team from the unhappiness of the customer if the CEO's direction is wrong. What actions are specifically taken to do so has to be handled on a case by case basis. If there was a clear cut answer, we'd replace the PO with an entry level employee and a script =)


On what level do You want to be as a product owner?

This article describes 5 levels of maturity as a product owner.


Then I guess it is up to you (OP) what you are happy with coming from the described situation.



Realistically, if the PO can’t convince the CEO that the PO is right, the PO can and possibly should be removed or the project canceled. Budgeting or other issues (possibly outside of the PO’s scope) may make a project unfeasible or force the CEO to reevaluate the scale and priorities of the project, but within those limits, if the PO can’t make a case for the project, one of the two (possibly both) should go.

That’s assuming it is a significant disagreement, if the issue is trivial then resolution is likewise trivial.

How this affects the team can vary from not at all, to all of them finding pink slips on their desk the next morning.

What the PO should do in this situation, will depend upon just how messed up things have gotten, the relationship between the PO and the CEO, and other factors that will very much depend upon the situation. The best thing the PO could do, would be to avoid it entirely, and not allow the situation to degenerate so far that the CEO has lost faith in them.

  • 1
    "Being a CEO does have its privileges." The person who is responsible to the Board of Directors for the daily management of the entire company does have the prerogative to tell you what to do. Commented Feb 26, 2021 at 14:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.