Who Should Be the Product Owner? Role Definition for a New Project

#1

Hello Everyone,

My team has been using Kanban for some time now. We have a new project developing a tool for another department within our company. Currently, we are defining the roles for the project. My boss believes that the key stakeholder that we are building the tool for should be the product owner. However, this stakeholder has no experience with SDLC or Agile. I believe that the product owner should be a member of our internal team that has agile experience. This person could work closely with the key stakeholders to develop a vision and prioritize the backlog.

What are your thoughts on who should be the product owner? An internal team member with agile experience or a client that is the subject matter experience for the domain that the tool is being used in, but has no SDLC or agile experience.

#2

In our organization we have found that the best PO has come from the business / client with the domain expertise. We can teach and guide them on what a POs role is and how to conduct the agile components they need to do. Yes, it take a little longer for the backlog items to be created properly but with a good agile team they can pick that up.

The business domain isn’t always the easiest to pick up and have the passion / in-depth knowledge of how the product will solves the business challenge.

#3

I’d second that approach. Subject matter expertise is harder to gather. You can learn how to operate in an agile role if you have the right mindset, but gathering deep knowledge that addresses a genuine business need in a field is difficult.

The PO is your link to your customer’s state of mind. It isn’t necessarily the easiest thing for a delivery team to bridge that empathy gap. It can work, but it is harder.

#4

I just heard in a keynote talk the other day (forget which one), that:

“It’s easier to teach business folks to talk to engineers, then teach engineers to talk to business people”

It’s okay to differentiate between “customer” and “product owner”, but someone who can bridge that gap is important. If the stakeholder can’t make the time to be available for the team, I can see your desire to have someone already inside the team. But if the team isn’t close enough to the customer, they will make the wrong thing. Also, I assume you don’t have the option of hiring to solve this problem (if you did, then hire a good PO to do the job).

Rather than make a one-size-fits-all statement, I’d make a judgement call based on the people and personalities (and chemistry) involved and find a way to measure success from retro to retro.

#5

I am in a similar (imposed) situation. From that experience I would recommend a high level business stakeholder as product sponsor (aka they believe in the benefit but don’t need to act until issues arise - this should be a person with a proven track record, ideally from the It side) with a product owner representing the business needs. Key is though that the product owner actually has the bandwidth to be approached by everyone by the development / delivery team. If that’s not the case we are back to trying to bridge ‘wagile’.

#6

I’d second all of what’s been posted so far and @kschlabach and @Karina_Gerdes comments echo my thoughts and experience as well.

In past, when we had to deliver a fixed price project to a large utility, we had a “Product Owner” who gets it (that was me, lol), working closely with a “Business Owner/Representative” representing the business and technical teams on the client side. The client usually knows that they have a lot of problems to solve (and will ask to solve all of them now), in most cases they also do have solutions that they think is the best, having a PO that worked closely with the BO in prioritizing, defining the MVP and setting the expectations greatly helped us deliver the project on time and meeting the businesses needs.