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

Is a valuable service being provided to others?

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.

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.

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.

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.

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.

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.