Go-to-Market for Developer-Centric Products

I had an unexpected and very interesting conversation last week with a founder for a really interesting product/technology focused on improving the auditory experience for virtual experiences. We ended up talking through a lot of the “general considerations” for GTM, and that felt pretty normal to me…

And then I realized that it’s not a “pretty normal” experience for a lot of people. I tend to take my own experience for granted and assume everyone has the same (or more) experience that I do. After 15+ years of diving deep into products, platforms, growth, design, marketing, and I can’t remember what else, I am finally starting to remove that assumption step from my thinking.

I’ve been lucky to work closely with hundreds of incredible developers, and to talk to even more as potential customers and end users of products I’ve shipped. erations that you might not know to think about.

The right GTM strategy really needs to factor in your technology, how the product is built, and who you plan to compete in the market. My goal for this post is to give the teams working on these types of products a better set of considerations so they can move forward with a higher level of confidence.

Disclaimer: I am *not* actually an engineer. I understand the basics, I’ve spent my fair share of time trying to debug things like page indexing, ad loading, styling issues, etc. but I’m not one of those product managers who spent time writing code.

Embrace Simple Storytelling

Highlight your product by highlighting the success of the people who use it.

Core Concept: Showcase real-world applications of your product and what people can do (and have done) with it.

Why It Works: Developers in the planning phase are essentially deciding what materials they want to build with. They have a set of standard criteria they apply to any pre-made solution, whether that be something like a library, a framework, or another product.

Some of the things on their checklist:

• Will it be performant?

• Will it handle the scale I need it to?

• Is it secure?

• Can it solve more than one of my requirements?

• Is it easy to implement aka will it actually save me time/resources?

• Is it going to be around in 5-10 years from now?

• Who else is using it?

Example: Salesforce exemplifies this approach by sharing success stories that demonstrate the tangible impact of their products across multiple applications and use cases. For instance, the story of how T-Mobile used Salesforce to revolutionize their customer service is not just inspiring but showcases measurable success, like a 25% decrease in call center costs (Salesforce Customer Success Story).

How to Approach It: Start by establish an open line of communication with your community. Maybe it’s as simple as a very active public repo in Github, or maybe you set up a Slack or Discord instance to offer real-time support/help.

Once you have the communication channel established, you’ll start to find traces of great stories just by supporting your community. Open up the conversation with those users and customers and ask if they would be willing to share more about what they are doing and loop in their marketing team.

Kudos if you can wrap these stories up with the achievements and outcomes that follow, but developers tend to care more about what’s possible in the techology selection phase than the end results. Their logic-based thinking will disconnect from your story if it gets too far away from their current use case, so keep that in mind.

Unless they are in stealth mode, most of your customers are building things that they want people to know about — which makes them very willing participants in co-marketing opportunity. Once you have the content ready, work on that earned media coverage.

Documentation Required.

Core Concept: Take the time to make sure your documentation is useful. Equip your developers with whatever they need to implement/integrate your product with the least amount of friction. This is especially important for your go-to-market, because if you frustrate your early adopters, you’ll end up with a reputation of being hard to implement/integrate and that will make everything else a lot harder moving forward.

Why It Works: Developers place an extremely high value on quality and efficiency, (probably) because their success tends to be evaluated with the same criteria. Every speed bump or interruption they experience while working with your product is a nudge towards them advocating for a different solution. What they need from you:

• Up to date and detailed documentation.

• Examples across a variety of use cases.

• Templates, snippets, and examples where possible.

• Supported integrations into the other “ingredients” they are working with.

• The resources they need to get a usable sandbox/dev environment setup quickly (Db dump, Docker image, etc.)

Example: I have a running joke (mostly in my own head) that at least 50% of developers will give me the same answer if I ask about who does documentation really well. While there are plenty of notable examples out there, Stripe is the clear winner.

Not only is their documentation thorough, it’s easy to follow, flexible enough for all developers across all disciplines to leverage, and very easy to navigate and leverage. I even had one conversation where someone called it “beautiful” — which is not something I hear from a lot of developers.

How to Approach It: 

Step 1: Keep your documentation up to date and expand it to cover common questions you’re getting from your community. You might even consider letting developers submit “pull requests” for updates to the documentation.

Pro Tip: Talk to your team about why they are excited about the things they are working on and what kind of things it unlocks. Ask them to capture some of the less standard but more exciting applications so that you can include them in your documentation and spark ideas for the users leveraging it. This gives them something to look forward to *if* they choose to use your product while also ensuring them that you’re thinking ahead.

Step 2: Look for opportunities to enhance your documentation with ready-to-use resources like templates, code snippets, dummy data, or config files. that are easily accessible when they need them. Regularly update these resources based on new features and feedback.

Pro tip: To encourage usage, consider integrating these resources directly within your product’s development environment.

Step 3: Make it easy to share. If all of the other pieces are there, your developers will actually share your resources with each other.

Developer Tooling and Kits

Core Concept: Leverage Software Development Kits (SDKs) to improve the overall developer experience and reduce friction.

Why It Works: SDKs streamline the development process by providing necessary tools in one package. Take Twilio’s SDK, for instance. By offering comprehensive SDKs, Twilio has not only simplified the integration of communication features but also reported a notable increase in user engagement and retention, with developers spending 40% less time on integration issues (Twilio SDK Impact).

How to Approach It: Do the research to figure out what your early customer base is building with. Figure out who is most interested in leveraging the SDK and treat them like a design partner for putting it together. If you don’t have customers yet, consider finding some design partners ASAP and/or leverage the developer communities that already exist.

Develop SDKs that are well-documented, easy to integrate, and compatible with multiple programming environments. Regularly update them based on new features and developer feedback. Consider creating tutorials and sample projects that demonstrate the practical use of these SDKs in real-world scenarios.

To Open Source or NOT to Open Source?

Idea: Consider open sourcing as a strategic move to build trust and community around (or adjacent to) your product.

Why It Works: 

My experience in Open Source is very weighted in WordPress — the CMS that powers over 40% of the internet. When I was at 10up, we went from allocating some open source time to a few people on the team to running an entire open source practice dedicated to improving WordPress core and also building and releasing our own tools, documentation, and products to the open source community.

I wanted to gut check myself here so I looked for a few other success stories in the open source space.

Red Hat’s success with open-source solutions illustrates this strategy’s effectiveness. By open sourcing their products, they have built a robust community of developers and users who contribute to and advocate for their software. This approach has led to significant growth in user base and revenue, with Red Hat consistently reporting increases in their financial results (Red Hat Open Source Success).

How to Approach It: If you decide to open source your product (or a part of it), ensure that you have a clear governance model and a strong community engagement plan. You will need to invest some resources into starting, managing, and growing the community but it absolutely pays off and can act as a key differentiator (or even a moat) for your product.

Encourage contributions and feedback from the community, and be transparent about your development roadmap. Open sourcing can be a powerful tool for growth, but it requires careful planning and sustained effort.

Outside of the investment required to make open-sourcing your product meaningful, you need to think about your business strategy. Open-sourcing the wrong thing can make it really hard to monetize your product, so think about the different parts of your product. Look for things that are useful on their own in a wide variety of use cases, but probably aren’t *the* thing that people are going to be excited about and willing to pay for.

Sometimes it’s as simple as a library, a training model, or even a framework or strategy that you discovered during the process of building your product.

Whatever you do, don’t force it. The best candidates for open sourcing will feel obvious. That means they are:

• Useful in a wide variety of use cases.

• Something that others can contribute to without “going out of their way”

• Is relevant now and will *probably* be relevant in 2-3 years from now.

As I mentioned, this isn’t a guide, but it covers a few specific things that I’ve seen teams overlook or forget about until it’s almost time to ship. Consider them early in in the development lifecycle so you can be intentional about how you enter the market and shift your focus to finding product market fit.