At some point, organizations that want to scale to more agile development programs or take on wider scoped digital transformation efforts need to consider how best to cultivate Product Owners.

Scaling additional development teams is a lot easier. Once an organization has a defined agile practice, a defined set of technology platforms, and a documented development standard then scaling development requires finding additional technologists, reshuffling teams so that new ones have a mix of both new and tested team members, and identifying aspects of the practice that need to scale.

But adding product owners isn’t as easy. Organizations have a choice of looking outside for people that have the skill set and experience but need to learn the business, customers, and product landscape, or, identifying existing employees that know the business but need to learn the art and skill of product ownership. The latter option is far harder to do than leaders understand especially those that equate product ownership with project management.

What New Agile Product Owners Need To Learn

Product ownership is a blend of several disciplines and skills, but what I focus on below are the key changes when product owners are groomed from within the organization.

• • Listening to customer and stakeholder feedback but owning decisions – Early product owners fall into a couple of traps.The first trap is when they do a good job of listening to customers and stakeholders, but then try to give everyone what they want. Product Owners in this camp fail to recognize that they are working with finite budget, time, and skill and their role is to digest the input then communicate a set of priorities, strategies and requirements. These product owners need to communicate the rationale behind these decisions and accept the fact that they aren’t going to make every one of their stakeholders equally happy.Their job isn’t to make people happy but to make decisions that drive customer adoption and growth.

    The second trap is when the product owners fall in love with their vision to the extent that they fail to listen to stakeholders including the technologists that they need to partner with on solutions. Product owners need to constantly reshape their vision and priorities based on feedback and those that don’t listen may fail to adopt. Second, product owners need to share and communicate their vision repetitively and gain buy in over time, otherwise, stakeholders will communicate their objectives, often loudly and forcibly and probably late in the development process when changes or pivots are more costly. Lastly, product owners need to shape their vision based at least partially based on the organization’s capabilities so they need to be presenting problems to their team and learning from their team feasible solutions.

• • Participating in Team Commitment is Key to Agile Success – New agile product owners often fail to fully understand the importance of getting a team’s commitment and learning to manage to their velocity. Even when teams estimate and forecast a schedule, getting the team to formally commit insures that they have a shared understanding of the prioritized stories and have a plan to address them in the allotted time. Without commitment, new product owners may find their teams falling behind schedule, completing stories with quality issues, introducing unnecessary technical debt, or unhappy – all issues if the organization is going to maintain a culture and practice of excellence.

• • Adopting the Team’s Agile Tools and Practices – Because many organization equated product ownership with project management, they tend to promote individuals with management skills into this role. Many will make the mistake of trying to manage the team through tools that have worked for them in the past and try to force agile project schedules into other tools like MS Project, spreadsheets, PowerPoints, etc. It’s a huge waste of effort duplicating this information, it leads to inaccuracies, and it will likely frustrate the team when their product owner isn’t collaborating with them with tools and practices selected. Product owners need to start their role by learning and using the selected practices and tools. If anything, they should drive the team to adopt my recommended best practices in configuring agile tools.

• • Driving Data Driven Decisions – The best way agile product owners can get both stakeholders and agile team members on board with their priorities is to demonstrate that there is data backing their decisions. “What does the data tell you?” is the first question I ask product owners when reviewing their vision or priorities. If the answer is that we have limited data, then my follow up is, “Where in your backlog have you prioritized data collection priorities?”

• Leveraging Estimations To Shape Vision, Priorities, and Solutions – Understanding that estimation is not a contract. I have written several posts on agile estimation as a key tool to form a dialogue around solutions, to drive a discussion on MVP, and to help teams plan releases. Agile product owners have to use estimation as feedback to make decision, but some fall into the trap of using estimates to manage their teams to fixed timeline, fixed scope releases. Sometimes it works, but when estimates are done early in the process or performed by less mature teams they will have degrees of inaccuracies. Agile product owners that “box in” their teams to fixed schedules and deliverables will lose their ability to adjust priorities or worse, they may degrade the culture that drives both execution and innovation.

Lastly, what steps are they taking on to learn their craft? I encourage agile product owners to adopt some self reflection. Are they adopting any of the 20 bad behaviors of agile product owners? Are they listening to their team’s and prioritizing some work to address technical debt?

Better yet, are they learning some of the practices of strong agile product owners?