Skip to main content

Can you be a Product Owner if you don't have a Product?

Last post 06:11 pm March 8, 2021 by Ian Mitchell
7 replies
01:07 pm March 2, 2021

Not quite intended to be a philosophical discussion like the title may suggest but actually a real world situation. 



There is a dev team, there is a scrum master, and there is a product owner. But there is no product. This team is tasked with making sure the data in the system which is used by other product teams is maintained and accurate, and they are responsible for building new integrations with partner systems as these partners are brought onboard by the CEO.

A typical sprint for this team involves taking care of Support issues which have arrisen (data problems), working on some internal tooling to, again, reduce dev involvement on support issues (surfacing information or abilities which would otherwise require a developer to do), but this is again varied and really not the remit of this team, and building integrations with partner software.  

There is no 'product' to own, unless you define the data in the system as a 'product' but even then there isn't really any "ownership" of it, more like a "custodian". 

I have been brought in to be the Product Owner of this team, but i'm struggling becuase unlike any PO role i've done before, in my eyes I don't have a product, i'm not defining it's direction, talking to customers, building a roadmap and delivering on a vision. I'm simply managing a backlog of tasks which arrive at my team's door. 



Am I missing something here?

 


09:36 pm March 2, 2021

Is a valuable service being provided to others?


11:40 pm March 2, 2021

The Scrum Guide contains this text:

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

It seems like the product is the data, or perhaps the services offered to maintain and access the data.

I'm also not sure why you aren't defining a direction, talking to stakeholders, and delivering on a vision. How else do you determine which support issues are more important than other support issues or which integration is more important than another integration or how to balance time between all of the support issues and integrations? A true Product Owner would have the authority to make decisions about which ones best serve the stakeholders.


08:49 am March 3, 2021

I guess you are correct in that, looking at the above definition, I can answer all those points. 



Direction is tricky. There is a team above this one who's responsibility it is to essentially 'feed' this team with integration documentation and the relevant data required for them (kinda like a technical sales team, they are approaching the partners, getting the documentation, getting the data together and then passing it all down to us). This team then just does the leg work to build the integration, test it and put it live. Therefore, at present, the direction is primarily set by the team above as they are the bottleneck.



If that bottleneck opens up and we end up with a large number of integrations on our backlog and a choice as to which to build next, I still believe it would be the team above who would say which was most important, but that is yet to be seen. 



I guess I am struggling because i'm used to much more 'ownership'. This tea m/role just feel ike managing a conveyor belt. Also, we're primarily responsible for maintaining this data, but it is other people in the business who actually do the majority of the input here. (that tech sales team bringing in the original data when a new partner appears, shop floor people updating data to meet new requirements (perhaps a product has changed price etc)). We're just there to investigate/mop up when there is an issue.   

At no point does it feel like my product.


04:18 pm March 3, 2021

Not all products have human stakeholders or cost money to use.  Your product is the stewardship of the data.  Someone needs to learn the current and future needs of the stakeholders.  Someone needs to maximize the value of the work that the Developers deliver. 

A typical sprint for this team involves taking care of Support issues which have arrisen (data problems), working on some internal tooling to, again, reduce dev involvement on support issues (surfacing information or abilities which would otherwise require a developer to do), but this is again varied and really not the remit of this team, and building integrations with partner software.  

As a Product Owner you might want to analyze the Support issues and see if there are ways to prevent them from happening instead of reacting to them as they happen.  As Product Owner you might look at the partner software integrations and see if there are any future plans or common needs that could be done.  There is a lot of the "normal" product ownership/management work that can be done on internal tools but you have to be able to envision the problem space.


08:04 pm March 7, 2021

I read your initial paragraph and thought to myself that I do see a product here. Perhaps not a marketable, sellable one to a mass market. But a product all the same.

As long as the PO can actually make decisions about how to prioritise the work etc then I'm sure there is a place for the PO in this situation.

Then by constantly inspecting and adapting the team might find ways to reduce the amount of support needed.

When work "flows" and that is often the case in a support oriented environment I tend to feel Kanban might make sense. But each situation is unique.


10:39 am March 8, 2021

So i took my concerns to the CEO (i have weekly meetings with him).  And unfortunately he reinforced my worst fears. 



The plan is to move all the data maintanence and support work away into this new team which is being built, leaving my team with just the integrations. We would be fed integrations which were 'data ready'. My team's only job would be to code & test the implementations. My only responsibility would become the scheduling of these integrations. 



When i mentioned that I was concerned, that my team will essentially become just a conveyor belt for integrations and I could forsee morale issues if that was the case, as it's basically the dev equivelent of working on a production line.



His reply:

"... success for your team would actually be a conveyor belt of integrations"

I guess i'm seeing things differently to others here. I didn't become a PO to just schedule dev work.


06:11 pm March 8, 2021

On the plus side, congratulations on having access to the CEO. You have been able to get inside the management bubble and are not languishing at the bottom of the corporate food chain with the little people. Access to a sponsor for agile practice is something many do in fact struggle with. On the downside, not a lot of sponsorship for agile change, or an understanding of it, is actually being evidenced by senior leadership.

If your CEO views "success" as having a conveyor belt of sorts, why use Scrum at all? What outcome is hoped for? If it's a faster or cheaper production line, then the CEO's expectations may need to be revised. Scrum is about learning to build the right thing at the right time.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.