Source: https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/
Summary
The three components of crypto’s success are: 1) product/market fit ; 2) community participation ; 3) sufficient decentralization.
The founding team must over time relenquish control because that is better long term for the health of the network. Because decentralization minimizes platform risk, the possibility that the rules will change on developers. Platforms need committed developers and committed users.
Sufficient decentralization is also important for regulatory reasons. SEC deems decentralized companies not as securities (?? why??)
Notes
Decentralization minimizes platform risk
Quotes
Crypto founders have a unique challenge in front of them. In addition to building a product that people want, ==they also need to consider how that product can successfully run in a decentralized manner — that is, as a protocol owned and operated by a community of users.
This is a difficult challenge because much of what it takes to build a successful product at the outset — product leadership, rapid iteration, a managed go-to-market — ==complicates the path to community ownership and regulatory compliance, which guarantee long-term health.
==I’ve talked to a number of crypto founders working to resolve this tension. Here I’ll propose a three-step process that may serve as a guide for how to do it, by way of progressive decentralization — a process in which founding teams relinquish control by degrees, over time. Doing so step-by-step allows teams to focus and creates a path toward regulatory compliance, including issuing tokens that hopefully will not run afoul of securities regulations.
==Keep in mind that this process is intended for certain crypto startups building applications on smart contract platforms.** It’s less useful for blockchain computing platforms themselves, which require sufficient decentralization from inception in order to be useful.**
The answer is that community participation and control results in limited platform risk — the risk that the rules of a platform will change against the will of its users
The Three Components of Crypto Success
==1. Product/market fit =2. Community participation =3. Sufficient decentralization (community ownership)
The need for product/market fit is obvious. Without a product people want, there are no users, no business, and it will be difficult to sustain a community for long. ==Community participation and decentralized control are less applicable to traditional startups, but are crucial for crypto startups. Why are they so important?
==The answer is that community participation and control results in limited platform risk — the risk that the rules of a platform will change against the will of its users. Web 2.0 platforms have demonstrated the potential for this kind of misalignment, for example by killing innovative app ecosystems built on their APIs, or by profiting at the expense of users’ privacy or wellbeing. In contrast, user-owned networks can benefit from a cooperative economic model that helps ensure crypto services remain better aligned with their users, even as they scale.
Another important reason for achieving decentralized community control is regulatory compliance**.** ==Crypto tokens that facilitate economic alignment can be deemed securities under the Howey Test, a regulatory framework used by the SEC. Managing a distribution of securities to a large community of users can be challenging and expensive for a startup to manage — even Airbnb and Uber haven’t figured out how to do it.
==But analysis of recent SEC commentary and enforcement actions suggests that true decentralization may enable a startup’s token to transmute from a security to a non-security if the team is able to sufficiently decentralize operations, eliminating information asymmetry or dependency on the efforts of the founding team to create value.
The idea of a core team controlling all aspects of a project may ruffle the feathers of some early users, but founders shouldn’t be wary of this.
That said, it’s important to communicate clearly about where control exists. Faking autonomy is a quick way to undermine trust, whereas transparency is a way to build it.
Objective 2: Community Participation
At early signs of product traction — a growing user base, developer ecosystem and network effects — it’s time to start devoting more cycles to fostering harmony between passive users, more-active contributors and the core team.
==To start, founders might invest more heavily in best practices for running the product like an open source project: invest in good documentation; develop openly; offer bounties, grants or other incentives for third-party development; hire community leaders to help steward open development; and introduce rough consensus on decision making’
==Going further, it may make sense to start eliminating platform risk through imposed technical constraints. For example, in Compound v2.2, upgrades take effect 48 hours after they are pushed, allowing time for users to exit the protocol, or review and voice dissent. Urbit practices “Kelvin versioning,” in which version numbers count downwards to 0, at which point no more updates are to be made.
Incentives (Fees)
An economic incentive is one way to engender community contribution. But where do the economics come from? A pragmatic and familiar business model for crypto services is a fee-per-call, similar to an API micro-service like Twilio or Stripe. Distributing this fee stream to active contributors can align the community around the project’s success.
Distribution (Tokens)
==To start, teams might test a distribution with a managed and permissioned group of community members. A number of teams have elected to do this by allocating a slice of future tokens to early “power” contributors, for example through testnet programs where independent community members can register to participate in operating a node. A promissory and managed token distribution to users that contribute valuable work can help eliminate community dependency on the effort of founding teams.
==Next, teams need to plan how remaining tokens will be distributed to participants, both fairly for past contributions, and effectively as a future incentive for ongoing participation**.** The distribution design needs to consider the core team that built the product, as well as the users that make it useful. Getting this right is hard, and will always be specific to the application in question, but some common questions to think through are:
- What percentage of tokens should be allocated to the initial team and cap table?
- How will you reward different types of contributors to the product or service, historically and in the future?
- How will technology leadership be rewarded going forward?
Objective 3: Sufficient Decentralization
In practice, I imagine teams will “exit to the community” by airdropping tokens to users and contributors based on the plan mapped out in the prior objective. This would happen the moment a smart contract is triggered to mint and distribute tokens. Optimally, once this function is triggered a number of things will have happened:
- The core team will have ceded majority ownership of the application (fees and control) and mitigated platform risk by ensuring the product is community-owned and operated.
- The token may have transmuted to a non-security, given that the service is now sufficiently decentralized — that is, independent of the efforts of a single entity that might have asymmetric information.
- The company is sustainable, having retained enough tokens to benefit from fees and growth.
- User-owners realize increasing returns to scale, as the cooperative economics of the service allow for better alignment and growing value (as defined by users rather than shareholders.)
How to Avoid Getting Stuck
==For instance, app teams that pursue community ownership first (starting with a wide token distribution) risk engendering a community of speculators, rather than real users. Without a working product, ownership is worthless, and the community won’t stick. Many teams that have done this are unable to back into product/market fit, and as a result have a hard time kickstarting meaningful community participation.
==Another sequencing risk is jumping straight from early signs of product/market fit to decentralized community ownership (skipping objective 2, community participation.) Failing to formalize real community participation can land projects in an uncanny valley of decentralization theater. A symptom of being caught here is an apathetic community with low participation rates, and a heavy dependency on founding teams. In this situation, formalizing control (e.g. through delegation) may be a better path to building trust, whereas hiding under the pretense of decentralization is a quick way to undermine it.