Scrum Product Owner Interview: Product Delivery & Scrum Methodology

There are many methods for achieving a product goal on a specified timeline. Among the most popular is Scrum methodology, according to Zippia, which reported that 61% of survey respondents from around the world used this process. Understanding how this method delivers on product features by having Scrum teams work with stakeholders is the key to figuring out how it can help you turn good ideas into exceptional products.

At the center of this team-up is a communicator and representative of the target audience: the Product Owner.

A critical role in Scrum, the Product Owner is responsible for defining and prioritizing the features and requirements for a product and ensuring that the development team is working on the most important ones at any given time. In this position, a professional experienced in Scrum will work closely with the development team members, stakeholders, and customers to understand their needs and priorities. Another part of Product Owner roles and responsibilities involves keeping the project aligned with both overall strategic goals and the focused product vision.

They also play an essential role in facilitating Scrum team procedures, such as sprint planning, daily standups, managing user stories and product backlog items, and sprint review and retrospectives to implement the Scrum framework during product development.

Learn more about how the Product Owner role improves collaboration in product management by hearing directly from our qualified Product Owner, Elisa. Below, she answers common questions about Scrum methodology and her work experience with development teams and decision makers.

Read: Scrum Masters and Product Owners: Roles In Software Delivery

Exclusive Interview with Product Owner, Elisa

Tell me a little bit about your experience. How long have you been working as a product owner in Agile team direction?

I’ve been leading teams for approximately 10 years. For Agile teams specifically in a product owner or Scrum Master role, I’ve done that for the past 5 years or so.

The very first technology team I worked with was really interesting because it was a very small team: two developers and a designer. They didn’t have a project manager at that time, so they were kind of lost. I was brought in from a different department, and I was both the Scrum Master and the product owner for that team because it was so small. 

Together, we implemented Scrum. We built up the team. And because we were able to get organized, the team was able to grow. 

At that point, I realized that Agile and specifically Scrum really fit my professional goals and what I wanted to do. I’ve stuck with that process from that point on.

You said you had two roles at the same time, which can happen with a lot of small teams. What’s the difference between a Scrum Master, a Project Manager, and Product Owner? 

The Scrum Master is there to do two things. One is to ensure that Scrum process is being followed in the way that the team decided to follow it. Scrum is a framework, so they give you guidelines of what you should do, but you’re not obligated to follow a specific pattern. As a team, you decide how to implement things. 

But there are certain things that the Scrum Master doesn’t ensure: that the daily call is taking place, that the daily call is not getting derailed into 45-minute discussions about a specific thing, that the sprint goal is being defined. So basically, think of a Scrum Master as an auditor of sorts. They’re just ensuring that things are running as smoothly as they can with the Scrum process itself. 

The Scrum Master is also responsible for ensuring that any roadblocks the team runs into are resolved. So, if the team has an issue with the database and they’re unable to proceed with implementing a change until the issue is resolved, the Scrum Master would need to reach out to the data team (or whoever’s responsible for maintaining the database) and check in with them. 

They need to see how much longer it will be for that to be resolved, so they also remove roadblocks to the best of their ability.

Now, the Product Owner is a representation within the team of the end customer. In some companies, they do have the end customer play the role of the Product Owner. That doesn’t always happen, depending on how the company is set up. 

The idea is for the Product Owner to be the voice of the customer within the team. So they need to ensure that the highest priority items are being taken into account, that the requirements are shown or described in a way that will ensure that they’re implemented correctly, and making sure the day-to-day team has all of the necessary knowledge to implement the requirements properly.

Finally, for a Project Manager. The main difference between a Product Owner and a Project Manager is that the Product Owner’s emphasis is on the product itself. So again, it’s a representation of the customer within the team whereas a Project Manager is more focused on the company’s performance overall. 

I believe that a lot of tasks and responsibilities will be very similar. The main change is the focus and the importance that each role gives to the day-to-day tasks.

Why did you decide to manage teams with Agile methodologies?

I have a software development background, education wise, so I already had a certain affinity for the development process. But development itself was not something I found my passion in once I was already involved. So, as I was working with a technology company, we were exploring different options where I could apply my technical background in a more administrative role. That’s how I got started. 

Then, a lot of the soft skills I have really fit well with this role. I enjoy the process of prioritizing tasks, of getting to work with different people in different roles, and figuring out how different skill sets all work together to accomplish a specific goal. Or, in the case of Scrum, to accomplish all the sprint goals.

So I’ve really enjoyed that side of things: organizing everything, gathering the requirements, cleaning them up, working with the teams, answering questions, and meeting with other people that may have the answers if I don’t have the answers. I think that’s what I’ve enjoyed the most about being a Product Owner, is that communication. 

I mentioned earlier that you meet with people from all different backgrounds. So, as a Product Owner, you will have a meeting with the database team and their own culture. Sometimes, you get to meet with the design team, which has an entirely different culture and different personalities. It’s really cool and interesting to be able to experiment with how different teams have their own culture and their own way of communicating, then adapting to that.

Understanding that a Product Owner is basically a client within the team, have you ever disagreed with a stakeholder because their request was in conflict with the purpose of the team?

Yes, and it does happen a lot. At different scales, right? Sometimes, it’s smaller differences in what they think the best approach for implementing something is. I think part of the role of the Product Owner is to keep the customer’s best benefit in mind. 

Sometimes, that will include pointing them in the right direction if what they’re requesting is not in the best interest. If it’s a situation in which what the customer is requesting is going to be very complicated and would impact other requests, it is the role of the Product Owner to make that clear to the stakeholder or the client. 

If the client is aware that what they’re requesting could potentially impact other requests or that it will take a significantly longer amount of time than another proposal, I think the Product Owner should follow the customer’s request as long as they make it known what issues they could run into in the future. I don’t know if other Product Owners would think differently, but I do think it’s important to keep the customers in mind and their wishes and desires as top priority.

Now, there will be cases in which what they want just cannot be done. In that case, I think the best approach is to get a couple of representatives from the technical team, get the stakeholder or the client and the Product Owner on a call, and brainstorm together what the best solution is going to be.

In my opinion, that has worked really well because it clarifies to the customer why something cannot be done the way that they wish. And it usually ends up coming up with a solution that works for almost everyone, or at least resolves the most critical aspects of the request. 

I will say that sometimes, depending on the technical team, you can have a team that is not very customer-friendly. In those cases, it will require the Product Owner to be a lot more involved in understanding the technical blocks themselves, so that they can clearly explain that to a customer if a technical team is not able to explain it in terms that are easy to understand for someone that’s not technical.

What would you include in skill sets that are important for a Product Owner to have?

I personally think it’s a lot of soft skills, so: communication, organization, productivity. Organization is probably the most important. A Product Owner will usually have a few different implementations of a product going on at the same time. 

So it’s important to keep that organized and make sure you’re not missing anything crucial along the way. At the end of the day, you’re responsible for that product itself. That is literally the most important thing for a Product Owner. If you’re not organized, you can end up missing essential things.

Why is it important to have a Product Owner that is independent from the stakeholders, and on which types of projects?

Having one that’s independent isn’t always the best. The Product Owner not being the stakeholder or client themselves will typically happen when an organization has multiple customers. So, you have one product that’s being sold or marketed to several clients. 

When that’s the case, you obviously won’t be able to have one representative of each client in your meetings. That would probably not be very useful for the organization. So that’s definitely a setting in which you would not have that. 

Another one, and one that I’ve had to interact with in the past, is when a product is being used by multiple teams within the same organization. So these are external customers, they’re internal customers. But one program is being used by several teams in different ways. 

So you need to consolidate one Product Owner to represent these different teams. And that one can get tricky! Especially if you have different teams that their requests are more important than the other teams’. That’s when it’s useful to have just an independent or non-stakeholder Product Owner.

If you are creating a product for one team or one specific customer, if it’s within the reach to have a Product Owner directly from that team or from that customer, then that is the best approach in my opinion.

How has your experience been working with two different organizations as part of both of them?

I think my experience is slightly different than the majority, based on what I’ve been able to observe. But I work full-time with my day-to-day activities for one company, doing tasks that are all related to their operations. 

I’m more involved with the development partner only in the more social activities. There is one person in the partner company that’s in my team, but apart from them, everyone else is directly in the other company. So my daily work is more focused on that.

In a way, I’m the bridge of communication between the two. The company I work for full-time is on the smaller side, so the director and even the CEO are very involved and very hands-on in day-to-day activities. But yeah, bridging that communication between management and the actual team is part of the task.

What do you think is the most valuable thing you bring to the project you’re working on?

A different perspective! The way that the main company I work for handles Scrum and the Product Owner role was very different than what I was used to, and we’ve kind of compromised a lot. 

I have modified my way of working to fit their way, but I’ve also been able to bring a different perspective. And some of the things I’ve mentioned, we’ve been able to discuss and implement as a team. So I think that’s been helpful on both sides, actually. I have learned a lot and looked at things in a new way than I had before, and I think I have been able to provide a fresh perspective as well.