Bootstrapping user-owned Networks with Web3
What are the possibilities that web3, tokenomics, and the adoption of blockchain technology are enabling for founders? What are the steps to funding, and then transitioning to the network? Why and how should founders look into these possibilities? In this comprehensive long read we answer a lot of these questions by leveraging some real-world examples.
In this installment of the Platform-Ecosystem Atlas series, we’ll explore some of the emerging approaches being used to create web3 enabled platform-ecosystem initiatives. We focus the analysis on those web3 initiatives that aim at weaving “networks”, large communities of users that engage in scalable interactions across a certain “functional domain”.
We’ll see how such networks are often run by complex organizational systems made of different interacting nodes, sometimes formally incorporated, sometimes not, both for-profit and not-for-profit.
In the most interesting of these experiments, such a set of organizing nodes normally devolves – within time – at least part of the governance and ownership of the network to the very same players interacting in the network, embracing a process that has become known in the space as “progressive decentralization” or “exit to community“, effectively evolving into “user-owned” and radically decentralized players. Subscribe to our newsletter if you don’t want to miss a thing!
The DAO/Web3 paradigm has been used in many different contexts and thus this description may not fit in all cases: as an example, the pioneering decentralized investment vehicle The LAO – incorporated as a Delaware limited liability company that has been tokenized – leverages on a single service provider (Openlaw) to execute some key compliance processes, and thus wouldn’t fully fit in this description as it’s not really trying to weave a network. The core focus of the reflections presented in this piece – fits more specifically with experiments such as Braintrust the user-owned marketplace for hiring talent, DIMO a user-owned IoT platform that allows drivers to collect and share their vehicle data, or Rarible an NFT marketplace that opted for stronger decentralization versus OpenSea.
Bootstrapping networks: what does it mean?
What does it mean to bootstrap a network? And why is that important?
As explained in our recent Value Propositions in a business ecosystem – Products, Marketplaces, Extensions, any value proposition we build for digitally powered markets are inherently “network-based” given the connectivity that exists in markets today.
As products target users that are part of networks, marketplace-like features increasingly complement a product’s value proposition with demand generation, product feature extensions (such as plug-ins), connection with communities, and much more. As a matter of fact, most modern products are, indeed, relational experiences facilitated by a certain platform value proposition. As a result, any player currently approaching the market has to think in terms of bootstrapping networks, and the system that allows scalable interactions (in the network) is what we usually call the “product”, the “platform”, the “marketplace”.
Here, we are essentially talking about a set of processes and technological artifacts such as product bundles, channels, or financial processing functions that make it possible for players in the ecosystem to respond to their needs, participate in experiences, play a certain role in a particular market (such as renting a house on Airbnb). With time, we learned the art of building such systems at scale, bootstrapping them, and growing them: growth has become the poster child of digital, a place where design, product management, hacking, and marketing all come together.
If you’re interested in designing scalable systems, by mapping ecosystem potential, analyzing value chains, and designing scalable experiences give a look at our Platform Design Toolkit
Such scalable systems are inherently built according to certain “domain models” that describe how users interact and what workflows they participate within (e.g.: guest books a night from a host, experiences it, reviews it…). One could think of the domain model as a particular abstraction of the application context.
“In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior and data.”
In Web2, companies don’t normally publish how they describe their domain model – their “specifications” remain internal and core to their IP, and, of course, they don’t open up their data layers, if not by means of APIs they fully control. Many web 2 incumbents notoriously changed policies on the publication of their APIs (which essentially are open interfaces to their domain model and data layers) by applying a well-known plot: first, attract users by opening up, and then cut off whoever competes with the platform owner.
Due to the need to return investor capital, Web2 incumbents are poised to generate network effects as a key way to develop certain advantages with respect to competitors: they seek to create “defensibility”, building hard-to-commoditize moats by increasing the number of users, and this requires sensitive capital investments.
To be able to make such investments, normally a for-profit company (often an LLC) will go through a series of financing stages by diluting equity: normally starting from seed-stage capital round (1-2M USD) and progressing to Series A capital round (10-20M USD) and beyond.
Throughout this process, such companies try to achieve business model sustainability based on good unit economics (a favorable ratio between CPA – Cost Per Acquisition and LTV Customer Lifetime Value) and – as their value proposition depends on the number of users – they aim at network liquidity. For networks, liquidity is key: it represents a healthy relationship between supply and demand, and if these two sides are able to match easily, this brings up a flywheel that, by spinning continuously, increases defensibility.
Below a picture describing the two most core network effects flywheels:
To understand better the concept of network effects, liquidity, and flywheels, readers can check our earlier publications:
- Marketplace Growth: a Strategic Approach to Liquidity & the Chicken/Egg problem
- *Growth Engines in Marketplaces & Platforms
A fully open Product Design and Growth Guide is coming later on in the spring. Stay tuned for the release by subscribing to our newsletter.
In some cases, heavily funded players may even try achieve liquidity before proper business model sustainability. They may subsidize one or the other side in an attempt to establish defensibilities that can be later leveraged. This is especially common for so-called managed marketplaces: such marketplaces, that ensure a superior and organized experience through a deeper overseeing of it, are normally not “asset-light” and require a substantial investment that is often sustainable only when at scale.
In other cases, the equity-bearing company that starts the process is able to progress to scale and liquidity without the need to raise capital, by achieving early-stage business sustainability – for example in virtue of a single user-targeted value proposition, such as a SaaS.
Much more rarely we do see entities that do not bear equity such as coops – thus very different in terms of financing options – achieving good results in this context. Exceptions exist (mostly to prove the rule) such as those related to some players who emerged in the platform cooperative movement (e.g.: the often cited Stocksy United). The very nature of the work needed to bootstrap a network in the early stages, with an extreme need for focus, and fast decision-making cycles, bodes normally better for a pattern involving small teams and equity-based ventures.
Seminal work from people such as Jesse Walden on progressive decentralization or Nathan Schneider on exit to community paved the way for a better understanding of how entrepreneurial teams can – within time, and after an initial phase – progressively hand over control to more complex institutional systems, where more stakeholders can participate both in ownership, strategy, governance, and execution. The aim of a progressive decentralization process is indeed that of transferring both the ownership and the onus to sustain and evolve the network to the very same community, by decentralizing all or part of the jobs that have to be fulfilled to the community itself, effectively transforming the network into a common good.
Below, the reader can see how Jesse Walden framed the thinking in the seminal post “Progressive Decentralization: A Playbook for Building Crypto Applications” linked above:
So, what does Web 3 really enable?
In a recent post from November, Walden pointed out a new playbook – an interplay between “product and protocol” needed to “find a balance in web3“.
In the essay – co-authored with Jonathan Glick – Walden presents a vision that outlines a playbook based on two major elements in web3: the protocol and the product, assuming that the main focus of the initiative is to create the protocol and ensure its liquidity.
In Walden’s framing the playbook is rather simple:
- a team creates both the protocol and the first product to use the protocol with the aim of bootstrapping the protocol’s liquidity;
- the bootstrapping team gets rewarded for having bootstrapped the protocol and at the same time “commoditizes” the product (making it available for free) to enhance adoption of the protocol;
- within time, the team behind both protocol and product decentralizes governance and uses treasury to sustain other product teams, rewarding them systematically as they commoditize their products or keep them generally as less extractive as possible;
- over the long term, healthy competition between products enhances the protocol liquidity and keeps everybody happy.
It’s clear that Walden’s framing works great in #DeFi and indeed the key examples that Walden brings about are essentially all from the #DeFi space, such as Uniswap, and Compound. Defi though has its own specificities as a space: it’s rather protocol-centric, and has a strong focus on the lower layers of the value chain.
If we broaden the scope and embrace a more complete vision of a network stack (one that is able to characterize not only #DeFi players but also other contexts) we have something more resembling the one below.
In this picture, we explored the components and the interplay between the Scalable Interactions System and the organization supporting it.
The former is to be intended as the place where the community of users interacts, exchanges value, consumes the product, and historicizes the data in an open ledger; the latter as the institutional system that is in charge to produce and evolve the scalable interaction system (click on the picture to see fully detailed PDF version).
The Scalable Interactions System
The scalable interactions system is characterized by the interplay of two key elements, let’s call them the “platform” and the “protocol”. The former is characterized by three key connected types of value proposition:
- the product(s);
- the marketplace(s) – that connect the product users with certain types of counterparts;
- and the extensions platform(s) – connecting third parties developing extensions to the product with the product users.
We have thoroughly explained the interplay of these three value propositions in our recent Value Propositions in a business ecosystem – Products, Marketplaces, Extensions therefore we suggest the reader peek into that to understand better what are we talking about with real-world examples such as Airbnb, Salesforce, Shopify, Slice and more.
Key Innovations: data openness and permissionlessness, and tokens
One of the key innovations of Web3 allows such “platforms” to be based on open “protocols” made of a secure and permissionless data-info sharing layer, and a set of smart contracts that ensure that validation nodes are rewarded in various ways for their work of keeping the data layer of the system secure and accessible.
Another key innovation of Web3 is related to the possibility to adopt tokenomics not only at the “protocol” layer to favor staking or other validation-related contributions (pretty much what Walden refers to in the essay) but also at the “platform” layer. An eminent example of this is the use of tokenomics at Braintrust, where tokens are being used to reward users that play certain roles, and give certain key contributions to the platform as well as provide specific utility to users. Being Braintrust is essentially a marketplace connecting corporate clients with job offers with talents (it doesn’t have a strong “product” or “extension platform” value proposition in place yet) it uses the BRTST tokens to reward actions such as vetting new users, or doing referrals and attaches particular utility patterns to such tokens to be later used inside the network, such as for example the possibility to use them to advertise a certain job bid to an offeror or to provide signals of commitment to fulfilling a job by staking tokens and slashing them if the job offer is retired.
This scalable interaction system made of the interplay between the platform and the protocol is also clearly based on a certain domain model specification: a, more or less explicit specification that is normally described – to a various extent of clarity – in the whitepaper, and cautiously evolved later on.
Depending on the cases, some projects do lack one or another layer: many #Defi protocols focus on building the protocol layer only, leaving the product to third parties (this is what Walden advises in the long term), other web3 projects keep the transaction and data off-chain and actually focus on building the platform layer with a tokenomics structures often based on standard tokenization frameworks such as ERC20, attaching different types of utilities to tokens. This is indeed the case of Braintrust which doesn’t have any strong on-chain representation of the domain specification (which by the way is fairly simple) and doesn’t use a permissionless data-info sharing layer (see below the core of Braintrust logic from Figure 2 from their whitepaper) as the core of the transactional model is simple, entails off-chain players such as incumbents, and it’s based on doing professional work and processing traditional invoices.
But how do networks organize the efforts needed to produce and continuously design and evolve the scalable interactions system? Here we present an abstraction that covers several cases, but we have no expectation of being exhaustive as different approaches emerge all the time. The space is in a very early stage, then examples don’t abound, but we will first present a general organizational structure – based on sampling several existing cases and integrating them in a general view – and then explain how progressive decentralization has been attained (or is being attained) in some exemplary cases.
Let’s look into the most advanced models of organizations from the real world.
Let’s start by saying that there are many ways to look into an organization albeit, notoriously, three key problems exist in organizations that the organization needs to solve:
- Strategy: continuously choosing what to do, where to allocate resources, and the directions of exploration;
- Execution: distributing and coordinating efforts through natural leadership, decision making, collaboration, and feedback;
- Integration of performance: setting objectives and orchestrating how the different parts of the organization reach them together through motivation, targets, incentives, and value sharing.
In our 3EO Toolkit and framework – that draws inspiration from the most advanced models of organizing from world-leading organizational models such as Holacracy, Sociocracy, market-based, scaled agile, Team Topologies, and many more, and is largely inspired by world-leading Haier’s Rendanheyi – we break down organizational contributions in four more layers that are provided by different organizational players and effectively transversal to the key problems above.
These types of contributions include:
- the architecting: the responsibility and process of designing and evolving the organizational constraints;
- the enabling: the basic set of enabling services the units in the organization can use to be able to focus and thrive in their specific contribution;
- the enterprising: the unit-driven, outside-in, efforts towards developing new value, generating growth, and achieving objectives;
- the ecosystemic: the capability to weave value beyond the organizational boundary, to a wider level of interaction, influence, and participation.
and are normally played by a set of different organizational units (essentially, teams): someone calls them teams, other circles, others support platforms and micro-enterprises, and more.
In the emerging web3 space, we usually face minimal organizational structures: building in web3 inherently entails a high capability to encompass organizational processes in technology, and automate them, including in smart contracts. It’s normally a space populated by remote-first, async-first, contributors, familiar with the key governance mechanisms enabled by blockchain, such as token-based voting, and thus generally tends to generate very schematic organizational models, characterized by high delegation, and a lot of informality.
The Encompassing Organization
Most often web 3 institutional structures feature an essential encompassing entity that provides first of all the legal compliance needed for the creation of tokens, plus serves as a container for smaller organizational nodes and contributions. Tokens are often issued through either Primary Issuance Events (such as pre-minting tokens) or Primary or Secondary Automated Market Makers (bonding curves, liquidity pools, etc…).
This structure is often (not always) a no-profit foundation, as this connects well with the idea that – over the long term – if we are building in web 3 genuinely, the thing being built and bootstrapped will be, at some point, brought under the direct control of its own user base, through progressive decentralization, effectively configuring as a network’s commons.
Beyond legal compliance, this governance space is normally responsible for holding the space where collective governance expresses itself normally in the form of:
- Strategic direction;
- Treasury Allocation (and evolution of token issuance);
- Contracting smaller org. nodes that produce key functions, normally in continuity;
- Domain model and interface specification and update.
In doing so, the encompassing entity has normally a responsibility to host a space where token holders can directly steer the direction of the network. This happens normally via voting, often through tools such as Snapshot, with different weighing mechanisms, some more plutocratic (in line with the number of tokens the users hold), some more democratic (like quadratic voting), depending on the DAO.
Such “off-chain” voting influences the direction and the choices that are enacted by the organization, choices that often regard allocating fiat money or tokens from the treasury to fund certain activities: budget distribution is often seen as the main org function in DAOs.
“…at base, all governance within organizations really comes down to budgeting, what are we going to spend our money on – because that’s being spent on people for the work that they do, and everything else is just garnish””
Such funds are normally disbursed to either org. nodes that perform key functions over the long term or to contributors emerging from the community through what is normally called a “grant” or a “grant program“.
Other recurring decisions taken off-chain may regard policy changes, normally codified in the bylaws or in less formal agreements that regulate the encompassing organization, such as – for example – changes in the platform’s or protocol’s business model. For example, Braintrust specifically leaves the community in charge of policy changes related to the marketplace’s functioning model, including tak rates.
Recently, the Braintrust community held a vote – after the proposal informally surfaced in the community’s discord – to change the destination of the 10% take rate the network takes from jobs that are posted (from the poster’s side). Such 10% take rate was originally paid in fiat to the referral node (the company responsible to bring a customer in and process the customer payments in fiat currency): after a decision from the community of token holders, it has been decided that such take rate has to be converted (through a system called “fee converter“) into the native token of the community, through a direct market buyback, and then sent to the treasury to prevent the treasury of being depleted over time. As a result market demand for the BRTST token is increased, appreciating it benefitting all token holders. Such a vote shows clearly how off-chain polling among token holders can be used to enact profound policy changes in the network.
In some specific cases, votes are also to be considered “on-chain” – often following after a first “off-chain” voting session to check the temperature about certain decisions. An on-chain vote is different from the off-chain vote in the way it directly enacts a chance in the smart contract code that sometimes covers part of the implementation of the technological artifacts belonging to the protocol or platform layer. Of course, this entails that part of the network logic needs to be codified into smart contract code.
The Org Nodes
Org Nodes effectively represent sub-parts of the encompassing organization: and they are responsible to produce key organizational capabilities or bring forth essential lines of development.
Such capabilities are normally extremely contextual to the DAO/network and the shape the Org Nodes take really depends on the case, but a – noncomprehensive – list of support functions may include:
- to develop technological artefacts pertaining to the protocol or platform (in traditional code or smart contracts), often in coexistence with alternatives provided by other independent third parties, that can build theirs thanks to the openness of interfaces and protocols;
- to run parts of the network infrastructure either as network nodes or provider of cloud capabilities;
- to provide the ancillary functions needed to communicate the mission and grow the community of users such as design, growth hacking, and marketing and generate network effects-driven defensibility;
- to play a role in how the business model is executed, finances are processed and revenues are collected, managed, and distributed.
At DIMO, an “open-source protocol that leverages web3 technology to connect data producers and consumers” – which is one of the case studies we considered in the preparation of this article – the org nodes have been constituted informally as teams (dTeams), on the basis of the key areas of development they’re looking after.
At Dimo, dTeams look into:
- core infrastructure development;
- hardware development;
- platform development;
- developing the first native apps to bring liquidity to the protocol;
- facilitating third-party developers;
- creating media;
- hacking growth;
- and guiding orientation toward sustainability;
At the moment DIMO is a project run by Digital Infrastructures Inc) that has been the entity starting the bootstrap process and raising capital, through an undisclosed seed round first, and a recent Series A amounting to 9M$.
Such capital has been invested both in Digital Infrastructure Inc. equity and converted into DIMO Tokens. DIMO has a quite transparent process of token allocation, tokens have been distributed so far to the DIMO Core Team (essentially represented by Digital Infrastructures Inc and other early partners, eg. in hardware development as we understand), to investors and to the first users that are producing the car data i.e. the main asset the project wants to produce transparently and help users monetize.
Over the long term, DIMO wants to complete a pragmatic progressive decentralization process and transfer project control from Digital Infrastructures Inc to an upcoming DIMO Foundation (the process and the governance scope of the foundation is detailed here) ).
It’s interesting to note that capital investors that did invest early on, not only received DIMO tokens but also Digital Infrastructures Inc. equity: according to the information here), Digital Infrastructure Inc. plans to act as a Data Broker first, and according to some information we have collected from the team, Digital Infrastructures Inc. will mainly focus on developing applications on top of the protocol, that will find its own self-sustainability (by charging fees to apps and dApps).
As we have highlighted on the schematic picture of the dual system above (nfx = network effects, eos = economies of scale), it’s important to note that not only the protocol can generate network effects and build relevant defensibilities but the products, marketplaces and extension platforms that sit on such protocol can also accrue relevant value through economies of scale, network effects and other reinforcing mechanisms (check out our piece on the topic). In the case of web3, the accrual of value that happens at these “platform layer” is also more resilient since the underlying protocol is open, legible, and under community control: at the end of the day creating broader legitimacy. This situation justifies investors’ interest as the friction between the protocol and the platform is eased, granting a focus on longer-term outcomes, and an overall stronger resilience for the platform as incentives between layers are aligned and no party has the possibility to change the rules.
In another context, that of Braintrust, the org nodes have had a slightly different genesis. Braintrust doesn’t rely on a single corporate player and didn’t raise any capital in exchange of equity. The initial effort have been guided by a few early nodes (orgs, to which most of the founders belong) that brought forward the idea of Braintrust in a way that was surprisingly similar to any other startup: through customer development, prototyping, collecting corporate customers’ and investors’ interest.
The group raised money through a series of rounds of increasing size – a few seed ones, a Series A and a Series B equivalent – first through the use of SAFT (Simple Agreement for Future Tokens a widely used option for early-stage funding of web 3 players), and then through direct token offerings.
Such capital has been used so far to:
- pay for the work of the org nodes during bootstrapping – technological development, financial transaction processing, communication, growth, etc… most of such work is still paid in fiat in combination with minor token allocations;
- constitute the Braintrust foundation treasury (yes, also Braintrust’s treasury is issued and managed by a non-profit foundation).
More in detail the latest round 100M$ round involving Tiger and Cotue, was specifically aimed at reinforcing the fiat part of the treasury, making it easier to allocate money to grants that may help the network grow better and faster. The main difference with DIMO here, is that since no equity was sold, nodes have simply been rewarded with fiat money and tokens for the value they provided in the early stages.
From some deepening we had the chance to do with the founding teams – in both these situations (DIMO and Braintrust) the management approach to teams seems informal and emergent. More specifically in the conversation, we had with Adam Jackson – coming up on the podcast – he said that:
“[teams are] all independent […] I’m only being associated with one of the nodes. the others are completely independent entities all over the world. […] we coordinate, we’re friends and colleagues and folks that have come together for a common goal, and that is to make the Braintrust network bigger, attract more clients and attract more talent to build a bigger, better ecosystem […] so the coordination is simpler than you think. It’s like zoom calls, Google Docs, and things like that. And there are some things we need to coordinate on, and some things we can contribute independently, I don’t have regular communication with most of the nodes, they’re all incentivized to do their part and make the ecosystem more valuable for all of us.”
If we look into what has been happening in a space that is more DeFi related, and thus more resonant with Walden’s original points, a particularly interesting case is Yearn’s Gov 2.0 (YIP 216). Yearn is essential “a group of protocols running on the Ethereum blockchain that allow users to optimize their earnings on crypto assets through lending and trading services” according to Kraken . The experience of Yearn is relevant as – differently from the examples presented above – Yearn has never been incorporated in an encompassing organization neither pre or post-facto.
Indeed, according to its manifesto, Yearn is not a legal entity and it’s not backed by investors. We could probably associate Yearn more with an open-source development project than with a traditional organization.
Irrespectively of that, Yearn found itself in the need to informally formalize (pardon the oxymoron) its approach to governance to respond to the need to legitimize its processes in the face of its community. In April 2021 Yearn adopted a fairly structured, though simple, approach to governance that essentially made a clear snapshot of what “discrete decision-making powers” do exist in the organization, and how they either pertain to the YFI token holders or are delegated to the existing yTeams, formalizing them (DIMO’s dTeams have been taking inspiration from yTeams).
A new perspective to the entrepreneurial initiative and network creation
In our understanding at Boundaryless, the evolutionary background we’re seeing in technological enablers and systemic narratives (around social and environmental sustainability, and cultural evolution), is effectively conducive to decentralized approaches to bootstrapping and building networks. These approaches do not only seem more possible now – or just more viable – but effectively seem to be the most capable of producing what we could call “last movers”: initiatives that effectively and deliberately choose to outcooperate the competition and thus acquire a leading position in certain ecosystems.
Adopting such a perspective is suitable for many different types of players: in the case of DIMO and Braintrust we’ve seen how these initiatives have started from entrepreneurial, startup-like teams but there’s nothing preventing an incumbent in a certain industry to adopt a progressive decentralization mechanism to develop a new strategy or to transition an existing strategy.
In all cases though, such a perspective entails a different driver for the weaving parties. In a traditional setting, players have looked into bootstrapping networks, achieved defensibilities, and eventually started to extract disproportionate rents. Those rents took the form of strangling take rates, and have been paying back shareholder interest, even when the initial capital and the initial entrepreneurial contribution to bootstrapping have been more than fully repaid. This perspective clearly doesn’t fit within the emergent web3 playbook.
What we’re seeing in web3 is the effective emergence of a new entrepreneurial perspective, where bootstrapping players invest entrepreneurial energy from a more democratic standpoint. Those players are open (and intentional) with regard to transferring ownership and governance to network participants over the long term.
Despite not being in for long term extraction of rents, such founders can still seek several opportunities over the long term:
- playing a role in the scalable interaction system they are bootstrapping: for example becoming a commercial node bringing in more customers, as it happened with Braintrust Founders;
- providing enabling services as org. nodes to the larger organization at a fair and negotiable service contract fee with the network;
- develop applications on top of open and transparent protocols that can’t lock them out of the network, as Digital Infrastructure Inc. aims at doing with DIMO.
The financial driver
In terms of entrepreneurial drivers, owning a fractional part of the organization may still remain relevant as, often, the early partners that develop and bootstrap the network allocate part of the token base to them, often as a complement of the fiat currency investment that they collect.
At the moment though, valuing a governance token (that may also have other ancillary uses), in the same way, one would value shares may be a stretch for two essential reasons. First, such tokens are rarely configured as securities (i.e. attached to rights on future revenues), to avoid essential elements of legislation that would make allocation more complicated (e.g. KYC). Furthermore, the very mechanisms of token issuance and valorization are part of a widely immature landscape, ranging from pre-minting arbitrary amounts of tokens to adopting automated market makers such as bonding curves. Many other related issues also may affect token value, for example, the token liquidity on both standard (such as Coinbase) and distributed exchanges (such as Uniswap) therefore adopting collateral DeFi strategies such as staking to build liquidity pools, is essential to proper value accrual: for example, what if the fee converter smart contract in Braintrust fails to find BTRST tokens liquid on DEXs over the long term as the gross merchandise value of the network grows?
Conclusion and future works
In this long read, we at Boundaryless collected the first conclusions following months of research and collaboration with partners and customers.
This preliminary research depicts a space that is becoming more relevant by the day, especially in virtue of the major new possibilities that open up in creating strategies that are able to reduce traditional market inefficiencies, asymmetries, and flaws. We believe any organization operating to create new strategies or evolve existing strategies on the market should consider the implications of web3, and we encourage prospect partners and customers to reach out to us through the form below.
We plan to extend the research in the coming months in several directions, mainly integrating this with our existing body of methods for the design of the scalable interactions system (such as Platform Design Toolkit), and for the design management and evolution of the organizational structures that can be adapted to support it. Our 3EO framework is naturally suited to fit with DAOs and web3 by – at the same time – reminding founders that organizations are still needed as they have to express key contributions to solve key problems of organizing. In coming installments, we’ll explain how existing DAOs map out in the 3EO structure and highlight potential design strategies to develop balanced organizational systems to support web3 initiatives which – by the way – remain the pioneers we have to learn from.
Are you curious about developing mastery on the application of such techniques, access our beta tool releases and more?
Join us at the upcoming Platform Design Bootcamp in June:
Before You Go!
As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to share with your friends as this will help us to get more exposure, and hopefully, work more on developing these tools.
If you liked this post, you can also follow us on Twitter, we normally curate this kind of content.
Thanks for your support!
Get help in leveraging Web3 in your strategy
Value Propositions in Business Ecosystems – Products, Marketplaces, Extensions
What are the key value propositions in business ecosystems? How does a product or service bundle complement a marketplace? How...
What are the key value...
March 22, 2022