Depending on your environment, you may have worked with a Product Owner who functioned as an “Agile Project Manager” or Business Analyst. They “led” the project, captured requirements, wrote user stories, and managed the backlog. For others, the Product Owners were business stakeholders, likely the main end-user or subject matter expert, often working in tandem with the development team to help translate business requirements and perform user acceptance testing. Throughout our Agile consulting efforts, we’ve commonly seen how choosing the wrong Product Owner can slow down and even derail an otherwise promising effort. Regardless of function, a Product Owner’s approach or interpersonal interactions may have caused you frustration or seemingly led a project astray. During a retrospective you might have even discussed the negative behaviors or actions of a “bad” Product Owner, but have you ever thought about the distinguishing factors that make a “great” one?
Product Owners have the difficult job of understanding the business need, translating it to useful requirements for prioritization, and managing the business’ expectations of the team’s performance toward achieving that business goal. That job can be further complicated when the Product Owner is not a clearly defined role within an organization, lacks autonomy, or is managing requirements for multiple business groups.
In our experience, below are some of the key traits and behaviors of a successful Product Owner:
Ensure the team gets the vision. If the team does not understand the business goal they are working toward, it is hard to have an informed conversation about how to properly prioritize the work and/or make better solution recommendations. This becomes essential when serving multiple business groups. As a Product Owner, you have a responsibility to help the team understand the “big picture” and connect their work to the business need.
Build trust with your team. While you may not work with a consistent set of team members, your behavior in building trust with your team can be. Establish a reliable means of communication; be available to answer lingering questions through daily check-ins or schedule specific meeting times. If team members are virtual, be sure to set aside time to connect with them as well. When working with distributed teams, we recommend logging in to your virtual meeting space about ten minutes prior so that virtual team members have an opportunity to chat; they can also address questions and feel more connected to the team.
Manage stakeholder requirements. Don’t just collect requirements, ask questions that will help you write strong, testable user stories. Clarify, clarify, and clarify again with business users and don’t make assumptions! Just because a story is clearly written to YOU does not mean it will be clear to your team. User stories should be a conversation with your team. As you engage both the business users and the team throughout the project, it builds trust across the board. A clearer understanding of requirements also leads to more informed estimation and prioritization. Further, it ensures faster, better delivery of
requirements that truly convey and meet the business need.
Most importantly, support the team in finding the best approach to achieve the goal. One of the best experiences I’ve ever had was attending Kanban Practitioner training with my entire team (a combination of developers, a systems analyst, and a tester). The training helped us to better understand one another’s roles and how our actions, work, and even delays impacted each other. Prior to the training, the team had an imposed work in progress (WIP) limit of six cards for in-queue items. After the training, the team decided to reduce the in-queue WIP limit to three cards
and only bring in the amount of work they felt they could accomplish to meet their Definition of Done.
While this was an adjustment for the environment outside the team, this improvement allowed
them to better achieve their sprint goals. This change helped the team to focus more on the work
(as opposed to a quota), lessened the burden on the tester, resulted in less errors, and increased morale.
Remember, product ownership is hard work! There is no prescribed approach, however, adopting these habits can aid in fostering a strong and effective relationship with team members. Ensuring your team understands the vision helps them better understand the business value of their work and the connection to the strategic business goals. Treating your team as “customers” through consistent communication establishes trust, while making requirements a conversation expresses the value you have for their expertise. Managing stakeholder requirements is more than just collecting requirements, it is building a partnership with the business and your team to provide great solutions. In addition, it is supporting the team in finding their best approach to accomplishing their sprint goals that helps to build a strong, self-organizing team.
Developing these traits is achievable and can be scaled at the project or enterprise level. Contact us or check out EK’s agile coaching and facilitation approaches to learn more about how you can provide a solid training ground for a Product Owner to develop great habits and skills.