The Community Club

loading...
Cover image for Pillars of a solid Developer Feedback Program

Pillars of a solid Developer Feedback Program

tessak22 profile image Tessa Kriesel Originally published at thedevelopermindset.com on ・3 min read

Obtaining feedback from developers to better your product offering is a must.

If you're new to my blog, subscribe to receive updates around future pieces to build a robust Developer Feedback Program.

Developer-driven Decisions

It’s imperative that products are making educated decisions as they grow and evolve their offering. Each and every decision should be guided by your external developer community, both paid and free customers. Often times we think we know what is best for our users because we focus on it day over day. Developers who use your product day over day know a lot more about your product than you ever will. They will know tips & workarounds used to make exceptions for your products fallbacks.

The Right Platform & Tools

You need to ensure that you're engaging and communicating with developers in platforms and using tools that you're focused on growing engagement within. What does that mean? Don't not start a giant email chain with a group of developers and ask them individually to share what they think. Drive them towards your feedback or community platforms to complete these conversations, in hopes that after the feedback is complete, they will continue to provide value in these spaces.

Start a Conversation

When you put a group of developers together, they can accomplish a lot more than they can alone. The same goes for feedback. You will receive the most honest, detailed feedback if you start a conversation with the group together. Creating a forum category (or similar experience that aligns with your community platforms), inviting the entire group, and posing the feedback needs to the group will allow for a more conversational feedback loop. Ever watch a tabs vs spaces conversation among developers? We want this passion. We want to tap into their opinions and expose them and dive deep for the big and small details around improving your product.

Communication Style

Developers can see through your trickery. It’s important that developers know that you truly value their feedback and involvement. If any part of your communications seem selfish, sales or marketing driven, or lack compassion for their needs, you’ll fail. Developers give back when they know the other party is willing to do the same.

See Building Trust Model to think about how to initiate engagement with a developer.

Continued Engagement

Once you are able to bring a developer into a feedback loop of any kind, it’s important that you continue to engage and amplify that developer. If they have helped you, by providing invaluable feedback, you need to return the favor and continue to provide value to them.

Thank Contributors

Provide some type of a value to the developers that help grow and better your product. Depending on your company size and following, a social shoutout could be incredibly valuable and an easy task for your company to complete. My recommendation is to include thank you's in your changelog or release notes. These are content pieces that will be around for a long time and my naming those that helped with that release will allow for continued trust with that developer because you're giving them credit for their work.

Your product should be guided by developer-driven decisions, with a feedback program using the right tools to solicit feedback, ensuring developers can share their opinions in a place that allows for continued engagement, and ensuring credit is given to those who contribute.

Discussion (2)

pic
Editor guide
Collapse
mac profile image
Mac

I feel like a lot of this applies to community feedback in general, not just developer communities. What do you think the biggest difference and nuance between a general community and developer community feedback program?

Collapse
tessak22 profile image
Tessa Kriesel Author

I have only worked in developer communities, being a developer myself it's my passion place. I can imagine that it should/would be very similar though, as you said. I think the key difference with developers is their mindset. They tend to not trust anyone unless... a) you're a developer, b) they already know you, c) they see that another developer trusts you and they trust them. Which is where my Building Trust Model part comes in. That first engagement with a developer is so key to obtain their attention. Non-developers are a bit easier to engage with and begin engagement with. Developers are also crazy passionate (tabs vs spaces) and not to say that others are not, but when you hit a pain point with a developer they're bound to give you ALLLLLLLL the opinions they have in this area—providing the most actionable feedback.