The Product Owner is a key role in a Scrum team. I am not saying it is the most important role in the team (Scrum doesn’t advocate team hierarchy or reporting lines) but in my experience I have found that a Scrum team works more effectively with a strong Product Owner. Whilst they aren’t required or expected to lead the team, showing strong knowledge of their product and ownership of the work they ask the team to do are key components for an effective PO/scrum team relationship.


The biggest find I’ve found a team needs towards the PO is respect. The pure nature of the relationship between a PO and the team is one of suspicion and I’ve found in many occasions distrust. Dev’s tend to distrust people in the business and frequently accuse them of not knowing what they are doing or understanding their product or customer. The best PO’s i’ve worked with can engage with the team and discuss the product on more than just a business level. Whilst PO’s aren’t really expected to be hugely technical I’ve found that being able to understand the technical challenges faced by the team and engage with the team is a great way for a PO to gain a teams respect. I’ve heard many PO’s say “the technical stuff isn’t my problem, just get it done”. Whilst this is kind of correct from a black and white perspective, in practice it is very much the PO’s problem if it results in less productivity towards their product.

The proxy Product Owner

I’ve worked with a few PO’s who have just had the role of the PO forced upon them. They tend to not really understand what is required of them and they are not empowered to make decisions. I’ve worked with a few PO’s who need to go back to their boss or stakeholders for every single decision. The PO should be a single point of contact to the team, whilst i don’t object to frequent PO/stakeholder discussion (in-fact i wholeheartedly encourage it) having a PO who cannot make quick decisions will just slow down a team. I’ve also found the team loses respect for the PO very quickly as they feel they really aren’t in control or know their product. I tend to find you get a lot of “proxy Product Owners” in companies who do not fully adopt or understand agile software development.

As a ScrumMaster i hate it when PO’s have no idea of what the story they are asking for is for or why its important. I’ve experienced PO’s who have said at Sprint Planning “i have no idea what this is for but [INSERT BOSS’S NAME HERE] tells me it’s important”. Situations like this are just unacceptable and highlights a massive breakdown in the PO’s role.

I’ve found that if you put Crap into a sprint then you’ll get Crap Out!


Being certified doesn’t mean you own your product

Please don’t take this the wrong way, i think certification is an important part of anyone’s career progression and knowledge improvement. However, just because you have been on a course it doesn’t mean you are now a Product Owner. I have had the same argument with many more traditional PM types regarding the ScrumMaster course and i agree, a course doesn’t make you a ScrumMaster or Product Owner. In both roles there are characteristics and core principles of Scrum that need applying/spreading throughout your organisation. Some of the best PO’s i have worked with are not certified, Product Ownership is much more than being able to show a Scrum Alliance or certificate. Certification should be the very start of your journey with Scrum, unfortunately a lot of people seem to think this is the end of their journey. These are the people i wouldn’t call “true” Product Owners.