Building a Voice of Developer program

Shaziya Bandukia, Product Marketing Leader, highlights the importance of developing a Voice of Developer program.

She breaks it out into three essential talking points:👇

Why a VOD program?
What is a VOD program?
Challenges that need a VOD program

Why do we need a VoD program?

Firstly, It’s a way to help keep developer empathy top of mind within an organization.

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 or user interviews.

It's up to us to take this feedback and make it more actionable, quantifiable and discoverable across an organization. We don’t want to lose sight of the end goal of the VoD program.

The end goal is to establish a two-way feedback loop between you and the developers using your products. Over the years, I’ve found that most companies fall into two buckets when it comes to collecting feedback from their users.

Bucket one: Feedback = Distraction 🤷

Companies have the sense that if they open up the floodgates, they won't be able to manage or deliver upon expectations, because they don't have the resources. This article’s job is to prove that VoD has the exact opposite effect. It makes it easier and simpler to meet the needs of your developers.

Bucket two: Feedback= inaction 🙅

Then you have companies that have a tonne of channels available for collecting feedback. They'll acknowledge the feedback, explain why certain features fail to exist, but that's where it stops.

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

What is a VoD?

What a voice of developer program aims to do is 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 VoD was GitHub. My manager at the time felt we needed a way to increase developer satisfaction and cultivate a customer obsessed culture in building products.

I very much focused on the initiative to create an organization wide audit, to create feedback channels and devise a framework to prioritize the feedback.

And eventually, the goal was to publicize our product roadmaps for broader exposure.

Problem areas for VoD to solve

Now, I realize there are a lot of factors that go into building a successful VoD program.

Let's take a look at some of the problem areas a VOD program helps to solve.

Now, let's look closer at what these terms mean. 🔎

Discoverability

It 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 that there's so many different channels where the feedback loops. The VoD helps to identify the many feedback channels that have a tendency of getting lost. This may be because they simply live on X, but PMs are only looking at user interviews.

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

Stagnant

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

A VoD program helps influence your product roadmaps based on this feedback.

This could be major bug fixes, new web hooks, or 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.

So, users might be using your products in tandem with other products or comparing it to other products. It always helps, especially for marketers, to gain an understanding of what else is catching your users’ interests.

Reporting

In my experience, reporting upward on product gaps and challenges has helped identify broader need for more resources. This helps leadership stay in tune with user feedback and impact longer term higher level growth for the company.

VoD helps keep empathy towards your developer community

Mainly, the program helps keep empathy towards your developer community. It also supports sales ops marketing. 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!

Did you know, the first black hole image was taken using extensive code from an open source community of millions of developers?

We need to gain a better understanding of the developer audience and give them the tools that they need to keep building. This simply can't be done through traditional marketing, but through building authentic connections, value, messaging and a community around the product we helped build and promote.

Renewable and evergreen

This means that a VoD 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. t's important to be consistent in your approach, especially as it comes to your feedback loop. There are quite a few steps associated with building a successful voice.

Challenges that need a VoD program

There’s a whole range of challengers that a VoD program can help you to smash.

So, let's dive right in.

Setting it up

As with any process, this is going to be the most complex part, but don’t worry, we're going to break it down into a few easy-to-digest steps!

Identify your goals

Different organizations may have different objectives that they're trying to tackle. It’s your objective to showcase your feedback to relevant stakeholders. Perhaps your company 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 better for us to 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 up front, as they'll impact how you get buy-in for the program, and the resources that you may need to keep it running.

Find your champions

It's easy for us to get put in a tonne of work to create processes and frameworks that folks don't end up using. A VoD program can be as heavy or as light of 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 really important for you to find your relevant stakeholders. PMs engineers and designers will be different. 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. Leadership will be able to see what users are asking for and help in finding 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. Plus, accountability is an important part of the VoD 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 is your first step.

Audit your feedback channels

These could be internally sourced channels such as support tickets, your own developer community and forums, user interviews conducted by PMs or other stakeholders. It could be feedback your sales partnerships and channel teams get when they're making deals, or questions they have when working with customers on solutions.

And then you have external channels such as GitHub, X, Slack communities, Discord, Reddit, and so many others. Plus, there's a whole other stream of feedback that comes in from surveys that provide more insight.

Prioritize your feedback channels

This may vary between small and large companies, but essentially, you may not have the resources, people or bandwidth to tackle every channel. 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've found these to be largely rooted in support tickets and internal source developer channels such as forums, business development teams, and 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.

Find a home for your VoD assets

As you've learned by going through potentially many channels of feedback, it can be tough to discover and attribute the feedback that you find, especially when it spans across multiple avenues.

This can end up looking very overwhelming and pretty ugly.

Building a one stop shop repository for the feedback that 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've received.

Previously, I've used a GitHub repository that housed each piece of feedback, such as feature requests, bug fixes, or anecdotes, then each issue was assigned to relevant stakeholders.

The labels help track feedback based on type, the signing issues to the right stakeholders help to build accountability. The repository itself lets you search through issues and track things like frequency of ask and channel feedback. 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.

Define SLAs

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, what do we do? Wait in hopes for that to change? No.

For accountability’s sake, 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; let them know you plan to work on the new bug fix in the next three to six months, or that 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.

Synthesize the feedback

When you report on your feedback, what is the next step?.

It will be important that this information is provided as a list:

Provide actionable insights to folks who want to understand what's needed to fix potential issues,
Focus on slicing feedback based on specific product API's or feature sets,
Identify key trends observed.
Report out on the analysis you’ve been able to conduct.

Usually analysis is in written form or something more visual, such as tables and charts. It’s then reported out monthly or quarterly to relevant stakeholders. A quick example of a short insight might be, “our feedback app has seen a lot of positive reviews from our users this month..”

Report regularly on your findings

Going back to something I've mentioned already, the feedback is important but it means zero if not shared with the right people.

Reporting to relevant stakeholders and keeping the VoD top of mind within your organization 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. It’s a good way to surface this feedback. Other options could be to create a specific Slack channel that updates when new feedback is added to your VoD hub, or even roundtables and enablement sessions with your product sales partnerships and or channel teams.

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. Again, this could vary with company or team size, but it does help provide a general baseline.

I call it the fair method.

Frequency. The number of times we've received this feedback.
Alignment. How closely does this align with our current company and or team goals?
Impact. How high or low does the fulfilment of this feedback affect revenue or other targets that we're focused on?
Reach. How many users will this affect?

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 the day to day workflows of the very people building tools that improve our day to day workflows.

By the way, we do measure the VoD programs, and just regularly meeting with developers really provides valuable insight.

Improving effectiveness

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 VoD programs.

VoD toolstack

GitHub

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 with 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 streamlines the VoD workflow.

Google drive

Once feedback is resolved, issues can be closed but still later found if needed. Lately, Google Docs, Google Sheets and Google Drive have been immensely helpful in non GitHub situations. Drive lets me track Doc's associated with user interviews and business reviews.

Google Docs is where feedback is recorded and Google Sheets for metrics tracking.

Jira

Dashboards created from support tickets housed in Jira are also helpful in tracking feedback and result cases.

The downside here is that 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 serve as a team.

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 in raw interview notes with video and audio recordings. This is great because you can upload video audio files, and dovetail actually creates mostly accurate transcripts.

Then I'm able to use tags similar to my labelling strategy with GitHub, making it easier to search and filter through tags and build key insights based on research. The insights can be shared publicly, either externally or within your team.

And depending on the type of licence you have, the insights can also be easily copied and pasted into Google Docs or other tools that you might use to house your VOD assets.

Leverage VoD insights

As marketers, we often rely on market study 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 anything else.

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

And 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.

Inner source and empower 🤝

Tim O'Reilly coined the term many years ago, and our 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.

The reason I bring this up now is to empower anyone on your team to react to or proactively address VoDs in our products and experiences. For example, if I noticed feedback around a typo on the landing page, I should feel empowered to go and fix the typo and close out the issuer ticket.

If an engineer has a quick fix to a small feature request, they should be able to go in and build what's necessary and ship it.

Improving a developer's productivity or being empathetic to developer needs isn't on one person or function. It's a group effort. You need to have all hands on deck.

Measuring the success of your VoD effort

There are several ways to measure the impact of your VoD efforts:

Qualitative

This is feedback received through support tickets, email or social media.

Quantitative

This encompasses adoption metrics, which can vary from organization to organization. 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.

NPS or net promoter scores

These are calculated when users are asked to rate whether they recommend your company service or product to others.

Internally sourced metrics

This can be support tickets resolved, time to resolution, and even tracking how many improvements were made from user requests. I also like to look at numbers month over month, quarter over quarter to help show the impact of your VoD program.

To wrap up

The key elements of building a two-way feedback loop include:

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

Going forward, I hope you keep developer empathy top of mind in your work, and have confidence that it can be a valuable asset in your organization.

Get developer relations certified and gain hands-on experience with real-world DevRel strategies and frameworks, lead successful initiatives, and stand out in the industry with expertise that makes you an invaluable asset to any developer-focused org.