This article is the first in a series on building an effective developer advocacy strategy.

As a developer advocate, you’ll quickly discover that there’s no shortage of things you could do.

You could overhaul your documentation, write blog posts, speak at conferences, host webinars, build sample applications, run office hours, launch an ambassador program, engage online communities, organize meetups, collect product feedback, build AI agents, create MCP servers, and more. All of these are legitimate developer advocacy initiatives and, in the right context, any one of them could create tremendous value.

The problem is that you have limited people, limited budget, and limited time to prove the value developer advocacy contributes to the business. You can’t do everything.

Every quarter, every year, you have to get really clear on what deserves your attention.

What deserves your attention are the initiatives that help move developers through the stage of the AAARRRP framework your company or product needs to focus on.

Table mapping common developer advocacy initiatives to AAARRRP funnel stages, with a developer-journey band on top mapping Discover to Awareness, Evaluate to Acquisition, Learn to Activation, Build to Retention, Refer to Referral, and Scale to Revenue and Product: docs and how-tos serve acquisition and activation; library development and quick-start apps serve activation and product feedback; blog posts, tutorials, and webinars span awareness through retention; event sponsorship and conference talks serve awareness and acquisition; support forums serve activation, retention, and product feedback; pre-sales discussions serve acquisition and activation; alpha and beta programs and office hours serve activation and retention; capturing developer feedback serves product; recruitment help serves acquisition; ambassador programs serve referral.
Figure 1. The AAARRRP framework, which is Phil Leggetter's adaptation of the popular AARRR framework, breaks down the developer journey into distinctive stages that drive sustainable business growth: Awareness, Acquisition, Activation, Retention, Revenue, Referral, and Product, to help businesses that target developers better understand, measure, and optimize their customer journey. View full size →

Your thinking needs to shift from:

“What can I do as a developer advocate?”

to:

“Given my company’s current reality, which developer problems should I solve that will create the greatest business value?”

And how do you uncover that answer?

Through strategic analysis.

Before you decide what to build, write, or launch, you first need to gain a comprehensive understanding of the business you’re trying to help. To do that, you need to analyze three areas:

  • The company
  • The product and its users
  • The team

Each area answers a different strategic question.

  • The company: What business outcomes matter?
  • The product and its users: Which developer problems, if solved, will help achieve those business outcomes?
  • The team: Who is already working toward those outcomes, and where can Developer Relations contribute or collaborate without duplicating effort?

Together, these three areas progressively narrow the range of developer advocacy initiatives worth considering until you’re left with a much smaller set of strategically viable options.

Area of Analysis 1: Understand the Company

The first step is understanding the company itself.

Ask questions such as:

Getting the answers to these questions tells you what business outcomes the company is trying to achieve and, therefore, what Developer Relations is expected to contribute.

More importantly, it helps you identify which stage of the AAARRRP framework deserves the most attention given your company’s current reality.

Once you’ve identified that stage (or stages), you can focus on the developer advocacy initiatives that support it and temporarily eliminate initiatives that primarily support other stages of the AAARRRP framework.

Market Position

Market Position refers to a company’s or product’s standing relative to others in its market. Usually, companies or products are in one of four market positions: Market Leader, Challenger, Niche Player, or Shooting Star. Their specific position determines how they compete, the strategic priorities they focus on, and the business challenges they need to overcome.

For example, a challenger entering a crowded market is solving a very different business problem from a market leader defending its position. The challenger, who is a new entrant, is likely more concerned with building awareness, differentiating itself from competitors, earning developer trust, and convincing customers to switch. The market leader, on the other hand, is likely more concerned with defending its market position, deepening product adoption, retaining customers, and maintaining its competitive advantage.

Understanding your company’s market position helps developer advocacy figure out how to contribute to those priorities.

Growth Stage

Growth Stage refers to where a company is in its business journey. Companies are typically in one of three stages: Early Stage, Growth Stage, or Mature Stage. Their growth stage determines what the business is focused on achieving at that point in time.

For example, an early-stage company is likely more concerned with creating awareness, acquiring its first users, and finding product-market fit. A growth-stage company is likely more concerned with improving activation, increasing adoption, and retaining users. A mature company is likely more concerned with customer expansion, loyalty, and gathering product feedback to strengthen existing relationships.

Understanding your company’s growth stage helps developer advocacy understand which part of the developer journey deserves the most attention right now.

Monetization Strategy

A company’s Monetization Strategy describes how it captures value from the products or services it offers. In this series, we’ll look at four common monetization strategies: Revenue Upfront, Delayed Revenue, Market Enhancement, and Ecosystem Play. Each strategy influences what the business ultimately considers valuable.

For example, a company with a revenue upfront strategy is likely more focused on helping prospective customers recognize value before they make a purchasing decision. A company with a delayed revenue strategy, on the other hand, is likely more focused on driving product adoption and long-term engagement because value is captured after customers begin using the product. Likewise, companies pursuing a market enhancement strategy or an ecosystem play are likely to measure success differently because they create value in different ways.

Understanding your company’s monetization strategy helps developer advocacy understand the outcomes the business ultimately wants to drive.

After analyzing your company’s market position, growth stage, and monetization strategy, you should have a much clearer understanding of what business outcomes deserve the most attention and, therefore, which stage of the AAARRRP framework you should focus on.

For example, you might conclude:

“Given our company’s current reality, we should probably be looking at initiatives that support Awareness and Acquisition because those stages are likely to create the most business value right now.”

At this point, you still haven’t decided exactly what you’re going to do.

You’ve simply narrowed your focus from every possible developer advocacy initiative in Figure 1 to the subset of initiatives that are most likely to contribute to those business outcomes.

The next question becomes:

Which developer problems, if solved, will help achieve those business outcomes?

Area of Analysis 2: Understand the Product and Its Users

Once you’ve identified the business outcomes that matter most, the next step is understanding the product and the developers it serves.

The goal isn’t to decide which activities to execute. It’s to identify which developer problems, if solved, will help achieve those business outcomes.

Ask questions such as:

  • What kind of product is this?
  • How do developers discover, evaluate, and adopt it?
  • Who buys the product?
  • Who uses the product?
  • What motivates each of them?
  • Where do they experience friction throughout their journey?

While analyzing the company tells you what business outcomes matter, analyzing the product and its users tells you which developer problems are preventing those outcomes from happening.

For example, imagine two companies that have reached exactly the same conclusion.

Both are challengers in the growth stage. Both have identified Activation and Retention as the stages most likely to create the greatest business value.

From the company analysis alone, both companies would prioritize developer advocacy initiatives that support Activation and Retention.

However, one company sells an open-source CLI that developers can install and start using in minutes. The other sells an enterprise identity platform that requires procurement, security reviews, and implementation across multiple teams.

Although both companies are trying to improve the same stages of the developer journey, the problems their developers face are completely different.

Developers adopting the open-source CLI may struggle to discover key features, integrate the tool into existing workflows, or understand advanced use cases. Developers evaluating the enterprise identity platform may struggle with architecture decisions, implementation complexity, security requirements, or organizational approval processes.

Those differences fundamentally change what Developer Relations should prioritize.

The open-source CLI might benefit from quick-start guides, tutorials, sample applications, AI agents, and community support that help developers experience value as quickly as possible.

The enterprise identity platform might benefit from architecture guides, implementation workshops, security documentation, and reference architectures that support a much longer evaluation and implementation journey.

The business outcomes haven’t changed.

Only the developer problems have.

Understanding those problems is what determines how Developer Relations should contribute.

Area of Analysis 3: Understand the Team

Once you’ve identified the business outcomes that matter and the developer problems worth solving, the final step is understanding the rest of the organization.

Developer advocacy rarely operates in isolation. Product, Marketing, Sales, Customer Success, Solutions Engineering, Documentation, and other teams are often working toward the same business outcomes from different angles.

The goal is to understand who is already working toward those outcomes and where Developer Relations can contribute or collaborate without duplicating effort.

Ask questions such as:

  • What is Product focused on?
  • What is Marketing focused on?
  • What is Sales focused on?
  • What is Customer Success focused on?
  • What initiatives are already underway?
  • Where can Developer Relations create the most value?

Understanding the team helps you identify opportunities to amplify work that’s already happening instead of creating parallel initiatives.

For example, imagine you’ve identified developer onboarding as one of the biggest problems preventing developers from reaching Activation.

You then discover that:

  • Product is rebuilding the onboarding experience.
  • Marketing is creating onboarding campaigns.
  • Customer Success is improving onboarding for enterprise customers.

Rather than launching an entirely separate onboarding initiative, Developer Relations can contribute by creating technical tutorials, sample applications, developer workshops, and feedback loops that strengthen the work already underway.

The developer problem hasn’t changed.

What changes is how Developer Relations contributes to solving it.

By understanding the rest of the organization, you stop asking:

“What should DevRel do?”

and start asking:

“How can DevRel make the company’s existing efforts even more successful?”

Bringing Everything Together

By the time you’ve analyzed the company, the product and its users, and the team, you’ve transformed an overwhelming list of possible developer advocacy initiatives into a much smaller set of strategically viable options.

The company tells you what business outcomes matter and, therefore, which stages of the developer journey deserve the most attention.

The product and its users tell you which developer problems, if solved, will help achieve those business outcomes.

The team tells you who is already working toward those outcomes and where Developer Relations can contribute or collaborate without duplicating effort.

Together, these three areas provide the commercial context needed to build an effective developer advocacy strategy.

The six dimensions of a company's commercial context: market position, growth stage, business model, product and landscape, buyers and implementers, and internal teams, radiating from a central commercial context hub
Together, the three areas of analysis cover the six dimensions of commercial context that shape an effective developer advocacy strategy. View full size →

Only then are you ready to decide what to prioritize for the quarter or year, how you’ll measure success, and how Developer Relations will contribute meaningful business value.

In the rest of this series, we’ll dive deeper into each area of analysis, starting with understanding your company’s market position, growth stage, and monetization strategy, and how each one influences the business outcomes Developer Relations should be working toward.