Product Systems: The Architecture of Recombination

There's a question that separates companies that scale gracefully from companies that drown in complexity:

Can your components recombine to serve outcomes you haven't imagined yet?

If the answer is no—if every new customer segment requires rebuilding from scratch—you don't have a product. You have a collection of one-offs held together by heroic effort.

The Swiss Army Knife Principle

Victorinox has produced over 400 Swiss Army Knife models. They're not 400 separate products. They're combinations of around 100 standardised tools—each designed to work with any combination of others.

Want a knife with a screwdriver and scissors? Combine those three tools. Want one with a corkscrew and saw? Different combination, same system.

This is what Karl Elsener understood in 1891 when he founded the company: different customers need different outcomes from the same core capabilities. The solution isn't to build custom products for everyone. It's to build components that recombine.

The LEGO Test

LEGO bricks from 1958 still connect with bricks manufactured today. That's over 65 years of backward compatibility—through material changes, new product lines, acquisitions, and fundamental shifts in how children play.

This isn't an accident. It's a commitment to interface stability that constrains every design decision. New elements must work with old elements. Innovation happens within boundaries.

The result? LEGO can launch new themes, new characters, new mechanisms—while every piece remains part of one coherent system. Customers invest in LEGO knowing their collection will never become obsolete.

Monoliths vs. Systems

Most products start as monoliths. One thing, designed for one use case, optimised for the customers you have today.

That works until:

• A new customer segment needs 80% of what you built, but not the other 20%
• An enterprise wants to integrate your capability into their workflow differently
• You need to offer tiers without rebuilding everything three times
• Market conditions shift and your monolith can't adapt

Product systems solve this by decomposing capability into components with clear interfaces. Each component does one thing well. Combinations create variety.

The Elsener Checklist

For any product architecture, evaluate:

1. Component Independence: Can each piece function without the others? Can pieces be added or removed without breaking the system?

2. Interface Stability: Are the connection points between components well-defined and stable? Do changes propagate predictably?

3. Recombinability: How many valid combinations exist? Can new combinations emerge without engineering effort?

4. Backward Compatibility: Can new components work with old ones? Can customers trust that their investment won't be stranded?

5. Graceful Scaling: Does adding components make the system better, or does it make it fragile?

The Pattern in Practice

AWS is a product system. Each service does one thing. Services combine through stable APIs. New services can be added without breaking existing ones. Customers build architectures from components.

Stripe is a product system. Payments, billing, subscriptions, fraud detection—each can be used independently or together. The integration points are stable.

The iPhone is a product system. Hardware, software, and services—each evolves independently but works together through defined interfaces.

The Full Framework

The complete product systems analysis covers four case studies (Swiss Army Knife, LEGO, Milwaukee Tools, software platforms), the five criteria for evaluating system health, and patterns for migrating from monoliths to systems.

Read the full Product Systems analysis →

---

You don't build products for today's customers. You build systems for tomorrow's problems—using components designed to recombine.