Discovery can be the trickiest part of strategizing a DevRel campaign. The number of activities & deliverables that a DevRel team can work on can be infinite. During the discovery phase, we're going to break down how to ideate campaigns and narrow down which efforts will drive the biggest impact.
Before you dive in, be sure to read What is a DevRel Campaign?
Why build a DevRel campaign?
Before we dive into the fun part of discovery (ideation), let's discuss the why of your DevRel campaign.
Your developer relations program should have a program strategy and associated program goals. Your campaigns should always align with both your company goals, specifically for that quarter or time frame, as well as your program goals. Any campaign ideas that do not align with these goals, should be put in your backlog for when they do align.
If you do not have program goals defined yet, I encourage you to do so before trying to deliver on a campaign. Without goals, you're throwing darts at a wall. With goals, you're throwing darts at a dartboard. When you bring your company goals and your program goals together, you're throwing darts at the bullseye. This is how you drive impact for your company and obtain stakeholder buy-in.
We're going to define an example that we're going to leverage as you work through this Learn program.
If you’re ready to get started right away, I’ve created a DevRel Campaign Strategy Template you can access and use to step through laying out a successful campaign.
Unlock access to Tessa’s DevRel campaign strategy template
Creating goals for your DevRel program
Example goals for a developer-first company
Company Goals
- Objective: Drive awareness of our product within the developer ecosystem.
- Key result: Drive awareness towards 5k unique developers.
DevRel Program Goals
- Objective: Drive awareness of our product within the DevOps ecosystem.
- Key result: Drive awareness towards 3k unique DevOps practitioners.
Campaign Goals
- Objective: Drive awareness of our product within the DevOps ecosystem.
- Key result: Drive awareness towards 200 unique DevOps practitioners.
At developer-first companies, your program goals will likely align very closely with your company goals. At developer-plus companies, this may not be as clear and you may need to do more research and stakeholder interviews to define how your program can drive impact towards the company goals.
Take notice of the fact that the program has a goal to contribute to 3k of the 5k the company has defined as their company goal—your program shouldn't be responsible for meeting the company goal on its own. Other functional departments should be contributing too. DevRel alone can not carry a company forward, not usually anyway, nor is it healthy or reasonable to expect that.
You should also notice that the company cares about any developers, while the program has identified that DevOps practitioners are likely a better audience to target. Your program should be sharing these insights with the company so next quarter, the goals become clearer to the rest of the company. If this is experimental, you can try your tactics for a quarter and report back your findings.
Now to break this down even further, especially if you're a new team or function, you need to start with baby steps. This is why I defined a campaign goal of only driving awareness to 200 DevOps practitioners. 200 seems like a drop in the bucket compared to the 3k goal, but it will be more attainable after you learn a few tactics that work. Starting with 200 gives you an easy goal to accomplish, yet keeps you laser-focused on making incremental traction.
Collect the facts
One of the key differences between an engineering contributor role vs. a developer advocate role is the need to be able to scope your deliverables and think outside the box. This can oftentimes be a difficult hurdle to get over if you haven't had the chance to identify and scope needs before.
Our goal is to drive awareness to 200 DevOps practitioners. What facts do you need to be able to define a campaign that will attract 200 DevOps practitioners to your product? Or in your case, what facts do you need to be able to define the Strategy Objective of your campaign based on your campaign goals?
Search for insights
There are a lot of resources out there that can help you more specifically with your needs. Your goal isn't likely going to be the same as the example we set, however, by defining those goals, you now have a better understanding of what you're trying to accomplish. Search the internet, communities, social media, and other mediums to find insights.
Helpful insights may include
- Where does your target audience spend time online?
- What communities, resources, meetups, events, etc. exist for them?
- What do they care about?
- What pain points do they have?
- What products do they love? Why?
- Does anything make them unique from other developers?
Learn as much as you can about how they think and engage. Put yourself in their shoes. Take lots of notes—with each campaign, you will need to do less and less of this because you will begin to have a strong understanding of your audience and can leverage these notes to define your Audience Personas in your program strategy—if you don't already have one.
Interview stakeholders
Now that you've done your research, you should begin interviewing stakeholders for your campaign.
Stakeholders usually include your manager, your executive leader, and other folks who share similar goals and needs as you do. For our example goals, I captured the CEO & the CMO because we're driving awareness with our campaign. If your campaign was focused on product improvement or customer feedback, your stakeholders may include Product or Customer Success.
At early-stage startups, your stakeholders are likely the team leads, as the company grows, you should be aware of allies you can leverage on those teams instead. Every team is different, so it's up to you to begin to break down who would care about the impact of your work.
Leverage the knowledge you just captured to be a subject matter expert on the audience you are engaging with. Your stakeholders are looking to you to know and understand the needs of your audience. Wow them with the information and knowledge you captured.
Stakeholders hold a lot of important intel about what may be already in play at your company that relates to your campaign, as well as insights into what your board of directors is expecting, and what the executive team thinks you're capable of. When working with stakeholders, have your notes ready, prepare your questions ahead of time, and leverage your time wisely. Most stakeholders are leaders and they're usually tight for time so you want to use it effectively.
As you're engaging with stakeholders and doing your research, keep these two key questions in mind:
- Problem statement: What is the problem this campaign is going to solve?
- Solution hypothesis: What deliverables or results can solve the problem statement?
Begin brainstorming
As I shared above, the amount of possible deliverables a DevRel team can create is truly infinite. There are so many different angles and ways to approach your campaign goals. Because of this, many Developer Advocates struggle to do the right work. Let’s break down how to brainstorm and identify the most impactful work for your campaign.
In the Collect the Facts section we pulled together a lot of research both from external sources and internal stakeholders. It’s time to put that research to work!
During the research, I pulled together a number of DevOps practitioners' channels—channels being places where an audience exists. You can take a peek at the channels I pulled together in the Airtable base or in this quick view.
You can get started with any form of research, but for me, channels get my idea juices flowing and it helps me break down ideas based on channel opportunities. Another great way is to make a list of current pain points or problems they face and identify ways you can solve their problems.
Doing a quick Google search, I found a great article that outlined 30 DevOps pain points. Obviously, don’t believe everything you find on the internet, but as a developer advocate, it’s your job to do the research and validate your findings—does it align with the research you’ve captured thus far?
Effort vs. impact
The best way to prioritize ideas is to define the effort vs. the impact. If an idea is high effort and low impact, you might as well dump that one (or backlog it until it’s high impact). If an idea is low effort and high impact, do those first!
It seems like common sense, but as advocates, we get pulled into the excitement of ideas that seem fun and interesting and don’t realize that maybe that shiny new idea isn’t going to be all that impactful—even if it’s fun to build.
Prioritize your ideas
- Work through the ideas that you created and define the effort and the impact of each.
- If you’re leveraging your company's project management tool, create custom fields or labels for these items—you should start using this practice every time you consider a new idea.
- Backlog anything that is high effort. It’s the beginning of the quarter—hypothetically—so let’s start with easy, quick wins to validate that our assumptions on the target audience and our research is valid.
Don’t stress if you aren’t able to identify a lot of ideas yet. We’re going to come back to these ideas after we define the strategy section of our campaign.
Summary
We may have completed a few different areas in the campaign strategy, but the intent of Discovery was to help you capture the insights you need to sit down and knock out the rest of the strategy document. I’m not saying you won’t need to do additional research, but hopefully, you have enough intel to help you feel like you can at least search for the right things.
This article was originally posted on Devocate, which joined the Common Room family in August 2022. For more developer relations insights and resources, check out the Common Room blog. Learn more about Common Room’s solution for DevRel teams if you're looking for an intelligent community growth platform to educate, empower, and enable your community.
