Different clients bring different projects, perspectives, workflows, and experiences, as well as different challenges. Before starting a project, one of those challenges is to define who will be the Product Owner opens a new window .

Ideally, you would be able to assign the role internally or to the client based solely on the characteristics of the project. However, that’s not always the case. It might just be that the client insists on being the Product Owner or that you are a small team and can’t really assign the role internally. Whatever the reason, you might end up in a situation where your client isn’t really a good Product Owner.

Here I’ll share some strategies we implement to help our clients become better Product Owners and ensure the best experience for them and for our team.

Communicate expectations clearly

Not every client is familiar with the responsibilities of the Product Owner. Not every client is even familiar with Agile/Lean methodologies. Therefore, it is important to communicate expectations clearly at the beginning of the project.

During the kick-off call opens a new window , make sure the point of contact in the client’s team understands what the Scrum master and the Scrum team expect from them. Some key points to cover:

Product Owner is a role you play in the Scrum team.

It is not the same thing as being a Product Manager. As a Product Owner, there’s a need to be much more team focused than market/customer focused. A good way to explain the difference is to outline what the workflow would look like if there was a Product Manager and a Product Owner.

The Product Manager would conduct user research, identify market needs, align it with business goals and own the vision for a product. They would then communicate the requirements to the Product Owner. The Product Owner, in turn, would translate those requirements into user stories, prioritize them and work with the team to implement the solution.

The Product Owner is the point of reference for all things backlog related.

This is the person who brings in the client’s vision, who knows what project stakeholders want. But they’ll also need to be the one to translate that into user stories and priorities within the backlog. They don’t need to necessarily be the ones writing user stories, but they’ll be the ones making sure stories are well defined and the team understands what needs to be done.

The Product Owner is responsible for ensuring the backlog is visible, transparent and clear to all.

As such, the team expects the Product Owner to keep the backlog groomed and organized. They need to make sure priorities are assigned and are current. If priorities changed, this needs to be reflected in the backlog. If stories became irrelevant, they need to be removed from the backlog.

The Product Owner is the main point of contact for conceptual questions.

If the team needs any clarification on any of the stories, they’ll look to the Product Owner to answer their questions. During sprint planning calls, any clarifications in terms of the scope of a story or the requirements will be directed to the Product Owner.

Make sure the Scrum Master and the Product Owner are aligned and the Scrum Master is able to help as much as possible

You may find yourself in scenarios where the person assigned to the project by the client is not the Product Manager or the client has never heard of Scrum before.

In these situations, it is important for your Scrum Master to be able to step up and assist as much as possible. After all, they are familiar with Scrum already and are in a good position to help.

Some strategies that are helpful here:

The Scrum Master can write user stories

The vision on what needs to be done and what problems need to be solved will come from the Product Owner. But they might not know how to write a good user story. In this case, the Scrum Master and even the team can help by translating that vision into user stories.

The Scrum Master can be firmer during Scrum calls to make sure they fulfill their actual purpose.

Working with someone on the client’s team might mean they are under pressure from their stakeholders and will end up gravitating towards being more of a Project Manager than a Product Owner. The Scrum Master can pay attention to that and intervene when needed.

If the Product Owner is using Sprint Planning calls to just add that “one more story”, communicate clearly and explain what the sprint planning calls are for and why is it important to the team and more efficient long term to respect the limitations set.

If they start using retro calls as a way to pressure the team, make sure they understand retro calls are supposed to be an opportunity for learning and improvement that goes both ways. Asking why more things weren’t done isn’t going to help. The important thing is to evaluate what could be improved in the process and workflow so that more can be done.

The Scrum Master can help the Product Owner understand these concepts.

Rethink how you talk to the Product Owner about priorities.

One of the biggest problems of working with the client as the Product Owner is prioritization. A lot of the time they will see everything as a priority. So rethinking how you talk to them about prioritization is a good idea.

Don’t simply ask them to go into the backlog and prioritize stories. Instead, take some time to review the backlog with them before the next sprint planning call and ask questions such as “compared to all these other stories here, how important would it be to your business to have this done?” or “what feature here do you think would make the largest number of users happy?”.

Make sure they understand the time commitment and the impact it has on the team

A frequent problem with having the client as the Product Owner is the time commitment. You might end up experiencing a lot of absences, specially during sprint planning and retro calls.

It is important to make it clear from the very beginning of the project that the team needs the Product Owner to be available, not only for those calls but also on a day-to-day basis to answer questions and accept stories.

Make sure the Product Owner understands the impact an absence on a sprint planning call or a retro call with have on the team and on the project. Make it clear that, as the Product Owner, the team expects them to provide guidance in terms of priorities, answer questions about stories and accept stories that were delivered.

If they are not available for the calls nor to answer questions during a sprint, there might be delays during the project. Stories might need to be reworked due to lack of understanding and might even be worked in the wrong order because the backlog wasn’t prioritized.

Make it clear that there must be ONE Product Owner

Some clients will have multiple people involved in a project and, as such, several different stakeholders might attend your demo calls. The problem? In many situations, several different people might start asking for features, changes, tweaks or just “one more button”.

It is important to make it clear to your client from the very beginning that the team will rely on ONE person to own the backlog, prioritize it and make sure user stories meet the requirements. This person will make sure that every change or tweak that comes afterwards will be added as a new story.

It is also important to enforce those rules during demo calls. If the client’s stakeholders start discussing new features, nice-to-haves, bells, and whistles, the Scrum Master must intervene and make it clear that suggestions are being noted. Those notes will be discussed further with the Product Owner, who will be responsible for making sure user stories are written and clear. They will then provide the team with all the necessary details and prioritize all new stories.

Conclusion

Communicating clearly is key to making your clients better Product Owners and having in mind “red-flag” behaviors. It is also key to count on a Scrum Master who knows how to identify red flags and steer the client back to the Product Owner track. These strategies should help.