Why is SpaceX more agile and successful than NASA at launching new projects?
Why does Tesla invest in R&D only to open out the patents it acquires?
The answers to all these questions lies in a new system of solutioning which runs counter to industrial manufacturing and product development.
Open source software movements have leveraged similar ideas over the past three decades but we’re now at a point where these principles can be applied to innovation in any industry.
NASA vs SpaceX
NASA’s legacy model of space exploration relies on monolithic projects. Every project involves highly specific decisions and investments which contribute towards a one-off rocket launch.
This standalone project approach is highly inefficient - components are not reusable or configurable for application to future projects. Development times are longer in the absence of reusable work. Investments, which are largely project-specific, cannot be amortised across multiple initiatives. Because components are not leveraged across projects, there is a lack of continuity in NASA's space exploration efforts. Each mission starts ground up, leading to inefficiencies and delays in the development process.
In contrast, SpaceX takes a Building Blocks approach to space exploration.
As I explain in The Building Blocks Thesis Volume One:
Solutions are often consumed as bundles of value. For instance, a primary school student consumes education as a bundle comprising textbooks, teacher-delivered training, self-administered testing etc.
A building blocks approach unbundles a solution bundle into its fundamental constituents - in the above example, textbooks, teacher-delivered training, self-administered testing etc. would serve as individual building blocks. Building blocks may be combined and recombined to create a wide scope of end solutions, each solution leveraging common building blocks.
This is the approach employed by SpaceX - as also an entire emerging private space exploration industry.
It reimagines space exploration as a set of modular building blocks, which may be cross-leveraged and reused. Investments are no longer project-specific but can generate returns across projects. Using reusable building blocks, SpaceX has succeeded in cutting costs to orbit by a factor of 18 and attracting industry-wide inflow of investments into this space.
Building blocks can be recombined to create entirely new systems - as SpaceX does across projects.
As firms adopt a building blocks approach, a flywheel effect takes hold. Take SpaceX as an example. The larger the universe of building blocks, the more diverse projects it can support, leading to more launches. With every project, new building blocks get created and existing ones get configured further.
Most importantly, investors are de-risked. They are no longer investing in all-or-nothing projects. They are investing in a project execution framework supported by an ever-growing library of building blocks. Regardless of the outcome of a specific project, returns on the overall portfolio of projects improves over time.
As I summarise in the thesis:
Digital building blocks enable solution design at ecosystem scale. A digital building block leverages digital technologies, enabling greater flexibility in solution design. Digital building blocks are autonomous and hence perform specific tasks and functions independently. But by defining standards and specifications, these building blocks may be recombined towards solution design allowing interoperability between building blocks as well as interoperability between higher end solutions designed using these building blocks.
Effectively, digital building blocks enable a ‘system of solutions’ that can plug-and-play across each other, enabling a vast and seemingly unconnected ecosystem of solution creators to more effectively coordinate their efforts towards solving large-scale problems through diverse context-rich solutions.
Getting building blocks right
This is not just about space exploration. A building blocks approach may be pursued in any domain.
The key to winning with a building blocks approach is designing them for high reusability. This is achieved by ensuring that these building blocks are not specific to a solution but are generic enough to be readily used across solutions.
As I explain in The Building Blocks Thesis Volume Two:
To design building blocks, we consider the universe of possible solutions and consider unbundling and re-bundling across three vectors.
First, we identify elements that need to be context-agnostic, and build them as building blocks which may be re-bundled in new contexts.
Next, we identify solution elements which are governance-agnostic, and build them as building blocks which may be re-bundled ovel governance paradigms.
Finally, we identify solution elements which are actor-agnostic, and build them as building blocks which may be re-bundled by new actors, while being sensitive to the rights, reputation, capabilities, habits, and preferences of these individual actors.
The more non-solution-specific (generic/agnostic) the building block, the more reusable it is across solutions, domains, geographies, and actors.
Take financial services as an example. If access to credit were to be solved as a problem, a building block for determining credit worthiness should be:
a) Context-agnostic: It should be usable in all contexts, whether providing BNPL credit at the point of checkout or lending school loans.
b) Governance-agnostic: It should be usable in new geographies with new regulations.
c) Actor-agnostic: It should be usable by all types of lenders, whether established or emerging.
This article is based on the Building Blocks thesis. You can get a copy of the entire thesis at the link below.
In summary, building blocks should have three key characteristics:
They are usable as a component across multiple solutions,
They can be combined with existing solutions to create new solution bundles, and
Builders can benefit from an ever-increasing library of building blocks that all adhere to common standards and specifications.
Playing full stack business games
Building blocks eventually stack up. This is where things get very interesting.
Imagine starting with a rocket system and unbundling it into a building block, say, to manage propulsion. When the next (or parallel) rocket system project starts, that building block is now available to be used for these new projects.
Designers working on these new projects have one of three options:
They can use the building block as-is because, well, it fits their requirement perfectly.
They can make it more specific by configuring it to include a specific new capability to better solve for a narrower context (e.g. to handle propulsion variables under very specific temperature and pressure conditions)
They can make it more abstract by isolating a specific capability within it and making it more generalisable across wider contexts
In both options 2 and 3 above, the rocket system designers have created a new building block for the ever-growing library of building blocks, reducing solutioning time for future projects that encounter these flavours of the problem.
Eventually, we end up with a stack of building blocks over time, where blocks at lower layers are more abstract and the ones at higher layers are increasingly more specific.
From solution stacks to industry stacks
SpaceX’s building blocks approach to solution design is representative of a larger shift playing out across industries.
SpaceX creates a solution stack which can be used to improve its solutioning across multiple projects.
But across the economy, we’re increasingly seeing the rise of industry stacks as well.
Whether at the level of projects - as in the SpaceX example - or at the abstraction of entire industries, digital technologies reduce the cost of coordinating and aligning between different activities (also called transaction costs) allowing these activities to be performed independently by specialized players.
Industry stacks emerge when vertically integrated firms starts to unbundle. This gives rise to new specialised competitors – agile and innovative players that focus on specific tasks in the value chain.
These specialized competitors do not integrate across the value chain and hence need to plug-and-play across other players.
As I explain in The Emerging Financial Service Stack:
This unbundling of the vertically integrated industry architecture creates a more modular, layered stack where firms at every layer specialise in a particular value-creating activity.
Multiple competing firms can take up positions that were previously occupied by a single firm, thus driving down margins and expanding consumer choice.
They achieve this by opening out internal capabilities, often as APIs.
APIs and other open capabilities are the building blocks for industry-wide solution design.
The emergence of industry stacks delivers some of the benefits of building blocks at industry scale. New solutions can be created through recombining these capabilities across the industry, and across industry boundaries.
As I explain in The lego blocks of healthcare:
Firms can specialize and can recombine towards new business models. New vertical integration can be much more selective. Data can enable new forms of horizontal integration where a single firm may capture market access (e.g. Amazon Marketplace or Google Search) or set the standard for entire industries (e.g. Google’s SEO, Chromium Engine, Android, and others).
Building new industries ground up
How do you create the conditions for large scale solutioning?
As SpaceX illustrates above, you:
Work backwards from the universe of end solutions
Create the building blocks required across the solutions.
Engage a growing number of teams to keep leveraging the ‘stack’ of building blocks and contributing back to it in the course of solution design.
How do you create an industry ground up?
You apply the same approach at industry scale.
You build out a vertically integrated organization to create a proof-of-concept for the new industry.
You commoditize and open out key capabilities across the value chain as building blocks, which the rest of the industry can use.
You retain other capabilities which are complements to these opened-out building blocks and demand for which will increase as uptake of the building blocks that have been opened out increases.
Tesla playing full stack games
Much like SpaceX used the first approach above at solution scale, Tesla has been applying the second approach at industry scale.
In 2014, Tesla made all its patents public. Elon Musk was thinking full stack. By setting some of the basic building blocks free (and by accelerating creation of higher level building blocks), Musk wants to have the entire industry work on the problem.
How does this help Tesla?
Tesla is in the business of selling cars. Battery tech and charging infrastructure are complements to cars. The more these complements proliferate, the greater the possibility to move value capture back to the cars.
As the barriers to setting up charging stations reduce, more suppliers can build and install them, pushing prices further downward. The greater the advances in battery tech and the more dense the charging infrastructure, the longer distances EVs cover and the greater performance advantage gained vs traditional automobiles.
Here’s Elon Musk using standard distractionary storytelling about his lawsuit-hating altruism to essentially say they have no other way of playing except by playing full stack:
Full stack games
Here’s how you play full stack games to build new industries from scratch.
Think of your industry as a stack of capabilities.
Try to identify which capabilities are bottlenecks to industry performance today.
Frame a clear point of view on which capabilities you want to compete on.
Go ahead and commoditize the other capabilities by providing industry-wide building blocks.
Very cool. We have the same thesis at sarvam.ai, building the full stack for AI in india. And we see this kind of cross modularity happening already.
Great one...