Have we ever wondered how the language describing the traditional relationship between an Owner and a Manager became so twisted in the world of Agile and Scrum?
In the conventional business world, the relationship between ownership and management has always been relatively straightforward. A business owner establishes the direction of the enterprise, determines its mission and vision, makes investment decisions, and establishes priorities, while managers are entrusted with organizing and coordinating the activities necessary to achieve those objectives. Managers typically work for the owner, and in smaller businesses, the distinction may disappear altogether because the owner also performs the managerial responsibilities. This arrangement is so familiar that few people would question the underlying logic.
Of course, owning a business and fulfilling the Product Owner accountability in Scrum are not legally or organizationally equivalent. A Product Owner does not necessarily own the company’s assets or possess the authority of a business proprietor. Nevertheless, the terminology was intended to convey meaningful accountability for product value, priorities, and decisions rather than simply responsibility for documenting requirements or coordinating development activities.
This makes the evolution of Product Ownership within many organizations particularly interesting. Somehow, as Scrum became increasingly popular and organizations began introducing their own interpretations of Agile scaling, the relationship between ownership and management was effectively reversed. Product Managers became the senior organizational authorities responsible for strategy, vision, roadmaps, and business decisions, while Product Owners were frequently positioned as subordinate, team-level specialists responsible for writing user stories, maintaining backlogs, clarifying requirements, and reporting progress.
The Product Manager typically retained the higher organizational classification, greater decision-making authority, and more attractive compensation, while the Product Owner, despite the title, was often left with relatively little influence over the product itself. Over time, this arrangement became so normalized that many professionals began treating it as an inherent characteristic of Agile product development rather than questioning where the distinction originated and whether it was ever intended by Scrum.
How Scrum’s Product Owner Became a Subordinate Role
Scrum itself provides little justification for the organizational hierarchy that has emerged around these titles. The framework establishes three accountabilities within a Scrum Team: Product Owner, Scrum Master, and Developers. Product Manager is not among them, although this certainly does not mean that Product Management is unnecessary or incompatible with Scrum.
Product Management is a well-established professional discipline involving market understanding, customer needs, product strategy, commercial viability, investment decisions, and product lifecycle management. An experienced Product Manager may be exceptionally well-qualified to fulfill the Product Owner accountability, particularly when that individual possesses the authority and organizational support necessary to make meaningful product decisions.
What Scrum does not prescribe is a separate Product Manager positioned above a Product Owner, with the former retaining strategic authority while the latter serves primarily as a requirements administrator for a development team. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team, which requires substantially more than maintaining a collection of user stories or facilitating discussions about backlog items.
Effective Product Ownership requires understanding business objectives, customer needs, product economics, competing opportunities, technical constraints, and the consequences of investment decisions. It also requires sufficient authority to make decisions about product direction and priorities, particularly when competing stakeholder interests or organizational constraints make those decisions difficult.
The Scrum Guide explicitly emphasizes that the organization must respect the Product Owner’s decisions, yet in many enterprises, the individual carrying that title cannot make consequential product decisions without obtaining approval from a Product Manager, a steering committee, or several layers of functional management.
This contradiction raises a fundamental question about the meaning of accountability in organizations that claim to practice Scrum. If an individual is formally accountable for maximizing product value but lacks the authority to make decisions affecting that value, the organization has created a structural conflict between responsibility and authority. Changing the individual’s title does nothing to resolve that conflict, and introducing additional coordination roles often makes it more difficult to recognize.
The Organizational Origins of the False Dichotomy
To understand how this situation developed, it is necessary to consider the organizational environment into which Scrum was introduced. Most established enterprises already possessed elaborate structures of functional management, professional job families, compensation bands, reporting relationships, and approval mechanisms long before Agile terminology became fashionable.
Product Managers existed in many industries well before Scrum gained widespread adoption, and their responsibilities frequently included market analysis, product strategy, commercial planning, and coordination across business functions. Business Analysts were also well-established professionals whose responsibilities included requirements analysis, stakeholder communication, business process evaluation, and documentation of proposed solutions.
When Scrum introduced Product Ownership, organizations faced the challenge of incorporating an accountability that did not fit neatly into their existing organizational structures. A genuine implementation would have required reconsidering how product decisions were made, who possessed the authority to establish priorities, how development teams interacted with business stakeholders, and how accountability for outcomes should be distributed.
Such changes were not particularly attractive to organizations accustomed to traditional functional hierarchies, especially when those changes threatened established managerial authority, reporting relationships, and compensation structures.
Consequently, many organizations adopted a much simpler approach by assigning the Product Owner title to individuals already performing Business Analyst responsibilities. In some cases, existing Business Analysts were simply renamed Product Owners, while their actual responsibilities, organizational standing, and decision-making authority remained largely unchanged.
Requirements documents were converted into user stories, requirements repositories became Product Backlogs, and traditional status meetings were replaced with Scrum events, yet the fundamental relationships governing product decisions remained essentially the same.
The newly appointed Product Owners were expected to support development teams, clarify requirements, maintain Jira or Azure DevOps, participate in Sprint Planning, and provide progress updates, while product strategy, investment decisions, and prioritization authority continued to reside elsewhere in the organization.
This approach allowed companies to demonstrate visible adoption of Scrum without undertaking the considerably more difficult work of changing their operating models. Unfortunately, it also established a distorted interpretation of Product Ownership that gradually became institutionalized through recruitment practices, job descriptions, training programs, and organizational career paths.
Today, many Product Owner job descriptions emphasize user story writing, acceptance criteria, backlog refinement, Sprint ceremonies, and proficiency with Agile tooling, while providing relatively little attention to product economics, customer value, strategic decision-making, or accountability for business outcomes.
There is nothing inherently wrong with Business Analysis, which remains a valuable professional discipline, but renaming a Business Analyst as a Product Owner does not automatically create genuine Product Ownership. The problem arises when organizations assign the title while withholding the responsibilities and authority that give the accountability its meaning.
How HR Structures Reinforced the Distortion
One particularly important aspect of this evolution is the influence of traditional human resources classifications and compensation structures, which have helped reinforce the artificial distinction between Product Management and Product Ownership.
In many established enterprises, Product Management positions were already associated with relatively senior professional classifications and compensation levels. Business Analyst positions frequently belonged to different job families, with compensation determined by historical responsibilities, organizational expectations, and established career progression models.
When Product Ownership was interpreted primarily as a variation of Business Analysis, the new positions naturally inherited similar classifications and compensation bands. Product Managers retained their existing organizational standing, while Product Owners were frequently placed within lower-level professional structures.
Over time, these classifications began influencing how organizations understood the roles themselves. Product Managers were increasingly described as strategic leaders responsible for vision, roadmaps, and business outcomes, while Product Owners were characterized as tactical specialists supporting development teams.
The organizational hierarchy gradually became the justification for the division of responsibilities, rather than the actual responsibilities determining the appropriate organizational arrangement.
This is particularly ironic because Product Ownership is the accountability explicitly established by Scrum to maximize product value, yet the individual supposedly responsible for that value may possess less influence than managers whose primary responsibilities involve supervising employees, coordinating activities, or administering delivery processes.
The resulting separation between accountability and authority is not merely a theoretical concern. It creates practical problems when Product Owners must repeatedly seek approval for priorities, negotiate decisions already made elsewhere, or explain requirements they had little opportunity to influence.
Organizations then experience delays, misunderstandings, conflicting priorities, and unnecessary dependencies, often attributing these difficulties to insufficient Agile maturity or inadequate coordination rather than recognizing that their own organizational structures are contributing to the problem.
How Fake Agile Scaling Institutionalized the Problem
The proliferation of Agile scaling frameworks and enterprise transformation programs has frequently amplified these distortions rather than correcting them.
As organizations attempted to extend Scrum across multiple teams, departments, and business units, many introduced additional organizational layers, specialized roles, planning structures, coordination mechanisms, and reporting requirements. Rather than simplifying product accountability, these arrangements often fragmented it across an expanding collection of positions with overlapping or competing responsibilities.
Product Managers were assigned responsibility for strategy and roadmaps, Product Owners were assigned responsibility for team backlogs, program managers coordinated dependencies, release managers coordinated delivery schedules, and various Agile leadership positions supervised the overall process.
Transformation offices, centers of excellence, and external consulting organizations introduced additional governance structures intended to ensure consistent implementation of the selected scaling framework. The resulting operating models frequently resembled traditional project management bureaucracies, except that the terminology had been replaced with language borrowed from Scrum, Lean, and Agile product development. What makes this particularly troubling is that many of the organizational problems these structures were supposedly designed to address were created or reinforced by the structures themselves.
When product accountability is fragmented across multiple organizational levels, additional coordination becomes necessary. When teams are organized around functional specialties or arbitrary delivery boundaries rather than meaningful products, dependencies multiply. When decision-making authority remains centralized, organizations introduce escalation processes and governance mechanisms to compensate for the inability of teams to make timely decisions. The complexity becomes self-perpetuating because every new coordination problem creates an apparent justification for another managerial role, planning ceremony, reporting requirement, or specialized tool. Eventually, organizations find themselves investing substantial financial and human resources in managing the elaborate machinery of their Agile transformation while struggling to demonstrate corresponding improvements in customer value, product quality, or responsiveness to change.
This is not an argument against coordination or the need for specialized expertise in large organizations. Complex products frequently require collaboration among numerous teams, and some degree of coordination is unavoidable. The problem is the assumption that scaling product development necessarily requires scaling managerial hierarchy, administrative overhead, and fragmented accountability.
In many cases, organizations have simply reconstructed traditional command-and-control management within their Agile operating models, preserving centralized decision-making and functional boundaries while introducing new terminology to describe familiar managerial practices.
The Product Owner becomes one of the most visible casualties of this arrangement because the accountability intended to provide clear ownership of product value is reduced to a subordinate position within an increasingly complicated delivery hierarchy.
The Artificial Separation of Strategy and Execution
The conventional distinction between Product Managers and Product Owners is frequently presented as a natural division between strategic and tactical responsibilities.
According to this interpretation, Product Managers focus on markets, customers, strategy, and roadmaps, while Product Owners focus on development teams, requirements, backlogs, and delivery activities.
Although this division may appear convenient from an organizational chart perspective, it introduces serious problems when applied rigidly to product development.
Product strategy and product delivery are not independent activities that can be separated through a simple managerial handoff. Product decisions require continuous interaction between customer needs, business objectives, market opportunities, technical capabilities, delivery constraints, and feedback from actual product use.
A person accountable for maximizing product value cannot operate effectively while being excluded from strategic decisions affecting that value. Similarly, a Product Manager who remains disconnected from the realities of product development risks producing strategies and roadmaps based on assumptions rather than empirical evidence.
Separating these responsibilities often recreates the sequential handoffs that Agile approaches were intended to reduce. The Product Manager establishes the strategy and passes requirements to the Product Owner, who translates them into backlog items and passes them to developers, who subsequently implement the requested functionality.
Each handoff creates opportunities for misunderstanding, information loss, delays, and diminished accountability, particularly when individuals are evaluated primarily on completing their assigned portion of the process rather than achieving shared product outcomes.
This arrangement also introduces ambiguity regarding who ultimately makes product decisions when priorities conflict or circumstances change. The Product Manager may claim responsibility for strategy, while the Product Owner is formally accountable for maximizing product value, leaving both individuals operating within overlapping and potentially contradictory spheres of authority.
In practice, the conflict is usually resolved through organizational hierarchy, with the Product Manager exercising managerial authority over the Product Owner. Unfortunately, this solution reinforces the very separation between accountability and authority that makes the arrangement problematic.
The distinction between Product Management and Product Ownership should therefore be understood in terms of professional discipline and framework accountability rather than as a mandatory separation between strategic and tactical organizational positions.
Product Management encompasses a broad set of capabilities associated with developing and sustaining successful products, while Product Ownership represents a specific accountability within Scrum. These concepts are compatible and may be fulfilled by the same individual without creating competing positions or unnecessary managerial relationships.
Why a Product Manager Can Be an Excellent Product Owner
Consider an experienced Product Manager who understands the market, customers, competitive environment, product economics, organizational strategy, and technical capabilities associated with a particular product. If that individual also possesses the authority to make product decisions, establish priorities, evaluate investment opportunities, and collaborate directly with development teams, there is little reason to assume that a separate subordinate Product Owner is necessary. In fact, introducing an additional organizational layer may weaken the connection between product strategy and execution by requiring decisions and information to pass through another person whose authority is limited by the reporting structure.
A Product Manager fulfilling the Product Owner accountability can maintain direct involvement in customer discovery, strategic planning, backlog ordering, stakeholder collaboration, and evaluation of product outcomes. This does not mean that one individual must personally perform every activity associated with Product Management or Product Ownership. Business Analysts, UX researchers, designers, architects, data analysts, and other specialists can contribute essential expertise without assuming separate or competing accountability for the product.
Scrum explicitly allows the Product Owner to delegate work associated with Product Backlog management while remaining accountable for the results. This distinction between delegating activities and retaining accountability is important because it enables collaboration without requiring unnecessary fragmentation of decision-making authority. The same principle becomes especially relevant when multiple Scrum Teams collaborate on a single product. The Scrum Guide establishes that teams working on the same product should share the same Product Goal, Product Backlog, and Product Owner.
Nevertheless, many organizations have adopted arrangements in which individual Product Owners are assigned to individual development teams, with Product Managers positioned above them to coordinate product direction and priorities. These structures may appear convenient because they align with existing organizational reporting relationships, but they can also create artificial boundaries within a product and introduce dependencies that would otherwise be unnecessary.
The organization subsequently invests in additional coordination mechanisms to manage those dependencies, creating an expensive cycle in which structural complexity is treated as an unavoidable characteristic of scaling rather than a consequence of organizational design decisions.
The Organizational Resistance Behind the Terminology
The Product Manager versus Product Owner debate ultimately reflects a broader and more persistent challenge associated with Agile transformation. Many organizations want the benefits of adaptability, faster delivery, empowered teams, and improved customer responsiveness without accepting the changes to managerial authority, organizational boundaries, and decision-making practices necessary to achieve those benefits. They continue to rely on centralized planning, hierarchical approvals, functional specialization, and traditional performance management structures while expecting teams to demonstrate the flexibility and autonomy associated with modern product development.
This contradiction becomes particularly visible when Product Owners are formally held accountable for product value but are evaluated primarily on backlog administration, requirements documentation, and participation in Scrum events. It is equally visible when Product Managers are rewarded for producing roadmaps, supervising subordinate Product Owners, and maintaining delivery predictability rather than demonstrating improvements in product outcomes. Organizations may invest heavily in Agile training, certifications, coaching, tooling, and scaling frameworks while leaving the underlying management philosophy largely untouched.
As a result, the organization becomes increasingly proficient at performing Agile ceremonies and producing Agile artifacts without necessarily developing the capabilities required for genuine adaptability. The proliferation of dashboards, planning events, governance meetings, and transformation metrics can create an appearance of organizational sophistication, but these mechanisms provide limited value when the underlying information is unreliable or when teams lack the authority to respond to what they learn.
A company may employ hundreds of certified Scrum Masters, Product Owners, Agile Coaches, and transformation specialists while continuing to make consequential product decisions through the same traditional managerial channels that existed before the transformation began. The problem is not the absence of Agile terminology or insufficient adherence to a scaling framework. It is the failure to reconsider how the organization distributes accountability, authority, and responsibility for business outcomes.
The Difference Between Managing People and Owning Product Outcomes
Another important dimension of this problem is the continued association between managerial seniority and organizational importance. Traditional enterprises frequently measure managerial significance through the number of employees reporting to an individual, the size of the budget controlled, or the organizational level occupied within the hierarchy. This thinking naturally encourages arrangements in which Product Managers supervise Product Owners, who coordinate development teams, creating an apparently logical chain of managerial authority.
However, Product Ownership is fundamentally different from traditional people management because its primary purpose is maximizing product value rather than supervising employees or administering delivery activities. An effective Product Owner does not necessarily require direct reports or a conventional management position, but does require meaningful authority over product decisions, priorities, and value-related trade-offs. The distinction matters because organizations often confuse the authority to manage people with the authority to make product decisions.
A person may hold a senior managerial title and supervise numerous employees while having limited understanding of customer needs, product economics, or the technical and commercial trade-offs associated with product development. Conversely, an experienced product professional may possess deep market knowledge, strong analytical capabilities, and excellent product judgment without occupying a traditional managerial position. The effectiveness of Product Ownership should therefore be evaluated through the individual’s ability to maximize product value and make sound product decisions rather than through the number of subordinate employees or the organizational grade assigned to the position.
This does not suggest that Product Owners should be placed above Product Managers in a reversed hierarchy, because doing so would merely reproduce the same organizational mistake from the opposite direction. The objective should be to eliminate the artificial distinction where it serves no meaningful purpose and establish a coherent distribution of responsibilities based on actual product needs rather than inherited job classifications.
What Meaningful Change Would Actually Require
Organizations genuinely interested in improving their product operating models should begin by examining how product decisions are made rather than debating which titles should appear on organizational charts. They should consider who determines product direction, who evaluates investment opportunities, who makes trade-offs between competing priorities, and who possesses the authority to respond when market conditions or customer needs change. They should also examine whether the individuals formally accountable for product value have sufficient access to customers, stakeholders, business information, and technical expertise to make informed decisions.
Where accountability is fragmented across multiple organizational levels, organizations should challenge whether those divisions contribute meaningful value or simply preserve traditional reporting relationships. If Product Owners primarily perform Business Analyst activities, organizations should acknowledge the nature of those responsibilities rather than presenting the arrangement as genuine Product Ownership.
There is nothing inherently inferior about Business Analysis, and organizations benefit from capable professionals who can examine requirements, analyze processes, clarify business needs, and support product development. The difficulty arises when the Product Owner title is used to create the appearance of Scrum adoption without providing the corresponding authority and accountability.
Similarly, Product Management should not be diminished or artificially separated from Product Ownership merely because an organization has adopted Scrum. Experienced Product Managers often possess precisely the knowledge and capabilities required to fulfill the Product Owner accountability effectively. A more coherent operating model would recognize Product Management as a professional discipline and Product Ownership as a specific accountability, allowing organizations to assign that accountability to appropriately qualified individuals without introducing unnecessary hierarchical relationships.
Such an approach would also require reconsidering compensation structures and professional classifications so that individuals are evaluated according to the actual complexity, scope, and responsibility of their work rather than historical assumptions about job titles. Perhaps most importantly, organizations would need to reconsider their continued reliance on traditional command-and-control management practices, particularly where those practices undermine timely decision-making, cross-functional collaboration, and accountability for outcomes.
These changes are considerably more difficult than implementing a scaling framework or renaming existing positions, which may help explain why so many organizations have preferred the latter approach.
Conclusion: We Did Not Scale Scrum; We Scaled Our Misunderstanding of It
The illustration accompanying this article uses a deliberately exaggerated comparison between traditional business ownership and the organizational interpretation of Product Ownership found in many supposedly Agile enterprises. On one side, a business owner establishes direction while managers organize and execute the work necessary to achieve business objectives. On the other, an assertive Product Manager directs several overwhelmed Product Owners whose responsibilities have been reduced to requirements administration and team-level coordination.
The contrast is intended to be humorous, but the organizational dysfunction it represents is familiar to anyone who has spent substantial time observing large-scale Agile transformations. Many organizations have created environments in which the title Owner signifies less authority than the title Manager, despite the Product Owner being the accountability explicitly established by Scrum to maximize product value.
This arrangement did not originate from a requirement within Scrum, nor does it represent an unavoidable characteristic of Product Management. It frequently reflects an unwillingness to challenge traditional organizational hierarchies, reporting relationships, job classifications, and compensation structures. Instead of adapting the organization to support meaningful Product Ownership, many enterprises adapted the interpretation of Product Ownership to preserve their existing management structures.
As these arrangements expanded, scaling frameworks and transformation programs introduced additional roles and coordination mechanisms to manage the complexity created by fragmented accountability and centralized decision-making. The result has often been an increasingly expensive organizational machinery that appears Agile in terminology and process while remaining fundamentally traditional in its management philosophy.
Scrum was not introduced to provide organizations with a more elaborate vocabulary for conventional project management or to create new professional hierarchies around product development. Its purpose is to support the development of valuable products through empiricism, collaboration, adaptation, and clear accountability. An experienced Product Manager can fulfill the Product Owner accountability exceptionally well when provided with the necessary authority, organizational support, and access to the people and information required to make effective product decisions.
There is no inherent need to separate these responsibilities into two hierarchical positions, and there is certainly no justification for systematically reducing Product Ownership to a subordinate requirements administration function while presenting the arrangement as a sophisticated product operating model. The more important question is why so many organizations continue attempting to fit Scrum into traditional managerial structures rather than reconsidering whether those structures remain appropriate for modern product development.
Until organizations become willing to challenge their underlying assumptions about authority, accountability, and management, introducing additional Agile roles, scaling frameworks, certifications, and tools will do little to resolve the fundamental problem.
When an organization refuses to change its management philosophy, adopting Agile terminology does not create agility; it simply makes traditional bureaucracy more complicated, more expensive, and considerably harder to recognize.