How to Build an Effective Developer Advocacy Strategy (Part 1)

You just joined a company as a developer advocate. You spend the next six months writing blog posts, speaking at conferences, running a Discord community, and creating technical content.

Activity is happening. You feel productive.

Then, six months later, leadership asks a simple question:

“What business impact did all of that create?”

You hesitate.

You mention that developers loved your content. Your conference talk was well attended. One of your videos was shared hundreds of times.

Meanwhile, the Sales team can point to pipeline numbers that directly contributed to revenue. Marketing can point to qualified leads. But you struggle to point to anything that clearly demonstrates the impact of your work in a way that connects to the bottom line.

This pattern is one of the reasons DevRel has, for so long, been viewed by outsiders as a feel-good department. The work is valuable, but nobody can clearly point to the business impact of that work. And when budgets become tight or layoffs come around, DevRel is often one of the first functions whose value gets questioned.

One of the biggest reasons this happens is that we do much of our work based on assumptions. We jump straight into producing content, speaking at conferences, building communities, and running programs without taking the time to gain enough context to help us answer two important questions: What initiatives should we prioritize, and why are those initiatives the best way to support the business?

It is only when you take the time to understand that context that you gain clarity and direction, spend less time on low-impact activities, and begin to clearly explain how your work supports business outcomes. You also collaborate more effectively across the company because you’re solving the same problems everyone else is trying to solve.

So where do you start?

That’s why I started this series, How to Build an Effective Developer Advocacy Strategy.

As I explained in the introductory article to this series, building an effective developer advocacy strategy starts with understanding your company. You need to be able to answer three questions:

• Where does your company sit in the market?
• What stage of maturity is your company in?
• How does your company make money?

This article focuses on answering the first question.

Companies don’t walk around wearing labels that say, “This is our market position.” So this article will show you what to look for and how to identify the position the company you work at occupies in the market.

Understanding this will help you uncover how your company is positioned relative to the businesses it competes with. That context will help you define the messaging and positioning of the developer advocacy initiatives you prioritize.

Most products fall into one of four distinct categories, and each one requires a completely different approach to developer advocacy. Here is what each one looks like.

Market Leader

A market leader is a company that already dominates its category. It has the largest market share, the strongest brand recognition, and is often the company customers compare every other product against. Rather than trying to convince people that the category matters, market leaders are usually trying to convince them that their product is the best choice within that category.

Think of companies like GitHub in code hosting, Stripe in developer payments, Twilio in communications APIs, or AWS in cloud computing. When most developers think about these categories, these are often the first companies that come to mind.

You don’t need access to your company’s board meetings to identify a market leader. There are usually plenty of signals. Customers frequently compare competitors against your product rather than the other way around. The company has significant market share and strong brand recognition. Industry analysts and media regularly reference it as the default choice in its category. Competitors position themselves as alternatives to your product, and your product is widely adopted by both startups and large enterprises.

Market leaders want to defend their turf while continuing to expand their market. Your messaging is less about convincing developers that your category matters and more about helping them get the most value from your platform. Instead of asking, “Why should developers care about this problem?” you’re often answering, “How can developers be more successful using our product?”

Imagine you join Datadog as a developer advocate. Spending your first six months writing introductory content about why observability matters is unlikely to create much business impact. Most developers evaluating Datadog already understand why the category is important.

For market leaders, developer advocacy initiatives will often be weighted toward the Activation and Retention stages of the AAARRRP funnel. The goal is usually less about introducing developers to the company and more about helping them become successful, long-term users of the product.

Based on that, your DevRel actions should likely focus on maintenance, optimization, and ecosystem growth.

• Create advanced technical content that helps users adopt new features.
• Write advanced guides covering scaling architectures, performance optimization, and edge cases.
• Build comprehensive tutorials showing how your product integrates with newer and emerging frameworks.
• Write migration guides that reduce friction and help existing customers extract more value from the platform.
• Your documentation is likely massive and bloated. Making sure developers aren’t drowning in legacy APIs, outdated examples, and old versions of the documentation by curating and making everything easily searchable.
• Prioritize backward compatibility and publish meticulous upgrade guides whenever older APIs or features are deprecated.
• Launch champion or ambassador programs that recognize your power users, giving them early access to betas, exclusive opportunities, and community recognition.

Market Challenger

A market challenger is a company that has established itself in the market but isn’t the dominant player. It has a strong product, a growing customer base, and enough credibility to compete seriously, but it’s still trying to convince customers to choose it over the market leader.

Think of companies like Linear competing with Jira, PostHog competing with Mixpanel, or Neon challenging traditional PostgreSQL providers. These companies aren’t trying to convince developers that the category matters. They’re trying to convince them there’s a better way.

You don’t need access to your company’s strategy documents to identify a market challenger. There are usually plenty of signals. The company frequently compares itself to the market leader. Its messaging emphasizes why it’s faster, easier, cheaper, more developer-friendly, or more innovative than existing alternatives. You’ll often hear phrases like “the modern alternative” or “built for today’s developers.”

Market challengers want to win market share. There’s no need to explain why the category matters. The pain point is already well understood and acknowledged. The focus is on convincing developers to switch from the incumbent by demonstrating why your approach is better and who it’s better for.

To do that effectively, your content strategy should expose the gaps left by the market leader. Maybe their product is expensive. Maybe onboarding is painful. Maybe the documentation is difficult to navigate. Maybe customer support is slow. Whatever those weaknesses are, your job is to educate developers on how your approach solves those problems better, faster, or more efficiently.

For market challengers, developer advocacy initiatives will often be weighted toward the Awareness, Acquisition, and Activation stages of the AAARRRP funnel.

Based on that, your DevRel actions should likely include:

• Building frictionless migration scripts, CLI tools, and SDKs that make it easy for developers to move away from the incumbent.
• Writing objective “X vs. Y” comparison guides that acknowledge your product’s limitations while clearly highlighting its strengths.
• Creating migration guides and technical breakdowns that show developers exactly how to switch from competing products.
• Making your documentation objectively better than the market leader’s. If the leader’s documentation lacks code snippets for Next.js, yours should have polished, copy-pasteable examples for every major framework your audience uses.
• Creating educational content that demonstrates how your approach solves developers’ problems better or faster.
• Emphasizing differentiators that matter most to your audience, whether that’s self-hosting capabilities, data ownership, pricing, performance, or a community-driven roadmap.

Niche Player

A niche player is a company that intentionally serves a specific segment of the market rather than trying to compete for everyone. Instead of building the broadest product with the most features, niche players focus on solving a particular problem exceptionally well for a clearly defined audience.

Think of companies like PlanetScale (before expanding beyond MySQL), Clerk in authentication, Resend in transactional email for developers, or Temporal in durable execution. These companies aren’t trying to become the default choice for every developer. They’re trying to become the obvious choice for a specific type of developer or use case.

One of the easiest ways to recognize a niche player is by looking at who they don’t build for. Their messaging isn’t designed to resonate with every developer. Instead, it speaks directly to a specific industry, technology stack, workflow, or developer persona. If someone outside that audience doesn’t immediately see the value, that’s perfectly okay. That’s often a sign the company has a clear understanding of its market.

Niche players want to dominate a specific corner of the market. Success doesn’t come from attracting the largest audience. It comes from becoming indispensable to a smaller one.

For niche players, the challenge is capturing highly targeted Awareness and Acquisition within your specific layer of the ecosystem.

Rather than diluting your focus, your job is to become indispensable to the exact developers your company was built to serve. Speak exclusively to your sub-segment using the language they use every day. Create educational resources that generic competitors cannot match, whether that’s in-depth whitepapers, specialized workshops, or technical courses. Instead of building another generic React to-do application, build templates that reflect your audience’s actual workflows. If your audience builds real-time applications with Next.js and WebSockets, create a high-performance analytics dashboard they can use as a starting point.

Your product should also fit naturally into the ecosystem your audience already loves. Invest in framework-specific examples, high-quality integrations, IDE extensions, CI/CD actions, and modular SDKs that allow developers to customize behavior without fighting your abstractions.

Finally, don’t be afraid to tell developers when your product isn’t the right choice. Publishing a guide that explains when the market leader is the better option, and when your product is the better fit, builds far more trust than pretending your solution is right for everyone. For niche players, credibility is often a bigger competitive advantage than reach.

Shooting Star (Category Creator)

A shooting star is a company creating a new category or fundamentally changing how developers think about an existing problem. Rather than competing head-to-head with established players, these companies introduce a new way of solving a problem that many developers may not even realize they have.

Think of companies like Turso, which reimagined SQLite for the edge, or LangChain, which helped define how developers build applications powered by large language models. These companies aren’t simply building a better version of an existing product. They’re introducing a new way of thinking.

Unlike market leaders, challengers, or niche players, category creators have a different obstacle. They aren’t competing against another company. They’re competing against the status quo.

Developers are naturally skeptical of new paradigms. They’ll wonder whether your category is just another buzzword, whether the problem is real, or whether they could build the same thing themselves using the tools they already know.

For category creators, developer advocacy initiatives are heavily weighted toward Awareness. Before developers will evaluate your product, they first need to understand the problem you’re solving and why existing approaches fall short.

Your strategic focus shifts almost entirely from product education to conceptual education. Before developers can learn your API, they need to understand the new mental model you’re asking them to adopt.

You’ll likely find more success focused on doing things like:

• Teaching the concept before the syntax. If you’ve created a new type of database, don’t start with your API documentation. Explain why traditional databases struggle with this problem using diagrams, mental models, and familiar engineering concepts.
• Validating the category through customer stories. Showcase early adopters who achieved measurable improvements by embracing this new approach. Developers trust evidence from other developers far more than marketing claims.
• Developing a shared vocabulary. Categories become easier to adopt when developers have language to describe the problem and discuss potential solutions.
• Repeating the core message consistently across blog posts, conference talks, workshops, documentation, and videos. New ideas rarely click the first time developers hear them.

Turning Your Diagnosis Into a Plan

The uncomfortable truth about a DevRel career is that it never looks the same at two companies, and it should not. A market leader does not need the same strategy as a challenger, and a niche player should never behave like a shooting star. The work must change because the business context is different.

Market position	Example	The developer’s view	Where the funnel usually stalls	What your advocacy should focus on
Market Leader	Datadog	Already the default, trusted choice	Activation and the deep funnel: retention, revenue, referral	Advanced content, feature adoption, and migration guides that help existing users extract more value. Go deeper, not louder.
Challenger	New Relic	A credible, more modern alternative	Awareness and acquisition	Comparisons, clear differentiators, and migration guides that give developers a reason to switch.
Niche Player	Sentry	The specialist for one specific problem	Awareness and acquisition within the niche	Deep, insider technical content for a precise audience. Be indispensable, not everywhere.
Shooting Star	SigNoz	The fresh, underdog option	Top of funnel: awareness and product feedback	Seed early communities, generate awareness, gather feedback, and help shape the product. Get discovered, fast.

How each market position changes where the funnel tends to stall, and what your developer advocacy should focus on in response.

It is also important to keep in mind that this framework applies to individual products just as much as entire companies. A massive market leader might launch a brand-new product that enters the market as a challenger. In that scenario, your strategy should be shaped entirely by the market position of the specific product you are advocating for, rather than the parent company operating behind it.

However, understanding your market position is only the first step. It diagnoses the commercial challenge your company is trying to solve and points you toward the broad lifecycle outcomes that matter most, whether that’s driving Awareness, Activation, or Retention. It doesn’t tell you what the business is optimizing for right now.

Two companies can both be market challengers and require completely different developer advocacy strategies because they’re at different stages of growth. For example, two companies can both be challengers but one is an early-stage Series A startup trying to achieve product-market fit, and the other is a growth-stage company focused on scaling revenue or expanding into new markets. Their commercial objective is the same, but their immediate priorities are not.

In the next article in this series on how to build an effective DevRel strategy, we’ll look at what this means for you.