Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I just had a discussion with a colleague about the Product Owner role: In a project where a customer organization has brought in a sofware developing organization (supplier), can the role of Product Owner be successfully held by the customer organization, or should it always be held by the supplier?

I always imagined, that the PO was the supplier organizations guy. The guy that ensured that the customer is happy, and continously fed with new and high-businessvalue functionality, but still an integral part of the developer organization. However, maybe I have viewed the PO role too much like the waterfall project manager.

My colleague made me think: If the customer organization is mature and proffessional enough, why not let a person from their camp prioritize the backlog?? That would put the PO role much closer to the business, thus being (in theory) better to assess the business value of backlog items. To me, that is an intriguing thought. But what are the implication of such a setup???

I look forward to your input.

share|improve this question
    
I've recently blogged about the user or customer vs. a product or project manager playing the product owner role. In a nutshell, I recommend that the customer should play the role whenever a bespoke product is developed. –  user41767 Nov 29 '11 at 16:09

4 Answers 4

up vote 3 down vote accepted

What has @Thomas Owens described is common explanation of PO. I agree with it as a nice theory but practice is in my experience often far away. Why? Because:

  • Willing participant - at least for duration of the project PO is fulltime job. This can be serious problem for most customers. When working with 5-7 member team, PO can easily spend half a day by discussing user stories currently developed by the team (remember user story is only promise of future communication) and half a day by maintaining and refining product backlog to define user stories for upcoming sprints. IMHO PO should also verify completed user stories during the sprint as the necessary step to make them "done" and ready for review meeting where these completed features will be presented to customer and stakeholders (not to PO!).
  • Moreover PO can be considered as a real job position (in the same way as Scrum Master is). In such case you cannot expect to get good skilled PO at 99% of customers.
  • Financial responsibility - PO has financial responsibility for the project. Even in Scrum somebody has the responsibility and because there is usually no product manager or project manager the responsiblity usually is on PO. Financial responsibility means responsibility for success of the project, for correct implementation and understanding of customer needs, expectations and requirements. This can look like ideal situation for PO on customer side but delivery organization needs somebody involved in the project with financial responsiblity as well.

Scrum is not a standardized approach - it is just a blueprint with many variants. Because of that you can find projects where PO is from customer side or where PO is from delivery organization. Once you have PO from customer side make sure that he really does his job. I have seen the situations where official PO was from customer side but at the end it was only empty title to satisfy management expectation from delivery organization and most of his job was performed by some team member who secretly played his proxy. That was obviously bad because the result of the sprint was often dependent on proxy's understanding to customers business needs!

From my experience with customers (this can be only local) once any customer really demands to have his own PO it also means they are going to lead the project themselves - they don't look for delivery organization to lead the project. They look for organization which can sell them developers = not delivering implementation but a workforce.

share|improve this answer

I would recommend, whenever possible, having the Product Owner be a representative of the customer. The role of the PO is to be the voice of the customer, to ensure that what the team is producing adds business value, and write and prioritize user stories. Who better to perform these roles than a willing participant from the customer's organization? The key words are willing participant - they need to be willing and able to participate in the Scrum environment if that is the process methodology used by the team.

This isn't unique to Scrum, either. The concept of a customer representative (with an on-site representative often favored) is part of Extreme Programming, as well.

share|improve this answer
    
Thanks, I guess i WAS seeing the PO as a project manager!! –  Morten Nov 22 '11 at 15:52
2  
No, the PO is not a project manager. There really isn't a single equivalent to PM in Scrum. The PO is responsible for developing and prioritizing requirements. The ScrumMaster is responsible for process and removing roadblocks. The team as a whole handles estimation and scheduling. The duties of a typical PM are split up across multiple people. –  Thomas Owens Nov 22 '11 at 15:54

Good product owner needs to answer few fundamental questions:

  1. Will I be available for team enough for planning and review?
  2. Will I be able to constantly work on next release & sprints preparation?
  3. Will I be able to approve implemented functionality fast enough? In ideal case it means immediately is functionality completed.

In my experience it is better to have product owner who is YOUR team member.

  • You need someone who understand what developers say, but also what customer needs.
  • product owner should works with your accounting, sale etc.
  • developers must see & feel that product owner is on 'the same boat'
  • sometimes you will have to say NO to customer to open his mind.
share|improve this answer

Some things to consider about allowing the customer to be the PO:

  1. If they are not full committed you can find the whole development process screached to a halt. The vast majority of customers don't want this kind of involvement, some think they do, but when it comes down to it, most actually don't want that committment.

  2. You take a process that is in your control and give that control to the customer. It has been my experience that not being in 100% control of a project for a client is more dangerous than the risk of not delivering exactly what they are asking for. OTOH if a missed requirement occurs the blame lies entirely on the customer for missing this requirement, they can't fault you for that.

  3. If you are developing a product that you or your organization has no interest or rights to turn around and use or sell to other customers then this can work. Otherwise if you are developing a product for your company that you may want to customize and tailor to other customers in the future then you could be creating a catastrophe for yourself in the future. The PO in this case should be somebody within YOUR company because you are developing a product that is intended to be reused for multiple customers.

share|improve this answer
    
I'm not sold on #2. The process is run by the ScrumMaster, who should always be part of the developing organization. People not following procedures, identifying potential problems, and removing road blocks all fall on the SM. However, if the PO is a customer and the PO is causing difficulties, dealing with it requires more tact than it would if it was a member of the developing organization. –  Thomas Owens Nov 22 '11 at 16:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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