Throughout my career, at some point or another every company that I have had dealings with has struggled with the role of the Product Owner.
I think each Scrum role is confusing for a lot of teams, companies and individuals, but arguably the Product Owner is the simplest one to understand, but one of the hardest to accept.
In simple terms, the Product Owner is responsible for ensuring that the team delivers something valuable. They are not responsible for how work is completed, or necessarily deciding every last detail themselves but they are ultimately the ones that set the direction, manage expectations and generally steers the Development Team in the right direction.
What I have observed as being challenging for businesses isn’t the concept, but rather accepting that this is the best thing to do, and/or actually giving the Product Owner the responsibility and trust that they require to be successful in their role. The Product Owner is one person, not a committee, as the Scrum Guide says — and yet to a greater or lesser degree almost every person I speak to in the agile community tells tales of a Product Owner being second-guessed by their superiors, team leaders, CEOs or even the development team themselves.
When you say to somebody “you’re in charge of steering this car” and then continuously reach over and grab the steering wheel, violently changing the course it’s almost inevitable that the car is going to crash sooner or later, and that in the meantime the path the vehicle takes is not going to be a smooth one.
It is when a development team, or members of a development team, don’t trust or respect the Product Owner that the greatest damage tends to be done. The unity of the team becomes damaged and the value of the work diminishes — in place of delivering value, the team easily starts doing ‘busy work’, choosing to simply do “something” rather than “something that matters” to the users of the product. When teams go down this road it can be very difficult to steer them back on course and in some circumstances it can be very difficult to even identify that this is happening.
When a team is used to doing 30 Story Points of work, getting them to accept that doing just 15 Story Points that deliver 10x the value, even if it theoretically means more down time, is actually better.
The Product Owner needs to be trusted, they need to be allowed to fall over and pick themselves back up without undue pressure or criticism: nobody will make perfect decisions every time.