One thing I’ve been noticing in conversations about AI is how quickly people move from “can it produce the thing?” to “great, now we have the thing.” I understand why that happens. If you’ve ever had to turn a pile of call notes, support tickets, survey responses, Slack threads, and half-remembered customer comments into something usable, the appeal is pretty obvious. AI can take a messy input and turn it into a tidy summary. It can find themes. It can draft the recap. It can make the blank page less blank, which isn’t nothing.

I don’t think this is bad. I use AI, and I’m interested in what it makes possible. I’m also not especially nostalgic for the days when every customer insight had to be manually assembled by someone squinting at a spreadsheet at 11:00 p.m. while wondering whether “miscellaneous feedback” was a category or a cry for help. There are real gains here, especially for teams that have been doing too much of this work manually for too long.

The problem is that a polished output can make the work feel more finished than it actually is. A summary can tell you what themes showed up, but it doesn’t necessarily tell you what those themes mean. A recommendation can sound reasonable without being especially useful for your specific company, customer base, product maturity, team structure, or timing. And when the original signal has already passed through several layers of interpretation before AI ever touches it, the final output can look useful while still missing the thing that mattered most.

The answer is usually the beginning of the work

That’s where I think a lot of GTM teams are going to get themselves into trouble. The issue isn’t that AI will always be wrong. That would be easier, honestly. If the output were obviously terrible, people would know to ignore it. The harder problem is that a lot of AI-generated output will be basically reasonable. It’ll sound organized. It’ll use the right words. It’ll include the expected steps. It’ll probably be good enough to drop into a doc, share in a meeting, or turn into the next slide in the deck.

And because it looks useful, teams may stop too early.

Take a simple example. A company asks an AI tool how to build a community initiative around a product launch. The answer will probably include some version of the usual steps: define the audience, set goals, recruit early advocates, create programming, gather feedback, measure engagement, and connect the work back to business outcomes. That’s all fine. It’s also the kind of answer that could apply to almost any company, which means it doesn’t yet apply to this company.

The harder questions are more specific. Is this product launch aimed at existing customers who already trust the company, or a new audience that has no reason to care yet? Is the product asking people to adopt a genuinely new behavior, or is it a better version of something they already understand? Does the community team have enough influence to shape the launch before decisions are made, or are they being asked to create excitement after the strategy has already been locked? Are customers confused, skeptical, excited, tired, or politely saying “interesting” while meaning something else entirely?

Those are the details that determine whether the answer is useful. They’re also the details most likely to get flattened when teams optimize too heavily for speed, summarization, and outputs that look more complete than they really are.

Where the plausible answer breaks down

This isn’t only a community problem. It shows up across GTM because every function has its own way of interpreting customer signal. Marketing hears language. Sales hears objections. Customer Success hears risk. Product hears requests, friction, and sometimes noise, depending on the week and who’s reading the recap.

That’s normal. Each team has different responsibilities, so of course they listen differently. The problem is that AI can make those translations happen faster without making them better. It can take the same messy signal and turn it into a smoother version of whatever the organization already knows how to process.

You can see this in a few common places:

• In customer feedback, AI can summarize hundreds of comments into a few themes. “Customers want better onboarding” might be accurate, but it could mean the product is confusing, the docs are weak, implementation is underdeveloped, peer examples are missing, or customers don’t understand the value they’re supposed to get. Those are different problems, even if they collapse into the same summary.

• In sales, AI can turn community conversations, webinar questions, support tickets, and product usage signals into an account brief. That’s useful, especially when the alternative is asking someone to spelunk through five systems and somehow emerge with insight. But the brief still needs judgment. Is the customer showing buying intent, trying to solve a peer problem, or giving the company useful context for a longer relationship?

• In product, AI can cluster feature requests and complaints. That can help teams see patterns faster, but it doesn’t answer whether the request is the real need or the workaround customers invented because they didn’t know what else to ask for. Anyone who’s been around product feedback for more than twelve minutes has seen this.

I’ve seen versions of this throughout my own work. At Asana, community conversations often revealed where customers were trying to understand not just a feature, but a way of working. Someone might ask a tactical question about a workflow, a template, or a permission setting, but the real issue underneath was often broader: how do I get my team to collaborate differently, how do I make this process stick, or how do I translate what Asana can do into the way my organization actually works?

A tidy summary might call that “product education” or “workflow guidance.” That’s not wrong, exactly. But it misses the more useful point. The customer wasn’t only asking how to use the tool. They were trying to figure out how to change behavior inside their company. That’s a different kind of problem, and it requires a different kind of response.

At Evernote, the pattern showed up differently. Customers often had deeply personal systems for managing their work and lives, and when something changed, the reaction wasn’t only about a feature. It was about trust, habit, memory, and a workflow they had built around the product over years. If you flattened that into “customers dislike change,” you technically captured something. You also lost most of what mattered.

And now at Gradual, I see the operating version of this problem all the time. Community teams are sitting on useful signal, but that signal only becomes business value if it moves somewhere. If it stays trapped in the platform, or gets summarized into a vague monthly recap, it’s not going to help Sales, Product, Marketing, or Customer Success make better decisions. It has to connect to the systems and conversations where decisions actually happen.

This is why I keep coming back to customer signal as an operating problem, not only an information problem. Most companies already have more signal than they can use. They have support tickets, call transcripts, CRM notes, community discussions, survey data, product analytics, win-loss notes, social comments, event questions, advisory board feedback, and the occasional Slack thread where one person says the thing everyone should probably be paying attention to.

The issue is how that signal moves through the company.

It gets summarized too early. It gets stripped of context. It gets translated into whatever each function already cares about. None of those translations are inherently wrong, but each one narrows the signal in a different way. AI can make that narrowing faster, more polished, and harder to notice.

Very exciting. Everyone gets a prettier version of the same problem.

Community preserves some of what summaries lose

That’s where community becomes important in a way that’s easy to underestimate. Community isn’t useful here because it gives the company one more place to distribute AI-generated content. Please, no. We have enough channels distributing vaguely useful answers already.

Community matters because it gives people a place to make sense of the answer together. Members can test it against lived experience, challenge what sounds too generic, add the caveats that actually matter, and surface the context that would otherwise stay hidden.

When someone asks a question in a community, the answer they receive is often only part of the value. The surrounding conversation is usually just as useful. One person gives the official answer. Another describes the workaround. Someone else explains why the answer worked for them, but only after they changed the process internally. Another person asks the question underneath the question. Occasionally someone says, gently or not, “I wouldn’t start there.”

That’s hard to capture in a neat executive summary. It’s also exactly what makes the exchange useful.

A healthy community shows when customers are asking the same question in five different ways. It reveals when the official positioning doesn’t match how people actually describe the problem. It helps teams understand whether a feature request is really about product capability, confidence, workflow change, peer validation, or something else entirely. None of that means every community thread should become an executive memo. Members aren’t there to become raw material for your next GTM strategy doc, which should not need saying, but here we are.

The value comes from stewarding the system well enough that customers are willing to be honest with each other. If the company is paying attention, that honesty becomes a source of context the rest of the business usually struggles to preserve.

The interpretation work has to go somewhere

This matters more as AI becomes embedded in GTM work. The more teams use AI to produce summaries, recommendations, briefs, enablement content, and playbooks, the more they need ways to test whether those outputs are actually useful.

I’d be less interested in asking how AI can help a company create more community content. That question might matter sometimes, but it’s not the most useful starting point. I’d rather ask whether customers are better able to understand, trust, and apply what the company is putting into the world.

A few questions make this more concrete:

• Where do customers go when the official answer is technically correct, but still not specific enough to help them act?

• What do customers understand after talking with peers that they didn’t understand from our documentation, onboarding, campaigns, or sales materials?

• Which customer conversations are helping the business make better decisions, and where does that learning actually go?

• Where are we preserving nuance from community interactions, and where are we flattening everything into themes that are easier to present than act on?

• What decisions have changed because of what customers helped each other understand?

That last question is often where the useful work starts. It moves community away from being a place where engagement happens and toward being part of how the business learns.

This is also where the conversation gets uncomfortable. If community is part of interpretation, then the community team can’t be treated as a peripheral engagement function. The work has to connect to customer education, product learning, lifecycle programs, sales enablement, support, and executive decision-making. Otherwise the signal stays in the community, people admire it, and nothing changes.

AI won’t fix that. It may even make it easier to ignore, because the summary will look productive.

What I’d watch for next

The companies that use community well in this next phase won’t be the ones that simply add AI to the community calendar and declare themselves modern. They’ll use AI where it actually helps: synthesis, routing, drafting, pattern recognition, and reducing some of the manual work that makes community and GTM operations more ridiculous than they need to be.

But they’ll also be careful about what AI can’t do by itself. It can produce an answer, but it doesn’t know whether customers trust the answer. It can cluster feedback, but it doesn’t automatically understand the emotional stakes underneath it. It can draft a playbook, but it doesn’t know which parts will break inside a specific organization with specific people, incentives, history, and politics.

Community is one of the few systems that can help with that, assuming the business treats it like a system and not a content bin. It gives customers a place to interpret information together, and it gives the company a way to see how that interpretation actually happens.

That’s the part I’d pay attention to. As AI gives everyone more answers, the advantage may come from understanding which answers mean something, which ones don’t, and what customers need from each other before they’re ready to act.

I’d love to hear where you’re seeing this show up. Where does AI-generated synthesis help your team move faster, and where do you still need human context, customer interpretation, or peer discussion before the output becomes useful?

Decoded Takeaways

AI can help GTM teams produce more organized summaries, faster briefs, better first drafts, and more neatly packaged recommendations. That’s useful, especially for teams that have been manually stitching customer signal together across too many disconnected systems. The risk is that polished outputs can make teams feel like the work is done before they’ve actually understood what the output means.

Community becomes more important in that environment because it preserves context that summaries often lose. The useful signal frequently shows up around the answer: the caveats, workarounds, questions, disagreements, examples, and peer interpretation that make advice usable in the real world.

For GTM teams, the practical question isn’t whether AI helps produce more. It probably does. The better question is whether customers are making better decisions because of what the company puts into the world. Community can help answer that, but only when the business treats it as part of how it learns, not just another channel for distributing content.

Related Posts

• AI Without Community Doesn’t Work in GTM

• Even AI Agents End Up Building Communities

• The Efficiency Trap in AI-Powered Customer Experience

Resources and upcoming events

I recently joined Todd Nilson from Clocktower Advisors on the “Talk About Your Community” livestream to talk about community, GTM, and how organizations can think more clearly about the role community plays in growth and customer trust. Check it out here.

Packt’s Yukta Kandhari is hosting me on July 15th for a webinar about community, AI, and customer trust. If you’re thinking through how AI changes the way customers learn, evaluate information, and engage with companies, this will be a useful conversation. RSVP here.

And a small book note: The Community Code was just featured in the SFSU Alumni Magazine, which was a very nice full-circle moment as an SFSU alum.

That came up early in my conversation with Vera DeVera, who led community at Watershed. Many of the sustainability professionals she worked with sit inside enterprise companies with tens of thousands of employees, yet the actual sustainability team may consist of one to five people.

They’re expected to influence complex decisions across finance, operations, legal, procurement, and leadership. In many cases, the role itself is still new. There may not be an established playbook, a large internal team, or a long line of experienced peers sitting nearby.

The company is large. The work can still feel very solitary.

Vera has spent much of her career building communities for people in that kind of position. Before Watershed, she built programs at early-stage companies where emerging professional roles were trying to establish themselves at the same time as the companies serving them.

What she’s building now gives sustainability leaders something they often can’t get inside their own organizations: a team of peers who understand the work.

People arrive through different doors

Vera’s own path into sustainability wasn’t traditional.

She came from community, not environmental science. What drew her to Watershed was the chance to bring her professional experience into a company whose mission aligned with her personal values.

The people in the community have similarly varied backgrounds.

Some studied environmental science and built their careers around the field. Others volunteered to lead a workplace recycling or sustainability effort, became more involved over time, and eventually helped create a formal role inside the company.

That range matters because emerging functions rarely develop in a straight line.

People are learning the technical work while also figuring out how to explain it internally, secure resources, and influence leaders who may not understand why it matters yet. They’re often developing the role at the same time they’re performing it.

Community becomes useful because it gives them access to people at different points along the same path.

Someone who has just inherited sustainability responsibilities can learn from someone who built a program two years earlier. A more experienced leader can compare notes with peers facing the same regulatory or organizational pressure. The expertise doesn’t flow in only one direction.

The four C’s

Vera describes community through four C’s:

• Connection

• Collaboration

• Commiseration

• Celebration

The inclusion of commiseration is important.

Professional communities often emphasize expertise, best practices, and success stories. Those things are useful, but people also need somewhere to say that the work isn’t going well.

That can be difficult inside a company.

A sustainability leader may be trying to build support for a new initiative, complete a complicated reporting process, or secure headcount. Admitting uncertainty internally can carry political or professional risk, especially when the function is already fighting for credibility.

A trusted peer community gives people somewhere to be more honest.

They can say, “I’m stuck,” or “I tried this and it failed,” and hear from someone who has dealt with something similar. The conversation can remain private enough to be useful and specific enough to lead to action.

That kind of safety has practical value. People surface problems earlier, learn from one another’s mistakes, and gain confidence before returning to the internal conversations where they still have to make the case.

Community as an external team

Vera described the community as something close to an extended team.

That’s more than a nice metaphor.

She has watched people meet through dinners and events, become accountability partners, and continue helping each other across companies and cities. Some members now have someone they can call when they’re facing a problem their internal colleagues don’t fully understand.

That relationship changes the experience of the role.

The member still has to do the work inside their own company. Community doesn’t remove the organizational constraints, and it doesn’t give them formal authority. What it can provide is a place to test ideas, compare experience, and avoid starting from scratch every time.

For emerging functions, that’s a substantial advantage.

The community also helps members become more influential inside their organizations. They can bring back examples, language, approaches, and evidence from peers who have faced similar resistance. The community gives them a broader base of practical knowledge than their internal team alone could provide.

Listening before building

When Vera joined Watershed, the company had already created the community role. She still didn’t start with a predetermined program.

She began with a listening tour.

Internally, she talked with customer success, product, and other GTM teams that were already close to customers. Externally, she spoke with dozens of customers and asked questions about how they learned, what problems they were facing, how they wanted to connect with peers, and what they could teach others.

That last question is especially useful.

Community discovery often focuses on what people need. Vera also looked for what they could contribute.

She wanted to identify the people who had experience worth sharing, then create the conditions where that experience could help someone else. That approach treats members as participants in the value creation, rather than an audience waiting for the company to deliver everything.

It also reflects something I wrote about in The Community Code: the company can design and steward the system, but much of the value comes from what members create together.

Trust is built through curation

Vera’s work includes a lot of deliberate matchmaking.

She pays attention to who is struggling with a particular problem, who has recently solved something similar, and who might benefit from being in the same room. Sometimes the most useful outcome from an event isn’t the content on stage. It’s the person someone meets over dinner.

That kind of curation can look informal from the outside. It still requires judgment.

A good community builder notices patterns, remembers context, and understands enough about the members to make useful connections. The goal isn’t to force relationships. It’s to create enough proximity and relevance for the right conversations to happen.

This is one area where scale can become misleading.

A community may have thousands of members, but the value often appears through much smaller interactions. One introduction, one peer conversation, or one honest admission can change how someone approaches the work.

The numbers matter. They don’t explain the whole experience.

The business value follows the member value

Watershed didn’t create community only because sustainability leaders needed friends.

The company also sees community as a growth and retention driver. Customers who are more connected, more confident, and more successful are more likely to stay, advocate, and help others understand the value of the work.

Those business outcomes are real.

They depend on the member value coming first.

A community built primarily to extract advocacy will eventually feel extractive. A community that helps members become better at their jobs creates the conditions for advocacy to develop more naturally.

Vera’s approach starts with the work people are trying to do.

How can they become more capable? How can they feel less isolated? How can they gain more influence in rooms where they may not currently have much power?

When the community helps answer those questions, the relationship with the company becomes stronger for understandable reasons.

What this adds to the broader conversation

We spend a lot of time talking about how community creates engagement.

Vera’s example is more specific.

The community is filling an organizational gap.

It gives people access to peers their employer may not be able to provide. It creates a place for practical honesty that may not exist inside the company. It helps members develop influence in a function that is still establishing its role.

That’s a more consequential form of value than keeping people active in a platform.

It also shows why community can matter most in emerging or under-resourced roles. The need isn’t simply information. People need examples, language, reassurance, and relationships with others who understand the stakes.

A content library can help with part of that. A trusted peer usually helps with more.

Watch the conversation

In the full interview, Vera and I talk about:

• How her personal values led her into sustainability community work

• Why emerging professional roles often need community the most

• How she conducted internal and customer listening tours

• The role of peer safety and commiseration

• How curated relationships turn into accountability and support

• Why community can drive retention, advocacy, and growth

• What she has learned building communities from zero to one

The conversation is practical and warm, which is very much Vera’s style. She has a clear point of view about the business value of community without losing sight of the people doing the work.

Decoded Takeaways

Community can become an external team for people who don’t have enough peers, support, or institutional knowledge inside their own companies. That’s especially valuable in emerging functions where people are still defining the role while trying to perform it.

Vera’s approach begins with listening. She looks at what members need, what they can teach, and where trusted relationships could make the work easier or more effective. The company creates the conditions, but members help one another produce much of the actual value.

The strongest communities also give people somewhere to be honest about what isn’t working. That kind of safety has practical consequences. Problems surface earlier, members learn from one another’s experience, and people return to their companies with more confidence and better language for influencing decisions.

For the business, the value shows up through stronger customer relationships, retention, advocacy, and growth. Those outcomes are more credible when they follow from helping members succeed, rather than treating community as a source of activity or promotion.

Timestamps

00:00 Introduction and Vera’s path into community
01:40 Vera’s four C’s of community
03:06 How people arrive in sustainability careers
04:50 Why Watershed invested in community
06:21 Similarities between emerging legal and sustainability roles
07:57 Community as an external team
10:43 Vera’s listening-tour process
11:57 Helping members become more influential
12:25 Why community needs to feel safe

Related posts

• Community Without Power

• The Efficiency Trap

• Community Codebreakers: DeMario Bell on Sequencing B2B Community for Scale

A community leader gets invited into quarterly planning.

The company wants community to improve adoption, help with retention, create more advocacy, generate better customer feedback, and support education. By the time the community leader joins the meeting, the plans behind most of those outcomes are already finished.

Marketing has its campaign calendar. Customer success has set its adoption priorities. Product has committed the roadmap. Education has chosen its content plan. The community leader is asked how the community can help.

I’ve seen this pattern in companies at very different stages. People are usually well intentioned. They like the community team, believe the work is valuable, and genuinely want to collaborate.

The operating model still leaves community responsible for outcomes shaped somewhere else.

How the mismatch develops

Community usually starts inside one function for a sensible reason.

Support creates a forum because customers are already helping each other. Marketing builds an advocacy or events program. Customer success launches a peer network to improve adoption. Product creates a place for feedback and expert users.

The program needs a home, a budget, and an owner. That part makes sense.

As the program grows, the work starts to spread.

Members create educational content, answer product questions, refer new customers, explain use cases, identify bugs, test features, lead events, and help other customers navigate organizational problems. Community begins contributing to the work of several teams even though it still reports into one of them.

That’s where the mismatch appears.

The community team is asked to influence horizontal outcomes with vertical authority. It can recommend, persuade, share evidence, and offer access to customers. It often can’t decide what happens next.

That distinction matters when the desired result depends on choices the community team doesn’t control.

Adoption is a useful example

A company may ask community to improve product adoption.

That’s reasonable. Experienced customers can show newer customers what good use looks like. Community events and discussions can help people discover workflows, learn from peers, and see how others solved similar problems.

Adoption is also shaped by a lot of things outside community:

• Whether the product solves the customer’s actual problem

• Whether onboarding prepares them to use it

• Whether their internal champion has enough influence

• Whether education arrives at the right time

• Whether customer success understands the real barrier

• Whether the product experience reinforces the intended behavior

Community can contribute to all of those areas. It doesn’t own most of them.

When adoption rises, several teams may point to their influence. When it stalls, community can still be asked why engagement didn’t translate into more usage.

Retention creates a similar problem. A strong peer network can deepen a customer’s relationship with the company and help them succeed. It can’t fix a product that no longer meets the need, a pricing change that undermines value, or an implementation problem that began before the customer ever joined.

Community affects the result without controlling the conditions.

What I was trying to resolve in the book

One of the tensions I kept returning to while writing The Community Code was that community creates value across the business while remaining structurally attached to a single team.

I argued that companies should treat community as part of the GTM system. I still believe that. The harder question is what that requires from the organization.

It’s easy to say community should partner with marketing, product, customer success, sales, support, and education. Most experienced community teams already do that. Partnership doesn’t resolve the power imbalance by itself.

A community leader can attend cross-functional meetings and still be invited after the important decisions. They can share strong customer evidence and still lose to the metric another team is measured against. They can be accountable for an outcome without having any authority over the workflows creating it.

This is where the language of collaboration can become misleading. Everyone may be responsive and friendly while the structure leaves community with very little leverage.

When community becomes an internal service desk

Community teams spend a lot of time translating their value for internal audiences.

Product wants usable feedback. Marketing wants stories and advocacy. Customer success wants adoption and retention. Support wants deflection. Sales wants references. Executives want measurable business impact.

None of those requests is unreasonable. The accumulation of them can push community into a service model for the rest of the organization.

The team finds speakers for events, recruits beta testers, sources customers for case studies, fills reference requests, creates peer groups, and produces recurring reports. Much of that work is useful, and some of it is central to a strong program.

The risk appears when internal demand starts determining too much of the member experience.

Customers don’t join because marketing needs a case study or sales needs a reference. They participate because they expect to learn, contribute, connect, or get something they couldn’t access as easily on their own.

Once members begin to feel like a company resource, the program gets weaker. The community team is usually close enough to see that shift. It may not have enough authority to stop it.

Authority can be practical

Giving community more power doesn’t require creating a giant centralized organization or handing every customer decision to the community leader.

Authority can be much narrower.

It may mean bringing community into lifecycle planning before the campaign is finalized. It may mean requiring product teams to respond to recurring member patterns. It may mean giving community a role in customer education planning or allowing the team to decline requests that would damage member trust.

Some decisions may belong clearly to the community team:

• Which member segments receive access to particular programs

• What participation standards protect the quality of the space

• How member contributions are recognized and used

• Which internal requests fit the purpose of the community

• When repeated customer patterns require executive attention

These decisions shape whether the community remains credible. Without authority over them, the team can spend an extraordinary amount of energy negotiating for permission to do work it is already expected to own.

Measurement helps, but it doesn’t settle the argument

Community leaders are often told that stronger measurement will earn them more influence.

Better measurement helps. I’ve used account data, product behavior, business outcomes, qualitative evidence, and program activity to show what community contributes. The assumption that proof automatically changes the operating model is less reliable.

Data enters an organization that already has priorities, incentives, and power structures. A strong result may earn more budget while leaving decision rights unchanged. Another team may accept the evidence and still prioritize the metric it owns.

This doesn’t make measurement pointless. It means the report has to do more than prove value. It has to connect the result to a decision.

A company may learn that community members adopt more features or renew at a higher rate. Everyone congratulates the team, and onboarding continues to be designed without community input. The evidence showed impact. It didn’t alter the workflow.

Being invited isn’t the same as being involved

I’ve been in enough planning processes to know that timing tells you a lot.

A team may ask for community input once the core plan is fixed. At that point, the remaining choices are usually promotional. Can members attend the webinar? Can an ambassador share the launch? Can the community amplify the announcement? Can the team recruit advocates?

The more consequential questions were answered earlier.

Did the product reflect the behaviors the community had been observing? Does the education plan match how customers actually learn? Will the launch create confusion inside an existing program? Are the company’s most credible customers prepared to explain the change?

Late involvement limits community to distribution. Early involvement gives community a chance to affect design.

That difference is one of the clearest signals of whether the company sees community as infrastructure or as an audience.

The part nobody likes to say out loud

Meaningful cross-functional influence usually requires someone else to give up some control.

A product leader may have to change a roadmap based on patterns that didn’t come through the formal research process. Marketing may have to adjust a campaign because the language doesn’t match how customers describe the problem. Customer success may have to change a standardized journey for people participating differently through community.

Cross-functional work sounds great until it changes someone’s plan.

That’s why many community teams remain advisory. The company benefits from their proximity to customers without allowing that proximity to disrupt established ownership.

I don’t think most leaders do this cynically. The existing structure feels easier to manage. Clear functional ownership makes planning, budgeting, and accountability simpler.

The customer’s experience is less interested in the org chart.

A better operating model starts with decisions

The most useful place to begin is with the outcomes community is expected to influence, then trace the decisions behind them.

• If community is accountable for adoption, where is it involved in onboarding, education, product discovery, and customer success planning?

• If it’s accountable for advocacy, can the team influence the customer experiences that create genuine advocates?

• If it’s expected to improve retention, does it participate in conversations about risk, value realization, and product friction?

The gaps become visible quickly. From there, leaders can decide which decisions require community input, which decisions community co-owns, and which decisions belong to the community team.

That level of clarity is more useful than another promise to collaborate.

It also makes accountability more honest. A team should be measured against outcomes it has enough influence to shape.

The argument I’m still working through

I still believe community should be integrated across GTM. And I’m increasingly convinced that integration without authority has a ceiling.

A community team can build strong relationships, gather useful insight, and create value across the customer lifecycle. It can do all of that while remaining peripheral to the company’s most important decisions.

At some point, better partnership stops being enough. The organization has to decide whether community is mainly a source of labor and distribution or whether it participates in how customer-facing work is designed.

You can usually see that choice long before it appears in a strategy deck. It shows up in who is in the room before the plan is finished.

Decoded Takeaways

Community teams often influence adoption, retention, advocacy, education, support, feedback, and growth while controlling very few of the decisions behind those outcomes. That creates an accountability gap that good collaboration alone doesn’t resolve.

The program’s reporting line may still make sense, but its value often spreads well beyond that function. As community becomes more useful across GTM, the company needs clearer rules about where community provides input, where it shares ownership, and what the team can decide directly.

Measurement supports that conversation, but evidence doesn’t automatically change decision rights. Community leaders have to connect results to the workflows that should operate differently. Executives have to decide whether the team’s proximity to customers will influence planning or remain useful mainly for distribution and execution.

The practical test is timing. When community enters after the plan is complete, it’s usually being treated as an audience. When it participates before priorities, experiences, and workflows are fixed, it has a chance to function as infrastructure.

Related posts

• Why Community Should Report to the COO

• Community Has Impact. It Doesn’t Carry Across GTM.

• The 3 Biggest Lies About Community and GTM—And The Truth

A founder recently asked me recently whether AI could help them scale customer support, onboarding, and education without adding a lot of headcount.

The honest answer was yes. It probably could, and in some areas it probably should.

Most companies have a long list of repetitive work that doesn’t require a person every time. Customers shouldn’t have to wait for someone to reset a password, locate a basic answer, or walk them through the same setup step that hundreds of people have already completed. Teams also shouldn’t spend their days copying information from one system into another because nobody has connected the systems properly.

I’ve worked inside enough companies, and advised enough others, to know how much energy gets wasted that way. There’s a lot of customer-facing work that can become faster, more consistent, and more useful with the right automation.

What I’m less convinced of is that making each interaction more efficient will automatically create a better customer relationship.

That’s where the conversation usually gets fuzzy.

A customer doesn’t experience support, onboarding, success, product, marketing, and community as separate functions. They experience one company. They don’t care which team owns the answer or which system generated it. They care whether the answer helps, whether it fits their situation, and whether they trust the people and product behind it.

When teams optimize those interactions one at a time, it’s very easy to lose sight of what they add up to.

A series of reasonable decisions

Most of the choices that create this problem make sense on their own.

Support introduces an AI assistant because response times are too slow. Product adds more self-service because customers want to move without waiting for someone. Customer success standardizes outreach because the team has too many accounts. Marketing produces more educational content because buyers want to do their own research before talking to anyone.

None of that is particularly controversial.

The risk appears when each function gets better at the part it owns and nobody looks closely at the relationship forming across all of it.

I’ve seen customer accounts that looked healthy from every internal view. Support volume was low. Product usage was stable. The customer success team had completed its check-ins. Nobody had raised an escalation, and there wasn’t an obvious warning sign.

The customer was still considering leaving.

Nothing dramatic had happened. They’d simply reached a point where they no longer believed the company understood what they were trying to accomplish.

That kind of confidence loss doesn’t usually arrive as a clean data point. It tends to show up through a collection of smaller changes:

• The customer asks fewer questions because they don’t expect a useful answer.

• They stop joining events or participating in programs they used to value.

• They use the product in a narrower way and stop exploring what else it could do.

• They become less willing to advocate internally or publicly.

• They remain technically active while becoming less invested.

Sometimes silence means the experience is working. Sometimes it means the customer has stopped expecting much. Those look surprisingly similar for a while.

The customer journey has more owners than the customer

Inside most companies, the work has to be divided somehow. Marketing owns acquisition. Sales owns evaluation. Customer success owns adoption and renewal. Support owns troubleshooting. Product owns the experience inside the product. Community may touch all of those areas while (usually) officially sitting inside one of them.

That structure is practical, but it creates a blind spot.

Teams naturally optimize the moments they can see and measure. Support looks at resolution time and deflection. Marketing looks at content performance and conversion. Customer success looks at health scores, adoption milestones, and renewal risk. Product looks at activation and feature usage.

Those measures tell you whether a workflow is operating efficiently. They say less about whether the customer trusts the overall experience.

Trust develops gradually. A customer gets a useful answer, sees another customer describe a similar situation, notices that customer success understands the context, and sees the company acknowledge a limitation rather than pretend one doesn’t exist. None of those moments has to be dramatic, but together they create confidence.

The reverse happens the same way.

An automated response misses the nuance. A success check-in arrives with no awareness of the support issue from the previous week. The educational content sounds polished but doesn’t match the customer’s actual problem. Nobody has done anything terrible, yet the relationship starts to feel less useful and less personal.

The company may still be hitting every internal target. That’s what makes this difficult to catch.

Community works differently

I often describe community as relationships at scale.

That doesn’t mean community replaces sales, support, or customer success. I’ve never found that argument particularly credible. If you have a complicated product, you still need people who can answer technical questions, guide implementation, and help customers work through issues that require judgment.

Community works alongside those teams.

A support person can explain how a feature works. A customer success manager can help an account build an adoption plan. A community gives customers access to people who have dealt with something similar and can explain what happened in practice.

That distinction matters because customers often need more than information.

They may need to know:

• Whether someone else has tried the same approach

• What went wrong the first time

• Which tradeoffs mattered more than expected

• How another team got internal buy-in

• What the official process left out

A technically correct answer may still leave the customer unsure what to do. A peer can help them interpret the answer in the context of a real situation.

The same thing happens in education. A company can build a comprehensive course that explains every feature. Another customer can say, “These were the three things we needed first, and we ignored the rest until month two.”

That’s often the more useful answer.

In The Community Code, I wrote about community as part of the operating system around the customer. AI makes that idea more relevant because companies can now scale information and interaction much faster than they can scale judgment, context, and trust.

Community can help preserve those things, but only when it’s connected to the rest of the customer journey. A forum sitting off to the side with no relationship to support, product, success, or education won’t solve much. It may just create one more place for customers to repeat themselves.

People are messier than personas

One of the recurring problems in scaled GTM is that the customer gradually becomes a persona.

Personas are useful. Marketing teams need a shorthand for planning campaigns. Product teams need patterns. Customer success teams need segmentation. Nobody can design every workflow around the full complexity of every individual customer.

The risk is forgetting that the person on the other side doesn’t fit the bullets as neatly as the slide suggests.

They may understand the product and still lack the internal influence to get anyone else to use it. Their company may have unusual politics. Their implementation may be blocked by someone who wasn’t part of the buying process. They may look like a healthy account while feeling increasingly unsure about whether the product is worth the effort.

Those details are often where the actual outcome is decided.

AI can make personalization better. It can tailor messages based on role, industry, product behavior, and past interaction. That will probably be more useful than the broad lifecycle campaigns many companies have been sending for years.

It still isn’t a relationship by itself.

A relationship requires some degree of recognition. The customer knows there’s someone on the other side who understands enough of the context to be useful. The company has enough continuity to notice when something changes. The person is more than a set of attributes used to generate the next message.

Community is one of the few GTM motions where people regularly show up as people to one another. They have names, histories, expertise, preferences, and frustrations. They don’t always behave the way the segment says they should, which is partly why the experience can surface things the rest of the system misses.

Automation solves real problems

There’s a version of this argument that romanticizes human interaction and treats automation as something inherently cold. I don’t find that very useful.

People give bad advice. Communities can repeat outdated information. Employees send canned responses. A customer may get a much better answer from an AI assistant at midnight than from a person two days later.

Automation can improve the experience in several practical ways:

• It makes basic information available when people need it.

• It reduces repetitive work for teams that are already stretched.

• It can identify patterns across far more interactions than a person could review manually.

• It gives experienced employees more time for situations that require judgment.

• It can make messages and guidance more relevant than the generic campaigns customers are used to receiving.

Those are real benefits. The decision isn’t whether to automate. It’s where automation belongs and what still needs human context around it.

A company that automates repetitive retrieval while preserving access to judgment is making a very different choice from one that treats every interaction as a candidate for removal. Both may describe what they’re doing as efficiency, but the customer will feel the difference.

What conventional metrics miss

The efficiency gain usually becomes visible before the relationship cost does.

A team can see support deflection quickly. It can measure how many customers completed an automated onboarding flow. It can compare the cost of a live webinar with an on-demand course. Those results are useful and easy to explain internally.

Trust takes longer to show up.

It may appear when a customer asks a question earlier because they feel comfortable admitting confusion. It may show up when one member helps another avoid an implementation mistake. It may become visible when a customer advocates for the company internally because they trust the people around the product.

Sometimes the clearest evidence arrives when something goes wrong.

A customer who trusts the company gives it a chance to repair the situation. A customer who has received efficient but disconnected service may simply leave. By the time that happens, the original operating decisions are hard to trace.

This creates an incentive problem. Teams are rewarded for visible improvements inside their own reporting periods. The cost of removing useful human context may be distributed across retention, advocacy, product learning, and brand over a much longer period.

Nobody has to make a reckless decision for the overall system to get weaker.

Start with what the customer is trying to decide

When I’ve helped companies think through community, education, support, and customer engagement, I’ve found it more useful to start with the customer’s uncertainty than with the available channel.

What are they actually trying to decide?

Do they need information, judgment, reassurance, proof, or access to someone with similar experience?

Those needs lead to different answers.

A searchable help center may be ideal when the customer needs a factual answer. An AI assistant may be faster when they’re trying to locate the right documentation. A customer success manager may be necessary when the issue involves organizational risk. A peer conversation may be more credible when the customer wants to know how another team handled the same tradeoff.

Those are all legitimate parts of the customer journey. They just don’t produce the same kind of value.

This also changes how I’d think about community. It shouldn’t become the human fallback for everything automation can’t handle. That would turn it into an underfunded service layer with an impossible remit.

Its more distinctive role is creating the conditions where customers can learn from one another, see their experience reflected, and build confidence through participation. To do that well, community has to be connected to the teams designing the rest of the journey.

The operating choice underneath the technology

Two companies can adopt the same tools and create very different customer experiences.

The difference comes from what they decide to preserve.

Do customers still have access to people who understand their context? Can they learn from peers without every interaction becoming a sales opportunity? Does the company notice when repeated questions point to a deeper product or education issue? Are community insights allowed to change how onboarding, support, and customer success are designed?

Those are operating choices. The technology makes some options easier and others cheaper, but it doesn’t decide which relationships matter.

I’m optimistic about what AI can do inside customer-facing work. I’ve watched teams struggle for years with repetitive tasks, fragmented knowledge, and limited capacity. There’s a lot here that can genuinely improve the experience for customers and employees.

I’m less confident that the pursuit of efficiency will naturally preserve the parts of the relationship customers value most.

In my experience, those parts survive because someone identified them, argued for them, and designed them into the system.

Decoded Takeaways

Companies can improve support, onboarding, customer success, education, and product guidance while still creating a weaker overall relationship. That happens because each function measures the interaction it owns, while the customer experiences all of those interactions together.

AI makes local improvements easier to achieve. Faster answers and more self-service are useful, but they don’t always provide the judgment, continuity, or peer context customers need when the situation is unfamiliar or consequential.

Community can help by giving customers access to comparable experience and a place to interpret company guidance with other people. That role has to be connected to the broader customer journey. It won’t work particularly well as a forum or event program sitting off to the side.

The practical next step is to look at what customers are trying to decide at each stage. Information, judgment, reassurance, and peer proof aren’t interchangeable. Once you can see the difference, it becomes much easier to decide where automation improves the experience and where human context still needs to be designed in.

Related posts:

• Community Has Impact. It Doesn’t Carry Across GTM.

• How the Same Customer Signal Turns Into Different Decisions

• How Signal Gets Distorted

Her range is part of what makes this conversation useful. Jane has seen community across local consumer communities, creator ecosystems, product-led communities, ambassador programs, events, and large-scale advocacy work. Each of those environments has its own goals and constraints, but the common thread is pretty consistent: strong community programs tend to build around real member behavior, rather than internal assumptions about what the company wishes people would do.

One of the first things Jane said stuck with me because it gets at a point companies often skip past. In many cases, you’re not creating a community from nothing. The community already exists in some form. People are already helping each other, sharing feedback, writing reviews, creating examples, teaching peers, or explaining the product better than the company does. The program comes later, and the job is to understand what’s already happening before trying to formalize it.

The community exists before the program does

When Jane talked about Patreon, she described a company with an existing creator community that needed a more intentional way to listen, support, and build with those creators. The program didn’t begin as a blank-page exercise. It began with a real ecosystem of creators, fans, podcasters, musicians, and artists already using the platform in different ways.

A company can create a program, a forum, an ambassador structure, a newsletter, an event series, or a Slack channel. It can’t manufacture the emotional bond that makes people care. The more useful work is understanding what people are already doing, why they’re doing it, and what kind of structure would make that behavior easier, more useful, and more aligned with the company’s goals.

Jane described community as more than a role, identifier, or product relationship. It’s a sense of connectedness around a shared interest, experience, passion, or problem. That doesn’t mean everyone in the community is the same. In fact, stronger communities often bring together people from different backgrounds who care about the same thing from different angles.

For GTM and community teams, this is an important distinction. If you treat community as something the company invents, you’ll probably overbuild the container and underinvest in the behavior. If you treat community as something you’re trying to understand, support, and structure, the program has a much better chance of earning participation.

Start with input, then build the program

Jane kept coming back to the importance of gathering input before designing the program. That sounds obvious until you remember how many companies still launch community initiatives from a planning doc written mostly by internal stakeholders. The intentions may be good, but the result can end up reflecting the company’s operating needs more than the community’s actual motivations.

At Grammarly, Jane ran a pulse survey to understand how active community members were using the product, what they valued, and who might be interested in deeper advocacy. At Patreon, she used Discord polls, surveys, focus groups, and one-on-one interviews with creators to understand what was working, what wasn’t, and where the company needed to listen more closely.

Her approach was practical: use the full funnel of input. Broad data can show patterns. Surveys can surface themes. Focus groups can pressure-test hypotheses. One-on-one interviews can uncover the nuance that never shows up cleanly in a dashboard.

No single input is enough on its own. The point is to triangulate. If survey data tells you one thing, focus groups add context, and individual interviews reveal the emotional or practical reasons behind the behavior, you’re in a much better position to build something people will actually use.

Jane put it simply: “Your community is always the wisest resource you have.”

Easy to say. Frequently ignored. Usually expensive to rediscover later.

Find the behavior you want more of

One of the most useful parts of the conversation was Jane’s explanation of how to identify the right first members for a program. A lot of teams start with a vague idea of “power users,” “superfans,” or “advocates,” then try to reverse-engineer a selection process from there. Jane’s approach was more grounded: look for the people already modeling the behavior you want the broader community to adopt.

At Yelp, the goal was reviews. So the team looked for people already writing thoughtful, useful, high-quality reviews. They weren’t just looking for enthusiasm or brand affinity. They were looking for people whose behavior matched the value Yelp needed more of.

At Patreon, the goal was different. The team wanted creators who could help build awareness and bring other creators into the ecosystem. That meant looking for influence inside specific creative niches, creators who were already supporting others, and people with recruiting potential inside their own communities.

The useful part of this example is that the principle stays the same, even when the business goal changes. The right early members are usually already doing something worth scaling. They’re helping, teaching, creating, organizing, advocating, or connecting others before the company gives them a badge or invites them into a formal program.

The mistake is treating member selection like a popularity contest or a pure reach exercise. Reach can matter, of course. Influence can matter. But if the person’s behavior doesn’t map to what the program needs to create more of, you’re mostly recruiting visibility without much operating value.

A better question is: who is already acting like the community we want to build?

Pilot before you scale

Jane was very clear on this point: pilot the program.

At Patreon, the ambassador program started with 50 people, then expanded to 50 in different international metros before rolling out more broadly. The first year was invitation-only before applications opened up.

This kind of sequencing can feel slow, especially inside companies that want the optics of scale as quickly as possible. It’s also how you avoid making a big promise to the community before you know whether the experience works.

A pilot gives you room to kick the tires. You can see what people respond to, what confuses them, what internal teams actually need, and where the operational load starts to break. It also gives the company time to understand what kind of support, communication, tooling, and internal coordination the program will require.

Community programs involve people, trust, status, access, and identity. Rolling them out broadly without testing can create problems that are hard to unwind later. Expectations harden quickly once people feel like they’ve been invited into something meaningful.

So yes, starting smaller can feel less exciting. It’s also a lot less chaotic than launching a dinner party by opening the doors to the entire city and hoping the vibes sort themselves out.

Bold. Usually unwise.

Scaling requires structure

Jane likes what she called the “slow burn” approach. That doesn’t mean staying small forever. At Patreon, the program grew from 50 to 500 creators in a year. The difference is that growth followed learning, rather than replacing it.

She mentioned several tactics that helped: referrals, targeted invites, events, segmented outreach, and using data to identify members whose behavior aligned with the program’s goals. She also talked about the emotional challenge of scale. In the early days, community managers often know everyone. They know people’s names, interests, projects, and sometimes their pets. At a certain point, that one-to-one intimacy can’t work the same way.

The work then becomes less about personally knowing everyone and more about designing systems that still make people feel seen, supported, and connected.

At Patreon, that included clearer support pathways for ambassadors, including a dedicated email address and service-level agreement with the customer support team. Ambassadors had a more direct experience, and the community manager didn’t have to become the human router for every product or support question.

This is where community scale tends to get very real. More members means more edge cases, more internal asks, more communication needs, and more chances for the experience to become uneven. Without structure, the program starts depending too much on individual heroics. And individual heroics are a terrible operating model, even if community teams have historically been very good at disguising them as “being scrappy.”

Consistency is underrated

Jane also made a strong case for consistency: monthly events, reliable communication, a regular newsletter or update, and a predictable rhythm people can depend on.

This may sound basic, which is probably why it gets neglected. A lot of programs over-index on big moments and underinvest in the operating cadence that keeps people engaged between those moments. Jane’s view was simple: don’t bombard people, but do show up reliably.

At Patreon, she sent a monthly newsletter by a consistent date. If internal teams wanted product updates, testing opportunities, or announcements included, they had to meet that deadline. Over time, the newsletter became valuable because members knew what to expect and internal teams knew how to participate.

For community teams, this is one of those unglamorous operating practices that makes the visible work possible. A reliable cadence creates trust with members and discipline internally. It also gives other teams a clear way to work with community without turning every request into a last-minute favor.

Reporting needs both business impact and program health

Jane’s reporting framework lined up closely with how I think about community measurement: you need to understand both the business value and the health of the community itself.

The business side answers how the work is helping the company. Depending on the program, that might mean more high-quality reviews, creator acquisition, product adoption, advocacy, customer stories, early product feedback, or support for launches.

The community side answers whether the program is healthy enough to keep creating that value over time. That might include member growth, engagement quality, event participation, satisfaction, programming value, retention, and whether members feel like the program is worth their time.

The mistake is choosing only one side. If you only report program health, leadership eventually asks why the work matters. If you only report business impact, the community starts to feel extracted from. You need both lenses if the program is going to keep earning investment without burning through the trust that makes it work.

A mature community program should be able to say, “Here’s what this is doing for the business, and here’s how we know the community is still healthy enough to keep creating that value.” That’s a much stronger story than reporting activity and hoping people connect the dots themselves.

Key takeaways

• The community often exists before the program does. The work starts by understanding what people are already doing, then building structure around the behavior that matters.

• Member selection should begin with behavior. At Yelp, that meant finding people already writing useful reviews. At Patreon, it meant finding creators with influence inside their own communities.

• Pilots protect the relationship. Starting small gives you room to learn, fix weak spots, and avoid overpromising before the program is ready.

• Scale requires systems. As a program grows, the work shifts from personally knowing everyone to designing pathways, rhythms, and support structures that still make people feel connected.

• Consistency builds trust. Regular communication and predictable programming may not sound exciting, but they’re often what keep the program usable for members and internal teams.

• Reporting needs two lenses: business impact and community health. One helps earn continued investment. The other protects the engine that creates the value.

Decoded insight

The best community programs don’t start by asking how big they can get. They start by asking what behavior is already worth building around.

Jane kept returning to that idea in different ways. Whether she was talking about Yelp reviewers, Patreon creators, Grammarly advocates, or ambassador programs, the pattern was consistent: find the signal, build around it, and scale without flattening the thing that made it valuable in the first place.

You can connect with Jane Nadaraja on LinkedIn to follow more of her work across community, advocacy, and customer engagement.

And if this conversation sparked a thought, leave a comment or share it with someone building a community program that needs more structure and less wishful thinking.

Timestamps

00:00 – Meet Jane Nadaraja
00:59 – Defining community
02:00 – A memorable Patreon moment
05:20 – Why Patreon invested in community
07:22 – Where community sits inside the org
09:08 – Gathering input
12:21 – Designing around business needs
14:52 – Piloting before scaling
15:49 – Finding the right first members
20:23 – Scaling without losing quality
27:24 – Engagement rhythms
30:35 – Reporting on impact
34:28 – Sharing community work internally

If you take the idea from the last post and follow it a bit further, the more useful question isn’t whether signal gets reshaped as it moves across teams, because that part is almost inevitable. What matters more is understanding where that reshaping actually happens in practice, and why it tends to show up in the same places over and over again.

It’s easy to talk about this in abstract terms, but when you look at how work actually moves through a GTM organization, the breakdown points are surprisingly consistent. You can usually trace them back to a small number of transitions where information has to change form in order to be useful to the next team, and those transitions are where most of the signal loss happens.

Where translation tends to happen

In most GTM workflows, customer signal moves through a few predictable steps before it influences a decision. It usually starts in a raw form, whether that’s community activity, support tickets, sales conversations, or product usage, and from there it has to be turned into something that can travel across teams.

That typically involves a sequence of changes that look something like this:

• Summarizing what’s happening into a smaller set of patterns

• Grouping those patterns into categories or themes

• Framing them in a way that fits the next team’s priorities

Each of those steps is necessary, because without them the signal is too noisy to act on. At the same time, each step introduces a small shift in meaning, where something specific tied to a particular situation becomes more general and easier to process, but also easier to deprioritize once it’s competing with other inputs that have already been structured in a similar way.

Why this doesn’t get caught earlier

One of the reasons this is difficult to address is that the process makes sense from inside each function. Product needs to see patterns across many customers rather than individual anecdotes, marketing needs language that can scale, and sales and customer teams need signals that map to pipeline and retention.

From within each of those contexts, the translation step feels like the right thing to do. The issue is what happens when those translations aren’t connected to each other, because over time you end up with multiple versions of the same signal that all make sense locally but don’t line up in a way that drives a clear decision globally.

Where it breaks inside workflows

If you map this to how work actually gets done, there are a few points where the signal tends to break down, and they’re usually tied to moments where ownership shifts or where inputs get combined.

One is the initial handoff from a raw source into a structured system, which is where context is most likely to get compressed. Another is when that structured input gets combined with other inputs, because at that point it’s no longer evaluated on its own terms but as one item in a broader set of priorities. You also see it when outputs get pushed back out into the market, because messaging, enablement, and product updates are all shaped by whatever signal made it through those earlier steps.

Across those moments, the same pattern tends to show up:

• The signal becomes easier to compare

• It becomes easier to prioritize at a high level

• It becomes harder to connect back to the original context

That tradeoff is part of what allows teams to operate at scale, but it’s also where the gap starts to widen in ways that are hard to see from inside any single function.

Why adding more signal doesn’t fix it

A common response to this problem is to try to improve visibility by adding more dashboards, more reporting, and more ways to surface customer feedback. Those can help at the edges, but they don’t address what’s happening inside the workflow itself.

If the underlying process requires signal to be translated multiple times, then adding more signal just increases the volume moving through the same system. You end up with more data, but the same points of breakdown, which is part of why community can feel like it’s working and not working at the same time. It generates a lot of useful signal, but that signal is still subject to the same translation steps once it leaves that environment.

What this looks like in practice

If you look at how this plays out across functions, it tends to follow a familiar pattern. Product sees a set of categorized inputs that are easy to compare but harder to tie back to specific customer situations, marketing works with language that has been generalized enough to scale but doesn’t always reflect how customers actually describe their experience, and sales and customer teams operate on signals that map cleanly to their metrics but don’t always capture what’s changing underneath.

None of those views are wrong. They’re all shaped by how the work needs to happen. The issue is that they don’t reconnect, which makes it harder to act on the underlying situation in a coordinated way.

Where this leaves you

If you’re trying to improve how customer signal influences your GTM, the goal isn’t to eliminate translation, because that’s not realistic and it’s not even desirable. The goal is to understand where it’s happening and what’s being lost at each step, which usually starts with a simple question: at what point in your workflow does the signal stop looking like the thing you originally observed?

Once you can identify those points, you can start to decide where you want to preserve more context, where you need better alignment between teams, and where the system itself needs to change. That’s a harder problem than just improving visibility, but it’s also where most of the leverage tends to be.

Decoded Takeaways

Customer signal doesn’t disappear inside GTM workflows. It gets translated into forms that are easier to process and prioritize, and that translation happens at predictable points.

Those points include the initial shift from raw input to structured data, the combination of that data with other inputs, and the way decisions get pushed back out into the market. Each step makes the signal more usable within a specific system and less connected to its original context, which over time creates gaps between how different teams understand the same underlying situation.

Improving visibility can help, but it doesn’t address where the signal is actually breaking down. The more useful approach is to identify where translation is happening and decide where you need to preserve more of the original meaning.

Related Posts

• Community Has Impact. It Doesn’t Carry Across GTM

• Where Community Breaks Down Inside GTM

• What K-Pop Can Teach Go-to-Market Teams

When I was at Asana, I got into the habit of spending time in the forum before big cross-functional meetings. It wasn’t part of any formal process. I just wanted a quick read on what customers were actually dealing with at that moment and how that was evolving over time.

If you spend even a little time in a space like that, patterns start to show up quickly. You begin to recognize the same accounts, how their questions change, and where they’re running into friction. A lot of what you see tends to fall into a few categories:

• Where people are getting blocked

• How they’re working around limitations

• What they’re trying to do that isn’t fully supported

• How their usage is changing over time

Then I’d go into a planning conversation, and that context wasn’t already in the room.

It wasn’t that people didn’t care about it. It just wasn’t part of the system they were using to make decisions, so the same customers and the same product showed up as a different set of priorities depending on where you were looking.

Where this gets expensive

One place this becomes very clear is in expansion.

You’re reviewing accounts and deciding where to spend time, and from the perspective of the systems most teams rely on, things look fine. Usage is steady, nothing is at risk, and nothing is moving in a way that demands attention. So the account ends up somewhere in the middle. It’s not something you ignore, but it’s not something you prioritize either.

At the same time, if you look at what’s happening in the community, you can see a different trajectory. The signals don’t look urgent in isolation, but taken together they tell a different story:

• Questions are shifting from basic to more advanced

• The same people are showing up repeatedly in events

• Customers are starting to answer other customers’ questions

Those are usually signs that an account is going deeper into the product and starting to figure out how to apply it in more complex ways.

From one angle, the account looks flat. From another, it looks like it’s moving. Both views are grounded in real data, but they don’t connect in a way that changes what happens next. As a result, the account stays where it is.

From the outside, that can look like a missed opportunity. From the inside, it’s a reasonable decision based on the information that’s available, which is part of what makes this hard to catch early.

How that pattern repeats

You see a similar dynamic in product conversations.

Community surfaces a steady stream of signal, and it’s not just feature requests. It’s confusion, workarounds, and patterns in how people are actually using the product. That signal usually makes its way into product discussions, but it has to be translated into something that fits how roadmap decisions are made.

That typically means it gets summarized, categorized, and compared against other inputs that are already structured in a similar way. This step is necessary, because product teams need a way to evaluate tradeoffs across many competing priorities.

At the same time, something changes in that translation.

What felt immediate and clear when you saw it in its original context becomes easier to deprioritize once it’s been reshaped. The context that made it feel urgent doesn’t fully carry through, and over time that creates a gap between what’s being surfaced and what actually influences decisions.

From one side, it can feel like the same issues keep coming up without anything changing. From the other, the signal doesn’t quite map cleanly to how decisions are made, so it gets acknowledged without materially shifting the roadmap.

Messaging drifts in a similar way

Marketing runs into a version of this that’s a bit less obvious, but follows the same pattern.

Community is one of the few places where you hear how customers actually talk about the product when they’re not trying to fit into your positioning. You get a clear sense of the language they naturally use, where they hesitate, and how they describe what they’re trying to do.

That’s useful input if you’re trying to refine how you show up in the market, but unless there’s a tight loop that brings that language into how messaging is developed and updated, it tends to stay local.

Over time, that shows up in ways that are easy to rationalize:

• Messaging feels slightly off, but not enough to trigger a full rethink

• Different teams describe the product in slightly different ways

• Customer language shows up inconsistently across channels

Nothing in that process looks broken when you’re inside it. It just takes longer to get to something that feels coherent.

Why this is hard to catch

One of the reasons this persists is that the system keeps working well enough that it doesn’t force a correction.

Expansion still happens, product still ships, and marketing still drives pipeline. From the inside, it feels like normal complexity, where each team is doing good work and decisions make sense within the context they’re operating in.

The cost shows up more in timing than anything else. You see it in opportunities that take longer to surface, decisions that take longer to line up, and messaging that takes longer to correct when it starts to drift. None of those issues trigger an immediate response, but they accumulate over time.

What’s actually going on underneath it

Each GTM function is doing what it’s designed to do. It takes in information and translates it into its own system.

Marketing is looking at pipeline and conversion, product is looking at usage and roadmap, sales is focused on deals and expansion, and customer teams are looking at retention and support. Each of those perspectives is grounded in something real.

The challenge is that the same underlying signal gets reshaped as it moves through those systems. Each step makes it easier to interpret within that context and harder to connect across contexts, which is where the drift starts to show up.

This is something I kept coming back to while writing The Community Code, because community is one of the few places where you can see the full arc of how customers actually think and behave over time. The visibility is there. What happens after the signal leaves that environment is where things start to break down.

Where I’d look first

If you’re trying to make sense of this in your own organization, I wouldn’t start by asking whether you have enough customer insight, because most teams do.

I’d start by looking at where that insight changes form, where it gets summarized, reframed, or filtered to fit a different system, and where it stops influencing decisions even though it’s still being surfaced. Those are usually the places where the underlying issue becomes visible.

Decoded Takeaways

The same customer behavior can show up across multiple systems and lead to different decisions depending on how it’s interpreted.

Each team is working with real signal, but they’re working with it in a way that fits how their system operates, which makes it harder to act on collectively.

Over time, that shows up less as obvious failure and more as delay, where opportunities, decisions, and messaging all take longer to line up than they should.

If you’re trying to improve outcomes, it’s worth paying attention to where the same signal leads to different conclusions, because that’s usually where the system is introducing friction.

Related Posts

• Community Has Impact. It Doesn’t Carry Across GTM

• Where Community Breaks Down Inside GTM

• What K-Pop Can Teach Go-to-Market Teams

If you spend time inside most go-to-market teams, the work generally looks fine. Marketing is generating demand, product is shipping features, sales is closing deals, and customer teams are running onboarding, driving adoption, and trying to protect retention. You can sit with any one of those teams and they can usually explain what they’re doing, why they’re doing it, and how they measure success.

That part is rarely the issue. When I was at Asana, and in most of the companies I’ve worked with since, the internal story at the team level was usually coherent. People were thoughtful about their tradeoffs. The work was intentional. There was a clear sense of progress.

But customers don’t experience teams. They experience the system those teams create together. And when you look at it from that angle, things start to feel less connected. The message they hear early doesn’t always carry into onboarding. The context they build up during onboarding doesn’t always show up in product decisions. The signals they’re sending in one place don’t seem to exist in another.

No single team owns that gap, which is why it persists. The work inside each function holds up, but the system between them doesn’t.

Where things actually start to drift

The way I’d think about this is that GTM systems don’t usually break inside workflows. They drift at the seams, where work moves from one team to another and has to be reinterpreted.

Onboarding is one of the clearest places to see it. Marketing spends a lot of time getting the story right. Who this is for, what problem it solves, and what success looks like. That’s usually the result of a lot of iteration and pressure to improve conversion.

Then the customer lands in the product or in an onboarding program that’s optimized for something slightly different. Product might be focused on feature exposure. Customer success might be focused on time-to-first-value. Support might be trying to reduce ticket volume. All of those are reasonable goals, but they don’t always line up with the promise that brought the customer in.

So the customer ends up doing the translation work themselves. They’re trying to reconcile what they were told with what they’re now being asked to do. That gap isn’t the result of a bad decision by any one team. It’s the result of how the work is structured across teams.

You see the same pattern with product feedback. Community surfaces a constant stream of signal, not just feature requests, but confusion, workarounds, and the language customers actually use to describe what they’re trying to accomplish. Product teams want that signal and will often set up processes to capture it.

But once that signal moves into product, it has to fit how product makes decisions. It gets summarized, categorized, and prioritized alongside roadmap commitments, sales input, and internal hypotheses. In that process, a lot of the context gets stripped out, and what started as a clear signal turns into something more abstract and easier to deprioritize.

Nothing is broken inside the function. The hand-off changes the meaning.

Every team defines success differently

This is where the issue becomes more structural. Each GTM function is operating against a different definition of success, and those definitions shape how customer behavior gets interpreted.

Marketing is looking at conversion and pipeline. Product is focused on adoption and usage. Sales is looking at deal velocity and size. Customer teams are tracking retention, expansion, and support load. All of those are valid, but they create different lenses on the same underlying reality.

A spike in community questions might signal strong engagement from one perspective and product friction from another. A highly active customer in the community might be seen as an advocate by one team, but not show up as expansion-ready in another team’s systems. So each team takes the signal and reshapes it to fit its own model.

Over time, that creates drift. Not because anyone is doing something wrong. It’s just that there’s no shared mechanism to carry meaning across those interpretations.

Community sees more than it can carry

Community sits in an unusual position in all of this. It often has visibility across the entire customer journey, from early interest through onboarding, product usage, and expansion. It hears the same customer talk about different parts of their experience over time, which gives it a more continuous view than most other functions.

In theory, that makes it a useful connective layer. In practice, it’s usually embedded inside a single team, most often marketing or customer success, and that placement shapes how its work is interpreted.

If it sits in marketing, its insights tend to get pulled toward demand and engagement. If it sits in customer success, they get framed around retention and support. Either way, it struggles to carry signal cleanly across the rest of the system. It can surface insight and advocate for it, but it rarely has the structural authority to ensure that insight changes how other teams operate.

So it becomes a source of signal without a reliable path for that signal to travel.

What this looks like in real workflows

You can see this most clearly in a few recurring workflows, but one that stands out from my time at Asana is expansion.

We had accounts where, from a traditional lens, things looked stable but unremarkable. Usage was steady, no major support issues, nothing that would trigger immediate attention from sales or customer success. If you were looking purely at product analytics or account health scores, these accounts would sit somewhere in the middle of the pack.

At the same time, if you looked at community behavior, a different picture emerged. You’d see people from those same accounts showing up consistently in events, asking increasingly sophisticated questions in the forum, and in some cases, answering other customers’ questions. They were moving from basic usage into deeper workflows.

That’s not a vanity signal. That’s a leading indicator of maturity.

The problem was that this context didn’t consistently show up in the systems that sales or customer teams were using to prioritize expansion. So decisions were being made based on a partial view of the account.

If you map that out, it tends to look something like this:

• Product sees stable usage and no obvious risk, so the account is “healthy but not urgent”

• Customer success sees limited expansion activity, so it doesn’t rise to the top of the queue

• Sales focuses on accounts with clearer, more immediate signals tied to pipeline

Meanwhile, community is seeing depth, curiosity, and increasing sophistication, but that signal isn’t structured in a way that carries into those decisions.

No one is making a bad call. They’re making a rational call based on the data available to them. The issue is that the system isn’t designed to bring those signals together in a way that changes how the account is handled.

So expansion opportunities get missed, or at least delayed, not because the signal isn’t there, but because it doesn’t travel.

You see a similar pattern in messaging. Community hears how customers actually talk about the product, what language resonates, what confuses them, what they struggle to explain internally. That’s valuable input for marketing.

But unless there’s a tight loop, that language tends to stay local. It might influence a few pieces of content or a specific campaign, but it doesn’t consistently shape how the company talks about itself across channels.

Each team continues refining its own version of the story, and over time those versions start to diverge.

Why this stays hidden for so long

One of the more frustrating aspects of this is that the system can operate this way for a long time without forcing a correction. Nothing fully breaks. There’s enough overlap and redundancy to keep things moving. Teams compensate, build their own processes, and fill in gaps manually.

From the inside, it feels like normal complexity. From the outside, it shows up as inconsistency.

Customers don’t see the internal structure. They experience the system as a whole. When signal doesn’t carry across hand-offs, that shows up as repeated context, mismatched expectations, and small moments of friction that accumulate over time. None of those moments are catastrophic on their own, but they compound.

Where things go sideways

If you step back, the issue isn’t that teams aren’t doing good work. It’s that the system they’re part of isn’t designed to preserve intent as work moves across boundaries.

Each team takes in customer signal, interprets it through its own lens, and optimizes accordingly. That’s rational behavior, and it’s also what causes the drift. Community makes this more visible because it sits across those boundaries and hears when customers notice the gaps, but without structural support, it ends up compensating rather than resolving.

Teams respond by trying to improve the work inside each function. Better onboarding, clearer messaging, stronger feedback loops. Those are all worthwhile, but they don’t address the underlying issue.

The breakdown isn’t inside the work. It’s in how the work connects.

So where does it break for you?

If you’ve tried to make this work across teams, you’ve probably felt some version of this already. The more useful question isn’t whether your teams are doing good work. It’s where that work starts to lose meaning as it moves between them.

Where does the original intent get diluted or reshaped? Is it onboarding, where the promise doesn’t quite carry into the experience? Is it product feedback, where signal gets filtered to the point of being unrecognizable? Is it expansion, where you know more about the account than your systems reflect?

Or is it somewhere else entirely? I’m curious where this shows up most clearly for you.

Decoded Takeaways

• Most GTM teams don’t struggle because individual functions are underperforming. They struggle because the system connecting those functions isn’t designed to preserve meaning as work moves across it.

• Each team is operating with a different definition of success, and that shapes how it interprets customer behavior. Over time, that creates consistent distortion. The same signal gets translated differently depending on where it lands, which makes it harder to act on collectively.

• What makes this difficult to address is that the system continues to function. There’s enough overlap to keep things moving, which hides the underlying issue. Teams compensate instead of fixing the structure.

• Community sits in the middle of this. It often has the clearest view of the full customer journey, but it doesn’t have the authority to ensure that signal carries across teams in a consistent way. It surfaces insight, but it can’t guarantee that insight changes how the system operates.

• If you’re trying to improve outcomes, the instinct is to optimize within a function. That helps, but it doesn’t solve the problem.

• The more important question is where intent gets lost between functions. That’s where the system actually needs to change.

Related Posts

• Community Has Impact. It Doesn’t Carry Across GTM

• Where Community Breaks Down Inside GTM

• Community x GTM Playbook: What Every Chief Product Officer & Head of Product Needs to Know

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

Today, my new book, The Community Code, is officially out.

It’s available now on Amazon.

This book comes out of a pattern I kept running into across companies, roles, and stages. Community was clearly doing something valuable. Customers were helping each other learn the product, sharing use cases, influencing adoption, and in some cases shaping pipeline and expansion.

But that impact rarely translated across the rest of the organization.

Individually, the signals were easy to point to. Collectively, they were harder to make sense of. That’s where things tend to break down.

Why this book exists

Inside the company, each team interprets what it sees through its own lens. Marketing frames it as advocacy. Product treats it as feedback. Customer success sees adoption patterns. Sales looks for proof points to support deals in motion.

All of those interpretations are valid. The problem is that they don’t connect in a way the business can actually operate on.

What looks like a cohesive system from the outside gets broken into pieces on the inside. As a result, community ends up feeling simultaneously important and hard to justify. There’s visible impact, but no shared understanding of how that impact moves through the business.

This book makes that system visible and usable.

Where community-led growth falls short

“Community-led growth” helped move the conversation forward. It gave the work more weight and tied it to outcomes leadership already cared about.

That shift mattered. But in practice, it also introduced a mismatch.

Most organizations aren’t designed for any single function to lead growth on its own. Product, marketing, sales, and customer success each control different parts of the lifecycle, and growth shows up when those parts reinforce each other over time.

Community doesn’t sit neatly inside that structure. It cuts across it. So expectations expand, but decision rights and operating models don’t change alongside them.

As companies scale, the result becomes obvious. Multiple versions of “community” start to appear across the org. Marketing builds advocacy programs. Customer success builds onboarding and support spaces. Product runs betas or feedback groups. Developer relations builds ecosystems.

Each effort makes sense in isolation. Each is tied to a clear goal. But they’re owned by different teams, measured differently, and rarely connected in a way that reflects how customers actually experience the product.

From the company’s perspective, the structure is rational. From the customer’s perspective, it’s fragmented.

The problem isn’t belief, it’s translation

At this point, most GTM leaders don’t need to be convinced that community has value. The harder problem is making that value usable.

Signal is generated in one place and consumed in another. Context gets lost along the way. Teams fall back on their own proxies because the underlying system isn’t visible enough to work from directly.

That’s why the same patterns keep repeating. Product teams see spikes in requests without full context. Marketing highlights stories that resonate externally but don’t fully reflect usage. Sales leans on isolated proof points. Customer success sees early signs of friction but struggles to connect them back to upstream decisions.

These aren’t failures of execution. They’re artifacts of how the system is structured.

Without a shared way of carrying signal across functions, each team optimizes locally. The result is a set of decisions that make sense individually but don’t consistently reinforce each other.

From fragmented signal to community-integrated GTM

A more durable approach starts by changing how community shows up in the system.

Not as a standalone program, and not as a function that owns outcomes, but as a way of feeding shared customer signal into how product, marketing, sales, and customer success actually operate.

When that signal is visible and consistently used, things change in a way that’s hard to fake. Product decisions reflect how customers are using the product in context, not just isolated requests. Marketing messaging aligns more closely with how customers describe value in their own words. Sales conversations carry examples that generalize. Customer success leans more on peer momentum instead of purely reactive support.

What changes isn’t any single output. It’s how those outputs start to reinforce each other.

That reinforcement is where leverage shows up. It’s also where most community efforts stall, not because the work isn’t valuable, but because the system around it isn’t designed to absorb and use that value consistently.

How this looks in practice

You can see this in companies that have invested in connecting customer signal across functions.

At Asana, the community forum, ambassador program, and events surfaced patterns around how teams were adopting the product, where they were getting stuck, and how use cases were evolving over time. That signal showed up in product conversations, influenced how customer stories were told, and informed how teams approached onboarding and expansion.

At Atlassian, community conversations often surface emerging needs and workarounds long before they appear in formal feedback channels. That signal feeds into product teams, partner ecosystems, and support content, creating a more connected view of how customers are actually using the platform.

In both cases, the value of community isn’t just in the interactions themselves. It’s in how those interactions inform decisions across the rest of the organization.

That doesn’t happen automatically. It requires intentional design around how signal is captured, translated, and shared.

What the book does

The Community Code breaks this down directly.

It maps how customer signal actually moves across go-to-market, where it gets lost, and how to integrate it into the way teams operate day to day.

This isn’t about elevating community as an idea. It’s about changing how work happens across product, marketing, sales, and customer success so they operate from the same underlying inputs.

If you want to go deeper, you can learn more about The Community Code here.

Decoded Takeaways

• Community generates some of the earliest and most nuanced customer signal, but that signal often fragments as it moves across teams

• “Community-led growth” elevates the importance of the work, but doesn’t resolve how it fits into vertically structured organizations

• The core issue isn’t belief in community’s value, it’s the lack of a shared system to translate that value into decisions

• A community-integrated approach creates a common layer of signal that product, marketing, sales, and customer success can operate from

• Durable advantage shows up when those functions start reinforcing each other based on the same underlying inputs

Related Posts

• Why I No Longer Say “Community-Led Growth”
  Where the language starts to fall apart in practice, and how it creates expectations most organizations can’t actually support.

• Where Community Breaks Down Inside GTM
  How community gets fragmented across marketing, product, sales, and customer success, and what that fragmentation costs the business.

• What K-Pop Can Teach Go-to-Market Teams
  A different lens on the same idea, showing how coordinated community behavior can shape distribution, adoption, and narrative without owning growth directly.

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

For years, I described my work as community-led growth. I don’t anymore.

After spending time recently in rooms full of community practitioners, I’ve been thinking more carefully about how we describe this work. The language we use shapes how organizations structure authority, expectations, and accountability.

For a long time, calling it community-led growth felt accurate and necessary.

Community teams had spent years being treated as engagement programs orbiting the “real” work of go-to-market. So when the phrase gained traction, it felt like overdue recognition. It signaled business impact. It signaled ownership. It suggested that community wasn’t just supporting growth but driving it.

And in some cases, it did drive meaningful outcomes.

But over time, the language started to feel slightly misaligned with what I was actually seeing inside organizations.

Durable growth is rarely led by one function in isolation. Product doesn’t grow the company alone. Sales doesn’t. Marketing doesn’t. Customer success doesn’t. Each function controls a vertical slice of the lifecycle, and growth shows up when those slices reinforce one another.

So saying that community “leads” growth began to feel structurally imprecise.

Vertical companies, horizontal leverage

Most companies are vertically organized.

• Product owns roadmap and prioritization.

• Marketing owns demand and narrative.

• Sales owns revenue.

• CX or Customer success owns renewals and expansion.

Each function has clear authority and defined metrics. Accountability follows the vertical.

But community rarely maps cleanly to that structure. It gets placed somewhere on the org chart, but its impact doesn’t follow a single vertical line. That’s why it often feels awkward organizationally. It inherits goals that don’t fully reflect what it influences.

Uniquely, community operates horizontally.

It spans awareness, adoption, expansion, and advocacy. It sees early curiosity before it shows up in marketing dashboards. It notices which customers are quietly becoming power users long before expansion conversations begin. It hears friction before churn metrics move. And it captures the language customers use with each other when no one from the company is steering the message.

Years ago, when I explained community in stakeholder meetings, I’d draw the core GTM teams as vertical pillars and sketch community as a horizontal layer connecting them, supporting and informing each one.

That picture still holds up.

Community connects and integrates across pillars. It doesn’t lead or replace them.

Where “community-led” overcorrected

The issue with “community-led” isn’t intent. It’s structure.

The word “led” implies authority over outcomes and decisions. Inside most organizations, community doesn’t have that authority.

What it has is insight and influence without formal control. It can surface signal, generate advocacy, highlight friction, and create momentum. But the levers that convert those inputs into measurable outcomes still sit inside other teams.

When companies adopt the language of community-led growth, expectations rise quickly. Community is asked to drive pipeline, strengthen retention, increase advocacy, surface product insight, and deepen engagement. At the same time, product still owns prioritization, marketing still owns messaging, sales still owns revenue targets, and customer success still owns expansion and retention.

So what happens to community? Responsibility expands. Authority does not.

I’ve experienced that directly. I’ve also seen a related pattern inside larger organizations.

As companies grow, they sometimes create multiple community teams across verticals. Marketing builds a brand community. Customer success builds a customer community. Product builds a beta group. Developer relations builds its own ecosystem.

Each one reports into a different vertical leader. Each one is measured against different goals.

From the inside, it feels logical, because each community program maps to what their part of the org chart is trying to achieve.

From the customer’s perspective, it’s fragmentation.

The same customer ends up navigating multiple community experiences owned by different teams, each optimized for its own metric. That’s vertical thinking applied to something customers experience horizontally.

Calling any one of those efforts “community-led” doesn’t resolve that tension.

What community was actually doing

There are moments when community genuinely feels like the tip of the spear.

At Asana, community programs helped us expand into new markets. Champions drove internal adoption inside teams. Certified partners extended our reach into customers we couldn’t directly serve. Community surfaced friction in adoption long before it showed up in executive dashboards.

But community wasn’t operating in isolation.

It strengthened product decisions. It strengthened marketing credibility. It strengthened sales conversations. It strengthened expansion.

It amplified what the system was already trying to achieve.

Introducing community-integrated GTM

What I’m calling community-integrated GTM is a model that reflects how organizations function when they’re working well.

Community’s real leverage unfolds in three layers. They build on each other.

First: Alignment.
Community surfaces live customer signal across the lifecycle. When that signal is visible across product, marketing, sales, and customer success, teams stop optimizing against slightly different versions of reality. Alignment isn’t about agreement in meetings. It’s about shared inputs.

If marketing is telling one story, product is building for another, and sales incentives pull in a third direction, community engagement won’t compensate for that drift. Shared signal is the starting point.

Second: Integration.
Signal has to be embedded into decision loops. It needs to show up in roadmap discussions, positioning reviews, enablement materials, onboarding design, and expansion strategy. When community insight lives in a quarterly recap deck, it remains peripheral. When it’s part of how decisions get made, it shapes outcomes.

This is where many organizations stall. They gather insight but don’t restructure how they act on it.

Third: Amplification.
When alignment and integration are real, community strengthens what already works. Marketing claims are reinforced by visible customer momentum. Product bets are informed by active user behavior. Sales conversations include credible proof. Customer success can plug customers into peer networks instead of solving everything one-to-one.

Amplification is what people notice. Integration is what makes it durable.

What this changes inside a GTM organization

This reframing doesn’t mean community stops working toward shared goals.

Community should absolutely tie its impact to what matters most to the business at any given time. Pipeline. Activation. Retention. Expansion. Whatever the organization is optimizing for. That’s how credibility gets built. That’s how the dots get connected.

But community’s true impact doesn’t come from owning those outcomes in isolation. It comes from shaping how the vertical teams pursue them.

When community is integrated, product decisions are informed by live user behavior. Marketing messaging reflects how customers actually describe value. Sales conversations include credible proof from engaged users. Customer success can shift from reactive support toward peer-driven momentum.

Community works toward shared goals. It just does it through a horizontal lens that no other function has.

When organizations expect community to behave like another vertical team, they measure it narrowly and eventually split it apart. You see this in larger companies where multiple community teams emerge across different departments, each reporting into a different leader and each optimized for different metrics. Marketing builds one experience. Customer success builds another. Product builds its own. Developer relations builds a separate ecosystem.

From inside the org, it feels aligned to structure. From the customer’s perspective, it’s fragmentation.

That’s vertical logic applied to something customers experience horizontally.

Designing for community-integrated GTM means tying community to shared outcomes while protecting the horizontal vantage point that gives it leverage in the first place. Product, marketing, sales, and customer success still own their vertical goals. Community influences how those goals are pursued by strengthening the links between them.

Most GTM failures aren’t dramatic collapses. They’re slow misalignments. Teams operating from slightly different assumptions about the customer. Messaging drifting from roadmap. Sales optimizing for a slightly different definition of value than product intended. Small disconnects that compound quietly.

Community, when integrated intentionally, is positioned to see that drift early and influence correction across functions.

Over time, the shift shows up in how decisions get made across teams. That’s where durable advantage builds and compounds.

This is one of the core ideas behind my upcoming book, The Community Code, which comes out April 1.

Decoded Takeaways

• Community-led growth elevated the role of community, but it didn’t fully account for how vertically structured organizations distribute authority.

• Community’s leverage is horizontal. It influences product, marketing, sales, and customer success while still tying its work to shared business goals.

• Community-integrated GTM builds in sequence: align around shared customer signal, integrate that signal into decision loops, then amplify what works.

• When community strengthens the links between vertical teams and reduces cross-functional drift, it becomes a force multiplier across the entire go-to-market system.

• Durable advantage comes from how coherently the system operates over time.

Related Posts

• Reframing Community Metrics: What GTM Leaders Need to Understand About Value and Impact

• Why Community Should Report to the COO: Driving GTM Alignment and Business Results

• The 3 Biggest Lies About Community and GTM—and the Truth

A few years ago I was sitting in a meeting with a sales team reviewing a large enterprise deal. The pitch itself was solid. The prospect understood the product, the pricing, and the implementation plan. Nothing about the conversation suggested the deal was in trouble.

Then someone pulled up a workflow from our community.

It wasn’t a marketing asset or a case study. It was a post from a customer explaining how their team had solved a messy operational problem using the product. No polish. Just screenshots and a short explanation of what they had figured out.

The sales team shared it with the prospect.

The dynamic in the room shifted almost immediately. Instead of explaining what the product could do, the conversation turned to how another company was already using it in practice. The prospect started asking different questions. The example made the value tangible in a way the slide deck hadn’t.

Moments like that happen constantly inside strong communities. Customers share what they’ve figured out, workflows spread between teams, and ideas move from one organization to another faster than any company could orchestrate on its own.

Once you start paying attention to those interactions, it becomes hard to ignore how much influence they have. They shape how customers learn a product, how quickly they adopt it, and how confidently they recommend it to others.

Over time I started noticing something else.

Companies often recognized that these dynamics were valuable, but they struggled to explain where community actually fit inside the broader go-to-market system. Community touched product, marketing, sales, and customer success, yet it was usually owned by just one of those teams.

That tension kept showing up across companies, which is ultimately what led me to write my new book, The Community Code, available in print and digital April 1.

The pattern that kept showing up

Over the past decade I’ve built and advised community programs inside a number of SaaS companies. Some of them grew into fairly large ecosystems.

At Asana, for example, the community eventually included hundreds of events, a global ambassador network, and a forum with hundreds of thousands of members. Experienced users regularly helped newer customers understand workflows, troubleshoot issues, and adopt more advanced use cases.

Those interactions had real consequences for the business.

Customers ramped faster because they could learn from peers who were already further along. Product teams gained a clearer view of how teams were adapting the product to their own processes. Marketing had a steady stream of authentic examples of how the product was being used in practice. Sales teams could reference real workflows from existing customers instead of relying entirely on positioning.

None of that happened by accident. We built systems that connected what was happening in the community back into the business. Product teams paid attention to recurring themes from community conversations. Customer stories surfaced through community programs often became the most credible examples marketing had. Experienced users sometimes introduced other organizations into the ecosystem.

Over time the community stopped feeling like a side initiative. It behaved more like connective tissue between customers and the rest of the company.

But the team responsible for it still had to live somewhere on the org chart.

After seeing those dynamics play out across multiple companies, I started trying to articulate what was actually happening. The usual explanations for community work didn’t quite capture it.

That effort eventually became a book called The Community Code. In it, I explore how communities influence adoption, learning, and product understanding, and why those dynamics often cut across the traditional boundaries of marketing, sales, customer success, and product.

Where the structural tension appears

Inside most SaaS companies, go-to-market responsibilities are fairly well defined. Marketing drives demand and narrative. Sales manages pipeline and revenue. Customer success focuses on retention and expansion. Product owns the roadmap and feedback loops.

Community interacts with all of those areas, but organizationally it usually sits inside just one of them. Sometimes it reports into marketing, sometimes customer success, occasionally product or support.

Wherever it lands, the work inevitably gets interpreted through that team’s priorities. When community sits inside marketing, the focus often shifts toward advocacy and storytelling. Inside customer success, it becomes an onboarding or support lever. Inside product, it becomes a feedback channel.

None of those interpretations are wrong. They simply reflect the lens of the team responsible for the work.

The challenge is that what actually happens inside a healthy community rarely stays confined to a single function. Customers share knowledge with each other, surface friction, demonstrate workflows, and build credibility around how the product works in practice. Those interactions influence product, marketing, sales, and customer success simultaneously.

But the organizational structure around community rarely reflects that reality. The activity spans the system while the team responsible for it sits inside a single department. Once communities start working at scale, that mismatch becomes hard to ignore.

What’s inside the book

When I started writing The Community Code, I wasn’t trying to produce another tactical guide about launching a forum or running events. There are already plenty of resources that explain how to do those things.

What I kept encountering inside companies were deeper questions about how community actually fits into the broader go-to-market system.

Leaders would recognize that community mattered, but they struggled to explain exactly how it connected to outcomes like adoption, retention, or advocacy. Community teams often found themselves translating their work into different languages depending on who they were talking to. One conversation might be about marketing impact, another about product feedback, another about customer education.

The book unpacks those dynamics.

The first section explores community as a growth system and why strong customer ecosystems often generate outcomes that traditional GTM channels struggle to replicate. The second section introduces the Community GROWTH model, a framework for designing and scaling community programs so they align with real business objectives. The final section moves into the operational side of the work, covering how communities recruit members, how engagement evolves over time, how champions emerge, and how programs scale without losing the qualities that made them valuable in the first place.

While much of the material draws from programs I’ve built or advised over the years, the book also incorporates the perspectives of other experienced community leaders. Their voices and experiences are woven throughout the chapters, offering different viewpoints on the same challenges and reinforcing how these patterns show up across many organizations.

Why I wrote it

Community has matured a lot over the past decade. When I first started working in this space, the conversation was mostly about whether communities were worth investing in at all.

That debate is largely over.

Today the more interesting questions are structural. Companies are trying to understand how community connects to product development, customer education, adoption, advocacy, and revenue.

Community doesn’t operate in isolation. It shapes how customers understand products, how they learn from each other, how they adopt new workflows, and how they share their experiences with other companies. Those dynamics are already happening inside many organizations. What’s often missing is a framework for understanding how they fit together.

That’s what The Community Code explores. Writing it forced me to revisit nearly two decades of community work and put language to patterns I had mostly been operating on instinct.

The more time I spent working with communities, the more I realized that the most interesting things weren’t happening inside marketing campaigns or onboarding programs.

They were happening between customers.

Someone sharing a workflow they had figured out. A team adapting a use case they learned from another company. Experienced practitioners helping newer users navigate the messy early stages of adoption.

Those interactions often shape how products are understood long before a company’s official messaging does.

Most organizations already sense that something valuable is happening in those spaces. What they often struggle with is understanding how those dynamics connect to the rest of the business. Community ends up living inside one department while the effects show up everywhere else.

The Community Code unpacks those patterns. It draws on programs I’ve built, ecosystems I’ve helped shape, and the perspectives of other community leaders who have been wrestling with the same questions inside their own organizations.

Because once you start paying attention to how customers actually learn from each other, it becomes clear that community isn’t just another program inside go-to-market.

It’s part of how the whole system works.

Decoded Takeaways

• Customers often learn products faster from other customers than from formal onboarding programs.

• Community interactions influence multiple parts of go-to-market at the same time.

• Many organizational challenges around community come from structural placement rather than skepticism about its value.

• Companies that design community as part of their go-to-market system unlock far more value from it.

Recommended Posts

• Community x GTM Playbook: What Every CCO & Head of Customer Experience Needs to Know

• Make it Daebak: What K-Pop Fandoms Can Teach GTM and Community Teams

• Reframing Community Metrics: What GTM Leaders Need to Understand About Value and Impact

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

The space exists. Members participate. Programs are running. From the outside, it looks healthy. Internally, though, community hasn’t fully been claimed as part of the operating system.

That’s the environment DeMario Bell stepped into at Culture Amp.

Today, he serves as Senior Community Manager, North America, Marketing Developer Experience at Amazon Web Services. In this conversation, we focused on his time leading Culture Amp’s global community of more than 100,000 HR practitioners. What he inherited wasn’t dysfunction. It was something subtler. Community had momentum, but it wasn’t tightly integrated into go-to-market strategy. It was adjacent to the business rather than embedded within it.

That distinction shaped everything.

When community exists but isn’t positioned

Early on, DeMario ran listening tours both externally and internally. Externally, he surveyed members, studied NPS, and spent time with detractors rather than only promoters. Internally, he met with stakeholders across marketing, sales, and customer success to understand how they saw community and where they thought it could contribute.

The insight wasn’t shocking, but it was clarifying. Many stakeholders didn’t fully understand the function. Some barely knew the team. In a few cases, working relationships needed repair.

Before scaling outward, he rebuilt trust inward.

That work doesn’t show up in dashboards, but it determines whether future initiatives land.

Designing in sequence

There’s pressure in community roles to demonstrate movement quickly. Launch something new. Announce a program. Show growth.

DeMario resisted that instinct and instead designed in sequence.

Moderation came first. How are conversations structured? How is ownership shared without overburdening members? What guardrails protect quality as scale increases?

Rewards and recognition followed. If members are contributing expertise and time, how are those behaviors acknowledged in ways that reinforce the culture of the space?

Only once those foundations were stable did deeper initiatives like voice of the customer and ambassador programming make sense.

The order wasn’t cosmetic. Each layer depended on the previous one. That sequencing made the system more durable.

Then the environment shifted. The team was reduced from four and a half people to two during layoffs. Director-level responsibilities landed on his desk: forecasting, attribution, stakeholder alignment, executive communication.

What could’ve destabilized the function instead sharpened it. Community became less about engagement mechanics and more about infrastructure. Data capture. Process clarity. Translating participation into signal the business could use.

That shift is what often separates early-stage community work from mature community work.

Forums, support, and the narrow mental model

Many leaders’ only exposure to community is the support forum. A place where customers troubleshoot and ask questions. That function matters. It reduces friction. It improves product understanding.

But it’s not the whole system.

A forum answers a question. Designed community shapes identity and belonging around the product. It reinforces learning before friction escalates. It surfaces qualitative signal that can influence roadmap decisions. It contributes to retention and expansion when it’s integrated thoughtfully.

None of that happens by accident. It requires deliberate mapping between member personas and business priorities. It requires deciding where community intersects with marketing, customer success, and product, and where it doesn’t.

That boundary-setting is part of the design.

The invisible labor of education

Community work carries a constant layer of internal translation.

Stakeholders change. Leadership priorities shift. Budget pressure increases. New executives enter with different assumptions.

You don’t get to quietly execute in this role.

DeMario described his posture as consultative. At times political. Not in the cynical sense, but in the sense that influence requires repeated articulation. If the value of community isn’t explained regularly, it becomes invisible. If it becomes invisible, it becomes fragile.

That ongoing education isn’t ancillary to the role. It’s central to it.

Protecting the member

As community becomes more visible internally, demand increases. Marketing wants amplification. Product wants structured feedback. Sales wants references. Customer success wants scalable engagement.

All of those requests are rational.

But member trust is finite. If the space becomes extractive, the underlying asset erodes.

Part of the community leader’s responsibility is protective. Not oppositional to the business, but protective of the conditions that allow the business to benefit in the first place. Guardrails aren’t resistance. They’re durability.

Starting with why

When asked what he tells GTM leaders considering community investment, DeMario doesn’t start with tooling or tactics.

He asks why.

Why now. What problem are we solving. What constraint inside acquisition, engagement, or retention are we addressing.

Community built because competitors have one tends to remain ornamental. Community built to solve a defined problem has a different trajectory.

Clarity at the outset determines durability later.

Decoded Insight

Community becomes durable when it’s intentionally designed to intersect with business priorities while preserving the human experience that makes participation meaningful.

Timestamps

00:01 – Identity, belonging, and how personal experience shapes community design
08:04 – Stepping into Culture Amp and clarifying the mandate
11:48 – Listening tours, NPS, and engaging detractors
19:17 – Community inside marketing and GTM alignment
27:12 – Sequencing moderation, recognition, and ambassador programs
33:08 – Layoffs, expanded scope, and operational maturity
37:13 – Forums versus intentionally designed community
46:45 – Starting with why before investing in community

Recommended Posts

• Why Your Forum Isn’t Your Community—And What to Build Instead

• Community x GTM Playbook: What Every CCO Needs to Know

• Why Nobody Cares About Your Community Engagement Metrics (and What to Do Instead)

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

Community-building superstar Max Pete is currently at Sprout Social. In this conversation, we focused on his time at Square, where he stepped into a community that had been active since 2016.

By the time he arrived, the community already had structure, history, and habits. Engagement had settled into familiar patterns. Member behavior reflected a post-pandemic normalization. Nothing dramatic was happening. But nothing felt particularly sharp either.

That’s where his work began.

When a B2B community finds its equilibrium

As communities mature, they develop gravity. Programs continue because they’ve always been there. Rituals stick around because they once worked well. Engagement levels flatten into something predictable.

Max approached the situation with a quieter kind of rigor.

He revisited onboarding to understand how new members were entering the system. He evaluated gamification to see whether incentives still matched behavior. He looked at which programs were actively supporting members and which were simply consuming time.

Square’s members are business owners. Their time is constrained. Their reasons for participating are practical. That reality shapes the design decisions.

The team refined structure instead of expanding it. They created clearer spaces for asynchronous participation. They made it easier to find event recordings. They carved out room for business conversations that extend beyond product troubleshooting.

When a community reaches this stage, the question shifts toward integration. How does this space reduce friction for customers. How does it reinforce product understanding. How does it contribute to retention and expansion patterns.

Those are operational questions. They pull community into the broader GTM system rather than leaving it adjacent to it.

At the same time, the human layer never disappears. A thoughtful tag. A quick acknowledgment. A small seasonal badge. These signals compound. Even in B2B environments, people respond to being seen.

The reporting habit that changes your posture

One of the more honest parts of our discussion centered on a program Max ran earlier in his career. Members valued it. Participation was strong. When budgets tightened, the program was cut.

What stayed with him was not frustration about the decision, but clarity about what was missing. The connection between activity and business impact had never been formally captured.

Since then, his operating model has changed.

When new initiatives launch, baseline metrics are recorded immediately. Badge distribution. Rank progression. Monthly active users. Engagement movement over time. Even when leadership has not requested that level of detail.

Collecting data early shifts posture. It allows community leaders to speak in the language of the business when necessary. It makes engagement legible.

Qualitative stories still matter. Testimonials still matter. But narrative paired with data carries further inside executive conversations.

That pairing is what allows community to move from being appreciated to being relied upon.

What actually moves engagement

We also spent time on the small mechanics of engagement, which is often where community either compounds or stalls.

One tactic Max relies on consistently is thoughtful tagging. He looks at who has contributed to similar conversations in the past, who operates in a relevant industry, who has context to add. Then he tags them directly.

It’s manual. It requires paying attention. It works.

That kind of engagement assumes that participation is not evenly distributed. Some members need a nudge. Some members need a reminder that their perspective is useful. A well-placed tag can restart a thread that would otherwise sit quietly.

Broad calls for participation tend to fade into the background. When everyone is invited in the same way, no one feels particularly needed.

The same pattern shows up with recognition. A short thank-you message. A note acknowledging that someone helped another member. These gestures take seconds, but they reinforce something deeper. Participation is visible. Contributions are noticed.

Community grows through repeated signals of attention. Not spectacle.

Decoded insight

Community becomes durable when its activity can be translated into business-relevant signal without losing its human texture.

If the work feels meaningful to members but invisible to the organization, it stays fragile. If it is measurable but disconnected from real participation, it becomes hollow. The balance between those two is where community starts to influence how a company operates.

Why Max’s perspective carries weight

Max has worked inside startup environments and scaled SaaS organizations. That range shows up in how he thinks about tradeoffs. He understands when to experiment and when to stabilize. He knows that mature communities demand a different kind of attention than early-stage ones.

He’s also one of the most well-loved builders in the community space. Not because he’s loud. Not because he’s self-promotional. People consistently describe him as warm, honest, and generous with his time. He shares what he’s learning. He admits what he’s missed. He champions other builders.

That posture matters.

Community work is relational at its core. The credibility you build with members and peers eventually becomes part of the signal you carry inside your organization. Max embodies that balance between operator discipline and human care. Max is also featured in The Community Code book, and the themes we discussed here show up in his contribution there as well.

If you’re leading community in a B2B SaaS organization that has moved beyond launch energy and into operational reality, this episode is worth your time.

You can connect with Max on LinkedIn. He means it when he says his inbox is open.

If this conversation reflects something you’re navigating inside your own organization, I’m curious how you’re thinking about it. Community gets more interesting as it matures. It also gets more complex. That tension is part of the work.

Timestamps

00:00 – From freelancing burnout to community
05:40 – Stepping into a mature Square community
09:17 – B2B vs. B2C engagement realities
13:24 – Getting internal stakeholder input
21:19 – Capturing baseline metrics early
25:58 – Surprise and delight in practice
36:28 – Calibrating content and engagement
45:04 – When programs get cut and why
48:34 – Engagement tactics that actually work
53:58 – Why he continues to do this work

Last week, a story traveled well beyond the usual AI corners of the internet. It showed up in places like Fortune, Forbes, and even the New York Post. The premise was strange enough to spread on its own: a social network designed not for people, but for AI agents.

Not humans running bot accounts. Agents interacting directly with other agents. Comparing techniques, sharing context, and learning from what was happening in real deployments.

A lot of the coverage focused on how odd that sounded. What stayed with me was how predictable the pattern felt.

As agents spread across more real-world use cases, something interesting happened. Context started traveling laterally through interaction, not through centralized oversight. Learning accumulated through exchange. Patterns surfaced without needing to be specified ahead of time.

In practice, a shared space emerged.

That move followed a familiar path. As systems grow more complex, coordination through documentation and rules starts to strain. Interaction becomes a practical way for context to move. This is the same dynamic that shows up in customer communities, practitioner groups, and internal teams once reality starts changing faster than formal processes can track.

That’s why this story matters outside the AI news cycle. It reflects a set of conditions GTM teams already recognize.

When community becomes the default response

Community often gets framed as something layered on for engagement or loyalty. Sometimes that’s true. More often, community appears because the underlying system is under pressure.

Information spreads across too many places. Learning happens through experience instead of playbooks. Context lives in people rather than tools. Coordination gets more expensive. Feedback loops stretch out.

At that point, interaction starts doing quiet work. It moves knowledge. It shortens loops. It lets participants compare notes in real time.

This holds whether the participants are customers helping each other onboard, sales engineers trading field insights, or AI agents exchanging what they’re encountering across environments. The form varies. The function stays consistent.

Moltbook is interesting in this light because it shows how quickly shared interaction becomes useful once a system crosses a certain complexity threshold.

Where AI actually helps community members

A lot of AI-in-community conversations drift toward moderation, content generation, or automation. Those uses are visible, but they don’t address the main friction members feel day to day.

People aren’t short on information. What slows them down is figuring out what applies to them right now. The conversation that matters. The example that maps to their situation. The person who’s already been there.

Used well, AI can reduce the effort it takes to surface things like:

• Conversations tied to a member’s current problem

• People who’ve recently navigated similar situations

• Content grounded in real usage rather than positioning

• Themes that cut across fragmented discussions

This doesn’t replace human interaction. It shortens the distance to it.

When members reach relevant context faster, the effects ripple outward. Marketing hears how customers describe value and confusion in their own words. Sales gains access to peer context that feels grounded in reality. Customer success sees early signs of friction. Product teams start noticing patterns instead of chasing individual requests.

The interaction stays human. AI just makes it easier to find the right one.

How AI shifts the shape of community work

Community work has always involved a lot of invisible labor. Necessary tasks, but not the kind that benefit much from human judgment.

Organizing content. Routing questions. Summarizing long threads. Identifying overlap. Tracking participation manually.

Over time, that work pulls builders away from facilitation, interpretation, and relationship building.

This is where AI can change the shape of the role in a very concrete way. When the mechanical layer is handled automatically, builders spend more time making sense of what’s happening inside the community and less time managing its surface area.

They help different teams understand what the community is revealing. They translate experience into something usable. They apply context rather than just maintaining structure.

That shift doesn’t make the role lighter; it makes it more senior.

Teams that approach AI mainly as a way to cut costs tend to miss this. The value shows up when builders have more room to think, connect, and influence across the organization.

The GTM signal that’s hard to use

From a leadership perspective, community often feels diffuse. There’s activity, but the insight doesn’t arrive in a form that’s easy to act on. Valuable context lives in threads, events, and side conversations that don’t map cleanly to how GTM teams operate.

What’s missing is translation.

AI can help by interpreting what’s happening across the community and surfacing what matters to each function.

• Marketing benefits from patterns in how customers talk about problems and outcomes.

• Sales benefits from peer stories that reflect real buying contexts.

• Customer success benefits from early signs of risk or advocacy.

• Product benefits from clusters of need that explain why something keeps coming up.

When that interpretation layer exists, community starts feeding directly into prioritization and decision making. It stops feeling like a parallel effort and starts behaving like shared intelligence.

What this moment points to

Moltbook doesn’t need to be a model anyone copies. Its value is as a signal.

It shows how quickly shared spaces emerge when systems grow more complex than their formal structures. Context moves more easily through interaction. Learning compounds without needing to be perfectly categorized. Patterns surface early, before anyone knows exactly what to ask.

Many teams struggle here by swinging too far in one direction. Some expect AI to replace community. Others treat community as a place to experiment with AI features without much intent.

There’s a more durable middle ground. Community supports learning inside complex systems. AI helps make that learning easier to see and act on.

When those roles are clear, they reinforce each other. When they aren’t, teams end up with more activity and less clarity.

The work comes down to holding onto context while making insight easier to use.

Decoded Takeaways

• Community tends to appear once systems grow faster than documentation can keep up

• AI creates leverage in community by improving relevance and visibility

• Automating mechanical tasks gives community builders more room for judgment

• Community becomes more valuable when insights are translated by function

• AI strengthens community when it helps signal travel without flattening context

P.S. A special thank you to for inspiring this post!

Most GTM teams reach for simplification when scale shows up.

As the audience grows, variation starts to feel risky. Messaging tightens. Programming narrows. Community experiences get compressed into something broad enough to include everyone, even if it doesn’t feel particularly useful to anyone.

Early on, this can look like progress. Participation stays high. The surface area feels manageable. Over time, the cracks show up in quieter ways. Conversations drift toward generalities. Experienced customers contribute less. Newer members hesitate to jump in. The community keeps moving, but it stops pulling much weight across adoption, retention, or pipeline.

There’s another way to think about scale, one that treats audience growth as a business problem rather than a moderation challenge. It comes from an industry that operates with product portfolios, monetization pressure, and constant competition for attention.

That industry is K-pop.

Not as culture. As operating model.

K-pop groups operate like product ecosystems

K-pop groups are businesses. Albums, tours, fan platforms, merchandise, and sponsorships function as products. Decisions about how to grow an audience have direct commercial consequences. As scale increases, these organizations expand the experience in more targeted ways rather than compressing it.

That’s where SHINee offers a useful case study, even for leaders who have never paid attention to the genre.

SHINee debuted as a five-member group: Onew, Jonghyun, Key, Minho, and Taemin. As a group, they established a clear identity that anchored everything else. Over time, individual members launched solo projects that leaned into different styles, audiences, and creative directions.

From a GTM lens, the structure looks familiar:

• The group functions as the flagship product.

• Solo projects behave like differentiated offerings.

• Each attracts overlapping but distinct segments.

• Engagement and revenue increase across the ecosystem.

I’ve seen SHINee perform as a full group, and I’ve also attended solo concerts from Onew, Key, and Taemin. The experiences don’t feel interchangeable. They also don’t compete for attention in the way you might expect.

Fans engage where the value feels highest for them. Some stay close to the group releases. Others invest deeply in a specific member’s work. Both paths remain visible and supported within the same ecosystem.

That structural choice is the part most business communities overlook.

Why flattening feels reasonable, and where it starts to strain

In B2B community, flattening often shows up as discipline. One forum. One Slack. One cadence of programming. One voice. As the audience grows, everything gets routed into the same shared space.

The challenge is that customer needs spread out rather than narrowing as scale increases.

New customers look for orientation and reassurance. Experienced users want nuance and edge cases. Practitioners want peers who understand their constraints. Leaders want signal they can trust. When all of that activity lives on the same surface, relevance drops unevenly.

At that point, engagement metrics start telling an incomplete story. Posts continue. Comments happen. Activity remains visible. What becomes harder to see is how that activity connects to adoption, retention, or advocacy.

K-pop avoids this tension by treating segmentation as a way to manage growth, not as something to contain.

A note for execs who see community as “nice to have”

If this still feels abstract, it helps to strip the analogy down to economics.

K-pop companies invest in solo projects because different segments monetize differently, retain differently, and create different kinds of long-term value. Forcing every fan into the same experience would cap revenue, shorten engagement cycles, and weaken loyalty over time.

SaaS businesses already operate with this logic elsewhere. Products get segmented by use case. Pricing tiers reflect value. Onboarding adapts as customers mature. Vertical solutions emerge once horizontal ones stop carrying their weight.

Community often gets excluded from this thinking. It’s treated as a single surface rather than a system. The result looks efficient, but it leaves value on the table.

When community is structured as an ecosystem, it starts behaving like one. Adoption accelerates because customers can find peers solving similar problems. Retention improves because relevance doesn’t decay after onboarding. Expansion and advocacy show up because deeper engagement creates stronger attachment.

This isn’t about belonging for its own sake. It’s about whether community is allowed to do the same strategic work as the rest of your GTM system.

Sub-communities increase relevance without weakening the core

SHINee’s solo projects extend the group rather than pulling it apart.

The group identity stays intact, while fans move into different experiences based on taste, interest, and energy. Some remain loosely connected to the group’s releases. Others invest deeply in a specific member’s work. Both paths coexist without forcing everyone into the same mode of participation.

That pattern maps cleanly to how scalable community-led growth works in SaaS.

Strong communities tend to develop layers over time. There’s a shared identity at the center that anchors trust and belonging. Around it, more focused spaces emerge that reflect how customers actually use the product and how their needs evolve.

Those spaces end up carrying real weight. They absorb complexity that would otherwise overwhelm the core. They give advanced users somewhere to go. They help newer members understand what progress looks like. Conversations stay specific without fragmenting the audience.

In practice, this often shows up as:

• Role-based depth, where admins, builders, or operators compare approaches without rehashing fundamentals.

• Use-case or industry depth, where peers share constraints and tradeoffs that don’t apply universally.

• Lifecycle depth, separating early adoption questions from longer-term optimization and influence.

As these layers mature, the community often becomes easier to navigate rather than harder. People spend less time scanning for relevance and more time contributing where their experience actually fits.

A quick test GTM leaders can run

If you’re trying to understand whether your community is flattening as it grows, you don’t need a new platform or a full redesign. The signals usually show up in behavior.

Look at where your most advanced customers spend their time. When they outgrow your primary community space, do they disappear, or do they create side channels and backchannels to get what they need?

Pay attention to which conversations regularly stall. Are people talking past each other because they’re at very different stages, or trying to solve fundamentally different problems in the same thread?

Notice how clearly intent shows up. When someone engages deeply in your community, can your sales or customer success teams tell why they’re there without asking? Or does everything register as the same generic “engaged user”?

Finally, compare community activity to downstream outcomes. When adoption accelerates or retention dips, does anything change in the community itself? If the answer is no, that often points to an experience that’s become too broad to reflect what customers are actually doing.

None of this appears neatly in a dashboard. It shows up in where people cluster, where they linger, and where they stop participating once the community no longer meets them where they are.

Where GTM impact starts to show up

When community is structured this way, the GTM effects become easier to see.

Marketing gains clearer signal around which narratives resonate with specific audiences, based on where conversations concentrate and what members respond to. Sales sees intent through participation patterns that reveal context, not just volume. Customer success teams notice faster adoption when customers can learn from peers facing similar constraints. Product teams hear feedback from users operating in comparable environments, which makes patterns easier to interpret.

Over time, community stops being a debate about platforms or formats and starts behaving like infrastructure. It supports adoption, retention, pipeline, and advocacy in ways other channels struggle to match.

The risk most teams underestimate

Many leaders worry that sub-communities will fracture the audience or dilute the brand. In practice, the strain shows up elsewhere.

When everything is designed for everyone, experienced users disengage quietly. Newer members hesitate to participate. The core weakens, even though activity continues.

K-pop succeeds because it preserves a strong center while expanding relevance outward. Belonging and specificity coexist. Growth adds depth instead of smoothing it away.

Business communities can do the same, but only when segmentation is treated as a strategic choice rather than a concession to complexity.

Decoded Takeaways

• Communities lose GTM impact when scale prioritizes uniformity over relevance.

• Sub-communities strengthen the core when they’re anchored to a clear shared identity.

• Self-selection into depth produces clearer signals than one-size-fits-all programming.

• Community-led growth compounds when segmentation improves signal for marketing, sales, customer success, and product.

• When a community stays active but struggles to influence adoption, retention, or advocacy, the issue often traces back to flattened experiences rather than lack of scale.

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

The conversation usually shows up right around planning season.

A founder is looking at a new year with a mix of ambition and fatigue. Last year didn’t fall apart, but it didn’t quite come together either. Pipeline felt harder to predict. Support volume crept up. Retention held, but only with more effort than expected. Product shipped, but adoption lagged behind the roadmap.

Somewhere between goal-setting decks and headcount spreadsheets, someone floats the idea of building a community.

Not as a campaign. Not as a side project. As a way to change the shape of the business. More engaged customers. Stronger advocacy. Better feedback loops. Maybe even a little lift across the funnel.

This is usually the moment when community starts carrying expectations it was never meant to bear. It’s rarely framed as a fix, but it often functions like one. A way to address a cluster of problems without naming each of them directly.

That’s where expectations start to drift.

Community has real power, but it isn’t corrective by default. It doesn’t resolve underlying tension. It reflects it, at scale.

Why community becomes the answer to everything

Community tends to enter the picture when the edges between teams start to fray.

Marketing is under pressure to drive customer engagement without leaning harder on paid channels. Sales is being asked to do more with warmer leads and longer cycles. Customer success is trying to move from reactive support to proactive retention. Product wants clearer signals about what actually matters to customers, not just who is loud.

Community appears to offer something to each of those groups at once.

And in isolation, each of those expectations is reasonable.

The trouble starts when no one reconciles them.

Community gets positioned as a shared resource without shared accountability. Marketing expects stories. Sales expects proof. Success expects deflection. Product expects insight. Everyone agrees community is strategic, but no one agrees on what tradeoffs it’s meant to absorb. Over time, this ambiguity stalls community and weakens trust in the function itself.

At that point, community doesn’t fail loudly. It fails quietly.

The conversations don’t quite land. Engagement looks fine on the surface, but nothing downstream changes. Teams struggle to point to concrete impact, so they start narrating intent instead. Community becomes busy without being directional.

This is often when leaders conclude that community-led growth is slow, or hard to measure, or not worth the investment.

What’s usually happening is simpler. The company hasn’t decided what it wants amplified.

What community is actually good at supporting

When community works, it tends to work in very specific ways.

It reinforces behaviors that already exist among customers. It accelerates trust where trust is already forming. It makes patterns visible that are already repeating across accounts.

In B2B environments especially, community-led growth shows up less as a spike and more as a drag reduction. Sales conversations move faster because prospects have context. Onboarding gets smoother because customers can see how others navigate complexity. Retention improves because customers feel oriented, not because they feel entertained.

For marketing, community sharpens language. You hear how customers explain value to each other, not how they respond to positioning tests. For customer success, it creates air cover. Fewer tickets about the same issues. More room to focus on moments that actually affect adoption. For product, it reveals where friction compounds across workflows, not just where features are requested.

None of this requires community to persuade customers to care. It assumes they already do.

That assumption matters more than most teams realize.

What community can’t carry for you

Community struggles when it’s asked to compensate for things the business hasn’t resolved.

If customers are unclear on who the product is for, community doesn’t clarify that. It turns into a place where mismatched use cases collide. If sales sets expectations the product can’t consistently meet, community becomes the record of those gaps. If internal teams disagree on what success after purchase looks like, community reflects that disagreement in real time.

These issues don’t show up as a single moment you can fix. They accumulate.

Questions linger without response because ownership is unclear. Power users disengage because they’re tired of translating for everyone else. New members watch more than they participate, picking up on tone before content.

From the outside, it can look like low engagement or poor community management. From the inside, it’s usually a signal that the system around the community isn’t stable enough to support it.

This is where the distinction between a community and a forum becomes less academic. Forums collect activity. Communities expose relationships. If the underlying relationships between teams and customers are strained, community doesn’t hide that. It gives it a microphone.

A few questions worth sitting with this year

If you’re entering a new year thinking about community, these aren’t questions to answer quickly. They’re questions that tend to surface whether you ask them now or later. The difference is whether you engage with them deliberately, or let your community surface them for you.

• Are customers already helping each other in small, informal ways?
  If not, community won’t create that instinct on demand. It will feel manufactured.

• Do teams agree on what happens after the deal closes?
  If retention, adoption, and expansion mean different things internally, community will surface those seams.

• Is there clarity on who acts on what the community reveals?
  When insights pile up without response, customers notice.

• Are you prepared for more visibility into frustration as well as success?
  Community doesn’t filter sentiment. It aggregates it.

• Is there patience for impact that compounds rather than converts?
  Community supports pipeline and advocacy over time, not on a campaign calendar.

If these questions feel uncomfortable, that’s not a reason to avoid community. It’s a reason to understand what it will amplify.

Reframing the decision for the year ahead

At the start of a new year, it’s tempting to ask whether community should be on the roadmap.

A more useful question is what you’re willing to hear more clearly.

Community can make momentum louder. It can also make friction harder to ignore. It doesn’t change the direction of the business. It shows whether that direction holds up once customers start talking to each other.

That’s why this idea shows up early in The Community Code, a book I’m publishing later this spring. Not as a warning or gatekeeping exercise, but as a grounding one. Community-led growth rewards coherence, and it also exposes its absence.

Decoded Takeaways

• Community amplifies existing GTM systems. If those systems are unclear, the amplification makes that visible fast.

• When community feels noisy or unfocused, it often reflects upstream misalignment.

• Scalable community depends more on internal clarity than external engagement.

• Treating community as a fix usually delays harder strategic decisions.

• The real choice is whether you’re ready for visibility, not whether you want engagement.

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

Tiffany Oda has spent more than a decade working in community roles at companies like Salesforce, Talkbase, and now Asana. That range matters more than it might seem at first glance.

She’s built programs from scratch, stepped into communities that needed to evolve, and worked inside large organizations where community sits right alongside support, operations, and customer experience. She’s also lived the part of the job that rarely shows up in job descriptions: constant education, internal alignment, and translating between what members need and what the business expects.

Today, Tiffany is part of the community team at Asana, where the support community plays an active role in how customers learn, troubleshoot, and help one another. That work was recently nominated for CMX Support Community of the Year, which says a lot about how intentionally the program is designed and run.

When we sat down to talk, we weren’t aiming for theory. We wanted to unpack what actually makes community work, especially when it’s closely tied to support and GTM.

What “community” actually means inside a company

One thing Tiffany came back to early in our conversation is that community rarely means the same thing to everyone internally. To some teams, it’s peer-to-peer support. To others, it’s advocacy, education, or engagement. When those definitions aren’t aligned, community teams end up absorbing the confusion.

A lot of Tiffany’s work across roles involved internal clarification. Not evangelizing, but grounding expectations. What problems is community meant to help solve? What isn’t it responsible for? How does it complement support instead of quietly becoming a replacement for it?

As companies grow, this clarity matters even more. Without it, community programs can turn into catch-alls for unresolved needs or get measured against goals they were never designed to support.

Where support and community actually intersect

A big part of Tiffany’s current work at Asana sits right at the intersection of support and community, which is where this conversation gets especially relevant for GTM leaders.

Support communities, when they’re designed intentionally, do more than deflect tickets. They give customers a place to learn in context, hear from peers who’ve been there before, and build confidence using the product. That kind of learning is hard to replicate through documentation alone.

Tiffany talked about community as an extension of the support experience, not a separate destination. Customers arrive with real questions and real friction. Community adds value by pairing official guidance with lived experience, and by letting patterns surface that support teams can learn from over time.

That’s where community starts to compound its value. It helps teams scale without losing trust, reduces repetitive support load, and creates feedback loops that benefit product, support, and GTM teams all at once.

Building from scratch takes more patience than most teams expect

Across Salesforce, Talkbase, and Asana, Tiffany has helped launch community programs from the ground up. One lesson shows up every time: most organizations underestimate how much planning and alignment needs to happen before anything should go live.

When teams rush to launch, the cleanup work shows up later. Stakeholders have different expectations. Tools get chosen before use cases are clear. Early members arrive without enough context to participate meaningfully.

Tiffany emphasized slowing down early. Getting clear on goals. Involving cross-functional partners, especially support and product. Thinking through how members will actually use the space, not just how it looks in a slide deck.

Community wasn’t built in a day, and trying to shortcut that reality usually creates friction down the line.

Vendor choices shape behavior more than we admit

Tooling came up as a surprisingly important part of our conversation. Tiffany was clear that vendor selection isn’t just a technical decision. It’s a strategic one.

Who gets involved matters. Support, community, and GTM teams all bring different needs to the table, and leaving any of them out tends to create downstream issues. The right tool isn’t the one with the longest feature list. It’s the one that supports the kind of participation and outcomes you’re actually trying to create.

She also pointed out that tools should serve the program, not define it. Communities evolve, assumptions change, and flexibility usually matters more than perfection.

Engagement shifts from transactional to relational

Another theme that kept coming up was how engagement evolves over time.

Early participation is often transactional, especially in support-driven communities. People show up with questions and want answers. That’s expected. Over time, though, the strongest communities create space for something deeper.

Tiffany talked about the shift toward intrinsic motivation. Members start helping because they want to. They recognize each other. They feel ownership. The community becomes a place they return to, not just a resource they use once.

Designing for that shift takes intention. Feedback matters. Recognition matters. And so does paying attention to how people are actually using the space, not how the team originally imagined they would.

Feedback is how community stays relevant

If there was one principle Tiffany returned to throughout the conversation, it was this: community programs have to evolve.

Member needs change. Business priorities shift. Support volumes fluctuate. Communities that stay static eventually lose relevance, even if they start strong.

Feedback isn’t a checkbox. It’s the input that keeps programs aligned. That includes surveys, but it also includes everyday signals from participation, questions, and behavior. The work is never really done, and that’s not a failure. It’s the nature of community.

Decoded Insight

The strongest communities live where support, trust, and shared learning come together.

Closing thoughts

If you’re building or scaling a community that touches support, customer experience, or GTM, Tiffany’s perspective offers a grounded look at what actually makes these programs work over time.

You can connect with Tiffany Oda on LinkedIn to keep the conversation going. And if this post sparked a thought or challenged an assumption, feel free to leave a comment or share it with someone navigating similar terrain.

Timestamps

00:00 – Tiffany’s path into community
03:04 – Defining community inside organizations
06:08 – How community roles vary by company
08:47 – Community’s role in support and GTM
11:59 – Building community from scratch
14:56 – Vendor selection and alignment
18:07 – Launching with support in mind
20:53 – Engagement and motivation
23:56 – Evolving established programs
27:08 – Feedback and iteration
29:45 – Final reflections

We talk incessantly about ICPs, personas, and segments. In most GTM teams, these are sacrosanct, even fetishized, as if they hold the secret to unlocking rational decision-making, predictable retention, efficient pipeline. If only! Here’s the problem: while personas have their place, they’re not people. And when your strategy treats personas like people, you’re designing for the average instead of the individual, driving a wedge between your go-to-market strategy and the messy, emotional, human reality of your customers.

At a recent dinner I attended with other GTM leaders, a guest mentioned how Gen Z’s trust operates on what they called a “vibe check.” That line stuck with me. It captured something I’ve been thinking about for a while: GTM teams rely so heavily on personas that they often miss the nuances of real people. I’ve seen this repeatedly in community-led growth initiatives, cross-functional GTM alignment efforts, and product-community integrations. It’s time we stop confusing persona for person.

A persona is a model. A person is real.

When we talk about a persona, what we usually mean is a composite: role, title, industry, pain-point bucket, decision-maker checklist. It’s tidy. It fits nicely into spreadsheets, slide decks, and demand-gen campaigns. But a person doesn’t fit that neat box. A person is also dealing with uncertainties, emotions, competing priorities, and politics, often irrational ones.

Why this matters for GTM and community-driven engagement:

• Personas direct you toward product features, value propositions, and messaging templates. Persons push you toward listening, empathy, and nuance.

• Personas create discrete handoffs where marketing owns “the persona” up front, sales picks it up in outreach, and CS manages “the same persona” in renewal. Persons demand alignment across functions because one human experiences the company as one brand.

• Personas optimize for average behavior. Persons optimize for diversity of behavior, for outliers, and for growth levers through advocacy and community.

In other words, designing around a persona often leads to fragmentation of experience. Designing around a person leads to alignment.

How this plays out in GTM and community

If your company has a “persona” mindset you might see:

• Marketing develops templated campaigns: “VP of Engineering, innovation in regulated enterprise.”

• Product builds “modules for that persona”: “Dashboard for VP metrics.”

• CS segments “that persona” as a renewal cohort: “All renewals where VP of Engineering signed off.”

Each team increments the persona’s “representation” in isolation. They forget that behind that persona is a human with a job, a team, a political mandate, a weekend hobby, maybe a side hustle. They bring their personal context to every interaction, even if we ignore it.

If instead you bring a “person-centric” mindset, your GTM strategy shifts. You start asking:

• What are the emotional stakes this individual has beyond the job title?

• What community or peer group does this person belong to, and how can we tap that?

• How does this person’s journey through marketing, product, community, and CS feel as a continuous thread rather than three separate handoffs?

• How might this individual become an advocate or network connector, not just a unit to convert or retain?

Take a real example: dbt Labs built its product around analytics engineers, but its growth engine wasn’t just a persona narrative. The company leaned into real people; practitioners who wanted connection, peer learning, conference meetups, and contributions to open source. Their community generated a meaningful portion of inbound leads, and product adoption grew via word of mouth through these humans, not just an ICP checklist.

For cross-functional GTM alignment across marketing, product, CS, and community, this matters deeply. When you treat people as personas, each function builds for “their version” of that persona. But the customer only experiences one company. When you treat people as people, you align the touchpoints: marketing creates relevant invitations, community fosters connection, product delivers value, and CS drives outcomes together.

Why personas persist (and when they become a trap)

Personas endure because they offer simplicity in complexity. In B2B, especially, you have to distill myriad variables (industry, org size, role, decision process, etc.) into something digestible. The danger comes when:

• A persona becomes the strategy instead of a tool.

• You stop drilling into actual motivations, behaviors, communities, or peer networks behind the persona.

• You rely on historical data and assume the persona remains stable, when real people and markets are shifting fast.

In that same dinner conversation about Gen Z’s “vibe check,” I pushed the group to think about what that means for modern GTM. If your strategy for Gen Z-influenced buyers still treats them as traditional personas defined by role, title, or budget authority, you’re missing how they actually evaluate trust, community, and peer signal. One letter separates “persona” from “person,” but the gap between them is huge.

How to shift from persona-driven to person-centered GTM

Here’s how to reorient your GTM strategy without throwing out persona work entirely:

1. Map actual journeys, not just idealized ones.
Go talk to real users in that persona bucket. What were they doing just before discovery? What peer forums do they belong to? What frustrations moved them to search? Use these qualitative insights to enrich the persona and make it human.

2. Audit cross-functional touchpoints through the human lens.
Marketing, community, product, and CS each play a part. At every handoff, ask: “What will this person think, feel, and do here? What cues matter?” If each team builds for the persona without coordinating the human flow, you’ll hear complaints like “We were promised one thing and delivered another.”

3. Design your community as a place for real people, not just customers.
If you’re building a scalable community, don’t focus only on “users of product X.” Build for “practitioners who care about topic Y.” That subtle shift expands your reach from the immediate persona to the human motivation behind it. Community then becomes a GTM lever across retention, advocacy, and adoption.

4. Measure behaviors that reflect people, not just personas.
Don’t just track the percentage of persona X who convert. Track how many members of the network contribute, refer, or co-create. These are signals of person-level engagement. For example, dbt tracks contribution, advocacy, and community journey, not just headcounts.

5. Iterate your persona based on what real people show you.
Your “ideal persona” was a hypothesis. Let it evolve by observing people. Ask what different contexts they’re in, what adjacent roles matter, and which peer networks they’re embedded in. Over time the model adapts and becomes richer.

Say it with me: personas are not people

If your GTM strategy refuses to grapple with the complexity of real people, if it stays anchored in tidy persona boxes, you’re limiting your ability to build engaged communities, differentiated product experiences, and aligned customer journeys. But if you make the shift—designing for people who exist, not just personas you invented—you open the door to deeper engagement, stronger retention, and a community-led growth flywheel instead of a segmented funnel. Personas aren’t useless. But person-centric thinking should be your default.

Decoded Takeaways

• When you treat customers as personas you design for “average.” When you treat them as people you design for connection, diversity, and meaningful engagement.

• GTM alignment improves when all functions build for the same human experience, not isolated persona fragments.

• Community is a powerful lever for shifting from persona to person because it reveals motivations, networks, and peer behavior that personas alone miss.

• Real people show you what the persona model leaves out—peer context, emotional stakes, and unexpected use cases. Use that to iterate and grow.

• Measuring person-centric signals like contribution, advocacy, and referral gives you a fuller view of community-led growth, adoption, and retention than just tracking “persona X sign-up rate.”

  Thanks for reading The Community Code! Subscribe for free to receive new posts and support my work.

You can watch our full conversation in the video above or read on for highlights and takeaways.

Jason’s path into community leadership wasn’t traditional. He earned a master’s degree in biblical exegesis and expected to spend his career in teaching or ministry. Along the way he discovered Logos, a research tool used by pastors, theologians, and scholars. He began sharing tips and support through Facebook groups and newsletters, which eventually led to a role in marketing. Over time Jason transitioned into community leadership, helping Logos evolve from a collection of legacy forums into a modern, connected community.

Turning a legacy forum into a living community

When Jason took on his new role, Logos already had more than twenty years of forum history. It was an incredible resource for user-to-user support but not yet a true community. He led the migration of that system to Higher Logic Vanilla, a move that gave the company a chance to rethink what community could mean for its users.

Instead of focusing only on troubleshooting, Jason wanted to make the experience about connection and learning. His team added an events calendar, built product feedback loops, and introduced AI-suggested answers to help members find relevant information faster. These steps transformed the space from a traditional forum into a place people wanted to visit regularly, not just when they needed help.

He also consolidated multiple user portals, including support, feedback, and the knowledge base, into one hub at community.logos.com. That small but strategic change made it much easier for members to find answers, share feedback, and stay involved.

Balancing passion, structure, and internal alignment

Faith-based communities come with unique dynamics. Theological conversations can turn passionate quickly, and moderation requires both empathy and structure. Jason relies on a long-standing volunteer group called MVPs (Most Volunteer Posts) to help monitor discussions and keep conversations healthy. These volunteers are essential partners who help identify issues early and maintain a respectful environment.

One story he shared stood out. A member posted a heated message that crossed the line. Jason had to step in and issue a temporary ban, which turned into a weekend-long email exchange. The member eventually returned to post a public apology. The community responded with understanding and encouragement. Jason saw this as a defining moment. “That’s the difference between a forum and a community,” he said.

Internally, Jason has been working to help others at Logos understand the strategic role of community. He created clear escalation paths, launched a company-wide Slack space called “Ask Community”, and started regular reporting updates to share key metrics and insights. These consistent touchpoints helped shift perceptions inside the company, moving community from a support function to a cross-functional program that drives connection, feedback, and learning.

Making community everyone’s business

At Logos, the community function sits within the customer success organization. That structure fits naturally but also introduces competing priorities. Marketing wants visibility, product wants feedback, and CS wants faster answers. Jason’s approach is to stay transparent about what the community can realistically deliver while keeping the focus on outcomes that support customers.

His primary metrics tie back to customer success, such as faster response times and increased satisfaction. He also tracks secondary signals like engagement, churn risk, and how often users reference the community during support interactions. By connecting these dots, he helps other departments see how community strengthens the broader customer journey.

He also makes collaboration an ongoing process. Jason works closely with product, support, and marketing leaders to ensure community insights feed into decision-making. His internal “roadshow” updates keep everyone informed and invested, showing that community is not a side project. It is a critical part of how Logos serves and learns from its users.

Why he does this work

When I asked Jason what keeps him motivated after wearing so many hats—educator, marketer, and community manager—his answer was immediate. It’s the people. He shared a story about two users who met through the Logos community, became friends, and eventually introduced their families to each other. To Jason, that story captures the real value of this work.

“I’ve done social and SEO, but those things can feel transactional,” he told me. “Community is life-giving. It changes people.”

That sense of connection and shared purpose is what drives him. The product may be the starting point, but the relationships people build around it are what make the work meaningful.

Key Takeaways

• Community programs can evolve at any stage, even in long-established organizations.

• Volunteer leaders are powerful partners when they’re supported with clear roles and recognition.

• Internal storytelling builds credibility. Share community wins across the company to make the impact visible.

• Replatforming is an opportunity to redesign how people connect, not just move data.

• Cross-functional alignment requires clarity. Define what community is, and what it is not, so others don’t define it for you.

• Empathy and transparency build trust. Sometimes the best community outcomes come from difficult conversations.

Decoded Insight

A thriving community isn’t built on technology. It’s built on clarity, connection, and consistency.

The tools matter, but they only go as far as the vision that guides them. Jason’s story at Logos is a reminder that communities evolve not just through new platforms or AI features, but through the intention behind them. He focused on connection first, process second, and technology third, and that order made all the difference.

As GTM and community leaders, it’s easy to get caught up in growth metrics or new engagement tools. But sustainable community programs come from doing the slow, patient work of defining purpose, setting expectations, and building trust both with members and internally across teams.

The next time you evaluate your community strategy, ask yourself: are we building systems, or are we building connection? The answer will tell you whether you’re building a forum or a true community.

Want to connect with Jason?

You can find him at community.logos.com. Reach out if you’re interested in how Logos approaches community building.

If this conversation sparked ideas or new perspectives, feel free to leave a comment or share the post with someone who’d enjoy it.

Timestamps

00:00 – Introduction to Faith-Based Community Building
02:41 – Jason’s Journey into Community Management
06:41 – The Community Program at Logos
11:16 – Modernizing a 20-Year-Old Forum
15:57 – Navigating Theological Discussions and Conflict
19:26 – Managing Sensitive Conversations and Moderation
24:37 – Building Internal Buy-In and Collaboration
29:52 – Creating Communication and Escalation Channels
34:05 – Defining Success and Reporting Metrics
39:39 – The Value and Flexibility of Community Management
43:39 – Why Community Work is Life-Giving

Everyone is asking how AI will disrupt GTM. The better question is what happens when AI runs without community. The short answer is, it doesn’t.

AI isn’t replacing connection, it’s exposing the need for it

AI has worked its way into every corner of GTM. Sales teams are experimenting with it for prospecting emails and call notes. Marketing is using it to draft campaigns. Customer success is rolling out bots for front-line support. Product teams are running it across feedback in search of insights.

When you see AI everywhere, it’s easy to wonder if community is next. If a model can answer questions, recommend resources, or provide onboarding, why invest in creating a space for customers to talk to each other?

That assumption is wrong. AI generates information. Community creates trust. And trust is the actual lever in GTM. Without it, all those outputs are just noise.

Efficiency is a mirage without trust

Executives love efficiency. AI promises faster output, fewer repetitive tasks, lower costs. Those are fine, but efficiency isn’t what changes customer behavior. Connection is.

I see the efficiency mirage play out all the time:

• Marketing. You can churn out content at scale, but if no one believes it, it won’t drive a single deal.

• Sales. You can identify perfect-fit leads, but without community proof points, conversion stalls. Trust is what moves deals across the line.

• Customer success. You can answer more tickets with bots, but customers who feel dismissed are more likely to leave. Retention is built on being heard.

• Product. You can cluster feedback with AI, but if you don’t engage in conversations, you miss the nuance that fuels adoption.

AI makes things faster. Community makes them credible. If you confuse the two, you’ll end up with busy dashboards and flat results.

Redefinition: how AI and community work together

The smartest play isn’t to choose between AI or community. It’s to use them together — AI for scale, community for meaning.

Here’s how the relationship works when you design it with intent:

• AI surfaces signals. Community makes sense of them. A model can flag patterns in behavior, but customers explain why they matter and what to do with them.

• AI automates content. Community decides what’s credible. AI drafts tutorials or scripts. Community vets them, improves them, and makes them usable.

• AI generates recommendations. Community gives people confidence to act. An algorithm can suggest next steps. People act when they see peers who already made those steps work.

This is community redefined. Not a forum. Not a support channel. It’s the trust layer that makes AI-driven GTM believable.

Forward-thinking companies are already pairing community with AI-driven GTM efforts

This isn’t hypothetical. Companies are already showing what happens when AI is paired with community.

• Replit. Developers experiment with AI coding agents, then share the work in forums. Peers refine, troubleshoot, and improve it. Individual hacks become collective knowledge that accelerates adoption.

• Runway ML. The generative video platform highlights community-built projects powered by AI features. These examples aren’t just flashy demos. They give other creators the confidence to test new features themselves.

• Character.AI. Users don’t just interact with AI characters. They create their own and build sub-communities around them. The staying power comes from people, not the model.

AI can spark activity. Community is what sustains it. That pattern is already in play.

The client lesson: why credibility beats scale

If you’re running marketing, sales, CS, or product, you’ll keep hearing pitches about how AI will make you faster or leaner. Some of that is true. But the real problem isn’t speed. It’s credibility.

I worked with an advisory client recently who had to choose which lever to pull. They could have leaned on AI to pump out more content, automate outreach, and create the appearance of scale. Instead, they made a different bet. They invested in building a community anchored in peer relationships and trust.

Their reasoning was blunt: their mission depended on credibility, and customers weren’t going to find that in a campaign or a recommendation from a model. They needed to see people like them navigating the same challenges and succeeding.

Together, we built a framework that gave customers space to share stories, compare experiences, and validate each other’s progress. The company still used AI behind the scenes, but the centerpiece was human connection. The goal wasn’t volume. It was confidence.

That decision stood out because it was the harder path. Efficiency would have been easier to sell internally. But the leadership team understood that peer trust was the only thing that could move their audience. And that’s the shift I’m starting to see across GTM. The real question isn’t “how fast can we go?” It’s “how believable are we?”

Decoded Takeaways

Community isn’t being replaced by AI. It’s becoming more important because AI on its own doesn’t create trust.

• AI doesn’t build belief. It generates outputs, but customers only act when they hear proof from peers.

• Community makes AI usable. AI can produce signals, recommendations, and content. Community filters, contextualizes, and makes them actionable.

• AI without community is a vanity metric machine. It produces activity, but activity without trust doesn’t translate into growth.

• The GTM payoff spans every team. Marketing gains credibility, sales closes more deals, customer success drives retention, and product fuels adoption when AI and community are designed to work together.

• We already see the pattern. Replit, Runway ML, and Character.AI prove that AI activity becomes meaningful only when community sustains it.

AI will accelerate what’s possible, but it won’t do the hard work of building trust. That’s still the job of community. And in a GTM environment obsessed with efficiency, trust might be the most valuable asset left.