🙋Messaging for Developers
TL;DR - They don’t care how good you say you are. They care about what you can do for them.
Do you have any questions, need personalized guidance, or want to share your journey in this playbook? We'd love to talk to you. Reach out to us.
How Does a Strategic Messaging Framework Help an Organization?
Branding: Creating an identity and a brand voice for your company that is distinct and easy to communicate quickly
Creating Buyer Personas: The profile of your target customer, encompassing their roles, their pain points, and the solutions your company will provide
Initial Content Marketing: Content marketing can grow your business by driving website traffic and leads, answering key questions, and positioning your startup as a thought leader
General Availability Launching: With effective messaging, you can clearly convey the value of key launches and drive adoption of new products and enhancements
Finding Design Partners: A key to long-term success is engaging design partners who can provide high-quality product feedback during development and testing phases to improve launches
Messaging is a critical foundation for so many early-stage activities, including:
A successful brand messaging framework, along with your persona document, should help you:
Empower: Your teams to rally around a clear purpose and identity, eventually informing every piece of content you create
Prioritize: The needs of core users
Increase productivity: By removing approvals on site changes, sales decks, or even blog posts from your marketing team
Drive alignment: By being a constant reminder of the public promises you’ve made to end-users
Key Factors of Developer Messaging
Creating content that appeals to developers requires understanding their pain points, goals, and workflows. Here are a few tips to help you create content that will resonate with developers:
Use technical jargon - Speak the same language as your audience to build trust.
Provide solutions - Give developers practical information they can use to solve problems.
Use case studies - Show developers how your product has helped other companies solve similar problems.
Keep It Developer-Friendly: A “Developer-friendly” approach tends to be very practical. As mentioned previously, developers don’t want to be marketed to. They want to understand very quickly if your product is for them. To do this, your messaging should help developers decipher questions like these:
What type of product is being offered?
What does it do?
How does it make a developer’s life easier or better?
Why should a developer use it?
Tone and Voice
It's essential to pinpoint the voice that reflects your identity, whether it's professional, serious, fun, geeky, or edgy. Any of these styles are suitable, as long as they align with your developer personas, remain consistent, and authentically represent your company culture and people. Developers typically prefer a down-to-earth tone over a corporate one, so it's okay if your company's corporate voice differs from the one you use with developers.
Additionally, consider the reading level that resonates best with your audience. While it's crucial not to oversimplify language, overly complex language might alienate your audience.
In marketing communications, using "you" instead of "we" can be particularly effective when addressing developers and communities. Instead of boasting about your company, focus on how developers can succeed without resorting to marketing jargon.
They don’t care how good you say you are. They care about what you can do for them.
Check out Algolia's developer hub to see how they communicate - https://www.algolia.com/developers/
Example : How PostHog thought about their brand
Then they decided to be a more fun company:
Examples of other Devtool companies:
Feedback and Communication Loops
As with everything you do, a feedback loop is essential. Provide your developers with a means to get their questions answered and to tell you how you are doing. Talk directly to your users to find out how you are doing, regularly find out their needs (as they may have changed), and ask them what they like or do not like in your messages and about your product. You can do this by social media, email, regular surveys, focus groups, in-person, or forms on your site.
Keywords: Features v/s Benefits
Messaging keywords are simply that – the words used to describe what your product is and does. In this context, these messaging keywords should not be confused with Google AdWords keywords or SEO keywords, although this work will inform your ad buying and SEO strategy. They come in two forms, features and benefits. Both are important, but 80% of the words you use in messaging should be based on the features of your product, given the practical nature of what helps the developer make a decision about your product as described earlier.
Messaging Keywords (Features) : 80%
Keywords based on features come directly from the words you used when creating your segmentation and from your product specs. They are practical and factual. Let Developers know what you offer and what they can build with it backed with any tech specs that are relevant. For example, if your tool is a machine learning modeling tool, you must say that so it’s clear what you offer. If your tool is only for Android developers, you must say that so iOS developers don’t waste their time. Developers want to see these words so they can be confident that what you offer is what they are seeking. Use those words directly in your messaging and activities, across the journey. They will provide clarity and confidence in your offering and clarity in what developers can build with it.
Messaging Keywords (Benefits) : 20%
Benefits are the words that describe what your product can do for the developer. It’s important to be as descriptive as you can, in an honest and authentic way. Again, refer back to the pain points and use cases you identified on your Persona Canvas to connect the dots. Let’s go back and review the message at the start of the chapter – “An easier way to develop.” The statement brings up more questions than it answers. What type of development is easier? What part of the development process is easier, all of it? Define easier? Why is it easier? Because the developer will use tools they already know, it’s important to be as specific as you can.
We used AI to analyze Devtool companies' homepages:
Hasura
80%
20%
Gitlab
60%
40%
Hashicorp
65%
35%
Last9
70%
30%
Jam.dev
70%
30%
DeepSource
60%
40%
Snyk
60%
40%
Harness
70%
30%
Signoz
70%
30%
While for Non Devtool companies:
Hubspot
40%
60%
A powerful Framework: Thinking in terms of Benefit Layers:
Indeed, some features don’t require benefits. Developers don’t need you to tell them why a faster CPU is a good idea, they will just want the specs.
This is why each feature requires a different Benefit Layer. These are:
Feature-only - Skip the benefit if it’s obvious Direct benefit - Use if the immediate effect needs pointing out Knock-on benefit - Use if the bigger implications are unclear Top-level benefit - Avoid unless you’re a category leader
It can be tempting to pitch the top-level benefit to try and increase the perceived value. But, that leads to the overused “Ship Code Faster” headlines which don’t tell your reader anything helpful.
Source:
Here's an interesting hackernews thread on benfit layers:
https://news.ycombinator.com/item?id=36716258
Why selling features work?
Benefits are why someone would use your product.
Features are what your product does.
An example of selling by feature is Datadog:
Homepage SEO title: “Cloud Monitoring as a Service | Datadog”
Homepage headline: “Modern monitoring & security”
Homepage strapline: "See inside any stack, any app, at any scale, anywhere."
Example: Requestly
Sachin, CEO of Requestly, shared insights into their approach to messaging and website redesign. They have just revamped their main landing page at requestly.com, focusing on clarity and targeted communication. Here's a glimpse into their thought process:
What are they building?
One Word: HTTP Interceptor
One-Liner: Simple & Powerful "HTTP Interceptor" for browsers
The term "Open-Source" was omitted from the tagline, with a GitHub badge prominently displayed instead.
Who needs this?
Frontend Developers & QAs (highlighted in the second fold)
What is an HTTP Interceptor? The first fold of the website details the core features, making it immediately relevant to their target audience:
Override/Stub API Responses
Redirect URLs (APIs, Scripts)
Create API Mocks
Modify HTTP Headers
Capture HTTP Sessions
How does it help? The second fold explains how Requestly accelerates local development for front-end developers, helping them ship faster.
Other considerations:
Collaboration features with Team Workspace
Comparison with "Charles Proxy" & "Telerik Fiddler"
Additional features, testimonials, and blog posts
Social validation through reviews, ratings, and company logos displayed in the first fold
Here's a post from Sachin on this:
Why features > benefits
Marketing wisdom often emphasizes focusing on the "why" rather than the "what." However, this approach can be ineffective for developer-focused products.
Here's why: Developers are particularly sensitive to vague language and need clear details to understand how a product works. Benefits-focused marketing can come across as insincere and make it difficult to evaluate a product's actual features and capabilities.
While some benefits language is necessary for non-technical stakeholders, it can hinder the user experience for developers who need to understand the product's inner workings. A balance is necessary.
While benefits language is essential for executives and non-technical users, it should be used sparingly for developers who require more technical information.
Additional tips for developer messaging from PostHog
(source)
Be opinionated
Pull, don’t push
No sneaky shit
Read more here:
Was this helpful?