My company is going through an agile rollout and is currently considering options for what that means.

The ScrumMaster role is somewhat straightforward, but Product Owner has many candidates: Product Managers, UX, Software Analysts. The favored candidate for the moment is for each development manager to be the team Product Owner.

However, using development managers as product owners seems like it will discourage self-organization. What's the "right" way to select product managers in an Agile way?

  • 2
    Could you further define your organization's roles? Different organizations may have different definitions for what a product manager, UX engineer, and software analyst does. Providing definitions may allow for better understanding of the question. – Thomas Owens Oct 30 '14 at 15:35
  • I'd think a manager would be too busy with manager-y stuff to effectively focus on the product and work with the business to define features. – Andy Nov 6 '14 at 0:47

Generally speaking, the person who knows the most about the application requirements or has the responsibility for interfacing with the client is the one who should be the Product Owner.

If the development managers in your organization have the best knowledge of the product's requirements, then they ought to by the Product Owner. Developers need to be able to go to the Product Owner in order to clarify requirements and make sure that what they're developing is actually meeting the requirements.

As far as self-organization is concerned, I don't believe it should have an effect unless the developers report the development managers.

If the developers do report to the individual development managers, then the developer's performance metrics should be adjusted so they are not penalized if they work on other manager's requirements. Likewise, rules need to be put in place so a particular development manager doesn't leverage their employees to gain priority for their product development at the expense of other requirements.

You may consider enhancing the scope of the ScrumMaster in order to make sure that the development managers don't exert undue pressure on the developers in order to change previously agreed upon priorities for the user stories.


As @Contrarian mentioned, the Product Owner needs to understand the requirements and is usually involved in a business perspective with clients or Product Managers who are influencing the overall product releases. Prioritization is a key feature here as well, so this person needs to be granted the power to decide on priority of what to do.

In most situations, a Business Analyst makes the jump to a Product Owner very easily. If you currently have somebody playing this role, they make a great PO.

In some organizations, however, the requirements are actually clarified to the team by an architect who has an overall vision of the product or of a particular module/component of the product. These individuals can act as the Product Owner and can help with prioritization, though they may not necessarily be involved in the business/client-facing side traditionally.

As for using a team's direct development manager, I would caution against this. It is one thing to have a colleague informing you of priorities and representing the client's needs, and quite another to have your boss doing it.

Imagine your colleague tells you: "Jay, the buttons here aren't going to work for the client. They don't match the branding guidelines." You can have a conversation about it, go back to your work, and ship out something new for a review.

Now put your boss in that place. Suddenly it's no longer about a conversation to get to the right deliverable and is now about performance. You will avoid showing things early on to get feedback because you might look bad to your boss. You will not necessarily be honest about what you are building or how much you have left. An agile team needs to be transparent to each other so that they can react and adjust.

That being said, we have put development managers in some of our teams, just not as the Product Owner. We will have them involved as a team member who happens to also be providing technical advice or support to the Product Owner and Scrum Master. This allows their knowledge and access to other levels of the organization to be a tool that the team can use, without them being able to have complete control over all aspects of the sprint.


Look for the person on the team that is strongest in these qualities:

  1. Knows the general business (not just the customer's business)
  2. Has the relationship with the customer
  3. Good at logically breaking down customer wants into little business-value oriented stories (Pretty much the Agile BSA mentality)
  4. Has process improvement skills
  5. Has change management skills

As far as self-organization; a PO generally shouldn't have any direct reports on the delivery team as this can be a conflict in interest in terms of the team challenging the PO on requirements, priorities, etc.

A great PO will be a BSA at heart, but should always be considering the process and change management impacts that go along with delivering a technical solution. After-all, building a solution that doesn't fit within a current or future process, or that no one adopts doesn't provide much value to the customer.

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.