The PO spot has become a major point of focus in recent years, especially when the PO is doing a less than spectacular job.
However, the issues people are having with the PO are a natural consequence of how it evolved. Luckily there is a solution for the PO problem!
As you may know, the “Product Owner” evolved from XP’s “Onsite Customer”.
The “Onsite Customer” concept had a lot of problems in execution, and so, it was refactored somewhat to the “Product Owner” role. However, a few mistakes were made.
In some Agile methods (such as “Scrum”) the PO actually performs several different functions;
1) They are overall in charge of the project
2) They are the primary “voice of the customer”, or customer proxy
3) They must understand and coordinate many different business functions such as budget, backlog, customer feature requests, and prioritizing what the dev team works on.
Now, in a traditional business environment, there would be a “Project Manager”, and that PM would normally have a technical background.
Therefore, they would have an understanding of technical debt, and the need to architect or rearchitect a system, not just throw features at it.
The problem with the PO is,
1) They are usually converted Business Analysts and generally do not have a technical background
2) They have complete control of a technical endeavor which is generally beyond their core competencies
So how do we fix the problem? Very simply.
We refactor the PO to be the CP. The Customer Proxy. They prioritize the backlog, still, and juggle customer requests versus bug fixes but they do not have absolute power over the entire project.
Enter the Return of a Real Project Manager, with technical skills, who the CP now (rightly) reports too. The PM can then arbitrate conflicts between the Dev Team and the CP, keeping in mind the tradeoffs in terms of maintenance over the long term and juggling the profitability of doing any particular feature versus just doing whatever the customer says they want.
This lets the CP focus solely on what the customers want; the dev team to focus on what they need to succeed, and the PM to juggle the various tradeoffs and arbitrate conflict.
Putting a technical person in the PM role means the team will no longer be directed solely by a soft skills BA who does not often understand the technical project that is being managed.
Some may decry this as a return to the old, but the old had a lot of advantages compared to the new. To me this represents the best of both worlds.