When the Product Owner has to say no

I read the following blog post "When the Product Owner has to say no". Intriguing but I could resist the urge to comment.

The scenarios where Product Owner has to say no in the blog post were quite true. To me, the Product Owner has to be able to say no and sometimes make those difficult trade-offs between which customer or internal stakeholder gets what they are asking for and which ones have to wait. Until you've had to sit in front of a VP and explain those trade-offs and why that VP didn't get what they needed, you haven't earned your chops as a Product Owner.

Here's what I take issue with the conclusion: "Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance." While I have no problem taking responsibility for my actions and learning from them. I do think this type of broad generalization leaves out of a lot of key facts:

1. Sometimes the Product Owner has to say no to an internal stakeholder in order to keep the team focused on its goals and commitments. This is not due to a failure in PO performance, but rather a lack of focus from other folks
2. The Product Owner is part of the team. While some may say that they are the single "wringable" neck, I'd like to think that the team can self-manage to prevent these types of unwarranted behaviors.
3. Part of the role of the Scrum master is make sure that the team is acting agile and following scrum practices. Many of the issues noted by the author of the blog post indicate a lack of leadership on the part of the scrum master.

I'm all about taking responsibility, but I'm not about the "blame the product owner" for everything mentality.