In modern organizations, few things reveal strategic maturity more clearly than the way a company defines its “product.” Behind every definition lies a quiet but decisive truth: a company’s ability to define its product broadly and meaningfully is directly proportional to how much of its technology stack it actually owns.
When we examine the continuum from on-premises infrastructure to SaaS solutions, we see that the degree of ownership across these models shapes not only what a company can build, but how it organizes itself, empowers its teams, and connects technology to customer value.
From Full Ownership to Minimal Control: The Four Models
Let’s begin by revisiting the four major hosting and service models — each representing a different degree of control and responsibility.
1. On-Premises (On-Site Hosting)
In the on-premises model, a company owns and manages everything: networking, storage, servers, virtualization, operating systems, middleware, runtime, data, and applications. The entire ecosystem belongs to the enterprise. This complete ownership enables a much broader product definition — one that can cut across infrastructure and software, spanning from the physical to the digital. Teams in such organizations can be built to include multiple disciplines, working end-to-end on customer outcomes, without dependency on external providers.
2. Infrastructure-as-a-Service (IaaS)
Here, a portion of ownership is delegated. The provider manages the underlying hardware infrastructure (networks, servers, storage), but the client still owns and operates the operating systems, middleware, runtime, data, and applications. This allows for reasonably wide product definitions. Teams can stretch beyond applications to include middleware and operating system components — broad enough to maintain real product centricity and internal coherence.
3. Platform-as-a-Service (PaaS)
With PaaS, a provider hosts and manages everything below the level of applications and data. The client company controls those upper layers only. While this restricts technical depth, it still allows for meaningful product definitions — as long as teams work across multiple applications and datasets to deliver a coherent customer experience.
4. Software-as-a-Service (SaaS)
In the SaaS model, nearly all layers — from infrastructure to applications — are hosted by the provider. The client’s influence is limited to configuration, integration, and workflow customization. The product definition in such organizations naturally narrows, centering more around business processes and user interactions than around the underlying systems themselves.
Ownership as the Foundation of Product Definition
When an organization owns more elements of its technology landscape, it also gains the right — and the obligation — to define products more broadly. A fully on-premises company, for example, has the ability to design end-to-end solutions that integrate infrastructure, software, and data into one cohesive system.
Conversely, a SaaS-driven organization operates within boundaries defined by its provider. Expecting it to build deeply cross-functional product teams would be unrealistic. Thus, product definition should scale with ownership — the broader the control, the broader and more holistic the definition should be.
The Dysfunction Behind Narrow Product Definitions
Yet despite having broad ownership capabilities, many companies fail to take advantage of them. Even those operating under on-premises, IaaS, or PaaS models often define products in shallow, fragmented ways.
Instead of forming cross-functional, outcome-oriented teams, they define “products” around single applications, databases, or platform components, and assign “product owners” who are, in reality, legacy application or database administrators with new titles. These “fake products” and “fake product owners” perpetuate siloed thinking, disjointed ownership, and a fundamental lack of customer centricity.
The result is predictable: endless hand-offs, elongated cycle times, inter-team dependencies, and the classic “us vs. them” culture between technology domains. In such organizations, agility becomes an illusion — a set of renamed roles and repackaged silos masquerading as “product teams.”
The Fairness Scale: Judging Product Definition by Ownership
To evaluate organizations fairly, we need to introduce a “fairness scale” — a mental model that aligns expectations for product definition breadth with the degree of technological ownership.
At the highest end of the scale are on-premises companies, which control every layer of the technology stack. These organizations deserve the highest expectations for broad, cross-component product definitions and genuinely empowered product management. When such companies still operate through fragmented application silos, the dysfunction is glaring. They have all the ingredients for cross-functional agility but fail to use them — a clear sign of organizational inertia and poor design adaptability.
Just below them on the scale are IaaS companies, which still own substantial parts of their environments — including operating systems, middleware, runtime, and data. These organizations should also define their products broadly, ideally spanning multiple technical layers. If they fall into the trap of defining “applications” or “databases” as standalone products, they exhibit the same structural weaknesses as on-premises companies, though with a slightly more excusable degree of limitation.
Moving further down, PaaS organizations occupy a middle ground. Their ownership extends mainly to applications and data. As such, they can — and should — create product definitions that unite these elements under coherent customer-oriented outcomes. However, their technical boundaries are narrower by design. Criticizing a PaaS-based company for not owning infrastructure would be unfair; yet, expecting them to build multi-layered, value-centric product teams within their control domain is entirely reasonable.
Finally, at the lowest end of the scale are SaaS-dependent companies, which have minimal ownership beyond configurations and integrations. Their product definitions are expected to be narrow, often focusing on how software is adopted, customized, and leveraged within the business. For these organizations, agility manifests not in full-stack technical ownership, but in how effectively they orchestrate vendor relationships, data integrations, and business workflows.
This fairness scale reframes the discussion: the broader your ownership, the broader your accountability. And with that accountability comes an expectation for truly integrated product thinking.
The Organizational Design Correlation
The connection between product definition and organizational design is not accidental — it’s structural. Product definition expansion reflects the degree of organizational fluidity: how teams are structured, empowered, and connected.
In truly adaptive companies, teams are not built around technologies; they are built around value delivery. Developers, infrastructure specialists, data engineers, UX designers, and business analysts collaborate within the same product boundary. They own outcomes together, not in sequence.
But when an organization owns every component of its stack and still chooses to build around siloed applications and technical layers, it exposes a deeper failure — not of technology, but of mindset.
Stop Playing the Productization Game
At this point, it’s worth addressing an uncomfortable but necessary truth.
Many organizations — especially those at the lower end of the fairness spectrum or those that have failed to disrupt their traditional, component-centric structures — should stop pretending to be “product companies.”
If an organization still operates in strict silos, defining “products” around single applications, databases, or infrastructure components, it is not practicing product management — it is relabeling project management. The cosmetic renaming of programs, projects, and portfolios into “product initiatives,” and of project managers into “product managers” or “product owners,” only deepens confusion and erodes credibility.
This performative productization does not make an organization product-centric; it only gives it the illusion of progress while preserving the same rigid hierarchies, dependencies, and hand-offs that agile transformation was meant to eliminate.
The first step toward real change is intellectual honesty. A company that does not own or cannot influence key layers of its solution space — or one that refuses to redesign its organizational architecture around customer outcomes — should not borrow the language of product thinking. It should instead focus on improving the fundamentals: collaboration, flow, and clarity of purpose.
True product-centricity is not a branding exercise — it’s an organizational commitment to design around value, not components. Until that shift happens, it’s better for such companies to pause the “let’s go products” rhetoric and confront the real reasons why they remain structurally constrained.
In Closing
A fair understanding of product definition requires context. Companies that rely heavily on external cloud providers should not be judged by the same standards as those that own every byte and blade of their systems.
However, when a company enjoys full ownership and still operates with narrow, application-centric definitions of “product,” it reveals a profound organizational dysfunction.
The greater the ownership, the broader the product definition should be.
And when that proportionality breaks, it’s not the technology that’s at fault — it’s the organization.