This essay is for those of you who are new to building communities or are just thinking about how to improve this part of your project. It's a look at things you must have and things you should try to avoid. It is not a definitive guide to community mastery

In the past, I built different communities, like a community of artists for digital publishing, open-source developers for wifi routers stack, patient efficacy groups for big pharma, productivity and TKM consultants for SaaS products, or music fans for a music club. And in the past five years, I've observed tens of web3 communities. That's to say that I have a decent insight into the dangers waiting on community builders.

I can only tell you what a great community looks like for your project if I know your project and your vision inside out. It is and should be specific - to what type of project you're building, your needs, and your goals. Since I don't know your project, I can show you a simple framework you can use when thinking about community building and you can build "ideal community" picture for yourself.

Community Building Issues

Let's start with issues I see in community building - hopefully, you're not in these categories.

In a typical SaaS or web2 startup, a community often turns into one of these two versions:

• a/ Features announcements feed with no or very little interaction from the team outside of announcement calls or write-ups;

  • Why this is not good:
    Such a community is passively waiting to be fed some good news or bad news. It reminds me of user communities for enterprise software companies. They're waiting for that monthly call where you say things like - we're very excited about what's coming, and A, B, C features are taking longer than expected, but it will all be great soon.

• b/ Support questions management - basically Q&A channel for product issues;

  • Why this is not good:
    Would you say that your telco's company call center answering questions and solving clients' issues is catering to a community? Probably not, right? Everyone needs a way to solve product issues and bugs, etc., but that's not a community. That's support. And support can be part of the community but if it's the the only part, then it's not a community.

For web3 project there's a different danger; community often slides into:

• a/ Hype-machine and shilling game filled with requests for public support.

  • I think we've all seen discords like this filled with bots and a never-ending feed of spammy messages promoting something or asking you to fire up that tweet or message.

  • Why this is not good:
    Even though I don't mind airdrop farmers and hypers, they're part of every healthy economy, if this is your community, it's a community that will abandon you at first issue and they will crucify you on their way out.
    That is the real danger. They're there to take and receive, not to give or contribute.

• b/ Both versions from web2 issues also apply here. I've met web3 projects recently that have feature announcements as a main community interaction. They use different rethoric than web2 startups would use but final outcome is the same = not ideal.

Building a vibrant and friendly community is hard. It's like building a great product, only that the product is a community. It requires constant attention and experimentation. You are never done. Depending on the type of project you are building, you may need to build several different types of communities. If you're a web3 protocol-level project, you will be building "builders" and "users" communities. These are different people with different interests; they sit on different sides of the table. Imagine it like a marketplace model - developers are your sellers, and users are your buyers. You'd never mix those two and you'd never expect they need the same things.

There's a simple rule for spotting the real community - it's where fans and team communicate with each other, not shout at each other.

That's where fans and team work together to answer questions from newcomers or from people with issues. That's where you and your community believe in the same things and you have communicated these things and act on them consistently. And that's where fans and the team also have unscripted fun together.

I often say that communities go through modularization during the project life. That means, if all is going well, there are smaller (modular) communities popping out inside your larger community. That's a good thing. These smaller groups (modules) have informal leaders who attract certain people with their vision and actions. "Actions" is the crucial word there. Modularization allows for two things:

• a/ You can focus on informal leaders instead of every member individually;

• b/ You clearly see what topics and actions attract your community members' attention, and that should also tell you something about where your product could go.
  

How to Think About Community

So let's finally talk about the generic framework I use when considering building a community around any business. I like it simple because then it's doable 🙂

• The key to everything in business, and community is no exceptions, is to have a clear vision of what problem I am solving and for whom. It's possible that I am still looking for my perfect WHO-persona, but I need to be clear on my solution's JTBD (Jobs To Be Done).

• This means that I understand who we are working for, and what I want the community to stand for, and how they can help us. From here, I can start thinking about what we can/should provide in return for their support and help. This will be very different for each project.

  Said differently - You have to believe in and be doing something distinctive from others and you have to communicate it. That must be part of that community vision and it's also part of your brand vision. Something that sets you apart.

• I also think (often dream) about what different communities might be inside our global community - are they regional, are they topical, are they sales (or on-boarding) channels related, are there "suppliers like" and "buyer like" differences, and anything else that makes sense in my context. Maybe I want formalised partner program, maybe I want ambassadors/evangelists.

• Also what communication and interaction channels make sense for these different communities. Of course, I want as few channels as possible, without harming my ability to attract and communicate with members.

• One tactical thing I find very helpful -> there should always be a written "Community member handbook" of some kind, and the above info is a crucial part of it. Member handbook can be a simple blog post, article, document, or welcome video - or all of these - and you use it during onboarding new members, during search for community moderators, and even when you want to expand your community to new directions.

  Member handbook is great because it will make you think about things as you write it and it will give you an anchor as you will evolve and grow.

• The ideas and ideals transmission journey is: You -> Your Team -> Your Community -> and it creates Your Project perception and brand.

• Here is the scare consequence - it means it is all a reflection of You:

  • Your values

  • Your work ethic

  • Your ability to share the vision and story

  • Your ability to bring people along

  • Your ability to produce results

  • and, as I mentioned before, your vision for your project and community part in it.

Just think about everything you do on the distribution front of your project as a partly a community-building exercise. This way, if you have a newsletter, Twitter, Farcaster, Podcast, monthly Spaces, or discord calls - it must all be partly focused on community, and you should make sure it reflects your vision.

I certainly hope you will stick around and we will connect more.
If you like it - bring your friends - they may love it!

Find me as BFG (aka BrightFutureGuy) and let's connect!
- on X: https://twitter.com/aka_BFG
- on Farcaster: https://warpcast.com/bfg
- Web3 Magic Podcast on Substack - https://www.web3magic.xyz