Episode 699 | How to Build Elegant, Scalable Software Products with Derrick Reimer

Rob Walling:
Welcome back to Startups For the Rest of Us. I’m Rob Walling. I’m your host this week and every week. This week I speak with Derrick Reimer. He’s a fan favorite guest on this show. He’s the founder of SavvyCal, what I call the best scheduling link on the internet. And today we answer a handful of listener questions from a single listener, a bit about UX design, how to prioritize and build features that scale. We talk at the end. There’s a bonus question about podcasting and just how to get better at that. All in all, it’s I think a really informative and casual conversation between Derrick Reimer and myself. 

Derrick and I have known each other for, I don’t know, 14 years or something. So these episodes flow very naturally and I feel like hopefully the content in this episode in thinking about product decisions and UX paradigms and just we relive some moments from building Drip as well. Hopefully these are inspirational as well as provide you with some actionable things that you can implement in your own entrepreneurial journey. 

Before we dive into that, tickets for MicroConf US in Atlanta next April 2024 are on sale. This event will sell out. If you’re thinking about coming to Atlanta, April 21st through the 23rd to see me co-host this event with Lianna Patch and to see speakers like myself, Rand Fishkin and several others, head to microcom.com/us to grab your ticket before they sell out. We had an amazing event just a few months ago in Denver, and I expect the event in Atlanta to be no different. So MicroConf.com/us to grab your ticket today. So with that, let’s dive right into my conversation. Derrick Reimer, thanks for joining me on The Startups For the Rest of Us.  

Derrick Reimer:
Thanks for having me back. It’s always a pleasure.  

Rob Walling:
Yeah, it’s good man. It’s good to catch up with you. I have several questions today from a longtime listener, Alan King. He’s a multi-time MicroConf attendee and he pinged me with some questions and eventually I said, “You know what? Just record them as audio. Derrick’s coming back on the show anyways, I like having him on.” 

So let’s talk through them. A lot of these are going to be around UX design, attacking different verticals stuff based on your experience and knowledge. So with that, let’s roll into our first question.  

Allen King:
Aloha Rob, Alan King here with funjoin.com. I’m a loyal listener, big evangelist and fellow Jedi Master in practice of course. What are the top three things that a senior UX designer needs to consider when scaling a product like Drip?  

Rob Walling:
So when Alan asks this, I think less about scaling throughput of billions of records and rows, I think as an app scales to many users with disparate experience and technology level or I think of even how do you scale this to different use cases. So how did Drip serve bloggers and SaaS founders and we had some media brands on it. We had e-comm, that’s a form of scaling. And even just functionality, if you know you’re going to become a complicated app or you kind of already are, how do you allow that to happen without having a terrible user experience. Salesforce, I’m looking at you. It’s like that kind of stuff where it’s just bloat and all that. How do you think about this and whether we do top three or whatever it is, what are the things that you’re thinking about? And I know the answer because you and I did this for years, but I’m fascinated to hear what you’re going to say.  

Derrick Reimer:
Yeah, this is a big question and a really tricky one because as you mentioned, just as an example, something like a Salesforce, it’s really difficult and some of the most successful software products in the world in terms of revenue or market share actually do a pretty poor job at this and end up having to fall back on a lot of training or handholding or just at a certain point, a lot of these products end up having their own kind of university or training program with certified people to just help people wrap their minds around how to actually use the thing. So I mean part of this is there’s always going to be this tension of at a certain level of scale and complexity, you’re just going to find there’s more and more support burden and training and supplementary things that need to go along with it. 

But I still think it’s a worthy ideal to try to architect your product as well as you can so that people don’t feel like they have to constantly be reading the docs or asking support or whatever. So all that to say, I think a couple of things come to mind. I remember when we first hired our first outside designer besides me at Drip post-acquisition, one of the first things he did was starting to think about the design of the application more as a design system. I think before that point, each interface that we built was sort of an ad hoc thing. It was sort of its own creation. I think in the early days of building a product, that’s that’s how I’ve found things naturally happen. You don’t really know how the product’s going to take shape. What do the setting screens look like when there’s five pages of them and a bunch of different sections? 

I mean early on you usually have a page of settings and so you kind of start with just what you need to begin with and you design that interface ad hoc and then you realize, “Okay, I need to add another tab here and what are the pieces that are actually reusable?” So we’re not having to constantly rethink, “Okay, now we have a new setting section. How do we approach designing this? Are we using check boxes or toggles? Are we using native dropdowns? Do we have a custom dropdown that has more information stuffed into it?” 

And before you know it if you’re not thinking in terms of a design system, then you can end up with a hodgepodge of different choices that don’t really speak the same design language. So it can be kind of confusing and it could also be a lot of effort for your team to, if every single interface requires you to kind of think from the ground up. How this is going to look, what components you’re going to use, it just becomes really difficult to maintain, difficult to scale and costly because you’re doing a lot of repeat work. 

So something that, I mean a design system, I think it doesn’t necessarily have to be what you see some of the bigger companies or bigger startups doing. I think Airbnb is an example that they have a huge website that’s just all of their component libraries and everything is parameterized and it’s like they almost built their own custom library of stuff. I think other companies tend to do this. When you’re small, that’s way overkill. And I think we had something sort of that we could gradually build out. So I think he started with a single page, Brian, our first designer, started with a single page, let’s just standardize our buttons, form elements when we display a table, unless it’s a really, really custom thing, we can just use this standard design and banners and icons. So we just started to standardize these elements. It made the process of building new interfaces a lot quicker. So that’s probably my first thing.  

Rob Walling:
That’s solid gold advice right there. And it’s funny, because I had forgotten that. So I jotted notes of my own things and it’s super tactical things, but when he says top three pieces of advice that is, that’s the top three, to have some type of design language. And I remember because the way we got that far was you were the only designer and so everything you designed, you’re like, “I remembered I put it over on this page, copy paste.” But the moment we had two designers, that doesn’t work anymore because they don’t remember that you put the toggle over here, you had the multi-select or whatever. 

So that’s what it was his job to go through and look at all the work you did and say, “Let’s put it into this single kind of internal knowledge base thing.” If I remember, I don’t remember what the software was, but it was something, and like you said, it was pretty lightweight and it was built out as we went. That was something that you and I think for the betterment of everything, we were pretty resistant to heavy process and we’re not going to build out all these UI components, custom Drip dash whatever, right? Like we don’t have the bandwidth for that. Even with the team size, we did  

Derrick Reimer:
A couple kind of tactical things to add to this bullet point I think too, and these are things that I’m thinking about as I’m building SavvyCal. We’re still very small. I do most of the design work, but I am keeping in mind ideally I want my developer to be able to take a first crack at an interface and be able to pull things off the shelf that we already have designed and I may need to go through and do a design pass on it to make it kind of pixel perfect or whatever. 

But it’s similar to when you’re thinking about architecting a good code base for the user experience side of things. You can think about it similarly where you kind of abstract, you take pieces that are reusable and you’re not repeating yourself over and over again. So depending on what your front end technologies are, if you’re using React for example, then you can start to build out a directory of React components that are kind of generically named that you can use and those would hopefully bundle in kind of the style parameters that you’re using. 

I love Tailwind CSS. There’s a reason why it’s become so wickedly popular I think is because it gives you sort of the fundamentals for building out your own design system and it kind of eliminates, at a minimum, it gives you sort of units for putting margin and padding on things, which seems small, but being able to just say, “We always use a margin three to space elements out in a form”, it’s a lot better than making sure that you put margin 13 pixels or whatever it would end up being. You end up with some 12 pixels in there and some 16 pixels. And if you’re just making these little visual tweaks all the time, then you’re ending up with a lot of inconsistency. So things like utility styles like Tailwind CSS can help you constrain the number of choices you’re making all the time.  

Rob Walling:
Very nice. You want to dive into your number two?  

Derrick Reimer:
Sure. Number two, this is sort of a little bit amorphous, but thought about, it’s just understanding how customers are actually using the product. Because I think I find myself occasionally getting bitten by this where it’s like I hear a use case and I kind of know fundamentally what we need to accomplish, but it’s so easy to get the flow wrong where you realize the way that people are actually expecting to use this is they want to… I’ll just give an example. People will often say, “Okay, I’m going to share a scheduling link with somebody and I want to propose sometimes”, but they usually go through the process of wanting to maybe edit the link and then go preview it and then from the preview page go and propose times. And if I don’t have a propose times button on the preview page, then I’m requiring them to click back through to a different part of the application to get to that thing. 

So there’s these friction points that that’s not a huge deal, but they can start to add up over time to where people gain this perception that your software is clunky or the things that they’re expecting to be there are not in the place that they’re expecting them to be. And a lot of times these insights don’t come unless you’re actually trying to get this qualitative data from customers. And there’s a few different ways that I’ve seen people do this. 

We used to use Full Story I think was that software. I mean it’s a little dicey from a privacy perspective. I think there’s some things you can do to black out the screen to hide personal information or whatever, but we used to literally have a TV screen up in the office, remember this?  

Rob Walling:
Yup.  

Derrick Reimer:
And you could just walk by and watch customers actually step through the interfaces. And it was so fascinating to see when people would just get stuck on a page and the cursor would kind of move around and you could tell they’re confused and that kind of stuff is gold for figuring out what are the friction points, how can you make this more intuitive?  

Rob Walling:
I like that one a lot. And I think you had said before we hit record, you’re like, “Some of these feel like they might be obvious or they’ve been said before” and it’s like, yeah, kind of in different ways, but this stuff bears repeating. It’s that important. It’s like we as technical folks, I don’t even mean developers, I just mean product people who know how to use products. We have a very high ability to just learn stuff really quickly and most of our users do not unless you’re serving other product people. And it’s so easy to forget that my dad doesn’t know when I say, “What’s your web browser?” He’s like, “Do you mean my Firefox”? He doesn’t know what that term means, and he’s 80 years old. So that’s just the way it is and we can easily forget that we have the curse of knowledge. 

I want to piggyback on that a little bit with something that’s similar but different. It’s not exactly what you said, and I want to give an example and the thing I’m trying to communicate or my point here has also been said on this podcast, but it’s listen to your customer’s problems but not their solutions. So learning how they talk about it, what they’re actually trying to do, what are you trying to do with that? What are you actually trying to do with that? What’s the big picture you’re trying to do with that? Because usually they’re not even in the right neighborhood of the application to do what they want to do and they want you to add a checkbox and a dropdown on this page. You’re like, this makes no sense to me. But it turns out, oh, if we go to this settings page, we can add something. 

They’re completely different side if you actually know what they want to do. And I want to bring up the example. One of my favorite examples, Derrick. All right, so if you log into Drip or if you use any type of email marketing software where you have a sequence of emails, we used to call them campaigns. And so you have a table view and let’s say you have five or six emails in a row and it’s like one is welcome and then second is, Hey, you downloaded a sample chapter in my book and the third is what did you think of the sample chapter? And they’re sent days apart on a schedule, right? Pretty simple. It’s in a lot of piece of software. We used to get a lot of requests for people saying in between the first email and the second email, can you add a button or an option to where I can put an if then L statement? 

If they have this tag then I want to send them a different email or skip the next one in the sequence or add a label or just do something. Can you add a checkbox that allows me write in there? And it was always like, this is interesting. This person obviously has a problem, they have a problem, but their solution is catastrophic. As a product person because there’s no way. If we listen to their solution, it would’ve just been a spaghetti code mess or a visual… Talk about technical debt. Visual technical debt is brutal. It’s hard to solve. And we heard those for months and months and we were like, I don’t know what the solution is, maybe we should build one of these things. I don’t know. And you remember what the solution was after a year of hearing these? It was building workflows.  

Derrick Reimer:
Workflows, yeah.  

Rob Walling:
It was completely different paradigm. It was us saying, wait a minute, we need a visual builder where people can put a box on a thing that sends an email and then have a split and if then, this and that. It was a whole other feature and we still kept the campaigns in the table view as well, right? The sequence because a lot of people were like, it’s a clean view and if you’re just sending stuff in a certain order, it’s really nice to have that sequence actually embedded in a workflow. There were competitors of ours where if you wanted to send 10 emails a day apart, remember you were adding 10 different boxes to this visual. It was very cumbersome and ours was actually a more elegant solution. So that’s what I want to bring up. There’s just one example. If you listen to this podcast, you’ve definitely heard that paradigm before.  

Derrick Reimer:
And I think that’s especially applicable to what Alan’s describing here where I think he’s kind of getting at, he’s working on a product that serves a lot of different kind of use cases. So you’re going to hear, especially in this case where you’re pretty horizontal, you’re going to hear really strong opinions from customers phrased in the way that they’re used to solving the problem. And the trickiest part about building a horizontal product is that you’re trying to look for what’s the abstraction between these kinds of disparate requests that are sort of pointing to the same thing but they’re pointing to it in a different way and can we figure out a solution that sort of satisfies the verticals that we want to hit on, but without it being too specific to one where you end up with something that only applies to a small number of customers. And it’s hard, it’s very difficult, but that’s the challenge.  

Rob Walling:
So to wrap up this topic, I actually have two more tactical things maybe that I want to throw out. One is pay more attention to naming than you think you should. Just naming anything that appears in a top nav, any label on anything. You and I used to sit in front of that whiteboard at the first Bitwise building in Fresno and when we were building automations and tags and events and labels and custom feed, all that stuff, we wrote it all out, whiteboard, whiteboard, we were in there for hours saying, “Okay, first what are the paradigms? Let’s get our head around them, how technically what they’re going to do, what are they going to do in the UI? Just mentally, all right, I think that makes sense.” Name value pairs versus things with a date, that’s a custom field versus an event. 

And then we said, “What do we call these? What do we call them?” And we would, hours just agonizing we’ve got to brainstorm. Well, what does the rest of the industry call them? Do we want to be in line with that? If MailChimp calls them this thing and Infusionsoft, which is now called Keap, I believe if they call them this thing, what if that’s a really bad name? Infusionsoft named their stuff poorly and so a lot of times was just like, that’s not actually what this is, but they did it and so people thought that that name meant that thing and so we were trying to stay in line with them like tags. Okay, everybody knows what a tag is.  

Derrick Reimer:
I’m actually curious if you feel like, because that was something I remember, what was it like a campaign in MailChimp was actually a broadcast and we called them broadcasts and then our campaigns were sequences and theirs were called what autoresponders or something?  

Rob Walling:
Yep.  

Derrick Reimer:
And I remember there was friction around that. I actually don’t know the answer to this. Do you regret how we chose to originally name things or do you think is there wisdom in just staying in line with the bad industry names for certain things or is it worth fighting back and naming well?  

Rob Walling:
Here’s the thing, I think the advantage Alan has is I don’t think there’s a MailChimp or a Salesforce in his space. I don’t know of one, so he probably has more flexibility than we did naming. But to answer your question directly, I couldn’t have lived with myself if we called broadcast emails campaigns. That is not what that is. But it would’ve bothered me every day I logged in because I would’ve been like, “Yeah, so in order to have MailChimp people get an easier way when they start using our product, we did this.” Now with that said, have you logged into Drip lately? You go to campaigns and then there’s a dropdown list with I think three different things and there’s single email campaigns, email sequence campaigns, and I believe it’s like a website campaign, something like that. I’m messing up the naming, but you get the idea. 

They grouped them under that same thing, probably because MailChimp and others did it. So I don’t know, man, this is that hard part of you’re a product person, you’re so opinionated and taste, I want to really love what we build, but it’s the intention with industry norms, ease of onboarding, ease of support. That’s exactly what we’re saying here, right?  

Derrick Reimer:
Yeah.  

Rob Walling:
All right, last thing I want to chime in. This is so tactical, so we’ll go real quick on it. Hiding features. If you have features that people request and you’re like, “Boy, only one vertical uses this, or even this whole screen or this whole section”, you can build versions of your application that just hide a bunch of stuff from certain people or only show it to a certain, there’s a feature flag. There’s a flag on their record. If I had three verticals or four verticals I was serving that really were different, we had a lot of verticals using Drip, but we figured out a way to generalize everything. 

If I really needed the naming to be different and let’s say realtors have clients and so-and-so has customers, whatever. It’s naming of labels or of top nav stuff, I would consider having just a different type of account and this is a realtor account versus a brick and mortar account. I don’t know, we didn’t have to do it, but having that bit. 

But the example that I actually want to bring up of hiding features is the feature we didn’t want to build but people were requesting it. You know what I’m going to say. RSS to email, I hate that. Where it’s like, well I have this blog and I’m publishing stuff anyway and I want an email to go out for each one. And it’s like that’s not a very good way to do email marketing, but a bunch of people wanted it, so we built it and only the people that had requested it, we checked checkbox and they saw it. And then over the course of years and we had a KB article about it, I think by the time we left 50 people had access to it out of tens of thousands of users.  

Derrick Reimer:
It was such an interesting one because yeah, if the demand had been lukewarm, we probably would’ve just said, “Sorry, we don’t have it.” But I feel like at the time, maybe it was like AWeber or one of those kind of older school ones, everybody who was using that publishing workflow relied on the RSS to email and it was just a hard blocker for them.  

Rob Walling:
Yep, for them to switch.  

Derrick Reimer:
I actually don’t know, maybe people are still using that, but I feel like RSS has sort of become less integral to the publishing workflow and now there’s Ghost and there’s the email sending platforms are trying to become more of the publishing platform also. So the trends have shifted and yeah, there probably still remains a small contingent of people who love that magical feature that just automatically sends emails when the RSS feed updates, but it was a real nightmare to maintain. q  

Rob Walling:
It was a pain. And so you might ask, “Well why did you build it then?” And it’s exactly what you said. We were literally losing deals over just that and they were significant deals. They were hundreds of dollars a month, obviously thousands of dollars in ACV at a time when we were, I think we built it when we were 20 to 30K MRR and I knew that there were thousands of dollars of MRR, at least a few thousand that we could get with it. And so it became that I don’t want to build this, but I am going to grit my teeth and build this, but I’m going to hide it just to try it. I just don’t don’t want to support it for what wound up being thousands, tens of thousands of people. I don’t want to promote it as a good email marketing practice. 

Finding the perfect software engineer for your team can feel like looking for a needle in a haystack, and the process can quickly become overwhelming. But what if you had a partner who could provide you with over 1000 on demand, vetted, senior, results oriented developers who are passionate about helping you succeed, and all that at competitive rates? Meet Lemon.io. They only offer handpicked developers with three or more years of experience and strong proven portfolios. With Lemon.io, you can have an engineer start working on your project within a week instead of months, plus you won’t waste your time on candidates who aren’t qualified. 

Lemon.io gives you easy access to global talent without scouring countless job boards, and it’s more affordable than hiring local talent. If anything goes wrong, Lemon.io offers swift replacements, so it’s like hiring with a warranty. If you need to grow your engineering team or delegate some work, give Lemon.io a try. Learn more by visiting Lemon.io/startups and find your perfect developer or tech team in 48 hours or less. As a bonus for our podcast listeners, get a 15% discount on your first four weeks of working with a developer. Stop burning money, hire devs smarter. Visit Lemon.io/startups.

With that, let’s roll into Alan’s second question.  

Allen King:
Also, do you have any suggestions on best practices to scale new products that serve different verticals once your main PMF has been secured and profitable?  

Rob Walling:
We’ve already talked a little bit about if it’s not an independent product, but actually keeping it as one how you might think about either generalizing things or having different account types that show different functionality. I will be honest upfront, I wouldn’t add multiple products unless I really, really, really needed to. I would hold off. This is that thing of translating my product into other languages, into Spanish and German. It’s just usually, can’t I just find more customers of this type? Have I maxed out the entire market? And I find that folks who want to launch additional products, it’s just so much more work than you think it is. So that’s kind of a blanket thing. I’m not saying don’t ever do it and we can still answer the question, but that’s kind of my overall opinion on this topic.  

Derrick Reimer:
Yeah, I think as we riff on this we can maybe come to some thoughts about how to do this well, but I agree that it sounds like he already acknowledges that it’s really difficult to serve a lot of different verticals and keep everybody happy at the same time. So my gut is just from a strategic standpoint as he’s thinking about, all right, we’re continuing to grow the business, we work really well for a bunch of these people. I’m sure he is finding some of these market segments are just, the customer type is just not the type that he wants to serve, hopefully. 

Hopefully he has some clarity around that even though they’re making it work, does it feel like you’re fighting against, they’re constantly kind of dissatisfied to the point where the way you want to take the product and the vision you have for it just doesn’t really seem to overlap with what this one particular use case is? Then I would urge you to consider just narrowing away from that and trying to identify who are the few, and hopefully you can find enough commonality between their use cases that you can have a roadmap that is generally speaking to the needs for all of those segments. So those are my initial thoughts on just narrowing focus a bit.  

Rob Walling:
Yeah, narrowing focus I think is what I would try to do as much as possible and to not serve. I mean by the time, again, if you’re serving four or five verticals but it’s all within the same app and generalizable, that’s fine, but it’s when you start, you have 10 different kind of use cases and you really need 10 different apps or this component. I think of HubSpot with modules and Salesforce and modules that you add on and remove. And maybe that’s the answer is that there truly, I was talking about having account types earlier that just hide and show stuff automatically, but that can easily turn into a paid add-on for this extra module and that’s a pattern that we see with enterprise software. 

To me it just feels complicated when you’re early, that feels complicated. I don’t see most companies below seven figure ARR trying to do that. And is that a sign that either you’re trying to do too much, you’re taking just a little too big of a bite at the apple or you’re not saying no to enough things? And just being like, “You know what, we have one customer type or two or three that work and unfortunately we’re just not going to serve this other market.” 

I don’t know, without more information. I obviously can’t give specific advice, but it’s an unusual pattern. There’s a little yellow flag for me if you’re trying to solve the problem in the way that you’re describing it where it’s like I want all these modules. And again, I’m assuming Alan’s early stage, we don’t know his revenue.  

Derrick Reimer:
I think what we kind of touched on earlier where if the main difference is just nomenclature for example, then that feels like something that’s solvable. Even if it’s like, I’ve seen products do this, I think Stripe does this with their checkout product where it’s like do you want the confirmation button to say purchase product or should it be subscribe or should it be, they have different ways to customize what the fulfillment button says to indicate the type of thing. It’s something we’ve considered with SavvyCal. We generally refer to things as meetings, but that’s not always the intention. It’s not always a meeting. Maybe think of it more like a session or I don’t know. There’s just different kind of ways to identify the thing and if that’s really the main difference, but all the other mechanics are the same, then that seems reasonable to try to figure out a way to allow that level of customization. 

But to just give another example, that’s something that we bump up against. We have a certain type of customer that loves our core functionality, but then they want this whole sort of buy a pack of time slots and then you can eat away at your balance of credits that you’ve purchased for a certain number of meetings and maybe you want those recurring and it starts to just spider out into this whole separate thing. It’s not something I’m necessarily opposed to doing, but that sort of thing we’ve really been careful in gathering customer requests and insights and really thinking hard about it. Can we see a world where it makes sense to add this onto the existing product? 

In some ways it almost feels like a completely separate product or a completely separate module where it’s like, okay, now you basically have sort of a commerce tab of some kind where you’re storing a lot of information about customers who have bought a certain number of time slots and now you need to manage state around that. So it’s a huge kind of build out that we’re very hesitant to do unless we feel like we can actually be competitive in that area and it won’t wreck the user experience for the rest of the product, which is a big consideration. You don’t have to feel like, it’s easy to get to the place where you used to be the simple elegant solution and now people start saying, “Well, it’s sure feeling complicated over there” and you never want to get to that place if you can at all help it.  

Rob Walling:
Yeah, and that’s where I think, I like that example you brought up because I think of Squarespace, which started off as a website builder, but now Squarespace Commerce is a big thing and it’s a decent shopping cart. It’s not the most sophisticated, but I use it to sell the SaaS playbook. So SaaSplaybook.com is hosted on Squarespace, and then I have other sites that don’t have commerce built in. And there’s a selling thing in the left nav, and if I click it and I don’t have the commerce, it just says, “Oh, you could sell stuff if you wanted, click here to upgrade. And if I have a cart and I have sales and I click in, it’s my whole dashboard. And you could easily make it that if I didn’t have selling, it just didn’t appear in the left now. That’d be the thing is how modular can you make this and I mean it goes without saying, keeping consistent UI and UX paradigms per the first thing to do.  

Derrick Reimer:
Yeah, I actually have one other thought that just occurred to me too. If you already have some existing patterns on how you build external integrations with other platforms. I don’t know if Alan has any of those at this point. I’m sure he does with calendars or whatever. So you think about how you generally build those into your product. In SavvyCal for example, we have on links, we have sort of a little automation or integrations area and you can basically install an external app. So if you want to send booking information over to HubSpot, you can click a little dropdown, say add an integration and then send contacts to HubSpot. And you install that and there’s a little bit of configuration, choose your account, connect to your HubSpot account or whatever. 

And now you have this sort of modular connection between a scheduling link and your CRM. And it is interesting to think about can you apply those similar patterns, similar ways you would think about integrating with external products, but do that with your own internal modules as well? And I think there’s a lot of patterns you can sort, even though I think you wouldn’t want a whole separate app that you log into. Ideally it would be a module of some kind inside of your core monolithic application, but can you treat it as you would almost an external integration if it’s separated enough?  

Rob Walling:
I think that’s a very elegant way to think about it. All right, let’s dive into Alan’s third and final question, but he actually sent me a relevant super bonus question that maybe if we have time, we’ll answer at the end.  

Allen King:
Lastly, does Derrick Reimer have any processes that he’d like to share for creating articles, change logs and updating content when it becomes dated? I’m a big fan of his knowledge base and his SavvyCal product as a whole. I love the work you both did on Drip and I’m very grateful for all the work you’ve done for our community. Looking forward to MicroConf this year. Thank you. Thank you. Thank you. Aloha from Hawaii. Peace, see you soon.  

Derrick Reimer:
So I use Help Scout’s knowledge base feature, which is pretty nice because it integrates deeply with their Beacon widget. So when someone clicks the help tab in SavvyCal, it opens the beacon and they can start to type a question and we can surface knowledge base articles to them. And if those don’t satisfy their question, then they can send an email to us. So that kind of integration is pretty nice. I think Alan’s using Intercom maybe, and I think they have a very similar type of thing. I took a peek at Alan’s knowledge base. It looks like you’re off to a really good start on that. 

But yeah, we generally, when building any feature of substance that’s not a tiny thing, I usually default to wanting to publish some kind of knowledge base article, something very specific to the feature. And the title is usually something, it’s not like I’m trying to describe an entire subsystem in one article. We keep them pretty granular, almost phrased like the answer to a question if someone was asking the question. And for most projects we just drop a ticket in the project management system for that. So the project’s not considered done until we have a little KB article. 

And I also have, speaking of component libraries, like a lot of the settings sections that we have, we just default to having a little info icon in the product that requires a URL to a KB article. So it’s a good forcing function for us to make sure that we have somewhere to send them if they were to click the info icon to learn more about the feature. And I also like to, I use Headway for our change log and we have a little widget in the app. It’s that standard pattern when there’s something new, it’s like a little red dot with a number on it and you can click it and it shows the little top five things in the change log. 

And that’s just a helpful way to surface new stuff. I mean, it’s hard to keep new customers abreast of features and also existing customers who aren’t necessarily receiving onboarding sequences and things, it’s hard to keep them aware of new stuff happening. So I feel like that’s a good touch point for sure. And similar to the KB articles, we generally as part of the launch plan for any feature, bias towards just dropping something in the change log. And I try to keep those really, really concise, like one or two sentences and I have a little template, so I usually try to include a screenshot, something that represents the feature. And yeah, it’s not a huge burden because we plan on keeping those short. Try to speak to how this improves the customer’s life. So describe the functionality of the feature and also why they should care. And just a couple sentences and yeah, that’s just kind of integrated into our process.  

Rob Walling:
Ladies and gentlemen, a masterclass in how to maintain your KB. Thank you, sir, we should record that, sell it as a course. It’s just a really good thorough answer. Very concise.  

Derrick Reimer:
And I think another note on keeping things up to date, I mean is that’s hard. I think there’s probably some stuff in our knowledge base that’s a little bit outdated and if it’s just small changes to the UI, I don’t think it is a huge stumbling block. So we are not necessarily keeping on top of every single screenshot to make sure it looks identical to the current UI. But what we do is empower support agents to make any changes to the knowledge base at any time. So if they are sharing a KB article, which we often do in support, we’ll explain how something works, but then we’ll also include a link to the knowledge base article. It usually has just a little bit more expansive detail than the specific response. I think our support guys are used to looking at the knowledge base article to make sure it’s relevant and if they notice something that’s out of date, they’re spending a lot of time in the product helping diagnose things for customers or explain things. 

So they usually will spot if something’s out of date and they can just grab a new screenshot. I like to use CleanShot, but there’s a bunch of different apps that’ll do that. That basically lets you take a screenshot and draw an arrow. That’s the default way that we do stuff. Put arrows on product screenshots, and those are really easy to replace. Things that are a lot harder is like if you have videos that have a lot of shots of the product, there’s a much higher cost to updating those. For that reason, we generally skew towards text and images, which are easier to update.  

Rob Walling:
In the early days, getting a loom or equivalent recorded for your support or for your KB is way faster to do. Over time, it is essentially a type of debt, video debt, documentation debt. We did that with Drip in the early days, right? Instead of writing a long KB article, I just recorded a video and it was great and it got us going, and then we had to go back and redo. Basically I paid someone to redo all those and basically turn the videos into written. And that’s why most KBs are written because the video is just hard to maintain. It doesn’t mean you shouldn’t do it, just know that you’re going to run into some issues down the line. 

I like what you pointed out about keeping things up to date that you kind of do the best you can because even again, when we left Drip, it was doing tens of millions a year with tens of thousands of customers and there was still stuff that was, it just gets out of date and you just don’t pick it up. So it’s one thing I would, you do your best and just know that there’s going to be stuff that’s out of date at any, it’s not going to be perfect and it doesn’t need to be, and you can still be wildly successful. 

All right, you want to take a crack at this fourth super bonus question about podcasting? I love talking about podcasting. Yeah.  

Derrick Reimer:
Oh, sure.  

Rob Walling:
His question is what magical wizardry secrets or dark, scary, painful pitfalls would you give to your virgin podcast selves before you got started actually podcasting? I have a couple of things that come to mind. One is, fewer people are going to listen to you or care about your podcast than you think, especially in the early days. And that’s a good thing because you’re not going to be very good when you start. I’m talking to me, by the way. Just to be clear, me 14 years ago, it’s just not, you can go back and listen to the first five episodes of this show. 

They’re not very good. We don’t have the energy, we’re not concise enough, there’s just a bunch of things wrong with it. The audio quality isn’t very good, et cetera, et cetera. And that’s okay because I put in the reps and eventually you get better. So fewer people listen to you in the early days. I stressed about it in the early days. “I’m on the mic, I’m so nervous, oh my God.” We’re all going to be nervous. It’s fine, realize that fewer people listen to you, and hopefully it helps you just be more of yourself. 

Second thing I want to say is the only way I know to get better at it, some people are naturally good at it. I will give them the first time they get on the mic. They’re amazing. Most people that I know are not, the only way I know to get better is to practice. It’s just to do a bunch of reps. And again, if you go back and listen to the show by the 10th or 15th episode, it’s like, “Oh, that’s not terrible.” By the 30th it’s like, “Ooh, these guys kind of know what they’re doing.” Practice and listening to other podcasters, I would say both because just doing the same thing over and over doesn’t make you better. But I would listen to other podcasts and say, “Ooh, this is very entertaining. All of a sudden, why am I entertained by this? Can I do that? Does it fit to adapt that approach to my show?” 

So practice and developing taste of what a good podcast is, I think is a thing. The third one that took me a very long time. In fact, if you go back even, I don’t know how many years, but you go back six or seven years, I still wasn’t doing this until again a few years back. But it’s to have just a little more energy than you naturally would. Like if you and I, Derrick were on this call and just talking about SavvyCal strategy or talking about Dungeons and Dragons and the nat 20 that Darren rolled last night on his persuasion check, we would just be talking and having fun. 

Somehow, when you do that and talk naturally, you sound subdued and with low energy. It’s just this weird thing that cameras and microphones do. And so now at this point, I naturally switch when I’m in front of a microphone, I talk just a little bit different than again, if you and I were hanging out. And it’s just a one notch above in energy. That was a very difficult and painful thing for me to, it was felt very unnatural, like I was faking it, like I was not being me, like I was being hyped. Why am I acting like this person who’s excited when I’m not actually excited when I say, “Welcome back to Startups For the Rest of Us. I’m your host, Rob Walling.” That’s how I say it now. 

But when I say it, I’m like, “Oh, that feels weird.” When I listen back, I’m like, “That’s a good intro.” And when I listened back to intros from 10 years ago, I’m like, “That intro sucks. It’s boring.” So there’s something about energy and learning how to channel it in a way that feels authentic. To me, I am not on this mic if I’m not being me and trying to be authentic, but you have to be a little more energetic than I think you would naturally.  

Derrick Reimer:
Yeah, I think because I’ve heard people go too far in that direction where it’s like, “Hey, I’m trying to have a radio voice”, and they talk that way the whole time and it’s like, “Ooh, that’s too much. That’s too much.”  

Rob Walling:
Yeah, it’s terrible. It’s not authentic.  

Derrick Reimer:
So it’s the authenticity piece. And I think, yeah, it does take practice to figure out how to do that. I mean, I don’t know any other way other than reps and listening back to yourself. I was a very reluctant podcaster from day one. I mean, Ben Ornstein can attest to this, that he basically had to pull teeth to get me to agree to just first start guesting with him. And then he was like, “You want to kind of do this for the foreseeable future?” And I was very hesitant because I didn’t feel like I had a natural knack for it. I didn’t think I sounded smart or funny on audio. It took a lot of getting past my own barriers, and it helped to start to hear from people like, “Hey, I really enjoyed, that was great.” And I was still not convinced for a long time that it was any good, but I just kind of persisted through it. 

I think this is sort of a hack, is having a co-host that you have good rapport with. Is it the kind of person you could just have a 30-minute-long phone conversation with and it would feel pretty natural, or is it stilted? Because if you can’t have a normal conversation, it’s going to be hard to have a good podcast recording together. Because a lot of times podcasts, especially interviews and even more conversational ones, they often end up being kind of like, I talk for a while, then I mute, and then you talk for a while, and then you mute. 

And I have found trying to steer it more towards feeling like a conversation, even if I’m responding with uh-huhs and things, that can all be cut in editing, so you don’t have to keep all the kind of conversational connective tissue in place. But I find that the more I do that in the course of a conversation over a podcast, the more authentic the edited version feels. And to that point, good editing. I would say, if you’re wanting to seriously produce a podcast, have an editor edit out the awkward pauses and things, because that makes a huge difference. I’ve listened to the unedited version of a podcast I’ve done, and then the edited versions, and it’s way better with good editing.  

Rob Walling:
That one didn’t even occur to me because editing is just something we’ve done from day one. And you used to edit a lot heavier in terms of cutting out ums and ahs. There are just a lot fewer ums and ahs these days. You do it long enough and you stop doing that. I want to revisit something that you touched on that is something I do and hadn’t occurred to me that I would need to say it, but I call it game tape. When I used to play football, ran track, we would watch tape of ourselves. This tape, it was, yes, it was on a video recorder of some sort. It was before digital. It was the nineties people. 

But we watched game tape and be like, “Ooh, yeah, I shouldn’t have done that. Oh, I could get better doing this.” To me, I’ve listened to every episode of every podcast I’ve ever recorded, even the interviews, as far as I know, as long as if people let me know that it went live, I go and listen to it. 

And I don’t do it as some ego thing or to say, “Ooh, aren’t I smart?” I actually listened to it to say, “Huh, I should have communicated that better.” Or, “They asked me a question that I didn’t know the answer to, and I can feel myself kind of vamping and I eventually usually get to something. But the first 60 seconds of that was a non-answer, so I’m going to do better next time.” And the other thing for me is I will listen back and be like, that was a really interesting framework that it just occurred to me on the show. I said it once, I never said it again. And it’s like, that should be in a book or that should be revisited on the podcast. I’ll actually pull nuggets out of old conversations that just happen to be on tape. And so listening to game tape, I think the number one reason is to get better. And you’re going to cringe the first few times for sure, but then you’re going to realize, “Okay, so I say um too much. How do I work on saying um less?”  

Derrick Reimer:
Yep. And something that I discovered too is that I would often leave a recording session feeling like that was terrible. And then I would go back and listen. And I usually had some takeaways on things to improve, like you just described, but I also usually came away with the feeling that that was not nearly as bad as I thought it was. And that was a reinforcing thing of, you know what, yeah, you’re not going to be perfect at it. Nobody is, but this is not as bad as your brain was telling yourself that it was.  

Rob Walling:
That’s a really good point. I agree with you there. Any TinySeed founder that comes on this show, I kind of force them in a nice way. I say, you need to listen to this interview because, and the reason I only do it for TinySeed founders is I feel like I have some sway over there. You know what I mean? Or some input into how they operate professionally. And so I’m sure not all of them do, but I really, really encourage people to do it, to listen to the interview, just to be like, oh, that part was good and that part was bad. And try to evaluate it and be honest. And of course, you cringe a little bit, but that’s how you get better.  

Derrick Reimer:
And to tie it back home too, the same applies for your product. Watching people use your product, you’re going to learn a ton, and it’s one of the most painful things you can ever do.  

Rob Walling:
That’s so painful. Dude. No doubt. Thanks for those questions, Alan. I hope, yeah, I hope our answers were helpful to you in your entrepreneurial journey. If you’re smart and you’re like Alan, then you’re coming to MicroConf in Atlanta here in just a couple months. It’s April 21st through the 23rd, and tickets are actually going pretty fast right now, and this will sell out. I don’t know when, I don’t know what month it’ll be, but if you’re considering it, you want to head to MicroConf.com and pick up your ticket. I’m speaking, Rand Fishkin, Asia Orangio. Lianna Patch is co-MCing with me, and I think we have another super special guest that Xander’s waiting to announce. So yeah, grab your tickets. And Derrick Reimer sir, thanks so much for taking the time today.  

Derrick Reimer:
Yeah, of course. Thanks for having me.  

Rob Walling:
Dropping mad knowledge. Folks want to keep up with you and they want to see the best scheduling link on the internet, they can go to SavvyCal.com and of course, follow you on Twitter @DerrickReimer.  

Derrick Reimer:
Indeed.  

Rob Walling:
Thanks again to Derrick for coming on the show. It’s always great to have him and hang out for 30 or 40 minutes. I hope this 30 or 40 minutes has provided you with some tactic or strategy or maybe some inspiration to think about building and growing your business this week. I’ll be back in your ears again next Tuesday. This is Rob Walling, signing off from episode 699.