Making “product” more productive

In the world of IT, the term "product" is often confusing and therefore unproductive. From software applications to IT infrastructure, the term seems to stretch across a wide range of offerings, leading to confusion, especially when it’s tied to discussions about product teams versus platform teams. To improve clarity and precision, it’s helpful to rethink how we categorize and define the various types of products in the context of modern IT organizations.

One way to bring clarity to this discussion is by introducing a 5-layer stack model that distinguishes between different types of products and their relationship to both internal and external users. By doing so, we can clarify not just what "product" means in each layer, but also the different ways these products are provided and consumed. This approach offers greater precision in understanding the various roles and responsibilities of product teams. This builds on a previous LinkedIn article[1] "Products", and "goods" and "services".

Pentastack for product teams

The stack consists of five layers, each representing a distinct category of product, whether digital or analogue. The layers are analogue products (final goods & services) and four types of digital products (data, software, platforms and infrastructure). These layers reflect the nature of the product, as well as the responsibilities of the product teams that build and support them.

These types of products should often be seen in combination. Firstly, an organization may offer a product that comprises several of these ‘elementary’ product types, for example, software as a service (SaaS) that combines infrastructure, platform and software. Secondly, such a product offering can be provided by a single team or several teams, for example, an infrastructure and platform team and a software team.

To add more clarity to these categories, various provision types apply to all layers of the stack:

1. Provided as a service:

The provider owns and maintains the product, and provides the right to use the product. This can happen virtually (access) or physically (possession – but not ownership).

1a)?Access: The product is made available for use over the internet or other means. The provider retains physical possession of the product, and operates it. This applies to offerings like SaaS, DaaS, PaaS, and IaaS.

1b)?Possession: The product is physically provided to the recipient, who integrates it into their own systems and operates it. Usage is governed by a licensing agreement, where the right to resell the product or change it, is usually excluded. The provider provides updates as appropriate. This applies to software or data that are integrated into internal systems or processes, where ownership remains with the provider.

2. Provided as a good: The product is sold or transferred outright to the recipient, who assumes full responsibility for managing and operating it, and is able to sell or change it. This applies to physical goods, like consumer electronics, as well as software or other digital products where ownership is transferred (e.g., perpetual software licenses or hardware sold to customers).

These product provision types correspond as follows with a broader typology that describes product/service offerings in terms of support, access, possession? and ownership.

1. Analogue products (final goods & services)

Analogue products represent tangible, physical items or services that are sold directly to customers. These are the final goods in an economic sense and typically have a direct, physical presence in the market. They can take the form of both goods and services. Goods are physical items, while services refer to intangible offerings that meet customer needs.

Product teams working in this layer are focused on designing, producing, and delivering physical products or services to market. While digital tools and software may assist in the manufacturing process or service delivery, the product itself is an analogue good or service.

2. Data

This is about data that is either made available as a service or sold outright. This can be proprietary data that is created internally, or acquired from external providers (e.g., market data, weather data). It is then provided to external or internal users. For external users, it can be provided as a service or sold outright.

• Internal use: Data warehouse for business intelligence, employee performance metrics database
• External access (DaaS): Real-time market analytics feed, weather forecasting API, consumer behavior data platform
• External possession: Licensed datasets for research institutions, demographic data packages
• External ownership: Customized market research reports, one-time data dumps

3. Software

Although platform and infrastructure also include software, in this layer, software products refer to applications that perform specific functions for end users. AI is also software, with the key distinction that it is adaptive (short term) and learning (longer term). LLMs could be added to the stack as "generative software", while AI agents could be added as "autonomous software". These would contrast with traditional "static software".

Examples:

• Internal use: HR management system, internal ticketing system, custom analytics dashboards
• External access (SaaS): CRM systems, accounting software, project management tools
• External possession: Licensed enterprise software, custom applications deployed on client servers
• External ownership: Perpetual license software products, mobile applications

4. Platform

Platform products provide a foundation for building, deploying and operating applications. These products allow organizations to develop and run their own software on top of them without having to worry about the underlying technology.

Examples:

• Internal use: Development environments, CI/CD pipelines, internal API gateway
• External access (PaaS): Cloud application platforms, serverless computing platforms, low-code development platforms
• External possession: Licensed development frameworks, containerization platforms (e.g. Docker)
• External ownership: Custom platform solutions, specialized development environments

5. Infrastructure

Infrastructure products represent the foundational IT components needed to run applications, such as servers, storage, networking, and other critical resources.

Examples:

• Internal use: On-premises data centers, private cloud infrastructure, network systems
• External access (IaaS): Cloud computing resources, virtual machines, storage services
• External possession: Network equipment, server hardware, storage systems
• External ownership: Custom hardware solutions, specialized computing equipment

Typical combinations

As already mentioned, these types of products should often be seen in combination. Here are some examples of product offerings that comprise all of the ‘elementary’ product types. These will be typically offered as a whole but provided by a combination of product teams, for example a data/software team and platform/infrastructure team.

Why this matters for product teams

As product teams continue to evolve, the need for precision in the term "product" becomes ever more apparent. For teams working in IT, distinguishing between the different layers—data, software, platforms, and infrastructure—helps to set expectations, clarify responsibilities, and align work. It also helps organizations understand where their efforts overlap with other teams, especially when it comes to custom-built applications and internal tools.

Understanding the nature of the product being built—whether it's a commercially available product or a custom-built solution—helps clarify the specific role of the product team, whether they are managing software applications for external clients or building a bespoke platform for internal use.

This 5-layer stack model, combined with the three product provision types, offers a more structured approach to product management, ultimately improving clarity and effectiveness in managing product teams.

By embracing a more nuanced and specific approach to the term "product", organizations can break down silos, reduce confusion, and foster a more collaborative environment where product teams across different layers of the stack collaborate more effectively.

Product team canvas

This five-layer stack can be extended to form a canvas for mapping product-related responsibilities to teams. Useful high-level responsibilities are:

• Own: The stakeholder who defines strategic direction, maintains control, and captures value from the product as an asset. This entity makes key decisions about investment and evolution of the product.
• Build: The team responsible for creation, development, and implementation. This includes engineering, configuration, and quality assurance of the product to meet specified requirements.
• Operate: The team that ensures reliable, secure, and efficient operation. They maintain availability, monitor performance, and keep the product running smoothly.
• Deliver: The team that manages distribution, access, and support. They ensure users can effectively access and utilize the product while providing necessary support.
• Use: The end beneficiary who derives operational value from the product. Their needs and feedback drive continuous improvement and future development.

This framework helps organizations clarify roles, reduce redundancy, and ensure smooth handoffs between teams across the product lifecycle. It's particularly valuable for complex systems where multiple teams need to coordinate effectively.

Team Topologies’[2] four types of teams help understand the framework. These are:

• Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
• Enabling team: helps a stream-aligned team to overcome obstacles. Also detects missing capabilities.
• Complicated subsystem team: where significant mathematics/calculation/technical expertise is needed.
• Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams.

In the simple example below, a stream-aligned-team makes use of a platform provided as a service by a platform team that, in turn, makes use of a infrastructure provided as a service by another platform team. Enabling teams and complicated subsystem teams might also be used but these have been excluded for the sake of simplicity.

Here is a practical application of this framework, showing how a business unit that provides non-digital products to their customers is supported by its internal IT department, which partners with a Managed Services Provider (MSP) and cloud platform services. In this scenario:

The business unit provides funding for the IT system and services and determines the requirements. The IT department develops custom software to meet business requirements, and enables the end users to use the system. Day-to-day operations are handled by an MSP, leveraging commercial Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) providers. This creates a streamlined service delivery model where:

• Business units maintain control of their core processes and data
• Internal IT focuses on software development and service delivery initiatives
• The MSP manages routine operations and housekeeping
• Cloud providers supply the underlying technical platform and infrastructure
• Each layer builds upon the capabilities of those below it

This common division of responsibilities balances internal control with operational efficiency, allowing the organization to focus on its core capabilities while leveraging external expertise for technical operations.

Here is another example, for a mobile app for banking. The mapping is very rough and not necessarily correct, but hopefully good enough to illustrate how the framework can be applied.

By providing a structured way to visualize and map responsibilities across different product layers, the product team canvas serves as a useful tool for managers who are considering how to organize work. It helps leaders and teams understand their roles in the product lifecycle, identify potential gaps or overlaps in responsibilities, and ensure clear accountability. Whether applied to a simple software product or a complex multi-layered system, this canvas facilitates better communication, more efficient coordination, and clearer organizational design. As organizations continue to evolve and embrace digital transformation, such clarity in product team responsibilities becomes increasingly vital for successful delivery and operation of products and services.

[1] https://www.dhirubhai.net/pulse/products-goods-services-mark-smalley-wouze/

[2] https://teamtopologies.com/key-concepts/