Jane Nadaraja has spent nearly two decades working across community, marketing, events, and advocacy programs. She started her career at Yelp, spent six years at Patreon working closely with creators and their communities, and most recently worked with Grammarly’s large-scale community. She’s also advised companies on how to build programs that can grow without turning into a pile of disconnected activities with a nice program name slapped on top.
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
