Currently, I'm a Senior Solution Architect within a Agile organization (transitioning from waterfall to Agile to SAFe practices) and I'm filling a product owner role for the interim. I'm wearing both hats at the same time for now (Architect & PO).

I'm being asked if I want to stay as product owner since I have past experience being a scrum master & PO.

I like the senior solutions architect role and always wanted to grow in that area (still want to grow in this area) like becoming an enterprise or principal architect in future since I have a very technical background.

Product owner is sometimes considered an authoritarian role in our organization where product owner has the final say in which direction to go. It may override senior architect's decisions sometimes.

On paper, a product owner usually doesn't have a technical say / technical decisions maker. Due to this aspect, I'm not fully convinced that I want to stay a product owner for a long run because I would like to have that technical say / decision maker as an architect or SME. I'm concerned that by becoming a product owner, I'll lose that authority but I like the product owner role as the one who leads an agile squad and get to be someone who decides priorities and face of the team to deliver maximum value.

I am torn as I can't decide if product owner is a step-up role or not. I like my technical side of the role as an architect / SME.

I'm wondering if there is a Technical Product Role where product owner has a say in technical decision and can guide developers with right approach & best practices and can do more that just managing a backlog and stories?

In other words, as a product owner I don't want to be seen as a person whose role is focused on managing just backlog, stories etc and doesn't have technical in-depth knowledge - because I do.

  • Are you a SAFe Product Owner or a SAFe Product Manager? In the SAFe framework, a Product Owner is at the team level, along with the SAFe Scrum Master / Team Coach and the developers. The System Architect, Product Manager, and Release Train Engineer are at the ART level. There is no role in SAFe called "Technical Product Owner".
    – Thomas Owens
    Jan 6 at 13:10
  • Also, is "Senior Solution Architect" your company's title and does it have any relation to the SAFe Solution Architect that exists in the Large Solution level? It seems like there may be confusion between your company's role names and the SAFe role names. On top of that, there may be conflicts between what a company expects a role to do and what SAFe's definition of the role is. I would recommend editing this question to use exclusively the SAFe role names.
    – Thomas Owens
    Jan 6 at 13:13
  • Thanks @ThomasOwens for your feedback. My company is in a transition please where they are making Agile squads and bringing SAFe into the play. Yes, my company title is Senior Solution Architect. Based on your description it should like PO and Architect are distinct roles and can't be mixed. I either need to choose to stay PO then I won't be involved in technical decisions but if I continue down my architect plan then I'll be into technical decision. At this point, my org have not added any product manager positions or scrum master. It's PO + Agilist + Devs = Agile Squad
    – kl2
    Jan 6 at 13:48
  • 1
    I can't make career recommendations. That's a personal decision for you to make.
    – Thomas Owens
    Jan 6 at 14:27
  • 1
    Career advice and guidance is off-topic. We can't and won't answer those questions here. You'll have to go elsewhere if that's what you're looking for. Unfortunately, I can't suggest a place to go for this kind of question, but there's probably a discussion forum or similar out there that deals with career advice.
    – Thomas Owens
    Jan 6 at 14:34

1 Answer 1


The separation of product-centric and technology-centric roles is common across frameworks - DSDM, Disciplined Agile, SAFe and other frameworks all separate the business and product management from the technical architecture, design, and implementation.

In my experience, separating product decisions from technology decisions is a good thing. There is an inherent tension between what users and customers want and what needs to happen to build, operate, and maintain a solution. By putting the voice of the customer and the voice of engineering/technology, the people speaking on behalf of these two sides can have a facilitated conversation. From what I've seen and experienced, when one person is responsible for both, it's difficult, if not impossible, for them to have a rational debate over options with themself and the choices made may not consider the other side. Introducing a third coaching role also introduces a facilitator into the mix.

There is a problem when one role has an "authoritarian" position and is the final decision maker. The problem is exacerbated when the decision maker is using that authority and either choosing to not have conversations with their counterparts or does not have the knowledge and skills needed to make informed decisions, even with conversations. However, this is also often a necessary problem since someone needs to be able to decide when the product side and technology side disagree and cannot reach an agreement. I've seen causes where the authority rests with product and where the authority rests with technology/engineering and both have risks. There is no "best practice" here.

The rest of this gets more into The Workplace territory, regarding finding and maintaining employment or developing a career and requisite skills.

There are a set of skills that are seen as "product" and a set of skills that are seen as "engineering" or "technology". Some of these skills do overlap. In most cases, though, as you move up through an organization to higher levels of seniority in either product or engineering/technology, you are expected to focus. That doesn't mean you can neglect the other. An engineer who neglects product management knowledge will be a weaker engineer since it will be more difficult for them to have a conversation with a product owner or manager. Likewise, a product manager who doesn't try to understand the technical work will not be able to effectively prioritize work in a way that sets the organization up for long-term success. However, at some point, organizations typically expect people to focus on one side or the other. And once you specialize, it may be difficult to move across, especially without going backwards a level first.

But I'd also point out that there is a third option: coaching. And the Agile Coaching Competency Framework demonstrates my point. All agile coaches are expected to be able to teach, mentor, facilitate, and coach teams in lean and agile values, principles, and practices. They do this by drawing on some kind of mastery - technical mastery, business mastery, or transformation mastery. Good coaches are strong in one form of mastery but need at least awareness of the topics in the other. Having experience and strength in two can make the coach that much more effective, especially if the strength is in both technical expertise and product management. Someone who is strong in both can facilitate the hard conversations between the voice of the technology and the voice of the customer.

  • Thank you Thomas for sharing these details, it is very helpful. I have some questions, are you saying in true agile environment, architects should'nt be a part of an Agile squad and should be independent of a squad? The ART hierarchy that you described? Also, in my org there are no scrum master. It's PO, Agilist and developers.
    – kl2
    Jan 6 at 14:39
  • Another aspect where I would like to learn more (if you could please help me understand) how to separate roles from titles. May be I'm confusing the job title with these roles because my org tends to give POs an official product owner title. My understanding is that an architect or manager or anyone can be a producer other focused on the product success. But, then what's the point of having an architect or manager title if day to day role is to manager backlog of a product?
    – kl2
    Jan 6 at 14:42
  • @kl2 Every team should have design and architecture skills, but there are many ways to get those skills on a team, with one option being to have an architect on the team and another to have domain experts off the team that the team can turn to. When you scale up to multiple teams, you often want and need someone looking at architecture across all teams and coordinating activities. You see this in DSDM's Technical Coordinator or SAFe's System Architect, Solution Architect, and Enterprise Architect or Disciplined Agile's Chief Architecture Owner.
    – Thomas Owens
    Jan 6 at 14:48
  • @kl2 As far as role versus title, I'll use myself as an example. My job title is given to me by my organization. Now, it happens to be "Senior Process Improvement Analyst". My work is like SAFe's SAFe Program Consultant or Disciplined Agile's Process Engineer. Roles tend to be defined by methods or frameworks and come with responsibilities within the context of that framework. Titles are given by an organization and come with responsibilities to that organization. Hopefully, the two are at least somewhat aligned.
    – Thomas Owens
    Jan 6 at 14:55
  • 1
    @kl2 Architect doesn't have to be a separate role - sometimes it is, sometimes it isn't, and there's no right or wrong. However, I do believe that your technical roles should be separate from your business and/or product roles.
    – Thomas Owens
    Jan 6 at 15:23

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.