Connecting dev rel and product
Bear Douglas highlights the best ways to use that feedback to support your company’s product roadmap and broader strategy.
Last updated
Was this helpful?
Bear Douglas highlights the best ways to use that feedback to support your company’s product roadmap and broader strategy.
Last updated
Was this helpful?
Communicate Consistently
Finding channels that work
Assigning somebody from the DevRel team to show up to stand-ups.
You’ll always have people’s ear when you’re there with them in person.
Giving context in the moment
Bring good or neutral news as often as bad news.
Get your developers to come and do a brown bag with people who are building your platform.
Be both Filter and Funnel
Dig deeper on customer requests
Communication is key
People might want things fixed now.
They think that you might have infinite engineering capacity.
Communicating back with customers.
Close the loop
Be transparent about the feature status
Show internal teams their impact
It’s always an ongoing process and it’s different as teams grow.
It’s different as you get new leadership.
Every company you’re going to be working at is slightly different.
Be consistent about your communication, and that means finding new channels always, that work, the more that you can be what they consider an effective filter and funnel of information.
Make sure that you’re closing the loop with both your end customers and your product managers, that’s when people will really understand what dev advocacy is and how it fits into the production process.
You are the reliable transmitter of information feedback at scale, qualitative feedback at scale.
One of the key differentiators is what you’re doing to bring back developer feedback into your product.
How are you really advocating for their needs, their requests as it gets baked into your product process?
James Ward called out in a great talk called “The Seven Deadly Sins of Developer Evangelism” is a bridge to nowhere.
Evangelists talk to a lot of people day in and day out.
Can be really hard to take the time and consolidate that feedback and make sure that it gets heard, but that is the crux of what we do.
You have to establish with people what you do and what exactly your role is.
There’s a lot of work to be done especially as you’re in a larger company just establishing who on earth you are and why you have any credibility talking about what your customers and what your developers want.
Secret step one – is the legwork of giving people inside your company context on who you are and why you’re saying all these things.
Creating a consistent cadence of feedback so the product teams know that you’re going to be coming to them and they know that you’re going to have something valuable to say.
Finding channels that work
These will change as your company grows.
They’ll change as teams grow
they’ll change based on team preference.
Assigning somebody from the DevRel team to show up to stand-ups.
You can weigh in on feedback because you’re there in person.
You’ll always have people’s ear when you’re there with them in person.
Giving context in the moment
It’s easy to engage in that conversation rather than it just being a one-line piece of non-contextualized feedback.
Bring good or neutral news as often as bad news.
Don’t have to be happy sunshine all the time especially if it’s a lie, but ….
Positive to neutral news is just as important as bad news and information about what’s broken.
Get your developers to come and do a brown bag with people who are building your platform.
Make the first one good, vet that first speaker because if you gather an engineering team together and they come and they get great insight from this developer, they’re much more likely to come back in the future.
How do you be both a good filter and a funnel?
Why do you want feature x? What are you trying to do with it?
And once you get past the solution that they’re asking for and to the need -- share with the product manager.
People might want things fixed now.
They always want things fixed now because they don’t have to face the trade-offs.
They think that you might have infinite engineering capacity.
Like you’re a big company, you’re a big name, so how many people are working on your API, like 50, 60?
You can probably fix this in a matter of days.
Communicating back with customers.
Being transparent about what your trade-offs are will give them much more leeway to be patient with you.
Important, both the people who are giving you feedback and the people to who you’re sending feedback to.
Be transparent about the feature status
Have conversations transparently with your developers.
Incredibly valuable both for your product team and for your devs getting an understanding of markets and problems being addressed.
Show internal teams their impact
Happy news for people to see the impact that they’ve had on other people.
One or two slides at the beginning of meetups that talked about how we were keeping customers happy and excited.
How are we keeping customers both happy and excited?