Product owner competencies
How much technical knowledge does the PO have to have? One of my colleagues claims, that the PO must have a deep technical knowledge, and has to be able to architect the solution for the teem. As far as I remember from my training, the PO requires domain knowledge, so if you write an accounting software, the PO must understand accounting, but not IT. The PO is the guy who says What, but it is the development team who says How it will be implemented.
What do you think?
The Product Owner is the person who is responsible for prioritising the backlog (based on business value, hopefully), negotiating with stakeholders and working with the team to manage the items on the backlog. The Product Owner owns the product backlog. Those are his or her tasks.
There's nothing wrong with a PO that has deep technical knowledge. But there's certainly nothing wrong with a PO that has no such knowledge. In any case, a PO does need to have an understanding of the business value of the items on the backlog and be able to make informed decisions. If technology has an impact on these decisions, then it is up to the team to educate the PO where necessary to allow him or her to make decisions.
Requiring deep technical knowledge from your PO, or even asking him/her to solely architect the solution, seems to me like mixing up roles and responsibilities. The Development Team is responsible for translating the backlog into working software. This includes architecture. If a PO wants to be involved there, I don't see an immediate problem. As long as the PO remains focussed on his / her own responsibilites before anything else.
I totally agree. I just want to convince my friend, and there is always a chance that I misunderstand something. This is why I asked here.
A Product Owner should care about the release of value. If they need a "deep technical knowledge" to do that, and to manage the release of value in a timely way, then so be it. But that's not usually the case.
Your colleague may have had prior experience on a rather unusual project (such as an internal one for paying back inherited technical debt) which has shaped his or her thinking.
The Product Owner should be technically aware enough to appreciate the feasibility of the solution, exploit new technology for maximizing the value of the product, and empathize with Dev Team when they highlight technical impediments. But under no circumstance should they super-impose their technical competency on the self-organizing behavior of Dev Team, though they can share their thoughts on the technical approach, and Dev Team should be transparent in providing the information as long as it is not impeding their Sprint Goal.