Made by
Made by
Slack’s head of developer relations, Bear Douglas, has learned a lot about how to communicate developer feedback effectively. In her talk from DevXCon San Francisco 2018, she highlights the best ways to use that feedback to support your company’s product roadmap and broader strategy.
Hi, I’m Bear. In the past I led the developer relations team for mobile over at Twitter where we ran a product called Fabric and also for the Twitter data product called Gnip. In previous lives before that, I was at Facebook and then at also smaller startups.
Matt Asay, who’s going to be talking later today from Adobe, and I were at a 10 to, later, 30-person start-up together back in 2011. So I’ve been doing developer relations throughout that time at companies of various sizes. And at each of those companies, we’ve had different relationships with the product team.
Sometimes the working relationship has been really good, highly functional, and then other times, not so much. So there’s a lot that I’ve learned about how to communicate with product teams effectively and how you have to change up your strategy as your company size grows and also as you’re working out different products.
So, Phil, who’s organizing today and you might see him floating around, and wrote this great post and an interactive tool to help you figure out whether you’re doing dev evangelism or dev advocacy. And 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? So it’s something that we consider pretty critical at Slack as part of being the DevRel team. And if you’re doing dev advocacy at all, you might know that that’s an important thing.
When we’re doing all of this work, one of the cardinal sins that James Ward called out in a great talk called “The Seven Deadly Sins of Developer Evangelism” is being a bridge to nowhere. We talk to a lot of people day in and day out, and at the end of the day, it 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.
It’s very easy to just hear feedback and know it in your own head and then not share it out. So there’s some practical strategies for doing it well. And some of you might be working with product teams who have this as their motto. They try to be future thinking. They’re predicting future needs. And when you talk to customers, what you get is their problems today and not their problems that they need to be solving tomorrow. No perspective on what it is that they truly need.
And that’s not necessarily all product teams. A lot of products teams understand the importance of current customer feedback. But this is something that you might have to battle when you’re coming to people with feedback from this day about what people want out in the field right now.
So what can you do about it? First of all, you have to establish with people what you do and what exactly your role is. In a lot of companies, even companies that have established developer relations teams, it’s still a little bit fuzzy.
“So you guys write docs and you go out and talk at conferences. So you’re just going out and talking to people, right. Are you in marketing?” “Well, no, not really.” “Well, are you in product, you’re trying to make recommendations here?” 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.
Step one – 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. Great, so how do you actually do that? The first thing that I found helped is 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.
The first thing, and this is probably challenging in any company I’ve been at, is finding channels that work because these will change as our company grows. They’ll change as teams grow and they’ll change based on team preference. So I’ve worked at companies where it was not only perfectly acceptable, but expected that you @here people every time you got a piece of customer feedback.
So you can imagine that in a company of more than, say, 15 people, that would get very noisy very fast, and very annoying, but at that one company that I was at, they valued every single piece so much that they wanted the @here.
So, great, work with that. At other companies I’ve been at, we wanted a weekly roll-up from the support team, from the DevRel team about what we were hearing in the field. And that worked for a little while, but one of the things that we had was a top five issues from developers this week and because that remained static more or less week-on-week, readership dropped off sharply after about a month.
So that worked for a little while, but then we had to find something new. Something that I found works relatively consistently is assigning somebody from the DevRel team to show up to stand-ups. Because whatever is being talked about at that stand-up, whatever is the sprint topic, if you have feedback, you know it in your head and you can weigh in because you’re there in person.
That’s something that is relatively scalable as you’ve got a developer relations team that might be able to go to all those stand-ups. And that’s something that I found really helps because nobody stops going to their team stand-up. You have to go to the team stand-up and then you’ll always have people’s ear when you’re there with them in person.
It’s also valuable because you can give context in the moment, so if you’re bringing something up and people have follow-on questions, it’s easy to engage in that conversation rather than it just being a one-line piece of non-contextualized feedback.
This one is also really important. I had a colleague of mine tell me a story about a person who led the support team at their company who people would literally run away from because if that person was approaching you, it meant that they were about to throw a bomb on your day.
Something was super broken, they had complaints, and was only going to be bad news. And when you’ve developed that rapport with a product team that you are always the bearer of bad news, they want to go to la-la-la-la, or run away, or just not interact.
And I’m not saying you 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. So an example of neutral and interesting news is, at Slack, we have a lot of developers who are interested in building radio buttons into messages that they send inside Slack channels.
And that’s not something that we offer, but we saw with the people were hacking our attachments to create an image with a selected state so whenever somebody clicked a button, they replaced the attachment to show the selected state and the unselected state on the other button. So that’s something that we can take to our team and say, “Here’s an observation that we have about ways that people are hacking our existing platform,” as a kind of implicit feature request.
It’s not positive news, it’s not negative news, but it’s interesting, and it’s good feedback. And when people realise that you’re giving them color, you’re giving them context that they might not get from just looking at an analytics dashboard, that’s when they acclimate to the idea that you’re bringing them something extra, something that they really need.
You can only do so much bringing this information to people yourself. It’s really important to get the product team out with you. If you can bring them to a user conference, get them out in front of people. If you can’t get them out of the office, I found it really powerful to bring developers into the office.
This is something we do at Slack. It’s something I know that Twilio does, the Heroku does. Get your developers to come and do a brown bag with people who are building your platform. There is some pressure, 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.
If the first one was terrible, the next time you put it on somebody’s calendars, people are going to ask each other, “Ooh, did you go to the last one? Was it any good? Oh, no? Okay, I can skip it?” And that’s always a disappointing experience because your developer shows up and they’re 15 people in the audience when your engineering team is like a hundred.
So, getting people out and about with you is always Is always really helpful for them. I found that the places that have the best developer empathy are ones where engineers or sometimes even the founders started off doing support on a regular rotation. And that is something that bleeds out into product process for long periods of time.
But you can’t always be there from the beginning to set that DNA, so how do you course correct? Get people out there with you. When you’re giving people all of this feedback, it’s important not to just be the fire-hose because you get the fire-hose every day, you know how much information that is. And sometimes it’s super useful. Sometimes it’s just a lot of edge cases that you’re playing whack-a-mole with that you can’t make a pattern out of.
So how do you be both a good filter and a funnel? First thing that I always try to do is put on my product manager hat when I’m getting customer feedback and dig deeper on what it is that they’re trying to get at. So someone might come to you and say, “This is really broken and I want feature x.” I was like, “Okay, well, 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, that’s something that you can share with the product manager. You can say, “Here’s the customer need. It really is literally our job to figure out how to address that need, but I’m hearing about these different needs rather than just the proposed solution.”
This is also something that I’ve forgotten to do a few times. You know, when you get people coming to you and they say, “Hey, this thing is broken,” and sometimes your reflex is just to post it in a channel and say, “Hey, do we know of any known issues right now with notifications?” With no context, just be like: “People are telling me this is broken right now.”
It’s important to take the time and, as much as you can, give details. Press back on customers and developers to get all the context you have on what’s going on with a bug. Any sort of stack trace you can get. A quick poll of the room. How many of you do developer support as part of developer relations? Okay. Looks like it’s about a third, about half.
And that’s a big component of when you’re doing dev support, as part of your job, getting that bug information in a packaged way that you can send to the product team. And the more that you spend time doing this, the better result you can get.
This part is always hard. When you have people coming up to you every single day saying, “This is really important, my product is broken until you can fix this one API. Like, my business is going down the drain because you all have been punting on fixing this issue for six weeks.”
It’s really hard to hear that feedback and not immediately go to your product team and say, “We have to fix this. People’s businesses are going down the toilet.” What is hard to do, but is always important to get, credibility with your product team is really keeping perspective on urgency. People might want things fixed now. They always want things fixed now because they don’t have to face the trade-offs that you do.
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.
So communicating both back with customers and being transparent about what your trade-offs are will give them much more leeway to be patient with you and understand the trade-offs you’re making so that you can address their problems with an appropriate level of urgency.
Closing the loop is always important, too. This is for both the people who are giving you feedback and the people who you’re sending feedback to. So things that we’ve experimented with lately at Slack has been an open roadmap feedback session that we’ve done at our developer events, first at an event last summer that was about a hundred people. And just now at our developer conference back, which was about 400, 500.
We print out our roadmap for platform, which we are very lucky to have open source already on Trello so that anyone can look it up at any time. But we printed out a giant physical wall with it and gave people stickers that they could use to upload or download features that were on our roadmap. So, it’s a pretty cool idea.
In principle, there are a couple of things that needed work to make it actually actionable. So the first thing is that we had to have staff at it at all times You can’t get context-free feedback, a plus one is no better than you’d be able to get online. So we had a product manager standing there at all times.
What one of our PMs, Armand, did that was great, was he made people, for every three green stickers they put up on that wall, put on a red sticker. Because he said, “You know what, it’s great. You want all the things. We want to give you all the things, but as a team, we have to make trade-offs. So give me context about what’s truly important to you and if you had to make a trade-off, what would you cut on this map to make it possible to get the things that you want?”
And so by having that interaction with people, they got to dig a little bit deeper and understand what was truly urgent for people, what was a nice to have, and to get a little bit more at the why of what they were choosing. Another thing that was an interesting fallout of this map is that for the sake of being flexible enough to be public, some of the language on our roadmap was a little bit vague.
We would say things like, “A better way to send content from Slack messages to apps.” And we launched a product called App Actions two weeks ago which was the actual incarnation of what that message was. But when people approached the board, they didn’t necessarily make the connection that what we had just put on that card was the thing we had just launched.
So we got a lot of upvotes for shipping that, which was good. I went like, “We shipped that today.” And another thing that people sometimes didn’t understand was what we meant when we said things like, API.Slack.com redesign. People said, “Well, it’s working fine for me, so I’m going to download that. If you’re making me put down a red sticker, like, I’ve got your information as much as I need.”
And what the product teams did with them is talk to them like, “Great. You’re here because you can read our API docs, but that’s still on our roadmap because there’s a non-addressed market that’s coming to our API site and still getting confused.”
So this moment where we had that conversation transparently with our developers was incredibly valuable both for our product team and for our devs getting an understanding of where we’re coming from with the markets that we’re trying to address. So very powerful exercise, but I also recognize that it hinges upon the fact that we had an open roadmap in the first place.
To the extent that you can, getting to that point where you have an open-ish roadmap is super, super valuable. Maybe it’s just in Vegas terms, like here’s a product and an existing bug that we know we’re going to fix in three months or in the next quarter, in the next half. The more you can have that honest conversation, the more free you are as a developer relations person to have the authentic conversation that builds trust with your external devs.
And also the more that you can really have your product team start to commit to making things public and making things accessible and promised to developers in a way where they feel accountable. Because nobody gets into developer products because they’re here to screw over developers. Everyone is in it because we have a common group that we’re trying to serve.
So give your product teams some credit, but work with them to think about how transparent can we be. Maybe it has to be a little bit vague. Maybe it has to be vague on the timing, but there’s probably something that we can talk about. So the way that we’ve done it and the way that Twitter has followed suit, as well, is by putting it out on a Trello roadmap.
You’ll see here that our freezing is not super descriptive. We’ll say things like “new display types” and that ended up being the launch of a brand new way to create attachments inside Slack. It’s brand new framework for UI. So it’s a lot more exciting and sexy than what we put on that card there, but this is something that we can commit to and that we update quarter on quarter.
And we’ve gotten feedback about that. People say like, “You know, you’re only updating it every quarter that’s not enough for me to really build my business on,” which is interesting feedback. Ideally, you wouldn’t want your roadmap to change so much month on month that you would need to update it that frequently, but we are still trying to find the correct balance between how transparent to be so that we’re still being honest and giving developers enough feedback that they can have enough information that they can really plan off.
It’s always happy news for people to see the impact that they’ve had on other people. A great practice that we had on the Fabric team was every week, we would have a kickoff where we talked about what we were going to do that week, but we also had one or two slides at the beginning that talked about how we were keeping customers happy and excited. That was a goal that we had every single week. How are we keeping customers both happy and excited?
And we would always share tweets. Things that we were hearing from people. There’s always at least something to share whether it was feedback from a support channel, whether it was love on Twitter, whether it was something that we heard at conferences. And just having this stream of a way to make your engineers and product managers understand they’re having real impact on people’s working lives or consumers working lives is a way to keep everybody engaged and excited about hearing feedback in general.
So the things that I found worked, and 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. But the more you can 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.
And the more than you can 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 product process.
You are the reliable transmitter of information feedback at scale, qualitative feedback at scale. Getting the little bits that they can’t possibly capture with analytics alone. And that’s when I found that working with product teams really gets productive. I think I have like three minutes so I can take a question or two. Yeah.
Audience member 1: Getting feedback into deciding which ones to push with product. I’m doing it based on the amount of money that someone pays the company or the amount of potential money. And I just was wondering if you had any suggestions on how to prioritize on some other way or.
Bear: Yeah. Sometimes what’s helpful is community size and projected future impact. So, there’s money today and then there’s also money tomorrow. The way that you can figure out money tomorrow is if there’s like a critical bug in a language that you know is going to be important for a new market that you’re trying to unlock.
Like, let’s you’re going after .NET developers and you don’t have a .NET SDK and then you build one and then it’s got this critical bug. You can kind of extrapolate that into here’s the total addressable market. It’s a lot of extra math, but you can think about the multiple of, whoever’s writing in to you with a problem, there at least 20 other people who have not written in to you with the same problem and try and figure out patterns based on that. Yeah.
Audience member 2: Thanks. Perhaps you could help me in persuading people I work with to expose the roadmap because that’s something I’ve been dying to do. And usually, the main argument against it is, I don’t know if you’ve heard this, but sometimes people miss deadlines in software projects.
Bear: What?
Audience member 2: And they don’t want to lose users’ trust by missing deadlines for something we’ll say is going to be ready on Q3 and it ends up being ready on Q7.
Bear: I haven’t ever even heard of Q7. Yeah. So what we do, and we still try to keep ourselves tied to general timelines here, but we have the near-term, the midterm, and the long-term. And the long-term we treat practically as an icebox. I think we’re pretty transparent about that in the “about this roadmap” section.
Long-term is like this is something that is on our mind, but we don’t actually have it resourced yet. So things that have sat there for a long time are things like a payments API. In fact, I think that only recently fell off the long-term roadmap because it’s something that we’ve been talking about, but we were pretty transparent with developers was not a top priority right now.
For the near-term stuff, they’re sort of in the immediate next two quarters. But we have yet to come by anything slipping a little bit. In the event that we have had something on there for a long time that people are asking us about, we do try to just be communicative about it. Say, like, “Yes, we know this has been on our medium-term roadmap for a little while, here’s where our thinking is.”
To the extent that you can de-risk it by being a little bit vague in your language. Like I said before, the new display types was actually a UI framework. And we didn’t leak the fact that we were working on a UI framework. We just said, “new display types,” and that’s true.
So there are ways that with language and with being slightly vague, but still accountable on your timelines, you can de-risk it, so it’s not like, “You missed this deadline by a week. You’re terrible, we hate you.” It’s more like, you know, we all understand, we all work on software, we know there’s delays here and there.”
Audience member 3: Hi, so for…a lot of our engineers are sourced from our developers, which is usually really cool, except they now think they know better than all of the people who are still developing on our platform. Do you have any suggestions to help remind them that they are not all of the developers, that there are other developers we have to listen to?
Bear: Yeah, that’s when anec-data becomes something where you think it’s more powerful than your analytics. I find that in those cases, anything that you can show that’s actually large-scale analytics data about how developers are behaving on your platform is the best way to combat that.
When I was working at Facebook, you can imagine everyone, because they have their own experience of using Facebook, think that everyone else uses Facebook just like they do. And you can get blind to it really easily. But the best way you can combat that is by showing information that says, “Well, actually, no, a lot of people are using it in xyz way. And, you know, in this country, Facebook is more like LinkedIn, did you know that?” So combat anec-data with analytics is my usual tactic.