We’ve put together our best practice approaches to get your developer content strategy off the ground.
1. Conduct industry analysis: Get to know your competition’s content
Conducting industry analysis can be a helpful first step to determine what other companies are doing and how successful their efforts have been. In turn, informing your own decisions on how best to position your own messaging. Remember that your content should be driving engagement and solving a problem, plus your strategy must be unique to your company, product or service.
It’s a good idea to conduct industry analysis periodically or every time that you launch a new product or feature. Here are our steps to get you started:
- Complete detailed research – Compile a list of your competitors and answer these key questions:
- What principles, benefits, and opportunities do my competitors claim in their content?
- Do my competitors target the same developers that I do?
- Are my competitors gaining clout and market share over us?
- Collect data and examine your competitors – Review how they are interacting with developers and how their content is impacting the developer community
- Analyze competitor data – Determine their strengths and weaknesses
- Evaluate your position – Are you building the right stories and covering the gaps to facilitate developers and for them to realize the value of building with your tools or services?
2. Review key considerations: Determine content topics and channels
You’ve checked out what your competitors are doing and what type of content they are publishing, now you need to work out what content topics will work for your own content strategy. A great place to begin is by finding out what questions are frequently being asked by your own developer community about your product or service. If the same questions keep popping up write a piece of content which addresses them.
Take a look on forums such as Stack Overflow, social media sites including Twitter, and on your developer portal forum. Once you’ve answered these key questions, put a note in the diary to keep reviewing these different channels and build a task into your content calendar. The next step to providing exemplary content is learning what your developer community gets stuck on and attempt to anticipate questions from developers before they ask – publishing your content before they post their question.
When you’re thinking about other types of content you can produce, you’ll want to ensure it will resonate with your developer community. Generally speaking, developers are task oriented and busy. You need to clearly assert the importance of your content and why it matters to them. Developer content typically falls into two categories, technical and non-technical. The former must be clear and technically accurate. This is your opportunity to help them get to building fast and in turn, increase the chances of adoption. Non-technical content should be interesting and relevant without fluff. Make sure you’ve clearly explained why this content is important and ensure it’s written with the mindset of ‘developer first’ – don’t churn out the same content you’re using for your B2B or B2C marketing. Ask yourself, what value does this piece of content give and is it addressing an issue or being informative? It’s imperative to convey the value of your content directly to your target audience.
How can you make sure that your messaging is raising the bar? There are a few Catchy top tips that you can follow to better position your content, grow its organic reach and encourage word-of-mouth:
- Use keywords that are relevant to the core message
- Leverage community influencers for content distribution
- Give developers a platform for feedback and reviews
- Join conversations about current and relevant industry topics
- Create innovation opportunities and rewards for participation
- Focus on what benefits developers, not your business
- Become a trusted resource for developers
It’s important to maintain a consistent structure across content pieces, with standardized layouts that appropriately represent your company. Your content should be in a variety of different formats, the most common being tutorials, blog posts, videos, introductory guides, use cases, product information, and reference documentation. Make it is easy for developers to find your content. If you make it challenging it will become a frustration for them and they might leave your developer program. The right location for your content is driven by what you hope to accomplish with it and the type of content itself, but it must be consistent and logical. For example, if a developer needs to find some reference documentation they are likely to look on your developer portal, so make sure it’s easy to find.
3. Learn from audience profiles: Understand who you are talking to
To continue constructing an effective content strategy, it’s critical to understand who your audience is. As you learned in Part 1 of this guide, there are many different types of developers. Begin by distinguishing between them and clearly define your developer personas. Personas are a useful tool for content marketing, as they will help you to deliver the right message. Without accurate personas, you may only be guessing what your developers want, which means you are more likely to craft content that is self-serving instead of information they actually want and need.
When you first start thinking about personas, you might be drawn towards demographic segmentation. Whilst this type of information is important, it’s only one small part of crafting your persona. The personas you create will focus on key market signals that your organization can use to refine its segmentation criteria, such as different areas of expertise, the developer stack and the school of thought this group subscribes to when building software. Going through this process will help you to identify unique challenges and opportunities which will help shape your content.
Start by envisioning which developer could benefit the most from what you have to offer. Define who they are by job title, what type of company they work for, their typical responsibilities, and what determines their own personal successes. These answers will serve as the foundation for a persona.
Example: Bob is a back-end developer who works for Microsoft on the Office 365 team. He’s responsible for server-side web application logic and integration of the work that front-end developers are doing. He is successful when workload benchmarks are achieved on schedule.
Consider their role in relation to your product, and what challenges they might be facing on a typical day of work. Think about any related details concerning their potential needs, influence on decisions, content preferences and consumption patterns. This information can help to identify the most valuable content topics, types, and channels that will move them closer to taking an action or making a decision. Once you’re finished documenting the persona, share it with your team, and utilize it the next time you start creating a new piece of content. Continue to map out new personas and decipher any shared or contrasting motivations, behaviors and preferences. Personas can further help you develop A/B testing, progressive profiling, and sentiment analysis to improve conversions over time.
Example: While Bob is not solely responsible for making purchasing decisions, he does have a significant influence on how funding is allocated. He enjoys trying out new tools and software frequently and makes recommendations based on what he thinks will boost productivity for his team.
Keep in mind that developer journeys are not linear. Developer audiences are very segmented, with subgroups based on a variety of categories. Because organizations and individual decision makers are so diverse, when considering the process of developer journeys, it’s important to look at the complete view. The personas that you’ve created will represent some of these audience segments. Developers come from all stages and can be programmers or engineers of any type, or even hobbyists and students.
- Web developer
- Frontend developer
- Enterprise developer
- System administrator
- Data scientist
The overarching point is to define, understand and target those you wish to engage, however you choose to segment and prioritize your audience be sure to build an understanding of their needs and address those needs in your actions. It’s also important to understand the prime motivating factors for most developer segments. The most common motivations are innovation, advancement, community, purpose, and mastery. Developers are passionate about technology and are always seeking to learn new thing and improve their skills.
4. Map out the editorial process: Get organized and productive
Now it’s time to rev up your content-focused marketing machine. Start by assigning someone to take the lead on your developer content. Allow this person to help create, manage and measure the components of your editorial plan. This will help your team stay organized, prioritize collateral, create content taxonomy, maintain content workflow, and define the ongoing content. Your editorial plan should be tactical and detailed, breaking down your marketing mission and who will be responsible for what specific tasks. This process will help you focus on the actual execution of the content itself.
While there are many details to consider, include these important considerations in your editorial planning:
- Key areas or categories for editorial coverage
- Topics in those categories to cover
- Team member responsibilities
- Content to publish and repurpose
- Accompanying social media and community messaging
- Success measurement targets
Continue by putting editorial calendar best practices into place, to remove speed bumps and waste from your content production operation. There are many free collaboration management and calendar tools available online, or it’s fine to start out using a spreadsheet. This schedule will help track your content’s progress throughout your editorial process. How you design, share and access your calendar will depend on your goals and resource allocation.
As a foundation it’s recommended to include these fields in your calendar:
- Publish date
- Content topic
- Content headline
- Channel for publishing
- Author of content
- Owner of content
- Status (continuously updated)
One of the most challenging parts of the editorial process is making sure you have enough interesting ideas in your pipeline to turn them into valuable content pieces and maintain a consistent publishing schedule. By making these documents accessible, everyone can add information, refine ideas, and help with long-term content planning.
Then look at the metrics and audience feedback to inform future content planning and determine which key performance indicators (KPIs) are most valuable to you for determining the impact of published content. These KPIs are likely to vary between channels and types of content. For blogs and social media, quantitative data like the number of views, shares, likes, and traffic growth is important, but don’t forget to understand the overall impact of your strategy. If you are trying to retain developers on your developer program, is your content making this happen? Or are they getting frustrated and leaving.
A big consideration for all of your content pieces is the tone of voice. For your B2C or B2B marketing efforts, you might have brand guidelines which outline the brands’ tone of voice, is this appropriate for your developer audience? If not it’s something you’ll want to give some thought to and you may need to create separate guidelines for your developer audience. Generally, you’ll want to establish a unified voice for your content to build trust with your audience.
Finally, consider what your publishing cadence should be. There is no universal “right amount” of content to publish. The key is to figure out how much high-quality content you can produce on a regular basis — and then maximize it through your distribution channels to reach your goals. Any technical content, should, of course, be updated when new releases and updates are made. If your technical content hasn’t had a pair of eyes look over it for a while, take a look to see if it can be refreshed – no developer will want to see reference documentation from 2006.