I’m the Product Marketing Lead at NexHealth, and I'm excited to talk about developer insights.
I can't think of a more foundational element to a successful developer-focused, go-to-market strategy or product strategy than acquiring and using developer insights.
My developer marketing journey
I’d like to start with a little bit about my background and my journey throughout developer marketing. I began marketing to developers when I was at Salesforce, where I joined the MuleSoft division, which is an API management and integration platform as a service (iPaaS).
I worked specifically on the financial services team, adapting our core API management platform to that industry. I also helped the Salesforce teams on Sales Cloud and Service Cloud speak the language of developers in their own go-to-market motions.
I then moved to Stripe, where I worked on launching several payments-adjacent products, including Financial Connections, which is a way of linking bank accounts to Stripe.
Since August 2022, I've been at NexHealth, leading API and developer marketing. At NexHealth, we build the universal API for healthcare data. I'm helping to orchestrate all of our go-to-market motion around that product and also the developer audience broadly across our portfolio.
In each of these experiences, I've worked on a slightly different type of product and a slightly different type of developer at the heart of our go-to-market strategy.
But I've picked up some tips and tricks that I think will allow anyone, whether you're at a startup like NexHealth or a large company like Salesforce, to do a better job of making developers' voices heard as part of your strategy and product roadmap.
I'm going to talk about:
- What it is about developers that make them such a uniquely valuable source of feedback.
- Specific ways to gather qualitative and quantitative insights from developers.
- How to put those insights into action through your product roadmap and go-to-market strategy.
Teresa Garanhel
The value of developer insights
Let's start with the ‘why’ behind developer insights. The reason I actually fell in love with marketing to developers is because they're such a unique audience. They deeply understand technology and they're very well-versed in their subject matter.
These are people who’ve spent years studying software engineering, and they continue to acquire new skills and invest in ways to be more productive and more efficient in solving new problems. So that means you can learn quite a bit just by talking with them.
They'll be very informed and opinionated, and they'll often know exactly what it is they're looking for when it comes to solving a problem or finding a new solution.
That's a real treasure trove of insight if you're a marketer, a go-to-market strategist, or a product manager because developers will know what they're talking about, and they won’t mince their words when it comes to giving honest and direct feedback.
Sometimes the feedback you get may sting a little bit, but that's actually for the best because you’ll know exactly what developers are feeling with regard to your messaging.
In one particular case, I was talking with a developer about a product name that we were considering, and they said the name was a bit deceiving.
They'll call you on your BS; it's not something where you have to really interpret a lot of grey space. It's very direct and honest, and that can be super useful, both from a go-to-market perspective and also from a product strategy perspective.
How to gather developer insights
Now, let's dive into actually gathering developer insights. Like with any customer insights program, you’ll want to spend time talking to your developers directly. One-on-ones and structured interviews are really great ways to yield qualitative insights for your go-to-market and product teams.
Anusuya Kannabiran
Something specific with developers is to make sure you're really well prepared going into these conversations. Their time is really valuable, so you’ll want to come in having a really clear sense of what your objective is, and a good, structured set of questions that you can ask them.
Something I think we did well at Stripe was actually having a documented interview guide that any new product marketer or developer marketer could use to conduct various types of developer interviews.
We're now doing the same thing at NexHealth. As we build our developer marketing motion from the ground up, we're thinking about each conversation we have, documenting the learnings, figuring out what went well and what we could’ve done better, and then packaging that into an interview guide.
We have a set of outreach instructions and actual trackers that tell you which developers have achieved certain milestones in the product and would be good candidates for specific types of interviews.
Another thing that's really important is automating this outreach process as much as possible. A lot of times, I think marketers forget to do customer interviews and use developers as a source of feedback because there's so much else going on.
You want to take the guesswork out of that and try and set triggers for yourself based on what's happening in the product or where developers are in your funnel so that you're being notified, whether it's via Slack or email notification, when they’re now a good candidate to have a conversation with.
That's going to make it a lot easier for you and it's going make it a lot easier for the developer if you use tools like Calendly and Mixmax to automate the scheduling of these interview appointments. Don't have a lot of back and forth over email, just get on the schedule. That's not something that’s going to resonate with the developer audience in particular.
And then finally, use your own meetups and events as an opportunity to do this. You can go to your developer community and just be a fly on the wall. You can use that as a chance to have those direct conversations.
But if you also need something really fast, a quick hack that I've found to be effective is to just talk to your own internal engineers. A lot of times we work at software companies with large engineering teams, and they can be a great proxy for what your end users are going to be feeling, whether it's about a piece of copy or visual, or even something else that you're working on as it relates to a campaign.
Now, in addition to those qualitative conversations, you want to get that 30,000-foot view of everything that's happening across your developer services. This is where product usage data can be really important.
At NexHealth, we use a tool that helps us understand exactly what endpoints are receiving the most calls and what errors developers are encountering. So, we use this quite a bit even as it relates to billing our users, and also for things like writing better error messages and tracking the consumption of different endpoints over time so that we know what to emphasize in our messaging.
It's helpful to define your metrics upfront before you actually orchestrate any analytics, so you know exactly what steps in the funnel and stages in the developer onboarding and usage process you're going to be interested in measuring.
Hasanpasha Abdulov
So, document that, get alignment with your teams on what you're going to track, and then implement those analytics in your product early. This doesn't have to be the first thing you do before you have product market fit. But if you're moving from private beta out to public launch, you should probably have analytics orchestrated before that time.
And then you should establish a good review cadence with your teams. Sending out weekly recaps on developer conversations and product usage is helpful. That’s been done both at Stripe and NexHealth.
I think that sharing insights even more frequently can also be useful when there are particular actionable items that maybe a PM or even a salesperson might want to act on. And I'll talk more about how we've done that in the past very soon.
And finally, there are surveys. I think these are a bit of a polarising topic in the developer marketing community, but they can work if you structure them in the right way.
I’ve found that the most effective ones tend to be short. Again, cut out all the unnecessary fluff at the beginning with the qualification questions. A lot of times, you should be able to do the research yourself in your developers' product profiles or even on Salesforce records to understand what business they're in and what their use cases are. Then you can get right to the meaty stuff in the context of the survey.
You want to personalize your outreach as much as possible. I've found a lot more success sending these directly from my Gmail account, as opposed to using marketing automation tools.
And then offer incentives, but don't just think about these as monetary incentives. A gift card or a charitable donation can certainly help, but also think about motivating your developers with recognition and flair and just elevating your voice within your community.
That's something that I think Salesforce and MuleSoft did really well; our active developer participants in our community would often get brought into the brand itself.
Ben Oguzie
And that's where you know the developer’s going to feel appreciated. They're going to understand how important this feedback is to your company, and that's something where the entire ethos of that developer forward strategy really starts to manifest itself throughout your brand and your organization.
I think that's something you should really keep in mind, ways to reward and recognize the developers who are talking with you regularly or filling out your surveys. And then that’ll lead to a virtuous cycle where they’ll then recommend that their developer colleagues share feedback themselves.
Using developer insights to inform your product roadmap and go-to-market strategy
Okay, so now comes the fun part, which is actually putting those insights into action that you've gathered through surveys, interviews, and product usage data.
I think there are two particular ways to do this: one relates to informing your product roadmap, and the other is around go-to-market strategy.
Informing the product roadmap
With the product roadmap, developers will often be very opinionated about the product. They’ll also have a long list of requests for things to build next, so make sure to document those.
Take notes and have a tracker that you and your PM share to account for each feature request you're getting, who's requested it, and importantly, the dollar value associated with it. That way, it's really easy to prioritize the features that are going to be most impactful for the business, and that developers are actually willing to pay for.
That's something where I think having that documented and shared across your team is really critical for making sure that those developer insights are making their way into the actual roadmap prioritization.
Something else that I've done at Salesforce and now at NexHealth is bringing developers right into the product meetings themselves. PMs and the internal development teams really appreciate hearing from developers.
And again, a lot of times those folks are really busy. They're not necessarily going to have the time or space to set up those conversations themselves, so make sure you’re acting on their behalf to elevate your developer users' voices in their product planning sessions and their product development process.
Liz Moy
Also, share interview notes. I mentioned before that having a weekly recap is a really good best practice. But also, if you've learned something right away that's actionable for a team, for example, you've identified some bug in the product, get that to the relevant stakeholder like a PM or an engineering lead immediately, because they’ll typically want to act on it right away.
It's doing no one any good if you just sit on those insights until you have time to write up your recap.
It's helpful to then synthesize interview themes across several different conversations that we recap or something that's maybe going out on a bi-weekly or monthly cadence to a broader audience.
But get the actionable intel to the right team right away. That's going to then show that you're iterating quickly and it's going to make your developer interviewees feel even more appreciated and heard because you're acting on their feedback very quickly.
And then finally, create those feedback loops. Make sure you're always going back to your developers and documenting, whether it's in your newsletter or just in one-off conversations, what feedback you've acted on.
If you're not acting on certain feedback, you can share that and explain that there are other priorities right now. But always make sure that you're closing that loop with the folks who are actually offering you feedback.
Kendall Hershey
MuleSoft’s framework for the Small Business Administration Paycheck Protection Program
Below is an example of something we actually built at MuleSoft, which is based specifically on developer interviews that we were running.
This was in early 2020, and we were in the same position as many B2B SaaS companies; our customers in financial services were pivoting all of their development resources away from the initially prioritized projects to COVID-related initiatives.
Essentially, we wanted to learn about how we could help with the projects that these developers were going to be working on in 2020.
We heard over and over again from the members of our developer community, we talked to developers who were part of our regular interview process, and the number one thing that had come up was the CARES Act.
The Federal Government's response to COVID was in part to establish this paycheck protection program for small business emergency loans, and there were a lot of challenges in orchestrating this that we could actually support with our API management platform.
With just a little bit of customization, we could take the core product, adapt it to this use case, and then directly accelerate the process of administering and forgiving these loans.
What we did in the course of these interviews was document what we’d heard, bring it to the executive team, get alignment on building this specific solution based on the opportunity value associated with it, and then work with those developers who’d told us this was a problem to co-create the solution.
Building alongside them and putting this on our exchange and delivering it to some of our top financial services customers was a huge win for us. It was also a great win for the developer community who felt heard and felt like they'd had a real impact on the roadmap prioritization. And of course, it was a great result for the business and the end recipients of these loans who were able to get them forgiven faster.
We wouldn't have known that this was such a priority until maybe too late, had we not been having those ongoing conversations and had that automated structured process of talking with developers and learning about what the priorities were on their end.
Thanks to having that in place, we were able to get really quick intel that this was something that was going to be important for them and that we could help build a solution for.
Adem Sengul
Refining the go-to-market strategy
The go-to-market strategy is another area that you can inform with developer feedback, and there are some obvious ways to do this with your content strategy.
You can look at the developer questions you're getting on your forum and the type of inbound you're getting around different topic areas that developers are curious about. That's obviously important.
There's pricing, where you can do a lot of quantitative research via surveys to understand willingness to pay, and the way that developers like to pay.
Some other interesting things that I've found to be helpful where developers can yield insight is actually the way you name your products themselves. Developers often approach product names a little bit differently than a non-technical audience, where something exciting like Salesforce Lightning resonates really well with a sales or marketing audience.
We actually ended up naming that MuleSoft solution ‘the Framework for the Paycheck Protection Program.’ It’s not a very sexy name, but it’s one that actually worked really well in our testing because we knew that developers were going right into our exchange and just typing in ‘paycheck protection program,’ and the name of that small business loan program.
They weren't looking for any sort of branded term or something that was a bit of a fluffy name, they just wanted to know if we had a solution for this particular problem. That's what we named it, and it made it a lot easier for them to find. And ultimately, that's often going to be what resonates with the developer audience, something literal and descriptive like that.
You'll also want to think about more than just gut feeling, but actually how your names relate to parts of your product that developers are already using.
Think about the code they've already written if you have an API product. Is the name you're proposing for a new part of that API going to conflict with any other endpoints that you already have? That's something really important to keep in mind.
Teresa Garanhel
And again, test with your internal teams and your external developers who are already using the product and have written code to see if a potential name is going to break anything.
Then, also think about how your brand resonates with developers. And this is really important because a lot of times you'll be in a company where developers aren't the only audience you market to. At NexHealth, we also sell to non-technical dentists and doctors and SMB medical administrative staff.
Thinking about how can you create a brand that resonates with all these different groups is really tricky. But a lot of times, a one-size-fits-all approach is ultimately not the best one.
You can come up with something that’s designed specifically for your developer audience and that's going to resonate with them, taking into account their particular needs around showing the product, being literal in your descriptions, and ultimately, having something that just sets off a clear developer feel with technical sophistication, maybe a little bit of irreverence.
Those are the sort of things that are going to make them feel appreciated and that they're clearly in the right place.
Below is an example of how our API page looked prior to a recent rebrand that we did at NexHealth. We tested this, ran it past some developers before redesigning the page, and heard a couple of things that they really wanted to see out of this.
One was that there was no actual product on the page. A lot of times throughout our site, we relied on stylized product imagery. In this case, we had this graphic at the top that showed us connecting to different back-end health record systems.
But developers actually wanted to see the product, and they also wanted to know what they could build with the product. It's not always immediately obvious what you might use an API for, especially an API as broad and far-reaching as ours, where it's a universal API for healthcare data. So they wanted to know the particular use cases that they could go explore.
When we redesigned the page, that was something we kept top of mind. We incorporated the product right at the top, showing actual code that you could run to make a call to our API. And then you could build the example front-end experience on top of this.
This was actually a simplified version of a real customer’s front end where they built an AI chatbot on top of our solution for scheduling patient appointments. If you go to our site, you can actually see this code animate, and then the chat experience animates on the phone in real-time alongside it.
That was something that again just conveyed a little bit more specifically what it is our product does and what you can build with it.
We also added the use case section down at the bottom that provides much more detail about what different customers are building already with our API, just to give developers a sense of what they might want to explore.
It's also helpful for SEO because we often see developers searching for things like ‘forms API,’ ‘medical forms,’ and ‘appointment scheduling API for dentists.’ And that's the sort of thing where without any of those use cases articulated on the page, it's harder to rank for that in organic search.
The last thing you'll notice is that the brand is quite different. We took an approach here where we really embraced the dark mode theme. We tried to make this more of a technical area so that developers would know they were immediately in the right spot, relative to the rest of our site, which is still in that light mode.
Having the combination of the color scheme there and the product really clearly documented and illustrated just makes it so that developers feel like they have a home on our site, more so than maybe they did in the past.
JD Prater
Key takeaways
Developers are a great source of feedback. They're highly informed, they're pragmatic, and they're direct, so use that to your advantage. Don't be shy, they’ll tell you exactly what's on their mind if you just ask them in the right way.
Get a mix of qualitative and quantitative insights. Make sure you're having those conversations on a regular basis, and try to automate that process as much as possible so you don't forget to do it. And then also leverage that product usage data to give you the 30,000-foot view that you can then drill in on in specific interviews that you're having.
And don't forget to use surveys. They’re a good backstop to get an understanding of broader trends across your developer audience.
Feedback is a gift, so make sure you reward it whenever you get developers participating in your surveys or your interview process. Think about ways you can elevate them in your community, give them a voice, offer them speaking engagements, and even represent them in your brand where that's appropriate.
And then apply those insights to your go-to-market strategy and your product roadmap. Make sure developers know you're closing the loop on the things they're telling you they want to see.
Take the guesswork out of your product strategy by spending time on the ground with developers, understanding what it is that's a priority for their organization, and where they're going to be spending their time so you can build the right solutions to help them.
Become a brand your developers love. Incorporate the actual types of visuals they want to see, the detail of the product that they expect, and make sure that that's resonant throughout all of your properties.
