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 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
|
|
|
|
|
---|---|---|---|---|
|
|
|
|
|
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 |