Every developer advocate eventually runs into the same problem.
There are twenty things you could be doing, but you only have time to do five.
Should you write tutorials, launch a community, improve onboarding, speak at conferences, start a newsletter, or build sample applications?
The hardest part of developer advocacy isn’t figuring out how to do the work. It’s deciding what deserves your attention first.
In the previous article, we looked at why understanding your company’s market position is the first step in building an effective developer advocacy strategy.
Your market position 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.
But knowing the business problem isn’t enough.
Imagine two companies. Both are market challengers competing against an established incumbent. Both need developers to choose them over a better-known alternative. On the surface, it might seem like they should have the same developer advocacy strategy.
Now imagine one of those companies is an early-stage Series A startup, while the other is a growth-stage Series D company.
The Series A company is still trying to achieve product-market fit. The business is optimizing for learning as quickly as possible. Developer advocacy therefore contributes by conducting customer interviews, creating lightweight tutorials, gathering product feedback, and experimenting with messaging that helps the company learn what resonates with developers.
The Series D company is solving a different problem. It has more resources, a larger customer base, and a clearer understanding of its market. The business is optimizing for repeatable growth and scale. Developer advocacy can therefore shift its attention toward repeatable onboarding, integration guides, enterprise enablement, and educational content that helps the company scale what it already knows works.
They’re both challengers. They’re both trying to convince developers to switch. But they won’t execute the same developer advocacy strategy because they’re at different stages of growth.
Remember the developer activities table we introduced in the intro article: your market position tells you which parts of the AAARRRP framework represent the most pressing challenge the business is optimizing for. But there are still many developer advocacy initiatives that fall under those stages. Your company’s growth stage helps you further prioritize which of those initiatives are most likely to create the most value today for the business and the developers it serves, given the resources available to the company.
This article will help you identify what stage of growth your company is in and understand how that should influence the developer advocacy initiatives you prioritize. Because when your work aligns with what the business is actually optimizing for, you’ll spend less time on low-impact activities and more time delivering work whose impact you can clearly explain when someone asks, “What did all of that achieve?”
The Three Growth Stages
Companies don’t just occupy different positions in the market. They also move through different stages of growth, and each stage comes with its own priorities, constraints, and definition of success.
As a developer advocate, your job is to align your work with what the business is optimizing for at that stage.
An early-stage startup that’s still trying to achieve product-market fit doesn’t need the same developer advocacy strategy as a mature company focused on defending its market position and expanding into new opportunities. They may be trying to solve the same commercial challenge, but the initiatives that create the most value today will look very different.
Broadly speaking, companies tend to move through three stages of growth:
- Early Stage – The business is optimizing for learning.
- Growth Stage – The business is optimizing for repeatability and scale.
- Mature Stage – The business is optimizing for defending and expanding.
Each stage changes which developer advocacy initiatives are likely to create the most value, even when companies are trying to solve the same commercial challenge.
Let’s look at each one.
Early Stage
Early-stage companies are still trying to answer some fundamental questions. Does the product solve a real problem? Who is it for? Why should developers choose it over the alternatives?
At this stage, the business is optimizing for learning. The goal isn’t to scale yet. It’s to reduce uncertainty by validating assumptions, achieving product-market fit, and understanding what resonates with developers.
That changes the role of developer advocacy.
Your job isn’t simply to educate developers about the product. It’s to help the business learn. Every conversation with a developer, every piece of feedback, and every experiment should help the company make better product and go-to-market decisions.
In the previous article, we established that your company’s market position helps you identify which stages of the AAARRRP customer lifecycle deserve the most attention. Your company’s growth stage now helps you determine which of the developer advocacy initiatives under those stages will create the most impact, given the state of your product and the resources available to the business. This is what saves you from making expensive mistakes.
Looking at Figure 1, imagine you’re working at an early-stage market challenger. From your market position analysis, you’ve already concluded that Awareness is one of the stages your company should prioritize. Looking at the initiatives mapped to that stage, you might notice that both event sponsorships and blog posts contribute to Awareness.
On paper, either looks like a reasonable choice.
But they’re not equally valuable.
Event sponsorship takes significant budget, months of planning, and usually pays off in brand exposure that’s difficult to measure. Blog posts and lightweight tutorials cost very little, can be published in days, and help you continuously test your messaging while learning what resonates with developers.
Both initiatives support Awareness. But because an early-stage company is optimizing for learning and often has limited budget, blog posts and lightweight tutorials are usually the better investment. They help the business validate assumptions, refine its messaging, and learn faster while making the most of limited resources.
Growth Stage
Growth-stage companies have already achieved product-market fit. They’ve validated that developers want the product and have a good understanding of who their customers are. The challenge is no longer proving the idea. It’s repeating that success at a much larger scale.
One of the clearest signs you’re working at a growth-stage company is that the conversations inside the business begin to change. Instead of asking, “Do developers want this?” people are asking, “How do we help more developers adopt it?” or “How do we make onboarding more consistent?” The focus shifts from learning to scaling.
That changes the role of developer advocacy.
Rather than validating assumptions, your job is to remove friction from the developer journey and build systems that help every developer succeed without requiring more manual effort from your team.
Imagine your market position analysis has already told you that Activation is one of the stages of the AAARRRP customer lifecycle your company should prioritize. Looking at Figure 1, you’ll notice that both office hours and documentation contribute to Activation.
On paper, either looks like a reasonable investment.
But they’re not equally valuable.
Office hours are an excellent way to help developers overcome blockers and experience success with your product. The challenge is that every new developer requires another conversation. If your documentation, quick-start guides, tutorials, or sample applications don’t yet exist or aren’t good enough, you’ll find yourself answering the same questions repeatedly.
Because a growth-stage company is optimizing for repeatability and scale, and because your team’s time is one of its most limited resources, it’s usually a better investment to first build self-service resources that help every developer succeed independently. Those resources continue creating value long after you’ve published them, allowing your team to reach thousands of developers instead of dozens.
That doesn’t mean office hours aren’t valuable. Quite the opposite. Once those foundational resources are in place, office hours become even more impactful because they can focus on edge cases, advanced implementations, and higher-value conversations rather than repeatedly covering the basics.
Mature Stage
Mature companies have already established themselves in the market. They have a sizeable customer base, repeatable ways of acquiring users, and a product that developers trust. They also tend to have larger budgets, bigger teams, and more specialized functions across marketing, sales, customer success, and developer relations.
The challenge is no longer finding product-market fit or scaling a proven motion. It’s sustaining growth in an increasingly competitive market while defending the position they’ve already earned.
One of the clearest signs you’re working at a mature company is that the conversations inside the business begin to change again. Instead of asking, “How do we grow?” people are asking, “How do we deepen adoption?”, “How do we retain existing customers?”, “How do we expand into new markets?”, or “How do we successfully launch new products?” The focus shifts from scaling to defending and expanding.
That changes the role of developer advocacy.
Your job is no longer just helping developers adopt the product. It’s helping existing customers become more successful, strengthening the ecosystem around the product, and creating leverage by enabling others to advocate on the company’s behalf.
Imagine your market position analysis has already told you that Referral is one of the stages of the AAARRRP customer lifecycle your company should prioritize. Looking at Figure 1, you’ll notice that both conference talks and ambassador programs can contribute to Referral.
On paper, either looks like a reasonable investment.
But they’re not equally valuable.
Conference talks are an excellent way to reach new developers and build credibility. However, every talk requires another CFP, another presentation, another trip, and another member of your DevRel team on stage.
An ambassador or champion program works differently. Instead of relying solely on your DevRel team, it enables your most successful customers to become advocates for your product by speaking at conferences, writing blog posts, answering questions in the community, creating tutorials, and recommending your product within their own organizations.
Because mature companies have larger customer bases, more resources, and dedicated teams to support these programs, they’re in a much stronger position to invest in initiatives that create leverage. Rather than having a handful of developer advocates educating the community, they can empower hundreds of passionate customers to do the same.
That doesn’t mean conference talks stop being valuable. They absolutely remain an important part of a mature developer advocacy strategy. But once you have the resources and community to support them, ambassador programs often become a higher-leverage investment because they amplify your impact far beyond what your internal team could achieve on its own.
Turning Your Diagnosis Into a Plan
Understanding your company’s growth stage changes how you think about developer advocacy.
It’s easy to look at a list of developer advocacy initiatives and assume they’re all equally valuable. They’re not. The value of an initiative depends on what the business is optimizing for at that point in its growth journey.
An early-stage company optimizes for learning. A growth-stage company optimizes for repeatability and scale. A mature company optimizes for defending and expanding. Those priorities should shape which developer advocacy initiatives you invest in, even when they’re all contributing to the same stage of the developer journey.
A customer interview might be one of the highest-impact things you can do at an early-stage startup that’s still learning about its users. The same activity might be far less valuable for a mature company that’s focused on helping thousands of existing customers adopt a new product. Likewise, investing months into polished onboarding content might transform adoption at a growth-stage company, while an early-stage startup would benefit more from learning why developers aren’t getting that far in the first place.
But there’s still one more piece of the puzzle.
Two companies can share the same market position and the same growth stage, yet still require completely different developer advocacy strategies because they make money in different ways.
A company selling an open-source product with paid enterprise support won’t measure success the same way as a company selling usage-based APIs or enterprise software. Those differences influence what the business ultimately considers valuable, which metrics matter, and where developer advocacy should invest its time.
We’ll explore that in the next article in this How to Build an Effective Developer Advocacy Strategy series.
Because at the end of the day, your job isn’t simply to help developers succeed with your product. It’s to help developers succeed in ways that also help your company succeed.