Product Group Placement Models
Introduction
This review presents two models for internally structuring and placing the Product Group within the company’s organizational structure, along with their advantages and disadvantages.
The Product Group
The Product Management Organizational Placement review presented the history and inadequacy of placing the Product Management Department (aka Product Management Function) under the Marketing Group or the Engineering Group.
The lessons learned made executive management realize that product management is an autonomous corporate entity deserving of top-level placement in the corporate organizational structure.
The outcome was the creation of a Product Group, a top-level business unit that holds all functions related to product management.
The Product Group is sometimes called the Product Management Organization.
However, under different circumstances, companies also experimented with coupling the Product Group with the Engineering group.
Eventually, two organizational models emerged for internally placing the Product Group within the company’s organizational structure, each with advantages, disadvantages, and implications on product leadership.
Domain Separation Model
In the Domain Separation Model, the Product Group and Engineering Group are separated in the organizational structure.
The Product Group is managed by a VP of Product Management or Chief Product Officer (CPO).
The Engineering Group is managed by a VP of Engineering or Chief Technology Officer (CTO).
The CPO and CTO are equal peers, each reporting directly to the company’s Chief Executive Officer (CEO).
Roles in the Product Group and Engineering Group communicate and collaborate through forming Cross-Functional Teams (aka Matrix Team, Inter-working Team, or Multi-functional Team).
PMTK’s Product Management Team and Product Definition Team models are examples of cross-functional teams.
At the individual level, the Domain Separation Model allows product managers and engineers to retain a sense of belonging, cultivate a professional identity, promote the sharing of best practices, and jointly develop professional competency and expertise.
At the macro and leadership level, the Domain Separation Model helps product leaders avoid conflicts of interest, promotes check and balances on critical decisions, enables focusing on the domain, more straightforward management of a homogenous staff, and prevent feelings of impropriety and marginalization by specific roles over the other.
The Domain Separation Model is advocated by Blackblot and is a component of PMTK as it acknowledges the separation of the problem space (product management) and the solution space (engineering) per PMTK Foundation Rules.
Note: The Blackblot PMTK Methodology™ provides a detailed description of organizing Product Groups, departments, and teams.
Successful execution of the Domain Separation Model hinges on well-defined roles, clear division of labor, known responsibilities, direct ownership, and separating decision-making authority between product management and engineering.
PMTK product planning guidelines to establish efficient cooperation and collaboration between product management and engineering, under the Domain Separation Model, are to promote a consistent company-wide understanding that:
- Product Managers are market experts, and Engineers are technology experts.
- Product Managers are problem-tellers, and Engineers are problem-solvers.
- Product Management owns and controls the product’s market requirements.
- Engineering owns the solution and the product development project schedule.
However, not applying the aforementioned PMTK guidelines can induce friction between product management and engineering, create a silo mentality with less cooperation and collaboration, and give rise to a struggle for control over product strategy and feature set. This is the inherent risk of the Domain Separation Model.
In addition, separating leadership between the Engineering and ProductGroups and having the CPO and CTO as equal peers can potentially lead to contention and stalemate, eventually drawing the CEO from their strategic duties to arbitrate. Too much arbitration and possible CEO bias are severe drawbacks.
Domain Aggregation Model
In the Domain Aggregation Model, the Product Management Group and Engineering Group are part of the same business unit and report to one General Manager (aka Business Unit Manager, Head of Business Unit).
In the Domain Aggregation Model, one executive owns both product management and engineering resources.
This model’s main advantage is fast centralized executive-level decision-making, which brings closure to any outstanding issue. A quick resolution is just around the corner.
Some companies and their product projects are plagued by stagnation due to turf wars, internal politics, and ego battles. The Domain Aggregation Model allows an executive (General Manager) to quickly change product and project direction without too much interruption or resistance.
Another advantage includes dedicating and focusing all relevant resources on a specific market and product, committing everyone to one goal.
Many General Managers favor the complete control that the Domain Aggregation Model provides.
Many CEOs favor the Domain Aggregation Model because it allows holding a single General Manager overwhelmingly accountable for success or failure, for profit or loss. There are also significant cost‑savings; one less salary to pay.
However, the Domain Aggregation Model lacks the check and balances required in product decisions.
The Domain Aggregation Model can allow too much centralization and limit group dynamics and deliberations.
It is natural for people to gravitate to their comfort zone (business or technical) and make decisions according to a predisposition, and executives are not immune from this.
Not only that, the Domain Aggregation Model can allow for favoritism. For example, a General Manager with a solid technical background may frequently side with engineers.
The Domain Aggregation Model requires a uniquely talented executive versed in the technology and business worlds, exemplified in their strategic aptitude and technical skills. Locating and recruiting those qualified executives with relevant domain expertise can be challenging.
The Domain Aggregation Model inherently generates duplication of product management and engineering resources across the company’s different business units. Duplication of resources is always an inefficient arrangement.
Furthermore, and by design, the Domain Aggregation Model lacks all the individual and leadership advantages of the Domain Separation Model.
In the Domain Aggregation Model, the roles in the Product Group and Engineering Group also communicate and collaborate by forming Cross-Functional Teams. This arrangement generally works fine, but there have been instances where the notion that the shared boss (General Manager) favors one group over the other caused strain and less compromise.
Natural Self-Segregation
Planet of the Apes (1968), starring Charlton Heston, is a science fiction movie about a world ruled by intelligent apes.
The film was a commercial and critical success and won an Oscar for costume and makeup effects.
In the movie, there are three ape species played by human actors in costume and makeup: chimpanzees, gorillas, and orangutans.
Incidentally, it took upwards of six hours to put each of the many actors in full ape makeup.
In what can be described as an unintended social experiment, after the actors playing the ape characters put on their costumes and makeup, they segregated themselves by the ape species during lunchtime.
Charlton Heston noted: “It was instinctive segregation on the set. Not only would the apes eat lunch together, but the chimpanzees ate with the chimpanzees, the gorillas ate with the gorillas, the orangutans ate with the orangutans, and the humans would eat off by themselves.”
This novel and peculiar event demonstrate people’s natural inclination to self-segregate with others similar to them.
In general society, self-segregation can occur along many lines, including a foreign language, religion, ethnicity, race, social-economic status, and like-mindedness.
At the workplace, self-segregation will occur along status and occupation. Executive management, senior management, engineers, salespeople, and product managers will prefer to congregate with their professional peers.
The congregation provides a sense of belonging, group bonding, and fellowship that helps reinforce a clear identity of one’s self.
Self-segregation does not mean an aversion to working with dissimilar people. For the most part, everyone at a company is (and should be) willing to work with anyone from another department.
Organizations are mini-societies and social systems where the organizational structure is dictated and enforced by someone.
But people will strongly object to being officially and hierarchically grouped with others in a way that blurs their perceived social status or alters their self-image and professional identity.
Lunchtime on the Planet of the Apes movie set reiterated that social structures are related to one’s identity, and they reinforce each other.
Accordingly, the Domain Separation Model helps product managers build a distinct self-image and professional identity, while the Domain Aggregation Model could infringe on their self-image and professional identity.
This is yet another reason PMTK advocates the Domain Separation Model.
Summary
This review presented the Domain Separation Model and the Domain Aggregation Model for structuring and placing the Product Group within the company’s organizational structure.
Both models are valid and offer inherent advantages and disadvantages.
How to organize and where to organizationally place the Product Group is ultimately a judgment call.