Matt Goldman CEO of Churn Buster

Episode № 18

Matt and I talk about running a SaaS business after acquiring it, the mistakes they made early after taking over Churn Buster, and the common ways that SaaS businesses get dunning wrong and how they can do better. We also talk about the value of iteratively improving automation for tasks and how important it is to clearly document and explain manual process.

Garrett Dimon: All right, hello. Today I’m talking with Matt Goldman, the CEO of Churn Buster. Hi, Matt. How’s it going?

Matt Goldman: Good. Thanks for having me.

Garrett: You’re welcome. I’m really excited about this. This I think is going to be really interesting on two fronts. One, you run a SaaS-based app, and two, that SaaS app is designed and its whole purpose is to help other recurring revenue situations grow and avoid churn, mitigate churn, that kind of thing. I think there’s a lot of layers to this conversation. I guess can you give a quick intro rundown to your career trajectory and what led you to Churn Buster.

Matt: Yeah. I don’t even know how long ago it was now. Forgive me for any slow thinking. I have a three-week-old at home and my brain doesn’t work. A few years ago, we started Stripe analytics product called HookFeed, my wife, Joelle, and I, and ran that for a couple years. At the same time, we were running a podcast called Rocketship.fm. At some point along the way, we interviewed a guy named JD Graffam, who ultimately bought Sifter from you. He told us about his process for buying SaaS apps and we really liked it. It got us thinking about what we could buy to get past the problem that we were having with HookFeed, which was product market fit. Could we find something with some fit that we could then focus on growing, which we thought was going to be the easy part for us, but you learn that there’s always other challenges.

We had gotten to know Andrew Culver, who started Churn Buster, a few years before, and after a few months of exploring the idea of selling it, we ended up pulling it off. He was CTO at another company, this was a side project for him, and he was a bit burnt out running both things at the same time. We found a way to keep him involved as a partial owner and add on a teammate, Ken Johnson, who worked on Manpacks before, and yeah, we took it over.

Garrett: Right on. I guess … How long have you been working on it now? About a year and a half?

Matt: It’s been about a year and a half, yeah.

Garrett: Okay. Let’s talk a little bit I guess about the acquisition process in a little more detail. What really instigated … Sounds was maybe we can avoid this whole growth thing and just fast forward a little bit. What was the sequence of events? Had you all known each other through other things beyond that, or what was the details there?

Matt: Yeah. We met Andrew at Micro Conference.

Then a handful of people from that started a Slack chat, where we would hang out. Share ideas. We just got to know him over time in there and at one point, we threw out the idea, after seeing him talk about maybe selling it, we throw out the idea that we would be potential buyers, and we didn’t know at that point how we would raise the money or what the deal would actually look like, but we just wanted to be considered in case he ever did make the final decision. After that, we went quiet for a few months, and then he got more serious, and we were there to negotiate.

At that point, we followed JD’s process pretty tightly, which is as you know, it’s light on legal fees and timeline, and pretty quick. Did due diligence, looked at metrics and code, and made sure everything looked like it would be a good fit, and since we had worked the Stripe ecosystem before, and we worked on Ruby and Heroku apps, it was just a perfect fit all around. Something that after the code looked good, we were able to drop in and start running it from day one without much coaching from him.

Garrett: Yeah. Just the back channel’s ongoing and-

Matt: Yeah.

Garrett: You knew each other, and that made it a whole lot easier because there’s a level of trust there that goes into it.

Matt: Not having any experience buying someone else’s product, and working in their code base, we wanted to make sure that we kept him around beyond just a 30 or 60-day support window. We wanted to make sure that he really had a shared interest in the project doing well and would want to be around to answer a question if a year later something came up that we missed or a client wanted to have a conversation with him. We wanted to make sure that he was still excited about the project.

Garrett: I think I missed the boat. I’ve been doing that for JD and Sifter just for free. I should’ve-

Matt: Yeah.

Garrett: I should’ve worked that in. The logistics requiring it were obviously really simple and straightforward because you knew each other and had that mutual trust or it wasn’t this long, drawn out, complicated situation with a crazy extensive consulting agreement. Sounds like it wasn’t just a straightforward all cash deal simplicity, but it still was fairly … There wasn’t this long letter of interest due diligence process.

Then in the year following, we did a house remodel. We got pregnant. We had other projects going on. It was endless things the first year. That definitely distracted us all the way back to the actual acquisition process.

Matt: No. If anyone listening knows Andrew, they know that he’s the nicest guy in the world and he would never do anything to harm a friend. We knew that going into it and he thought highly of us as well, and everything was very straightforward.

Garrett: Looking back, is there anything that really got you off guard or that you didn’t expect with the sales process that it would’ve been better to know going into it, or you could’ve prepared for better, timing-wise, schedule-wise, anything like that?

Matt: You told us a long time ago to not put life on hold. We followed that pretty well. At the time, I think we were in due diligence when we were at our wedding.

Garrett: Wow.

Matt: Then in the year following, we did a house remodel. We got pregnant. We had other projects going on. It was endless things the first year. That definitely distracted us all the way back to the actual acquisition process. Then I know that we ran into a lot of problems in learnings in the year and a half following, but the actual sales process was pretty straightforward.

Garrett: Okay. No curve balls or things that you wish you had known?

Matt: No.

Garrett: Let’s talk about that first year. I know you’ve mentioned it was painful, a lot of learning curve. It wasn’t the hit fast forward and just sit back and grow- I think you all probably hoped for. Can you talk a little bit about that?

The first problem that we ran into was that we raised money to take over the product to buy it from Andrew, but we didn’t raise money to fund some growth in the first year. Starting that first month, we had a zero bank balance, and money would come in and it would go right back out.

Matt: Yeah. The first problem that we ran into was that we raised money to take over the product to buy it from Andrew, but we didn’t raise money to fund some growth in the first year. Starting that first month, we had a zero bank balance, and money would come in and it would go right back out.

For the first six to nine months, we were struggling with cash flow, which isn’t a common … Maybe it’s more common than I think, but it seems like with SaaS, it’s not like working in an agency where you’re constantly focused on cash flow. For us, he launched the product in the last few days of the month, so all of our original clients who were still customers would pay in the last few days of the month. Our expenses wouldn’t line up with those and it was a pain in the butt.

That would’ve made it a little bit smoother in the first year. After that, I think that … This is a direct result of that. Not being able to fund a tech lead for the project meant that I was the tech lead. Every customer conversation, every code question, every script that we had to run in different scenarios, there were a lot of manual processes within Churn Buster, and all of that was in my head. There was never really a good time during that first year to be able to delegate that to someone else, especially since our dev help was at very low hours, less than part-time.

Until very recently, we didn’t have someone where we would really hand off everything too and have them be the lead. Especially because a lot of the manual scripts that needed running had to be done in response to a customer request. If they weren’t going to be working for a few days, then it would’ve just fallen back on my plate.

By not being able to fund a little bit of a team around it, all that fell onto my plate and also onto my partner, Ken’s, plate, who was leading sales. Between manual onboarding, manual upgrades of accounts, and every support request becoming an escalatable request, we were just making 100 micro-decisions a day.

In that first year, we couldn’t identify the actual cause, but we just knew that we weren’t getting work done and we weren’t being as efficient and productive as we were on past projects.

In that first year, we couldn’t identify the actual cause, but we just knew that we weren’t getting work done and we weren’t being as efficient and productive as we were on past projects.

We just felt stuck.

Garrett: Forced to tread water and catch up. The whole time too-

Matt: Yeah.

Garrett: You’re not totally solo. You’ve got some experience with Andrew, but you’re learning the whole business. Even though it’s similar to your past experience, you’re basically learning the whole business, the ins and outs. All the little subtleties through all of this at the same time.

Matt: Yeah. I think something else that we screwed up really starting day one was we came in and we assumed that there wasn’t a reason why he was doing the things that he was doing, and we took our ideas and rolled with them from brand new pricing to taking self-serve onboarding, and making it manual onboarding. We changed a lot of major aspects of the business on day one.

Garrett: Real quick, yeah.

Matt: We had a huge first two months and we churned out almost everybody.

Garrett: Wow.

Matt: Just because expectations were off.

Garrett: Yeah.

Matt: We had no clue what we were doing in this new business, and a lot of ideas seemed like a good idea on the surface, and it would show until three or six months later that it wasn’t working.

Garrett: Yeah.

If we were going to do it again, we would’ve moved much slower. We would’ve focused on shipping features rather than working on performance and bugs behind the scenes.

Matt: This is one of the bits of advice from JD that we didn’t follow is when he takes something over, he’s looking for something that will run for six to 12 months flat, and he’s not worried about growth. He’s doing it on debt and he wants to service his loan before he takes any risks. In the first year, he doesn’t change anything. It’s working he leaves it. We came in and thought we were brilliant. If we were going to do it again, we would’ve moved much slower. We would’ve focused on shipping features rather than working on performance and bugs behind the scenes. Yeah.

Garrett: That’s interesting because so many people I think, it’s so tempting to think, “Okay, I just got this. Now I’m going to go hit the gas and really make it accelerate and grow.” Everybody’s habit, everybody’s temptations.

Matt: Yeah.

Garrett: “I want to grow faster, I want to move faster. I want to ship faster,” when in reality it sounds like it may have been healthier to just slow down, take a step back, focus on some fundamental things, play it safe, learn, and then choose your battles after that.

Matt: Talk to customers.

Garrett: Talk to customer. You know, if you have time. Then in hindsight, it sounds like raise a little bit more money to cover some technical help and/or find some way to facilitate that so there’s less of a burden. Then give yourself a little time, spend it talking to customers, doing research, getting yourself familiar with the existing code platform, the problems, spending two, three months doing that. Then make a much more informed decision about the areas you attack and how you attack.

Matt: Yeah. Yeah, I think something that applies in this as well as not acquisition, is I think a lot of companies rely on scripts. Did you have a lot of manual stuff behind the scenes at Sifter?

Garrett: A good amount … I was pretty good about automating stuff in an admin tool that I had built.

Matt: Yeah.

Garrett: Yeah, there was definitely a lot of things that in hindsight, it’s a whole chapter in the book now is you could automate more. I think I even have written it up on Medium already, that I wish I had automated more and really thought about the value of automation, not just in terms of it’ll save me 30 seconds, but it only takes me 10 seconds to do it. I don’t know.

Matt: Yeah.

Garrett: It’s not worth it.

Matt: Yeah.

Garrett: It’s worth a lot more than we think it is doing simple time math.

Matt: It took us a long time to actually commit to doing that, and it wasn’t until the fast few months when we did. For us, it helped to look at it as a spectrum from having a manual code that you run to a few lines of code that you paste in a terminal, to making a class that makes it a one liner, to delegating it to somebody else and documenting it how it works and what it does. Then to automating it and turning it into a button.

Garrett: Yeah.

Matt: Something that just runs.

Garrett: It’s funny, I think that was a big part of the problem, at least in my head, was it was black and white. It was either it’s automated or it’s not.

Matt: Yeah.

Garrett: In reality, there’s a whole progression that you can make that helps slowly chip away at it, but you want to do it as manually as possible for a while to really, really get familiar with the process.

Matt: Yeah.

Garrett: Until you’ve done it 10, 20 times, depending on how complicated it is, that learning curve is good for helping you figure out the best way to automate it. Otherwise, if you build the automation right out of the gate, you’re probably going to build the wrong thing to automate it.

Matt: Yeah.

Garrett: Make a mistake. You have to go back and revisit it. It’s helpful to do automation in a progression rather than just one big fell swoop automate something.

In my head, it was just let me jump in here, do this 10-minute task, and move on, but when so many things are backing up, that 10-minute task ends up being a one or two-hour task because there’s so much switching costs going on.

Matt: Yeah. I think what compounded that problem was I wasn’t … My head was in so many places that I wasn’t in a place where I would take those learnings in and then think to go automated, or think of low hanging fruit opportunities to improve along a progression. In my head, it was just let me jump in here, do this 10-minute task, and move on, but when so many things are backing up, that 10-minute task ends up being a one or two-hour task because there’s so much switching costs going on. I just can’t think when I’m overloaded. What’s been really cool the past couple months is getting that onto our developer Ryan’s plate and seeing him go through the process. Seeing him run into enough frustration to where he finds a path to automate it along that progression because those were the things that I just wasn’t thinking about. I was thinking about how to get this task done.

Garrett: Yeah. Another thing that we talked about briefly was in that first year, you’re treading water, trying to catch up, get familiar with everything, and as customers, or potential customers, they see a company that’s just been acquired, they have high hopes, they expect everything to become amazing and start really seeing a lot more investment. Did it play out like that? How did that turn out for you all?

Matt: The first few months, we brought on some really big customers and then the system ran into some performance problems. We spent probably nine months to a year trying to fix performance problems the way that they were showing themselves were timeouts in the dashboard. It was very, very prevalent. It was probably one in five or 10 page loads-

Garrett: Yeah.

Matt: Would be a timeout error. We just went through the app week after week, fixing what we thought was causing the problem. It would help a bit, but it never fixed the ultimate problem, until we brought in an outside contractor and he identified a script that was running … I believe it was a fail safe to make sure that our campaigns were getting classified the right way for analytics. We’d look at the history in each campaign and make sure that the status of it was what it should actually be. Whether it would be recovered without a customer updating their card or whether we take credit for it, or if the customer’s lost. It was running through every campaign that had ever existed. Then looking at every web hook that had come in during that campaign, and then running calculations, and it was-

Garrett: Wow.

Matt: Doing that every hour. The script itself ran for two hours.

Garrett: That was running on the same VM as the web server?

Matt: Yeah.

Garrett: Okay.

Matt: It was just backing up. We transitioned a lot over to Sidekiq when we took over.

Garrett: Okay.

Matt: This was running on other tech, we just didn’t have visibility. Our New Relic and Skylight wasn’t showing it.

Garrett: Did you push that off on a separate VM or just with your Sidekick and-

Matt: No. We did it all.

Garrett: Fragment it. Okay.

Matt: We did one or two. The line code changed and it removed the need to check for that.

Garrett: Okay.

Matt: There were a lot of scripts early on that had been … Andrew put them in in probably the early weeks of building Churn Buster, it’s “It should work, but just in case it doesn’t, let me just write this script,” and it worked fine at that stage, but once you-

Garrett: Scaled it-

Matt: Bring in a really massive customer and once it operates for four or five years, and you’re going through the full history, behind the scenes it grows to be dangerous.

Garrett: Yeah.

Matt: There’s a lot that first year where we could just, in a lot of cases, just delete it, or find a way to re-write it, to beat performance. That and a few other changes were happening late last year and it wasn’t until then that we … About a year end that we finally started to see performance lift, and it lifted in a big way. Everything else we did that year were minor improvements that probably helped, but didn’t solve the actual problem. During that whole time, we had a whole team of people, and our big claim was that we had a team focused on solving this problem every day, but that wasn’t showing to customers because we were doing performance, fixes, and bug fixes. They weren’t seeing big features, we weren’t differentiating from competition, and we would get people actually writing into us saying, “Are you there?” Going to competitors and telling them that Churn Buster’s not even working on the product.

Which is tough from a competitive standpoint and really tough for the team to hear when they’re working their butts off every day. Ultimately that’s not a problem tied to performance. It’s a problem tied to process where we weren’t prioritizing shipping visible features. If that were our focus from day one, it would’ve happened.

Garrett: Even when the features aren’t visible, making a point to share either via newsletter, blog post, Twitter, keep customers in the loop, keep open lines of communication so that it’s clear there’s signs of life and it’s not just this business may not be there. One of the-

Matt: Yeah.

Garrett: Things that I advise, and I’m going to have a whole chapter of vendor evaluation in the book, is people to go check Twitter feeds and blogs, and look at things like the footer. Does it say “copyright 2010,” then don’t necessarily take that as a bad thing, but do some due diligence and make sure that this business isn’t just wobbling along on the side. It sends a strong signal when you go to check these sites and people, they’re not communicating with customers, they’re not saying anything. They’ve been quiet or it definitely sends a bad sign.

Matt: I think it’s also a side effect of being distant from customers.

Garrett: Yeah.

Matt: We’re still not communicating as well as we should with current customers. We do in a sense that most customers come on board with us through a sales conversation and can stay in great touch with them, but we still aren’t using Intercom very heavily. We aren’t doing NPS or understanding what people like, what they don’t like, and as a result of that, it limits how well we can speak to them.

Garrett: Yeah.

Matt: When it’s not necessarily a future announcement.

Garrett: I think the other … There’s two … One, you can’t talk to your customers enough I don’t think. In hindsight, I didn’t enough with Sifter. I felt like email was enough, but every time I got on with the phone with somebody, it was so much different. That’s one thing. Talk to them more and talk to them in person. Don’t just think email’s enough. Then the other thing is you’re talking to the people that chose you, but if you’re not-

Matt: Yeah.

Garrett: Actively trying to find the people that shows another product, that’s where a lot of the most interesting lessons are is why didn’t you choose our product.

Matt: Yeah.

Garrett: You can end up with some election bias and working on the wrong things. It’s important, and that’s the hard part is how do you find the people that didn’t choose you. Go through trials that didn’t convert and that thing, and reach out to them.

Matt: Yeah.

Garrett: Offer gift certificates. That’s a really hard thing to do and that’s something that because it’s hard, a lot of people are just like, “I’m not going to bother. There’s easier things for me to go work on.”

Matt: Yeah. Not only do you have to think to do it, you have to find the time to do it, you have follow ups. One of the things that we’ve struggled with is looking at things that we should be doing, and not just doing them because we should.

That means admitting that we aren’t Slack and admitting that we have a limited team, and maybe our Twitter feed doesn’t have to take a hit in the short term, or maybe we can’t ship a weekly feature, but you have to step back and decide which things you want to do and-

Which things you should actually be doing. That’s an example of something that I should’ve been doing from day one, and that I really want to do now that my place cleared. When you’re in it every day, you have a list of things that you need to do, and then a list comes up from other people that have been escalated to you because you haven’t done a good job of delegating, you’re constantly treading water, and that’s the hideout you think that always takes a back seat.

Garrett: Yeah. Now that you’ve got a newborn, you mentioned that you’ve taken off three weeks, truly taken off three weeks, how did you get from treading water to being able to do that? Not just you, but both of you taking off the time. I’m assuming Joelle is taking off even longer than that.

Matt: Yeah. She’ll probably do three months. I’m planning on doing … I was planning on doing four weeks. It’ll probably be more like six now because she had a C-section and it was a rough recovery. Leading up to it, we knew that that was something that was going to be important to me. I think we’re very lucky, the ones who are relatively independent to be able to take a longer break, and we looked at it as an opportunity to be able to hand some stuff off to the team that we haven’t prioritized in the past.

Knowing that we had this impending due date really pushed us to get everything I do handed off. When something would come up during the day, I would write it down, and I would write down whether it was delegatable or documentable. If it was, then I would put it on a separate list to do that. We just had spreadsheets running of probably over 100 different things. We ended up with a GitHub wiki that was filled with every possible thing that comes out of our plates. It helped to get everything out of my head, not only in how things are done, but in how things could be improved. If we would write down a process for something, at the bottom, I would write down why it hasn’t been automated yet or any concerns I have around it and know that future-

Conversation or decision around whether to do that doesn’t have to run through me again, and I don’t have to worry that they’re going to build something that will break this thing in this other part of the code base, which was a big problem with this code base when we took over is that since it’s such a complex product, it was not uncommon that you would change some code over here and it would break something over there. In automating these scripts, that was something that held us back a lot was fear of what could happen. Being able to delegate it, document it, and document how to make it better as far as I know, and then trust that the team will take that, and if it’s a big enough problem that they will automate it, that was something that really got everything out of my head to where when it came time to leave, there were almost no issues getting escalated to me anymore.

Then the team understanding that we’re actually out of reach was a big help. There’s been probably five to 10 occasions where there’ll be a quick question, I can pop in and write a quick answer, but they’ve really done a good job of running with it without us. Something that came up that we didn’t expect, Ken had been planning a Japan trip with his sister and he had thrown out a few different dates long before we realized the due date, and then a few weeks leading up to it, he was like, “Crap, I’m going to be out of town for 10 days pretty much offline about a week after the due date.” We just figured out how to work with it. He did the same thing on his end. We documented customer-facing stuff, he documented his sales process. There was a 10-day window that we’re now past where none of the partners were online.

The team did an awesome job of keeping everything running. For us, it helped us realize that how can we go from day after day of stress-filled never ending to-do list to doing absolutely nothing, and the company running without us.

Now we’re coming back from that and starting to debrief around what does that mean for our roles now, and how defensive do we have to be about the stuff coming back onto our plate. What kind of strategy and high level partner level thinking can we start to do now that we felt like we weren’t being effective at the past year. Now we understand why we weren’t.

Garrett: Yeah. I think that really the most interesting thing in there is documenting the processes, it’s documenting the reasons they are or are not a certain way yet. I haven’t had time because of X or this complexity that you don’t see makes this more difficult to automate, or whatever, so that it’s not just the process, but there’s context there that helps people make decisions, because that’s so often … We all want a second guess, be like, “I could just go knock this out,” and then you dig into it and you’re just reinventing the wheel-

Matt: Yeah.

Garrett: Hitting the same wall, whereas if you document that wall, that could save the nest person time too so they can know, “Okay, we can’t automate this until we can commit to solving this other problem.

Matt: That’s super costly for someone on your team to jump in.

Garrett: Yeah, to waste time-

Matt: Fill the better process-

Garrett: Research-

Matt: Then come to you. You’re going back and forth saying why it can’t be shipped. Now they worked on something that’s not going to ship.

Garrett: Yeah.

Matt: Everyone’s worse off for it.

Garrett: Yeah. No, that’s a really interesting angle on that. It’s so simple, but it’s huge.

I knew that we should’ve been documenting. I knew that it’s smarted to or that it’s wrong to think that I can do this faster than just handing it off to somebody else. Each time we made that decision, we would acknowledge that in our head and then still do it.

Matt: Documentation in general is simple. This isn’t new … For the people listening, this isn’t new advice. I knew that we should’ve been documenting. I knew that it’s smarted to or that it’s wrong to think that I can do this faster than just handing it off to somebody else. Each time we made that decision, we would acknowledge that in our head and then still do it. It wasn’t until we forced ourselves to step away permanently, or fully for a set amount of time, that we forced ourselves to do it. We didn’t think that was possible, any of this, before we stepped away. I would recommend planning to just … If you have a couple other people at your company, take two or three weeks completely offline. In the weeks leading up to it, look at every conversation as an indicator of what you would have to do to get someone else ready-

Garrett: Yeah.

Matt: To handle that without you or punt it while you’re gone. If it doesn’t, it has to be de-escalated, and use that as your motivation to actually document this stuff because without that, I think we would’ve continued another year working on the wrong low value projects.

Garrett: Yeah. Really interesting. Start a SaaS app, have a kid, and then have use the kid as the motivation to do the things you should’ve done in the first place.

Matt: Yeah.

Garrett: It’s a good strategy.

Matt: Use your children-

Garrett: I can see how that would be difficult for anybody. I’ve got some more questions about the experience, but I want to talk a little bit about dunning and just high level dunning advice for people. I know you all have written a lot of really interesting things that have gotten me thinking based on … I had to hand build everything for Sifter because hardly anything existed back then. Certainly no dunning solutions.

Matt: You hand built your billing too.

Garrett: Yeah. I did the whole thing because Stripe didn’t exist and Braintree barely existed, and it was really rough. It was on the old API. We at some point had to migrate from their old API to their new API. Yeah. That’s one thing that I do not … I’m like, “I really wish I … If I had waited a couple years, life would’ve been a lot better.”

Matt: Yeah.

Garrett: I guess if you could give people some basic dunning advice separate from just use Churn Buster, what would you tell them … What are some common mistakes that you all see when people sign up that they’ve been doing that you helped them fix?

Matt: We wrote a post that we can link to called “Eleven SaaS Retention Techniques Nobody’s Talking About” That touched on the most common problems. The reason why we saw value in this and why we wanted to take over Churn Buster was we saw a lot of people thinking of this problem as a vanilla failed payment problem. When a payment fails, you send out some emails and you recover some number of customers, and now we have that in place, let’s scale. It was handled like a password reset form.

It was something that dev teams built and ticked off a list, and then it would stay in place for years to come.

It was something that dev teams built and ticked off a list, and then it would stay in place for years to come. We saw competition, thinking about it in the same way. They would help people build ultimately the same product at that time to send an email and response to a fail payment web hook from Stripe or anyone else. What Andrew was doing at the time was he had complex funnels in place so that he could control when retries happened and when emails went out. In the case of a card being successful on the first re-attempt, in those kind of cases, you don’t want the customer to receive an email because it’s our opinion that the emails your customers receive should be good marketing emails and not your payment’s failing when your payment’s not actually failing. It just created work for everybody.

That was something that he was doing really well with his campaigns. He just had a lot more customizability built into the product. What we learned is that 1% improvement in that process when you’re at scale, adds up to a lot because every customer you win back compounds every month. One of the big learnings we had early on is that if you recover one more 100 a month customer every month, after 12 months, that’s not worth $1200. It’s worth $7800. When you look at that math applied to a company that’s over a million ARR, it really, really means that a better system pays off.

Whether it’s sending emails at the right time, retrying cards at the right time, making sure that you’re responding properly to balances that happened, finding new points of contact when someone leaves a company, which happens every year if you’re selling to startups.

These are the kind of problems that we’re trying to solve. There’s certain lower hanging fruit, things that you can do in your in-house built product to make it work better, which we talk about in that article. One of the best things is to not do pre-dunning, which is when you send out an email that says, “Your card’s going to expire.” One of the things that Stripe rolled out the past year is called card updater. I know Braintree has it and a lot of other … I think Authorize.net even has it now. That allows Stripe to, in the background, update cards for you. It’s turned on for everybody. If you’re using Stripe, you can go into your event log, look at card updates that have a request coming not from the API, but from automatic. You’ll see address updates, CVC updates, expiration year, month, card number. The only thing it doesn’t catch is when either if they’re in a certain country where it’s not supported, or a card brand that’s not supported, or if someone closes their Costco Visa and switches to a silver Amex. Which is no way to know.

If you switch from your Costco Visa over to Amazon Visa, it might, depending on the bank setup, it might know how to draw that parallel and pass that data to Stripe, which then gets passed through to your own billing.

Garrett: And that’s a nicer thing for your customers in general too because it’s less burden for them and everybody wins.

When you’re sending out a pre-dunning email to 100 people telling them that their card’s going to fail, 70 of those people aren’t going to have a card failure.

Matt: In those cases, Stripe card update works for … The last time we checked it, it was over 70% of cards. When you’re sending out a pre-dunning email to 100 people telling them that their card’s going to fail, 70 of those people aren’t going to have a card failure.

What happens is with a lot of people’s internal systems, it looks like those emails are working because they’re getting card updates and people are making a successful payment, but what they ignore is the amount of people who had you not sent the email would’ve done the same. Beyond that, I think the biggest other problem I’ll talk about the rest you can look at the post, is people have a very short window for recovery. The shortest we’ve seen is one day. Stripe has settings where you can say retry X times over Y days, and it ultimately either cancels the subscription or leave it as past due. We’ve seen people do one retry on day one and then cancel the subscription. Even if you don’t have a great performing system, you could be capturing 30, 40% or so, or more, just with basic retries.

Garrett: Yeah.

Matt: A little bit more basic emails or in-app updates. Have something in place and make it go over as long of a process as you can because people travel, people don’t check their inbox.

Garrett: Three-day weekends. If it fails on a Friday night, and then Monday, or Tuesday, they just get back from a three-day weekend, and they’re locked out, “What’s going on?”

Matt: People check internally to see who’s actually using the product if it’s not them. In general, I think a lot of the SaaS founders out there, if they have a simple product, they have a very simple understanding of how their customers interact with it. It’s not always the case that the person who signed up for the product is the one using it today or the one who integrated it. Billing issues are complex. At least give it time and if you can, build a better process that article will help you or just use Churn Buster.

Garrett: Yeah. Easy enough.

Matt: Yeah.

Garrett: Now I want to wrap up. We’re running a little long, but I want to wrap up with some of the painful phases of all this. With fairly straightforward stuff is … The simplest one is what has been the absolute, most difficult, single day that you’ve gone through? What happened? How’d you get through the day?

Matt: That’s tough. I can’t think of a single day, but I know we’ve had … I know that during the first year and a half, we had a lot of stressful days where I didn’t necessarily feel stressed. It’s not until you come out of that you realize-

Garrett: It’s death by 1,000 cuts.

Matt: Yeah, you realize how your body was trying to tell you. It’s not until you come out of that that you realize. I think that we had a persistent stressful experience with Churn Buster, and I think that all three of us, at least at the partner level, were really frustrated with the day to day. We weren’t working on things that were having an impact. We were trying to integrate with companies who couldn’t quite integrate with us yet, having long sales processes, having customers who we work really hard to please, and then they wouldn’t have any appreciation for it after several months. Ultimately, all that comes back to us. We have to be able to spot what’s needed, whether that’s shipping more features or whatever else it could be. What’s hard is when you’re in that thinking about how to identify the actual problem and solve it. It just feels like a shitty day.

We had a lot of that, and it took us a while to come fully out of it, identify with the layers, and start to fix each one. Now we’re at that for the first time. It was totally death by 1,000 cuts.

Garrett: Yeah.

Matt: In terms of burnout and stress.

Garrett: Has growth been pretty steady? Has there been plateaus that you’ve hit and had to creatively break through? If so, what were those plateaus and what was the adjustment that got you through?

Matt: Pretty low volume compared to most staffs.

Garrett: Yeah.

Matt: We charge quite a bit more, we do a lot of hands-on sales. It’s really hard to track any significant growth or churn, and the cause of it. We totally have spikes and lulls and you don’t really have big shrinking months with SaaS, but there’s definitely times where we’ll grow like crazy for a month or two and will actually get an email from an investor, and it’ll say, “Do you think that this will happen next month? If not, why?” It’s a good question and then the answer to it is usually, “We have no clue.” We think this thing might’ve worked, we’re trying to find a way to make it more regular, but we don’t know.

Garrett: Yeah.

Matt: It’s very cyclical and what we’re trying to do, what I’m hoping we can do by changing up our roles to be more strategic and try more growth activities, is that we can make it more regular and have more irons in the fire because when you’re so consumed by the day to day, you’re not thinking a month or two out, and talking to the people that you should.

Garrett: Yeah. What are some of the reoccurring challenges that you face or currently facing that you haven’t solved that you think you should solve? It sounds like you might’ve cleaned up a lot of the stuff before the baby, but is there any lingering things that you know is just a struggle that haven’t been able to commit the time or wish you had found time to fix it at this point having it repeat over and over again?

Matt: Yeah. I think the biggest challenge we face at this stage is balancing big projects with small projects. There’s certain … We definitely have a tendency towards perfection. We want to work on something for a long time, make it perfect before anyone sees it, and that’s not what we need right now. We need quick releases, but you have to balance that with the three, six, 12-month projects that no one’s going to see coming that are going to potentially you have a huge impact on the business.

Garrett: Yeah.

Matt: We have those running right now. We’re trying to balance the two, but it’s something we still struggle with. Maybe we’ll get two or three weeks of frequent updates out and then we go quiet for a bit.

Garrett: Yeah.

Matt: Big projects tend to drag on longer than you think. Any project does. It’s still a problem that we will have simple in dashboard updates, which aren’t complex, that haven’t shipped for months because other things just take priority. Every 30-minute possible change is really a half or a full bay, which takes a lot for that to take precedence over another feature.

Balancing those two is something I think everyone struggles with. Especially with a small team.

Garrett: Yeah. It’s really, really difficult. I know we started doing what Basecamp’s been doing, which is six weeks, two weeks cycles where-

Try to work on six-week things, six-week projects, and then have two weeks of light cleanup and miscellaneous bug fixing and that little stuff.

We’re early in it, but so far it’s been going well and it’s really helped us divide and conquer better.

Matt: Seems like your guys’ updates are picking up quite a bit. It’s cool-

Garrett: Yeah.

Matt: Even if it is more spread out to get an email. If boom boom boom, here’s all the stuff that’s happening at postmark, even if those are small things.

Garrett: There is a lot going on. It’s almost to the point now where I can’t even keep up with everything we’re working on. A lot of infrastructure stuff as well, performance, growth, but at the same time, user facing stuff that’s helpful and-

Matt: Yeah.

Garrett: All that. Yeah, it is very difficult to pull that off without feeling like you’re neglecting other areas, right?

Matt: Yeah. It’s hard to see companies doing it because you don’t hear about how hard it is.

Garrett: Yeah.

Matt: For us, we look at Postmark. “God, how are they doing this?”

Garrett: We have a much bigger team.

Matt: Yeah.

Garrett: Much bigger team is part of it. I think we’ve got probably 18 people effectively full-time, focused on postmark right now.

Matt: Yeah. That helps.

Garrett: Eighteen, maybe 16. There’s a lot of love going into postmark.

Matt: Yeah.

Garrett: If you go all the way back to the beginning, give yourself a heads up about something, maybe this is just Churn Buster, even before Churn Buster, what would that be? You know you’d listen to yourself and take the advice.

Matt: It would be to not be tech lead.

Garrett: Find that person quicker.

Matt: Yeah. However you find the way to do it, just because it’s tough. You know what we would’ve not learned as a result of the three of us being as involved as we were. Stepping into a new business, especially one with a complex product, that’s really important. Our sales cycle isn’t simple, evaluating our customers, setups before they transition to us isn’t simple.

Every support request isn’t simple. It’s tough to know if we would’ve been as effective with that without being as involved as we were, but we definitely know that it held us back and that it led to a lot of stress. It sucked out the I think the value to some extent of having a qualified team and place to focus on growth. We came in thinking product’s ready to go, it has fit, let’s grow the thing. All of our energy went into fixing the problems we were seeing because we were so close to it. Ken came in with tons of growth experience and hasn’t really had a chance to zoom out from the sales process and tackle that, which is also the most fulfilling thing for him. There’s a lot that we used to do with HookFeed that we haven’t been able to focus on. Those tend to be the things that you get the most energy and excitement out of is-

Working on something that you enjoy and then seeing the results come from it. That’s something that we missed in the short term, and that we’re going to get back now, but I wonder if our growth would’ve been different in the first year had we approached it differently. That being said, we did awesome in the first year and it wasn’t until we got to the end of the year and zoomed out, and we actually did pretty well.

Until we realized that, but while you’re in it, it feels like you’re moving so slow. That’s probably the case no matter what you do.

Garrett: It’s the case with everything. I know with my leg, it’s felt that way, but when I look backwards and see events or when day one pops up a reminder, like “A year ago today,” and I pull up, you’re kidding. That was a year ago?

It definitely … I found that retrospectives to celebrate wins is what … I did this recently with Wildbit, I looked back at my work and I’m “Coming up on two years, I’ve been here two years and I haven’t done anything.” Then I look back and I’m like, “Okay, we’ve done a lot.”

It’s so easy to not give ourselves credit for what we’ve been doing and accomplishing and the progress.

Matt: Exactly.

Garrett: There’s usually a lot more there if you look back.

Matt: Yeah. Back in January, we moved into our first office. We worked out of co-working spaces before.

Garrett: Yeah.

Matt: We went to Costco and we bought all the snacks, and we got a big bottle of tequila and a big bottle of whiskey. They’re still sitting on the shelf unopened. We looked up the other day and we’re like, “Have we really not had a celebratable moment in the past six months? Come on.”

Garrett: Yeah.

Matt: We got to drink this stuff.

Garrett: Yeah. It can feel that way.

Matt: Yeah.

Garrett: I think you got to look back and look at what you’ve … Force yourself to spend an hour or two and say, “Let’s just list everything we’ve accomplished.” There’s plenty to celebrate, it’s just hard to see when you’re down in the thick of it.

Matt: Yeah.

Garrett: Cool. That’s pretty much it. Any parting words of advice or wisdom to share with people?

Matt: No.

Garrett: I think we’ve covered-

Matt: …covered it pretty well.

Garrett: Yeah.

Matt: Yeah.

Garrett: All right. Cool. Thanks so much for coming on. Appreciate it.

Matt: Thanks.

Garrett: All right.

Matt: Bye.



An illustration of an iPhone with a podcast player.

New episodes weekly Insights about software business trials and tribulations from both established and new founders of all types of software businesses.