When designing a product that requires a network to be successful, there is the additional complexity of the cold start problem. As discussed in The Elements of User Experience, product designers should aim to design every aspect of the user's experience with conscious intent. As part of scoping the features of a product, or a minimum viable product (MVP), it's vital to prioritize features that can help overcome the cold start problem. With the proper framework, we should be able to translate the complexities of a cold start problem into clear guidelines that help guide the scope of our product's features and user experience.

This article aims to provide such a framework by focusing on the aspects of Andrew Chen's five-stage network growth model that prioritize the initial set of user needs and features. Andrew Chen's book, The Cold Start Problem: How to Start and Scale Network Effects, is available here. Camin McCluskey has summarized Chen's book here.

Network Effects

Network effects are where a product or service's value increases as more users engage with it. Similarly, network effects kill products that cannot simultaneously acquire the right users and content as there is no value for a new user upon encountering the product, also called anti-network effects. Hence we have the cold start problem where the network needs to be cold-started until it reaches the tipping point where network effects become a positive rather than negative force for growth. Andrew Chen calls this tipping point the Allee threshold, borrowed from the biological phenomenon where meerkats obtain increasing benefits from adding new members to their community.

In Andrew Chen's framework, there is also the concept of a carrying capacity, a limit in the growth from network effects, which may or may not be possible to overcome. Examples of signs that a network has reached carrying capacity include problems like spam and trolls that have become commonplace on popular social networks.

Cold Start Theory

The Cold Start Theory is a five-stage model of network growth.

1. Cold Start
2. Tipping Point
3. Escape Velocity
4. The Ceiling
5. The Moat

Each stage has unique considerations and problems that product designers need to overcome. This article focuses on the concerns related to the prioritization of a product's features and user experience design to harness positive feedback loops from network effects while overcoming and avoiding anti-network effects.

1. Cold Start

Every network must bootstrap from a cold start – the lack of a network.

The Atomic Network

The Atomic Network is the smallest network that can stand independently and sustain engagement with your product. This network is small but dense and stable in terms of interconnectedness among the initial users. Further, this network is likely smaller (in the 100s) and more specific than the user segments identified in your strategy document.

To appropriately test the hypothesis for an initial atomic network, product designers should prioritize features that:

1. meet the needs of users in the initial atomic network, and
2. encourage connection density and stability in the initial atomic network while

deprioritizing features that:

1. only meet needs unique to users of subsequent atomic networks,
2. solve problems of larger networks that do not currently exist, and
3. seek aggressive monetization before establishing an atomic network.

The Hard Side

Networks often have a hard side and an easy side. The hard side is usually a small minority of users who create disproportionate value in the network.

Product designers should prioritize features that:

1. meet the needs of the hard side, and
2. encourage engagement by the hard side to grow the network and interact/transact with the easy side while

deprioritizing features that:

1. do not engage the hard side, or
2. create friction for the hard side.

The Killer Product

The killer product is usually a simple, one-click experience. Therefore, product designers should deprioritize bulky features. Also, see How to Un-Bloat Your MVP by Liron Shapira.

Magic Moments

Magic moments are the instances where a product feels like magic. An example of a magic moment is a car arriving at your doorstep at the touch of a screen. The opposite of a magic moment is a zero.

Assuming a product can deliver magic moments with a mature network, product designers should focus on avoiding the opposite of these magic moments by prioritizing features that:

1. guide the user to prevent a zero upon onboarding or initiating the product, and
2. detect and correct zeros (e.g., by nudging other users to create a more magical experience for the user who experienced a zero)

while deprioritizing features that create the potential for more zeros, similar to reducing bloat above.

2. Tipping Point

The Tipping Point is where the network is ready to transition from nascency to hypergrowth. Chen lays out several strategies that can help prioritize features for a product:

1. Invite-Only: Consider invite-only features to provide a better experience for new users, who are more likely to be more connected to the existing network and potentially hard side users. There is the added benefit of containing growth while creating FOMO for parties without the invitation.
2. Come for the Tool, Stay for the Network: Provide utility to users beyond the network and work to pivot them from using the tool to participating in a network.
3. Pay up for Launch: Pay for, or provide monetary benefits to the hard side, if needed. For example, Tinder paid for parties where they required attendees to download their application.
4. Flintstoning: Simulate a functional network until it's on auto-pilot if needed. For example, the founders of Reddit programmed bots to post links until they had sufficient user-generated content on their website.

3. Escape Velocity

Escape Velocity is the hypergrowth stage, achieved through the convergence of three distinct forces.

The Engagement Effect

This is the effect that engagement increases as the network reaches escape velocity.

This effect can be acquired using features that reactivate dormant users, which may be by notifying them that someone they know has joined the network or pointing them to content that may be of interest.

The Acquisition Effect

This is the effect of organically acquiring new atomic networks. Features should enable quickly onboarding new users via invites and integrating them into an atomic network in which they may be interested.

The Economic Effect

These are features that increase the economic performance of the network, such as those that encourage increased conversion to paying users.

4. The Ceiling

The Ceiling is the point at which the network growth begins to stall.

Saturation: New Atomic Networks

Saturation may signify that a new smaller network is required to stack onto the existing network. Therefore, new features should focus on attracting new atomic networks, which may differ from the features that attracted the initial atomic networks.

Shitty Clickthroughs: New Acquisition Effects

Every acquisition channel eventually deteriorates. Therefore, features at this stage should reinforce acquisition effects instead of increasing spending on channels with diminishing returns.

Network Revolts: Hard Side Professionalization

Features favorable to the majority of the network, the easy side, may face adverse reactions from the hard side. Features should nudge the hard side towards professionalization to a point where they can earn a livelihood participating in the network.

Eternal September: Fragmentation and Spam Prevention

Sudden network growth spurts can lead to alienating users due to context collapse. To prevent context collapse, features should:

1. enable users to retain smaller networks, e.g., bilateral DMs, group chats, and communities, to avoid context collapse as the network grows, and
2. prevent spam using downvotes, moderation, proof-of-work, and paywalls.

Overcrowding: Curation and Discoverability

As the network grows, it may be difficult for users to find content that is interesting to them. There may be "old money" effects where earlier users have large audiences that promote their content. Features should:

1. curate content relevant to the users' needs, whether manually or algorithmically, and
2. provide discoverability to new hard side users to avoid churn.

5. The Moat

The Moat is the stage at which the network needs to protect itself from competitors.

One aspect of networked products that Chen does not directly address is the case where a networked product is intentionally interoperable with its competitors.

Such effects exist when building interoperable networked products with Bitcoin and the Lightning Network. Until recently, it would not have been possible to conceive of incentives beyond the ideological and activist realm into the economic realm on such protocols. However, with Bitcoin, products using its currency, its blockchain, or the Lightning Network can benefit economically from its adoption.

Instead of building moats, as in the case of closed networked products, interoperable networked products must differentiate themselves based on improved user experience. As a result, there is likely to be increased competition since switching wallets or on- and off-ramps will be trivial for users. At the same time, cold starts may become easier to execute since a network already exists, and new products may better serve different niches within that network by cherry picking.

The Future of Network Effects

While Chen is more excited about "crypto becoming infused into every aspect of software" than he is about Bitcoin, this contradicts a core insight from the book: networked products lean toward a winner-take-all outcome. One would then posit that one winner will take all, or at least most, of the currency use case. That winner, to date, appears to be Bitcoin.

Symbiosis and Parasitism

Beyond the fact that their special purpose currencies need to compete with bitcoin and other currencies for liquidity, products built on blockchain-based protocols are not technically viable to reach the scale to replace the currently prevalent closed networked products. In contrast, interoperable networked products built on protocols such as nostr have a  chance of working. Unlike Bitcoin, however, interoperable networked products without a currency would not have the embedded economic incentives to drive their adoption. Instead, their growth beyond a user base of ideologues and activists requires economically viable products in symbiotic or parasitic relationships with other thriving networks whenever possible.

External symbiosis for an interoperable networked product may involve providing desired functionality to users of Bitcoin or the Lightning Network to benefit from the existing user base and simultaneously grow both networks. External parasitism may include features that allow seamless migration from a closed networked product (e.g., nostr-based competitors to Twitter, Uber, and potentially GitHub, discussed here, here, and here).

Internal symbiosis may exist until the network reaches a ceiling that the collection of interoperable networked products can't overcome. Internal parasitism would be the natural end state for interoperable networked products once the network reaches its global ceiling. After that, there may only be a need for a few decentralized alternatives to a particular application.

While Chen may have been overly optimistic about "crypto" providing the foundation for future networked products, it is more plausible for interoperable networked products based on open protocols without separate currencies to provide this foundation. Product designers who choose not to compete with Bitcoin by issuing distinct cryptocurrencies should consider externally symbiotic and parasitic features to other networks when prioritizing their scope to overcome the cold start problem.

---

Don't trust, verify: This article is based solely on my personal views and does not represent the views of my employers. This article is for informational purposes only and does not constitute an endorsement of any products and services discussed or investment, financial, or trading advice. I do not guarantee the reliability of the content in this article and shall not be held liable for any errors, omissions, or inaccuracies.