Building a Voice of Developer (VOD) program: 10 key steps

As marketers in the developer space, we're fortunate to have an audience that's vocal and tells us exactly what they need to improve upon their day-to-day. This could come in many forms and sources, such as feature requests through user interviews or thoughts through support.

It's up to us to take this feedback and make it more actionable, quantifiable, and discoverable across an organization, without losing sight of the end goal of the Voice of Developer program, which is to establish a two-way feedback loop between you and the developers using your products.

In this article, I'll hone in on:

Two buckets of developer feedback

Over the years and countless hours of research data, I find most companies fall into two buckets when it comes to collecting feedback from their users.

Feedback = distraction

The first bucket is where companies or stakeholders may find feedback to be a distraction. This could be in a sense that, "if we open up the floodgates, we won't be able to manage or deliver upon expectations, because we don't have the resources".

Feedback = inactioned

Then there's the second bucket - companies that have made available a ton of channels for collecting feedback. They'll acknowledge the feedback or explain why certain features fail to exist but that's where it stops.

The feedback doesn't get reported to the right PMs, engineers, or even higher-ups. And in the end, users don't feel heard and will likely keep complaining to no avail.

What is the Voice of Developer?

Voice of Developer program aims to strike a balance between collecting feedback, communicating what's possible and what may not be, and using the feedback to influence not only product roadmaps but in our case as marketers. It also informs our messaging and go-to-market efforts.

My first venture into the world of Voice of Developer- or 'Voice of Customer' as we called it then- was at GitHub. My amazing manager at the time felt we needed a way to increase developer satisfaction, but further, cultivate a customer-obsessed culture when building products.

I even had a codename for this initiative, I'm not sure why but I was definitely excited. I very much focused on the initiative to get buy-in org-wide, audit our feedback channels, devise a framework to prioritize the feedback, and eventually the goal was to publicize our product roadmaps for broader exposure.

What are the benefits of a Voice of the Developer (VOD) program?

There are a lot of factors that go into building a successful Voice of Developer program. Let's take a look at some of the problem areas a VoD program helps to solve.

Discoverability

It improves discoverability and creates a streamlined process and system for sharing feedback within the company and internal stakeholders such as PMs, engineering, design, marketing, and broader leadership.

Multiple channels

You'll realize there are so many different channels where the feedback lives. The Voice of Developer program helps firstly to identify the many channels feedback is captured.

Feedback has the tendency of getting lost or not included in prioritization exercises, simply because it may live on Twitter. But PMs are looking at support tickets and user interviews.

Plus, identifying your top channels and creating a one-stop-shop repository for feedback makes the feedback attributable. You're able to respond to your users or even let them know you've shipped something they've requested.

Influence product roadmaps

Feedback is great, but it doesn't do much if it sits in a doc or support ticket somewhere.

A Voice of Developer program helps influence your product roadmaps based on this feedback. This could be major bug fixes, new webhooks for SDKs, or other feature updates that not only enhance your products but also your overall developer satisfaction.

Plus, this feedback provides insight into market trends and competitive tidbits. Some users might be using your products in tandem with other products or comparing them to other products. It always helps, especially for marketers, to gain an understanding of what else is piquing your users’ interests.

Improved reporting

In my experience, reporting upward on product gaps and challenges has helped identify a broader need for more resources. This can mean more budget, more headcount... you name it.

It also helps leadership stay in tune with user feedback, which helps impact longer-term higher-level growth for the company.

Empathy

Mainly, the program helps keep empathy towards the top of your developer community's mind for the organization outside of not just product teams, but also support, sales, ops, marketing- everyone.

Even if teams are building first-party products, that may not impact developers directly. They'll have a better idea of the types of gaps and challenges products have when it comes to things like extensibility.

People often ask me why I'm so passionate about developers and developer marketing. It's easy. Developers are building software that's changing the world. The first black hole image was taken using extensive code from an open-source community of millions of developers.

In order for us to understand, support, and expand this type of innovation we need to gain a better understanding of the developer audience and give them the tools they need to keep building.

This simply can't be done through traditional marketing but building authentic connections, value add messaging, and a community around the products we help to build and promote. That's why developer empathy is consistently top of mind for me, hence building out a Voice of Developer program.

VoD program: an evergreen initiative

This also means a Voice of Developer program is meant to be an evergreen initiative, to be expanded upon and repeatable, and not a one-and-done type situation.

In order for your developers to trust you, it's important to be consistent in your approach, especially as it comes to your feedback loop.

How to set up a VoD program?

There are quite a few steps associated with building a successful Voice of Developer program. I'm big on docs so each of the steps I mention is normally fleshed out as part of a written brief, in which I start with the problem statement. Let's dive right in.

Step one: identify your goals

Different orgs may have different objectives they're trying to tackle. Is your objective to showcase your feedback to relevant stakeholders?

It might be to create a one-stop-shop to house all your feedback so it's easier to search and engage with. Perhaps your org isn't acting on feedback today unless it stems from very angry support tickets.

Or, perhaps you realize feedback isn't top of mind when building new features or products, and you'd like to change that.

Even as marketers, creating a program might be helpful for us to better tackle our messaging, understand use cases, and be able to synthesize that broadly in our communication plans.

Whatever your goals might be, it's important to understand them upfront as they'll impact how you get buy-in for the program, and the resources you may need to keep it running.

Step two: find your champions

It's easy for us to put in a ton of work to create processes and frameworks that folks don't end up using. Voice of Developer program can be as heavy or as light a lift as you'd like.

But in no way is the intention to create process-oriented delays in product development. That should be communicated upfront. As you start building out the program, it'll be rather pertinent for you to find your relevant stakeholders.

Stakeholders

I'll tell you, PMs, engineers, and designers will be the first to sign up. Knowing what users want makes their jobs easier as they devise, design, and plan. Support already gets bombarded with feedback. They'll appreciate being able to respond meaningfully or better yet, have a PM talk to customers directly.

Sales and marketing teams will appreciate being able to better anticipate certain questions or requests, and leadership will be able to see what users are asking for and help them find the resources to support certain requests that could very well up the ante on the product or feature set.

People will be on board, but it's about making it easy for them to understand why and how it'll benefit them and the business in the long run.

Accountability

Plus, accountability is an important part of the Voice of Developer program. The right people need to be involved in order to act on the feedback received. That's why setting your problem statement and identifying your goals act should be your first step.

Step three: audit your feedback channels

Internal

These can be internally sourced channels such as:

Support tickets,
Your own developer community,
Forums,
User interviews conducted by PMs or other stakeholders,
Feedback your sales partnerships and channel teams get when they're making deals, or
Questions SEs receive when working with customers on solutions.

External

And then you have external channels such as:

GitHub,
Twitter,
Slack communities,
Discord,
Stack Overflow,
Reddit, and so many others.

Plus, there's a whole other stream of feedback that comes in from surveys, such as NPS that provide more insight.

Step four: prioritize your channels

This may vary between small and large companies but essentially, you may not have the resources, people, or bandwidth to tackle every channel. So, you've got to:

Identify the channels that are most used and regularly maintained, and
Be mindful of the noise. Customers will complain anywhere they can, so you've got to pick up on the most effective channels for you.

I found these to be largely rooted in support tickets and internally sourced developer channels such as forums, business development teams, and of course, direct user interviews.

Plus, as you're picking your channels, make sure they're ones that relevant stakeholders can access and use to respond to, or collect additional information.

Step five: build a VoD “hub”

Next up is to find a home for your Voice of Developer assets. As you've now learned, going through potentially many channels of feedback can be tough to discover and attribute the feedback you find, especially when it spans multiple avenues.

Building a one-stop-shop repository for the feedback you collect will be important. It makes discoverability and attribution easier. But also, it'll be simpler to track status on things like responses, people involved, and progress made on improving or backlogging based on what you perceived.

Make use of tools

Previously, I've used a GitHub repository that housed each piece of feedback as its own issue, with specified labels for feedback type. Labels such as feature requests, bug fixes, or anecdotes. Then, each issue was assigned to relevant stakeholders.

The labels helped track feedback based on type. Assigning issues to the right stakeholders helped build accountability. And the repository itself lets you search through issues to track things like frequency or ask where the channel's feedback was taken from.

Plus, using projects helps track progress made on each type of request. There are other tools as well, such as even creating a Google Drive to capture interview notes, and a JIRA or Looker dashboard to track support tickets and resolutions.

Step six: define SLAs

Define SLAs for response times and create canned responses. This step is often forgotten simply because we may take in a request and forget to respond, or not have anything useful to say right off the bat. So we wait in hopes for that to change.

Don't do this.

For accountability’s sake, say give yourself or your teams five business days to respond to a request. You can create canned replies based on product scope. For example, you can let the user know that your team:

Is working on the feature requests or bug fix currently,
Plans to work on it in the next three months or six months, or
It's not prioritized on your roadmap today but you will share the feedback with the relevant teams.

The answer doesn't always have to be yes, but an answer itself helps the developer feel heard and acknowledged.

Step seven: synthesize the feedback

When you report on your feedback which is the next step, it will be important that this information isn't provided as a list or link-offs but is actionable insights to folks who may only have 30 to 60 seconds to understand what's needed to fix potential issues.

Depending on the format used to report out I focus on slicing feedback based on specific product API's or feature sets, identify key trends observed, and report out on the analysis I've been able to conduct.

Usually, this is in written form or something more visual such as tables and charts, and reported out monthly or quarterly to relevant stakeholders.

A quick example of a short insight might be that our feedback app has seen a lot of positive reviews from our users this month, with the main theme being to improve productivity by adding emoji reactions and searchable filters.

Step eight: report out often

Next, report regularly on your findings. The feedback is important, but it means nothing if it isn't shared with the right people.

Reporting to relevant stakeholders and keeping Voice of Developer top of mind within your org will help to alleviate some of the problems associated with feedback capture in general, but also truly help internal stakeholders empathize with the folks using your products.

I like to use all hands in both monthly and quarterly business reviews as a good way to surface this feedback. Other options could be to create a specific Slack channel that updates out when new feedback is added to your Voice of Developer hub, or even roundtables and enablement sessions with your product, sales, partnerships, and/or channel teams.

Step nine: prioritize your feedback

As with any passionate community, we tend to receive a lot of feedback from our developers and unfortunately, not all feedback can be prioritized or acted upon.

In order to take into consideration various factors of prioritization, I've previously created a framework that I use to guide my own prioritization exercises.

The FAIR method

Again, this could vary with company or team size, but it does help provide a general baseline. I call it the FAIR method and it takes into account:

Frequency, which is the number of times we've received this feedback.
Alignment, which is how closely does this align with our current company and/or team goals? This is usually measured through percent, so 100% for high alignment, 50% for medium alignment, so on, and so forth.
Impact, which is how high or low does the fulfillment of this feedback affect revenue or other targets we're focused on? This could be the number three for massive impact or point five for low impact.
Reach, so the number of users this feature affects. Depending on the size of your company and user base, these numbers can vary. But my scale has usually been the number one for one to 3000 users, two for 3,000 to 10,000 users, and three for more than 10,000 users.

I then multiply each of these numbers and come up with a score. Essentially, the higher the score the more potential the feature has to be prioritized.

Clearly, this isn't a foolproof method. But in a world where growth is product-led and competition is plenty, it certainly helps build a general idea.

Step ten: influence roadmaps

The last step is to inform. During quarterly or annual planning, sit in with your relevant stakeholders, share the insights you've created over a given timeframe, and ensure the ones that are high in priority are added as part of roadmap planning.

When those features are shipped, let developers know, they'll not only be excited, but you've just rounded out a two-way feedback loop and helped improve day-to-day workflows of the very people building tools that improve our day-to-day workflows.

Regularly meeting with developers helps me realize a couple of things. Their feedback can range from, "This is a complicated pricing model, please fix it" to "Your product is f'ing dope, build more".

I sometimes feel like there's no middle ground, but I think that's the beauty of it. The other thing I realized is that their developer tool stack is ever-changing.

From tools that improve productivity to tools in the DevOps lifecycle over the years, I've devised my own tool stack for Voice of Developer programs, and I realized that with every role, with every team, the tool stack consistently evolves.

Improving effectiveness

In this next section, I'll discuss how to improve the quality and effectiveness of the Voice of Developer program, starting with my current tool stack.

My VoD tool stack

GitHub
I've mentioned previously that I've loved creating a GitHub repository that acts as a hub for all feedback. I can create issues for each piece of feedback, assign specified labels to it, accompanied by labels that include product and feature names.

I'm also able to assign issues to relevant stakeholders and we're able to have discussions within the issues themselves. That makes for easy tracking and of course, streamlines the Voice of Developer workflow. Once feedback is resolved, issues can be closed but still later found if and as needed.

Google Drive
Lately, Google Docs, Google Sheets, and Google Drive have been immensely helpful in non-GitHub-using situations.

Drive lets me track Docs associated with user interviews and business reviews.
Google Docs is where feedback is recorded under specified filings. And
Google sheets for metrics tracking.

JIRA
JIRA dashboards created from support tickets housed in JIRA are also helpful in tracking feedback and resolved cases. The downside here is you can only track feedback if it's housed in JIRA.

So if your team doesn't regularly use the tool, the feedback hub might be harder to surface team-wide.

Research

Dovetail
Dovetail is also a fantastic research tool that helps track user interviews and various research projects in one place. For example, I'm able to add raw interview notes with video and/or audio recordings.

This is great because you can upload video audio files, and Dovetail actually creates the most accurate transcripts. Then I'm able to use tags similar to my labeling strategy with GitHub, making it easier to search and filter through tags and build key insights based on research.

Google Docs / Sheets
The insights can be shared publicly, either externally or within your team, and depending on the type of license you have, the insights can also be easily copied and pasted into Google Docs or other tools you might use to house your VOD assets.

Measure

Delighted
Delighted is a wonderful tool to gather feedback from your users in real-time, whether in product or email, but also to apply a net promoter score using the Net Promoter System.

Making a splash

Now I want to talk about making a splash with your Voice of Developer program.

Leverage VoD insights

As marketers, we often rely on market studies or PMs to tell us why our products are better than others. I've learned that being out there, talking to developers on a regular basis is the best way to learn why or how a product is meant to be better than competitors.

My own habit is setting up at least two 30 minute interviews per week with developers or partners using the products that I support. Asking them questions around usage, what works, what doesn't, and of course gathering feature requests.

That has helped me position and message products better than, honestly, anything else.

Plus, if you're a marketer that's either driving the Voice of Developer program at your company or acting as a stakeholder, you'll also have access to excellent information that helps you understand use cases, define messaging, find testimonials, and target speakers for internal or external events.

For those of us building a developer community, we also get first access to our superfans that can help promote products to their developer friends adding to organic growth.

The Voice of Developer program isn't just for product managers to use for informing roadmaps, but marketers whether PMMs, developer marketers, growth folks, and others can use anecdotal information to build enablement material, better train our sales and growth teams, create campaigns targeting the right audience types and build a community for our product simply based on feedback received.

Inner-source and empower

Now, let's go into inner-sourcing your Voice of Developer model. Tim O'Reilly coined the term many years ago. Inner-sourcing is the use of open-source software, best practices, and the establishment of an open-source-like culture within organizations for the development of software.

It's a term we used a lot at GitHub. The reason I bring this up now is to empower anyone on your team to react to or proactively address Voice of Developers in our products and experiences.

For example, if I noticed feedback around a typo on our landing page, I should feel empowered to go in, fix the typo, and close out the issue or ticket. If an engineer has a quick fix to a small feature request, they should be able to go in, build what's necessary and ship it.

All hands on deck

Voice of Developer will only work if you're all hands on deck. Improving a developer's productivity or being empathetic to developer needs isn't on one person or function. It's a group effort and that is something people on teams should be empowered to tackle.

Heck, that should even be a standing OKR - the need to read and act on developer feedback when possible.

Measuring success

There are several ways to measure the impact of your Voice of Developer efforts.

Adoption

Some are more qualitative, such as feedback received through support tickets, email, or Twitter. Some are quantitative, such as adoption metrics, which can vary from org to org.

Some examples include:

Number of developers,
Number of apps created,
Number of apps published,
Number of apps installed, and
Number of API calls per app.

Research

There's also NPS or Net Promoter Scores that are calculated when users are asked to rate whether they'd recommend your company, service, or product to others, something that is surfaced in-product or in an email.

Internal

Plus, there are also internally sourced metrics such as support tickets resolved, time to resolution, and even tracking how many improvements were made from user requests.

*Varies by org

Track contextually: MoM, QoQ, YoY

I also like to track often, looking at numbers month over month, quarter over quarter, and year over year, helps tell a story and will help show the impact of your Voice of Developer program.

Final thoughts

There you have it, an overview of building your very own Voice of Developer program.

The term feedback was mentioned 66 times in this article, it's certainly important and a first step but the key elements of building a two-way feedback loop include:

Synthesizing the feedback across different channels,
Sharing them with the right people, and
Influencing product roadmaps.

Building a Voice of Developer (VOD) program in 10 steps