The Failed Product Owner - do you even provide feedback?

Product owners often get blamed for not understanding Agile and for not providing clear requirements. Is this their fault though, or are you not providing the correct feedback to help them improve? Agile teams often work with the product owner absent, especially in the retrospectives. If that is true for your team, who is actually at fault then?

I hear this all the time. "The product owner" is absent or "the product owner can't give a straight answer on what I should do, it changes by the minute". This is especially prominent in project based organizations where Agile means that you just remove the requirements phase in your waterfall process to make things fall down to the development team faster. Agile becomes ad-hoc and chaotic and it is all the product owners fault. Right?

This is a problematic attitude and one that to me clearly means that the team is not really Agile, but still work as a receiver instead of the engine it should be. Although in most organizations there are two processes and the development team always is the receiver of strategic goals, they should not be a passive one.

Not being passive means that you put demands on what you receive.

How you receive a new business need, what information you need and how you work together with the product owner is not something that you passively sit around and complain about. It is the core of what the retrospectives are for! I would bet that in most teams where you have issues with the product owner you do not include that person in your retrospectives? Do you even provide feedback or set up activities to help the product owner improve together with you?

If the product owner is not included, then could the issue be with you and not the product owner?

The product owner is a part of your team. This means that you are responsible to speak up and ensure that everyone in the team is working in the way that best benefit the team. This means that you should provide feedback if the product owner is absent or if you do not get the information you need. This should be done in retrospective, just like you do it with every other feedback concerning your work process and collaboration in the team.

Easy to say, but our Product Owner does not care.

I know, this happens all the time. The product owner is tied up in meetings all day and just ignore your feedback. This is where you need to play hardball and provide empiric evidence that the issues you have is not your fault and that you have done your job to try to improve this. The First step is to go above the product owner and point out the issue to the people above. Sometimes that works, but it may not always be an option.

In the sprint planning you should be very clear on what information need to be present for you to accept a user story. Remember that once you put the user story in the sprint, you have accepted the user story and you are responsible for the consequence for poor requirements. Never accept a user story that is not clear enough for you to work on. It is the responsibility of the product owner to ensure the user story can be accepted by the development team.

If you use Jira then your next step will be to push back everything that is unclear to the product owner. This is done by assigning the product owner to the issue, put the issue in blocked status, or flag the issue if you do not have a blocked status and then comment saying that you wait for the product owner to respond. Once done, leave the issue and move to another issue. This will effectively remove the priority for the first issue as it will now be done after whatever issue you pickup next.

This will allow you to move responsibility to the product owner and point out the issues you are having. It also allows you to get statistics on waiting times the team have due to the product owner not doing their job.

Failure is on the team, not the product owner alone

Just as the entire team is at fault if the scrum master or a team member is dragging the team down, the same goes for product owners. You manage it through the retrospective and constructive feedback. Help the product owner to be the team member you need hem to be. If that fail, then you as a team will fail as well.

Make demands, just as you would for any other team member. Make sure their calendar have all stand ups booked, all retrospectives should be holy times and if they run around for meetings all the time, have them block time in their calendar for the team. You would not accept a developer to not do their job, so don't accept if the product owner is not doing theirs either.

At the end of the day, remember that no product owner want to be a bad one. They often get dragged into activities where their role is poorly defined, so they need help to define what you as a team demand of them. This will make it more clear to them how to prioritize their time, or find a replacement to make sure you get the team member you deserve and need.

Never sit silent with a clenched fist in your pocket.

Speak up and offer constructive solutions and you will be surprised how willing many are to solve the situation with you. Teams work together and since we still have not developed telepathy we need to verbally communicate and express our need to work better together.

Product owners are not outsiders, they are valued team members.

...or at least they should be.