Technical product owner does it really exist?

Question

I am considered a technical product owner however, looking at the amount of times my "user stories" and requirements get pushback from my Architect I am wondering whether being a technical product owner is a "real" thing and if so, maybe I am misunderstanding what it is about.

So could someone help clarify what is to be expected of a "technical product owner" if this really exists?

Just looking for some guidance/help here.

I am a PO for system-to-system API's.

UPDATE: I have come to understand there is no such thing as a TPO, however the way this company is setup and the phase they are in with regards to adopting agile helped me understand why my "position" was necessary.

1. To be able to translate customer needs related to "business logic" that needs to be implemented (i.e. retention policies on data based on domain, necessary filters and the design of the API itself)

2. To analyze feasibility of functional feature requests taking our integration layer into consideration (we do not only deliver API's we also created the integration between source and target system)

3. To help identify and manage any issues related to the source systems delivering the data as these are very functional in nature.

Answer 1

The very short answer is: No, there is no such role as Technical Product Owner in Scrum.

It understand why, we need to look at team composition. First, let's look at the whole Scrum team. The job of the whole Scrum Team is to deliver increments of a product that solve the needs of the customer.

Now, we could work like in XP where the team works with the customer as needed, but Scrum says "Wouldn't it be nice if one member of the team's whole job was to really understand what the customer needs?" and so you have a Product Owner.

So, if you are the team member whose entire job is to understand the customer's needs, then you are the Product Owner. How that turns into a backlog is largely between you and the team.

Past that, Scrum dictates that the team takes whatever approach it wants to build the product increment. In that regard, if you are determining the best way to do the work technically, you could be doing that as a member of the Development Team if that is the best way the team knows to build the product increment. However, since you are getting pushback, that doesn't seem to be the case.

Ultimately, the more important question than if the Technical Product Owner role exists is: Are you as a team finding the best way to build valuable product increments that are potentially shippable to the customer every sprint?

Answer 2

I agree with Daniel's assessment. It looks to me like someone realized the need for your position, got it approved with HR, and dubbed it with this title that isn't in the books. "Okay, just roll with it."

It seems to me that you should now just have a chat with your Architect – who seems to be your "downstream client" – to find out more about what (s)he needs and expects from you. What you can do to make his/her job easier and your work-products more beneficial and useful. Also check with any "upstream clients," to see if there's anything you can do within your role to make the team's processes and eventual deliverables more effective. (You can guess about this sort of thing, but I say, "nothing beats a polite and well-asked question followed by very careful listening.")

Your role might be more that of an internal SME = Subject-Matter Expert: chasing down and articulating requirements taken from "upstream" and turning them into architectural specifications that the Architect can then use. Which would be a very important role, indeed. So be it. Just do it. Whatever it's called ...

Answer 3

As others said, no, there is no TPO in Scrum.

However, typically, companies employ the TPO role to bridge a gap. This gap is between one level up and one level down.

One level up and maybe you'll find the true PO, maybe it's someone from "The Business", or a collective of people who are shaping the product.

One level down, the problem is that the team needs to deliver technical tasks, as opposed to solutions. And the TPO typically creates "technical user stories" to be fed into the team.

I am a PO for system-to-system API's.

As you see the whole setup is around the technical aspect of the organization/product because if it weren't, the company wouldn't need a TPO in the first place. So they need this someone who can talk on a technical level with their surroundings. Sometimes, (I don't know whether that's the case with you) this role is just a renaming of a Project Manager role, who needs to have a technical view/opinion on the project. Thus, your role is restricted to the technical implementation side, rather than truly act as a customer.

Granted, this setup is caused by not having an actual product. It also goes hand in hand with component teams (as opposed to feature teams). Component teams are building just a part of the product/software e.g. the API, or the database, and therefore are "doomed" to work on technical tasks.

Answer 4

In an idealised agile team, there is no need for a technical product owner. In a real one which has not only external end-users but a vast ecosystem and the people behind it, who have to live with the solution you create while taking whatever approach you find best for your customer, then maybe it is better to have someone whom we may even call a technical product owner.