One of the more consistent patterns I’ve seen across companies is a mismatch between where community sits and what it actually does.
On paper, it almost always lives inside a single function. Marketing, customer success, or support, depending on how it got started. That part’s logical. Community begins as a program, and programs need a home, a budget, and someone accountable for them.
But once the community starts working, the shape of the work changes quickly.
Customers answer each other’s questions. They share how they’re using the product in ways that don’t show up in official documentation. They create content, run events, and surface patterns that would otherwise take a long time to identify. You start to see influence show up in onboarding, expansion, product decisions, and even how deals move forward.
At that point, the work is no longer contained within a single function, even if the team still is.
The organization still makes sense of community through the structure it already has in place, so it gets interpreted through the lens of the team it reports into. If it sits in marketing, it looks like an advocacy or content engine. If it sits in customer success, it’s framed around adoption and retention. If it sits in support, it becomes a way to deflect tickets and scale knowledge.
All of those views are accurate. They’re also incomplete.
They describe the same underlying behavior from different angles, but one of those angles becomes dominant because it aligns with how the team is measured and funded. The rest get treated as secondary benefits rather than core outcomes.
You can see the effect of that in how decisions get made. The roadmap follows the priorities of the parent team. Success is measured in a way that reflects one function’s goals. Resourcing follows the same pattern, reinforcing the idea that community belongs to that team.
From the outside, it can look like community is working across the business. From the inside, it often feels like you’re doing cross-functional work from inside a single-functional box.
There’s an assumption that once community proves its value, the structure, buy-in, and resourcing will evolve around it. In practice, that doesn’t happen.
“Community-led growth” framing helped move the conversation forward. It gave community teams a way to talk about impact in terms the business understood and made it easier to connect community work to outcomes.
At the same time, it raised the stakes on what we were claiming community could do, without changing what organizations were set up to support.
We weren’t just talking about engagement anymore. We were influencing revenue, retention, product adoption, and expansion across the business. That’s a much broader scope, and it implies a different level of ownership and integration.
The issue is most organizations didn’t adjust around that shift. In trying to elevate community, we set expectations that most organizations weren’t actually equipped to meet.
Community stayed where it was. Reporting lines didn’t change. Budgets didn’t scale in proportion to the expectations. The operating model remained functionally anchored.
That creates a mismatch.
Community teams are expected to drive outcomes across marketing, product, and customer success while still operating within the constraints of a single function’s goals, budget, and planning cycle.
That mismatch shows up pretty quickly, both strategically and in the day-to-day work.
This pattern is familiar. You spend time translating community into the language of different teams instead of operating it as a shared system. You get pulled toward one set of priorities even when others in the business have more leverage. You end up proving value repeatedly because each cross-functional team evaluates community through its own lens.
I’ve seen this play out very directly.
In more than one case, I’ve been told explicitly that the impact community was having on other teams didn’t matter, only what it was doing for the team it reported into. In some cases, that even meant being asked to stop work that was clearly valuable elsewhere in the business because it didn’t map cleanly to that team’s goals.
It’s not malicious. It’s how organizations are designed to operate.
Teams are accountable for their own outcomes, and anything that doesn’t clearly support those outcomes gets deprioritized. When community sits inside a single function, it gets pulled into that same logic, even when the work itself is clearly creating value across the business.
A more effective way to frame this is to stop treating community as a program or a channel and instead look at it as part of the go-to-market system itself.
I call this community-integrated GTM.
If you look at how customers actually experience a product, a meaningful portion of what determines whether they’re successful doesn’t come directly from the company. It comes from other customers. How they explain things, how they share examples, how they validate decisions, and how they help each other get unstuck.
At Asana, this showed up in clear, measurable ways. Community members were more likely to be on paid plans and saw a lift in team collaboration. That wasn’t driven by isolated programs. It was the result of customers learning from each other and applying those learnings inside their teams.
The forum and ambassador program reinforced the same pattern. The forum surfaced real usage patterns quickly, often ahead of formal research. The ambassador program created a layer of customers actively teaching others, which supported onboarding, education, and advocacy simultaneously.
Community is one mechanism showing up and creating value across the business.
But most organizations aren’t designed to operate around shared mechanisms. They’re designed around functions, each with their own goals and planning processes. Community cuts across those boundaries, but the structure around it does not. That’s why so many community teams end up stuck in a single function, even when their impact clearly isn’t.
Most community leaders don’t control org design. That’s not where the leverage is. The leverage is in how your work is designed and how it shows up across the business.
There are a few shifts that make this more practical in day-to-day work.
One of the most effective shifts is to design around behaviors that create value in multiple places.
It’s easy to build a roadmap that mirrors the priorities of your parent team. If you sit in marketing, you end up with campaigns and content programs. If you sit in customer success, you focus on onboarding and retention. That alignment makes sense locally, but it reinforces the idea that community exists to serve that one function.
A more effective approach is to start with behaviors that produce multiple outcomes at once.
At Asana, the ambassador program is a clear example. Ambassadors ran events, answered questions, created content, and shared how they were using the product. That layer of participation drove awareness, education, and product insight. It didn’t need to be split into separate programs for each function because the behavior itself created value across them.
You can apply the same thinking at a smaller scale. A customer-led session can support onboarding while generating content and surfacing product questions. A strong forum thread can resolve a support issue, become a reusable resource, and reveal how customers are actually using the product.
When you design around those behaviors, the cross-functional value becomes visible without forcing the narrative.
Another shift is making your work easier for other teams to recognize.
Community work is often visible in the sense that people can see the activity, but it’s not always clear how that activity connects to what each stakeholder team cares about. A busy forum or a well-attended event doesn’t automatically translate into something meaningful for product, sales, or customer success.
Instead of relying on a single narrative, connect your work to how different teams already operate. Speak their language when you report on it.
At Asana, one of the most effective ways to build alignment with product was to point to specific product decisions that changed because of patterns in the community. That made the value concrete. It wasn’t a general statement about feedback. It was a direct link between what customers were doing and what the product team decided to build.
With customer success, the conversation focused on time to value. Where customers were getting unstuck faster because they could learn from each other. With marketing, it was about credibility and how community-driven content influenced how people understood the product.
This doesn’t require perfect attribution. It requires enough clarity that each team can see how community connects to their goals.
It’s also important to create small points of dependency instead of trying to reposition community all at once.
Large structural changes require executive alignment, which most community teams don’t have the authority to drive. Instead, what you can do is create specific examples where other teams rely on community to achieve their goals.
That might be a product team using the community to get faster feedback, or a customer success team incorporating community into onboarding. Each of those moments builds familiarity and trust. As they accumulate, other teams begin to treat community as part of how they operate.
The final piece is being deliberate about how community gets defined internally.
This shows up in everyday language. The forum becomes “the place for support questions.” The program becomes “the advocacy engine.” Events become “a marketing channel.”
Those labels are convenient, but they narrow how people understand the work. Over time, they shape expectations and make it harder to expand beyond that definition.
Being precise in how you describe community helps keep the scope aligned with what’s actually happening. Community is where customers interact with each other in ways that shape how the product is learned, adopted, and used.
None of this immediately changes your reporting line, but it does change how your work is understood.
That shift builds through repeated exposure to the same pattern: customers interacting with each other in ways that move the business forward. As that becomes visible, teams start to see how community connects to their outcomes, and it stops being treated as something owned by one function.
At that point, community isn’t something the business supports. It’s something the business depends on.
Josh is Head of Marketing & Community at Gradual. He led community at Asana and Evernote, and advises numerous companies on community and GTM strategy. He's the author of The Community Code.
