Go slow & build good things, with Rob Moore from Churnkey

Rob Moore (00:00):
So there's this phrase around if you are not ashamed of what you're shipping, then you've done it too late, right? Yeah. And I think I go the opposite way of that. Go slower, build good things and share along the way.

Jack Bridger (00:16):
Hi everyone. You're listening to Scaling Devils, the show that investigates how devs go from zero to one. I'm joined today by Rob Moore, who is the CTO and founder of turnkey, which is a tool that helps you with all things retention, so cancellation flows, and just making sure that your customers stay around. Rob, thanks for joining.

Rob Moore (00:37):
Yeah, it's awesome to do this and in person, it's the first time I've done a podcast in person with somebody. So this, it's a cool experience,

Jack Bridger (00:44):
Really excited and this episode's going to be a little bit different in that we are lucky enough to actually have a CTO with us. And I wanted to really ask you, Rob, about how do you make decisions around software and the dev tools that you buy, as well as talking about retention so that we can kind of get a better idea of what really goes into it, looking at it not from the seller's perspective, but actually from the buyers perspective as well.

Rob Moore (01:10):
Yeah, yeah, let's absolutely dig into that.

Jack Bridger (01:12):
Yeah. So first thing maybe could you tell us a little bit about Turnkey?

Rob Moore (01:17):
So we built Turnkey, actually it started as an internal product for the same group of people we're working on a podcast marketing tool called Wave. And we had a massive churn problem. We were looking at 10 to 13% month over month churn. And we threw everything at this. We tried everything. We hired outside consultants for tens of thousands of dollars and we were just trying to get to the bottom of this. And we spent easily six to eight months working to figure out how we could get this customer retention number up. And what ended up happening is it kind of defied what we expected, but a cancellation flow which takes into account how customers are using the product and presents 'em with dynamic offers, whether it's pauses or discounts or trial extensions or whatever it may be at the point of cancellation to retain those customers ended up being really, really effective far beyond anything that we thought was possible.

(02:19):
So before we sold Wave, we had this in place for a number of months and we cut the churn by a substantial margin and we'd like that internal tool so much we decided to productize it. And since early 2021, we've been working on building out this tool now called Turnkey to be the best possible version of it. So that's kind of the origin story of Turnkey. And as of now it's a product that we do cancellation flows, but we also do fail payment recovery. So this is called Dunning where if a customer's card needs to be updated, we'll send an automated retention email campaign where they can easily go and update their card.

Jack Bridger (03:02):
Yeah, that's really cool. And I know that's a massive difference. One of my friends implemented the Dunning Flow and was raving about it for ages.

Rob Moore (03:11):
Yeah, yeah. So Dunning's been in place for quite a while. I mean for six or seven years I've spent a few competitors in the space and to the point where it was surprising that the market on that kind of grew stale in terms of there's, there's not a lot of innovation. So we ended up taking everything that we learned from cancel flows, the personalization, the realtime offers, and we applied that then to fail payment recovery. So now instead of just going in and updating your card, we can say, if you update your card now, we'll give you 30% off that invoice and 20% off your subscription for the next couple of months.

Jack Bridger (03:49):
Yeah, that's really cool. And actually Rob, so in terms of developer tools, sorry, I'm just the developer tools person, so just

Rob Moore (04:00):
Yeah,

Jack Bridger (04:00):
Of course. What developer tools are you using at the moment?

Rob Moore (04:05):
Yeah, I love talking about this problem from this side of it, right? Because I mean turnkey in itself is a developer tool largely for the most part. So when I'm actually evaluating products to use, it's this whole psychology, which all these assumptions that I have that I think people are going to think about Cherokee are flipped on their head. So I would say the number one thing that stands out to me and as talking towards an audience who is building developer tools is we often think that especially when we're talking to developers trying to sell to developers or trying to get them to use our tool, that they are rooted in logic and they're just going to say, this tool is going to save me time and it's something that now I don't have to build myself and I'm going to use it. And I think what I've realised so much more from working on both sides of this at the same time is it's less a question of logic and it's more about energy and excitement.

(05:03):
And there is of course this time element, but where we were doing previously maybe a time versus money equation it for me it's more of a time versus energy equation. And those are things that you can add to on either side. So I think with developer tools on the whole interesting thing is that as a developer you can build something once and then 10 people or a hundred people or 10,000 people can use that same tool. So it's like when you're sitting there coding at your kitchen table on your laptop, you're not just coding for yourself, you're coding for 10,000 other companies that can eventually use that same exact code. I mean that's the beauty of code. It's infinitely scalable, at least very, very cheap to scale. So when people are evaluating whether or not they want to use that, there needs to be this certain activation, energy of excitement.

(05:58):
So either A, you're taking away a very painful thing. So with Turnkey for instance, it's a lot of this billing logic. Everyone hates to write billing code. It's, it's a pain to test, it's a pain to write, you don't want to do it. So wherever there is, there are pain points. I love when we come up on something that's a pain to do cause I know nobody else is going to want to do it. So the more of those hard things that we come up, the more excited I get. So I think that's number one for Dev tools is you need to either be very excited about it because it's solving a hard problem that you don't want to do or because it's introducing this new thing, this concept that you haven't thought about and you don't necessarily want to dedicate the time to learning about it.

(06:39):
So when I'm personally evaluating dev tools, there is this the energy equation, which is alright, how much energy is it going to take to implement something? And it's not just as a developer tool, you have outsourced this entire piece of code. For me it's okay now instead of using this. So instead of using Stripe to manually or to handle subscriptions, maybe you are taking part of that and you have this API wrapper which simplifies it, but I still need to learn your API wrapper. So you need to be very cognizant of how much energy is going to be required, not how much you're saving them, but also how much they're going to need to learn your product. And these are all different levers that can be pulled. So you can with really awesome marketing and really awesome use cases, you can get people excited about it where they hit that activation to energy and they're willing to dedicate two or three days to integrate with your product and learn it really well.

(07:39):
But if it's not something that maybe is not the most exciting thing in the world, churn key is it's a billing churn thing. Nobody likes talking about churn. We know very well we're not delusional, it's not an exciting product. So the money aspect is maybe exciting, you're got more revenue every month coming in, but from the standpoint of a developer, they're not going something they're going to be looking forward to implementing or installing. So what we focus on is making sure that energy required for them to instal turnkey is really low. We want to make this implementation as simple as possible. And for the dev tools that I've used, that's almost always been the case. And something that I've seen done really well is, for instance, products which have a small niche to cover. So there's this entry point almost where you can go in and you can start working on something and you can take a little bit of this bigger project and that's where you can get integrated. And then once you get that initial entry point, kind of expand from there. So that's another way to lower that activation energy required to use the developer tool.

Jack Bridger (08:49):
That makes sense. And in speaking, in terms of chunky in that activation level, are there any kind of levers or things that you've really felt of, okay, we did this and it made it way easier for developers to

Rob Moore (09:04):
Take? Yeah, I would say documentation is, I mean it's an obvious one, but it has to be done really well. We spent, it's one of these where as you're building a developer tool, you need to be really cognizant of your time. Going back to that thing where you're sitting at the table working for 10,000 different companies at once, any hours that you spend working on a particular customer support case where you're working with them to debug and troubleshoot, that's taking hours away from those other 10,000 companies. So you need to be really cognizant of your time and how to most effectively scale your time. That's what developer tools are all about. So whenever we hit something where we get multiple requests for some, they've run into some problem. I mean, it's user error or not, but if somebody hits a problem, there's either a problem in the UX or something's not clear enough in the documentation. So we pretty relentlessly being a small team overall, we pretty relentlessly pursue these pain points and make sure that's as seamless as possible because we're not going to be able to scale and just throw support hands at these things. So as a small team, you've heard of probably engineering as marketing, I am more bearish on that and more bullish on engineering as customer support, just make it very good error logs when things do go wrong and just very, very clear ux.

Jack Bridger (10:28):
Yeah, that makes sense. But I see a lot of companies kind of leave their documentation kind of unloved. Usually documentation is kind of a few steps behind the actual what your API can do, how do you put it at parity with actually features. And

Rob Moore (10:54):
So ours wasn't for a while and we were using GitBook, which is pretty commonly used. And it basically, GitBook works with a git repo and you host all your pages in some repo and then it has a webpage render where it will show all this, but the GitBook editor is, it's fine, but it's a bit of a headache to use. You're not just going and go in there and make changes. We switched to using Super Dot, so which is, it's a wraparound notion, so you have just a notion page and you can edit it and basically real time those edits will show up on our documentation site. And it was this, we realised we weren't going in and updating the docs nearly as much as we should be. So we switched to super and just using a notion page and it's been the best thing we could do for docs because now I am troubleshooting with somebody and I realise that our docs could be updated and instead of forgetting about it and coming back to it a week later, I just go in real time and update the docs.

(11:51):
So it's been this ease of updating the documentation, which has helped tremendously. So the other thing I would say is that we got away entirely from trying to create API schema based stocks. So right now it's I would say 70% plain text and 30% examples and almost no schema type api, like your open API or your swagger type documentation, which is it technically correct, this is the endpoint that you can use and all the different parameters for it. That's more or less it's a pain to use. And when you've got examples in front of you and just plain text's, explanations of it, it's better for all parties. It's better for somebody just reading through and figuring how to do stuff. And with examples, it's a copy paste exercise. You show the developers the pattern versus trying to abstractly describe what to do and they just take it from there.

Jack Bridger (12:44):
Yeah, that's actually a really good point. So it makes so much more sense to see it very specifically work for this use case that then you can extrapolate back to your own own use case rather than here is all the information you need to know about how

Rob Moore (12:58):
This Right, exactly. And I'm actually interested on this front now, a lot of developers, they're using chat G P T or co-pilot within VS code. And it'll be interesting to see if adding code examples to GitHub for instance, becomes a documentation strategy where co-pilot can now pick up on those code examples that are in GitHub and automatically do them for you. So for very new products, obviously co-pilot have those examples to go with, but for something that's been around for a while, for example, I was working with the HubSpot API and it's these API calls that I've never used before, so I don't really know the exact syntax, but co-pilot knew what they were. So that's a big advantage for HubSpot then for developers to use it because now they have to deal with a lot less developer burden on their front. So something to keep an eye on for sure.

Jack Bridger (13:49):
Yeah, interesting. Yeah. Are you going to do anything actively with chat G P T?

Rob Moore (13:56):
That's a good question. Probably not. So I think there's some use cases within Cherokee, not on the documentation side, which we may explore, but on the documentation side it we'll see where it goes.

Jack Bridger (14:08):
Okay, awesome. I really want to dig into an example of a tool that you bought recently, a developer tool that you bought recently and what your thought process was and how you arrived at that stage.

Rob Moore (14:24):
Yeah, so one I switched to recently is a small product built by a solo developer. It's called logn. So Log, it's a logging product and its whole pitch is that it's just super simple logging. So whereas before you might use something like Century this or CloudWatch, this is basically, there's an, there's an API endpoint and you send a log which has a name and a category, and that's basically all there is to it. There's a nice dashboard where you can see these events flowing in and there's some neat charts and stuff you can stitch together. But basically the entire pitch of this company is that it's simpler than some of the other things out there, which try to automate everything for you. But as a developer, you've got a very good idea of for this problem specifically, what kind of things you want to look, what do you want to pay attention to? And it basically solved me on that, hey, were the simplest option pitch.

Jack Bridger (15:33):
And kind of thinking even broadly as a cto, why was simplicity important to you

Rob Moore (15:41):
With logging specifically? And I mean guess this comes to a lot of things, but you don't want to dedicate a lot of energy learning a complex logging software. This is something where if I didn't use Log Snag, and we've used Century in the past, but again, century is the UI side of Century, when you're actually exploring things is very complex and it's overloaded with information. So the alternative when I was thinking about getting off of Century was to just log these things in our own database.

Jack Bridger (16:15):
So the next question on that was like, do you remember how you discovered Logn?

Rob Moore (16:22):
Yes. So it was actually through Twitter, which seems to be the hotspot, especially for indie developers, people working on small SaaS projects. So he was sharing the UI that he developed. I mean it's very common now to build in public where you're sharing your r r, you're sharing your growth. But I mean there's different variations of that. And the ones I find most interesting are the ones where they're kind of sharing their product process. So they're UI development I love, I'm a soccer for good ui, so I saw he was posting some updates on some of the dashboards that he has, and I found him through there. And that's actually been the story for another tool which is called Woba, which is actually a very similar pitch to the simplified logging, which is a simplified crm. And while that's not a developer tool specifically, it is the same mindset of there's now, there's so much burden of choice, it's all around us.

(17:26):
So if there's something where it's does its job very specifically and it's going to be a decent price for it, I can see that being very compelling And going back to how I found them, I do think for dev tools, Twitter can be a good marketing spot. It's a lot of times it's not natural for developers to jump onto that, put on that marketing hat and try to basically sell and market what they're building. At least as a developer myself, I've always kind of fallen for this dream of build it and they will come and it's unfortunately not the case. You can have the best software in the world and it needs marketing. So what these successful small dev tools have done is they have found a good marketing strategy on, I think a lot of them on Twitter.

(18:23):
And again, I mentioned this fallacy of building, they will come, but I have actually have a startup from five years ago, four or five years ago where I put all my effort into building it and basically zero effort into marketing it. And it's frustrating. It's frustrating that we can build a great thing and it doesn't do well, but it's just part of the reality of it. And something that is, I mean, I'm still working to be comfortable sharing things and it, I mean, it feels like you're kind of bragging about it, but I think there's an aspect of being proud of what you've built and where there is the consensus around building MVPs and there's this phrase around if you are not ashamed of what you're shipping, then you've done it too late. And I think I go the opposite way of that. I love to be very proud of what I'm building.

(19:22):
And I think especially as an individual developer, if you build something that you're not proud of, it's really difficult to come back to it. If you don't have time every day to be working on this and you've kind of done a half-ass job, it's not something that you're going to want to come back to on the weekend and work on it because you're not proud of it. So I think having this craftsman approach to it and being very proud of what you're building and making sure the code is in good shape can often be underrated in lieu of trying to maximise for speed.

Jack Bridger (19:51):
Yeah, I see what you mean. So if you go slower, but you're always sharing your process and

Rob Moore (19:56):
Exactly

Jack Bridger (19:57):
The good stuff that you're doing,

Rob Moore (19:58):
Go slower, build good things and share along the way. And I think as developers, if we're hesitant to share things as is, and if it's not something we're proud of or something that we know has holes in it, if you lift up the cover, it's not going to look good. I think that only adds to the hesitation to share it. So I think building something you're proud of and you can look back and three years later still be proud of it helps developers in particular to share their small projects as they start to grow.

Jack Bridger (20:29):
Yeah, that's a really interesting point. Yeah, I might have to try that approach on my stuff because I've just been shipping stuff that's pretty rubbish. So

Rob Moore (20:39):
Yeah, I mean, it is a balancing act, right? Yeah. You do want to get stuff and start to get feedback on it, but I think especially if you're working as an individual, there's this aspect of pride and kind of craftsman builder that can be helpful.

Jack Bridger (20:52):
Yeah, that's really cool. Rob, I think the final question I wanted to ask you about is churn. I mean, yeah, I imagine that that's pretty much an area of expertise for you now. So I just wondered about what kind of things you're seeing that companies are doing to reduce their churn and what maybe some of our listeners can do with their own developer tools.

Rob Moore (21:18):
Churn is, it's a problem everyone faces. There's no getting away from it. You can have the best company in the world and you're still going to have churn. It's important to think about it. Number one, it's not as fun as growth. It's not as sexy as new customers, but it's far cheaper to keep a customer that you already have than to try and go get a new one. So one of the interesting things that has happened since we launched Turnkey is I talk to, to a tonne of founders, which is awesome. And what I've realised is that the second and third and fourth time founders don't even question it, right? They get into the demo and they know immediately that they want to either build something like this or buy it, and it's because they know that churn has a huge effect on the bottom line.

(22:08):
Some of the first time founders are more excited about growth, which is natural. It's completely natural, but it takes a little bit more selling to them to get them to buy into churn reduction through dynamic cancel flows and fail payment recovery. So I think first of all is thinking about it is a good first step. The other thing I would say is that dynamic point of cancellation offers, and that's kind of a fancy phrase, but it just means if you've used Audible, when you go to cancel their account and they will give you an offer to either pause or get a bonus credit, these are really, really effective, way more effective than I ever thought they would be. And it's just a good way to treat the cancellation experience less as a black and white experience, which is kind of natural for us. We, we've built something and somebody wants to cancel, we don't want to hold them back, and we kind of think, all right, they're gone. Right? So what I've realised is that cancellation is this whole customer life cycle is not a black and white experience.

(23:19):
They click that cancel button and it's almost an opportunity to refresh that relationship with the customer, especially now during a economic recession. I mean, churn rates are up across the board. Every single company that is connected to us are almost everyone. Churn rates are up. So if you position yourself as an understanding company, especially if you're a B2C product, you can position yourself as the company which understands the budgets are tight right now and is working to meet your customers in the middle for a few months while the economy and their business picks back up.

Jack Bridger (23:54):
Yeah, that makes a lot of sense. Yeah, the Audible one, I feel like I've redeemed it like quite a few times.

Rob Moore (24:00):
Oh yeah, I, I'm in there. I think they say you can only do it every year, but you can definitely do it at least every three months I'm in there just raking in the credits.

Jack Bridger (24:06):
Yeah. Yeah. That's really cool. Rob, if people want to learn more about turnkey and about yourself, where can they go to learn more?

Rob Moore (24:16):
Appreciate the opportunity to pitch it a little bit here at Drop Names. So turnkey.co is the domain name and my name is Rob Moore. There's, there's a lot of us out there, so the best thing to do is probably just Google Rob Moore turnkey if you want to. I'm pretty active on Twitter. Do some fun UI development stuff, machine learning, data visualisation, that kind of thing. So if you want to follow me on Twitter, that would be awesome.

Jack Bridger (24:44):
Thanks so much for joining, Rob, and thanks everyone for listening, and we'll see you again soon. Bye-bye.