Product Line System Archetype

Platform-Lever Type	Platform-Lever Example	Leverage Source
Production Asset	A chemical reactor, paper-making machine, just-in-time automation	Scale or flexibility
Hardware Design	A computer motherboard, a system’s core controller	Design reuse
Service System	An automated bank teller, an automated car wash	Automation, speed
Software Systems	A software operating system, Integrated application software	Versatility within the intended domain
Proprietary Formula	A unique pharmaceutical, molecular structure, formula, complex system	Uniqueness
Embedded Infrastructure	An optical fiber network, social network	Connectivity
Modular Systems	A roofing system, a closet connection system,  integrated automation equipment	Adaptability in use, multiple uses
Algorithms, Artificial Intelligence, and Machine Learning	Bank loan screening models, search engines, voice recognition	Rules, judgment, analysis,  decision acceleration, understanding
Connected Integration (IoT)	Intelligent and integrated HVAC (heating, ventilation, and air-conditioning) controls	The data structure, stack, queues
Blockchain	An NFT that assigns certification to a tangible or intangible product or object.	Scale and meta transfer
Hybrid and Combination	An 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)

	Orientation					Platform-Levers
Code	Offering Type	Code	Customer Set	PL Count	Code	# 1Plat Lev	# 2Plat Lev	# 3Plat Lev
OT1	Tangible	B2	B2B	up to 3	PA	Production Asset
OT2	Service	CG	Cons		TD	Tangible Design
OT3	Combination	M	Combination		SV	Service System
OT4	Unknown	U	Unknown | Unsure		SS	Software Systems
					PF	Proprietary Formula
					EI	Embedded Infrastructure
					MS	Modular Systems
					AI	Algorithms, Artificial Intelligence, and Machine Learning
					CI	Connected Integration (IoT)
					BL	Blockchain
					HY	Hybrid and Combination

Table 3 Market Segments and Technology Building Block Readiness

Initiative	Market Segments-Noun	Market Segments-Verb	Technology	Competency
Status	Noun Segments	Verb Segment	Technology Readiness	Skill Competency
Conceptual | Forming	N4=Well understood	V4=Well understood	TR4=Fully Ready	SC4= Fully Capable
Testing Validation	N3=Somewhat understood	V3=Somewhat understood	TR3=Nearly Ready	SC3=Some Improvement Needed
Existing - Incremental Advancement	N2=Somewhat Unknown	V2= Unknown	TR2=More Needed	SC2=More Needed
Existing - Next Generation	N1=Unknown	V1=Unknown	TR1=Much More Needed	SC1=Much more is needed
Existing - Pivoting
Unknown | Unsure | Unclear