We are increasingly exposed to new types of communities as we continue down the path of hypothesis validation. And as a team that is building a credentialing protocol for communities, it is imperative to develop a deeper understanding of our operating environment. This is done best by creating a framework to think out of.

With the number of crypto-native communities springing up, web3 folks focus on slotting them by function. So on one side you have protocol DAOs (i.e. prominent crypto communities that look after the operations and future direction of a protocol, like MakerDAO). On another, you have grant giving DAOs (i.e. DAOs whose main purpose is to accelerate innovation and development by giving grants to interesting people and projects, MetaCartel does this). And so on and so forth.

One common thread among all the communities we speak of in any category though, is how they are somewhat stabilised in terms of their narrative and operations.

However, there does exist a larger set of communities that while functioning on the same ideals of digital cooperativism, are far from gaining clarity in terms of their mission or “what they actually do”.

The above description of newer DAOs might seem reductive, but the purpose of that is to hint at another way to think about them, i.e. between those that are “grown-up” and those that still have a lot of growing up to do. And I feel this way of thinking is most helpful for anyone building for communities.

The question now is which one should you focus on more? The larger DAOs are especially useful because they will use your protocol / tool / product in ways that you would’ve most likely never thought of. They also make you aware of the stress points of your platform as it’s used deeper and deeper. And these communities might make feature suggestions that are applicable across a larger board of users. However, this is not always the best option.

As a platform that is in public beta and one that goes through semi-major iterations every four weeks or so, we have seen that while the feedback by big communities is useful, it often takes a lot more for them to actually use it. This could be frustrating for teams that have been building for a while and need users before they continue.

These users could very well be found in the scores of new communities that sprout every day, and might just be more useful than the bigger ones we spoke of earlier. But for now, a strategy that focusses on small communities gets a bad rap.

First and foremost, from a growth perspective, one larger community does better to attract more users than several nascent stage communities. Second, these small communities are themselves going through an awkward phase so their feedback is shifty at best. Third, you might end up diving too deep in novel working mechanisms of a subset of these communities, but there is the very real risk that these working mechanisms or even communities don’t stand the test of time.

The safe option is clearly to grind out for bigger partnerships. I argue, the safe option is the latter.

The biggest reason I advocate seeking smaller communities is because they are easy to onboard. Several small communities testing your product today does better for feedback than one big community testing your product tomorrow.

Second, newer communities are typically “ahead of the curve”, meaning they often set out knowing the shortcomings of their predecessors, and might even have a plan to address those issues. We don’t need to go too far for an example: EVM-based L1s provided blockchains that did “more than just cryptocurrencies”. ZKP-based L1s provided scalability that went beyond that of other prevalant L1s. And so on and so forth.

But my personal favourite reason to focus on smaller communities is how they let us have a deeper impact on the space in general. Partnering with a community from the beggining exposes us to the various challenges of community building from the very beginning. It gives us a more accurate pulse on the ecosystem than what one would get from simply reading or hearing about other communities. And it gives a slower, more realistic timeframe for each iteration based on actual feedback and usage (as opposed to hypothesising about problems, building, and then testing them out).

Since the goal of every web3 tool should be to become a DAO, and since the path to do so lies through building something around which a community can be formed, focussing on small communities lets us do both. It also makes partnerships deeper than usual, since both parties are invested and stand to benefit from the success of one another.

Lastly, partnering with small communities that go on to become big tomorrow is several times better than partnering with a big one today. This is playing the long game in its purest form.

Obviously, the danger of a community “failing” or becoming dormant is large here. You could most likely end up wasting your time (in fact, I still end up chasing dead leads time to time—spending days trying to connect with someone from a “DAO” only to know that it’s been dormant all this while). But I am optimistic.

And I cannot afford not to make this bet.

You can also view this post on Substack.