Scrum master vs. product owner (PO): Key differences and roles

Have you ever been to the kitchen of a five-star restaurant? I recently got a chance to check out a five-star hotel in India and since I knew the head cook, I also got to check out the kitchen. I’m a food connoisseur and love seeing the behind-the-scenes of food making. Everything in the kitchen was organized — from the plates to the spices.

While talking to the head of the chef, I came across an interesting fact. The hotel has an external consultant who comes to the hotel once every two weeks to help other chefs and cooks stick to the process of making food. This person’s job is to help the chefs cook food safely while keeping the taste of the food intact. I never knew something like this existed.

After I came out of the hotel, I realized this is so similar to the roles we have in software development. Like a scrum master, the external consultant makes sure that processes are in place to ensure the food is prepared safely and at the highest quality. On the other hand, like a product owner, the chefs make sure the food is prepared within the timeline and cost.

Thankfully in the world of software, there are tried and tested methodologies that help you cook “food.” One of them is agile — a framework to manage the complexities of software development. It emphasizes flexibility, collaboration, and iterative delivery. However, it also highlights the importance of some key roles required in this type of software development practice.

In this article, I want to focus on these two key roles and explain in detail the differences and how they collaborate with the product managers to build software that customers use and pay for.

What is a scrum master?

The scrum master focuses on the scrum processes and makes sure the team adheres to them. Below are the key responsibilities of the scrum master:

• Facilitating scrum events
  • Standups
  • Sprint planning
  • Sprint reviews
  • Retrospectives
• Coaching the team
  • Helping teams implement scrum processes
  • Helping teams when they’re stuck or have questions regarding the processes
  • Proposing solutions for process optimization
• Promoting agile best practices
  • Advocating for continuous improvement
  • Encouraging agile tools for better team productivity

Overall, a scrum master requires a deep understanding of agile methodologies and scrum processes and needs to have problem-solving skills to address team challenges. You can read more about this role here.

What is a product owner (PO)?

A product owner (PO) focuses on managing the product backlog and making sure the team is working on the right priorities. Below are the key responsibilities of a product owner:

• Guiding the product development team
  • Clarifying outlining questions
  • Removing roadblocks
  • Ensuring the team understands the goals
• Managing the product backlog
  • Creating, prioritizing, and maintaining backlog
  • Writing user stories and acceptance criteria
  • Testing the user stories
  • Refining the stories for the next sprint
• Collaborating with stakeholders
  • Writing weekly or bi-weekly status updates to stakeholders
  • Engaging with customers, business leaders, and other stakeholders to gather insights and requirements

A PO focuses on the day-to-day operations of the team and making sure the team works on the right priorities. You can read more about the role here.

Major differences between scrum master and product owner

Consult the following table to help you better understand the differences between the two roles:

How PMs relate to a scrum master and product owner

Back when I was at Zalando as a PM, we only had a PO role. For all the situations where we needed a scrum master, we used to book an external freelance one to pitch in and help us. Below are some situations that detail how I worked with a PO and a scrum master:

Collaboration with a scrum master

At one point, our sprint planning sessions were extremely chaotic and frequently used to go off-topic. We discussed this with the external scrum master and he decided to lead the sprint planning session. It turned out we didn’t have any clear action items for the meeting. At the end of the session he helped us to write a document detailing each and every step we need to go through in the sprint planning session to make these meetings very effective.

Retrospectives also weren’t helping us. We realized we weren’t making any progress on our retrospective topics. The external scrum master asked us to assign a team-member for every retrospective topic and it would be the person’s responsibility to make sure the topic was worked on.

Some other topics I worked on with the scrum master were improving delivery times, implementing structure for standups, and improving the story estimation processes.

Collaboration with a PO

I worked actively with a PO to make sure our priorities were set correctly. I shared all the necessary information related to product strategy and vision that the product owner used to prioritize features and user stories in a way that maximized value delivery within sprints.

Alongside this, I collaborated with the UX and design team to interview customers and stakeholders and then the PO made sure to include the feedback in sprint planning as a high priority. I also partnered with higher management to understand the project timeline and the overall cost, which helped the PO optimize resources.

---

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

---

Overall, I was involved with the PO on a day-to-day basis to make sure the team was working on the right priorities.

Common misconceptions and challenges

When it comes to scrum masters and product owners, there are three common misconceptions that tend to arise:

1. Often a scrum master is mistaken as project manager mainly because of their involvement in scrum meetings. However, it’s important to remember that a scrum master is a facilitator and not a decision maker
2. Often a PO role is misinterpreted as a PM. In fact, a lot of times companies post job descriptions of a PO for a PM role. And in some companies, these roles are used interchangeably. A good way to resolve this is to clarify that strategy and vision stays with a PM, while execution stays with a PO
3. Viewing a PO as a decision maker for the product is also one of the biggest misconceptions. Since the PO works with other stakeholders, a lot of times a PO is considered as a decision maker as compared to a PM. You can solve this by having clear responsibilities documented for each role

Tips for product managers on how to resolve conflicts and facilitate collaboration

The more roles there are in a team, the more confusion and conflicts it creates. Here are a few important ways to resolve conflicts and facilitate better collaboration between a PM, a PO, and a scrum master:

• Open communication — Make sure you create an open communication culture where teams can speak their minds. Hold regular 1:1s formally or informally with the scrum master and the PO to understand their pain points and share yours and align on a mutually benefitted solution
• Use visualization tools — Invest in tools and frameworks such as product roadmaps and opportunity solution trees to create a shared understanding.
• Documentation — Clearly document the roles and responsibilities of the scrum master, a PO, and a PM in a document that can be referred in case of confusion
• Early conflict resolution — Make sure conflicts are resolved as early as possible and with empathy. Facilitate role-swapping for a day to help team-members understand each other’s perspectives
• Transparency — Last but not the least, be transparent with your expectations and communicate constructively.

Conclusion

I have been a scrum master, a PO, and a PM and understand these roles extremely well. With the addition of AI, these roles are bound to change. For example, I recently read an article on LinkedIn about how a company has built their own ChatGPT model to moderate meetings, something that a scrum master does.

In five years we’ll surely see a lot of these roles getting automated. But until then, it’s important to distinguish these roles and create an infrastructure where all these three roles come together to build useful products for the customers.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.