7 Habits of Highly Effective Product Owners

Share on FacebookTweet about this on TwitterShare on LinkedIn

Share on FacebookTweet about this on TwitterShare on LinkedIn



When it comes to Agile Development, the Product Owner is generally regarded as the single most important role on the project. It is the Product Owner who ultimately makes decisions about what features will be included in the system, what order they will be worked on, and when they will be accepted as Done. Agile projects without an effective Product Owner are doomed to fail.

For product-based organizations or on internal projects, having a Product Owner who is an integral part of the project team is fairly standard. For service-based organizations like Segue, where most of the work we do is based on a contract with a customer, it is often that customer who must serve as the Product Owner. Cultivating these seven habits should help any Product Owner, whether an integral part of the team or an external Customer, be effective and help the project succeed.

1. Be Involved 

This is the single most important habit of an effective Product Owner. The Product Owner must be involved in the project, from outset to completion (and often beyond). The PO should understand the full scope of system features, should be aware of which features are being developed now and which are down the road, and should actively monitor the daily builds and demos to ensure that user stories are implemented the way the Product Owner intended. Regular and continuous involvement in the project helps ensure that the project team is always working towards delivering business value.

2. Be Knowledgeable

The Product Owner must be knowledgeable about the subject matter involved in the system being developed. The project team will often look to the Product Owner for explanations about the customer’s business practices, as well as any business rules or customer industry practices which may apply. If the Product Owner is not a Subject Matter Expert (SME), he or she should be able to reach out to other resources to get the necessary information in a timely manner.

3. Make Decisions

Ultimately, it is the Product Owner who will be responsible for communicating to the project team any decisions that need to be made by the customer – in particular, about prioritization of work, business process, UI design, and other non-technical matters. While the Product Owner may not always be empowered to make those decisions, he or she must be able to reach back to whoever in the customer’s organization has that authority, and is responsible for ensuring that decisions get made and get communicated to the project team.

4. Be Responsive

Timely responses to questions, requests for information, acceptance of user story details, and acceptance testing of feature implementations are necessary to ensure the project is completed on time and within budget. Agile teams try to stay fully engaged at all times, so any delay in responding can result in work being done incorrectly, or in extreme cases, can result in the project stalling. A stalled project is more expensive, because the project team still needs to get paid even though they are not able to do any work. In one extreme example, our project team completed work on a project and was disbanded so they could work on other projects, only to find out that the customer had an issue with Feature X which had been implemented over a month prior. In that month, we had implemented other features which depended on Feature X, all of which had to be redone. Pulling the project team back together negatively impacted other projects, caused stress, and increased the cost for the customer as we had to extend the project duration to account for the rework. A timely review of the user stories and implementation could have prevented all of that.

5. Be Willing to Learn Something New

In addition to being knowledgeable about a new system, the Product Owner will be asked to fully participate as an integral part of the software development project. This means a willingness to learn new methods and techniques is required. You might be asked to use a specific requirements tool or work management system that the project team will be using; or work in a way you’re not used to working in. You may also learn more about your business processes as you turn a watchful eye on them to make sure the system you’re helping to develop meets your needs.

6. Ask Questions

The project team will be listening to you as they try to understand the requirements for an application. Please listen to the team when they propose alternate ways to implement what you’re asking for; identify technical, schedule, or cost challenges of a particular approach or requirement; or suggest additional features you might not have previously considered. The members of the project team aren’t always going to be subject matter experts in your business area, but they are software development experts and can give a fresh perspective on your processes.

7. Don’t Assume

One of the biggest risks to any project is assumptions. We all make them, even if we don’t realize it. Don’t assume the project team knows something about your business that you haven’t told them. Don’t assume that certain features will be included because “everyone does it that way” (rarely, if ever, does ‘everyone’ really do it that way!) If you want the system to have a particular feature, be certain to ask for it; if there is a business constraint, tell the team; and if you don’t see something you want written down in the user stories, bring it up again so the team can make sure to include it if appropriate.

Bonus Habit: Be Understanding

Sometimes there will be factors which limit the team’s ability to deliver exactly your vision of what you want the system to be. These factors could include cost, schedule impact, technical constraints, legal or industry standards, user interface design principles, or others. A customer once asked us to allow users to upload any number of files, of any type and in any file format, and then have the system automatically merge those files into a single PDF – all within seconds. Implementing this feature would require us to purchase several very expensive third party modules (which were outside of the customer’s budget), spend weeks integrating them, and still would only support the most common file formats. Additionally, in order to meet the response time requirement, the hosting environment would have needed to be scaled up to a size that would cost the customer significantly more than they had budgeted for operational expenses. Even though the customer identified this as a “critical” need, there was simply no way we could deliver that functionality within the scope of the project. After explaining the issue to the Product Owner, he was able to convince his superiors in the customer organization that the feature should be shelved until a later date.

By following these habits, you will be a more effective Product Owner, and the project team will be better enabled to deliver the software you want, on schedule and within the agreed-upon budget.

Download our Agile eBook