Feeling Undermined in My Role as Product Owner
I’m currently dealing with a situation and I’m not sure if any of you, as Product Owners, have experienced something similar or how you’ve handled it — particularly in work environments where there’s a lack of respect from someone on the Dev team.
I’ve been receiving repeated messages from the team’s architect via Jira tickets, where he asks me for clarifications on topics that he could easily direct to the person who’s actually responsible for the input or created the ticket. For example, someone from Business created a bug ticket that didn’t follow the format Dev expects. When the architect responds, he tags both me as the PO and the person from Business with messages like:
To me, this feels deeply disrespectful — and this is not the only time he’s pointed fingers at me like this. His behavior is causing me both stress and sadness, because I truly want a positive and respectful work environment.
I feel like he’s giving me orders, and while the Dev team says they reach out to me because I’m their Ansprechpartner (main point of contact) and not Business, and that I should be the intermediary — I don’t have a problem acting as an intermediary. What I do have a problem with is being constantly singled out by the architect, as if I’m not doing my job properly.
If only I could find another job...
It sounds as though the work was not ready for Sprint Planning. If Developers expect Product Backlog items to be in a certain format, then this ought to be taken care of in Product Backlog refinement. Is enough time being reserved each Sprint for refinement to happen?
That sounds like a tough and frustrating situation. As a Product Owner, it's important to feel respected and supported by your team. While being the main contact is part of the role, it doesn’t mean being a scapegoat. Maybe it’s worth having a calm 1:1 with the architect or involving the Scrum Master to help reset expectations and improve communication dynamics. You shouldn’t have to carry that kind of stress alone.
...a bug ticket that didn’t follow the format Dev expects.
This is a red flag for me. Not because someone entered an item into Jira in a different format. But because Dev expects a certain format. Not all things fit easily into a specific format. In my 30+ years of software development, I have never found a specific format that works for everything. I suggest that things be written in the best way to convey the message that is needed. Especially if this is being conveyed by someone internal to the organization. How difficult is it to just reach out to that individual if there are questions to get clarification. And then update what ever records you have with the new information?
Yes, I have dealt with this. The way I dealt with it was to ask the person that is complaining why the format they want is better? Have them show me how that format would have made the item that they are complaining about better. Let them be the one that changes the behavior since they are the one that expects it. Let them feel the pain of trying to fit everything into a specific mold. And you should also question them anytime that they do something that doesn't "follow the format" that you or others expect. Even if you have to make up a new format just for the exercise. Help them see that they are being unreasonable.
Thanks for raising this—it’s an important issue to address..
Similar to feedback above, speak directly to the architect, but I would recommend the entire team. Get the Scum Master involved, for advice and facilitation with the team on this issue.
As @Danial mentioned, it does sound like the development team might be trying to enforce overly rigid processes. It’s worth reminding them that Scrum is meant to be lightweight and adaptable—not bogged down by unnecessary bureaucracy.
From my experience in IT, architects sometimes feel compelled to take charge, especially if they feel their input is being overlooked. That frustration can occasionally come across as domineering. This is where open and respectful dialogue is essential.
Scrum promotes shared leadership and collaboration. The architect’s drive and energy can be a valuable asset to the team when channelled effectively. If their approach begins to overstep, raise it either in a team setting or one-on-one.
Don’t let this situation discourage you. These kinds of challenges can—and do—happen in many organisations. What matters is how we address them. Open communication and a team-first mindset are usually the best way forward.