Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about things to consider when building your launch plan, both from a preparation and execution stand point.
Items mentioned in this episode:
Transcript
Mike: In this episode of Startups for the Rest of Us, Rob and I are going to be talking about elements to consider when building a launch plan. This is Startups For The Rest Of Us episode 349.
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you built your first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s going on this week, Rob?
Rob: Not much, I’m just getting back into the swing of things. As I talked about last week, I was working remote from Chicago at a cello camp for my oldest. Back in Minneapolis this weekend after spending a day and hanging out over the weekend in the Wisconsin Dells, which I’ve never heard of, but when we drove through it, I saw a bunch of resorts there and so I wound up taking my son to a big water slide and stuff on the way back, kind of as a high five for slogging through a week’s worth of cello camp. It feels good, it’s always good.
I like traveling but I like that feeling of getting home, getting settled, having my stuff where it is, my external monitor. There’s just a certain piece that comes about returning back home. The cool part is I tend to be more productive because it’s kind of like my home is a new place because I haven’t been there for a while.
Mike: I hate travelling and trying to get any work done on the road, I just can’t do it. It’s more because of the access to the external monitors and having everything set up the way that I like it and need it to be. I hear what you’re saying about coming back to your home base and getting re familiarized with where you’re at and having to re energize a little bit but I just can’t work on the road, that’s just me.
Rob: What’s interesting is I’m very productive on the road, not in long stretches, I can’t just sit and work for eight hours, but I find that if I sit down for an hour here and an hour there, I get two or three hours worth of work done because it’s hyper focus and I’m just hammering through stuff. Although I don’t have my setup, I feel like I don’t get distracted, no one interrupts me. I feel like there’s a good balance. Last week in Chicago in the dorms, I was hammering on stuff.
I really felt like I got a lot of productive thinking done. That’s the kind of stuff that’s harder to do in the office because you’re just in the day to day slog of things. I do feel like having a good mix for me is probably the optimal approach.
Mike: You just said dorms, was it like in a college campus?
Rob: Yeah, it was on a college campus.
Mike: You’re partying the entire time and living up your college years.
Rob: Partying with a bunch of 10 year olds. I had my 10 year old there. It was fun. I do enjoy that, the college vibe. Obviously, it’s a middle summer, there were no college kids around. I enjoy the feel of campuses, I really enjoyed my college years and so to wake up and be in the dorms and then go to the dining hall. We brought scooters and just the scoot around campus was pretty relaxing and it was a fun time to spend with one kid.
We have two kids. When you’re with them all the time, it’s they like they fight amongst each other and you get frustrated with them but when you pair it down and you do an extended period of time with just one child, it’s like, “Whoa, I’m so jealous of people who were smart enough to stop after one.”
Mike: It’s funny. I had talked to a guy who had, I think he had five or six kids. We were asking him over lunch one day like, “What is the difference between having one kid, two kids, three kids, etcetera?” He’s like, “If you have one kid, it’s really not a big deal. It’s obviously like a shock because you’re going from zero to one, it changes a lot of things but it’s not really any different. Having two kids is like having three because sometimes you have one or the other and then when they’re together, they fight. It’s like having three.”
He’s like, “Three is no big deal, four, you have to buy a bigger car, five is not a big deal and then six you have to buy a bigger house.” It was interesting to hear him map out what the progression was, I’m like, “Nope, stopping at two.”
Rob: Anyways, we’ve gone off on a tangent here. What’s been going on with you before we dive into today’s topic?
Mike: I’m working on my Bluetick launch plan. I’ve realized that my notes were all over the place at the moment, just in various notebooks or different apps and things like that. I got to consolidate them into one specific launch plan and focus on the things that I really need to do and that I’m going to do versus the things that I would like to do because I can’t do everything on that launch plan within the three weeks that I have.
But one of thing I am going to do that’s kind of an offshoot of this is putting together a short video series called 21 Days Behind the Scenes of a SaaS Launch with a subtitle of with whisky to drown the sorrows, because I know that there’s things that I’m going to want to do that I’m just not going to be able to. I’m going to basically record a three to five minute video at the end of each day and document the daily successes and failures leading up to the launch. I’m just going to talk about the highs and lows and put them out there and see if resonates with people and if people enjoy it.
Rob: That sounds super cool. Actually, it reminds me a little bit of what Derek and I did with the Drip startups stories podcast where we just had nine months of audio and I edit it down to a couple hours but this is like more focused and intense and just about the launch. I like this idea.
Are you considering turning it into audio as well because that’d be cool, whether you drip it out as a podcast and an RSS feed people could subscribe to or you just slapped it all into one big audio file and let people download it. I think that could be interesting because I don’t know that I, personally, will watch this much video but I absolutely would listen to the audio.
Mike: I hadn’t actually thought about putting it together in a bunch of mp3s or a single mp3 and aggregating all of the audio together but that’s a really good idea, I’ll probably do that at some point. Obviously, I won’t do it on a daily or whatever. I’ll just have somebody go back through the whole thing afterwards.
Rob: Something that might be interesting if it really was one audio file, would be just to push it out on this feed so listeners could just get it as an app. We just make it other half episode or just an unnumbered episode, people could hear it. We could also do that with the Drip Series that Derek and I recorded, it’s like 90 minutes worth of audio but throwing it into RSS feed, people don’t have to listen to it if they don’t want to, it could be interesting. I can’t believe I never thought of that before now.
Mike: That would be cool. I listened to that as well and I thought it was really interesting to hear. The difference, I think, between what you did versus what I’m doing, I’m doing it more because when I heard yours, I was like, “That’s an awesome idea. I should do that.” I just never did it because I don’t really have anybody else to talk to about some of the behind the scenes stuff and I’m not going to record people on my mastermind group or anything like that.
I was like, “Well, I’ll just hold off.” But then the idea came to me to do a video series of behind the scenes and literally just like the 21 days leading up to it. All of this is like three to five minutes each day and encompassing like, “Hey, how did things go today? What’s up on deck next? How did things go?” I think that would be really interesting for people to hear.
Rob: If people want to follow to that, where do they go?
Mike: At the moment, I don’t have a landing page or anything like that setup for it but I’m going to be putting one up.
Rob: Boo! Boo!
Mike: I just thought of it yesterday, come on, give me a break.
Rob: Are you going to put it at singlefounder.com or do you have a domain or anything we can give people because you realize this is going to go live next week and you’ll already have started this.
Mike: I’m probably going to do it from singlefounder.com at the moment. People can go there, there’ll be a blog post on it and then they can go signup directly from there specifically for that. I’m going to send something out to my mailing list and say, “Hey, if you want to listen to this, you can listen to it but it’ll be separate.”
Rob: Let’s both plan, once you have that landing page or blog post up, you and I obviously will tweet it out. Anyone listening to this, if this sounds cool, seriously, go there and subscribe and tweet it out, let’s try to give Mike some love on this and build a little bit of Twitter buzz around this because I think this is a pretty cool little adventure you’re going on.
Mike: That leads us into today’s episode which, as I said before, these are things to consider when building your launch plan. It’s interesting, I went back through some of our older episodes and in episode 121, we had seven catastrophically common launch mistakes. Do you want to go through one real quick first?
Rob: Yeah, for sure. The seven mistakes we had, obviously you can go back and listen to it in its entirety, but mistake number one was not putting up a landing page before you start coding, number two is not tracking key metrics from the start, number three is saying people are finding you through “word of mouth” which really means I don’t know how people are finding us, mistake number four is running an open beta, mistake number five is launching with a single launch email when you should have between two and six, probably, mistake number six was having a free plan unless you really know what you’re doing and mistake number seven was not growing fast enough because you need to grow fast enough to keep yourself interested or you will abandon it.
Mike: Today’s list is a little bit different than that. These are more longer term things that you need to think about way in advance when you get to the point of building a software product and launching it. What we’re going to go over today is more about the short term things where you have a limited time window of whether it’s a month or two months, it’s an arbitrarily selected time period but in my case, I’ve got three weeks. The idea is to walk through the things that you should be considering when you’re putting together that launch plan.
The first one is to have a written plan. I think that this one sounds obvious but the idea here is to have a written checklist for you to work through so that you don’t have to stop at any point and think, “What should I do next?” Everything is all written out and you’ve already decided on that stuff. You don’t have to make any more decisions at that point. Your past self has already made those decisions.
Presumably, you trust your past self to make those decisions. At that point, you’re just iterating through all of the different things you’ve already decided that need to be done. By virtue of that, it’s going to make you more productive because you don’t have to stop and think about those things.
Rob: I used to not do written plans and I would try to keep it in my head. I would have scrolls here and a notebook and stuff there, just flailing around. When I was doing smaller launches with smaller products, it didn’t really matter because I only had a couple tactics. Once I started leveling up, especially into, I think it was HitTail where I made a big turning point, that’s when I started the Google Doc, it’s the marketing game plan, I think it’s what I called, HitTail marketing game plan. I basically just copied that over to start Drip and it becomes a long list of bullets.
I think now, I look back at Drip which I haven’t used for years but it was 12, 13 pages of pretty detailed, structured thoughts, it wasn’t just random stuff. But it was so helpful as we were going and we could just execute in line. That was the overarching marketing approach of like these are things we should try. But actually, for the launch itself, there is one subsection, I was like, “Do this on this day, do this on that day. Just in line, get these people on board to help promote, email a list here with these five email sequence.”
I really did think it through which sounds like it could be boring or whatever to think all that through but it’s like the timing is so critical and if you forget something until the day before that you should’ve done a week before, you can’t go back and redo it. I really think more folks should have written plans when they’re coming into a launch like this.
Mike: What you just said about the timing of different things is just super important because you can’t go back in time and do something that you forgot about. As long as you’re writing these things down, then at least they’re in front of you and you can think about, “Well, this is supposed to happen a week before but is there anything that leads up to that?” You do some backward planning at that point to determine if there are previous things that you should be doing or that you need to do in order to get to that point.
A lot of times, they’re just like these little things, you need to set up this webpage or you need to design this landing page over here. There are lots of little things that could easily slip through the cracks and you don’t want them to. The reason for that is because they lead to the next one which is being selective about what you do.
The first one on that list is decide what not do during that time because you don’t want to decide to do something or try to do something that is just not going to get done. If you do that, then what happens is it pushes your time back and it introduces these artificial delays.
If you’re already working towards let’s say 21 days or 30 days, if something delays your launch sequence or the plans that you have by let’s say 3 days or 4 days, then you have to decide what to cut out because it’s going to be hard to push back your launch date if you have a lot of other things that are already in place, that are going live on a specific day whether you’ve arranged with podcasters to put out specific episode on specific days or PR releases, things like that. You need to be careful about what those timelines look like.
The third one is to leverage your strengths. Rob, I think you did an entire talk about this at MicroConf one year, but most of this boils down to who you know, who knows you, and your relationships with different influencers. You need to know what your strengths are in terms of not just the product development but talking to people about your product. If you’re the founder of the product, you have a good idea of exactly what it does and how it can be used and who it’s going to be a good fit for.
It would be very difficult to bring somebody in the last minute to help you with those types of things unless there is no additional information that they’re going to need in order to be able to implement their piece of the project or their piece of the launch. If it’s completely standalone, they could do that, that’s great. But you’re going to have to be the person who’s the point person on a lot of that stuff. You need to be able to use your strengths to accomplish some of those goals.
If there are things where you fall short, you may need to bring in that extra help and just be aware of the places where you’re probably going to spend a lot of extra time as opposed to somebody who you just hired to do a very specific thing and hand it off to them and say, “I need you to this and this is everything that needs to be done with it.” And let them go so that it saves you time in the long run.
Rob: This is where cultivating a network, or an audience, or some pretty epic skills really come in handy and these are the things that you only build out over time. Who you know, who knows you, those are the things that you’re not going to solve that in the next 21 days, you need to attend conferences, or been blogging and met other bloggers, or had a podcast and have an audience.
That’s something that takes so long to build but this is where you start calling in favors, and this is where you start talking to your audience about it, and this is where you start really making a few withdrawals from that trust bank account or the relationship bank account that you’ve built up over the years by offering advice, helping people, and giving stuff away for free. This is one of those times where you’re going to start calling back some of those favors and some of the value you’ve given into the world.
Mike: Essentially, that’s capitalizing on that social capital that you’ve cultivated, as you said.
Rob: Exactly.
Mike: The fourth one on this list is relentless execution. Rob, you’ve mentioned this phrase a bunch of different times either on this podcast, or on ZenFounder, or in some of your MicroConf talks. I really like this phrase of relentless execution but you have to make the most of the time that you do have to put into the work that you’re doing. If you’re launching something else aside, you probably only have a couple of hours a day or even a limited time period per week to be working on this launch and you need to maximize the productivity for the time that you are working.
If you focus on that productivity, if you’re making sure that, “Hey, I need to be productive during this two hour stretch that I have.” Don’t let anything interrupt you and make sure that you don’t get distracted by things that are essentially meaningless. The font, for example, on a webpage is off, it’s not really that big a deal, there are probably much bigger things that you need to worry about. Just blog it as an item to come back to and then move on, it’s not on your launch list, go ahead and do something else.
Not everything is going to need to be perfect and it is worth taking those things, just setting them aside and walking away even if it bugs you. I would have a hard time with that. I do have a hard time with those types of things because I look at something and I’m a little OCD and I’m like. “Hey, this just sucks. I can’t deal with that.” But you have to be able to put those aside. If you write them on a list that says, “Hey, I am going to come back to this.” It makes that process of walking away from those things a little bit easier.
Rob: Yeah. During this three-week period, specifically this is where you have to really bring your A game and you need to remove the distractions. This is where I would probably go on a complete social media fast aside from what’s needed to promote your launch, I wouldn’t be reading the news, I wouldn’t be checking Twitter during the day, I would be getting that epic playlist together or perhaps this single song that I would loop for three weeks straight and have that general dose of caffeine every morning, every afternoon. This is where you need to bring everything you have because you have to execute on this and it can have such a huge impact on how the app gets started and the motivation.
If you have a good launch, you’re so motivated to continue. If your launch tanks, it’s tough, it’s tough to pick yourself back up after month and months of preparation for this point. This is where you need to relentlessly execute, as we’re saying.
Mike: The next one is to be a little bit mindful of how you’re presenting your products to people. This is more of a features versus benefits type of idea which we talked about in the past on this podcast. But you need to demonstrate how it benefits users versus how good the product is and what it does. You want to focus on what the users are going to get out of it and how well it’s going to help them do their job and make their lives easier versus these are all the different things that you can do with the product. They can do this, they can do that, etcetera, all those things don’t matter, what really matters is what they’re going to get out of it.
Again, this is something we talked quite a bit about so I don’t want to beat a dead horse, but it is important to think about that when you are putting together this list that says, “Oh we need to create this webpage or that webpage.” If it doesn’t fall into this bracket and allows you to present it in such a way that it’s going to resonate with people, then I would just skip it and move on because those are the things that are brand awareness that aren’t really going to help you, specifically during a launch.
Rob: The next thing to think about is to balance your long term and your short term goals because if you think about it, you can have a big initial splash that leads to waves of signups which tends to be good. Now, realize that that may clear out your pipeline for a while so your second and third months could potentially fall off, I guess, from there. Also, make sure that you have things like your tracking pixels and your analytics in place and you’re going to want to test and verify these.
If you want retargeting pixel from Facebook or from Perfect Audience, if you want certainly Google Analytics, whether you use Kissmetrics or Mixpanel, you want this stuff in place before you start driving traffic because you really want to know how they’re finding you, who’s signing up, who’s getting the most value and who’s sticking around.
Mike: Along with that, you really want to make sure that there is a stopping point where if somebody is not quite ready to buy, at least you have mechanisms for capturing their email address so that you can follow up with them later. If they’re not totally on board right now when you’re doing your product launch, at least have mechanisms to get their email address so that you can put them into an email series, either that’s a short term email course or a longer term follow ups, something along those lines.
If nothing else, you want to be able to at least get their email address. Tracking pixels do help to be able to bring people back but it’s not quite as good as getting an email addresses so that you can send them direct emails later on.
The last one for preparation is to accept critical feedback but be mindful of the trolls. Not everybody is going to be supportive or is even worth listening to. There are going to be some people who are not supportive or dismissive of what it is that you’re working on and you can just walk away from those. You can either listen to them or read them or whatever, have the conversation with them and nod your head and say yes, okay, I’ll think about it and then walk away and just let it go because some people are going to have things to say that are absolutely not worth listening to.
There’s going to be others that you are going to look at and say yes, this is important stuff but is it important right now? You don’t feel the need to act on every single piece of critical feedback. I heard a podcast episode from, I think it was Craig Hewitt and Dave Rodenbaugh a couple of weeks ago on Rouge Startups where they were talking about Craig was going through his launch and Dave have commented that as a strategy for support, you can’t listen to everything that somebody says and implement all of it. It’s really only going to get you about 30% of the way.
That’s so true. What it will do is it will eat away your time when you’re doing the launch and even shortly afterwards. You can’t just listen to everybody and do everything that they want, you have to be selective about it and filter out the things that are going to be important to large numbers of people and take the things that are not and set them aside and then come back to them later and decide whether or not you’re going to do anything with them or you’re just going to let them sit there.
Rob: It’s always tough to balance this when you only have a few data points and somebody complains about your pricing, it’s always something you doubted early on. Once you have hundreds or thousands of data points, you just learn what kind of noise and what the concensus is.
It is definitely hard early on to take feedback and figure out which is most valuable and which you should listen to. It’s just something you got to be mindful of. It’s kind of a learned skill but it also goes away with time. As the older the product gets, the more mature it gets. You just learn where it is. This is a hard one especially for folks who are just getting started.
Mike: That walks us through a lot of the preparation for a product launch. We’re going to talk a little bit now about specifically some of the execution. The first thing that you want to do is you want to look at how to prime the pumps, there’s a bunch of different ways that you can prime the pumps for your launch. The first one is an email list. What you want to do is you want to plan out when you’re going to send the emails, who you’re going to send them to and what you’re going to say in each of those emails.
I think it’s really helpful to print out a copy of the calendar and write on it and say, “I’m going to send out an email to this list on this date and it’s going to say X, Y, or Z.” You don’t have to write out the entire email at that point, you’re really just trying to build an outline of it and work backwards from the times that you want to send those emails.
In episode 121, mistake number 5 was launching with a single launch email, I have at least 2, possibly up to 4. That advice absolutely applies here. You want to plan out the number of emails that you’re going to send, when you’re going to send them, and what the headline is. That’s the place I would probably spend the most time, is on that headline to make sure it gets opened because if those emails are not getting opened, then the contents of the email are almost immaterial at that point.
But planning out when those emails are going to send and then setting everything up so that they are sent at that time automatically in the background whether they’re using Drip or anything else that’s out there. You want to make sure that those emails are going out when they’re supposed to go out because you can’t send them retroactively after the date has already passed.
Rob: Yup. Email launch, that’s the big deal. We’ve talked a lot about that in the past and that’s the thing you’re going to want to focus on a lot. Another thing to think about is when you start your podcast tour. If you haven’t heard of this, this is something I stumbled upon after revamping HitTail and I went on this big tour of all these appropriate podcast. I measured the impact each of them gave me as I went along and I went all these in a MicroConf talk.
The fun part about podcast tours is you’re able to reach a lot of folks through audio which means they tend to be a little more engaged than when reading a blog post. It’s such a small amount of time because you show up for 30 minutes to have a conversation and then a couple weeks later, you show up on someone’s podcast and you reach 5,000, 10,000 people. The thing you’re thinking about here is when should you do this, who to reach out to and how long it’s going to take for that episode to go live. Because if you record a bunch now, some podcaster booked out a few months. Other podcasters record and go live a few days later.
This is where you got to start thinking about there’s a whole bunch to learn about this. We don’t have time to go into how you plan all this but it’s something to consider if you’re up for getting on some podcast, I think that this is something that didn’t really exist. 10 years ago there were a few podcast here and there but there wasn’t nearly the audience for this kind of stuff as there is today.
Mike: The next one is to look where you can promote your launch to things like Product Hunt, or BetaList, or Hacker News. You have to be a little bit sensitive about some of the different communities that are out there because some of them are very accepting of people coming in and say, “Hey, I’ve got a product launch going on.” Some of them are not. It also depends a lot on how you go into those or how involved you have been in those communities in the past. A lot of this has to do with social capital at that point but some of them, it doesn’t matter really matter.
With Product Hunt, you don’t necessarily have to have a large following or a voice in the community, it’s a lot easier to just post with something like Hacker News or Reddit. You have to be a lot more sensitive about that. They are not very receptive to external people who are not members of the community and never really contributed, just coming in and trying to market themselves. Be a little bit sensitive to that but other ones that come up, you could go in and you could try to pitch TechCrunch, or Master Ball, or various tech blogs.
If you know influencers then you can reach out to them, and ask to either do a guest post, or appear on their blog, or if they have a video series or something like that, there are ways to get in front of their audience as well. That’s really the point here, you’re trying to leverage other people’s audiences in order to help bring about awareness of your product.
Anything where you’re getting onto an email list or mentions on blogs. Even if you’re not directly on a podcast, for example, at least if you can get a mention, that’s going to be helpful, you’re going to get some traffic from those assuming that it’s the right target market for that.
Rob: This is also stuff that you have to prep in advance. If you have relationships with these folks, whether it’s the Big Tech Blogs or whether it’s someone who composed the product for you. It’s so much better to not just hit these things cold and then have some type of plan that you’ve worked out in advance. There’s a bunch of blog posts and resources online. If you Google how to do a product launch or how to pitch TechCrunch for your startup launch, you can read through these and get a gist of what works.
These are crap shoots. If you’re relying on either of these for you launch, it’s a really bad sign because you can do it and either get 0 signups or you can get 1,000 signups. Even if you get 1,000 signups, a lot of people are just checking out what’s going on, they’re not actually looking for the apps.
It’s that method that TechCrunch launched, getting linked to from TechCrunch is not going to make your startup, it’s going to send some traffic to you from a bunch of people who like to try out a lot of different apps and your churn is going to likely be very, very high.
That’s not a reason not to do them, this will give you an incremental bump and they’re worth doing if they work but these are the exciting, fun things that when you do them it’s accelerating. I think they’re worth doing and they can definitely make you some money but these should not be the pillar of your launch approach, the email list. Emailing the launch list really is that pillar.
Another interesting approach, and it’s one that I’ve only seen done a few times, but it’s to launch at an in person event like at a conference. I spoke at LES Conf five years ago maybe. Brennan Dunn launched Planscope at that conference and I think Intercom spoke there. I don’t think they launched at LES conf but it was very close to the time that they launched. I just thought it’s an interesting idea if you can time it for that and you can get either a little stage time.
I don’t know if Brennan’s sponsored or if Steven Alan just gave him stage time but he had five minutes where he just stood up and he said, “Hey, I’m launching. Here is my background. I have this app, check it out.” It was for freelancers, obviously. There were bunch of freelancers there.
It’s an interesting idea and I think I’ve seen some folks launch at MicroConf as well. They either tried to attendee talk where they’re able to talk to through their process or mention their app in some say. Obviously, this is not giving you an audience of 10,000 people but since it’s in person, people can come up and talk to you and I actually think there’s a lot of value if you can swing this.
Mike: The big downside to something like that, I think there’s two. One is there’s only so much of you to go around and the audience is going to be much smaller than you would get. The big benefit of that is you get that in person, in depth conversation with somebody that you wouldn’t get if they just hit your webpage or they read an article someplace else and then came to your site. They don’t get to ask questions and you don’t get to ask questions, either. That’s the big thing that I’ve noticed in doing a lot of in person demos.
Right now, for example, with Bluetick, you still can’t sign up for it unless you talk directly to me. I’ve done that very intentionally so that when I’m talking to somebody, if I ask somebody a question, I get to hear them pause, I get to hear not just the words that they say but how they say them. That stuff is very, very important when you’re trying to figure out what is important to them and what’s not. If you get a question that says, “Hey, can I do this?” You can ask them, “Is that important to you?” “No, I was just asking.”
It’s very good to be able to differentiate between those two types of questions and you can do that in an in person situation. It’s just much harder to do that if you get that type of question through an email.
The last one is to put together some explainer videos. I think that this is important just because sometimes it’s really difficult to rely on your sales copy. You may have a group of people who you have treated as beta customers, you’ve talked to them, you’ve on boarded them and you’ve heard what they have to say but sometimes, presenting that in such a way that an anonymous person who comes to your website and sees it for the first time is not necessarily going to understand it as well as if you had that in person conversation with them.
An explainer video can be a really good way to enhance the sales copy that you have and inform people about what the product is going to do for them and how it’s going to work and answer some of the questions and overcome some of the objections that they have, in a way that your text and copy is not going to be able to. I think that relying on those explainer videos as sort of a crutch can really help you especially if some of your sales copy is a little bit deficient or it’s not quite where it needs to be.
I find that a lot of the sales copy is really helpful from an SEO perspective. When somebody comes to your website and doesn’t have any preconceived notions about what something is but the video is really, really helpful. You can show your app and it helps give them that little bit of extra trust as well because they see the app, they see exactly what the state it’s in. It gives them an idea of what it is that they’re buying into versus if you send somebody an email without the screenshots even.
A video is better than screenshots because you can show them this how it works and this is what it will do for you versus telling them what it’ll do and maybe giving them a screenshot. It’s just more in depth and more engaging.
Rob: I have a blog post that we will link up in the show notes called How I Created 4 Startup Explainer Videos for $11. It talks you through the process that I used to create some low fidelity and just crappy bootstrapped explainer videos that we had on the homepage of the Drip website for a couple years, actually.
I do think that there’s a lot of value in explainer videos as well especially if you can execute pretty well on them and they don’t feel cheap and they do show the benefits. Like you said, there’s always a balance to video versus text, some people like to skim but if you create 60 second explainer video, it can have a lot of impact, a lot more than just a wall of text.
Mike: Yeah. I have an explainer video for Bluetick that I did when the product is a different name, and at a different URL and unfortunately, that name is used inside the explainer video so I have to redo the entire video.
Rob: That’s a bummer.
Mike: I did really well with the video and it worked well to explain what it did. It’s just the old name is plastered all over it.
Rob: I think that wraps us up for the day. If you have a question for us, call our voicemail number at 888-801-9690 or email us at questions@startupsfortherestofus.com.
Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons.
Subscribe to us in iTunes by searching for startups. Visit startupsfortherestofus.com for the full transcript of each episode. Thanks for listening. We’ll see you next time.
Episode 319 | Questions about the Technical Side of SaaS
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike answer listener questions about technical sides of SaaS. Some of the topics include pros and cons of including marketing website in main codebase, SaaS quality, and re-engaging a cold email list.
Items mentioned in this episode:
Transcript
Rob [00:00]: In this episode of ‘Startups for the Rest of Us,’ Mike and I answer several listener questions about the technical side of SaaS, and we also talk about how to re-engage a cold email list. This is ‘Startups for the Rest of Us,’ episode 319.
Welcome to ‘Startups for the Rest of Us,’ the podcast that helps developers, designers and entrepreneurs become awesome at launching software products. Whether you’ve built your first product or you’re just thinking about it. I’m Rob.
Mike [00:31]: And I’m Mike.
Rob [00:32]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, sir?
Mike [00:37]: Well, I think I mentioned a little bit in the last episode about some of the scaling issues I’ve been running into, and one of them I got kind of kicked into the groin this morning about. I logged in and checked in my server bill is on track to be about $500 more than I expected it to be this month. So I kind of have to drop everything –
Rob [00:53]: That’s not good.
Mike [00:55]: No. It could be one of two things. It could be just like I have the wrong size for the server. But my sneaking suspicion is that it’s actually a licensing issue. So I switched over from one program to another inside [Avisure?] and I feel like they’re charging me a heck of a lot more than I probably should be. Unfortunately, the billing cycle is already more than half way through the month, so I may have to just eat some of it which really sucks. But that’s one of the things that I’ve actually been probably more concerned about, is just am, “I storing stuff in the right way that I’m not going to get – I’m not going to run into this type of thing.” Because that’s my biggest concern is if I’m not actively in there looking at how much I’m paying for the servers every month then I could get whacked with this massive bill, and I just wouldn’t even really know it until it’s too late. And it’s like, “Okay, here’s your bill.”
Rob [01:40]: Yeah. That’s one of the dangers of this metered pricing. [?] the Google app engine. Something that I was doing for a while, when we were moving a lot of stuff around, and starting new servers and stopping, is I had a counter reminder. Every two weeks it would ping up and it would say, “Check AWS billing.” And it had a link right in, and so I would just log in and I would just look at the bill. And I knew sanity check about what it should have been each month, and so if we were a lot more than half that two weeks in, or we were a lot more at the end, then I knew we had messed something up. I did it every two weeks for maybe a year. I think I only caught something once, but it saved us probably $1,000 at the time. So that may be something you want to think about. The bigger danger – you know if it’s a mistake – because I’ve made several mistakes with AWS and accidentally purchased different things, and dropped $2,700 on some reserved instances that turned out to be not what we needed, like pretty gnarly stuff. But the bigger concern I have is, “Is this a mistake, like an accident? Or do you need that much in server costs in order for your app to run? Because that’s a much bigger issue, right. You don’t want to be paying out more than you’re making from your customers.
Mike [02:45]: Yeah. And, I mean, that’s one of my biggest complaints is just that the licensing behind everything in Azure – not everything, but in certain things inside of Azure, it’s very obscure. And so if you’re under one particular program with them – by program I mean like a licensing program. If you’re under one program with them, like you might be paying one amount. And then if you’re not under that, or if you’re on a pay-as-you-go subscription, you could potentially be paying four times as much for the exact same thing. And I’m just like, “I don’t have time to deal with this.” I don’t want to have to deal with this, but I have to. I kind of sucks. I don’t know. I have an email in to somebody at Microsoft right now to talk to them about it and say, “Hey, can we kind of move up the time table on our discussion about this.” So, I don’t know. We’ll see what happens here. But that’s kind of always been in the back of my mind that I need to pay attention to that stuff. And it’s just a distraction. You know?
Rob [03:36]: Yep. This is all the stuff that doesn’t provide any value for your customers, but you have to do it. This is like handling legal, EU compliance contracts. This is frankly handling HR when you get there. This is handling benefits and payroll, and even hiring support people, and it’s just expected [dev ops?] I see as that these are all required necessary things that if they’re not there, then it is a really bad thing. But it doesn’t provide value to your customer. It’s not about building the product. And so that’s the tough part, man, of kind of being bootstrapped, is if you had a bucket of funding you could at least hire some really good people because you could afford to pay them. And I’m not saying everything’s easier once you have that, but I see – as we started growing Drip, I really saw how having more money could make a big difference in how quickly you could move, because you don’t have to do everything yourself.
Mike [04:28]: It also allows you to ignore those problems that are at a smaller scale that if it was an extra $500 a month for three to six months, that’s not a big deal if you’ve got revenue and lots of customers to work with, because it just kind of evens out over all the customers. But when you’re still working with that really small number then it is a big deal, because you don’t really have the revenue yet to cover that and do lots of other things. So it’s a very different story. And I realized something when I thought about our episode last week where I was talking about some of the scaling issues. I went in and I looked at stuff, kind of based on that episode, and I was like, “Okay, yeah. I’ve really got to get passed this and just see what I can do to move forward, because I felt like I was turning my wheels a little bit, and I think even on the podcast it probably sounded a bit like that. So I went back and I started looking at things and I realized that what’s really happening – in terms of some of my scaling problems – is just a lack of visibility. Like I haven’t gone in and looked at certain things. It’s in the back of my mind, like that might be a problem but I’ve yet to go in and at certain pieces, looked at data, or taken measurements, or done anything like that. It’s kind of a lingering fear in the back of my mind, “Hey. You’ve got to pay attention to this, or you should go look at that.” But I just haven’t done some of that yet. And this is one of those areas where I haven’t gone to look at it and it’s in my mind as a scaling issue but nothing popped up as a problem until just now.
Rob [05:48]: Yep. I totally get it. So, for me, I don’t have a ton new this week. I’m actually flying out to Boston to speak at SaaSFest. So maybe I’ll see a few folks there. I’ve also got about three or four days of work that I’m cranking on. Something I forgot to mention last week in our goals episode was I did have a goal for DRIP revenue. And, I don’t know, I hinted around about it and didn’t say it, but I kind of wanted to say it so that it’s like on the record, and that I can revisit it next year and talk about whether we hit it. But I think we can 2x DRIP’s revenue again in 2017. This is a tall order now, right, because you’re talking large numbers. I’m talking about going from –
Mike [06:24]: Five customers to 10. Is that what you’re saying?
Rob [06:26]: Five to 10. Yeah. We’re talking about something bigger than that. So I wanted to put that out there and realized that I kind of wanted to get that on the record so we could cover it again in 12 months.
Mike [06:36]: Awesome.
Rob [06:37]: Today we have a bunch of listener questions. We’re getting some really good listener questions, and I kind of wanted to do a little theme episode where the first four really are – they’re kind of the technical side, technically related questions about software as a service. And so, our first two come from Ray Smith. And he says, “I love the show. I started listening at the very start in your first 20 or 30 episodes. Then I started a non-software business and I’m getting itchy feet to get back into software and I’ve been listening for the last couple of years. A couple technical questions.” So his first question is, “When creating a SaaS app, what are the pros and cons of having your marketing website and the actual SaaS code base combined into a single project?” I’m assuming he means like a GitHub project. Like same repo, right? Or if you’re in dot net, it’s an actual project. Stuffs not broken out. The idea is that when adding features, changes or bug fixes at the SaaS app, you can then update the sales website at the same time and push all changes in one go. So he’s saying there’s a lot of pros to it. What are the cons? Do you have thoughts on this either way, pros and the cons?
Mike [07:38]: I think both of them are a trade-off. I think that it’s perfectly legitimate to either have everything all in one project or to separate them out, and I can think of pros and cons for both of them. If you are going to integrate everything I think I lean more towards the cons for each of them, and it’s more of a, “Hey, just make sure you’re aware that these are the limitations, or that these are the types of things that you’re going to run into.” If you have them combined, then you almost need a developer to make any sort of marketing side changes, and that is not necessarily the greatest of positions to be in once you’re, I’d say, down the road a little bit. The other thing is that you are limiting the technology stack that you’re marketing site can be in. I know that a lot of people tend to go in the WordPress direction for their main marketing website, because it’s just so much easier to make changes and you don’t need a developer to do it, versus if you integrate that directly into your website, let’s say that you need to make some changes solely for SEO purposes. Well, then you’ve got all those things intermingled a little bit, and it makes things more difficult to deploy just because of the fact that you’ve got to push those marketing site changes and you have to push the app changes at the same time, and because those things are comingled you have no other choice. It’s very difficult to push them separately. Now, you can split them out into, let’s say, different projects for example, or you can deploy them into different directories and something along those lines, but it still runs into the future problem of having to bring somebody on who may be doing marketing, but now you have to have a developer go in an actually make the code changes. Those are, I would say, probably the biggest cons to it. If you do separate them, that problem tends to go away, but there are advantages to having them kind of all linked into the same tech stack. One of its which is like your signup process. You don’t have to have somebody go from one domain to a different domain to sign up. The other thing is that if you have them in separate in technology stacks, or even separate servers or sites, then you don’t have to worry about redirecting somebody from one site to another and then losing some of your tracking mechanisms for having them signup and then go to a different subdomain, for example. So I’ve run into this with Bluetick where my main website is on Bluetick.io, but then the app itself is on a subdomain. So in terms of where I have people sign up, I want that to all be done on the main marketing site, but because it’s a different technology stack than the backend application now I have to figure out, “Okay, how are they actually going to go through and signup? And how am I going to pass that information over the wall to the backend to have it do its thing so that they can login when they get to that point?” There is the cookie situation where you’re trying to track things with you various marketing tools. You want to make sure that people go through your sales funnel. But, again, those are things that you can do. You can get around them, but it’s just a lot of issues you’re going to have to be aware of.
Rob [10:29]: Yeah. I think you outlined it pretty well. I think when you first start something, I’d probably have them combined. But, boy, we hit a place where we were going to have to devote engineering time to breaking them apart. And once I brought Zack on who was doing growth marketing for us, he wanted to run all these split tests. He wanted to do things and we couldn’t. We were limited by the fact that the Rails marketing site was tied into the source code of the project, of the actual application. So I think if I were to do it all over again, I actually would probably split them apart now that I’m thinking about it. There were a bunch of shared styles. There were reasons for doing it, but I think, in the end, you’re going to want someone to be able to do stuff on the marketing site. And if you build it from the start and they’re already separated, then you don’t have to come back and try to separate it later. Because it was just hard for me to justify spending two weeks or whatever to rip it out. And, in the end, when we were acquired by Leadpages, that was one of the first things that they did. They essentially recreated the site over on a new domain and now we’re at Drip.co. It was a great move, because they do a ton of split tests. They change a lot of things very quickly. They can just iterate and go quickly. I think, overall, I would probably vote towards having two separate projects. You can have two repos, and you’re just going to want to deploy them together, or you can use some type of CMS if you want to. Ray’s second question is, “How do you handle data protection? Not security, but not losing customer data? I know you can do database backups daily, etcetera, but are there any good options for doing live backups almost instantly to an offsite location? One of my greatest fears is losing customer data.”
Mike [11:55]: This is such a technology dependent question. I mean, because if you’re running Windows in Sequel server, then you’ve got one set of answers. And if you’re running MySQL and using AWS, it’s a completely different answer. And then in addition to that, if you’re using any sort of key value parastorage from either AWS, or Azure, or Rackspace, or any of those other providers, then you have this secondary set of data that is not in a database, but it is important to have that along with your customer data. I don’t know how to best answer this just because it does depend on those things.
Rob [12:30]: I actually think the answer for any relational database is going to be the same. And I think your right for key value stores like [Retis?] or whatever, I would argue that most people use those for caching, and that it you don’t necessarily need to back them up unless you’re using them to perpetually store things.
Mike [12:45]: It depends on what you’re doing there though. In Bluetick, for example, I store copies of header information from emails that I’ve synchronized from their mailbox.
Rob [12:54]: Okay, so you store them in [Retis?] or in a key value store?
Mike [12:56]: Yes.
Rob [12:57]: Got it. So then that you’d have to back up. Now is that writing to disk every minute or two and then you’re sending that off to the equivalent of S3?
Mike [13:04]: It’s synchronized. It’s the equivalent of S3.
Rob [13:06]: Okay.
Mike [13:07]: Yeah, I would say it’s kind of like that. The cache doesn’t go away when the machine restarts or anything like that. It’s just a long-term data storage. It’s basically like a non-sequel database is more or less the best way to describe it.
Rob [13:20]: Right. I think his concern is – he says, “I know you can do daily backups, but can you do stuff that’s more up to the minute – instant backups?” And any RDBMS has log files, right? And if you’re putting those log files to multiple drives – now maybe they’re not offsite instantly – but you can basically do a point-in-time restore using those log files, right?
Mike [13:40]: Yeah.
Rob [13:40]: And that should work for MySQL and Sequel server and PostgreSQL and all those.
Mike [13:44]: Yeah. That’s generally how you would do it. For the longer term storage stuff, even in AWS or Azure there’s multiple ways of having that data be sent out. Usually you can use some sort of location specific storage where you’re going into a particular region of the country, or a specific data center, or something along those lines. The other thing that you could look into is having essentially a multi-site fail over. Now, that’s not something that you want to get into on day one –
Rob [14:11]: Yeah, you’re way out ahead of Ray.
Mike [14:12]: Yeah.
Rob [14:13]: Ray’s talking about whether to have his marketing site with his app at this point.
Mike [14:19]: Yeah.
Rob [14:19]: I think that you wouldn’t even want to think about that at this point. I think, “A” if you have two hot swap databases – or not hot swap – but you have a main database, and then you replicate out to a second fully developed database, a backup that’s essentially hot and sitting there at any time, that’s you’re instant offsite backup, in essence. Or if you put it in another zone or something. That’s probably the safest way to do it. But I don’t think you need that at the start unless you’re dealing with really critical stuff. I think having your log files put to multiple drives, and written out to S3, and then having a daily partial backup, and then it’s a weekly full backup. This is the standard stuff that DBA’s would do. That’s going to get you a lot of protection up front. You don’t want to over-engineer your SaaS app when you have 20 customers or whatever. And then I think down the line, at some point, you are going to want that fail over in case something crashes. But a lot has to happen for all of that to be gone.
/// [15:13]
Mike [15:12]: Yeah. And most databases that I’ve seen you can go down to like an hourly backup that’s just a partial backup, and then you do a daily backup, and then you do a weekly backup. So you take your weekly’s, you put them offsite, and then you do your daily’s, and then your hourly’s are based off of your daily’s. So at most you would have to put in – let’s say it fails on a Friday – you’d have six days’ worth of daily backups to apply, and then you’d have however many hours of hourly backups to apply. Which is not, you know it sucks, but it’s not a huge deal, and you’d at least have that hourly snapshot.
Rob [15:43]: Right. And Ray, that’s advice from two guys who are not DBA’s, who basically know just enough to be dangerous.
Mike [15:50]: Well, I actually know more than a lot of DBA’s that I’ve met. I do agree with Rob that all the stuff I started talking about with being able to store your data in multiple geographic locations, I wouldn’t even worry about that stuff. I would just go with the hourly backup at the most, and then just work from there. If something crashes, if it’s some customer data, it’s probably not that big a deal. Especially if you only lose like an hours’ worth.
Rob [16:14]: I don’t know that I’d say not that big of a deal. I do think it will be a big deal if it happens. Just the odds of it in the early days when you have a small amount of customers, it’s just not that likely to happen. And so, you’re right, you need these backups. You want to be able to restore from them. You don’t want to lose data. But there’s always this knob you can turn of how far do you go when you only have a handful of customers.
Mike [16:35]: Right. The one thing I would point out – because I’ve seen this happen to somebody before – is test the backups. Make sure that you can restore them, because I’ve seen somebody’s business be completely destroyed because they thought they were doing backup and they weren’t, and their backups didn’t work. They not only lost their entire database, but they also lost all of their customer’s information, and the way that they get in touch with all their customers. It was all gone.
Rob [16:58]: Pretty crazy. I remember that. Our DBA does that once a month. Takes all the backups and restores them onto a server and queries it and shows us the results. It’s kind of nice. Our next question is from Roger in the UK. And he has a question about a SaaS app accessing a corporate database. So he says, “I have an idea for a product which I’d rather implement as SaaS rather than the client installing the application, because the software’s complex, it’ll be updated regularly, and therefore, the client installing it would not be practical. However, it would require access to the corporate database of the customer. How easy is it to get a client to provide the database name, user ID, and password to a SaaS app so it can access their internal relational database?” Mike, did you cringe when you read this? There’s just no chance – the answer is there’s no chance ever that this will work. No chance they’re going to give it to you. Not only are they not going to give it to you, even if they created a read-only login. You’d never make your database to the outside world. You don’t open the firewall ports to it. So, I think it’s probably more useful to talk around what are the other options, because you’re not going to have any customers if you do it this way. Do you have other ideas, maybe, for how Roger could approach this? And if he needs access to their data, how he can do that? I also think we should probably discuss whether it actually needs to be a SaaS, you know, or they need to perhaps install it inside their firewall.
Mike [18:22]: I think that was what kind of came to mind for me. You almost need this piece of software that’s in their environment that’s running, that is separate from the database. And the closest thing that I’ve seen to this type of model is where you’re essentially providing somebody a virtual machine that they can put into their infrastructure that acts more as an appliance than anything else. And that’s probably the closest thing that I’ve seen. But I don’t know as you would get somebody to hand over the database name and credentials and stuff like that, unless it was to go into something like that where it is reaching in, it’s accessing the database, but if it’s an existing database, that’s a totally different story. I’m getting the impression from the way that this question was phrased that this is acting on an existing database, and it’s providing statistics and queries and additional indexing of the data that’s in there, which is a different type of problem that you’re solving then if you simply need the customer to install a database in order to run your app. So those, I think, are two very, very different situations. Now if it’s the first one where you’re trying to analyze their existing database, you really need to have some sort of a downloadable piece of software. And if they want the latest features you’re going to want to have them update.
Rob [19:34]: Or you could build and auto-updater in it, right? Something that helps manage that, and it allows them to pretty easily update. It depends on how complex it is, but this is not out of the realm of – like .Net’s gotten pretty good at being able to auto-update desktop and server apps.
Mike [19:48]: That’s problematic though just, because of the issues that you’re going to face with like user access control in Windows. It’s actually gotten much more difficult to do those types of things.
Rob [19:57]: Yeah. When I say “auto update,” I don’t mean in the background.
Mike [20:00]: Okay.
Rob [20:01]: I mean that it pings the add man and it says, “Hey, it’s time to update.” One-click update. Maybe that’s what I meant.
Mike [20:05]: Okay. Yeah.
Rob [20:06]: That is what I meant. I meant much more of that, where they don’t have to download this big zip file and read a bunch of instructions and run command line things. They click the button, and as long as you give it the user access control stuff, it’ll go out and download it, and verify, and install the MSI, or whatever.
Mike [20:22]: Yeah. Simplistic updated –
Rob [20:24]: There you go.
Mike [20:24]: – versus auto updating.
Rob [20:26]: Yep. That’s a good point. The other idea I have here is, I don’t know to what extent Roger needs his code to be able to access their database, but it just depends to what extent. If he needs to run queries across millions of rows, then yeah, he really does need direct access. But if not, and if you’re just pulling users out to look at something or you’re just pulling different things out, you could either ask the corporations to build like a small rest layer – like a little API on top that you’re hitting from the outside – or build it for them. If all of your customers are going to be running Sequel server and they’re all going to be paying you a tremendous amount of money – let’s say the average contact value is $50,000 a year, or $100,000 a year, then build a single rest API layer, and you know that it’ll run on Sequel server. And if they’re running Sequel server, they’re probably running .Net so you build it in C#. And if you’re on PostgreSQL then maybe you build it in PHP or in Python or Ruby. But you pick a language where you almost lay something on top of it, and it accesses it and then is a couple to communicate it, like as a “conduit” is probably the best word. They would still have to install that piece but it’s a server piece that’s just communicating out through, obviously, a highly secure mode of communication, encrypted and SSL and all that stuff.
I still think you’re going to run into people who don’t want to install stuff on their servers but, again, it really depends – without knowing more about the idea. Because people do install monitoring software on their servers. They’ll install NewRelic, or they’ll install Redgate. So it’s not that it never happens. It’s that you need to “A”, get the credibility and, “B”, really tell people what they’re installing, and what it’s going to do on their servers. And if it’s going to provide them a lot of useful information, I do think that you can get some people to agree to do this.
Mike [22:04]: There’s a big difference between installing something like a server performance monitoring software, and something that goes into the core of the database and pipes any sort of data outside of the local network. That’s a big problem. Those are two entirely different things, and any DBA is not going to want to do that.
Rob [22:21]: That’s right. Any CTO won’t want to do that, unless the value proposition is there and it’s worth it. I mean, that’s the thing. Without knowing what this idea is, are there other companies that are already doing this, and doing it successfully, and it’s the standard for this type of application. What if it’s offsite backup software? Yeah, they’ll probably do that, right? Because that’s the whole point. It needs to back it up, it needs to send it off site. But you’re right, if it’s a time tracking app, then the odds of that are much, much less.
Mike [22:52]: Yeah, but even you get to a certain level, or certain scale, with the type of customer that you’re targeting, they are going to want to be able to control those things in house. They’re going to want to install them themselves. And even with an offsite backup, there’s companies that do provide appliances like that and they just buy multiple appliances and they point them on opposite sides of the country and it just propagates the backups from one side of the country to the other. And the companies are willing to pay tens of thousands for each of those appliances and it maintains in their control. They don’t necessarily have credentials to all the core stuff inside of it, but it’s an appliance. They own it. They can do whatever they want with it, and they control where the traffic goes. It’s not like it’s reaching out to some external service that they need to completely control all the traffic going into it and out of it.
Rob [23:37]: There you go, Roger. You heard it here first. If you’re building an offsite backup engine, we’re recommending using an appliance, or at least having a better chance of doing it. Now I think that depends if your certain clients are willing to do that. Certain clients of certain sizes. I think if you talk to a small or medium-sized business – let’s say you talk to a dentist, who has a couple servers running something. Or you talk to a 30-person law firm who, definitely has IT folks and definitely has servers, but are they going to be willing to pay $20,000 a year for an appliance? Or would they perhaps prefer there to be a less expensive option for getting offsite backup. So that’s where I think if you choose your customer wisely, you could potentially find folks who are willing to deal with some of these different options we’ve thrown out. Our next question – it’s our fourth technical SaaS question, and then if we have time, we’ll move onto another. This one is from John Buford. And he says, “Hey guys. In episode 311 with Derek Rhymer, you mentioned “SaaS quality” several times. Can you describe how you measure or quantify SaaS quality? Is it based on the code base, or is it more aligned with overall business in terms of MRR, low churn, big list size, etcetera? Are the differences in quantifying SaaS quality as viewed from a seller of a SaaS app versus the buyer?” This is not a common term. I just happen to throw it out and say [?] is a really high quality app. And all I meant by that was the code base was pristine. It had a tone of test coverage. Zero or very, very few known bugs, modular code, really good coding standards, the deployment and architecture are all set up. Just everything you would want as a developer from a code base was there. In addition, it looks really nice. The design is really nice. It just feels like a high quality app. That’s all I was referring to. I don’t know if anyone else’s definition would be the same as that, but I was not talking about financials, or churn, or big list or anything like that. It really was specifically from more of the technical side of things. Moving on to our next one. We have a question from Chris [Cottom?]. And he says, “Hey guys. You’re both now working on businesses that deal with tons of email, so maybe you’ll have some insight into this question. Do you have any tips for reengaging with an email list, or with leads with whom you haven’t communicated in a long time?”
Mike [25:51]: Yeah. I think that if you’re trying to reengage with people then you’ll probably want to, I’ll say, prep the email engine a little bit, and have at least some idea of what it is that you’re going to be sending them down the road. So let’s say you got a couple thousand email address that you haven’t touched base with in, call it 10 months, for example. In a situation like that you probably want to map out what it is that they originally signed up to the list for, and try and translate to say, “Okay, we’ll how do I get back on track with that? Where did things go wrong? Why did they go wrong? And how do we get back on track with that?” And map out the next half dozen emails that are going to be sent. Now, I don’t think you need to write all the text for each of those six emails, but you at least need to have a conceptual level of what the bullet points are that you’re going to cover over the course of those next six emails, and when you’re going to be sending them. Because the last thing you want to do is send out an email to those people to kind of reengage with them and then drop off the face of the earth again. I would start out by doing that, figuring out what it is that you’re going to say to them. And then, in addition, the first few emails that you send out to them to kind of reengage with them, you probably want them to be a little bit shorter than you otherwise would. Try and provide some value up front. You don’t want to just launch into a sales pitch, for example, because it’s been a while and they haven’t seen emails from you. You don’t want to lead with a sales pitch at that point.
Rob [27:10]: Yeah. I think what you said was good advice, and I think you want to provide a lot of value in that first one. This is a make or break moment, and you’re not going to get most of the people back, but you really have to be sure you explain why you’re contacting them; why they were originally on your list. And then give them something free that should otherwise cost money. Or give them a really great tip. Or give them something – depends on at what scale you’re doing this. Are you doing this to 10 people? In which case I’d do some very custom something or other. Review their website or something. And if you’re doing it for 10,000, you can’t do that, but you can give away an e-book or video course or something that is of quality to basically apologize and get them back.
Mike [27:47]: It gives them a reason to stay on your list, is really what that is.
Rob [27:50]: Yep. That’s right. There’s a whole other topic. Originally when I read this I thought it was for reengaging people who are on your list but who just haven’t opened emails in a while – kind of people who have disengaged. But there’s a really good workflow for this in the knowledge base. We go to KB.getDrip.com and search for I think it’s like “reengagement.” There’s workflow blueprints there. There’s only maybe 20 of them, so it’s easy to flip through. In essence, it sends them an email and it just says, “Hey, I’ve noticed you haven’t opened emails in a while. I’m going to unsubscribe you, basically, and if you don’t want to do that, click this link.” And you get a small portion of people to hang around and reengage a bit. The good part about that is you’re actually increasing your sender reputation by doing that because, these days, Gmail and Yahoo and these ISP’s, they look at the domain that it’s coming from, and if your open rates are crappy then they start penalizing you and sending you either into spam or into the promotions tab. So keeping that high is a good thing. In addition, it can cut down on your costs. If you unsubscribe those people, then you’re paying your ESP less money because you have fewer subscribers but your open rates will be a lot higher. That’s a good question. Thanks for the question, Chris. I hope that was helpful. Our last one is from Ali, and it’s a question about whether email lists are really relevant/effective in the US. He says, “You’ve mentioned email lists for marketing and sales throughout many episodes, and it made me wonder are things really this different in the US? I’m from Saudi Arabia. If I would ask my colleagues who work in sales and marketing about using email lists, they would not even entertain the idea – not even as a last resort. From my experience, if you send unsolicited emails – and “unsolicited” is the key here – unsolicited emails they will end up ignored or deleted, and if you persist, your domain probably will be blocked altogether. It’s all about knowing the right people in a [?] organization” and some other stuff. It feels like maybe he’s confusing kind of cold outbound email versus spamming, versus opt-in marketing lists. You have some thoughts on this, Mike?
Mike [29:42]: Yeah. Well, as you pointed out, the whole difference between unsolicited emails and things that people have opted-in to because they want to hear more about a particular topic. That right there is the fundamental difference between those two things. I will say that there is some semblance of certain types of cultures would probably shy away from certain sales techniques. And you can even translate this not just into cultures, but different groups of people, one of them being developers. Developers tend to not want to call people on the phone. So those type of people will tend towards email lists and other types of marketing efforts which don’t involve them getting on the phone and actively talking to a prospect versus that email list. It’s much easier for them. And then if you take that the other direction, you can say, okay, what about an inside sales rep. They’re used to being on the phone all day. So their natural inclination is to pick up the phone and call people. I don’t think that it’s a whole lot different whether you’re talking about different groups of people, or different cultures, they all have their natural tendencies to do one particular thing. But that doesn’t mean that it’s always the right thing for every situation. You do have to take it into context a little bit. But the fundamental thing is just unsolicited versus opt-in.
Rob [30:56]: Right. That’s a big one. That’s kind of building that prelaunch mailing list. Now there is this whole other branch of essentially B2B cold email. So there’s the CAN-SPAM Act in the US. And, obviously, if you’re sending bulk unsolicited email to consumers, that’s illegal. And there’s no way around it. I’m pretty sure if you send individual cold emails pitching a service or something, that that’s illegal. I don’t know enough about cold email, because we don’t allow it at Drip. But I do know that B2B there is a carve out in CAN-SPAM where if you’re sending like a direct, one by one emails from one business to another soliciting stuff — there are companies like LeadGenius and LeadFuze – where I’m an angel investor – and that’s a little cottage industry that’s formed around sending cold email outbound one at a time to prospects. And that has had success. There are entire books, like “Predictable Revenue” that are written around this concept. You probably have some thoughts on this, Mike, having worked on Bluetick now for the past six to 12 months.
Mike [31:55]: Yeah. I looked into this pretty extensively because that was one of the questions that came up early on. Not only did I have it, but there were people who asked me specifically. This is more applicable directly to the US because of the CAN-SPAM Act, but there are three general classifications of email. The first one is the commercial one. Most people are more familiar with this because they think if of it as the spam laws that people are running afoul of. So there’s the three different categories. There’s the commercial, and then there is the transactional emails which is if you purchase something from someone, they can send you a receipt; they can send you follow-up emails, let’s say, for you to download something. It’s generally the emails that you would send to somebody in the course of doing business with them. And then there’s this third category which is called “other.” And the documentation that I saw literally called it “other”, which is interesting because they don’t put a very good definition on any of them. They specifically say that for commercial, you’re emailing somebody in an effort to sell them something. But if you, let’s say, send somebody an email and ask them, “Hey. Can we set up a meeting? I want to talk to you.” That’s not considered a commercial email. That falls into “other.” Pretty much anything that’s non-transactional, or isn’t directly pitching something for somebody to purchase, falls under “other.” So it becomes this very grey area where you get into that situation and it’s like, “Okay, well, this one might be spam. This one might be considered commercial, this one might be considered “other.” Transactional is the one that’s really well defined. The other two are not. And it does depend, I think, a little bit more on whether or not you’re emailing with a business, versus an end-user or consumer, so to speak. But there’s a lot of grey area there that people work with, which is kind of the reason why the ESP’s are the ones that tend to be the people who are enforcing that – not the Google’s of the world or other mailbox providers. They don’t necessarily care as much, because if you get your domain banned, they’re not the ones who suffer for it. But with the ESP – you’ve run into this with Drip – it’s your IP addresses that are at risk. Not the customers. That’s really why those ESP’s really crack down on those, and really want to make sure that you are not sending bulk spam because they’re the ones that are penalized for it and all their other customers. There are revenues at stake.
Rob [34:09]: Yeah. That’s right. You look at MailChimp or Drip and we have entire massive algorithms. I won’t go so far as to say their AI, but it’s machine learning stuff that’s looking at listed or being imported. It’s looking at different signals that people signup behaviors in the app. Certainly the open and the click metrics and spam complaints. We have this whole network of we’re approaching a couple dozen signals that we look at over the course of the lifetime of a customer, all the way from the first time they entered that form all the way through their sending and we flag a lot of people and manually review them, and we always try to educate, to try to help the customer understand what they’re doing. But when you have IP’s and sending domains that you’re worried about, this is the stuff you have to have in place or else, as Ali originally mentioned, if you were sending unsolicited, then the stuff will get marked as spam and then your IP’s get dinged and then you can’t get into people’s inboxes any longer.
Mike [35:01]: Right. According to the official guidance from the CAN-SPAM Act, if you go over to FTC.gov, they’ll spell out certain things. They kind of boil it down into seven points. One of them is don’t use false or misleading header information. Don’t use deceptive subject lines. You have to identify it as an advertisement. Telling people where you’re located, giving them a capability of opting-out of future messages. But again, these are for bulk emails. And if your sending individual emails, it kind of falls into this very, very grey area. If I send out 10,000 emails – or even, let’s say 100 – it’s a very different story than if I send out the same email to 35 people and I individually click send on each of those. It’s treated differently. I also think that because of all the grey areas there, you’re in a different world when it comes to interpretation of what it is that you’re doing. And if you were to send out 10,000 of them you’ve got 10,000 possible sources of complaint. And that kind of puts you in a much higher risk category, I would say, then if you’re just emailing a few people here and there. Or even just 1,000 people but it’s over the course of a couple of months or a couple years or something like that. It’s a very different story.
Well, thanks, Ali. I hope that answers your question. And I think that about wraps us up for today. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690. Or you can email it to us at questions at startupsfortherestofus.com. Our theme music is an excerpt from ‘We’re Outta Control” by MoOt used under creative comments. Subscribe to us in iTunes by searching for ‘startups’ and visit startupsfortherestofus.com for a full transcript of each episode.
Thanks for listening. We’ll see you next time.
