How to Choose Your Community Initiatives
# Community
# Format: Playbooks
How to define the specific jobs your community should do for members and the business, so you can prioritize what to build first.
July 22, 2026
Joshua Zerkel
At a glance
- An initiative is a specific job the community does, more concrete than a vague aspiration like "engagement."
- Common initiatives: onboarding, peer support, product education, feedback collection, advocacy, events, customer connection, knowledge sharing.
- Every initiative should connect to a member need and a business goal.
- Prioritize by customer demand, business value, and team capacity, rather than by what sounds impressive in a deck.
- Each initiative implies specific resourcing: live programming, async discussion, content, groups, expert access, internal involvement.
- Don't design for every initiative at launch. Revisit as the community matures.
Introduction
I've reviewed a lot of community strategy decks that list ten or twelve things the community is supposed to do: reduce support tickets, drive product adoption, surface feedback, build advocacy, host events, create belonging. Every one of those is a reasonable thing for a community to eventually support. The problem is that a team trying to do all of them from day one usually ends up doing none of them well.
An initiative is more specific than a goal. A goal like "improve retention" tells you the direction. An initiative tells you the actual job: peer troubleshooting during onboarding, or a monthly space where power users trade advanced workflows. Initiatives are what you actually build toward, staff, and measure.
This guide is about identifying the initiatives that matter most for your community right now, connecting each one to a real member need and a real business outcome, and being honest about which ones you have the capacity to support well. A related Foundations guide covers how to choose which member segments to prioritize. This one assumes you know roughly who you're serving and focuses on what you'll actually build for them.
When this matters
This comes up most clearly right after a team has defined its community's purpose and chosen a priority segment, when the natural next question is, "Okay, so what does the community actually do for these people?" It's easy to answer that question with a long wish list instead of a short, deliberate set of jobs.
It also resurfaces when a community has been running for a while and feels scattered, when a team looks at its space and realizes there's a little bit of everything happening but nothing anchoring it. And it comes up whenever leadership asks the community team to justify its existence in terms the business recognizes, since a clear initiative is usually the fastest way to connect community activity to something a stakeholder already cares about.
What matters most
An initiative is a specific job
A goal is the outcome you're ultimately trying to reach, something like stronger advocacy or better retention. An initiative is the specific thing you build or run to move toward that outcome. "Build advocacy" is a goal. "Give customers a low-friction way to share a public review or case study after a successful implementation" is an initiative aimed at that goal. The initiative tells you what to build, who's involved, and roughly what success looks like. When I'm working through this with a team, I push them past the goal language until they can describe an actual member doing an actual thing inside the community. If you can't picture a specific person taking a specific action, you don't have an initiative yet. What you have is an aspiration.
Start from the common list, but don't treat it as a checklist
Most communities end up supporting some combination of onboarding, peer support, product education, feedback collection, advocacy, events, customer connection, and knowledge sharing. That list is a useful starting point for a brainstorm, and it stops being useful the moment it gets treated like a requirements document. I've seen teams treat it as a checklist to complete, building a little bit of programming against every item, which spreads effort so thin that no single initiative gets the attention it needs to actually work. Use the list to make sure you're not missing an obvious candidate, then narrow hard from there.
Every initiative needs two anchors: a member need and a business goal
An initiative that only serves the business feels extractive. Members can tell when a space exists purely to harvest feedback or generate case studies, and they participate less. An initiative that only serves members with no connection to a business outcome is hard to justify resourcing long-term, however well-intentioned. The initiatives worth building are the ones where a real member need and a real business goal point in the same direction. Peer troubleshooting during onboarding serves the member's need to get unblocked quickly and serves the business's need to reduce time-to-value and support load. Naming both sides explicitly makes it much easier to defend the initiative later when priorities get contested.
Prioritize on demand, value, and capacity
Once you have a real list of candidate initiatives, the prioritization question is concrete: how much are customers already asking for this, how much value would it create if it worked, and does your team actually have the people and time to support it well. I've watched teams prioritize the initiative that sounds most impressive in a board deck over the one members are actually asking for, and it rarely pays off. Advocacy programs look great in a slide, but if members aren't yet getting enough value to want to advocate, you're building the wrong thing first. Let real signal drive the order.
Match each initiative to how you'll run it
Every initiative implies a different kind of infrastructure. Peer support might live comfortably in asynchronous discussion threads. Product education might need structured content plus occasional live sessions. Advocacy often needs direct internal team involvement, someone reaching out personally rather than waiting for members to volunteer. Customer connection at the enterprise level might require a small, high-touch group with expert access rather than a broad open space. Naming how you'll run an initiative, before you commit to it, is often what reveals whether your team can actually support it right now.
Putting it into practice
1. Brainstorm every plausible initiative for your community.
Draw from the common list, member feedback, and internal stakeholder requests. Cast a wide net here. You'll narrow later.
2. Rewrite each one as a specific job.
Turn vague entries like "build community" into concrete descriptions of what a member does and what outcome results.
3. Name the member need and business goal each initiative serves.
For every candidate, write one sentence for each side. If you can't fill in the business side, flag it and come back to it later.
4. Score each initiative on demand, value, and capacity.
Rate what you're hearing from customers, what impact it could realistically have, and whether your team can resource it today.
5. Identify how you'll run each top initiative.
For your highest-scoring candidates, note whether they need live programming, async discussion, content, small groups, expert access, or internal team time.
6. Select two to four initiatives to build for first.
Choose the combination your team can actually resource well right now, even if it's shorter than what you could defend in a planning meeting.
7. Set a review point to revisit the list.
Pick a checkpoint, often 90 days after launch, to reassess which initiatives are working, which aren't, and what should be added next.
Where teams get stuck
The most common obstacle is stakeholder pressure to cover every department's interest at once. Sales wants advocacy content, support wants deflection, product wants feedback loops, and each function pushes for its initiative to be included from day one. Experienced teams handle this by showing the tradeoff plainly: a community trying to serve every function immediately usually serves none of them well, and a focused launch that proves value in one or two areas builds the credibility to expand later.
Another common snag is confusing activity with initiative fulfillment. A team might run events regularly and assume "events" is a working initiative, without checking whether those events are actually producing the member or business outcome they were meant to. Activity is a signal worth watching, but it isn't the same as confirming the initiative works.
Teams also get stuck waiting for perfect certainty before committing to an initiative. You won't know for sure which ones will land until you try. Pick your best-supported candidates based on available evidence, commit to them for a defined period, and use real behavior to adjust.
Before you move on
- You've brainstormed the full range of plausible initiatives.
- You've rewritten each as a specific job rather than a vague goal.
- You've named the member need and business goal for each candidate.
- You've scored candidates on demand, value, and team capacity.
- You've identified how you'll run each top initiative.
- You've selected two to four initiatives to build for first.
- You've set a checkpoint to revisit the list.
What good looks like
Planning element | Example output |
|---|---|
Candidate initiative | Peer troubleshooting during onboarding |
Member need | Get unblocked quickly without waiting on a support ticket |
Business goal | Reduce time-to-value and support ticket volume |
Demand signal | High volume of repeat setup questions in support tickets |
How you'll run it | Asynchronous discussion space plus a searchable FAQ thread |
Priority tier | Launch initiative (tier 1) |
How to know it's working
Track whether the specific member behavior the initiative was meant to produce is actually happening. Look for peer replies on troubleshooting threads, advocacy submissions, or feedback volume, not just overall activity levels. Watch whether the business signal you named connects, even loosely, to that activity, such as a shift in support ticket themes or sales team reports about faster onboarding conversations. Pay attention to qualitative comments from members about whether the space is meeting the need you designed it for. And keep an eye on whether your team can sustain the initiative with current resourcing or whether it's quietly draining more time than planned, since that's often the first sign an initiative needs to be scaled back or restructured.
Key takeaways
- An initiative is a specific job the community does, more concrete than a vague goal.
- Anchor every initiative in both a member need and a business outcome.
- Prioritize by real demand, value, and capacity, rather than ambition.
- Match each initiative to how you'll actually run it.
- Start with two to four initiatives and revisit the list as the community matures.
Common questions
How many initiatives should we launch with?
Two to four, depending on your team's capacity. Fewer, well-supported initiatives create more member and business value than a longer list that's thinly resourced. Add more once the first ones are demonstrably working.
What if an initiative only serves the business, not members?
Don't build it as a standalone community initiative yet. Community activity that only benefits the business tends to feel extractive to members and drives disengagement. Find the member need it could also serve, or address that goal through a different channel.
How do we know when to add a new initiative?
Look for consistent signals: repeated member requests, a gap your current initiatives aren't covering, or a new business priority with a genuine member-side need attached. Confirm your existing initiatives are stable before adding another.
Like
Comments (0)
Popular
ďťż
Dive in
Related
Resource
How to Define Your Community Purpose and Goals
By Joshua Zerkel â˘Â Jul 22nd, 2026 ⢠Views 7
Resource
How to Define Your Community Purpose and Goals
By Joshua Zerkel â˘Â Jul 22nd, 2026 ⢠Views 7