Slicing the Product

Between 2017 and 2021, I had the privilege of visiting GROOVE X in Tokyo several times, together with Aki Enomoto, who was coaching the company at that time. GROOVE X builds LOVOT, a companion robot designed to make people feel loved. Their Ambition was bold: create a robot that humans bond with emotionally, not one that performs tasks.

What impressed me was not just the manager-less organization with 120 people in 20 teams operating as a single unit under LeSS. What impressed me more was the product itself and the courage of its Ambition.

LOVOT is not a software product. It is hardware, software, AI, industrial design, sensors, a repair service, a flagship retail store, and much more. The Teams did not organize around technical layers. They organized around shared epics: “LOVOT welcomes the family at the entrance when they come home.” Every team could contribute to that epic, regardless of whether their work was in firmware, mechanical design, or behavior animation.

A fundamental principle at GROOVE X, inherited from Scrum and LeSS, was to maintain one integrated state of the product at all times. When production pressure grew, they tried running concurrent hardware versions to avoid production-line downtime. The result was a reinforcing defect loop: design changes could not be applied to versions already in production, multiplying defects across versions. One integrated product is cheaper than two diverging ones. They returned to sequential versions and never looked back.

They also learned a harder lesson about supplier dependencies. One of their sensor suppliers changed their own production line. The sensor behavior and data quality shifted slightly. The Teams had to refactor parts of the robot, including their AI models, because the underlying data had changed. When something like that happens late in the process, it becomes very expensive. In this case it delayed production.

The boundaries of a product do not end at the company walls. They extend into the supply chain.

For product engineering, these challenges are not new. Supplier disruptions, interface changes, and cascading redesigns have always happened. You just never know when or how. With AI now deeply integrated into products and services, these disruptions will happen more often and more broadly. Knowing when and how to slice a product into components, and how to organize the Teams that build them, is strategic knowledge.

What Is an Arena Product?

The Arena Product is not just code or a physical device. It encompasses everything the Arena produces.

The Arena Product consists of four layers of work. Each layer depends on the work results of the layers below it.

1. The work that produces results for customers: services provided by the labor of Teams and services or goods provided by automated systems. This is what the customer sees and uses.
2. The work to improve these results: developing and evolving the products and services. Every Improvement in the Arena Backlog is development work.
3. The work to improve the work system: practices, tools, processes, and organizational structure of the Arena.
4. The work on strategy: the strategic direction provided through Tournament, Enterprise Backlog, and Accountable Representatives.

Strategy enables the work system. The work system enables development. Development enables results for the customer.

At GROOVE X, Teams develop and manage. One Team develops AI behavior algorithms. Another manages the sensor supplier relationship. A third runs the flagship store operations. Supply chain management is Improvement work, no different from writing code or designing a circuit board.

This breadth matters for slicing. Product components include all of these: hardware modules, software services, human-delivered services, supplier relationships, retail operations. The slicing decisions apply to all of them.

Components: Horizontal and Vertical

Every product can be decomposed into components. The question is how.

Consider the iPhone. The visible layer includes apps, the operating system, the physical device, and the case. Below that sit invisible layers: the TCP/IP stack, the chipset, the wireless driver. Each component has its own lifecycle, its own rate of change, and its own set of constraints.

Horizontal slicing cuts along technical layers. One Team owns the frontend layer. Another owns the technical component drivers. A third owns the hardware. Each Team becomes a specialist in its layer.

But every customer-facing feature that crosses layers requires coordination between Teams. This is the component team model, and it will highly likely create the dependency problems described in Slicing the Organization.

Vertical slicing cuts through all layers end-to-end, from the customer down to the lowest infrastructure component. Each team owns a complete slice of customer value. This is the feature team model. In many cases it minimizes inter-team dependencies better than the horizontal model, because the interfaces to other components are more stable.

At GROOVE X, the Teams worked on shared epics that cut vertically through hardware, software, and design. At Web.de, as described in Slicing the Organization, the Teams were split horizontally into frontend and backend. The difference in coordination overhead was the difference between a product that shipped and one that fought itself.

Neither approach is safe by default. Choosing the wrong slicing direction locks in dependencies that are hard to undo. As we will see later, whether horizontal or vertical slicing works better depends on how stable the interfaces between components already are. But first: how do we know where the boundaries are?

Finding Product Boundaries with Aspects

How do you know where to draw the line between components? When an engineer says, “If we don’t design this now, we will pay much more later,” you are hearing an Aspect.

An Aspect is a requirement that affects the whole component, not just a single feature, and whose cost grows exponentially the longer it is deferred. Security, performance, compliance, repairability, multi-language support, and backward compatibility are all Aspects. They cut across everything a component does. You cannot add them as a feature later. They must be designed in from the start.

Aspects are a powerful tool for identifying product boundaries. When two parts of a product have fundamentally different Aspect profiles, they need different design decisions and different lifecycles. That is where you slice.

Consider the iPhone components again. Each has a fundamentally different Aspect profile:

The App changes 240 times per year. The Device never changes functionally. The TCP/IP Stack must be supported for 15 years and comply with international standards. These are not the same product in any meaningful sense. They only share a physical enclosure. The differences in their Aspect profiles are precisely why they are separate components.

When two parts of a product have fundamentally different Aspect profiles, they belong in different components.

The cost curves make this concrete. Functional changes become cheaper over time as the product matures and tooling improves. Aspect changes become exponentially more expensive. Adding multi-language support to a mature application costs orders of magnitude more than designing it in from the start. Retrofitting security into a product after deployment is a different order of effort than building it from day one.

Teams that focus only on functional slicing accumulate Aspect debt. When the bill comes due, it is exponential.

Mapping Product Evolution

The further left a component sits on the evolution path, the more likely its Aspects and boundaries will change. This is the critical connection between product slicing and Evolution Focus.

The LOVOT Wardley Map shows the product’s components at different evolutionary stages. On the left (Genesis and Custom Build): the AI behavior, the sensor unit, the industrial design, and the core value proposition, “Accept as an Individual.” These components are still being explored. Their boundaries shift with every iteration. Their Aspects are not yet fully understood.

On the right (Product and Commodity): the flagship store, the repair service, commodity sensors, and real estate services. These components are stable. Their Aspects are well-defined. Their interfaces are predictable.

The purple dividing line marks the transition: components on the left are developed by the Teams. The supply of the components on the right is managed by the Teams.

What Teams develop today, they will manage tomorrow.

This has a direct implication for organizational design. Conway warned that “the prevailing system concept may need to change” and therefore “flexibility of organization is important to effective design.” Creating dedicated component teams for Genesis-stage components locks in boundaries that are not yet stable. When the AI behavior shifts, every team boundary drawn around old assumptions becomes a coordination barrier.

For components in the Genesis and Custom Build zone, multi-team setups working across all components are recommended. Flexibility must be preserved. Only when components move into the Product and Commodity zone do their boundaries stabilize enough for dedicated ownership.

Why Slicing Matters

Three dimensions shape where to draw product boundaries:

1. Components tell you where to cut: which parts of the product can be separated along stable interfaces.
2. Aspects tell you what shapes the boundaries: different Aspect profiles indicate different lifecycle needs.
3. Evolution tells you when boundaries are stable enough to cut: Genesis-stage boundaries shift, Commodity-stage boundaries are fixed.

Without deliberate product slicing, organizational boundaries follow historical accident. Conway’s Law locks in whatever structure exists. The frontend team and the backend team at Web.de were not a deliberate design choice. They were an inherited structure that nobody questioned.

With deliberate product slicing, Owners, System Leads, and the Enterprise Owner can design team boundaries that minimize dependencies and maximize independent value delivery. This is the Inverse Conway Maneuver applied to the product: let the target product architecture determine the organizational structure, not the other way around.

Practical Guidance

How to Slice

• Slice along stable interfaces where inter-team communication intensity is lowest
• Slice as late as possible. Every boundary creates a communication barrier. Per Overall Optimization, premature boundaries are worse than no boundaries.
• Consider product architecture and organizational structure together. They are two sides of the same problem.
• Account for Aspects early. Identify which Aspects will dominate cost later and address them before they become exponential. Designing for Aspects develops the natural boundaries along which the product can later be sliced as it grows.
• Use Wardley Mapping to identify which components to develop, which to manage, and which to outsource or rent.
• Do not outsource components that are still in Genesis or Custom Build. Their Aspects and interfaces are not yet stable enough for external dependencies.

When to Slice

• The product has components at different evolutionary stages requiring different approaches
• Aspect profiles diverge: one component needs monthly releases, another needs 15-year support
• The De-Scaling Cycle identifies persistent dependencies that restructuring the organization alone cannot solve
• Outsourcing or renting a component becomes viable because it has moved to Product or Commodity
• The product scope has outgrown the current Arena structure and a new Arena is needed

The Other Side of the Coin

This chapter addresses how to slice the product: identifying components, understanding their Aspects, and mapping their evolution to determine where boundaries should be drawn.

The companion chapter, Slicing the Organization, addresses the other side: how to structure Teams, multi-team units, and Arenas for minimal communication overhead and maximum autonomy.

Conway’s Law tells us that organizational boundaries and product boundaries mirror each other. You cannot design one without designing the other.

Together, they form one practice: designing the organization and the product as a single, evolving system.