Scope: Product, Feature, or Component Owner?
To get the product owner responsibilities right, start by asking what the individual owns. Is it a product, a feature, or a component? While this may sound like a trivial question, it can be tricky to answer it: I have seen a number of companies where people did not have a shared understanding of what a product is. As a consequence, there was no clear and common definition of product roles and responsibilities, and people looking after components or features were confusingly called product owners.
What’s a product? It’s something that creates value for the customers and users as well as for the company. It addresses a problem or provides a tangible benefit—think of a product like Google Search that solves the problem of fining information on the Internet or Facebook that offers the benefit of staying in touch with family and friends. Some digital products directly generate revenue, such as, Microsoft Office or Adobe Illustrator. Others, like Amazon Kindle, help sell other products and services—Kindle Paperwhite devices and Kindle books, for example.
A feature is product capability users can interact with, for example, search and navigation and checkout on an e-commerce website like Amazon. Every product contains one or more features in order to create value for the customers and users. A component is an architectural element or building block. It includes not only component in the narrow sense (like an Enterprise Java Bean, for instance) but also (micro) services and layers, for instance, a data access layer. The following picture summarised the differences between the three terms.
Many product owners I have met weren’t product owners but feature owners or component owners. While there is nothing wrong with being a feature or component owner, the responsibilities significantly differ from a product owner.
A product owner owns the entire product. Consequently, the individual should focus on making and keeping the product a success—by ensuring that it offers a strong value proposition to the customers and users and that it creates the desired business benefits.
A feature owner, in contrast, is focused on one or more individual features. The individual’s responsibility is to ensure that the features performs well, for example, that the drop-off number of the checkout feature is low. Similarly, a component owner looks after one or more component, such as, the user interface or data access layer. The person makes sure that the architectural element works as expected. To do so, the individual usually has to have the appropriate technical skills. The picture below illustrates the three different owner roles.
Using feature and component owners is a scaling technique: It can help you grow your product by dividing the product responsibilities. A common approach is to have one overall product owner who manages the entire product and several feature and component owners who look after its parts.
Depth: Strategic or Tactical Product Owner?
Say you are a product owner in the sense discussed above. Then that’ great. But to which extend to you own the product? Are you responsible for the tactical and strategic decisions, or do you focus on the tactics? Strategic responsibilities include deciding on the product strategy, developing the product roadmap, and managing the stakeholders; examples of tactical duties are managing the product backlog, writing user stories, and working with the development team
Individuals who own the strategic and the tactical decisions are referred to as “big” product owners. Product owners who focus on the tactics are called “small” product owners. Depending on the ownership depth, small and big product owners have different responsibilities, as the diagrams below show.
Some people view a small product owner as a partial product owner—something I have suggested in the past too. Unfortunately, the definition of the role in Scrum—the framework that gave birth to it—is not clear. While the Scrum Guide states maximising value of the product as a responsibility, it only lists tactical tactical duties like managing the product backlog and working with the development team.
I find it not uncommon that small, tactical product owners work with a product manager or chief product owner who owns the strategic product decisions. This setup is usually chosen help grow the product—it’s another scaling technique. It tends to work well when the product is growing steadily or when it has become mature. It is less suited for young products, which require a closer alignment of strategic and tactical decisions.
[This post was first published on Jul 25, 2013. It has been updated and rewritten this then.]