Transcript

00:00:00 - Speaker 1: Support is one important way that you’re understanding how customers are experiencing the product and what you should be doing differently going forward. And at a more human and personal level, I think it’s important for motivating the product work, hearing from individual people about their desires for the product is quite motivating.

00:00:24 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with my colleague Mark McGranaghan.

00:00:38 - Speaker 1: Hey, Adam, now you’re a bit into the fatherhood journey. How’s that treating you?

00:00:45 - Speaker 2: Well, I love it. I love being a father. It’s extremely rewarding to care for a small and cute creature who basically depends on you for their every need. Also very hard work, really hard work, but we recently crossed into toddlerhood, so toddler, I think, is defined as one year and up, and actually that was a big transition because the Under one year, essentially the needs of the kid, especially as you get close to the early side of that one year, is completely different from adults, right? They’re drinking milk, maybe from a bottle, maybe from mom, how you bathe them, even when they are eating semi-s solid food, their needs are just utterly different from that of an adult, how they sleep, everything like that. But now that we’re into the toddler age, I’m finding it’s more like a very small and non-capable and gets tired easily and has a limited palate adult, but in a sense, you know, they can eat a lot of the same food, they kind of need to sleep at kind of somewhat similar times, so that’s actually quite nice and you add in the walking. And then you know potentially the talking and now yeah it’s less of a guessing game trying to fulfill the mostly physical needs of this creature and starts to advance into fulfilling their emotional needs and eventually their intellectual needs. So I’m finding that at a minimum sort of easier and less stressful, but also in a lot of ways a lot more fun. So yeah, it’s been really nice and it’s also a place where I think I really appreciate the very flexible work environment we’ve created for you, even though I did take off some parental leave time. I just assumed at some point I would need to take a bigger chunk, but that hasn’t actually really happened because I’ve been able to interleave childcare with my work. Now part of that is a lot of my colleagues are based in the states and so those meetings happen in the evening and So my daughter’s in bed then, but this is a good example I feel of where the flexible working environment that we’ve take quite a bit of effort to craft really starts to pay off.

00:02:42 - Speaker 1: That’s perhaps the most important testament to the flexible schedule we’ve heard yet. It’s awesome.

00:02:48 - Speaker 2: Well we can jump straight into our topic today, which is support.

Now, of course, it’s always good to start with a little bit of a definition, and support is something I feel strongly about.

I guess I feel strongly about all the pieces of what makes up a good company, or from my perspective, what makes a strong technology company, all these different functions that need to work together, engineering, design, marketing, and so on. But I feel like support is one that maybe doesn’t get its Do or doesn’t quite have the prestige of the others or something like that. Everyone agrees it’s really important, but you don’t think of working for a company in a support role necessarily as cool, maybe as being, I don’t know, a designer or something, and I find that a little bit unfortunate.

00:03:34 - Speaker 1: Yeah, I do think support is often underestimated, and I’m glad we’ll be digging into it today. So Adam, what does support mean for you exactly?

00:03:43 - Speaker 2: Yeah, I would define support as getting help with a specific problem you have with the product or maybe getting a question answered, but it’s something where you can’t do that through the sort of more automated means and you need to go to a call it a human interaction, you’re sort of contacting the company and maybe that line gets blurred a little bit with AI chatbot support thingies, but I think it’s you’re in this state where you have a problem to solve, you can’t figure out how to do it, and probably for every person that moment where you Give up and contact support happens at a different point. I’m more of an exhaust every other option, read all the documentation, Google about it, try to figure it out on my own before I usually reach for that, whereas others maybe go a little sooner. But yeah, you have a customer or a potential customer who is in a moment of need, and that’s an opportunity for the company to rise to that challenge and hopefully solve their problem.

But I think the tricky thing, as I think through the different support requests that I’ve handled over the years at the many companies I’ve worked at, including our work at Muse, is that you have quite a lot of different categories, right? It might be a request for information. How do I turn the pen from blue to red? And maybe that’s actually in the documentation and they just didn’t find it, so you can essentially just send them the documentation or just copy paste or whatever. It might also be a request for undocumented information.

So for example, we added safe mode to Muse, which is sort of protects you against a crash loop, kind of an unusual situation, but that occurs occasionally. But there is a way to manually invoke it and at least initially we didn’t have that documented or maybe outside of just the memo where we released it, so someone writes in needing access to this information and reasonably they haven’t been able to find it. And that’s kind of the simple thing, but then you go from there to, OK, it’s actually a bug report. I’ve had a crash, you know, I’m getting this very unexpected or undefined behavior, but it could also be a feature request and often I think all four of those I’ve named like.

I want to learn something about how to use your thing or there’s a bug or I want a new feature. They may actually not even know which one it is as they write in. So the person on the support side, on the company side, you know, me in this kind of hypothetical example is sitting there saying, OK, the pen color blue to red, yes, that exists, here’s how to do it. But it might also be, well, we don’t have that capability yet, but we want to in the future or we don’t have that capability yet, but that’s an interesting idea. Let me put it on the stack or think about that, or maybe that actually you can do it and this person for whatever reason is just like the software is not working properly for them and so this is actually a bug report. So it really could be from their perspective they want to solve this problem they have, which is do a thing that they haven’t been able to figure out to do, but which of those four it is they may actually not know when they’re writing in.

00:06:32 - Speaker 1: Yeah, and if it’s that I might add here is a service request. This is when someone writes in and requests that you do something basically manually, either because you’ve deliberately not included an automated path for that or just because it’s nothing you thought of before. So for example, sometimes we get requests about deleting all the users' data and that’s not exactly a bug or a feature, but it’s still something you need to handle the support.

00:06:56 - Speaker 2: There’s a couple of related areas I’d love to talk about here today, and one of those is what you might call service or customer service, which I think that does overlap or maybe is even a super set of support if you like, but I think in the software business or with digital products, support and service are not that different.

Maybe there’s occasionally things that A human operator working at the company can handle that you can’t handle, so you have to write to request that.

But there are a lot of businesses, particularly those that deal in more kind of physical world things, that is to say non software companies that customer service is a huge part of what they do because there’s so many things the customer can’t do, like the service department at a car dealership, it’s like after business.

00:07:37 - Speaker 2: Yes, exactly, and I think some of the best examples of companies that really differentiate on support or kind of a role model for this are companies that have a business more like that.

So Zappos. You know, they have their core value of this deliver wow through service idea, and if you kind of dig into that and what that means for them, particularly if you think back to 10 or 12 years ago when they were really pioneering this, they did things like free shipping on returns. So if you don’t like it, you can return it, it doesn’t cost you anything, no questions asked.

And maybe nowadays that’s been copied more, you know, you got Amazon and Zalando and others that do the same thing, but at the time that was a really kind of Surprising and impressive bit of customer service.

Yeah, so it’s a similar thing with anything where there’s going to be exactly car dealership, travel related things, that sort of stuff. It’s just you have to call in or email or whatever it is to get something done, and that’s just the nature of that business and I think for us, except for those very kind of rare and occasional things, for the most part, if we haven’t made a way to do it in app yet, that’s not quite a gap, I call a gap in the product, I would say.

Now, how do we go about handling support at Muse?

00:08:50 - Speaker 1: Well, in preparation for this episode, I was trying to go back and recall our original discussions on setting up support.

And the thing that I remember most strongly is what I didn’t want to happen, which is that typical experience where you, first of all, you go to the support page and it’s like this mechanism to prevent them from emailing you.

You know, all the FAQs and there’s a little tiny button with email us.

So I didn’t want that.

And I also didn’t want that feeling that you were being fed into a huge apersonal machine. You know, you fill in the form and it It gives you like ticket number 7,042, and there’s all this like support machinery stuff around it.

The experience that I wanted was basically like you’re emailing the founding team and they’re emailing you back.

And it literally just looks like a regular email. And that’s pretty similar to what we ended up with. You can email us at hello at and one of the five partners will read and respond and We use a tool Front app, which is great for basically multiplexing the email inbox, which works well for us.

00:09:51 - Speaker 2: Yeah, I also agree that the impersonal feel like you’re being fed into the machine thing is just to me one of my least favorite parts of contacting support, and one feature that is a default, I think in a lot of these helpdesk pieces of software, maybe like a Zendesk, for example, is that they email you back right away with exactly as you said, the ticket number. Your request is very important to us. You have request number 7000, and to me that actually is.

Anti reassuring. Now I guess the downside there is it can happen if you email the muse team and our current set up if you do it on a, I don’t know, Friday afternoon your time, but actually it was a person in Europe that was on duty that day and so they’ve already kind of signed off and we do have someone scanning the request over the weekend, but if it’s non-critical, you know, maybe you go 3 or 4 days in a worst case scenario without getting a reply and maybe that’s not very reassuring. And so the idea is that that sense that like at least they received my email. I have this kind of receipt.

But yeah, it just feels like noise and it feels like you’re in a machine.

And so, yeah, that was when we did set this up, it was Adam Wulf, who set up front for us, and we’d already kind of had this helloadme app.com catch all kind of the entry point to contacting us, but it kind of went to one person, which I think was me for a while, or maybe it was you, I can’t remember, but then when it became the report requests became too much. or unreasonable for one person to handle and kind of route, well then you want to add other people to the list, but now who’s going to answer each particular one? And that’s where, as you said, the multiplexing part comes in that it comes in and then the way that we end up multiplexing the assignments is essentially just day of the week because we have a number of team members that’s Less than equal to 7, so it’s pretty easy to just have each person take sort of one day, and that may not scale in the longer term, and actually one question for us would be whether we would hire dedicated support people at some point. Do you have a feeling on that, as you said, you feel like you’re emailing the founders versus the benefits of having people who are really good at support because that’s their expertise.

00:11:53 - Speaker 1: Yeah, it’s tough. I feel like it varies by support requests type.

So there are some things that I think could actually be handled better by a dedicated support person because it would be more responsive and they would have their full attention.

Things like these service requests, basic product feedback, ideas, product ideas, questions that are already answerable, like, you know, how do I access something that you can in fact do in the product, it just wasn’t clear to the user how to do that. That stuff I think would all be better served by a dedicated support person.

But then there’s a lot of the stuff that we currently get is stuff that actually needs to find its way to the person who’s working on that particular feature. So someone writes in with some weird sync behavior, for example, one of the engineers needs to look at that. And there, if you have a person in the middle can just add an extra step and make it slower and less crisp, and a lot of stuff that we currently get is of that form, so I think it’s kind of tough, and I wouldn’t be surprised if eventually we have a mix.

00:12:49 - Speaker 2: Yeah, sometimes the way that gets handled is you have the support levels and kind of level one should be focused on really common questions and could be answered quickly, and you use a lot of templates and that sort of thing, and then for things that are not in that category, they can, so to speak, escalate. And hopefully in that kind of a set up it would be something that’s done seamlessly that whoever is on the front lines there, one of the skills they would have would be triage, sometimes it’s the word that’s used, but they would have the ability to triage and really be able to sort out. OK, this is a feature request. We have 100 others just like it. We want to file it in our feature database and maybe we want some aggregate. Reported that, but maybe there isn’t a lot of deep info there or as you said, just a question they want answered that there’s an easy answer to, whereas here is like a really interesting reflection on a use case that we kind of haven’t heard before and how that interacts with the feature that was currently in beta.

OK, this seems like worth getting in front of someone for deeper consideration.

00:13:47 - Speaker 1: Yeah, and to be clear, going back to our motivation for setting up support this way, there’s some value perhaps that you have as a user if you are communicating directly with the founder, but I think a lot of the value is just having a very clear, simple line of communication. We don’t feel like you’re getting bounced around, you’re getting shuffled around. And so this triage could be totally transparent. It’s like you send an email and it’s magically answered by the exact right person to do so directly. And I think that’s a property that we can still maintain.

00:14:17 - Speaker 2: Yeah, the handoff element I’ve certainly run into that with maybe like banks or something where I already know because I’ve done this exact thing, like I don’t know, an international wire transfer or something. I’ve done this 20 times before. I know there’s a department that handles it. That department does not or refuses to give me the direct phone number. You got to call the main customer service, explain what you want to do. Then they say, Oh, we have another department that handles that. Would it be all right if I transferred you there and trying to head off their playbook, I have found if I say hello. I need to make an international wire transfer. Your international wires department handles that. Please transfer me. And they say, Oh, hello, Mr. Wiggins. OK, you want to make a wire transfer? Well, what kind is that inside the United States or international? And I’ll see if I can help you with it. And I’m like, yes, can we fast forward, please? That sort of handoff experience is not what you want, but rather you want your message to get to the right person to read it.

Since we’re talking about sort of examples of unpleasant support or support that we on the say the user experience side don’t like, two of the things I think that we, or at least I had in my mind when we were designing our support setup is one is where you go to that contact us page, and yeah, they’re trying to kind of divert you away from contacting them in some ways. But I always find it funny when you’re logged into a website where they have your full account information. Again, a bank would be a canonical example, but any software is a service, and if I click that, get support button, I’m surprised how often it takes me to a form where I fill out my contact information because it’s like, wait a minute, you know exactly who I am. I’m in my account and in fact it’s useful to you, you here being the service that I’m trying to write to. That you know you have all my account information, that context might be really important. So it feels very weird and impersonal. Why am I filling out this form like I’m a stranger that you’ve never heard from before.

And that’s one of the reasons we created the in-app feedback from Muse, which actually feeds right into the same channel as if you email hollo at museapp.com. So from our perspective answering, there’s no difference, but for the user, they can do it right in the app. They don’t need to identify themselves. They’re already logged into the app, so of course we know who they are. And indeed in front it has some pretty good features for surfacing past conversations, and we wrote a little plugin that gives us just some information like how long they’ve been a new user and stuff like that, because that could be really important context. Are they brand new or they’ve been a user for or a customer for 2 years? They’re probably looking for a different kind of support in that case.

00:16:45 - Speaker 1: Yeah, there’s a couple points I want to elaborate on there.

One is this ina feedback form.

So we had the intuition that the amount of feedback that you get is mechanically related to how troublesome it is to submit the feedback, and places like banks take advantage of this by making it as hard as possible to, you know, contact us and therefore they get less calls, which is their goal.

So we wanted to do the opposite of that, which is make it as easy and quick as possible with the thinking that that would give us more feedback, which, especially at the very beginning of the company and the product, we wanted to get as much feedback as possible. So that’s why we have this in-app form where it’s literally just a box that you open up and you type stuff into and you hit send. And by the way, we got some good meta feedback on that. People are like, oh, that’s such a, you know, easy and nice and pleasant way to submit feedback. More people should do that. The other was this idea of like the whole customer experience. So as a customer of a product and company, you have a notion of what your entire universe of interactions with that company has been. You know, I’ve bought this and this, I’ve said these things, I’ve given them this information, this is the nature of my account. And whenever you’re talking with someone on the other side who doesn’t have that full context, it feels jarring and incompetent. And so another thing we’ve tried to do is Make sure that we have all the context that you have when we’re giving you support. So that again is why we have all that stuff in front.

00:18:07 - Speaker 2: Yeah, I think that’s especially notable, the context stuff when you have, let’s say a kind of an open incident or an open thing you’re dealing with.

I don’t know, I think of like some of the car insurance, you’re filing a claim because you’re in an accident or whatever, you need to call back several times because there’s several things to do, and the good ones. They see right on your file that you have this open case and you don’t need to re-explain the whole story again every time you call, you’re calling back to say, OK, you know, you told me 3 days ago I should call when the repairs were complete, they’re now complete, tell me what to do next, for example.

But very often, yeah, you do get this like, OK, well, Mr. Wiggins, what can I help you with today? And, you know, I’m thinking you don’t have on your screen in front of you that there’s this thing going on.

00:18:52 - Speaker 1: This is an aside, but I feel like there’s an opportunity in software products to productize this notion more, like, give customers the sense that you in fact have a handle on their full history. So this is like the Amazon orders page, but for everything, but for your support requests and all this other stuff. I think some companies sort of do this, and I just feel like there’s something more there and if people really leaned into it, there’d be a payoff in terms of the customer satisfaction.

00:19:18 - Speaker 2: Yeah, and hopefully that would be, let’s say the pertinent to relevant things. There is a version of that that might feel creepy, which often the extreme degree of data that the Google and Amazons of the world have about us can be, but they should have the same context that me as a user does. Like I’ve placed a lot of orders or my account is brand new, or there’s an error with the billing and my, you know, it told me to log in because my credit card expired, but then when I tried to type it in, I got an error. So maybe they can see that I have an expired card and that’s like an open problem that I’m trying to solve, for example.

Yeah, I do wonder if there’s some kind of product opportunity for a support help desk that does encode a lot of these ideas, but I think it’s tricky because it would need such deep integration with the rest of your systems and would be fairly specific to your business. But yeah, I wonder if there’s something that could capture some of that.

Now we’ve been talking about bad support examples kind of from the user side, Mark, do you have examples of companies that you think do well or where you’ve had good experiences as the end user?

00:20:23 - Speaker 1: Yeah, well, I definitely had my own Zappos wow experience. I forget what the original trigger was. I think they like sent me the wrong size shoe or something. I don’t know. Anyways, like, I called them up, you know, they answered right away. It was a person who spoke perfect English, and I told them my problem, and they’re like, oh yeah, no problem. We’re giving you free shoes. You’re now a VIP customer for life, you know, we’re shipping it out overnight. It’s like, oh, OK, that’s awesome.

00:20:50 - Speaker 2: And I went on to buy like dozens and dozens of shoes from them over the years almost like overreacting to a customer problem as at least I’ve heard that that was a strategy that IBM used back in their powerhouse days. A customer would call in with a problem, and they would send, you know, 12 technicians out to the site, you know, ready to not only fix the immediate problem but improve everything in its immediate vicinity in a way that the customer was just left thinking this is amazing, and they would use that as an opportunity to turn someone into a customer for life. That’s exactly right.

00:21:16 - Speaker 1: Yeah. Another one that I always talk about is First Republic Bank.

So this is the rare example of a bank that actually gives good customer service. So when I first moved to San Francisco, I needed a bank in the area and I googled banks and stuff and I found First Republic on the maps, and so I walked over to the office, and the ratio of service people to customers was so high.

I thought I’d like walked into the corporate office or something, like there’s no customers here, there’s no line, there’s no big thick glass in front of all the counters, like all the other places that I’ve been to. Nope, they’re just very responsive. And again, that’s a company where I’ve referred many, many people over the years to.

00:21:50 - Speaker 2: Mhm. One that I’ll give an honorable mention to, but sadly is no longer in existence in a meaningful way as an ISP actually based out of the Muse headquarters city of Seattle called Speakeasy. Do you know these guys?

00:22:03 - Speaker 1: It sounds familiar.

00:22:05 - Speaker 2: I feel like they were kind of late 90s till I don’t know, mid 2010s and then got acquired and kind of just disappeared in the belly of larger companies, which maybe means that their whole approach wasn’t really viable. I don’t know what the story was there. But for me, they were so stand out because, I mean, ISPs are one of those ones that are like banks just famous for giving you miserable customer service like Comcast and the Comcast cares thing is almost like an internet meme joke that people have such bad experiences with that company, and I think that’s common for these sort of natural monopoly, telecom provider thing and driven to keep costs low, but then there’s complicated systems that break all the time. I don’t know. But in any case, Speakeasy was a rare case of a really good ISP. They charged a little bit of a premium, but importantly, they didn’t treat Linux and other kind of open source operating systems and software as well, they supported them.

I actually ran into that with ISPs that I had over the years where I’d get a cable modem or something and the only one that was available in my area, and they basically would just tell me straight up that they couldn’t let me use it because I didn’t have a Windows machine. And of course, it totally worked fine, and I would just kind of say, oh no, I’ve got windows, kind of like hedge a little bit and shoot them out the door, and then I would like set it up myself because it of course it works fine. But then I was always in a little bit of this fight with their their service reps about setup, and if you do call in with a problem, you know, there’s a problem in the line, which happened a lot back in those. Days, particularly with DSLs, and then they want you to click on this and this thing in the Windows whatever, but I don’t have that exact thing, so I’m trying to simulate it.

Anyway, Speakeasy got through all that. They were for more power users and people who are a little more knowledgeable about networks and their customer service was basically a joy to call into. They would quickly assess your level of knowledge about networks and whatever.

We could really be quickly talking in the form of, I say, look, I’ve already tested on the local network, that works fine to the router, but it’s the router to the here, you know, the trace route’s breaking, and they would say, OK, great, I’m going to run a line test on this and that. You push this button on the router. OK, it looks like there is a fault in the line. We’ll see if we can reset it from there. OK, yes, that did the job, or no, it didn’t, we need to send someone out, but it was always this kind of interaction and It’s a weird thing to be impressed by, but there were many cases where their line would have a status update when you first dialed in, where it would say our service is currently operational in all areas except for downtown Redwood City, where we are experiencing some outages and we’ll have more information at a future time. Now if you want, you can stay on the line and you could talk to someone about it.

For me, more often than not, I’d be like, oh great, they know about it, it’s affecting my area. I just hang up. Because that’s all the information I wanted to know, versus that it’s just affecting me, they don’t know about it, I need to like kind of poke them to get something to change. So that was a case where the automated system giving me the information I wanted was exactly perfect.

Maybe that’s an example of the support meets service, which is service doesn’t have to be, you talk to a human, it has to be like give me information or solve my problem or put me at ease that this problem is being handled.

00:25:22 - Speaker 1: Yeah, it also speaks to the whole specialty subfield of support and customer service for like operational businesses. So ISPs, Hiroku would go in this bucket, which was an application, a hosting company. Airlines also, and there you have all the standard support stuff, but there’s also this operational element where people need this thing to be able to like get online or run their business or travel to see their parents or whatever.

00:25:47 - Speaker 2: Yeah, and very emotional, right? You’re in this moment where you can’t get on the plane, you need the money in your bank account.

I had an experience like that with my very first business, which was a payment gateway called Trust commerce. I learned pretty quickly there how bugs in your software in the payment world has a, you know, higher stakes than other realms that I’ve been involved in before then, but we had a case where we essentially kind of double authorized someone’s credit card.

So, you know, now we’re getting into payment industry jargon, but an authorization. It is basically a reservation of money on a credit card, but by default it just gets released after some number of days unless you come and capture the result.

In this case, it was literally like a race condition or bug in our software. We charge someone’s card twice, but it turned out that it was a debit card, so it actually holds that money out of their bank account, and there isn’t really a good way in the system, at least back then, maybe this has changed to free that authorization. You’re just supposed to let it expire.

Eventually, the merchant who was our customer gave our phone number to one of their customers who had encountered this bug and basically a woman called me on the phone sobbing because she couldn’t buy food and turkey for the big Thanksgiving. The meal that she was having at her house with her whole family in 2 days and you know, that was like a very visceral thing to be exposed to. It wasn’t just this bug and this minor inconvenience, it’s something that really had a big emotional impact on a person’s life.

00:27:16 - Speaker 1: Yeah, and we should come back to this topic of like customer connection and motivating product development. I think we have a lot to say about that. But just quickly on the operational front, I think our experience has been that there’s a huge amount of appreciation for just clearly communicating to customers what’s going on. So you gave the example of the ISP outage. You’re not like calling to like complain or be mad, just wanna know what’s going on, and if the company is aware of it, and you know the company is aware of it, that addresses like 90% of your concerns because yeah, I think they’re gonna fix it in a few hours and we’ll be back in business.

00:27:47 - Speaker 2: Yeah, I’ll go for an early lunch, and it’s too bad because I really wanted to get this thing I was working on done and but I need an internet connection for that. OK, fine, I’ll take an early lunch and I’ll work on it later.

00:27:57 - Speaker 1: Yeah, I was almost surprised to the extent that this was true in a business like Hiroku where, yes, people don’t like if there’s something wrong or if the platform is down for a little bit. What they really, really, really don’t like is if you don’t communicate clearly about it, and they especially double dislike if you ever give something that’s like wrong or contradictory. And so to bring it back to the airline example, the classic cases where they tell you the flight is like right on time, right up until the scheduled departure, they’re like oops, it’s 3 hours late. Well, you knew that, didn’t you? You were just lying to us. That’s what people really don’t like.

00:28:29 - Speaker 2: And that’s where increasingly because a lot of this flight information is public or there’s public APIs or whatever, you have apps like Flighty, for example, which gives you the exact location of the plane that you’re going to be on at the moment and you can see it’s still on the way. Or it’s parked at the gate where it’s supposed to have departed or what have you, and yet the airline is strongly incentivized to not tell you until the last minute because they want you to get there and be ready and not delay because if they do manage to get the plane there on time, they want you to be ready for that, but then you don’t have the information you need to work with.

Yeah, I even remember a case where I had a flight straight up canceled. I think it was just a weather thing, but they sent me an email. I can’t remember what it was like 4 hours before, and I was going to leave for the airport 2 hours before. So it was already all packed and everything, but I get this email and I go, Well, that’s really inconvenient, and it cuts my trip a little short and it’ll make the conference I’m going to a little tighter. But hey, at least they told me. I don’t need to leave my home. I don’t need to even convenience myself. I’ll just unpack, stay home for another day and then fly the next day on the flight they offered me. So that was a case where It was a huge inconvenience in some ways, but because they communicated clearly and at the right time, in the end, I just wasn’t that upset about it.

You’d certainly imagine cases where you did really need to be there that day, but that just didn’t happen to be the case there. Yep.

Yeah, that’s a really great point. It’s the difference between the infrastructure operations aspects and I don’t know what we call this other kind of sport. So at Hiroku there was this thing of, I tried to load up my app, but I’m getting this error or I would like to be able to use this feature or I’d like to upgrade this one, have more scale or something like that, you know, they want the problem solved, but it’s not an immediate outage. And once we did get into running people’s apps which were business dependent on it, that sort of thing really quickly we had to get very serious about incident response and designing a status page that could try to communicate all the subtleties of what things may or may not be working, especially when you have limited information in the first place and how our pager rotations worked. There was a huge Certainly in the last year or two that I was at Haruku, I think way more of my time went into that sort of operational stuff as compared to what I would consider like the core product or what someone externally might consider the core product, and I think that’s kind of the nature of. Structure business, but indeed that was, I think I mentioned this in our podcast with Martin, but that was honestly one of my motivations for local first was wanting to make software where my servers are not in the critical path for basic operation. And certainly we’ve tried to set new up that way. We’ll see what happens as time goes on, you know, if there’s a serious sync server outage and someone can’t sync their devices, you can obviously still work, totally fine, you just can’t move between them. Uh that’s an inconvenience, but it feels different from, for example, when something like Notion has an outage, you just can’t use it or access any of your data at all. All right, so, Mark, from the company’s perspective, we started out by saying it’s important. Why is that so?

00:31:40 - Speaker 1: Yeah, well, I think there’s a customer perspective on this, and then there’s a company perspective on this, and we’ve been getting into the customer side a little bit. For example, we said that when a customer is writing in to support, often it’s something that’s important to them, it’s high stakes, it’s critical. So you’re already in an important situation. What I think people don’t realize unless you sort of do the math, is that your support function is often where people have the most or indeed the only human to human contact with the company. So it has the opportunity to leave a huge impression either for good or for worse. And also on the customer side, there’s this whole like support to sales process, perhaps we can talk more about it, but again, we’re thinking about support as part of a longer customer flow, a broader customer life cycle, and there it’s basically the first touch point on them eventually becoming a happily paying customer down the road. So we could talk more about those customer side things and on the company side. I think support is very important for getting information and motivation. Support is one important way that you’re understanding how customers are experiencing the product and what you should be doing differently going forward.

And at a more human and personal level, I think it’s important for motivating the product work in a sense that you’re a person too, you need motivation to do hard work and hearing from individual people about their desires for the product is quite motivating.

00:33:08 - Speaker 2: Yeah, that to me is huge.

The reason I build products is, of course we have ideas we want to express.

We are making products that we want to use ourselves, hopefully, but I am doing it to help other people to serve their needs, to help them in their creation process, their creative process, and hopefully building a tool that fits into their life in some way that improves things for them.

And so that includes both the call it positive or negative feedback.

Of course you tend to get less of this through your support channels, but I do always deeply appreciate it when someone writes in to say, you know, I don’t have any complaint. I just think what you’re doing is great and it’s really a great tool in my pipeline and you know, keep it up, or sometimes it comes along with, hey, I’ve got some small thing I wanted to report a bug or something, but also by the way, I just want to say I’ve been you know a new customer for a year and a half and You know, it’s really made a big difference in, I don’t know, writing my master thesis. So of course it’s great to hear the positive stuff and that’s very motivating.

But the negative stuff can also be both motivating in its own way, but also focusing, right, which is you kind of always have, here’s your backlog of 500 bugs to fix and 200 features that you know you want to build and what have you, but having someone write in and say very specifically, here’s who I am, what I do, here’s why I need this feature, or here’s why this bug is causing me a problem, and that just really brings it home in a way that Yeah, just the abstractness of here’s a ticket in my ticket tracker and my general, you know, we all have the general sense of craftspersonship. We want to make a good product and fix bugs and, you know, improve things, but it’s totally different to hear someone’s story about how it’s causing friction or creating problems for them and the tool they otherwise love to use.

00:34:53 - Speaker 1: Yeah, it really does have an outsized impact. I think people underestimate this, it feels like it shouldn’t, you know, we have all these statistics and road maps and metrics and whatever about what we should be doing. But then you talk to one human being. Ideally you look them in the eyes, but the next best thing would be you’re on an individual email exchange with them, and for some reason, I guess this is what humans are, you know, it’s so much more motivating than any number of stats or declarations from the product manager or whatever would be. So I think it’s super valuable.

00:35:24 - Speaker 2: Another piece of that being in touch with customer needs, is the fresh perspective. So, we have been in this world of how this product works and all the context that goes around it, greater tools for thought history, design thinking, and so on. And then someone new comes in, especially if they have very little context, you know, maybe Apple featured us under, you know, some productivity category, someone just clicked on it or tapped on it and like, yeah, cool, they install it, try it for 3 seconds and then they have a question and they write support, and they just don’t have a lot of.

Context and all the context, but in some ways we have almost too much context, and I’ll give you a concrete example of where we applied that somewhat recently was realizing that we really need to explain the concept of nested boards better and that in the kind of news 1.0 era website. We talk about it, spatial canvas, and you can nest your boards and there’s a little video, but what does that actually mean? because you see the zooming thing, but of course a lot of, I don’t know, modern mobile software allows you to just zoom in like a map or a photo, and it’s really not that, it is really about this nesting. The zoom is an interaction that achieves the nesting.

And so folks write in and they might say something like, my board is full, is there a way I can clear it? And then kind of wait, what do you mean full? Like, can you make it and you realize, oh, the home board, they don’t really realize that you can nest other boards within that. And so then you need to explain that. And having run across that a whole bunch of times, we realized that we really just need a whole page on our website. That basically explains the concept of nested boards, and that will seem to a long time user customer pretty basic, but for people who are new to it, that actually is a really core concept that it’s important to get or you’re not going to be successful at evaluating whether the apps are fit for you or not.

00:37:23 - Speaker 1: Yeah, and speaking of frequent feedback items, my experience is that a large chunk of support traffic is assignable to a small handful of areas at any given time.

So, just to pick one example, right now I feel like I’m getting a lot of support requests about how can I recover a car that I accidentally threw off the edge of a board, cause people weren’t aware yet of the undue last deletion feature.

And what it is kind of varies over time. At one point we were getting a lot of requests for discounts from college students, I think because we were on some college student YouTube channel, maybe. I don’t know.

But anyways, at any one time, there’s like 5 or 6 things that are basically on top of the collective minds of our users. And a coral area of that is that you don’t need to go through that many support tickets to understand what the 5 things are.

If you do 20 or 30 tickets, you basically know what they are and they start coming up again and again.

And it’s really valuable to know those things. It’s actually kind of inexcusable not to.

And so that’s an example of where you can just a little bit of support work, get a really important bit of data from our customers.

00:38:26 - Speaker 2: And this could be a place where the qualitative and the quantitative can reinforce each other a bit.

Another fun story from the early days of Hiroku was one of our early team members was a fellow named Orn Teich, who I’d say I learned just about everything I know about product management as a call it formal discipline, let’s say something like that.

He was a great teacher for me.

But his pilot project to potentially join our team, which of course he eventually did, was to basically send a survey to all of our customers asking them what was important to them, and then present us a bar chart of the results. And of course that sounds kind of basic, but we were pretty surprised and actually it showed that.

We kind of compared our roadmap of things we were working on, and then we compared that to, you know, there were 2 or 3 things that were far and away the most important thing that people were asking for. I’m trying to remember what it was, probably back then it was something like SSL capability. But we had it on our list, but we kind of thought it was like, ah yeah, it’s like number 15, we’ll get to it there. But when you looked at this, it was just like most people, you know, the things we were working on as our top priority items were way down the list that people were interested in.

And of course support and what customers want now is just one input to your product process.

You have a bigger vision. There’s a lot of reasons why you don’t just prioritize exactly what you work on based on that, but I think oftentimes product oriented companies with product oriented founders or CEOs or whatever do tend to lean so heavily on the vision side that they basically forget to listen to customers and.

Seeing that aggregated, not just the individual requests, which of course you start to get a feel for it if you’re doing it every day or every week, but actually putting that together whether it’s in a survey form or for example, we often tag stuff in our support tool where every time someone asks for the Mac app we tag that or every time someone asks for a dark mode we tag that, and then you can go and kind of have an aggregate sense of that over time.

Now another piece of the be in touch with customers, look them in the eyes, metaphorically speaking, is what I would probably call ad hoc user interviews or sort of just understanding who are these folks, right? And of course it’s part of our values that we don’t. Ask you to give anything, you don’t have to give a name or we don’t record a location or anything like that, even something like, I don’t know, FIMA for example, when you log in, they ask you what’s your first and last name, what’s your title, how many people are at your company?

00:40:55 - Speaker 1: I don’t know if FIMA does that, but a lot of people do it annoys me.

00:40:59 - Speaker 2: Yeah, it’s annoying, but of course it’s also valuable from their side. They can both for sales reasons it’s beneficial to the company, but probably also for support reasons as well.

They can understand context about their customers, which is fair enough, but yeah, I’m also annoyed.

Buy it, especially since I usually don’t cleanly fit into any category that they’re offering when I’m first trying out a tool, I’m usually not doing it for my work anyways. I’m just kicking the tires to have in my mind whether I might use it in the future.

Anyhow, so we basically have no information about you other than your email.

So then when someone writes in and they may either volunteer some information about themselves, Hey, I’m a professor of industrial design at this such university, or I’m a software engineer and I find that your product is useful for me in this way, that’s really nice to have.

But the other thing we do is essentially turn support interactions into customer interviews at times, which can sometimes come from the form of someone writes in. I see something in their footer, you know, their email signature, and I’m like, oh, that’s interesting, and I just kind of end up asking them about it.

Maybe they email in, Hey, I’ve got a bug, this thing didn’t duplicate, and they send a screenshot of their board and I’m looking at this board and I’m like, wow, this is awesome. What is this? And they’re like, oh, you know, I’m an amateur board game designer and this is like a game I’m working on for Kickstarter, blah blah blah. You get into that kind of conversation.

So the chance to draw out. What the context is, what kind of people are using this product, what are they using it for, and certainly when it’s in the context of a feature request where someone writes in and says, hey, I want to be able to do X, and I say, OK, well, that’s interesting, you know, it’s kind of a thing we want to do, but not really explicitly on a roadmap right now, can you tell me more? And the motivation of Why they want it, what they’re trying to do with it, what’s interesting about that is another piece of this, I guess, coming back to the motivation for the team and for development, having that story behind it, here’s how this would help this person is, again, a really powerful thing for motivating development work.

00:42:56 - Speaker 1: For sure, and I think in the same way that you want to have a pulse on the top 5 or 6 common like feature level issues, I think you want a sense of what are people tending to use the product for.

Now, often it won’t be surprising.

I would say that the users and the use cases that we have from use aren’t super surprising and the whole like the micro of it is really interesting, you know, like someone is a board game designer or they’re a restaurant consultant or whatever, you know, all kinds of interesting stuff, but the sort of Type or class of user isn’t super surprising, but my experience is that sometimes you have a customer base and you develop this really weird pocket that you need to inquire further about, you know, as some niche type of user or someone who’s using the product in a sort of surprising way, and you need to kind of look into that further.

00:43:43 - Speaker 2: I like that in the process of talking here, we’ve naturally drawn on our experiences, my payment gateway, Hiroku, we talked about Muse. I’m sure a lot of folks would love to hear about what your experience at Stripe was like, whether you were exposed to that and kind of what the company culture was from the inside.

00:44:02 - Speaker 1: Yeah, I had some exposure to that that I can speak to. The first thing I would say is, I think people underestimate the extent to which Stripe was initially uh like support slash customer service focused business. I think people tend to associate Stripe with product and engineering, you know, there’s a lot of good stuff there. But the original premise of the company, as I understood it, was fixing the support slash customer service problem that people. Had with payment processors, which was as follows.

If you were an online business, and you wanted to get started with accepting credit cards, it was basically a complete mess. Like you had to fill up this application, you had to wait a bunch of time, and then every week with some probability, the company would just confiscate all your money, you know, like the classic PayPal move of, you know, sorry, you can’t get it anymore. And then you would write in and they want to answer and whatever. And Stripe did a lot of product and engineering things to address that, but the core premise, again, as I understood it, was to fix that experience and frustration that people had from the support side on payment processing.

And I think it’s actually the straight folks where I got this insight slash idea that support is often one of if not the most substantial point of contact that people have with your company.

As someone inside the company, support looks like a relatively small piece of the business. You have all this product and engineering and sales and whatever. But in terms of the time that people spend interacting with humans at your company, it’s mostly sales and then support. And so if you want people to have a good connotation with your company to have a good experience, the support needs to be very good.

We’re also very lucky at Stripe as we were, I would say at Hiku with having just an incredible support team. It’s a really tough job, I think, especially at a company like Stripe, because in addition to all the standard support challenges, it’s an incredibly adversarial environment because basically some portion of the people who are writing support tickets are trying to steal an enormous amount of money from you, and you don’t know up front who they are, so you’re constantly dealing with that.

I learned, especially at Stripe, it’s a very tough job and one of the reasons is because you’re often stuck between a customer who has a very valid and legitimate issue or complaint or feature request and not having a ton that you can do about that personally to fix it. So customer writes in and says, oh man, our business is really stuck. We need feature XYZ without it, we’re kind of out in the cold here. And as support you guys say like, I hear you, you know, we’re looking into it or it’s tough. Whereas if you are an engineer who’s just founded a software company, for example, and enough of those customers right in, you can just go in and build the feature and fix it. He has a lot more ability, I think, and degrees of freedom. It’s one of the reasons why I think it’s such a tough job.

00:46:45 - Speaker 2: Yeah, it’s an interesting sub side of things. The far extreme to now gigantic company like Stripe would be something like the solo founder kind of company like you see with a lot of these calm fund companies or something where an individual or maybe two people are building a piece of sass, and they’re selling it. And they’re basically doing all their own support and very often, especially because their customers, you know, the B2B, so they’re often high ticket value, you know, you got your $10,000 a year customer, they write in and say this feature would really help us out. You may be willing and able and motivated to essentially just build it and deploy. The following week and then be able to follow up with like, here it is, check it out. And that’s like a really cool experience on both sides of that. I even remember doing some of that in the Hiroku days, maybe not features, but certainly more like fixes, which is someone write in, kind of see right away that they’re having the problem. And yeah, we’re a small team, and I don’t know, I was young, so I probably worked too much, but, you know, just like make a late night of it and fix their problem and deploy that and say, you know, here, go and try it again, maybe it’ll work now. Talk about a wow moment, getting that kind of a turnaround. I think that’s a way that a small company can differentiate from a larger, more impersonal one. Yeah, and speaking of the Peruki support team, definitely give a big shout out to those folks. They had a really difficult job, maybe less the stripe thing of the the adversarial element, but the problem of an incredibly complex product. And people write in with a problem, and it’s really hard, or I should say it’s as much an art as a science, to differentiate between something that’s genuinely a problem or a challenge with the platform, the product, that is, say, Hirokyo versus just helping them debug their app. And where to draw the line there and where to say, OK, well, you know, now you need to go on stack overflow and Google a bit and I really can’t help you further, but it can be hard to tell, and it can be hard to tell for people on both sides, so that means that the support person And in their expertise, which, you know, they may or may not be right, but they know what they’re doing, be able to say, look, this is kind of beyond the scope of how we can help you. Here’s some resources, good luck, and the person on the other end could feel like, no way, you’re blowing me off, this is a problem in your product, and that’s just a tough, tough, tight rope to walk.

00:49:09 - Speaker 1: A fun aside here is that for these developer focused products like Kuroku and Stripe, it was the case that the people who best understood how the product actually works is the senior technical support staff. It’s not the founders and it’s not the engineers who are building it. It’s the people who have to deal every day with customers running into the platform and all the complexities that that entails. It was kind of amazing actually the degree of encyclopedic knowledge that the senior technical support staff had about the platform. They knew every bug, every quirk, you know, every weird gated behavior, they had it all down cold it was, it’s pretty incredible.

00:49:51 - Speaker 2: And one thing that comes to mind for me in the balancing of the customers' needs or desires, what’s a good experience for them when it comes to support and let’s say what the business needs is just cost, right? Like human time is expensive.

Part of what makes software what it is is that it’s very scalable. You write one piece of software that many, many people can use, but that 30 minutes that the support rep spends on your case, that’s just 30 minutes of human time that they need to be paid for, and certainly it’s skilled work and the more you get into something like a Hiokku or a stripe, you know, Hiroku employs developers, pretty skilled developers in their support role, they have to, like, that’s the only people who can reasonably help you, but then that’s turns out, developers command a lot of earning power.

So here, you know, there’s obviously a relationship between maybe go with like uh ARPU, which is the jargon for average revenue per user, but basically how much you make for each person that’s a customer or user and what kind of support they can reasonably give you and the reason why I don’t know, Google search or social media or something like that can’t give much support is.

Each user just isn’t worth very much, right? So if the ARPU for Google search is $20 a year per user or something, you can imagine a support rep that’s paid $20 an hour, for example, you only have to burn one hour of support time and then instantly you’ve essentially are neutral or have lost money on that user.

So and that actually came to mind with your First Republic was the name of the. The bank you mentioned with the reps standing around it so like I think my first reaction would actually be, oh no, is the bank going to go out of business because they’re sort of overstaffed and for all I know that could be connected to why Speakeasy failed. They had these really skilled people answering the phone at kind of level one support, which I loved, but then as it turned out, you know, maybe that cost more than people were willing to pay for their DSL. I’m not sure.

00:51:44 - Speaker 1: Yeah, well, in the case of banks, I think it’s that sweet 0% deposit funding that they’re after, but I could see it being an issue for something like an ISP for sure.

Yeah, the cost thing is interesting, by the way, you can look at the public financial disclosures of these companies, and I think people often don’t realize how much of the cost comes from sales and support, especially people who have been around startups and early stage companies, we think like all the expenses basically engineering.

And that is true in the very early days of a company, but if you look at matureas companies like engineering or so-called research and development is a relatively small piece of the total expense, a lot of it is sales, support operations.

00:52:30 - Speaker 2: Yeah, other challenges that come to mind for me here is, especially being in the position of being the one to give support, which is, you can’t solve everyone’s problem, at least not immediately, maybe in the long run, you hope you can, people write with feature requests, and in most cases, you know, we might ask for more information or that sort of thing, but in the end it’s sort of, you log that in your system, however, you’re tracking those things, and then you say thanks, and that’s kind of the end of it.

Now I do differentiate a bit between someone has a problem like something happened and I lost some data or I’m locked out or something like that, that we take as a more critical happily we haven’t had a ton of those uses, but we have had some. For example, we created safe mode precisely in response to the crash loop problem, which is that ends up locking you out of your data and we dealt with some pretty frustrated and recently Irate customers as a result of that and so we’re building. And these safeguards to try to handle that situation a little bit, which of course is different from, hey, there’s this bug and it’s really annoying me that every time I do this, this panel pops up in the wrong way and you know, we’ll try to fix it as soon as we can, but we don’t see it necessarily as a critical blocker. It’s an annoyance. We try to have bug hunting days or weeks where we crank through as many of them as we can.

00:53:50 - Speaker 1: Yeah, and on the feature requests and product suggestions front, I’ve had pretty good results with just taking the approach of being honest and transparent.

Like someone writes in and says, can you add infinity pen colors, and we say, yeah, well, you know, we’re probably actually not gonna do that, at least in the short term, but my experience has been that you can use it as an opportunity to like message test or do some lightweight product management.

So someone will write in and say, you know, I love the boards, but I wish there was a way to just kind of put a bunch of stuff together in a pile or a box or something. And they often don’t even know exactly what they want. They’re just trying to describe an issue that they have. And I might take the opportunity to do some lightweight product testing and say, oh, yeah, that’s interesting. We’re actually thinking about doing collections and they’re gonna have these properties and this is roughly how it would work and would that solve your problem. And it might say, oh, not really, because of XYZ or like, oh that sounds great actually. When’s it gonna be ready? Well, not yet, but you know, keep an eye out. And you do that enough over the course of weeks and months, and you build up a little reserve of customer knowledge and product testing.

And I think customers appreciate that. It makes it feel more human and that they’re actually being listened to, because if you just reply and say your request has been noted, that sounds suspiciously like you just put it directly into the shredder. Whereas if you actually engage with them, there’s a little bit of proof of work there, and it feels more real.

00:55:06 - Speaker 2: Yeah, to be honest, I do some equivalent of your request has been noted usually in a case where it’s obvious what they’re asking for because a lot of other folks have asked for it or because they did provide a lot of detail. Maybe I’d be more likely to do that for someone where we’ve had multiple interactions and so I actually know the context already sort of who they are and what they’re using it for and that sort of thing.

But yeah, in the case of a new person that we haven’t seen before in our system and they didn’t provide a lot of context, then yeah, engaging and asking for more information and yeah, it’s a chance to find out what might be a fit.

And sometimes they say, you know, here’s the problem I have, I’d like a feature that does X, and they say, well, actually we have this other feature that does Y that maybe is kind of similar. Can you try that? And they try that and they go, oh, actually, yeah, that gives me 70% of the way there, but I still want these other things. So yeah, that kind of back and forth, but then maybe you realize we could actually kind of extend or expand this other feature and cover their case rather than building the thing they asked for.

I think it’s considered a truism in product work that you don’t just want to directly transcribe user or customers that they want to feature X, I build feature X, the more that you feed that into a complex system of inputs which includes vision, which includes other kinds of user interviews, which includes understanding the market, which includes looking at what competing or related products are doing. Which includes just the stew of interesting ideas and culture within your team, and you just put all that together, and the customer input that largely does come through the support is a huge and important part of that, but it’s just one ingredient that goes into what is hopefully a holistic idea of what your product could be in the future that will solve more problems for people, uh, address a wider audience, and just be more useful and more valuable in people’s lives.

All right, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at UAHQ or you can write us on email, which, as mentioned, arrives in our support queue. hello at musapp.com, and you can help us out by leaving a review on Apple Podcasts. And Mark, I’m glad we’ve been able to develop a simple but effective support system for you that serves our needs but gives the user experience we hope people like. I’m really curious to see how that might scale as we continue to go forward into the future.

00:57:29 - Speaker 1: Yeah, and today is actually my sport day, so I’m gonna go get at it.