Abstract

The topic of designing and developing extension platforms strategies around products is heavily underrepresented in the conversation around digital product strategies and design. While there’s a lot that has been said and done about building marketplaces much less has surfaced about ways that companies can adopt to build third-party ecosystems around some of their products in contrast with the evident strategic nature of the topic. The topic is central especially for b2b markets because we’re going through a moment of digitalization and transformation of industries as different as healthcare and diagnostics, mobility, construction, agriculture, energy, and more.

In these markets we come from a situation where have historically relied on legacy products, getting to the market mainly through sales rep-led business development, and complex contracting, and this has left us with markets where fragmentation is high, inertia dominates and debt is astounding. As these markets are ripe for transformation, for a brand to master the capability of building a convincingly legitimate ecosystem strategy, being able to enable and mobilize third parties (mainly Independent Software Vendors) can be a powerful strategic advantage and certainly a needle mover for the transformation of industrial markets.

In this piece we explain how platforms should increasingly rely on third parties to respond to joint customer needs, we explain the challenges of kicking off an extension strategy that involves third parties building complementary apps, with a focus on the UX and research challenges, product modularity, and organizational implications. In the end, we venture out to examine the impacts of no-code and AI on the challenge and we ponder how some radical innovations emerging from the web3 space might enable a transition towards protocol-enabled vs platform-centered modular software ecosystems. 

A quick recall: what is an Extensions platform strategy? 

In our article called Value Propositions in Business Ecosystems – Products, Marketplaces, Extensions we covered how to break down a digital product value proposition according to the three main vectors of value:

• the core product/service bundle, often a SaaS in digital products
• the marketplace of services and/or demand generation that can be built on top of it (or even as the core value proposition)
• the extensions platform strategy is responsible to integrate third parties around the product/service bundle with the aim of extending it with a set of plug-ins, templates, apps, or more generally compatible modules. 

To give you an overview of what we are talking about, let’s come back to the original piece:

“…the third key element of the value proposition that can be developed […] is that of so-called extension platforms. The term “extension platforms” is something we borrowed from Casey Winters.

In Winters’ framing, the evolution of a SaaS into an Extension Platform starts from what Winters calls an “integration platform”. The idea is simple: as you create a SaaS product (Winters’ analysis is essentially focused on SaaS) it’s ok to provide a core set of functionalities, but, in the long term it will become essential that you create the means, the context and the incentives for your product to connect and integrate with the other products that the customer is possibly using as a complement and extension of the features your product provides.”

Essentially, integrating different third parties to your products will help you deliver what Scott Brinker recently called on our podcast a “joint customer need”. The platform product becomes the core and its integrations (later extensions) complement and extend the use cases, allowing personalization. 

The landmark piece to understand why this is important is: “How to Eat an Elephant, One Atomic Concept at a Time” by Kevin Kwok: these wonderful graphics from Kwok explains how the ecosystem of partners, coupled with self-customization features that you’ve baked into the product can deliver almost infinite “nicheness” to the solution making it a “perfect” fit for everyone.

Therefore the first thing to underline is that building an extension platform strategy is about creating the condition for your product to become the pivotal piece around which third-party solutions and products – that your main customer is either already using or wanting to use – can be connected easily, thereby extending it.

Developing a successful extension platform strategy may have tremendous advantages, some tactical and some strategic. From the tactical perspective, such strategies can provide growth advantages from the very early stage, mainly related to customer acquisition and lock-in. Indeed a customer that is using a certain product may want to look for another area of its business and orient the choice based on the existing integration between the solution they are already using. On the other hand, if you successively achieve a pivotal position and your customer starts to use a complex set of integrations it will be much more difficult for them to migrate to another complex set of tools, and recreate the integrations in another setting. This will confer a substantial lock-in potential to your product.

On a more strategic level, developing such an approach can position your product as a “gravitational center” (in Brinker’s words) and help you become what Alex Rampell calls the “System of Record” (login to read the transcript) – the place where all the information is consolidated. 

Becoming such a pivotal point is, by the way, a rather gradual process and definitely not effortless, as it requires accruing a certain size and a certain attraction. Coming back to our piece:

“In Winters’ words, you start from “integrations” intended as somewhat costly, one-off processes to integrate other products’ user flows into yours, enhancing data and feature integration. Later you evolve your product stack towards being ready for “extensions”: extensions are supposed to be scalable and – on the contrary to integrations which require your direct intervention – extending should leave the third party in charge to use published and open interfaces to your product to integrate autonomously.”

In this passage – we refer to Casey Winters’ “Sequencing Business Models: So You Want To Be A Platform?” – which highlights how mature extensions platform strategies have to generate a value proposition for third parties (supply in the table below from Winters ) of not only retention but also acquisition, meaning that extension providers need to see the possibility of being featured as part of the ecosystem centered around your platform as a channel for the acquisition of new customers.

Such a powerful “magnet” is – quite clearly – hard to bootstrap. In his seminal talk on Platform Management, former Shopify VP of Platform Brandon Chu explains that “building the flywheel” is your responsibility as a platform owner.

In Chu’s words, the flywheel has three main pivots: developers, apps, and merchants (the core customer of Shopify, can be translated into any “key customers” of your product, they could be a restaurant for OpenTable, any business interested in Hubspot’s CRM…) and growth is driven through three core actions that are the key responsibility of the platform:

• Building app capabilities such as UI kits, APIs, data sources, and other elements;
• improving the “app store” and algorithms that can connect the merchant (key customer) and the third-party app providers (or plug-ins, templates, etc) at any moment (often keyword searches don’t work!)
• sustaining developer growth with things such as reports, insights, and even active research on areas of opportunity that you see emerging, where (joint) customer needs are unmet.

According to our initial research, a key aspect of becoming a good extension platform requires investing in creating trust with the developer ecosystem that has a need to effectively “build on you”. Both Chu’s presentation and our recent podcast with Brinker refer to trust-building elements such as:

• being transparent about ranking – Chu for example insists on making the metrics that impact the visibility of the apps on the app store transparent to the third-party developers
• invest in supporting the community by creating, for example, great documentation, or developer events
• most importantly, avoid enacting radical changes in the platform’s policy that can be destructive to the third-party business model and long-term success

Start by drinking your own champagne and product modularity

Our research on extendability is also telling us that – in becoming an extendable platform – massive implications exist from the perspective of both product portfolio and organizational focus.

First and foremost you must acknowledge that you can’t have a monolithic platform and a plethora of small extensions: instead, there needs to be continuity between product modularity and extensions. Hubspot’s case is extremely interesting. During the interview, Scott pointed out how Hubspot has embraced a posture of complementarity (and user freedom) when thinking about how its product offering and extensions create an integrated value proposition. According to him, the “hub” structure that characterizes Hubspot’s product family makes it easy for customers to adopt only part of its offering without requiring investing in the full suite of tools in order to obtain value. 

You can see how the Hubspot product itself is defined as a set of five hubs: Marketing, Sales, Customer Service, CMS, and Operations. This structure reduces the barrier to adoption and makes it more attractive for third parties. A third party can potentially build products that are partially complementary and partially “competitive” with a particular Hubspot hub, and – at the same time – Hubspot can more easily monetize customers that don’t necessarily want to invest in the whole Hubspot solution.

 

see how Hubspot helps you filter apps in relation to what product/plan you purchased

Why modularity

It’s important to understand that this need to embrace product modularity is not just a good go-to-market strategy for products and extensions platforms but rather a key driving force of modern-day markets. In the past, we’ve spoken at large about modularity as a background trend in current markets and at the same time, of the emergence of more prominent organizational models based on small team-powered small units, such as Haier’s Rendanheyi (or more generally Boundaryless’ 3EO Framework). The pattern we see emerging is that of companies intentionally building complex strategic portfolios and adopting clear product taxonomies internally. Being more aware of the modularity of your products, enacting common ways to look at the portfolio internally, defining what a component is (APIs, data products, infrastructure containers…) what a user-facing bundle is, the several levels of composability: all bodes well for you to be ready to connect with a third party ecosystem almost effortlessly. This is essentially what drove the tremendous success of Amazon after Bezos’ 2011 memo enforcing that units had to expose clear service interfaces. Once you enforce clear boundaries on internal units or products they become easily externalizable and, suddenly, your internal infrastructure for provisioning becomes a multi-billion dollar business (AWS), and your e-commerce platform can accept external category providers with the same interface as internal ones (evolving from Amazon to Amazon Marketplace). 

Indeed often these developer ecosystem initiatives start from inside with patterns and needs that are definitely common to open, third-party-focused ecosystems. In a presentation from a team at Shopify, one can see how the strategy was born first internally and then evolved externally. Scott himself told us that:

“…before you even think about the externalisation of a platform, and how you make it accessible to third-party developers, you have to bake this notion of extensibility reusability, standardisation, and modularization into the way you architect your products. We can say all the words we want about the strategies, but at the end of the day, this stuff actually lives on technical foundations.”

We’ve been kinda mind-blown when we discovered that – even beyond the technical layer – each of the hubs at Hubspot is strongly independent in strategy and runs its own P&L – a la 3EO. 

In a few words, envisioning building an extendable platform typically starts with:

• defining product modularity, taxonomy internally
• understanding your customer context and complex joint customer needs
• being strategic about what you want to build and what you want your ecosystem of partners to build
• empowering the single distinct products to be autonomous, as any third-party offering would be, with an organizational model that rewards autonomy

User Experience and extension platforms

Another implication of having to articulate your product as a platform featuring third parties integrations, is the need to consider the implications from the perspective of User Experience. There’s always a tradeoff between the level of control you want to exert and the level of freedom you want to provide to third parties.  Brandon Chu, who we mentioned earlier, highlights the tradeoff as a trust balance between the customer and the third parties. Indeed he asks the audience first what platform they would prefer as developers,  Google or Apple, and they predominantly side with Google (at the time BigG was even more permissive than today towards developers). Subsequently, when prompted to respond to the question from the perspective of users, most of them instead trust Apple more to protect them; this being a consequence of Apple’s generally more restrictive application development rules and vetting processes.

In the case of Hubspot, the situation is even more nuanced: as Brinker shared with us during the podcast interview, Hubspot offers different levels of integration to third parties: apps, workflow integrations, and data syncs; some simple others quite complex…see below how they are reflected in the app store menu.

Depending on the level of integration that the third party wants to achieve with Hubspot – ranging from a light one (data sync) up towards being featured as a quasi-native application, with a seamless UX that feels like “using the same product” – the level of control that Hubspot exerts on the UX varies accordingly.

We can generalize this framework as a way to think about the evolution between integrations and extensions: as you move up the ladder, you move from generic ontological compatibility (same concepts, same object-model…) through tighter integrations, such as what happens when you start to integrate at the API level, implying an integration happening as part of the workflow (and thus a certain level of coordination in the execution). 

Progressively, we get to an “app-level” integration that – for example – Shopify frames as some sort of “reverse APIs” pattern:

With an app extension, merchants interact with Shopify. Shopify relays information to your app that gets surfaced back to the merchant through your app extension in Shopify.

It’s rather clear that, in this case, the level of experience and workflow integration is substantial and the platform needs to exert a certain level of control to avoid misfunctions and brand impacts.

In the context of these evolutionary patterns, it appears clear how User Experience design and research practices must evolve towards a UX practice optimized for platforms and ecosystems. More in detail, UX and research will have to evolve to integrate both: a research approach that captures more of the need to integrate different products (more than optimize a single one) and, on the other hand, to be able to design open-ended user experience guidelines, that leave a blank space for third parties to introduce themselves in the workflows.

We assume this will increasingly work with platforms becoming minimally but strictly normative with things such as design systems, and workflow design paradigms and progressively and actively monitoring which ones emerge as the key applications in the ecosystem (the mostly used) but also actively seeking to spot where these integrations don’t actually work, leaving a hole in the customer experience, and actively fixing it by investing in deliberately collaborating with a partner.

Impacts of No-Code and Conversational programming

Talking to Scott about his experience also brought up another key element to investigate in this context: the effects that no-code frameworks will have. It’s easy to anticipate that, with the advent of no-code-based tools and models of integration, customers will be able to create personalized workflows and user experiences, rather than being limited to what one platform offers, making infinite niches of self-integrated products a realistic possibility.

Where will the limit of this evolution sit is difficult to say, but it will likely be dictated by the tradeoffs between: 

• the level of UX and the Total Cost of Ownership of the self-made integrations that no-code solutions will be able to provide 
• the uniqueness or nicheness of the workflow and the strategic nature of having a customized one 

In a way, after a couple of decades of software solutions migrating to the cloud en masse, it’s like we’re living the debate between make or buy again, but on steroids!  –  making things at the same time more complex and infinitely more interesting.

In this context, it’s key to consider speculations about the impacts of what Simon Wardley calls “conversational programming”: something that will enable us to actually speak to computers to obtain the software we need. According to Wardley: “We’re not quite there yet but we should be there soon.” 

The interesting thing about conversational programming as an evolution of serverless and other cloud-related elements is that – as Wardley explains – once you have an AI capable of understanding human input and mixing together existing modules not only will we be able to radically bring down the capital expenditures needed for a “make” of a solution, but also we’ll be able to quickly assess how the code workflows the AI generates actually performs from a financial or environmental perspective.

As Wardley explains: “Serverless has brought remarkable changes such as refactoring having financial value to the focus on financial visibility within code (including carbon cost of code)” and these changes are “unlikely to be lost in a conversational programming world”. According to him, what will matter in the new generation of conversational IDE (Integrated Development Environment) will be the “meta-data such as the cost per function and capital flow within an application whether carbon or dollar or yuan”.

All this paints a future where developing ad-hoc processes could be a matter of talking to an AI that will help us make conscious choices on the footprint of the technological solutions we decide to self-bundle: if this is the perspective, who owns the AI platform will be crucial.

Most of the platform-mediated user experience will be abstracted away and the capability of platforms to keep network effects-driven advantages alive will remain as the last man standing of platform advantages. 

Two major trends are now aimed at crushing these advantages: digital policymaking on one side (with initiatives such as UPI and ONDC in India) that aim at disintermediating network effects through public registries and the emergence of blockchain counterparts on the other hand, sometimes the two going hand in hand with digital policymaking being backed by genuinely distributed implementations. 

Even besides lacking a policy element some players in the web3 space are ambitious enough to aim at building what they call hyperstructures or, at least, minimally extractive “protocols” that can play the role of the platform. 

The intrinsic problems of having a centralized entity governing a complex ecosystem are clear and will become ever less tenable as we move more decisively into no-code/AI-based integration, where the plurality of modules becomes even more important. This trend won’t spare the blockchain space, as the recent acquisition of www.hal.xyz by Consensys testifies. 

The debate is open though around the capabilities of collective entities governed by what we usually call DAOs (Decentralized Autonomous Organizations) to govern such fast-evolving and complex institutions as an enabling platform protocol. We all know that committees don’t deliver enough innovation but the problems of achieving legitimacy as a platform and resisting asymmetric and unjustified value capture still prevails.

In a recent paper called Disambiguating Autonomy – Ceding Control in favor of Coordination in Cybernetic Organizing Michael Zargham and others provide an overview of how organizations can frame the debate around autonomy and coordination. According to the paper:

“Coordination amongst a group of individuals towards a shared purpose necessitates holding tension between Individual and Collective Autonomy. Individuals who are coordinating can be considered part of an organization. For “decentralized” organizations, an effective pattern is to associate Collective Autonomy with Strategic Autonomy, where the group sets goals, policies, and an initial social contract or constitution, and Individual Autonomy with Tactical Autonomy, where an individual can decide how to pursue those goals within any constraints being enforced by the organization”

If we look at the problem or, better, the idea we have of transitioning from ecosystems centered around platform owners towards ecosystems that potentially agree on an ontology, to be coded inside an enabling protocol, and then flourish building autonomous and interoperable pieces, we can see the how the “strategic” challenge about “deciding what jobs need to be done” is a mix of:

• defining the ontology of the ecosystem 
• deciding what seeding policies to enact (for example with grants) to nurture the creation of modules.

Such a vision implies that an organizational body actually exists to manage both: a continuous specification process – for the definition of the ontology – and an actual strategic process of capital allocation. Despite this “DAO” can be kept lean, such a vision brings up a critical issue in the seminal concept of Hyperstructures as portrayed by Jacob Horne as organizationless perennial infrastructures and resonates with Wilson Cusack’s critique expressed in his “Fees for the good of DAO and Protocol”:

Jacob’s piece didn’t sit quite right with me: I don’t think that protocols can just run forever on their own. Sure, the code will keep running. But the world will change and decisions will need to be made, new versions released, etc. Jacob’s idea, explained under the “valuable” attribute of hyperstructures, is that these protocols are valuable because of the threat of fees.

One would argue: why is this conversation on protocol-based vs platform-based ecosystems important at all? Well, two actual points make the case. First, it just makes intuitive sense as designers and innovators to seek patterns that can reduce the amount of reinventing the wheel, especially at the shared language, and infrastructure layer, something that Denis Roio captured so well in his The Real Crypto Movement, as he points out that:

“The advantage of crypto is not in speed or efficiency, but in a new and generally less risky and more scalable condition of interdependence, trust, and liability between infrastructure and applications” 

Furthermore, as we see the software industry modularize due to the trends we spotted above, we’ll need more variance, and more diversity in the modules available to enable more composability and nicheness and this goes through allowing the possibility to really create modular business models. 

The difficulty in finding a sustainable business model for a truly modular product that doesn’t integrate the value chain vertically can be a showstopper in this evolution and we’re finally seeing some promising development in web3. 

An example is Contract Secured Revenue (CSR):

CSR, or Contract Secured Revenue, is a fee-splitting model for the Canto network that enables smart contract developers to earn from original work by claiming a percentage of the transaction fees paid to the network when users interact with their smart contracts.

From CSR Fee Sharing to Launch Imminently — Canto Public (mirror.xyz)

The CSR pattern has been pioneered by the Canto Network but is now being increasingly supported by other L1s: 

Another L1 on Cosmos, Archway, similarly rewards applications on the network. More specifically, Archway offers three configurable rewards distribution mechanisms: gas rebates (50% of rewards go to developers), inflation rewards (25% of which go to app developers), and smart contract premiums (e.g. custom fees). 

from The Next Frontier in Cryptoeconomic Business Models – Variant

The CSR pattern is extremely interesting because it helps generalize at an eminently low level an affordance for teams to come up with components that sit in the ecosystem, and create revenues if used in a bundle or workflow. It’s definitely not for sure that this needs to be implemented at L1 layers but it points out how it makes sent to embed such a capability to reward modules at the “infrastructural” (or better, Hyperstructural, ontological) level.

After all this reasoning I realize that there’s still a lot of work to do in understanding the conditions that will move us clearer to solving the problem of converging towards shared, standard ontologies and languages that enable a shared creation space. There may even be some intrinsic issues due to the fact that converging is a demanding process with lots of tradeoffs, especially when different approaches already exist to tackle a certain problem. In a recent – yet unpublished – interview with Domain Driven Design legend Alberto Brandolini, we went long discussing this problem and Alberto noted that:

“a way [to establishing standards] is to get in a blue ocean first, with a very good quality level that becomes a de facto standard. […] if the quality of your component, it’s so good compared to the alternatives, this becomes an obvious choice. […] if instead, you have already competing for approaches to the same problem, forcing standards above the existing technologies, it’s very difficult…Think about the wall plug problems, it’s the same thing, the same problem in every country, but Italian wall plugs are different from the British, which are different from the German, which are different from those of other nations. And there is an interesting market for wall plug adapters in airports just because we couldn’t reach an agreement on a standard on something which is actually, like, three holes in the wall” 

From an upcoming episode with Alberto Brandolini of the Boundaryless Conversations Podcast

Conclusions

Understanding the evolution of product-platform design and modular software ecosystem has become a crucial skill in the modern organization: especially if you’re active in the B2B space, chances are that you’ll have to either inspire, build, or contribute to nascent ecosystems of modular and composable products.
Understanding the key dynamics playing out: product modularity, no-code and AI, organizational enables, web3, and protocols… will help your organization choose its strategic positioning in this developing industry.

If you need help understanding what strategies to pursue, reach out from the form below.