Product Line System Archetype

A PLaaS archetype is the “first form” or basic build of a product line system. “End-form” systems lay out the details of the product line system by adding all parts and forces.

The archetype is anchored by a platform-lever (or its absence.) Teams then build-out or detail the system using other parts and employing other forces. The different PLaaS platform-lever types create the foundation for various PLaaS Archetypes. See TABLE 1:

Platform-Lever TypePlatform-Lever ExampleLeverage Source
Production AssetA chemical reactor, paper-making machine, just-in-time automationScale or flexibility
Hardware DesignA computer motherboard, a system’s core controllerDesign reuse
Service SystemAn automated bank teller, an automated car washAutomation, speed
Software SystemsA software operating system, Integrated application softwareVersatility within the intended domain
Proprietary FormulaA unique pharmaceutical, molecular structure, formula, complex systemUniqueness
Embedded InfrastructureAn optical fiber network, social networkConnectivity
Modular SystemsA roofing system, a closet connection system,  integrated automation equipmentAdaptability in use, multiple uses
Algorithms, Artificial Intelligence, and Machine LearningBank loan screening models, search engines, voice recognitionRules, judgment, analysis,  decision acceleration, understanding
Connected Integration (IoT)Intelligent and integrated HVAC (heating, ventilation, and air-conditioning) controlsThe data structure, stack, queues
BlockchainAn NFT that assigns certification to a tangible or intangible product or object.Scale and meta transfer
Hybrid and CombinationAn automotive assembly (with engine and frames as separate platform-levers)Multiple

In the product line system, platform-levers are critical parts that deliver significantly more bang-for-the-buck (leverage) than other parts. Organization drive performance by focusing intensely on this limited set of parts.  But too many focal points within a single product line will diminish the intensity of focus on each platform-lever. The requisite of “intense” focus sets up a PLaaS principle. Teams should try to keep the platform-lever count to three or fewer when creating a new product line and to fewer than seven for large existing lines.

Platform-Levers and Product Line Systems

Throughout the industrial revolution, the production plant or production asset was a company’s primary platform-lever. Businesses gained leverage by scaling production and lowering per unit product costs. The scale then enables a lower selling price and higher profit margin.

Next, businesses learned to create design platform-levers as characterized by Henry Ford’s Model T automobile. Interestingly, Ford coupled the design platform-lever with its production asset platform-levers. The platform-lever design grew increasingly important as businesses learned the platform-lever and the product were not the same. Separating the platform-levers from products enabled companies to add unique modules to the design platform-lever to give different products unique features. No longer did one platform lever deliver only one product to satisfy all customer needs.

In the second half of the twentieth century, companies learned how to combine or matrix multiple platform-levers to create an array of products. Keeping with the automobile example, you’ll see powertrain (engines and transmissions) platform-levers coupled to chassis platform-levers as an example. Both are design-type platform-levers.

The back-end of the twentieth century and the beginning of the next introduced software and the internet to the platform-lever tool bag.  This advancement enabled many platform combination and allowed external forces (third party buyers and sellers, and user and contributors) to drive enormous power to the product line. It was this platform-lever evolution that forced businesses to rethink business models and chain-link business strategies.

Intense Focus

It’s important to see that nearly any technology building block or module may be a platform-lever. However, all potential platform-levers don’t deliver the same leverage. Companies must determine what is and isn’t a platform-lever for their product line. It’s a strategic choice, not a given.  The problem with declaring all building blocks to be platform-levers is the loss of intense focus.

Once a company makes a choice, they gain an intense focus through organizational structure, dedicated roles, processes, and support systems and practices. It is this intense focus that raises the building block or module to a platform-lever status in the product line strategy. And from that point forward, each platform-lever will be a critical part that delivers a vital force in a product line system.

Morphing and Evolving

Platform-levers types and their characteristics are dynamic and evolving. Expect today’s list to expand as companies apply creative and strategic thinking to forming and using Platform-Levers. There are many possibilities. Yet recognize the notion or theory of a new Platform is of little value until a company employs it and it works successfully.

We also see platform-levers combinations growing tremendously as a product line’s empowering core. For example, consider how a company may choose to combine a design platform-lever with a machine learning (self-evolving algorithm) platform-lever. You may be surprised to see Apple’s M1 CPU has set the stage for this strategic move. Although, not yet employed to  its fullest, the M1 chip (a design platform lever) has AI-specific processing elements embedded in it. Expect ML to first contribute to the  computer line as a building block. In the M chip’s future generation, though. I’d expect OS and ML to integrate seamlessly.

Archetype Breakdown and Codification

The product line systems archetype is the basic or core “first form” of the platform-lever combination.

Products, services, and combinations characterize a high-level grouping of PLaaS archetypes. This divide is much like you’d see for a business model. But you’ll see the PLaaS archetype goes deeper into the product line as a system. The PLaaS archetype will designate if the Product Line system beginning state will have one or multiple platform levers and the platform lever types employed.

The PLaaS beginning state matters a great deal. Consider an existing refrigerator line with a core design platform-lever. You’ll find adding new Platform-lever types to a current system is fraught with challenges because the company didn’t design the original system with the new PLaaS in mind. The integration can be kludgy, and data-generating sensors become an afterthought. It might work as a proof of concept, but it’s unlikely to be a great product.

Codifying Archetypes

The archetype sets the beginning or starting-point form of a product line. It is not a product line’s  detailed build out. The build out is better captured and communicate through system diagrams and roadmaps.

How you describe a PLaaS archetype will reflect your vantage point toward the system. Every function within a company has a unique perspective on a product line and will describe it differently.  And customers see the system differently than do competitors, plus both will  be different from an internal view of a product line system.

Laying out PLaaS archetype codification is like designating the DNA of a product line. It can look complicated to many but it is also helpful once you learn the code.  And like DNA, the each archetype can mutate into unexpected variants.

I divide PLaaS Archetypes into two levels. The first is the core orientation (see Table 2) and the second is the advancement orientation (see Table 3). Each level contains defining elements.

Table 2: Orientation and Platform-Levers (up to three during initial product line build stage)



CodeOffering TypeCodeCustomer SetPL
Code# 1Plat Lev# 2Plat Lev# 3Plat Lev
OT1TangibleB2B2Bup to 3PAProduction Asset
OT2ServiceCGConsTDTangible Design
OT3CombinationMCombinationSVService System
OT4UnknownUUnknown | UnsureSSSoftware Systems
PFProprietary Formula
EIEmbedded Infrastructure
MSModular Systems
AIAlgorithms, Artificial Intelligence,
and Machine Learning
CIConnected Integration (IoT)
HYHybrid and Combination

Table 3 Market Segments and Technology Building Block Readiness


Market Segments-Noun

Market Segments-Verb




Noun Segments

Verb Segment

Technology Readiness

Skill Competency

Conceptual | FormingN4=Well understoodV4=Well understoodTR4=Fully ReadySC4= Fully Capable
Testing ValidationN3=Somewhat understoodV3=Somewhat understoodTR3=Nearly ReadySC3=Some Improvement Needed
Existing - Incremental AdvancementN2=Somewhat UnknownV2= UnknownTR2=More NeededSC2=More Needed
Existing - Next GenerationN1=UnknownV1=UnknownTR1=Much More NeededSC1=Much more is needed
Existing - Pivoting
Unknown | Unsure | Unclear