Are a glorified order taker: The Product Owner works against a concept of where the Product is going to. They do not just accept requirements because someone important asked for it.
Commit on behalf of Team: The Product Owner defines what needs to be done and the priority; the Team decides how it will be implemented and how much they can work on.
Make technical decisions for the Team: Again, Product Owner does not worry about “how”.
Estimate Stories for the Team: The people doing the work should estimate the work.
Are not available to the Team: If the Product Owner is not available then the original reason for setting up this role is not being addressed.
Assigns work to Team members or otherwise tries to manage the Team: Team members determine how to execute the work.
Focus only on new functionality at the expense of ignoring the health of the product / solution: The Product is not just the result of new features; there is a significant on-going set of work associated with the health of the Product.
De-focuses the Team with latest break-in: While break-ins are expected, if this becomes a normal condition, then it is hard for Teams to make and meet commitments.
Create all User Stories: While Product Owners are often the initial source of requirements, Story creation and maintenance is a collaborative exercise with the Team.
Play favorites. Product Owners need to be able to balance the competing interests of stakeholders and have a transparent decision-making process.
Are not willing to make hard choices during the Iteration (Sprint) Planning meeting.
Are not available to the Team.