Throughout my career, I've learned a lot about the long game of product feedback – it's not about quick wins but sustained effort.
Today, I want to share some key lessons and insights to help you build credibility and turn your community into fanatics. We'll explore the foundational steps for anyone looking to create a feedback program, and I'll sprinkle in a few tips I've uncovered along the way.
Product feedback is vital, but it's a process that requires patience and commitment. By involving the right people, understanding your audience, and being open to feedback (even the harshest kinds), you can elevate both your product and your brand.
Let’s dive in.
The developer persona: Top things to keep in mind
There are a few things to keep in mind about developers as a persona.
Firstly, they have really high expectations for the companies that they engage with. Companies have learned that working with the folks that are building with your company to provide them with a strong experience is a really beneficial partnership for both parties.
So, they've really worked to improve that experience, and that's given developers a really high set of expectations for the companies that they're building with. That's not a bad thing at all, it's just something for us to note as we go forward with how we gather and collect feedback.
They also have a high degree of influence in sales and technology decisions. This is something that's often overlooked because they're not a persona we traditionally think about being at the sales table, but they make a lot of those technology decisions and oftentimes it's based off of that development experience.
In their opinion, this holds a lot of weight to the folks that are sitting at that sales table.
They also prefer to self-serve first. When they come to you, they're going to try to get as far as they possibly can in their development journey or their buying journey before they ever engage with anyone. That's just a good thing to keep in mind.
And lastly, they’re a very direct set of folks and they’re not shy when it comes to feedback. I’ve encountered feedback on a very regular basis at every company I've ever worked for.
Some folks might look at the tweet below and get a little bit scared or nervous because it could come off as really negative:
They very clearly outline the anxiety that it's causing them, and they give us a recommendation of how to improve it: ‘Make it appear by default. Make it easier to find.’
I look at something like this and am really thankful that they took the time to share this with us because it gives us an opportunity to improve a subpar experience that we might not have known about otherwise.
All feedback, even when it's really direct, is a good thing. Take that directness with a grain of salt as you're going through this and really see the positives that come through.
Who should be involved in the product feedback cycle?
Let's talk a little bit about who should be involved in the product feedback cycle because it's probably more than you might have originally thought.
First and foremost is product management, and they get a big gold star here because product feedback is something that they need to own and have a really large stake in. They’re the folks that are going to ensure that the company's committing resources to those community sourced requests, so they have to be on board with a program like this.
They're also going to be the ones that are scoping the requests, understanding what it would take to implement, and doing things like prioritizing bug fixes.
You should also be working with your developer evangelism team if you have one. They represent and communicate with the community. So when they're talking to product, they represent your developer community, and when they're talking to the developer community, they're representing your company and your products.
Teresa Garanhel
Because of that, they have strong communication skills and a really deep understanding of your technology and what it means to build with you. They can be a really great bridge between all of the different functions that are involved in this feedback process.
And then there’s developer marketing. Our role here is really around communication and content creation. Whether it's responding to feedback when you get it, that PR aspect of relationship management, or helping to spread the word when feedback’s been implemented and you're communicating that back out to your community, that's something that we’re part of.
And then, of course, content creation. As you're doing that communication, it’s the content that you’re creating and driving as part of that program.
If you have a separate function for product marketing, that's also a group that you're going to want to have involved here. Say you have a technology offering with an API available, they represent that core product.
They need to understand the point of view of the developers building with their product in order to fully represent that product and make sure that all of the assets and materials that they're creating include that strong developer experience.
Maybe you happen to have a product marketer that’s specific to your developer experience. Maybe they own your APIs or your platform company and they’re responsible for product marketing for your platform.
Jordan Schuetz
Obviously that's someone that's going to be really closely tied in with this entire group, and they also need to have a really strong point of view of how people are reacting to your products and what sort of feedback you’re all collecting.
They should also be involved in that content creation process as they have that deep understanding of the product that you're talking about.
Your technical documentation team should also be involved. You're probably going to find that your documentation gets just as much feedback as any product functionality does, just because of how inherent your documentation is to the entire developer experience.
Those folks that maintain that documentation need to be really involved in this process and implementing that feedback as you get it.
Teresa Garanhel
Your technical support team should be involved as well. They’re on the front lines and helping customers solve their challenges, so they’re a really great source for surfacing some of those common issues as well as communicating back with customers about what's happening.
As you can imagine, that's a really large group of people with a really big breadth of responsibility at a company. And a big part of that is because when you're managing a developer program, the types of feedback that you probably get are going to be more than what you were initially thinking of.
Categorizing the different types of feedback
We often think about product feedback for things like feature enhancements or requests, any bug fixes that might come in, bug reports that you get from your community, as well as innovative direction. What are things that might be new problems that your customers need to solve?
That's what we traditionally think of.
But, when you’re managing a developer offering, your documentation is just as much a part of your product as the actual technology itself. So, you're probably going to see types of feedback and things about wording choices.
Are you using industry terms or brand terms for certain pieces in your documentation? Is the structure something that's really easy to follow for your code samples? Is there clarity in the language that you're using around a particular go live scenario? Is it really clear what you're asking them to do or what the right next step is?
Is the navigation between your documentation simple? Does it make sense going from one area to the next? Do they know where they need to go?
Those are all the types of feedback that you'll see there.
For our developer marketing and developer evangelism folks, we also get feedback on our programs. Oftentimes, the relationship engagement when you're working with a developer spans a really long period of time. It's possible that they're going to be engaging with one or more of your programs during that development process.
The types of feedback that you can expect would be things like the timing of your program or communication and how it relates to their journey locations. Is there a physical meetup that they want to request that you add to your local meetup tours?
Teresa Garanhel
Or with the technology that you might be using to facilitate your virtual events, they might have feedback around that experience that you're providing.
And then, of course, swag. Developers love their swag, so you're probably going to get a lot of positive feedback about your swag, but sometimes negative as well, or a request for different types of swag that they might want to see.
So, you really have to expand the way that you think about feedback and the types of feedback that you should be looking out for.
Top places to source feedback from
Speaking of expanding how we're thinking about this, I also wanted to provide some basic places to source feedback from. Oftentimes, when we think about product feedback, we think about what's submitted to our product team or what’s submitted to a sales rep that's a little bit more formal.
But there's a really large opportunity to collect feedback from all types of sources.
Gathering feedback from social media
If you have developer marketing at your company or you're really committed to going after a developer community, you're going to have separate profiles for your developers across things like Facebook, LinkedIn, Twitter, and YouTube.
We get a lot of informal feedback on our social media channels, particularly on our YouTube channel. We get a lot of comments on our videos, which is phenomenal. That's been a really great source of feedback for us.
You're also going to see feedback on forums like Stack Overflow, Reddit, and GitHub, where you're often going to get a lot of technical questions. You should also be looking for those feedback nuggets that you're going to receive as they're reacting to answers or challenges that might have cropped up. That can be a really great place to take a look at what feedback you might be looking to implement.
Melodi Kaya
Gathering feedback via your own web properties and products
Of course, look at your own web properties and in-product opportunities.
DocuSign implemented page-specific feedback. If you're in the guides or a particular code example, at the bottom, you can give five stars out of five if they've earned it, and then there’s a little box for qualitative feedback. That can be a really strong source of feedback that they experience, not only for their documentation but also for the product itself.
Inside your demo environment, you might have the opportunity to leverage things like notifications or promotion banners. Keep a look out for that where you can proactively ask for some of that feedback.
Gathering feedback via customer support
When you're receiving support tickets and customers are reacting to some of the challenges that they're facing, that's a really good opportunity to source some feedback and some possible solutions.
Using social listening tools for feedback
You should also be looking at digital listing tools or what are often referred to as social listening tools. This can be a really valuable way to see what conversations are happening that you're not tagged in.
When you get proactive feedback on your social media, they're tagging you or sending it to you directly. They intend for you to see that. But there's also a lot of passive feedback that happens online. You can use tools that use Boolean search queries to hone in on the types of conversations that are being said about your APIs, for example, and understand if what they’re saying is negative or positive.
That can be a really, really valuable way to understand what types of things people are highlighting when they're not necessarily coming to you out of that moment of desperation when they've made that decision to tell your company how they feel.
Getting feedback from customer advisory boards
And then if you're looking for something much more in-depth, you have the opportunity for things like customer advisory boards or technical advisory boards. Oftentimes, this is a program run by marketers, but it can also be run by product or developer evangelism.
I've seen it done in a lot of different ways, but marketing has a skill set around programs that can be really valuable to something like this, making it a little bit more of a formal program.
They operate like forums or a focus group type scenario where you have a group of people who’ve committed to your company. They want to give you feedback on your technology and work together to solve some solutions that are common in your industry.
This is a really beneficial way to get deep product feedback. That’s something that I encourage every company to explore.
Ewan Maalerud
Pay attention to developers' questions
I think there's also a really large opportunity to not overlook questions as feedback. One thing we know about developers is that they do like to self-serve, so if they're coming to you with a question, that means they probably weren't able to find that answer simply or easily on their own.
Take that question as an opportunity for feedback and ask yourself how you could improve the experience so that this wasn't something they had to come to you with. If they couldn't find it, it's probably an indication that something wasn't simple enough to find or understand and could be improved. That's an important thing not to overlook as well.
Pulse-checking on where you’re at
Now let's take a quick pulse check in on where you're at. I’ve tried to boil this down to four major steps: gather the feedback, implement the feedback, communicate that feedback back to your community, and measure the impact of your program.
Gather feedback
This is something that should really be thought of as cyclical. It's a never-ending process. But a lot of what we've talked about today is, Are you already receiving this feedback? How do you collect it? How do you gather it?
But, sometimes, you're at a place where you're not actively receiving that feedback from your community yet, and you need to inspire. You need a prompt.
A few simple things that we can do that's within scope and control of marketing are things like asking for it on social media. If you have those profiles where you're able to engage directly with your developer community, ask them. Be active and be hyper responsive. It's going to grow over time as you build credibility with your industry as a responsive company.
When I first started with DocuSign, in my first 6 to 8 months, we weren't getting a lot of feedback. And that was something that I really wanted to change, so I became really responsive and started ensuring that we responded to every message. I know that seems simple, but it's important to be really diligent about it, and it does grow over time.
That's a really great way to develop that two-way communication with your community.
Michael Francisco
You can add it as a call to action in your blogs and emails. Really think of it as ingrained within your communication and that journey that a developer’s going to have with you so they also think beyond your blogs and emails. But it’s important to have an area where people can go and submit feedback.
Similarly, leverage those in-product communication tools like I mentioned. If you have notification centers or the ability to display promotion banners in either your demo environment or your production environment, or if you have the ability to target based on job role or something like that, in-product communications can also be a really great way to gather feedback.
Implement feedback
Perhaps the most important step of this whole journey is implementing that feedback, which is where that commitment from product really comes into play. Making sure that your organization is dedicated to implementing that feedback is incredibly important.
This is the step that allows you to really build that brand affinity. So if you take that time to listen to your community, understand their pain points, and unblock what they're asking for from you, you're going to get that brand love. That's where you start to get that Salesforce effect where you get really, really passionate folks that know that you’re invested in them just as much as they're invested in you.
You're also going to increase loyalty. It can take a really long time to build an integration.
If developers are spending a lot of time with your technology, if they have the opportunity to leverage that knowledge either in a future role or in a different team within the same company, if that type of problem comes up again, they're going to be a lot more likely to bring your technology along with them and that historic knowledge, assuming that was a good experience.
If it wasn't a good experience, they’re a lot more likely to give your competitor a try because at that point, what do they have to lose? So, it's a great way to increase that loyalty, as a developer might move between companies.
It’s also an opportunity to grow your recommenders network. That's still one of the most credible ways that any company has to grow their product adoption; colleagues asking colleagues or peers at other companies about the types of ways that they solve their problems. The same is true for developers.
Pulkit Agrawal
When you do that work to really invest in that community and that feedback you're receiving, they know that that's going to be a long-term, credible company that they're going to want to recommend to their peers.
Communicate feedback
And then it's really the role of developer marketing and developer evangelism to work together to get those enhancements communicated back out to your community.
Don't overlook this step. It's really important to hearken back when you announce or release new things, to call back when those things were community sourced. That can be really powerful.
Development cycles can be long. It could take six months to a year to solve a particular problem or address a particular piece of feedback, and people's memories aren’t that long. So, remind them when you go and do that communication for your new releases, and make sure that you tell that story and connect those dots for them.
Link that tweet if it was received in a tweet, link that community forum post if you found it in a community forum. It won’t only be valuable for the folks that submitted the feedback, but for everybody else to see that you're taking feedback seriously and closing that loop.
Measure the impact
And then, of course, measure your impact. This is something that can be done through a number of different ways. You can use a net promoter score or a customer satisfaction score. You can also look at things like community engagement over time.
If you can look at how a community sourced piece of feedback improved these metrics for your company and understand how it's affecting adoption, that can be a really, really powerful tool to use when you're doing planning and looking at resourcing for how much of your work’s going to be community sourced.
As much as you can connect that back in the actual numbers, the better.
Stacey Kruczek
Managing feedback
We've talked a lot about some best practices, some ways of thinking, and the people who need to be involved. Now, let's talk about managing a program. I just want to pass on a couple of best practices that you should be implementing.
Make sure you're collecting all of your feedback in a singular source. This is probably one of the best ways to make sure that all of your stakeholders across the business keep themselves on the same page. Jira can be really great for this. That's what we use. But obviously there are a lot of other tools out there.
This next one is a lesson I learned the hard way. Ensure you have structure for labeling and tagging those sources.
In those first six months that I was at DocuSign and we weren't receiving a lot of feedback, I didn't put a lot of thought into labeling and tagging. But what I learned is that over time, as we were discussing particular customer issues, we had this need to go back and look at how many times we saw this particular issue being reported.
How many different types of feedback did we receive about this particular process?
I didn't have the ability to do that, so we had to go back through some of our tickets and do some auditing. So, save yourself the trouble and do that upfront.
Host a regular monthly meeting with your stakeholders, if you can. I wouldn't do less than quarterly, so definitely try to keep that regular.
In this meeting, you should be looking to read out new insights. All of these different groups are coming together and sometimes it's not always inherent regarding a learning that your technical documentation team might’ve had, and the way that they communicate might impact how your developer evangelist is looking at new content creation, for example.
That can be really important to share out across team members.
Review your previous commits from the program. This is huge to ensure that everybody stays accountable for the program and the work that you're committing to your community. And then review those KPIs and metrics every single month.
Last but not least, don’t skip out on communicating that progress back to your leadership and key stakeholders. This can save you a lot of time. It's something that you don't always understand the importance of until you're not doing it.
Save yourself some of that trouble. Make sure you're regularly communicating that progress back out to leadership because they're making a lot of their decisions based on resourcing and where they could and should be putting their time.
This article is based on Kendall Hershey's talk talk at the virtual Developer Marketing Summit in 2022. You can enjoy the complete presentation – and hundreds of others – with Developer Marketing On Demand.
If you haven't already, join our growing Slack channel to stay on top of the latest in the industry, talk to your peers, and get inspiration for your marketing strategies.
Developer Marketing Alliance
