An intern kindly needs help: Internal proxy product owners a bad idea for this usecase?
Hi everyone,
This is my first time posting on this forum, and I am quite new to the scrum methodology so please excuse me if I make any mistakes.
I'm a student and I'm currently interning at a company where I am trying to understand if my supervisor's requirement is a bad idea, and I am trying to make a case with well thought out arguments. This is where I am kindly in need of the SCRUM forum's help.
First a little context: I'm interning at a software company and I've been tasked to update the methodology of the intranet department. The company I'm interning at has 7 departments and combined these departments consists of about 75 employees. All of these employees use the internal system (intranet) to varying degrees. Most of the intranet department problems can be traced back to one issue; there is no clearly defined methodology and there is little to no standardization of the internal processes. This is where I come in.
My internship supervisor wants me to implement a new methodology with 'proxy' product owners. This means every department has its own 'proxy' product owner representing their department's intranet needs. When I say intranet needs I mean potential bugs or certain features that employees would like to see added to the intranet. These 7 'proxy' product owners are in turn in direct contact with the intranet product owner. The intranet product owner is of course in contact with the development team and evaluates and prioritizes the requests they're getting from the 'proxy' product owners (see picture for more clarity).
I have read almost everywhere on the internet that proxy product owners are a bad idea, but I can't seem to apply these articles to my situation because it differs too much from the examples I have read. Hence why I am asking you guys for help. What would be the potential downsides of this described methodology? And is there a better way to implement this?
Thank you very much in advance!!
My internship supervisor wants me to implement a new methodology
Have you queried whether organizational change can actually be delegated in such a way?
with 'proxy' product owners.
Are the risks of this understood by the company, bearing in mind that the genuine Product Owner will remain accountable for value and outcomes?
What you describe doesn't seem to be consistent with how I understand the "proxy Product Owner" concept.
Typically, I've heard the term "proxy Product Owner" to mean a role between the people making the decisions about the product and the team. The person who sits with the team as the "Product Owner" has no real ability to make decisions about the product and the state of the Product Backlog. They are a proxy between the team and the people making decisions.
However, you describe the "intranet Product Owner" as a person who can make decisions about the product and the Product Backlog. The people you call "proxy Product Owners" are representatives of the key stakeholder groups. I see it as fully within the right of a stakeholder group to nominate someone to represent the whole group to the Product Owner to streamline conversations. As an example - would you want the Product Owner to get a meeting with the whole HR or Sales departments to get information or just contact one person to get the department's feedback?
If you rename "intranet Product Owner" to "Product Owner" and these "proxy Product Owners" to "key stakeholder representatives", it should be more straightforward to apply Scrum. There's only the question as if Scrum is appropriate for your context, but there's insufficient information to make that assessment.
I second Thomas.
My understanding of proxy product owners is different to what you, Simon, describe. Maybe you can ask your manager if he really understands what a proxy owner is? I'm kidding don't ask he's not gonna be happy :P
If the "proxy" product owners don't touch the Intranet Product Backlog, and don't interact with the Intranet Developers, then they are not "proxy" product owners, they are stakeholders.