Product owner competencies

Last post 01:55 pm April 18, 2013
by Ian Mitchell
3 replies
06:47 am April 18, 2013

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?

11:14 am April 18, 2013

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.

01:35 pm April 18, 2013

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.

01:55 pm April 18, 2013

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.