In Part 1 and 2 of this blog series, we looked at the benefits and pitfalls of filling the Product Owner role with either a business analyst or product manager.  In the final installment of this blog, we’ll look at one more potential role transition: project manager to product owner.

This role transition is one in which I have personal experience.  Years ago, when I first learned Scrum, this is exactly what I did.  I had been a project manager, overseeing the projects of my client.  When we moved to Scrum, I became the product owner and my clients were my stakeholders.

For many former project managers, the transition to product owner will be quite comfortable.  The Product Owner role is highly focused on delivering business value and he/she spends a good deal of time refining the user stories and product backlog to make that happen.  Project managers do that, as well.  Good product owners also know they must do “expectation management” with stakeholders to help them understand the inevitable trade-offs that must be made throughout the life of a product.  These kinds of conversations are a daily occurrence in the lives of most project managers.       

Finally, a competent product owner needs to have a certain mental toughness.  When stakeholders don’t get everything they want, some will inevitably lash out.  They may try to browbeat the Product Owner into delivering their user stories.  They may try to go around the Product Owner to upper management, threatening to “escalate the issue” every time they don’t get their way.  Or, they may go directly the development team itself and ask them to do their side projects “just this once.”  Good product owners must be fairly comfortable dealing with and being in the middle of conflict.

Again, our former project managers can help us out.  Dealing with conflict is something with which they have ample experience.  A good project manager hasstrong “emotional body armor”.   They don’t easily get their feelings hurt and cannot be intimidated by idle threats.  They keep their eyes firmly on the prize – delivering the most business value possible from the project with the time and money they’ve been given to spend.  Such individuals often make excellent product owners.

Does the project-manager-to-product-owner transition ever go amiss?  Yes.  Some project managers are taught that it is their job to drive the team to perform, overseeing their progress and directing their day-to-day work.  When stepping into the Product Owner role, these outdated ideas have to go.  Instead, product owners must partner with the team, clearly defining the “what” (“What are the requirements?  What is the priority?” so the team can create the “how” (“How, technically, will we fulfill those requirements?”)  The relationship between product owner and development team is a true partnership, not one of superior and subordinate.

What I hope you see from this blog series is that choosing the right product owner is a matter of looking at the individual, not the job title.  Good product owners can come from the most unlikely places.  One of the best product owners I ever worked with was a senior database analyst.  Others in the organization expressed doubt that someone so technical could understand customer needs.  But he actually performed very well in the role and, as an added bonus, being a meticulous and highly detailed person, always had a well-groomed product backlog with clearly written user stories.  Choosing your product owners on an individual basis, based on their abilities rather than their job title, will ensure you get the right people in the role.

In our next blog series, we’ll look at who succeeds—and who does not—in the ScrumMaster role.