Software Products and the Concept of Platform
Note: This is an excerpt from the post “Big Picture DevOps through the Ofmos Lens” on the Ofmos Blog, enhanced here with additional images and illustrations. For a higher visibility of the novel concepts and frameworks, smaller section of this post have been further excerpted and published separately as “Generic Platforms in the Product Context” and “The 3D Product Model Canvas: Thinking and Strategizing in Volumes.”
Header image: Pablo Picasso, The Bull (Le Taureau), state XIV, 1946; via MoMA.
The high-level actions characterizing a product relative to a set of customers with the same product-related behavior — basically, the dynamics associated with an ofmos — are relatively simple. Nevertheless, because they are based on information (i.e., marginal complexity) and knowledge (i.e., perceived value), the simplicity of those dynamics depends on the clarity with which the product is framed over time.
Tangible, manufactured products are inherently easier to frame. For example, the short video from my 2018 Ofmos Universe blog post “A New Perspective on the Evolution of Porsche 911 (What Is Commoditization?)” animates the process of commoditization for a particular car model. In it, we see the car model’s generations as separate-yet-closely-related products, each evolving according to the dynamics described above.
[SIDEBAR> COMMODITIZATION — GRAVITY OF THE BUSINESS WORLD
Porsche 911 is, broadly speaking, an expensive high-performance car, which also makes it a great case for discussing and understanding the new perspective on the process of commoditization. As established in the previous section, all products (that sell two or more units in the same market) commoditize. In the above-referenced video, the xy-map is just a small section of the largest xy-map that would capture the entire economy, which makes the drop in perceived value appear visually quite dramatic. In actuality, the 911 has not become a commodity — it has simply become more commoditized. When Porsche 911 was launched in 1964, it quickly became one of the top contenders among the few sports cars out there. After six decades, however, the 911 has become one of the more accessible choices in a field that now includes supercars and hypercars. <SIDEBAR]
When it comes to intangible offerings, however, product framing tends to be more nuanced. And, with its software tools and the industry’s distinct evolutionary stages, DevOps provides not only a unique and exciting standalone case to discuss, but it also provides generalizable insights and more clarity for all harder-to-define offerings — particularly, for software.
To look at DevOps through the Ofmos lens — with the goal of understanding product framing and the ‘big picture’ dynamics of the industry as well as the broader software products context — we must start with the one-need theory of behavior, which is the foundational building block of the ofmos theory. The one-need theory is a novel perspective on needs and value, which tells us that all needs are generated through a process of aggregation-disaggregation (see image below), and are thus components of one subjective overarching need, generically named “successful existence.”
In the hierarchical tree of needs that results from the process of aggregation-disaggregation, the needs at any given level have a higher value (i.e., importance to the owner) than the needs immediately below. In the abstract example from the above animated GIF, need ABCD has a higher value than any of its component needs, as well as a slightly higher value than their sum, need A + need B + need C + need D. In other words, the higher the need, the higher the corresponding product’s perceived value.
[SIDEBAR> THE ONE-NEED THEORY OF BEHAVIOR
More details about the one-need theory of behavior are available in my 2018 RedefiningStrategy.com article “A Natural Theory of Needs and Value,” which is a revision of the 2007 article “A Business-Relevant View of Human Nature.” First articulated in 2002 to explain human behavior, as part of the ofmos theory, the one-need theory also provides an efficient way of describing organizational behavior and the high-level functionality of cognitive systems. The name “the one-theory of behavior” has been assigned to this body of work recently, in late 2021. <SIDEBAR]
It is easy to see then the stages of the software life cycle as the direct functional needs that DevOps tool providers strive to address. Further, with commoditization as an ongoing natural phenomenon, it becomes clear as to why the industry’s center of attraction migrates over time toward unified offerings that cover an increasing number of stages, where the value provided to the customer is higher. And that is how, enabled by the underlying technologies and in-step with their becoming available, providers eventually end up covering all stages in the software life cycle — at which point, the offering becomes a platform.
As described in the GitLab blog post referenced earlier, “The DevOps Platform is a single application with one user interface and a unified data store. It includes every stage of the DevOps lifecycle and brings together development, operations, and security teams. It allows these groups to collaboratively plan, build, secure, and deploy software. As a result, this improves businesses' velocity, efficiency, and security, allowing them to deliver software faster and at a lower cost.”
In line with the term’s literal meaning as something to stand on in order to perform a task (i.e., Merriam-Webster Dictionary: “a flat surface that is raised higher than the floor or ground and that people stand on when performing or speaking”), the concept of DevOps platform provides general guidance for the broader family of intangible products as well (see image below; slides excerpted from my Spring 2021 Stanford Continuing Studies course BUS 93 “Corporate Strategy at Scale: Emerging Thinking on How Companies and Economies Evolve”): a ‘customer process’ platform is an application that supports customers throughout the entire life cycle of a repeatable multistep process with a shared core functionality and the option to add customizable enhancements.
In other words, a ‘customer process’ platform must cover all stages in the life cycle of a customer’s process (think, journey from A to B, regardless of how the intermediate steps are being defined), addressing all customer stage-specific needs with an end-to-end-integrated core functionality that is available to all users at all times (think, assembly line, regardless of the levels of enhancement). Simply put, and with the one-need theory in mind, a ‘customer process’ platform is the product that directly addresses the highest-level customer need that expresses the highest-level goal of a customer process.
[SIDEBAR> GENERIC PLATFORMS IN THE PRODUCT CONTEXT
// This Sidebar has also been posted separately as an excerpt, enhanced with additional images and illustrations. //
While the word “platform” has been used in an abstract sense for a long time, in their 2008 Harvard Business School working paper “The Architecture of Platforms: A Unified View,” Carliss Y. Baldwin and C. Jason Woodard note that, “more recently, the concept of a platform has been developed by management scholars in three overlapping waves of research, respectively focused on products, technological systems and transactions.”
The HBS authors “argue that the fundamental architecture behind all platforms is essentially the same: namely, the system is partitioned into a set of ‘core’ components with low variety and a complementary set of ‘peripheral’ components with high variety. The low-variety components constitute the platform.“ Holding the same basic view, I propose a deeper view of the concept of platform in the product context.
Simply put, if you are bringing a product to market and are actively crafting the product strategy, what does platform mean to you? Why would you, generally, choose this strategy? And what are your options? Built around the customer needs — as understood through the one-need theory of behavior — and the matching product functionality requirements, the new perspective on the concept of platform provides valuable insights for strategists and researchers alike.
To begin, it is important to see the product as a collection of functional blocks that can be mapped inside a holistic, tree-dimensional space made up of all the “functionality requirements” volumes necessary for a product to be both functioning (i.e., technical viability) and addressing the customer needs (i.e., business viability). This space, inside which the product is being modeled as an assembly of functional parts that are placed in its various subdivisions, can be referred to as the 3D PRODUCT MODEL CANVAS.
// The word “canvas” is commonly used in business. Providing an easy metaphor for the process of defining a particular thing inside a general set of requirements (i.e., painting on canvas), it is part of the name of several product-focused frameworks (i.e., business model canvas, lean canvas, opportunity canvas, jobs-to-be-done canvas). The 3D Product Model Canvas is unique, however, as it captures both the functional blocks and the value creation flows that determine how these blocks are laid out — both essential elements in product strategy. Moreover, the 3D canvas can also be used to analyze and strategize at the product portfolio level, whether a company’s supporting architecture is monolithic or distributed (i.e., Web 3.0, Infrastructure as Code); thus providing a contemporary alternative to the decades-old concept of value chain, the original business model framework. //
// This broader use case of the 3D Product Model Canvas — which stems from the one-need theory of behavior, as it is built backward from the customer needs — suggests that the tool can also be used as a business modeling tool. Think, the 3D Business Model Canvas. In her 2002 Harvard Business Review article “Why Business Models Matter,” Joan Magretta finds that:
business models are “stories that explain how enterprises work,”
“a good business model begins with an insight into human motivations and ends in a rich stream of profits,” and
“all new business models are variations on the generic value chain underlying all businesses.”
In their 2021 Journal of Management Studies article “What Can Strategy Learn from the Business Model Approach,” Lyda S. Bigellow and Jay B. Barney “posit that ultimately the business model approach, given its emphasis on interdependencies and multi-lateral connections, may provide more insight to managers and entrepreneurs who are grappling with the complexity of an increasingly interdependent environment in which to compete.” //
I first shared this “3D product model canvas” idea in my 2012 presentation “Unlocking Innovation in Education through Meaningful Technology (A General Model for Ed-Tech),” in which I introduce a general three-dimensional model [general model = canvas] for modeling an ed-tech product, bringing together (a) the two-dimensional view of the customer-facing functionality and (b) the layered view of the architectural functionality. Even though the actual labeling of the architectural layers in this presentation is directly inspired by older structures (i.e., Web 2.0), the rationale for the 3D Product Model Canvas stands:
Holistically, the cube-shaped canvas should provide the outer boundaries for the entire product category that revolves around the customer process. Snapshots of any product in the category should be mappable inside it at any point in time, thus enabling strategic analyses and evolutionary roadmaps.
The canvas’ subdivisions should be framed around meaningful functionalities that stem from either customer needs or underlying architectural needs. They should be captured in MECE (mutually exclusive and collectively exhausting) lists and analyzed at the same level of granularity, providing inputs for competitive analyses and product strategy.
The layout of the subdivisions in the customer-facing layer should be dictated first-and-foremost by the flow of the customer process. (The presentation attempts to capture the additional, “tool scope” dimension and the data/information flow associated with it. And something interesting to be further investigated here is whether or not the customer-facing end-to-end functionalities tend to drift into the architectural layer underneath.)
The architectural layers should span the flow that stretches from raw data to useful information in the customer-facing layer.
To put it differently, the 3D Product Model Canvas captures and articulates the product functionality along the three main value creation flows, in a context where the customer benefits are the ends and the product is the means:
The Customer Value Creation Flow
The Organizational Value Creation Flow
The Architectural Value Creation Flow
// As mentioned, thinking in volumes is key here; and the world of car racing provides a simple-yet-powerful aid in that respect. For example, competitions like Formula 1 allow the participating teams to customize their cars — all within the boundaries set by the regulatory body, which aims to keep the field leveled. A major aerodynamic component, the rear wing, then, might only be constrained in terms of position and dimensions (width x height x depth). Inside that invisible box, each team develops its own unique solution. Different product models, same 3D canvas, and an easy way to switch to this way of thinking. //
From this 3D product model canvas for ed-tech, then, a general 3D product model canvas can be readily generated by simply replacing the student life cycle with a generic customer process life cycle (i.e., sequence of interrelated tasks). Point solutions or complex products, with monolithic or distributed architectures, can all be mapped and analyzed inside the 3D canvas.
The purpose of this cube-shaped functional representation of a product, which I simply call the 3D PRODUCT MODEL CANVAS, can be summarized by the two Herbert Simon quotes surfaced in the above-mentioned HBS paper: “Every problem-solving effort must begin with creating a representation for the problem” and “solving a problem simply means representing it so as to make the solution transparent.”
This structured approach to the customer needs and the corresponding product functionalities reveals where all major efficiencies (i.e., higher speed, shorter time) can be created. And it also reveals where the opportunities for creating economic lock-ins (i.e., monopolies) across and along the data/information flows are. As a result, it provides a clearer way of thinking about platforms in the product context: a basic unified set of functionalities that addresses all needs within a clearly-defined domain, allowing for further customer augmentation and offering economic lock-in to the provider.
// It is important to keep in mind that the 3D Product Model Canvas, like other cognitive frames, could play an important role not only in a company’s strategy-making process but also in its political environment. In her 2008 Organization Science article “Framing Contests: Strategy Making Under Uncertainty,” Sarah Kaplan explains that, “Frames are the means by which managers make sense of ambiguous information from their environments. Actors each had cognitive frames about the direction the market was taking and about what kinds of solutions would be appropriate. Where frames about a strategic choice were not congruent, actors engaged in highly political framing practices to make their frames resonate and to mobilize action in their favor. Those actors who most skillfully engaged in these practices shaped the frame that prevailed in the organization.” //
The 3D Product Model Canvas makes it is easy to see the value-generating flows and, with them, the three generic types of platforms in the software product and software product portfolio context. (Note that, even though tangible products cannot be integrated into a single product/app, the 3D canvas framework and the concept of platform can be used in those cases as well.) Simply put, this representation shows the three basic lock-in options that product providers can pursue:
‘CUSTOMER PROCESS’ PLATFORM is a product that provides end-to-end core functionality along the stages of a customer process. Both the DevOps Platform discussed in this post and the student-facing functionality in the above-mentioned General Ed-Tech Model are examples of process platforms. Also, the corporate value chain (i.e., the set of basic activities performed by a company to bring to market a valuable product) and the user-facing functionality of the multifaceted marketplace applications (i.e., Uber, Uber Eats) fall in this category.
‘ARCHITECTURAL LAYER’ PLATFORM is a product that provides edge-to-edge core functionality across an architectural layer, supporting the higher-level functionality within the architectural level above. A cloud database, which might include one or more architectural layers, is an example of this type of platform.
‘BUSINESS CORE’ PLATFORM is a product that provides front-to-back core functionality, comprising of both a core customer-need-addressing functionality and a core set of supporting functionalities that cuts across all architectural layers. In my 2014 LinkedIn blog post “Build Your Own Cognitive Computing Thingy,” I describe the 3R Model of a cognitive system with its three key functions: Range (of data), Relevance (of information), Recipe (of decision). It is a deep, front-to-back functionality that can explain, for example, Google’s approach to product portfolio. Unlike other companies, its shared core (i.e., data, algorithms) enables the company to easily enter and/or exit various knowledge-based product spaces (i.e., software apps).
The three generic platforms in the product context — a categorization based on the 3D Product Model Canvas and the one-need theory of behavior — are very much consistent with how platforms tend to be categorized from the customer perspective as well. In their 2019 McKinsey article “The Platform Play: How to Operate Like a Tech Company,” Oliver Bossert and Driek Desmet find that “a platform-based company will have 20 to 40 platforms, each big enough to provide an important and discrete service but small enough to be manageable. To simplify platform management, it helps to group them into three broad areas: customer journeys, business capabilities, and core IT capabilities.”
In short, then, the ‘customer process’ platform can be thought of as “journey as a service,” the ‘architectural layer’ platform can be thought of as “information technology as a service,” and the ‘business core’ platform can be thought of as “company as a service.”
From here, there is certainly more to be said and explored as to how a product provider might navigate these lock-in options over time. Are the three basic types of platform equivalent in terms of strategic impact? is there an evolutionary relationship between them? Can they be combined?
Further, are there any predetermined paths toward becoming an industry platform? In their 2008 MIT Sloan Management Review article “How Companies Become Platform Leaders,” Annabelle Gawer and Michael A. Cusumano note that “to have [industry] platform potential, however, research suggests that a product (or a technology or service) must satisfy two prerequisite conditions: (1) It should perform at least one essential function within what can be described as a ‘system of use’ or solve an essential technological problem within an industry, and (2) it should be easy to connect to or to build upon to expand the system of use as well as to allow new and even unintended end-uses.”
The three generic platforms in the product context and the 3D Product Model Canvas, on which they are based, offer a common language for customers, providers, and their partners to create new levels of business value. <SIDEBAR]
