Should the product owner ideally be as part of the product management team? How does one handle the internal stakeholding if the product owner is outside the product management team?

We had problems since the product owner was not part of the product management team and there were lot of conflicts.


Ideally you want the product owner to be the person who signs off on the final product. They should be either the client you're selling the product to, or, if that's not possible, the final person who is selling the product to the customer. The idea is that this person knows what the final product should be and can guide it's development from afar by ranking user stories and providing feedback at the end of sprints.

Of course, sometimes you can't/don't want to give the customer the ability to see what you're making as you're making it, so you'll have to find a product owner that fits your team's needs. I've worked in both situations and honestly, having someone who knows how to rank features and be a good product owner is often more helpful than having the customer do it, as the customer tends to make everything super high priority, and doesn't understand how software development works well enough to know time estimation.

|improve this answer|||||
  • Could agree more violently with your final sentence. "The customer knows what they want" is arrant tripe. They know things they want, sure. But an effective process requires modulating desires with what's possible, with what resources, in what timeframe. For those that care about success or economic reward, it also requires someone who can gauge what investments and added capabilities will spur increased customer satisfaction, adoption, spending, etc. – Jonathan Eunice Jul 16 '14 at 16:02
  • I thought the product owner as you describe can't possibly be replaced by customers or anyone not having enough technical knowledge. For example: if the product owner doesn't know any the high level technical aspect, he might put feature A in later sprint even when we need feature A before you can have a feature say B in the early sprint. This is not going to work at all from what I can see. – InformedA Jul 16 '14 at 16:04
  • I would say that if you've got feature dependencies that are unclear, you should clarify them. "We can't sort online contacts because contacts aren't developed yet" seems straight forward enough. Again, this is assuming that the product owner has minimal development knowledge. At that point you need to make sure that your user stories are very high level and possibly even have multiple, more-technical stories underneath. – Ampt Jul 16 '14 at 16:06
  • @Ampt Of course features have dependency. If the project is from scratch, this is even more pronounced. All the chatting here is getting weirder and weirder... – InformedA Jul 16 '14 at 16:11
  • Join us in the whiteboard and we can chat it out :) – Ampt Jul 16 '14 at 16:15

Agile is more of a brand then a methodology, which type do you mean in particular?

In scrum for example, yes, it would be common to map a previous project manager to a product owner. Although much of the responsibility of the project managing would fall to the scrum master and the team, the skill set required to be a PO (communicating the customers needs, managing customer expectations, directing team efforts towards business value and being the guy who's accountable) are close to those of a PM. However, it is also possible to have a more technical PO or one that more directly represents the customer.

Here's the thing though. The fact you have product management team to conflict suggests that that text above isn't really relevant, because you may be doing cargo cult agile, with the PM and the PO replicating each others work. Do you still have a traditional project manager for example?

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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