Where Community Breaks Down Inside GTM
After years building communities in SaaS, I kept running into the same problem: companies knew community mattered, but very few understood where it actually fit inside go-to-market.
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.