Bridging the Gap: Improving Communication Between Product Development and Support

Share This

Nothing is more important than your customers, and if you want to keep them around you’re going to have to keep your Product Development and Support teams in sync and make it easy for them to communicate regularly. Sounds easy enough, right? But as many teams have discovered, bridging the gap between Product and Support is actually really difficult. Mercer Smith-Looper joined us at UserConf SF in November and shared how she’s bridging the gap between teams at Wistia and the challenges she’s faced in the process.

What follows is a full transcript of Mercer Smith-Looper’s speech at UserConf SF, “Bridging the Gap: Improving Communication Between Product Development and Support“:

I am Mercer, and this is me, as you can see. I am part of the customer happiness team at Wistia, in Cambridge. There’s four of us here, and it’s pretty exciting. Today I’m going to be talking about bridging the gap–so how we at Wistia procedurally got product and engineering onboard with support processes. Pretty exciting, right? This is something that everyone’s like “Yay!” we’re excited, we’re excited about this, come on!!’

So yeah, this is what I’m going to be talking about, this is Lenny, some of you may be familiar with this awesome adorable dog. I’m going to start with a quick little roleplay, just nod if this is something you’re familiar with. My friend Jordan is gonna come on and help me out with this:

Jordan: I’m an engineer. I’m pretending to be an engineer–so if this is not accurate, I’m sorry.

Mercer: Alright, cool. So I’m just gonna talk this problem through with you so you’re going to work and I’m going to say what’s going on and you’re gonna be like “yeah that sounds familiar!” and you’re going to help me.

Jordan: uh yeah, if that seems good to you.

Mercer: But that sounds good…you can do it right?

Jordan: Oh yeah, we can do that.

So this is something that everyone’s familiar with, right? How many of you have done this, or had something like this happen? Alright, good. Ok. Thank you, good. Yes….I mean not good. Not really good at all. So everyone’s heard “not right now” or “I don’t have enough time” or like “eeeeehhhh” Yeah. It’s a total bummer. So how do we get around that?

This is what it used to look like: I’ve got a really excited like Ace Ventura style customer up there, totally pumped–comes to me and says, “Hey this is my issue” and I’m like alright cool I’ll try to find a way–it’s like a little hard because it’s a tough question and there’s no way to get to Max–Max is going to be the symbol for engineering at Wistia for this presentation–engineering and product are one in the same at Wistia at this point in time.

So how do I get from here to there? Well. I bake. I baked him some cookies. I was like “Here Max, here! Have some cookies! You’re going to help me out now” and he was like “Nahh, these are not super great.” And I’m like, “No, c’mon!” and then he’s like “I wanna go away for the weekend with my wife–You wanna watch my dog?” and I’m like “Yeah I’ll watch your dog. She smells really bad but sure, yeah, totally, let’s do it!” And then he’s like, “Yeah, still really busy–still don’t have time to help, sorry.” And I’m like, “Alright cool, BEER! Everyone loves beer, right?” And he’s like, “Ah well I can’t even drink beer, I’m on this weird diet” and I’m like “Baaahhhh! God Max, you’re ruining my life!” And eventually he’s like “Okay, I see that you’re trying to like bribe me now, I will help. I feel bad kind of. You’re crying in the corner and all of that so, you know not good.”

So why do we go to these lengths? This is something that I think a lot of people have probably gone through, right? So we go to this length because we care. No one would be here in San Francisco if you didn’t give a shit about your customers I hope, right? You guys care, ostensibly, because when you’re talking to the customer everything seems like a huge deal–even if it’s the first person that’s ever come up about it, it’s gonna feel like a huge deal to you and it hurts because it hurts them. So if that’s the case then why is it so hard to communicate that to other teams? Why can’t you just be like “Hey Max, you care about customers, I care about customers, hwah! Awesome, we’re gonna do it together!” not easy. It’s not easy to do. I think at Wistia, at least, there was three reasons why this was super hard:

So there are big shiny new things that people, want, right? “C’mon we need this thing, we’re gonna be real sexy and all these people are gonna be really amped about our product and like that’s really great, we’re excited.” We like new customers, right? But there’s also old customers, they matter. Even if they’re old, boring (which I don’t think they are but some people do, I guess).

Secondarily, tiny teams. This is our engineering team. This is it. Keeping our whole application up with like 100-thousand customers or something like that. That’s insane. I could see why they would not want to take some time to help me with like a Javascript error for one person in like Ohio. No offense to anyone that’s from Ohio. So when I go and am like “Hey Max this really sucks, he’s like ” I am having like a million and one errors with a player right now and I don’t really have the time to talk to you, so goodbye.” It’s a bummer, not fun. but they’re small and I understand.

Lastly, as I already explained, zero process. Absolutely none. No way to get from here to there and it’s like some sort of demented Candyland game. Very unenjoyable, not even like any candy involved, which is like I don’t even really like candy but it would be nice for this, right? So we were like, alright cool, no process. Nothing is happening here.

So we decided we were gonna build something called all hands support. Who here does all hands support or has heard of all hands support before? Yes? Yes yes yes! Get excited, it’s an awesome thing! And if you do it, that’s great. So actually it looks like a few, or maybe a lot of you who already do this, right? Am I understanding that correctly? Yes. Alright, ok.

All Hands Support, is something that we call AHS, and it starts with every individual who works in Wistia–there’s about 30 of us, has one day every single month in the inbox. In the beginning I assigned them like 5 or 6 emails to get their feet wet, get them like encouraged and pumped, right. Cause people are like scared to talk to customers. We do it every day so it’s like psh, whatever it’s fine. But for some people it’s really scary and they’re like “Oh my god I’m gonna ruin this relationship,” and that’s a good thing: so you need to get them prepared and excited and then let them go out in the inbox on their own and answer things and see what the customer is feeling.

This turned our little Candyland game into a like skip go, or like you know when you get the lollipop card and you get to go to the lollipop queen and you get to skip everything, yeah! and that did that, but it was only like once a month. So the customer gets a direct line to Max, but only on that one day and then when that day is done, back to this shit here, not good.

So it was working a little bit, people were like “Awesome I’m really happy I get to talk to customers, I’m pumped that I get to see what’s happening and like understand their pains,” but the engineers and product people were like “Eh not working for me man..it’s not doing it for me really.” No one likes hearing that, it’s not fun, so when I talked to them about this I was like “Guys! explain to me what I need to do to get you excited about this!”

They came up with three main issues that they didn’t like about AHS:

First of all, they didn’t have time. Anyone who’s ever done engineering or ever talked to someone on engineering knows they’ve got a lot of stuff to do and the problems are usually really really broad and hard to fix otherwise we would all be able to fix them. So, when they’re in the inbox for one day they didn’t get the chance to go as deep as they wanted to, they really wanted to find one problem, that’s causing a lot of pain for our customer, go deep, and fix it. They didn’t feel that in the one day that they had, they were gonna be able to do that. So it was demoralizing for them because they really had these grand dreams, they were like, “You’re crushing them, Mercer!” and no one wants to do that, no one wants me to crush their dreams .

Conversely, they had too much time. This is Dave, Dave’s right there. Stand up Dave, turn around, let them see you–yes yes Dave. Um, so they had too much time. Because they are such a small team, for every month of AHS, it was like taking a week of vacation time for the engineering team. As one of the most heavily leaned on teams at Wistia, it was like “Wow that was a lot of time for them to be taken away from what they were expected to do for their jobs.” It’s understandable, again, as a small team keeping up the whole app, I can see that really being a big deal.

Lastly, as we all know. The same issues that might be a really big deal don’t necessarily come up every single day, so with their one day in the inbox, it’s not like they get to see every single problem, or really even get an understanding of what kind of stuff was happening. So what’s the point of them spending time in there if the point is for them to understand the problems and they can’t do that?

Alright, cool yeah, I hear you I hear you engineers, there’s no time. But why can’t you just fix my problem? It sounds really whiny and selfish the way I’m saying it–it’s like “Whyy! Why can’t you just fix it?!” But in this whining period, I came to terms with the fact that it’s not necessarily what engineering can do for you and what engineering can fix for you but what you can both do for your customers. I’m pretty sure JFK said that, I don’t know maybe. I’m just gonna steal it and say I did. We’re all good with that? Ok, yeah Mercer said that.

So we made something called Dev on Point (DOP). Dev on Point was a different version of All Hands Support in that it was specifically developer and engineering flavored. Sounds weid, right, I guess I’m going on like the ice cream thing right, with JFK, I’m like stuck on ice cream. And so instead of the one day they had a whole week and they were able to focus on those high pain, tough issues. So this turned our super shitty, awful, demented Candyland game into this: which reminds me of the tri-force which is why I like it. Any Zelda fans in here? No. Ok good, alright. And so this I like to call the Triangle of Customer Triumph. Yes, T’s ok, alliteration, gonna remember it. SO we’ve got the customer who has a direct line to me, me who has a direct line to Max, and Max who has a direct line to the customer. We’re all in full communication, we all understand what’s going on. There is no like, “Maybe I’ll bribe Max and he’ll like do something. Maybe, and like not tell me what he’s doing so I really just like hope it got fixed, maybe it’s just loke dying somewhere, hidden in an inbox.” and, so despite the fact that Dev on Point works really well and we still do it all the time, we also have All Hands Support still.

I think the main thing that people forget is that there are two different sets of people that work in your company and there are different things that need to happen for both of those groups. so AHS is still one day in comparison to Dev on Point, which is one week. All Hands Support, AHS is for marketing, design, and executives. Our CTO and CEO both do it, which is awesome I think. And the Dev on Point is for product and engineers.

So how does it work, you ask? I’ll tell you, alright. So we have an issue, this is something we’re all familiar with. We work in issues. It’s like the currency that we have, right. Issue goes to the Customer Champion. Customer Champion says, “Hmm, what is this language? I don’t know what this language is,” Goes to other Customer Champions in Hipchat, Slack or whatever you were using. Other Champions look at it and they’re like “oh yeah dude don’t even worry, I totally have seen this before, it’s not even a big deal, it’s totally fine. And he explains it, or they, she explains it to the Customer Champion. The Customer Champion is like, “Oh awesome, thank you so much for teaching me about that–I’m gonna go back and I’m gonna teach the customer.” The customer is happy, The Customer Champions are happy, everyone wins.

There’s also the event that the other Champions are like “I got nothing. I have no idea what that is. I have no idea what they’re for, I have no idea what they’re trying to do.” And at that point, the other Customer Champion is like alright, cool I’ll go and talk to the Dev on Point. The Dev on Point says all “Oh yeah blah blah blah blah. Very easy. Here’s the fix.” And explains it to the Customer Champion better than I just explained it. And so, the other Champion is like “alright, cool I totally understand. Thank you so much for teaching me about this, this is really helpful.” and then they’re able to document it so that in the future if it comes up we don’t have to come up to engineering, they’re able to tell the other Customer Champions that so they’re like, “oh okay cool awesome I learned something new today, I can help anytime something new comes up. and then they go back to the customer and ultimately the customer still gets an answer.”

This has obviously complicated our processes a lot it’s no longer just: we talk to customer, customer talks back to us; it’s we talk to customer, customer tells us what’s up, we go talk to the other Champions and then eventually go to the Dev on Point, right. Pretty complex. Maybe not the best. We’re still working on it as everyone is working on everything in their company I assume.

But despite that complexity, it’s added three really important things:

First, I don’t know about you guys but when I started at Wistia the most that I’d ever done with code was like making my Myspace profile really flashy, really nice, because it was like the highlight of my life. And now, I’ve learned at Wistia: Javascript I’ve learned HTML, I’ve learned how to use Git; I’ve learned a ton and with that knowledge combined with Dev on Point. I’ve been able to understand if there’s a bug that we can’t fix why it is that we can’t fix it OR if it’s an issue that we think should be prioritized or a feature request, why that isn’t being prioritized–we’re all on the same page it’s not like a black box that the engineers are like “Ugh you can’t see why we’re not doing it, we’re just not doing it.” There’s full visibility which is incredibly important in terms of everybody being on the same page and having buy in. Buy in is like a big, important word and when everyone is on the same page and advocating for each other it means that everything is a lot happier, it works better, right? Ostensibly. All the premise of this.

Secondarily, we’ve been able to push the most important fixes. Notice I say “most important” not like “sexiest” or like “most-needed” or “most requested”: it’s something that everyone agrees upon, so the support and engineering teams agree together and then build those changes, right? Which is awesome, it’s no longer one guiding the other. It’s two people partnered. Super important.

And lastly, we’re able to communicate better across all teams. the rest of our company was super inspired by the fact that our engineering and support, typically two every adversarial teams, were able to get along and bond and discover, “Yeah we can do this together, it’s better for our customers when we do this together.” So now, everyone in our company strives for a level of transparency that we currently have, which is inspiring.

So like I don’t know probably like a year and a half ago if you would’ve asked me, “Is this something that you think you can do?” I probably at that point would’ve probably been like “Nnyyahh. no.” Because I think support is traditionally a place where we don’t expect buy in, right, we’re very selfless people, we care about helping other people and we’re often times like, “Well I guess it’s not like super important what I need” right? Is this something that people can relate to? We don’t want to be controversial or have fights and so if you had asked me that I would’ve said no, and so this kind of communication as we’ve slowly built it up has really helped.

So if you’re at a company or want to work at a company and the focus is how much money you’re making or how many tickets it is you’re going through or what kind of toppings you get on your sundaes on wednesday, (which is pretty important but not, ultimately most important) you’re doing it wrong. You’re doing it wrong.

Customers are what make your company; they should be what’s guiding your product; they should be what’s guiding everyone’s motives.

So because there have been like, zero memes and I’m a big fan of memes, I’m going to provide you with a tool that you can take back to your company and you can surprise them and make them laugh about customers:

What’s more important than your customers? Nothing. Nothing is more important than your customers.

So I guess what I want to leave you with is, tomorrow, when you wake up in the morning and you are like super hungover and you are like “man where did that Dominoes box come from? oh dear,” I want you to look in the mirror, and no matter how haggard you look, which you probably will, cause this is UserConf, I’ve been there, I know. (I lost my glasses last UserConf. no idea where they went) you’re gonna look in the mirror and you’re gonna say:

“Dang (insert my name here) you are looking great. You are looking great today, but you know what’s even greater, customers. Pretty great. You know what’s even greater than that, YOUR customers!”

Your customers are great and if you take that energy and that drive back to your company, you’ll be able to do anything. And I know that sounds crazy and like affirmations people think it’s kind of bullshit but it will help. It will help, I promise, because when you empower yourself and you say “Yes! I can do it, customers are important, my customers rock” (everyone should feel this way) you’ll be able to do it. You’ll feel confident enough that you can make those changes and argue for those changes. So customers should be everyone’s reason for getting out of bed in the morning. Live long and prosper.

About the Author

Heather J. McCloskey, Inbound & Content Marketing Manager at UserVoice, is a former broadcast news producer. When she's not writing pieces about product management and customer support here, she can be found putting pedal to the metal behind a sewing machine or painting watercolor comics.

A product is more than just the bits and bytes that comprise the software. It’s more than the user experience that someone has when they’re inside your software and actively using it to solve their problems. It’s more than the …

Want to build swoon-worthy products?

At UserVoice, we help you turn customer feedback into a better product. We aggregate incoming product ideas and measure the business value of each idea so you can prioritize what to build next. Uncover your next big feature today!