In my experience, Scrum works best when the Product Owner is someone from business rather than IT. This is because, when I think about the role of the Product Owner, I envision an inspiring business leader with the responsibility to maximize the business outcomes of each Sprint. I see a person who spends much of their time speaking with customers and end users to discover their important jobs, the extreme pains they are looking to avoid, and the essential gains they are seeking.
Additionally, Product Owners are passionate about delivering maximum value while making a greater and greater business impact with their products and services. As experts in their domain, they are thoroughly aware of the market, key competitors and the important business and technology trends in the business. As business leaders, they are empowered to make the key economic decisions and product trade-offs which affect the business’s growth, profitability and competitive advantage.
After reading my high-level description of the Product Owner role, many people might conclude, “Okay, but nothing in your explanation prevents someone from IT from taking on this role.” And that would be true when we consider the senior IT leaders in most organizations – a CTO (or CIO), a VP of Technology, or a high-ranking director – could be excellent Product Owners since they have the necessary business acumen and commercial perspective to make the economic choices required to be an effective Product Owner.
Yet, I would still not want them to be a Product Owner (unless I had a REALLY good reason). Why? For me, one of the important distinctions that I have carried with me for the last sixteen years of being part of the Agile community is this maxim from Extreme Programming:
Business people make business decisions and
technical people make technical decisions.
As the business and domain experts (and the people most likely paying for the product), it is important to give the business people the control over the product’s vision, features and prioritization. In Scrum, that means they get to occupy the power position – the role of the Product Owner.
Almost every time I have seen IT take on the role of the Product Owner, the business stakeholders end up extremely dissatisfied with the outcome and their relationship with the Team. The stakeholders end up unhappy with the finished product because it does not take into account their feedback or the feedback of their end users. The stakeholders are dissatisfied with how the features were prioritized and/or the frequency of the releases and updates. They are also displeased that their needs were not consulted when the inevitable technical trade-offs were made without their consultation or were taken into consideration too late to influence the final outcome.
In this regard, here is an excellent, pragmatic article from product manager João Craveiro (@jpgcc_) that talks about the important factors to consider when asking this question, “Should the Product Owner live on the client side or the vendor side?”
Want to learn more?
For more about what it takes to be an effective Product Owner, check out my ongoing series on Product Playbooks:
Part One – Product Playbook: Why You Need One
Part Two – How to Build a Product Roadmap
Part Three – How to Build a Customer Journey Map