Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
We're a governmental organization and we're contracting with software companies to implement our projects. We're adapting the Scrum framework.
Question: Should the Product Owner be from our organization or the company we are contracting with? What is the best practice? and why?
There is no canonical answer to this question, although as a rule of thumb, it would be better for the PO to be from the client side, not the contractor side.
The Scrum Guide says this about the PO role:
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
A PO on the customer side has more chances of fulfilling these attributes. I'm not saying a PO on the contracting side can't do that, but there might be some issues:
Of course, there are also disadvantages to having the PO from your organization:
There are pros and cons to both options, but both can work if you have the right people and the proper level of engagement. Ultimately:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
... so think about the chances for this to happen if the PO is on one side or the other of the work being done, then go for the option which maximizes the value of the product. If you can have your PO at their location, inside their team, I think that would be the best combination.
And I'm going to take the middle ground between Bogdan and Thomas...
Bogdan already listed the responsibilities of a PO. To (over)simplify it in a single sentence, however, it would be:
The purpose of the PO is to act as a link between the customers and the Development Team.
As such, the PO is really the only role that can feasibly come from either side. Because s/he serves as the link between the two, s/he needs to be able to interact with both.
That, therefore, would be my largest concern - which is going to be easier - our PO interacting with their customers? Or their PO interacting with us? Most likely, it will come down to the communication skills and availability of the POs in question.
I'm going to disagree totally with Bogdan's answer. I believe that, in most cases, it's better for the developing organization to supply the Product Owner. There may be cases where it does work out, but I'm hesitant.
The first thing to consider is why you are contracting with a software company instead of building the software yourself, internally. It's most likely because your organization doesn't have deep expertise in software development, but the firms that you have contracts with have that expertise. The expertise would include product management, project management, and requirements engineering in addition to the design, build, and test aspects.
Generally, I'm concerned when customers dictate the development process. This is partially for the same reason as above - the customer is contracting out the work because they do not have the resources (usually staffing or knowledge) to do it on their own. The development organization should bid on the contract based on their ways of working and then execute on that way of working. It is helpful when the customer is willing to commit to Agile Software Development since frequent involvement can help to get to the right thing faster through rapid feedback loops.
The Product Owner role is also a full-time job of working with the development team. By taking on the Product Owner role, you are committing to working your entire time to supporting the development teams creating that product. You are looking at involvement in backlog refinement, Sprint Reviews, and Sprint Retrospectives - this could easily be (4 hours * weeks in Sprint) + 4 hours + 3 hours per Sprint, give or take. Your responsibilities to this team would come before other obligations, otherwise, you are a bottleneck to the team achieving their goals.
I'd also point out that the Product Owner coming from the customer will likely lead to a bespoke software product. There may be cases where this is appropriate, but there may be cases where you exclude potential contractors if the structure or contract prohibits building something that could be leveraged as a platform for future work.
Generally, the best thing to do is to have a Product Owner that is from the same organization as the development teams creating the product and is fully dedicated to them. Anything else runs the risk of slowing the team down. It may be necessary for a Product Owner to ramp up, but the long-term benefits of close alignment between the Product Owner and development team outweigh the necessary ramp-up time.
Client side. The PO needs to be able to identify the business priorities, provide subject-matter expertise and justify his or her decisions to the client organisation. Most software probably requires organisational or procedural changes at the client so it's also an advantage if the PO is in a position to make such changes happen. Finally, it's to both parties' advantage if the PO controls and accounts for costs - the PO makes decisions which may impact the cost of the work and if the client is paying then they will want to have control of those costs.
I am in the same situation, I am a PO on the client-side. To me, that is the only option because most times the contractors are after their selfish interest. The PO has to defend the customer and business objectives in delivering business value. The PO needs to be able to make strategic decisions in view of the overarching business strategy. The contractors are not in the position to do so but just to make money and move on.
Actually, there's another strategy: "cooperating de facto 'product owners' on both sides!"
On the customer side, this person is tasked with directly representing the business interests of the company as they relate to this software. This person can most easily put himself or herself into the "proxy position" of representing the actual system user community, while also possessing the requisite software-development know-how.
Meanwhile, on your side, you have what might be "the actual" PO, who is most aware of exactly what your teams are doing.
These two persons are tasked to be in constant and direct communication with one another in order to best fulfill the Product Owner's role in the project ... collectively!
To me, "Product Owner" is probably the single most-important role in assuring the smooth deployment and business acceptance of the project, and yet it is also the most vulnerable to being torpedoed by "assumptions" or failures of communication – especially where more than one company or business unit is involved. This is a very efficient way to avoid these snares. Plus, it helps to reinforce the idea that the client really does play an active, participative role in what they're ultimately paying for.
In the one governmental scrum project I worked in, the government agency used an external IT consultant as Product Owner.
This ensures that the product owner has no split loyalties while having the necessary expertise. On the negative side, the product owner needs significant ramp up time to understand the requirements, and the possibility of disagreement between the product owner and the users of the product is amplified due to physical and organizational distance.
I am supporting Mike's answer to utilize PO's advantages from both sides.
To be more specific, PO from your org should be the real single PO to make final decisions, maximize product value.
On the vendor side, we can have a proxy PO (or in my context can be called as Business Analyst) who works more closely with Development team to clarify requirements and prepare future stories (which will be approved by real PO).
