Much of my work on projects lately has been around coaching and mentoring product owners, both internally at ArgonDigital and at my customers. What I’ve found is that when companies make the change from traditional or “Waterfall” to more agile methodologies, they don’t always know what to do with this new role of “Product Owner.”

A lot of the times to solve this problem, companies will take one of their roles already established in the traditional framework (typically Product Managers or Business Analysts, but I’ve seen others) and “dub” them product owners. This can be very dangerous!

I say this because a Product Owner in an agile framework is so much more and different from any one role in a more traditional software methodology. Product Owners have to understand the business value of a product and be product oriented, like a Product Manager of old, but also have to understand the technology in at least enough detail to explain the nuances of the requirements/user stories to the development team, like a Business Analyst.  So, knowing that, how do you make sure that your new Product Owners are up to the challenge and how do you assess which people of your various roles will make GREAT product owners?

Well, there is no one answer to that question, but through many of my projects, I’ve seen a few common trends, which have led me to the following general process:

1. Identify the roles/people who might be a good fit for the Product Owner role. This may mean culling many of the traditional roles like Product Manager, Business Analyst and Business Systems Analyst.
2. Understand what traits/competencies you want YOUR product owners to have. The list I gave above is a very “pure” agile understanding of Product Owner where the Product Owner really does own the product from vision to delivery. Your organization may be structured a little differently and maybe you keep your Product Managers for the more market facing activities, so your competencies from a Product Owner may look a little different. Additionally, understand what level you want your product owners to be at for each of the competencies. For example, you may want your potential Product Owners to be very good at writing user stories and prioritizing based on value, but perhaps only okay at removing impediments since there will be a Scrum Master or equivalent role to help with that.
3. Assess each person for the different competencies you have identified. At ArgonDigital, we like to use a N, L, E, T system for tracking competencies (N=No knowledge/Learning, L=Learning the skill/competency, E=Executing on the skill, can do it independently, T=Training others to learn the skill), but find a system that works for you and assess each person against your list of competencies and levels.
4. Once you have done that, you have a list of people who have been assed according to the Product Owner competencies. Your best fits to be the first Product Owners are those who come closest to meeting your competency levels.
5. Usually, you won’t have any/many people meet all of the competencies/levels, so understand where each person you are making a Product Owner may need help. The good news is that since you assessed everyone, you should have a good feel both for where people need help to grow their Product Owner capabilities and those who might be able to help them.
6. Next comes the training, mentoring and coaching part of making a great Product Owner team. In order to make sure that your Product Owners can meet or exceed their competencies, they will likely need: 1.) formal training on how to be a product owner, 2.) Mentoring and coaching, either internally or externally, on how to grow their skills. I would heavily advise any organization making the move to agile to train their Product Owners and not just their Scrum Masters. Scrum Masters do act as coaches to the agile/scrum team but they do not usually have any training on how to be a Product Owner and so can’t coach to that.
7. Once you’ve trained your Product Owners, identify people to help mentor and coach them on their gaps in competencies. This can be internal pairing or resources, or external coaches.
8. Finally, hold your team accountable. If your organization is putting in this effort to identify, train, mentor and coach its Product Owners, then the chosen Product Owners should be accountable for growing themselves in this framework. Have each Product Owner commit to skills/competencies they will work on in a given time frame and if they are not showing the improvement needed, maybe you would be better off finding a new Product Owner within the company.

Now, one thing I did not mention here is what do you do with all those people you assessed that are not a good fit for the Product Owner role? Well, again, there is no one answer. You can have them fill their current role in support of the Product Owner (Business Analysts that don’t become Product Owners could still be Analysts and help write the detailed user stories/requirements, etc.). But the key is just taking one set of people and renaming them when you make the move to agile means that you’re likely going to be seeing a lot of misfit and/or turnover with this change.