DevRel Activation Isn't Awarness Anymore: A better PLG Approach

Most companies have seen big benefits from Developer Relations (DevRel), especially when it comes to building awareness. Traditionally, DevRel's main goal has been simple: get noticed, bring in developers, and expand the community.

But that approach isn't enough anymore. From what I've seen, DevRel should be part of the entire funnel, not just sitting outside it.

After you've got your plan, product, and rollout ready, the big question is: what should DevRel focus on next? There are endless options, but the real challenge is finding those less obvious, high-impact areas that actually drive product adoption.

Most companies aren't sure what those areas are. Based on my experience, in a Product-Led Growth (PLG) world, DevRel isn't just about awareness anymore. It's about getting developers started, helping them adopt the product, and keeping them engaged for the long haul.

Today's developers want more than just to know your product exists. They want to see value right away, with as little hassle as possible, and they want it to work at scale.

So, what should DevRel focus on after building awareness?

Product Activation, Not Just Mindshare

I've seen many companies bring on DevRel teams with only a vague mission like "raise awareness," "engage the community," or "improve developer experience," and then just hope things work out. Usually, this leads to unclear metrics, scattered efforts, and no obvious return on investment.

The confusion often comes from a simple mistake: awareness isn't the same as activation.

You can reach 50,000 developers with your product. If 49,000 of them bounce at onboarding, your awareness strategy has failed. Activation, where developers get past the first friction point into real usage, is the JOB.

When users adopt products on their own, there's no sales team or account executive to guide them. The product has to lead users through the journey, and DevRel's job is to make that journey as smooth and appealing as possible.

The PLG Reality: Friction Everywhere

Before we talk solutions, let's be honest about the problem. Product-led growth works because it eliminates sales friction. But it introduces a new kind: product friction.

Every obstacle between "I heard about this product" and "I shipped code with this product" is killing your activation rate. The difference between a 40% onboarding completion rate and a 65% one isn't better marketing. It's removing friction faster.

This is where Community-Led Growth (CLG) earns its seat at the table. Not because developers like talking to other developers (though they do), but because DevRel can spot friction everywhere: in docs, in SDK design, in error messages, in the time-to-first-value metric.

The companies winning at PLG aren't winning on awareness. They're winning on friction removal.

So the real question is: how do you tackle friction at every step?

The Activation Framework: The 6 Things That Actually Matter

The goal is to stop juggling random initiatives. If we want to focus, here are the six key areas what I feel can be used to channel the energy in:

Start with Onboarding, and Make It Frictionless

Onboarding is where most products fail their developers.

Onboarding isn't just a 30-minute tutorial or a welcome email. It's the whole journey from discovering your product to successfully shipping an integration or deploying a service. Every step along the way is a chance for users to drop off.

What to measure:

• Time to first successful API call
• Time to first deployed/production integration
• Percentage of signups completing each milestone
• Where developers get stuck (find the "death valley")

What DevRel does:

• Audit your onboarding for friction. Actually do it yourself. No assumptions.
• Create onboarding content that's outcome-focused, not feature-focused. ("Deploy a microservice," not "learn our CLI flags.")
• Build interactive quickstarts that developers can fork and use immediately. In my experience, platforms like Killercoda and Instruct are great for helping users see value quickly.
• Document the 80/20: what do 80% of developers actually do? Make that path frictionless.

The goal: reduce time-to-first-working-example from days to hours. Every hour you shave off compounds across your entire user base.

Pro tip: If your onboarding tutorial takes longer than 15 minutes to produce a working result, you've already lost a meaningful chunk of your developers. Eg: At vCluster, we launched a cloud and vind, which helps devs realize value before even having a control plane cluster. Devs get benefited faster without waiting for provisioning loops of control plane cluster and understand how awesome the product is.

Create Use Cases: Production, Testing, Sandbox, and Community

Onboarding gets developers to "hello world." Use cases get them to "This is actually useful for my job."

A use case is a real-world application of your product. Not a feature. Not a tutorial. It's a job a developer is trying to do, and how your product helps them do it better.

Many companies make the mistake of creating their own use cases and stopping there. That's not enough. You need to cover different environments:

Production Use Cases (highest trust, highest risk)

• Real-world, revenue-generating applications
• What enterprises do with your product
• Requires bulletproof documentation and support

Testing Use Cases (learning and experimentation)

• How developers trial your product safely
• Staging/pre-production scenarios
• Encourages experimentation without downside

Sandbox/Personal Use Cases (lowest barrier to entry)

• Hobby projects, side hustles, education
• Free tier optimized for this use case
• Creates a pipeline to production

Community Use Cases (viral, self-propagating)

• What developers build with your product
• Open source examples, integrations, templates
• Showcase community creativity; incentivize contributions

Why this matters: A developer might use your product in a sandbox for personal projects, then evangelize it internally when they hit a production problem. You need on-ramps at every level which they can relate to and then usher their creativity.

What DevRel does:

• Research and document each use case with 2 to 3 detailed examples
• Create runnable code for every use case (GitHub repos, templates, boilerplates)
• Identify gaps between what developers want to build and what your docs make easy
• Partner with customers to turn their implementations into public case studies

Multi-Product Attachment at Scale

Single-product attachment is a vulnerability. Companies that own multiple products or integrations win because they increase switching costs and create network effects.

"Multi-product attachment" means: once a developer adopts Product A, how many also start using Product B? How quickly? How successfully?

This is where PLG really compounds. A developer using your authentication service might never touch your database product... unless you've designed the journey. And DevRel owns that journey.

What to measure:

• Adoption rate of Product B among Product A users
• Time from first Product A integration to first Product B integration
• Retention lift from multi-product users (they stay longer)
• Revenue per user (goes up with attachment)

What DevRel does:

• Document integration patterns that require multiple products (make the happy path obvious)
• Create "next-step" content: "You've built with Product A, here's what Product B unlocks."
• Build combined examples that showcase synergy (not individual products in isolation)
• Identify power users who've discovered multi-product patterns and amplify their stories

Real-world impact: Companies like Stripe, AWS, and Twilio grew partly because developers bumped into their second and third products naturally. That wasn't an accident. It was intentional product and community design.

Value Realization Through Product Stacking

A key strategy is to demonstrate how our products work together to deliver enhanced value. This is achieved by combining features and products (Product Stacking) to create comprehensive solutions. For example, a developer using vCluster for tenant isolation can combine it with vNode for runtime isolation and use vCluster Standalone for cluster creation. This is just one illustration of how stacking our products provides greater utility.

The core goal is to emphasize this layered value proposition, starting with feature combinations (Feature Stacking — At Harness, we did this with CD) and progressing to full product stacking.

Continuous (Content) Delivery for Release Based Adoption

Release cycles create attention and opportunity. But most companies waste them.

Every release should include:

• Runnable examples updated for the new version
• Migration guides for existing users
• Use case updates if the release changes what's now possible
• Community showcases from early adopters (beta testers)
• DevRel "office hours" where developers can ask about new features live

The point is that releases are not just feature drops. They are opportunities to re-engage your community and accelerate adoption.

From my experience, structured content blocks are extremely effective. When a feature release is supported by coordinated content such as live streams, talks, and use case blogs, it drives both adoption and awareness. Not just for the release itself, but for what comes next.

This approach helps developers understand, implement, and get more value from the product.

WIP: I am working on a detailed checklist for release cycle content. After spending time diving into product marketing, I plan to share what works best.

What to measure:

• Activation rate post-release (% of users who try the new feature)
• Adoption velocity (days from release to meaningful use)
• Upgrade rate (% of existing users moving to the new version)
• Community content created because of the release ( Ideal Candidate for your Future Ambassador Programs )

What DevRel does:

• Own the narrative pre-release (what problems does this solve?)
• Prepare runnable code/environment before the release launches
• Coordinate with beta users to produce community content
• Create release-specific onboarding ("New to us? Start here with v2.0.")
• Monitor for confusion or friction in how developers use the new version

Why this works: Releases create natural pauses where developers re-evaluate whether your product is still the best fit. If you guide them through that re-evaluation with fresh use cases and clear next steps, adoption jumps.

Operation at Scale

Early adoption happens in small projects. Real adoption happens when teams trust your product at scale.

The core question shifts from "Does this work?" to "Will this hold up when it matters?"

If you don't answer that clearly, developers won't push your product into production.

What This Means

Operating at scale is not about claims. It's about proof:

• How your product performs under real load
• How teams run and maintain it in production
• What breaks, and how to recover
• What "good" looks like at scale

You're selling confidence, not features.

What to Measure

• Largest real deployments (clusters, traffic, users)
• Performance under load (latency, failure rates)
• Operational effort (setup, maintenance, debugging)
• Recovery time from failures
• Enterprise usage patterns

What DevRel Helps With

1. Turn scale into real content

Show, don't tell.

• "How we run 10,000 clusters"
• "What breaks at scale and how we fixed it"
• "Handling 1M requests per minute"

Honesty builds trust more than perfection.

2. Create operational playbooks

Developers need to run systems, not just build them.

• Monitoring and observability setups
• Failure and recovery guides
• Scaling strategies
• Cost optimization

Content like this helps keep users around for the long term.

3. Share real architectures/reference guides/experiments

Abstract diagrams are not enough. Provide:

• Reference architectures
• Infrastructure templates (Terraform, Helm)
• CI/CD patterns
• Multi-region setups

Make it reproducible. Eg: Scaling Kubernetes Without the Pain of etcd Sharding

4. Highlight customer stories

Proof from peers reduces risk.

• Real scaling journeys
• Migration stories
• Tradeoffs and outcomes

Address business concerns

At scale, the audience changes. You need to answer:

• Is this reliable?
• Is this cost-efficient?
• Can my team operate this easily?

When developers can say "This won't break when we grow," adoption inside companies accelerates.

That's where PLG turns into real revenue.

Worth noting: most of this work for 4&5 falls under Product Marketing. But DevRel can absolutely help by contributing and experimenting here by sharing it with the collective audience.

Nurturing the Community

Community is still a critical lever, but its role is often misunderstood in a PLG motion.

There's a lot of real, hands-on work here:

• Running and moderating Slack/Discord communities
• Hosting office hours where developers can get unblocked live, plus newsletters
• Organizing online events, technical talks, and webinars
• Running hackathons and challenges
• Supporting meetups and grassroots developer groups

These activities are extremely valuable for awareness, trust-building, and early engagement. In some cases, they can even outperform traditional marketing because they create direct, authentic developer interaction.

However, this is where many teams make a mistake.

They over-invest in community activity before fixing activation and adoption.

Community can bring developers in. But if onboarding is broken, use cases are unclear, or the product has friction, those developers won't stay. You end up scaling awareness without scaling value.

The priority should be:

• Ensure strong activation and product experience
• Build clear use cases and adoption paths
• Then amplify through the community ( NOTE: The other five areas are important, but awareness here matters just as much. I strongly advocate giving this equal focus alongside them at start )
• Get Feedback to the Product Team

When you do it in the right order, community becomes a force multiplier, not a leaky funnel.

With strong adoption underneath, community evolves into something much more powerful:

• Contributors and champions emerge
• Developers start helping each other
• Content becomes self-sustaining
• Your ecosystem grows without linear effort

That's when DevRel shifts from supporting growth to driving it.

A strong DevRel function doesn't just engage developers. It builds systems where developers succeed, contribute, and compound value over time.

Final Thoughts

If you already have a DevRel function, this framework might feel like a reorg. That's okay. DevRel activation isn't a campaign. It's a practice. Start with onboarding. Fix the most obvious friction point. Measure the lift. Then move to use cases. Then multi-product. Then continuous delivery of content with every release cycle.

While delivery is improving, make sure to focus on users who are contributing and becoming ambassadors (blog on this coming soon). Nurturing them matters because most sales-led products forget one thing: community is your moat.

Note: Community activation is still an important part of the function. When I say "focus on after awareness," I don't mean forget the awareness part, but focus on the post-awareness part. If you don't have awareness, for whom will you do the activities?

Keep the awareness circle running. Just don't stop there.