Big Picture DevOps through the Ofmos Lens
“The Grid. A digital frontier. I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I’d never see. And then, one day… (You got in.) …That’s right, man. I got in.”
Note: For a higher visibility of the novel concepts and frameworks, smaller sections of this post have been excerpted and published separately on the Ofmos Blog, enhanced with additional images and illustrations, as:
Header image: A prototype of a DevOps scenario layer for the board of the simulation game OFMOS, further detailed in the last section of the post.
Contents:
IN A NUTSHELL
THE DEVOPS PROMISE
SOME HISTORY AND CONTEXT
THE BASICS
Sidebar 1: The Scrappy Manager’s Guide to DevOps
THE OFMOS LENS
THE BIG PICTURE ACTIONS
SOFTWARE PRODUCTS AND THE CONCEPT OF PLATFORM (also posted separately as an excerpt)
Sidebar 2: Commoditization — Gravity of the Business World
Sidebar 3: The One-Need Theory of Behavior
Sidebar 4: Generic Platforms in the Product Context (also posted separately as an excerpt)
A NEED-BASED PERSPECTIVE ON INCREASING RETURNS (also posted separately as an excerpt)
Sidebar 5: The Postulates of the Ofmos Theory
DEVOPS — A POWERFUL SCENARIO LAYER FOR THE SIMULATION GAME OFMOS (also posted separately as an excerpt)
1. In a Nutshell
A key attribute of the simulation Ofmos — stemming from the underlying ofmos theory and the associated model — is its adaptability to an unlimited number of industry scenarios. Players can compete against each other by running companies that make tangible products, like cars and robots. Or, they can choose to go in the opposite direction and manage portfolios of intangible offerings, like software tools.
Among those harder-to-define offerings, DevOps stands out as one of the most exciting business areas to consider as an Ofmos scenario layer for the following three key reasons:
With a history of little over 10 years and still highly dynamic, the business space continues to quickly evolve right in front of our eyes. That means that a larger share of the conversation at the (game) table could be forward looking, with predictions that can then be verified against the real world in the immediate future.
There is a unique duality to this particular scenario. On the one hand, players can compete in a straight-forward way as leaders of their DevOps-providing companies. On the other hand, the same scenario can be used to support cases and conversations about other products that are or rely heavily on software. And that is because, with more products growing increasingly defined by the software that runs on them, we can see the DevOps solutions that a company employs as a direct determinant of the nature of its products.
Finally, and with significant implications for the broader business knowledge universe, DevOps offers a new perspective on why software products seem to defy some of the basic business dynamics that clearly apply to the tangible, manufactured products. As we look at DevOps through the Ofmos lens, the “increasing returns” phenomenon might be a simple matter of how we define these products and how the needs behind them are interrelated.
2. The DevOps Promise
This is arguably one of the youngest and most dynamic business spaces out there. As the label suggests, DevOps is all about bringing together a company’s software development team (“Dev”) and its IT operations team (“Ops”) to automate and deliver more agile solutions to the customers. In their 2017 Boston Consulting Group article “Leaner, Faster, and Better with DevOps,” Hanno Ketterer and Christian Schmid articulate three core benefits or promises:
FASTER DELIVERY / (Up to 90%) Reduction in time to market
GREATER EFFICIENCY / (Up to 25%) Less time spent on non-value-creating work
BETTER QUALITY / (Up to 70%) Lower software failure rate
Given the high potential for performance improvement (Note that the numbers from the BCG article were based on data from 2016!), it is clear that most professionals will have to eventually acquire, at the very least, a general understanding of this soon-to-be-ubiquitous practice and business area.
3. Some History and Context
While the DevOps category emerged around 2008 and is widely attributed to Patrick Debois (see the origin story in Fredric Paul’s 2014 New Relic blog post “The Incredible True Story of How DevOps Got Its Name”), the concept emerged naturally from the ongoing quest for agility in the business world. The same motivations that led to Toyota’s famous “lean manufacturing” practices (popularly known as “just-in-time”) several decades earlier have been and remain at play here. Which is why DevOps will only increase in visibility.
Famous statements such as “SOFTWARE IS EATING THE WORLD” (stated by Marc Andreessen, Co-Founder of Andreessen Horowitz and Netscape, in 2011) and “EVERY COMPANY IS A SOFTWARE COMPANY” (stated by Satya Nadella, CEO of Microsoft, in 2018) are distilled expressions of this movement, which is naturally driven by an all-encompassing transition to digital.
4. The Basics
To understand DevOps, it is important to start with the stages of the software life cycle. While some companies use different conventions, I find the eight stages defined in the BCG article mentioned above (and illustrated in the image below) to be very clear — Development (“Dev”): PLAN, CODE, BUILD, TEST; and IT Operations (“Ops”): DEPLOY, RELEASE, OPERATE, MONITOR. And they are the key activities or functions performed by a company bringing software (and the subsequent software updates) to market.
Now, if you think of this sequence of steps as an assembly line, it is easy to see why the overarching aspirations of DevOps are faster delivery, greater efficiency, and better quality. Tool and service providers might look at these benefits narrowly at the software life cycle stage level, where the needs are apparent (i.e., visible, easier to articulate, directly-addressable). Or they might look at them broadly over multiple stages, where the value provided to the customer is higher.
[SIDEBAR 1> THE SCRAPPY MANAGER’S GUIDE TO DEVOPS
For additional details on the benefits of DevOps, my 2020 12-slide presentation “The Scrappy Manager's Guide to DevOps” brings together several executive-level insights from the management consultancies Boston Consulting Group and McKinsey & Company. The brief document can also be useful to those tool and service providers who are in the process of crafting their top-down narratives and pitches. <SIDEBAR 1]
With that in mind, it then becomes further obvious that, in striving toward those three goals, integration and automation along the software life cycle is the way to go. And that is basically how the industry has been evolving throughout its decade-long history — from point solutions toward end-to-end integration and automation. Case in point, in his recent August 2021 GitLab blog post “Welcome to the DevOps Platform era,” the company’s Co-Founder and CEO Sid Sijbrandij identifies four evolutionary phases:
Phase 1 - SILOED DEVOPS / “each department or team built or purchased their own tools in isolation”
Phase 2 - FRAGMENTED DEVOPS / “organizations standardized on the same set of tools across the organization […] but each stage was still siloed from each other”
Phase 3 - DIY DEVOPS / “organizations that tried to remedy this by manually integrating their DevOps point solutions together reached the third phase”
Phase 4 - THE DEVOPS PLATFORM / “a single application with one user interface and a unified data store”
GitLab’s visual representation of a DevOps platform (see image below) uses its own convention for the stages of the software life cycle and follows the traditional “infinity loop” layout — a staple of the industry, for better or for worse — while adding the two end-to-end functions Manage and Secure.
5. The Ofmos Lens
To understand something at its highest level, it is important to use a perspective that captures the dynamics at that scale effectively and in the most efficient way. For example, you don’t have to analyze individual cells to understand human behavior. Following that same rationale then, to understand DevOps as an industry evolving over time, it is practical to use a LANGUAGE OF THE BIG PICTURE such as the ofmos theory.
The ofmos theory and its model shows companies and economies as complex systems of ofmos (short for offering-market cosmos), which are abstract business worlds defined by a product and a set of customers with the same need-addressing behavior relative to that product. These unique and irreducible business worlds allow us to see products and their evolution over time in a more predictable way, as they are mapped (see image below) relative to:
MARGINAL COMPLEXITY (x-axis) / How much work and resources (i.e., product managers, engineers) go into bringing to market an additional copy of the product? This coordinate is a measure of the process’ complexity, reflecting the company’s internal environment as it relates to the product and market.
PERCEIVED VALUE (y-axis) / What is the product’s subjectively-perceived value to the customers inside the offering-market cosmos? This coordinate is a measure of the product’s importance relative to the customers’ needs, reflecting the company’s external environment as it relates to the product and market. (Note that because of the way an ofmos is defined, the numeric value of this coordinate is approximately the same for all customers. That, in turn, allows us to view this set of customers as a single entity with needs and a capacity to learn.)
5.a. The Big Picture Actions
The July 2021 Ofmos Universe newsletter “The 6+1 'Big Picture' Actions in Business” shows that the high-level dynamics that characterize a product as part of an ofmos (offering-market cosmos) are relatively simple. For the purpose of our “big picture DevOps” discussion, we will focus on only three of the 6+1 ‘big picture’ actions:
COMMODITIZATION (Action 2 in the excerpted image below) / Over time and with additional units of a product continuing to be sold, knowledge associated with that product (i.e., functionality, user experience, development) naturally spreads throughout the marketplace. As that knowledge accumulates (i.e., collective learning), the product’s perceived value drops, also bringing down the profit margin of the offering-market cosmos. To fight this adverse occurrence and push the perceived value back up, providers strive to constantly improve the product’s functionality (i.e., new features, new generations), which also adds complexity.
However, these efforts of incremental innovation are no match for the ongoing pressure generated by the natural accumulation of knowledge in the marketplace. Commoditization — the gravitational force of the business and economic world — acts upon all products over time.
And it is important to note that every product (that sells more than one unit) commoditizes. While we traditionally refer to the highly-commoditized products as commodities, the same underlying mechanism that transforms them into commodities — which is the accumulation of product-related knowledge in the marketplace — causes all products to lose some of their perceived value over time. They simply become more commoditized.
DOWNWARD INNOVATION (Action 3 in the excerpted image below) / As products commoditize over time, they also become increasingly more complex. Driven by the market dynamics (i.e., customers, competition) and typically enabled by the related technological advances, providers tend to quickly capitalize on the opportunity created by the commoditization of a product. With the existent functionality as a reference, they introduce a more affordable related product with a lower relative functionality and a lower relative perceived value.
UPWARD INNOVATION (Action 4 in the excerpted image below) / Striving to capture more opportunities at the high-end of the market as well as additional business, providers also tend to use the functionality of an existent product as reference to introduce a more expensive related product with a higher relative functionality and a higher perceived value.
5.b. Software Products and the Concept of Platform
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 2> 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 2]
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 3> 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 my 2007 RedefinindStrategy.com 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 3]
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: “platform: 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 4> GENERIC PLATFORMS IN THE PRODUCT CONTEXT (also posted separately as an excerpt, enhanced with 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 4]
5.c. A Need-Based Perspective on Increasing Returns
Hi-tech products, and particularly software, have long been associated with an anomalous behavior referred to as “increasing returns” (as opposed to “diminishing returns,” where growth slows down over time and the profit margins drop). In his 2016 Fast Company article “A Short History of the Most Important Economic Theory in Tech,” Rick Tetzeli observes that “the theory of increasing returns is as important as ever: It’s at the heart of the success of companies such as Google, Facebook, Uber, Amazon, and Airbnb.”
W. Brian Arthur, who popularized the concept with his 1996 Harvard Business Review article “Increasing Returns and the New World of Business,” describes increasing returns as ”mechanisms of positive feedback that operate — within markets, businesses, and industries — to reinforce that which gains success or aggravate that which suffers loss. Increasing returns generate not equilibrium but instability: If a product or a company or a technology — one of many competing in a market — gets ahead by chance or clever strategy, increasing returns can magnify this advantage, and the product or company or technology can go on to lock in the market. More than causing products to become standards, increasing returns cause businesses to work differently, and they stand many of our notions of how business operates on their head.”
But how can that be? Ofmos theory tells us that every product commoditizes over time. Simply put, every product loses some of its perceived value relative to a set of customers with the same product-associated behavior, as the product knowledge accumulates within that business space (i.e., offering-market cosmos or, short, ofmos) over time. Does the concept of increasing returns imply that some products defy “business Gravity”? Or is that just an illusion?
[SIDEBAR 5> THE POSTULATES OF THE OFMOS THEORY
Developed to provide an explanation of a particular aspect of the natural world, a theory typically rests on a set of fundamental assumptions that are accepted to be correct or true without the need of proof. In mathematics, these assumptions are called “postulates” (i.e., Merriam-Webster Dictionary: “postulate: a hypothesis advanced as an essential presupposition, condition, or premise of a train of reasoning”) and, for illustrative purposes, I will use the same term here. If nature does not agree with the postulates or the theory, they might need to be revisited.
In my 2018 RedefiningStrategy.com article “A Natural Theory of Needs and Value,” I describe the POSTULATES OF THE OFMOS THEORY, as they were first articulated in the original 2007 RedefiningStrategy.com article “A Business-Relevant View of Human Nature:”
All living things strive to perceive the composition of their environment.
All living things strive to make the most out of a given amount of resources, in a given moment.
All living things strive to remember the changes that occur within their environment.
These assumptions, through the theory built on them, give us the arrow of learning and, with it, the arrow of commoditization. In short, humans accumulate knowledge about something useful that they interact with inside a relatively closed system (i.e., a community), during a period of environmental stability. This learning and the associated collective learning gradually strips that useful something to its minimal functionality, thus reducing its perceived value (i.e., importance to the users). <SIDEBAR 5]
Let’s see. The Ofmos lens is showing us that, like the DevOps industry, all business spaces where providers address needs that are part of a customer process are likely to first evolve toward a platform offering. That means that the total market available to the providers at the beginning balloons first, as the number of needs served by the industry rapidly increases until the entire customer process is covered and an upper limit of a meaningful product integration is reached.
Borrowed from physicists, who use it to explain the expanding Universe, the “balloon analogy” (see image below) is an easy way to think how a faster-than-the-leader follower might fall further behind, when the space between them expands.
Indeed, from this perspective, it becomes apparent that an industry that centers around a multistep customer process goes through a first evolutionary stage characterized by increasing returns, which lasts until the entire customer process can be supported by a single product: a platform (see image below). At that point, the dynamics change and the industry enters a stage of diminishing returns, in which the market size stabilizes and a more traditional battle for market share ensues. The platform itself begins to commoditize.
Throughout the first phase, providers tend to develop their products and portfolios by adding new layers of functionality just like the layers of an onion around their initial offerings. This metaphor breaks down once the platform functionality is reached, however, and some managers and companies struggle. Throughout the second phase, a better metaphor is that of Picasso’s bull from his drawing study, shown in various levels of abstraction. Same core functionality, different add-on packages. Yet, finding the best way to navigate this evolving environment, which offers many possible strategic directions over time, is inherently difficult.
In his 2021 InfoWorld article “How Docker Broke in Half,” Scott Carey captures this struggle in the DevOps space with the dramatic story of the 10-year-old-company Docker, recently noting that, “the game-changing container company is a shell of its former self.” Quoted in the same piece, Google’s Kelsey Hightower observes that, “They put something out for free that nailed it, home run. They solved the whole problem and hit the ceiling of that problem: create an image, build it, store it somewhere, and then run it. What else is there to do?”
Something “unnatural” does appear to be at play here. And, to make things worse, Arthur’s characterization that, “more than causing products to become standards, increasing returns cause businesses to work differently,” seems to suggest that, instead of commoditizing, these products behave differently — a finding that, if true, would contradict our fundamental assumptions about human behavior. He even concludes the HBR article by saying that, “A new economics — one very different from that in the textbooks — now applies, and nowhere is this more true than in high technology.”
However, at a closer look, this apparent contradiction seems to stem from the way Arthur frames the products. In his original 1983 IIASA working paper “On Competing Technologies and Historical Small Events: The Dynamics of Choice under Increasing Returns,” he writes:
“Usually there are several ways to carry through any given economic purpose. We shall call these ‘ways’ (or methods) technologies and we will say that members of the set of technologies that can fulfill a particular purpose compete, if adoption of one technology by an economic agent tends to displace or preclude the adoption of another.”
“This use of technologies rather than goods as the objects of choice has a particular advantage. Where most goods show diminishing returns (in the form of increasing supply costs), very many technologies show increasing returns: often the more a technology is adopted, the more it is improved, and the greater its payoff.”
It is a looser, inward-looking (i.e., what are we building?) framing of the product that has been a key part of this body of work. In his 2013 Research Policy comment “Rerun the Tape of History and QWERTY always Wins — a Comment,” 30 years after his original article, Arthur uses various possible units of analysis or “objects of choice” interchangeably when talking about the concept, “Under increasing returns or decreasing costs, one product or technology or firm or standard or convention comes to dominate.”
This perspective, while consistent with the more practical view employed by providers and customers (i.e., as its functionality changes over time, an app remains largely perceived as the same product), could create some confusion — not only for those trying to understand the phenomenon, but also for the strategists in the field, who may inadvertently create the instability that Arthur has identified. Described by Theodore Levitt in his 1960 Harvard Business Review article “Marketing Myopia” as a case of losing sight of what customers really need, marketing myopia is likely to be more prevalent in these circumstances.
In the InfoWorld article mentioned above, Docker Founder and former CTO Solomon Hykes looks back and reflects, “I would have held off rushing to scale a commercial product and invested more in collecting insight from our community and building a team dedicated to understanding their commercial needs.”
Is this phenomenon an illusion, then?
Somewhat. The Ofmos lens shows that all products commoditize at a more detailed level — knowledge about the defining product accumulates inside an ofmos (offering-market cosmos), which causes the product’s perceived value to drop. At this level of analysis, increasing returns do not exist. It is only at a higher, coarse level that we see this phenomenon emerging. By aggregating needs and the corresponding products, we conflate together multiple business spaces, which leads to “unnatural” behaviors. In spite of their names, increasing returns and diminishing returns seem to be different categories of phenomena that are visible at different levels of granularity.
Nevertheless, furthering our understanding of increasing returns is important. Some 2,300 years ago, Aristotle observed that heavy objects fall faster than lighter ones — a rock falls faster than a feather. We now know that it is the air resistance that creates that illusion. Still, more insights into that “anomaly” eventually led to valuable contributions toward aviation and other useful areas. Similarly, by adding to our toolset a more nuanced, outward-looking (i.e., what needs are we addressing?) product framing, we could open a new chapter in our exploration of increasing returns, as it was shown here through the novel need-based perspective and the DevOps industry case.
6. DevOps — A Powerful Scenario Layer for the Simulation Game OFMOS
SECTION UNDER CONSTRUCTION. COMING SOON.
text
In closing, watch a lighthearted, demonstrative session of Ofmos Classic (with a DevOps scenario layer) that I played with my friend Leon Stigter, who has extensive DevOps experience and is currently Principal Product Manager at Lightbend, Inc. Then, get the free Print & Play version of the game and give it a try yourself.
And, as we like to say, Think Big & Good Luck!
