Most companies organize go-to-market vertically. Product owns roadmap and prioritization. Marketing owns demand and narrative. Sales owns revenue. Customer success owns retention and expansion. Community gets put somewhere on that org chart, but customers don’t experience a company in those same departmental slices.
Community tends to cut across them.
At Asana, for example, the forum, ambassador program, events, and other community surfaces gave us visibility into how people were learning the product, where teams were getting stuck, which use cases were spreading inside organizations, and who was becoming an advocate. Those signals could matter to product, marketing, sales, customer success, and other teams for different reasons.
The useful question was rarely “which outcome does community own?” It was usually “how do we make sure what community is seeing actually changes how the rest of the company works?” That’s what this framework is designed to help with.
I’ve written separately about what community is doing once somebody has already become a customer, which tends to be the least worked-out part of this. What follows is the operating version of that argument, so I won’t re-make the case here.
The model
Community-integrated GTM treats community as a horizontal source of customer participation, signal, and connection across the customer lifecycle. The model has a sequence:
Alignment
Integration
Amplification
I use the sequence intentionally. I’ve seen companies try to jump directly to amplification by asking community to generate more advocacy, more pipeline, more referrals, more content, or more product feedback. Sometimes that produces activity. It rarely fixes the underlying operating problem if teams are still working from different assumptions about the customer.
Alignment
Alignment starts with shared inputs.
Different GTM teams naturally see different parts of the customer. Sales hears objections during evaluation. Customer success sees adoption friction after the contract is signed. Product sees feature usage and requests. Marketing sees which stories and messages get attention. Community can see pieces of all of those things, often in the same conversation.
The problem starts when each team builds its own version of customer reality from its own slice of the evidence.
Alignment means creating a shared enough view of the customer that teams can make related decisions from related information. They don’t need to agree about everything. They do need access to the signals that could materially change their decisions.
Questions I’d ask:
What customer signals are showing up in community today?
Which teams would make different decisions if they had those signals?
Where are teams currently working from different assumptions about customer needs, language, behavior, or friction?
Which business priorities matter enough right now that community should be paying particular attention to them?
A company is reasonably aligned when community has a clear connection to current business priorities and the relevant teams have a shared understanding of what community can see that they cannot see as easily on their own.
Integration
Shared information doesn’t do much sitting in a recap deck.
Integration is the operational part of the framework. Customer signal has to enter the places where decisions actually get made: roadmap discussions, positioning reviews, sales enablement, onboarding design, expansion planning, content planning, support processes, and whatever other operating loops matter in that company.
This is where I’ve seen a lot of well-intentioned community work stall. A community team may produce an excellent monthly report full of member feedback and emerging patterns. People read it, say it’s interesting, and then go back to their existing workflows.
Integration asks a more practical question: where does this information need to show up so somebody can actually use it?
Questions I’d ask:
Where are the recurring decisions that community insight should inform?
Who owns those decisions?
What format makes the signal usable for that person or team, and how often does it need to arrive?
What happens after the signal is shared, and can community see whether anything changed as a result?
A company is integrated when community signal has an expected route into relevant operating processes, with enough context that another team can evaluate and act on it.
Amplification
Once alignment and integration are working, community can strengthen things the company is already trying to do.
Before somebody buys, that tends to be easier to describe. Afterward, the description tends to collapse into engagement, which doesn’t give anyone a decision to make. It’s more useful to organize this part around what’s actually happening to the customer.
Adoption. A new customer sees how a comparable team made something work, tries a version of it, and reaches whatever behavior counts as adopted for your product. Customer success and education usually own the outcome, with community supplying the peer examples. Before anything shows up in an adoption metric, the thing to watch is whether the customers who saw those examples get there sooner than the ones who didn’t.
Expansion. This takes two shapes. A team goes further with what it already has, picking up capabilities it had ignored or moving from one workflow into several. Or somebody encounters a use case belonging to a different team, carries it back, and that other team starts using the product for its own reasons. The account team owns the follow-up either way, and community owns making the possibility visible in the first place. For the deepening version, the early indicator is which capabilities members are asking each other about before those requests reach sales. For the cross-team version, it’s how many distinct job functions from a single account are participating at all, which is countable long before anything reaches ARR. Both are participation counts, so report them as leading signs rather than as the outcome itself. Count them without making a show of it, as well. People share differently once they know a thing is being scored, which is its own reason to keep this a background measure rather than a program goal.
Retention. Accumulated participation raises what a switch would actually cost. Customer success owns the outcome, with community creating the conditions. The early indicator worth watching is whether that depth is developing in accounts outside your current top tier.
Advocacy. Value received becomes value produced. Community and customer marketing share this one. Unprompted member-to-member help moves well ahead of case studies or reference calls, which makes it the more useful thing to watch.
Community programs can also create their own direct outcomes. At Asana, our community programs influenced substantial pipeline, and community members were more likely to be on paid plans. Both of those are correlations, and I’d describe them the same careful way I’d describe anything else here. The larger lesson for me was how much more useful those programs became when they were connected to the rest of the business.
Questions I’d ask:
Which existing GTM outcome is community helping improve?
What behavior or signal connects community participation to that outcome?
Can we see an intermediate effect before the final business metric moves?
Are we strengthening a working system, or asking community to compensate for a broken one?
That last question matters. Community can help customers learn from each other. It cannot repair a product nobody wants, a pricing model customers don’t understand, or an onboarding experience that fundamentally doesn’t work. I’ve seen community asked to absorb problems that belong somewhere else. That drains the team and frustrates the members.
In practice
I wouldn’t start by reorganizing the community team or buying another platform. Start with one business priority where community already has useful signal or participation.
For example, suppose the business is focused on improving activation. Community conversations show that new customers repeatedly struggle with the same handoff between individual setup and team adoption. Rather than setting a goal to increase community posts, you might route that pattern into onboarding and education, recruit experienced members to share team setup examples, and track whether the relevant activation behavior improves among customers exposed to those resources.
The point is to connect community activity to a business problem through an observable mechanism. Otherwise you’re left with two charts that moved at roughly the same time and a lot of optimism about causation.
What to watch for
Community-integrated GTM doesn’t require community to report to a particular executive. I’ve had opinions about organizational design over the years, and context matters too much for one reporting line to be universally right.
It also doesn’t require every customer signal to become a cross-functional initiative. That would create its own bureaucracy. Some feedback is anecdotal. Some requests are specific to a small segment. Some patterns matter deeply to members and very little to the current business strategy.
The work is deciding which signals deserve broader attention, where they should go, and whether the organization has a way to use them.
Where the framework stops helping is attribution. Each of the four amplification paths is plausible and none of them is proven, because the data that would separate cause from correlation usually sits in systems nobody has connected. Say so in the reporting. In my experience executives trust the rest of the number more when you do.
Questions to work through
If you want to see how integrated community is today, pick one meaningful customer pattern that surfaced in the last month and trace it.
Where did it appear? Who saw it? Who else needed to know? Did it enter a decision process? Did anything happen? Did the community team or the members who raised it ever learn what happened next?
You can learn a surprising amount about the operating model from that one example.
The model at a glance
Alignment. Shared customer signal and shared connection to current business priorities.
Integration. Community signal and participation enter the workflows where GTM decisions get made.
Amplification. Community strengthens adoption, expansion, retention, and advocacy through those integrated loops, each with an owner and an early indicator that moves before the business metric does.
The sequence matters because amplification is easier to sustain when the organization is aligned enough to recognize useful signal and integrated enough to act on it.
Apply the code
If you only do one thing with this framework, pick one business priority and run it through these five steps:
Name the business priority. Choose one outcome the company already cares about: adoption, retention, expansion, pipeline, or something equally concrete.
Identify what community can see. Write down the customer behaviors, questions, language, friction, or participation patterns that community is surfacing around that priority.
Find the people and decisions that need that signal. List the GTM teams involved and the actual decision or workflow where the information could change what happens next.
Build one operating loop. Decide who shares the signal, where it goes, who owns the response, and how community learns what happened. Keep it small enough that people will actually use it.
Look for amplification. Track whether the loop improves an observable behavior or intermediate outcome before claiming a final business result. If nothing changes, fix the loop before adding more programs.
Checklist
We can name the current business priority community is supporting.
We know what relevant customer signal community can see.
The teams that need that signal receive it in a usable way.
The signal enters a real decision or workflow, rather than ending in a report.
Someone owns what happens next, and community can see whether action was taken.
We can point to an observable behavior or outcome that should change if the integration is working.
For any post-sale claim, we’ve named the path, the owner, and the early indicator, and we’ve said out loud what we can’t yet separate.
If you can’t check several of these boxes, I’d work there before trying to increase community activity. More activity flowing through a disconnected system usually gives you more disconnected information.
Try this
Mark which of the four amplification paths your community is actually being measured on right now: adoption, expansion, retention, or advocacy. In the teams I’ve worked with, the answer is usually none of them, and participation volume is standing in for all four at once. Pick the one your business cares most about this quarter, write a single sentence naming the behavior that matters and the early indicator you’d watch first, and take it to whoever owns that outcome inside your company. If you want the longer argument for community as infrastructure rather than a program, that’s most of what The Community Code is about.