Made by
Made by
October 10, 2017
zen-stones-on-beach
By the nature of their role, a developer relations team will spend much of their time working externally to their company. Unfortunately, this can mean that their voice isn’t heard internally as much as they’d like. The result of this is that vital customer opinion captured on their expeditions doesn’t always get treated the way they’d hope once it’s fed back to basecamp.
Matt Bernier
SendGrid’s Matt Bernier, who has traversed his way from dev rel to fully fledged Developer Experience Product Manager, has experienced first hand the frustrations this can cause for the people on both sides. He’ll be exploring the intersection of Dev Rel and product management in depth in his talk at DevRelCon London.
Ahead of the event, Matt’s given us five carefully chosen tips for dev rel teams to work better with their product managers, and make sure that all important user data is heard and understood.
Make sure you’re diligent in tracking everything about a customer interaction. Who you talk to, what their account is, where you met, and any specific notes you get from them. You’ll have your usual conversation and hopefully make a friend (useful for you) but you’ll also have notes of what you said (which is very useful indeed for people back at your company). Knowing where you were when you talked to a customer also helps you to then follow up with them later.
Having a CRM to put your notes in and share a contact with people can be very helpful for logging and accessing this information. It gives everybody a single place to go, and makes it easy to run reports and archive information. This makes it a lot easier to not step on your sales team’s toes. It also makes it easier to keep them informed too when you’re bouncing around from place to place.
You never know when you’ll happen to run into a developer that is at a company directly within the sights of a sales team. You may have some information that might really help with a deal. Or, you might be able to give that developer some information that helps them be an advocate for you. So, it’s really important to make sure that the sales team knows that you have been talking to them.
Naturally, people working within sales will have different motivations and needs than people in a product team. This can result in feedback like; “This guy was super cool. I would like to get them in touch with our Accelerate Program,” turning into “Let’s close the deal!” once it passes through the funnel. Being able to take verbatim quotes from the customer side – both positive and negative – can help to fix this problem. It will also tell the product team more about what that customer needs than your interpretation of what they said. It gives a certain amount of context that can then be followed up on and dug into later by the product team.
Having a note taker also means you’ll know whether you and your product management team are talking about the same thing. “We’re both talking about how to manage unsubscribes, but I’m talking about this thing and you’re talking about that thing.” They are related, but they are not the same. And one of them might be really, really profitable and the other one may not be.
In Dev Rel, your job is to go out and be with developers. You’ll feel what they feel about the software, and then communicate that back to your company. The danger is that by empathising so strongly with the customer, you’ll then be taking their perspective and priorities back to the company. This can put you out of kilter with the internal steer of your organisation. From their side, you can come to be seen as somebody who yells a lot, or who is obnoxious about one particular sticking point.
Fortunately, there is a workaround for this. By churning user passion into actual data, Dev Rel teams will be able to walk into a meeting and say; “Here are 50 customers, with their contact information and their quotes. And this is really important.” It tends to land a lot better than just anecdotally sharing; “A bunch of people think this feature totally sucks!” Matt and his team use the RICE prioritisation framework to help them do this. On the customer side, they are able to log how many people a certain issue might touch, and what the impact might be. This means internal conversations become objective, rather than subjective. The upshot of this is that it’s a lot easier for people to understand what Dev Rel teams are saying, why they’re saying it, and then take action on it.
Once you’ve got your tracking processes established, the next step is to make dashboards. Find a way to put your information together in a graph, and a spreadsheet, and a way that you can visualize the impact of what you are doing. Whether that’s in the form of those customer quotes, the number of projects influenced, or the names of people that you talk to, all of these things are really important. And it will give context to the rest of the company as to where you were, why you were there, and what the company got out of it. All of this can be really helpful for people who weren’t in your meetings.
Although it can sometimes feel like an overwhelming deluge of information to work through, spending time wisely in the open source community is really important for understanding what customers want. You’ll need to be objective when you do this, and avoid reacting and taking things personally. Take the time to really understand problems, and offer considered advice. By engaging people, and showing them that you care, you’ll get a deeper understanding of the impact of what your company is doing in open source, and be a much better conduit to relay what you’ve learnt back to the product team.
Taking the time to learn what a product team is working on next quarter can reap dividends down the line. Try to understand what’s in their backlog, and what their upcoming plan of action is. You can then use this to inform your customer interviews, making them richer and more aligned to the objectives of the product team. Having this targeted customer feedback available before they start work is incredibly useful to product managers. It makes them more efficient, and helps them to validate whether their course of action is the correct one. It also means they’ll be working on things that will really be useful to the customer, making the job of the evangelist much easier down the line.
Matt is speaking on this subject at DevRelCon London on December 6th. Get your tickets today >
Zen stones picture, CC0 licensed. Matt Bernier photo supplied by Matt.