Who is Leading the Product?
Product Management vs. Product Ownership
If you’re into building up or developing an organisation or you’re deep into agile coaching, sooner or later you might come around the question for a Product Manager and/or a Product Owner. Based on what you read they complement each other, belong together, or even exclude each other. With time and experience in companies of different sizes, I have come to the conclusion that there is no universal solution. We have to slice the functions according to the surrounding factors.
“Introducing Product Management means to install a discipline and to make the company product led and vision oriented. It does not mean to create some new job titles and hope that things get well.”
Functions needed
First it makes sense to look at what is needed:
- You need somebody owning the product, that is responsible for the core topics of the product.
- You need somebody taking care of what is developed together with the development team(s).
- You need somebody taking care of the marketed product and the interfaces to centralized Departments like Sales and Marketing.
- You need somebody to represent the product on C-level for strategic product decisions and when it comes to organisational development.
Job Titles
The two common names with the different side effects they have:
- The Product Manager often is not only a manager. With the actual definition of management as processing facts in differentiation to leadership, the emotional side and the caring for products and the team seams to fall short. Also this is not what most Product Managers do! They care, they are often very emotional about their product and they love what they are doing. Is management even the right word, or is it more kind of a Product Leadership? Also there often is the Head / Director of Product Management or even a CPO as kind of the Top Product Manager.
- The role of the Product Owner is mainly characterized by agile frameworks, especially Scrum. The term itself suggests the Leadership for the Product and its value proposition, not for the people developing it. So this might be a better term, but it is not accepted. By defining the role based on agile frameworks, for larger companies this means that this person is something relevant deep in the production hall. This is not what you’d expect from a person leading a product into success.
So the question is not how to name them, but how autonomous the employees act or are allowed to act and how hierarchic the company is. It is a thing of how to slice the functions, not only between different roles, but also between the roles and the rest of the organization. I tried to make recommendations based on the main factors and a fundamental product focus.
Influencing Factors and Assumptions
There are three main factors:
- Need of Scaling for a Product
- Employees and their Skills
- Actual Hierarchic Structure
Need of Scaling for a Product
The most important statement is: Do not split the roles between the Ownership-functions and the Management-Functions because of your need for scaling! There is no need to differ. If you call it a Product Manager or a Owner is secondary. To tell it with the words of Melissa Perri [1]: “ “Product Owner is a ROLE you play on a Scrum team. Product Manager is the JOB title.””. The created interface will make communication unnecessarily burdensome. Instead take care to install Product Management overall as a discipline and the whole team will help the Product Owner/Manager to lead! Why? Because he/she is not leading them but the product!
With a growing product that can’t be developed by only one team, you have to think about scaling via multiple functional areas. This makes it necessary to slice and scale also the responsibility functions for the product. To split the responsibility, try to cut the product down into functional areas (domains), that are as independent as possible.
Even then there might be no real need to install an overall responsible. If it is necessary you could adapt the LeSS-idea of a Product Owner and multiple Area Product Owners.
To give the Product Owner the legitimation to represent the product on the C-Level just add a title like Head of Product. Head of Product again means to lead the product, not the Product Management completely, wich again would indicate an hierarchic authority.
The communication and common vision is key to the success of a slicing like that. Especially as clear responsibilities are not settled well in an everchanging environment like a Start-Up or a Scale-Up. Each and every one of the (Area) POs needs a clear responsibility and there should be no overruling of the Area Product Owners by the Product Owner when it comes to decisions that have to be made for an area.
I would not recommend to do something I read in different articles: A Product Owner leading the product and multiple Product Managers that are serving as suppliers for the Owner, e.g. for requirements engineering. This is just another way of scaling hierarchically with swapped job titles!!! The only case in which I can see something positive in this approach is when an associate is to be introduced to the position and has the clear perspective of taking full responsibility for an area in the foreseeable future.
This scenario suits well for Product-Focused companies that have a single product (or product family) at their core.
Employees and their skills
My conclusions are stereotypical. Of course you always have to take an eye on the employees you have, their skills and a realistic hiring policy based on the actual job market. Your employees will be massively influenced by the actual structure of your company. So keep that in mind reading the following chapter.
Actual Hierarchic Structure
The central assumption ist that with more hierarchic layers there comes a need for the differentiation of the functions of Product Management. This itself might not be surprising! But if your target is an agile approach in the VUCA-world the conclusion can not be to build the Product Management structure up in the same hierarchic manner, but to slice the functions where the interfaces in between are as small as possible!
The question is: Is your organisation that big, that you need to manage further parts of the discipline in person, because the silos lead to a too little product focus overall? A Product Owner that has to focus for a good part in delivering value, will not be able to serve all the interfaces and to handle the politics needed in such a big, traditional structure and also represent the product on C-Level. In this case it might be better to shift the interfaces to coordinate requirements and demands via an internal interface between the Product Manager and the Product Owner.
With an well established Product Management discipline there could be no need to do so! It ist a compromise!
To be clear: They have to communicate on eye level and have to communicate with one common wording internally and externally. Don’t cut between those functions exactly where translation or extensive communication is needed. You support a Water-Fall-Scrum approach in a way that will not lead to success.
It makes total sense to locate both roles in the same team because again the common vision is king! It can’t be that the Product Manager is throwing requirements over the fence and hope for the Product Owner to process them!
If you slice responsibilities within Product Management roles, leadership, communication and a common understanding of the target, gets even more important!!!
If the hierarchic structure does not only emerge from multiple products but from multiple Business Lines, you should think about scaling them independently! But this is another chapter…
The sheer size often makes it necessary to actively manage internal products as well, because they are consumed at scale by multiple internal parties, which even expands the amounts of products.
This cenario suits for an large Enterprise with several business lines (enterprise) and possibly several portfolios, which are also actually differentiated and have at most a medium number of interfaces with each other.
Peculiarity: The historically grown Small Enterprise
The combination of a comparatively small workforce and a small revenue with the complexity of an internationally oriented enterprise serving multiple markets or sub-markets. This scenario poses great risks, especially in the volatile, future world. Sustainable success and successful scaling are hardly possible in the long run.
Regarding the slicing of Roles this is very similar to the portfolio-based company. But your biggest challenge will be to eliminate micromanagement and to establish a Product-Mindset over a Project Mindset, especially as the Project Mindset might still be needed for some other departments of the company.
Can Enterprises also scale like a Start-Up and keep the Agile Product led Mindset?
Could it also be the case that a active Management of interfaces is not necessary for larger companies? Theoretically yes, the everlasting example is Spotify. If a company has an extensive holacratic structure and is set up accordingly in the sense of a nesting of autonomous service organizations, this discipline can be carried out by the organization itself to the greatest possible extent.
Even then, the question of the representation of the Product Portfolio on a C-level and in marketing, etc. arises. So in this case the combination of Product Owners for the teams and a Head of Product make sense.
This handling is much easier with product-focused companies, more complicated with portfolio-based companies and often almost impossible in the case of scaling enterprises with several business lines. Often, this can be maintained quite well externally on the basis of technical expertise, but not internally. In addition, it is often accompanied by cutbacks in the area of organizational development. Such a company should rather be actively managed.
The success of a Spotify-like approach stands and falls with your employees and the culture you are able to establish.
Excursuses
Definition Product Management
Is it a Product and why Product Management?
This will be no lengthy treatise on Products, just a short definition for a common understanding:
A Product is a service or article that is predefined, often widely standardized, value-oriented and market-driven. A Product is scalable. This differentiates a product from a service, that could be undefined and may only solve a single set of problems or use cases e.g. for one or only a few customers. In both cases user-orientation and other values of a modern service organization are recommended.
Products at a high maturity include all articles, service elements, etc. that are part of a complete Customer Experience.
The Product Manager does not tell everybody involved in the product what to do. He/She is an interface between other responsibilities and has only some decisions to make him-/herself.
CIP
When it comes to changing the actual structure of Product Management responsibilities install Change Management as CIP permanently — This way you can already meet VUCA in the future, independent from this specific discipline.
[1]: Melissa Perri (CEO @ProduxLAbs). Escape the Build Trap, page 37
