Untitled

Discuss this episode in the Muse community

Follow @MuseAppHQ on Twitter

---

Show notes

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