Skip to main content

Product owner competencies

Last post 08:45 am May 7, 2020 by Anand Pandey
4 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?


Anonymous
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.


08:45 am May 7, 2020

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.