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.

  • 4
    Scrum doesn't have "architect" or "technical product owner" roles. Are you sure you're actually doing Scrum? What does your Scrum Master have to say about this?
    – Todd A. Jacobs
    Apr 6, 2020 at 17:26
  • 2
    Could you please clarify whether you're asking for curiosity's sake or if there is an underlying problem you are trying to solve? The request for guidance/help to me implies the latter, but I'm not seeing the issue stated anywhere.
    – Sarov
    Apr 6, 2020 at 19:26
  • 1
    The issue here is that a PO as I understand it is to translate the wishes of the customer. However, the wishes which I translate in my user stories often time get pushed back by my architect and I am not sure as to how to deal with this. As a PO you are treated as an "outsider" and a customer to the team but when the technical lead dismisses the customer wishes.. I feel there is an issue and something that I as a PO might not be able to overcome
    – S124C41
    Apr 6, 2020 at 19:47
  • 1
    My scrum master is quite passive I am not sure that she is the right person for the job. Her main activity is scheduling meetings and escalating to me to solve impediments. I feel an SM is supposed to do more but maybe that's just me.
    – S124C41
    Apr 6, 2020 at 20:04

4 Answers 4


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?

  • Thank you for your reply it is helpful. I have joined 5 months ago and feel the team is not used to delivering value in an agile way (incremental). We are slowly getting there as I am trying to coach the team to do so by defining deliverables as sprint goals. About 3 sprints ago the team started to "honor" these goals. Based on the other responses it seems we are not a real scrum team and to answer your question we are getting there but there is very much a waterfall approach to things. Thanks for the insights Daniel
    – S124C41
    Apr 6, 2020 at 19:55
  • In my experience it can easily take 6+ months for a team to accept scrum, that is if you have a strict scrum master/PO. If the leadership is lenient it will never work cause scrum is not made for developers, but for reporters.
    – niid
    Dec 18, 2023 at 10:41

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 ...


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.