Internal or external Product Owner?
Most of the information available on blogs, podcasts, and books on Product Management and Product Ownership focuses on commercial products aimed at end-users, such as the cases of Airbnb, Uber, Rappi, Mercado Libre, etc.
At the same time, in the past 8 years I certified more than 1200 Scrum Product Owners, I came across a vast number of professionals dedicated to managing internal products like billing systems, accounting, purchasing, dispatches, to name a few. These practitioners have never interacted with a final consumer to do their work.
Between the two worlds, internal and external POs, there are big opposites and much similarities that I propose to inspect right away so that you take them into account when considering the range of options for your professional path or that of someone else you could help.
The two sides (of the same coin)
No matter where your product is pointing, there are certain common aspects for those individuals who serve within the organization and those working at the same entity but facing the market.
Believe it or not, many Product Owners of internal products assume that holding a vision is exclusive to those who work on products marketed outside the company. And it's far from being the case.
Remember that the product vision describes the product's future state and the problems it is trying to solve or the ambitions it aims to achieve.
Having a clear and inspiring vision of the product will help you motivate and spark enthusiasm in the community surrounding the product construction, being they developers, stakeholders, customers and / or users.
Don't undervalue the power of a vision just because the work outcomes are primarily interior-oriented. Besides, you must use this vision to communicate the direction in which you want to move the product and to make decisions about what to build and what to avoid building.
Another similarity is having a strategy that connects your product goals with the vision.
A product strategy is a high-level plan that describes what a company hopes to achieve with its product and how it plans to make it happen. This strategy must respond to who the product will serve, how it will benefit those people, and what the objectives are.
The strategy is key so that the entire product team can connect their work with the desired benefit.
In both internal and external worlds, you must ensure that the Product Backlog is sorted by value. That is, place first the feature that holds the most value, regardless of the measure applied to establish that something brings value.
We will see that defining what adds value is usually not alike between these two perspectives. It is a common mistake to think that prioritization is determined by it.
Another frequent mistake when handling internal products is to believe that everything is much clearer than when the product is assigned to the market. When this belief prevails, the product development will aim at fulfilling requests and tasks, without focusing on results generation. In this way, a new control system over timing, budgeting, and the estimated scope will emerge, at the expense of slowing down the workflow of employees.
That is why I underscore the importance of outcomes orientation even when building a product towards the interior of the company in order to avoid falling into a false definition of "result achieved" when asking: "What is the desired result: to solve a need or comply with what was planned?"
Let's now look at the main contrasts I perceive.
Operational outcomes vs. market outcomes
The main difference between an internal and external Product Owner is that the intended results are typically more tied to operational aspects in the former case, and to the market in the latter.
While external Product Owners focus on lead generation, conversion, subscriptions, registrations, etc., Internal Product Owners are more attentive to cycle times, ticket cost, first response time, average resolution time, and inventory turns, to name some examples.
Cost effect vs. income effect
Next to the outcomes is the impact each one has. It is to be expected that end-user products pursue to increase the company's income, right?
In contrast, the impact of internal products generally purposes to reduce costs, time or the likelihood of human errors.
Systems/applications vs products
The third and final usual difference is that internal product owners may find it strange to understand their solutions as "products." Most of the ones I've known call them "systems" or "applications", for example, "the billing system" or "the order loading application".
It is important to highlight this point since the way we speak is a reflection of our thoughts and creates our realities. If you are an internal PO, you will resonate more vivaciously if you start to consider these applications or systems as "products" in themselves.
I hope that this preliminary list of similarities and differences comes in handy to reflect on which profiles are more related to an internal or external PO. Please, share this article if you think someone needs to read it, and let me know if you consider I missed something important. :-)