Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about handling failed payments, cold calling, and staying accountable. These topics come from more listener questions and Rob and Mike share their expertise and advice on the subjects.
Items mentioned in this episode:
- Drip
- Blue Tick
- Churn Buster
- LeadFuze
- LeadGenius
- HostFamily
- Successful DJ
- Startup Stories Podcast
- FogBugz
- TeamWork.com
- Codetree
Transcript
Rob [00:00]: In this episode of Startups for the Rest of Us, Mike and I talk about handling failed payments, cold calling, and staying accountable. This is Startups for the Rest of Us, Episode 276.
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at launching software products. Whether you’ve built your first product, or you’re just thinking about it. I’m Rob.
Mike [00:28]: And I’m Mike.
Rob [00:29]: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What do have this week, man?
Mike [00:34]: Well we’ve got an email from Will Samuels, who wrote in to us about our 2015 predictions, and he says he thinks that Rob was right on the storage. He gives us a link to … I think it’s hubic.com, it’s H-U-B-I-C dot com. They are a hosting provider, and they are, I believe the third largest in the world is what he says. According to the “”Way Back Machine, he says that back in March of 2015, they were offering 10 terrabytes of cloud storage for €120 a year, so that’s 5 terrabytes for $65.50. So according to that, Rob you were correct on one of your predictions last year.
Rob [01:13]: Wow, thanks Will, for writing in. Yeah, both you and I tried to look for some confirmation, or otherwise, from our 2015 predictions and it was kind of hard to find them and I think found some shady cloud hosting thing that did this, but I didn’t really want to call it good. So if these guys are the third largest in the world or thereabouts, I think that’s pretty good. Then when I made the prediction again for 2016, I can’t count that as a win, can I?
Mike [01:34]: I don’t think so. In fact, they’ve actually dropped their price, so 10 terrabytes is no longer $130, it’s more like $65 or so at this point. They’ve dropped the price since then, yeah, so 10 terrabytes personal cloud.
Rob [01:47]: Let’s be honest, this is kind of a gimmee. Every time you’re predicting that storage is going to get cheaper in the next year, it’s kind of obvious; like processors are reading it faster, phones are going to get better cameras and high resolution screens. This is not that interesting, but the fact that the price point was actually under that exact point is kind of cool. That’s a lot of storage, man. Five terrabytes, or now I guess, 10 terrabytes for that much?
Mike [02:10]: Yup.
Rob [02:11]: So, I’m running some split test right now on DRIP, on the homepage, and other pages, to try to nail down some messaging. We’ve had the same positioning and messaging for a long time, and I just want to see if something else resonates, because we’ve changed so much over the 18 to 20 months since we really nailed down that headline of “lightweight automation that doesn’t suck”. and I’m wondering if perhaps different ways to phrase that that might resonate with the current traffic to come rather than … the last split test I ran was 18 months ago. S, I always find split testing — I feel like it’s pain to get set up, even with something like Optimize.ly, but man, it’s so much fun. It’s so much fun when you hit Start and you’re just excited. Every morning, I wake up like a kid on Christmas and look at the results to see, is something winning?
Mike [02:52]: I thought you were going to say you’re excited to look at the credit card bill and say, “Oh, I just lost a thousand dollars yesterday.”
Rob [02:57]: Oh nice. Well, that could be the other thing, I guess, right? Like, “Doh! I totallt hosed it.” Yeah, I definitely a keep a close eye – when something like this, when it’s on the homepage, or it’s a high traffic page – I like to keep a pretty close eye, and tabs on it, because you’re right, you can, kind of, screw things up pretty bad pretty quickly, I think.
Mike [03:15]: Yeah, funny you mentioned that, because I’m just kind of in the final stages of finishing marketing plan for my product, Bluetick, and that’s kind of one of those things that I’m looking at pretty heavily right now, is to figure out what should the exact wording of the messaging be. I have my personal favorites picked out, but I’ve also got a list of about 10 different things that I want to go through and start testing to see what resonates with people, and whether or not those things take people through and convince them to actually sign up for, like a mailing list. So I’ve got to look through those, and do some split testing myself, and see what comes out of that, because whatever you think may not necessarily be the winner. It may be, but at that point, you’re just spending $1,000 a day or whatever, but it will be interesting to figure out what happens and what comes out of that.
Rob [03:58]: If I were you, I wouldn’t start with all 10. I would go back to the people who have already bought from you and run those by them and have everybody pick up their top one or two, and then try to aggregate a few from there. Because it seems like you already have a little bit of an audience, and if you have a mailing list as well you could toy around with that. If you felt like sending people an email or ask them to choose how they would describe it, or something like that. It might give you a little leg up so that you don’t have so many things to test, because you need a lot of traffic to test that many options.
Mike [04:30]: Right. I don’t think I was planning on going through and testing all 10 of them, but it also kind of puts in my head the idea that if I go to those list of 12 or 13 people that have place preorders so far, I’ve got their language, so I will essentially be finding more of those people, which is not necessarily a bad thing, but it’s also a very self-selecting group. I wonder if there are other groups out there that it would resonate more with. I don’t know the answer to that, but I’m also not sure whether or not that makes a difference at this point, and I don’t think that it does.
Rob [05:00]: Yeah, yeah. You’re pre-launched now, and so I would focus on super small vertical target market, and if selecting now, then that’s actually good. Because if you go out and try to get multiple groups of people in there, then they’re going to be asking for different features, and it’s going to conflict. I would imagine you have small entrepreneurs and solopreneurs and single founders and probably some bootstrappers in there, that type of thing. If that’s where it’s working right now, I would focus on that for the time being until you feel like you’ve tapped that market out, rather than trying to expand out. Maybe it’s not even premature optimization, but it’s just going to be time consuming to try to do this, when I think there’s other stuff that you could better spend your time doing.
Mike [05:44]: Yeah. Either way, I still have to go out and start doing … I want to start doing some paid acquisition to start acquiring email addresses that I can start building up that mailing list. I think that tying back some of the messaging into that is probably wise at this point. It would at least give me some data points. But you’re right, I don’t think just testing all of them would probably be a good idea at this point. I haven’t really gotten to the point where I’m going to actually pull the trigger on that. I’m just starting that process now.
Rob [06:11]: I think I realized when you said dropping a thousand dollars a day, you meant on ads to split test, right?
Mike [06:16]: Oh yeah.
Rob [06:18]: Okay, because right now you don’t have any organic traffic yet. No, the DRIP that I’m doing, I’m not running any ads to this. This is all the organic traffic that comes through. We get a bazillion visitors a month, so it’s actually going to be pretty easy. I was thinking you meant, when you said losing a thousand dollars a day, I was thinking you meant that if you run a split test and one of them is doing really poorly, that you lose the trials and therefore lose the thousand dollars a day.
Mike [06:39]: Got it. no. I haven’t even thought about that, but I was kind of operating under the assumption that you were going to be doing paid advertising for those split testing, but it makes sense.
Rob [06:47]: Yup, cool. Hey, we have a bunch of new iTunes reviews. Can’t read them all, but I’ll read a couple here. This is from Jerry Weir. He says, “Great show, value in every episode. If you’re at all into starting your own business alone or in a team, you really shouldn’t miss out subscribing for Startups for the Rest of Us. Actionable advice in every episode.”
Then we have one from Prof. Duchamp. Five star review from the US. It says, “Listen or miss out, you choose. If you’re doing anything related to startups, you would be plain silly not to listen to this podcast. Mike and Rob do a really job of exploring the minutiae of building a platform. It’s not about interviewing the biggest names in the industry, or even talking about the trending topics. They get into stuff that really matters. Keep doing what you do.”
Lastly, from Zephron ADR, from the US, he says, “Great content for first time entrepreneurs, great knowledge, thanks for sharing.” We have 462 worldwide reviews in iTunes, and we’re looking to get that number up over 500, so if you haven’t ever given us a five-star review, it would be awesome if you could. Log in to iTunes, hit that five-star. Even if you don’t write a full review like these folks did, you can just click the five-star and it will greatly help us out. If you feel like we’ve given you some value, it would be great to get some back.
Today, we’re answering some more listener questions. We had some really good questions come in, the first one is from Don Felcor, and it’s about handling failed payments and dunning. He says, “Hey Rob and Mike, I’d love to hear how you guys handle subscription problems that relate to failed payments. For example, if you use the default Stripe subscription system, you have three options after the user’s payment method fails three times. Those three options are to “cancel the subscription, to mark it as unpaid, or to leave it as is.”
By default, Stripe selects “cancel the subscription”. I feel this is bad mojo because you then lose the subscription that you worked hard to get. Therefore, I’ve changed it to mark it as unpaid so I can follow up with the customer. Given the other options, what would you recommend SaaS companies do in this case?” Then he has a follow up question. Maybe we’ll answer this one first, and then look at that one later. You have any thoughts about this?
Mike [08:42]: It seems like that’s the way that it should be handled. You don’t necessarily want to just make that subscription go away. You want to go back and talk to those people for a couple of different reasons. One is that it could just be that the credit card failed because it expired or their account was hacked so they got a new credit card. There’s a lot of different reasons for the credit card to fail. So it’s not necessarily uncommon for those things to fail three times, but there’s also a lot of cases where customers have decided, “Hey, I know that my credit card is expiring. I’m going to use that as an opportunity to essentially wipe the slate clean on all of my paid subscriptions, and anything that I really want to renew or that I depend on, then I will renew it.”
Those are the types of people that you probably want to reach out to, that you can at least get some sort of feedback about why it is that they cancelled or why it is that they chose to go in that direction. A couple of other options for getting those customers back…I mean, obviously you can send some sort of dunning email to them if you’re not doing that already, but there are services out there like Churnbuster or Stunning.co that you can use that will go out and try to get those people back for you as customers. It really depends on whether or not you want to be the one reaching out to them or if you’re at a scale where…I don’t want to say that their feedback to you doesn’t necessarily matter, but it is less important to you to hear the specifics of what it is that those people are saying. Those other services might be an option for you if you have other things that are a little bit more important to you than listening to the specifics of what their feedback is.
Rob [10:08]: Yeah, I think the meat of Don’s question is about whether after three email attempts – because that’s what Stripe does, right, it’s built in that they email three times and you can set the intervals. And after they haven’t responded, or updated their card after three attempts, do you cancel the subscription or not? Don says he doesn’t, and that he then wants to touch base with them.
So in my experience of trying to do this manually, and I did this with HitTail for a while in the early days, just because I didn’t know any better and I was experimenting and trying to get the people back. If they didn’t respond to the three credit card expiration emails, I never got a response to a personal email. Either they weren’t getting the emails, they didn’t care about them, they were going to spam, they’ve abandoned the inbox — there was just something, where if they’re not going to open or come back after three emails, I never… and let’s say I emailed by hand maybe 20 or 30 people. It’s not thousands of people, but it was enough that I stopped doing it, because it just was a bad use of my time. So I didn’t get good results from there.
With that said, I think that if you have phone numbers, and you can reach out, I know that that is dramatically more effective. I saw an article by [Allan?] at Less Accounting, where he talked about – this was a couple of years ago – but he talked about, I think it was like his sister doing basically dunning phone calls to people, and that they dramatically changed the number of people who gave them a credit card, and basically an updated card number.
That’s my thought. If someone doesn’t respond to three, and you’re just going to send them another email, I actually don’t think it’s worth it, and I would put their subscription into cancelled mode. Now, with DRIP, we wrote our own engine. We didn’t use the Stripes subscription API, we just used a [bare?] charge API, and as a result, after three emails — I think it’s three, maybe it’s four – your account is pending cancellation, and if you come back and try to log in to that account again, then it says “Hey, your card expired, or your account is cancelled, Just enter a new card here and we’ll get you started again.” It is easy to undo that, and I’m not sure if it is with the Stripe subscription API, because obviously we don’t do that.
Mike [12:06]: I’m not sure if Stripe actually sends those people emails if their payments fail. I think that it initiates a web hook – or you can have it initiate a web hook back to your site – but I don’t know that it actually sends them an email on its own.
Rob [12:17]: Oh got it. Okay. Thank you for that clarification. Absolutely then, I would capture that web hook and send some automated emails – whether you use Stunning or Churnbuster, or whether you just write some code to handle that web hook instead of emails – that has to get done, yes. I don’t think that you – even at a small scale – you don’t want to handle this manually, because it’s going to happen a lot more than you think.
Mike [12:39]: I really like the idea of capturing the phone number and getting in touch with them. It just sounds to me like that’s something you would probably want to do much earlier on in the cycle of them becoming a customer. So maybe a week or two weeks after they’ve become a customer, you pop something up and ask them for their phone number. And you can use that – maybe bribe them in some way, shape, or form. Either you give them an extra amount of service, or discount, or free white paper, or free consultation, like that, in order to gather that information, so if it does happen down the road, then at least you’ve kind of planned for it in advance.
Rob [13:10]: I’m glad you said that. It reminded me of what I did with HitTail. We do something similar with DRIP, although we do it during the guided set-up. We’re asking some other questions, and we do ask phone numbers and say, “We’re going to contact you for billing purposes.” It’s not required, but we get a good response rate to that. With HitTail, I’d coded up this form where it was like every fourth or fifth time you logged in, if you didn’t have a phone number, it would do a little pop-up, and it would say, “Hey, just in case your account gets messed up, can we ask for your phone number? We’ll use it for billing purposes.” We got a nice chunk of phone numbers, and then I went – this is before Stunning and Churnbuster, right – I went and I got an account with, I think it was Coalfire, and they basically do Robo-calling through an API. In essence, I recorded a 45-second call from me, it was just like, “Hey, this is Rob, I’m the owner of HitTail and your credit card is expired, and blah-blah-blah. Go to hittail.com/account to update your credit card.” Something like that. Then that would then fire, after all the emails had gone and people weren’t doing it, then it would put them into a call thing and they would basically get an automated call from me. Most of them hit voice mail – you can see how many hit voice mail and how many didn’t. But the impact of calling versus just emailing was substantial, I will say. I don’t want to give exact numbers, but it was substantially better. Even with Robo-calling, which is not going to be nearly effective as actually having someone do it. So if you’re at any kind of scale, you’re definitely going to want someone to help out and actually make the phone calls.
Then the second part of Don’s question, he says, “On another note, I know from conversations with Derek,” – that’s my co-founder with DRIP – “that he built the billing system for DRIP from the ground up, and it does not use Stripe-built subscription system. If you’ve built it that way,” – which we have – “how do you guys handle this kind of stuff?”
To be honest, we handle it similar to Stripe. We basically just, we retry, and if it fails, then we email. If you notice – I don’t think we’ve ever gotten our dunning emails. I think they might be published on the Stunning.co blog, to be honest, because he did a dunning series. They may have changed since then. But you’ll notice that they’re not shaming, and they don’t sound like they’re coming from a Fortune 500 company. They’re very much personable, and they’re like, “Hey, this happens to everyone sometimes. No problem. All you have to do is…I mean it’s just like talking like a person. I think I sign it as a co-founder of DRIP.
We do that a few times, and like I said, they go into cancellation. They can come back after any length of time, frankly, and reactivate the account. They just have to enter their credit card and make that payment. So thanks for the question, Tom. That was a good one, I’m glad we’re able to discuss it today.
Our next question is from Glenn at archived.io. It’s about cold calling, and he says, “Hey Rob and Mike. I’m in the very early stages of business development. I was wondering if for your B to B businesses, in the early stages, did you do much, or any, cold calling, or possibly cold emailing.” Then he addressed something to you, Mike. He says, “How did you go about finding the prospects to interview while you were doing customer development with Audit Shark.”
Mike [16:00]: So back when I was doing sales level, what I found was as I was trying to do cold calling it generally didn’t work very well for me. What I ended up running into was the fact that, in much larger size accounts, what tends to happen is that those types of accounts have enterprise sales reps who are talking to them from Dell, and HSI, and Tiger Direct, and HP, and places like that, and they’re all basically in the door. So, unless you’re talking to those people, and you’re getting introductions from those people, it can be very difficult to get anyone’s attention.
That tends to be more at the manager, or director of IT, level. I wasn’t trying to get in at the lower level people, like the end engineers or things like that. Although I did try to do that as well. I never had much success with it, but it could be just a matter of either the calling scripts that we were using, or the types of people that we were calling, and the leads that we ended up dredging up. It honestly just didn’t end up working very well for me. I do know that there are people out there who are making it work, and they’re doing extremely well with it, but they’re also in, I would say, different businesses where their products are not necessarily aimed at the IT department. So I can’t really speak outside of the IT department, because I haven’t done anything with larger companies outside of that area.
Rob [17:20]: I have not done cold calling in the early stages of a product – frankly in any stages of a product. I did used to do some cold emailing outreach, but it’s very, very specific, when I was consulting and contracting. I would email designers and other folks, to try to get work, and that actually worked pretty well. I mean, if you really hone it, and I wouldn’t email a hundred or 200 people. I would email like 10 in our local area and I would say, “Hey, here’s what I am. I can be your outsource developer, blah-blah-blah.” I had a pretty well-written email that got me some leads. I think cold email like that can actually work reasonably well. The other option is something that’s pretty popular these days, with the publication of Predictable Revenue – which is a book by one of the guys who helped grow Salesforce – is this cold outbound email to these large lists. So you can use a service like LeadFuze, or LeadGenius, and they will put together a lead list based on your criteria, and they will email them. If you don’t have the budget for it, you can totally Google this and people will show you how to do it. It’s not that hard, it’s just a lot of manual, grinding work, because you can’s mass email this lists. That’s spam, but if you send each email individually using a tool like Tout or Yesware – there are a lot of tools in that space – and you customize the email reasonably well, you can actually get some traction here and get some demos if you have a decent value proposition.
So I wouldn’t say that cold calling is dead, or doesn’t work, or anything like that, but I don’t think it’s a good use of your time, necessarily, early on, unless you really are trying to access a market where a cold email isn’t going to work. Maybe if you’re selling to realtors, or you’re selling to someone who is by the phone all the time and is going to pick up, I think that might have some legs. I think that may be the best way to get a hold of them, because in general, realtors tend not to respond to emails. If you’re marketing to designers or online marketers or software developers, or something, cold calling is probably not going to be a good way to do it, and you either got to do it through cold email, or frankly, just getting some semi-warm introductions. I think before I’d start doing cold stuff, I would think about running ads to a landing page and getting some prospects there. You get 10, 20, 30 emails and you don’t then have to go outreach. You can just basically say, “Hey, you’re interested in this. Let’s talk more about it.” That’s an interesting idea.
Another one is to think about going to your network before you try to do cold outreach that’s so time intensive, and trying to figure out if you know people who can recommend others who might be interested in this. So I think there’s two ways to think about this cold outreach. It’s like in the early stages of your company, when you’re just doing customer development and you’re just trying to figure out what to build, it’s not going to scale. But yeah, I think that maybe you should consider doing it if that’s really what you need to do and you can’t figure out a way using ads or using the network to get around it.
Then in the later stages, once the company’s growing and you’re looking to scale, I think that cold emailing has, kind of, been proven to be an effective medium. For the time being, anyways, everyone’s getting into it, and when everyone gets into these marketing approaches, they tend to stop working. I’m getting so many cold emails now that I’m already seeing the effectiveness of them drop. So I think, like infographics and like – what was it five years before that – certain things come into vogue, and then they go out of vogue. I think that cold emailing will be around, but I think it’s effect in this – especially with the technorati, who are getting all these same emails from everybody – I think the effectiveness of it is going down and will continue to do over time.
Mike [20:50]: One thing that you mentioned in there that I want to expand on was the idea of asking for introductions to people. I found that that works extremely well, especially if you find one person who is interested in what you have to offer and is interested in talking to you. So even if you don’t have a product yet, and you have one person in your network that you can talk to, you can ask them for an introduction and say, “Hey, are there three people that you can think of that you can introduce me to that might have this particular problem?” If they can’t get you one right away, I think that there’s a couple of videos from [?] talking about exactly this thing, where even if they say no right away, just say “Okay, just give me one. I just want one,” because that one person can lead to three others who are not in your personal network. And after a while, when all of those roads start pointing back to the same people, then that method has probably been saturated to some extent, because when I was going through this for Bluetick, I was asking that exact same question of people. What I found was that there’s one person who’s several people in a row would start recommending me back to him, and I’m like, “Okay, well, this network of people is probably, at least, a little bit saturated.” Obviously, I didn’t go through every single list of everyone that I had access to, but I got to a point where it was obvious that a lot of people were pointing back to the same people.
Rob [21:53]: Good question, Glenn. Thanks for sending it in. Our next question is a voice mail from Rudy, and he’s asking about starting two product ideas at once.
Rudy [22:01]: Hey there, guys. This is Rudy. I own [?] I have a quick question. I’ve been [?] for a little bit of a short while now, and I ran into a problem and some people then came up with a product idea for the solution to that problem. As guys that are involved with multiple ventures, and kind of dabble in different projects. What’s your advice on trying to manage maybe starting two product ideas at once, or trying to build something that would both solve your present need with a different existing business, as well as solve other users’ needs in different niches. Thanks.
Mike [22:41]: I think the technical term for this is Objectivius Shinium Syndromus, which is Shiny Object Syndrome.
Rob [22:47]: Yeah, the scientific name.
Mike [22:49]: There’s a scientific name for this.
Rob [22:50]: Episode 170 of this podcast, 12 Strategies for Avoiding Shiny Objects Syndrome. That’s exactly what I was thinking too.
Mike [22:55]: Yeah, it just seems to me like, yes, it’s a problem that you kind of need to be solved, but if you’re looking at it as something else that you can build, it’s very easy to get distracted from what you’re currently working on. It’s also very easy to let your attention, kind of, drift off to those other things.
Now, if your current business is kind of stalling out, and it’s not because you’re getting distracted, then maybe it’s worth looking at that as kind of the next area that you’re going to go at, but it seems to me like trying to build something like that and making it into a full-blown product is probably not a good use of your time.
One of the things that come to mind is Rob with DRIP. Very early on in the stages of building DRIP, what you had wanted to do was you wanted to be able to collect email addresses on the HitTail website. So you built this little widget that you could install onto the site to help collect email addresses and send them into an email campaign. That eventually turned into what is now DRIP, but you didn’t let that distract you too much from building on HitTail. You still buckled down and got everything on HitTail that you needed to do, and you didn’t turn that into a product until you had made the conscious decision that, “Hey, I’ve taken HitTail really as far as I want to go right now, and I want to go do something else, because everything is fine here and I just want to build a different product.”
So it seems to be like this may very well be one of those situations where if you build something, make it something for you, make it something you use internally, and if it gets you to where you need to go with your current products, awesome. But I would not spend any time and effort to build it out into like a full-fledged product for other people, because that involves a whole world of other problems that you’re going to need to dig into.
Rob [24:42]: Yup, that would be my advice as well. I think that it’s easy to see something and think of it as going to be more fun or easier than what you’re working on now. If you are ready to completely abandon what you’re doing now, then I’d say consider this. Because in essence, your summary of the HitTail to DRIP transition is mostly accurate. Basically, Derek was contracting for me at the time and he built that little widget. I was at the point where HitTail was already – we were not starting out. It was already generating somewhere between $20,000 to $30,000 a month, every month, as a SaaS app. Given the return and a bunch of other factors, I saw that it was topping out. I could have pushed it further by really digging in and building a bunch more features and doing a whole revamp, but I started evaluating the landscape, the SEO space, the [not provided]?. “There’s just a bunch of things, factors that are coming into play, and you know what? I think I’m kind of ready to move on. I think I’ve accomplished a lot here, and I’ve learned a lot.” And I was ready to move on to another business. I did keep HitTail running on the side. It declined over time, slowly, but it was able to fund the next project, which is now bigger.
Even that, trying to manage two things at once- trying to grow one and manage another – was a challenge. I would be very, very hesitant – not just hesitant, I would never start two projects at once. Don’t try to grow two things at once. That’s my unequivocal advice, is not do that. Owning two things at once is doable, if you get someone to manage one. As long as you’re not trying to grow both of them at once, because it’s the growth that really takes the founder and the creative thought, and it takes some mental energy. If you split that between two things, neither of them is going to go very far. If you’re thinking about building this other product, I would abandon the first one. That’s a decision that you have to make at this point.
All right, last question for the day is another voice mail. It’s about how to manage a project from conception to completion.
Bran [26:25]: Hey, what’s up guys? Big fan of the show. This is Bran from successfuldj.com. What my question is is about project management. I was listening to a little bit of the startup documentary, Rob. I just want to say that was awesome. Thank you for putting that out. But I’m curious about how you guys do project management. I was hoping you could do an episode where you walk us through how you go from, let’s say, the concept of DRIP to the creation of DRIP. I know you did that in the documentary, but if you could take maybe a smaller project and concept, and just give us some ideas in terms of software you use – [?], Trell, to do it, whatever it is, and some mistakes you made in the past with project management, and how you just keep everything streamlined and efficient in terms of breaking things down into small pieces, and what to put on the “to do” list, et cetera, et cetera. Keep up the good work, guys. I’m loving the show as always. Talk to you later.
Rob [27:20]: To clarify, he mentioned the Startup Documentary. That is the documentary that Derek and I recorded. It’s an audio documentary, as we were building DRIP, over the course of 9 months. That’s at startupstoriespodcast.com if you haven’t heard that before.
Mike, the reason I wanted to talk about this in this episode, instead of doing an entire episode around it, is I actually think it’s a lot simpler than most people think. I think he asked for mistakes that we made, and the mistake that I made in the past is putting too much process, or going too heavyweight. Seeing someone break out Microsoft Project to manage a three- or four-month software project. I have a couple of tools that I use pretty loosely, with some light process around it in order to manage features or even entire DRIP process. But I’m curious to hear, before that, what you use. Because right now, you’re in the middle of building Bluetick. What kind of tools and process you have set up?
Mike [28:13]: Sure. I think there’s two different aspects to this question that, kind of, came to mind when he was talking about it. The first one is what tools do you use, and how do you basically manage the flow of data back and forth between them. Then the second piece of it is, how do you decide what to do, and when? I think that those are related things, but the tools do not necessarily dictate what you’re doing and what order. They can, especially if you were to use Project, or anything like that, where you can put up cascades between one task and the next.
For what I’m doing now, I use probably three different tools pretty extensively. The first one is FogBugz, which is where all of the development tasks go. So anything that is related to code, or back end or front end application changes, all of that stuff goes in FogBugz. Everythig that’s basically product development oriented goes in there. I manage all of that code, and all the various sprints, and what we’re working on, all of that goes in there.
For all of the marketing stuff, I have a teamwork.com account, and I actually have two different projects that have been there. One for the engineering team, which I did not expect them to use, and they have not used at all yet. So it’s there if they need it, if they need to share files or whatever, but we also have kind of a Dropbox on the back end that everybody has access to the same sharer. So if they really needed to share larger files, they could, and it’s all connected to my account, so it counts against my storage space. Then I also have inside of Teamwork, I have a specific project set aside for just all of my marketing tasks.
Now the other thing that I use pretty extensively is a Goggle Doc, where I put together a marketing plan for Bluetick. What I did is – I actually have been working on that for the past couple of weeks. I sat down and I decided what my goals are, how am I going to get there, what the product is, how do I describe it to people, what are some of the descriptions and potential headlines that I used, what are the concerns that people have about the product, why would they use it? I have stuff in there about pricing, and all these other things that go into the marketing document. But most of them are really just notes. They are things for me to look at and review, and think about how I want to address that problem, or some of the different ideas or thoughts that I have about that particular piece of it.
Then what I do is I take those things and then I translate them into my Teamwork account and say, “These are definitive things that need to be checked off as something to do.” For example, in my marketing plan I might have the idea of hiring writers. Then I have like a bunch of different job boards, or places where I might find writers. Then I take that over into my Teamwork account and I write it down and I say, “Okay, if I’m going to through, and I’m going to do a content marketing campaign, these are the places that I can go and evaluate a writer. But, one of my tasks is going to be to go each of these things, do a little bit of research, find a writer, and then hire them.” Then it then leads into the other tasks. The document itself is really just for me to kind of basically spew out all of my different thoughts on a particular topic, because Teamwork is much more for lists of tasks, and being able to iterate through those. There is like a notebook section, but because it’s not really tied over to the tasks section it’s a little bit more difficult for me to use it in that way. So those are the tools that I use in terms of process. I kind of start from that marketing plan document and decide what needs to be done, and then it goes over into Teamwork. Again, all of the software development stuff gets managed directly through that other side of things inside of FogBugz.
Rob [31:44]: For me, when I’m first starting a project out, I don’t use any type of issue tracking. I go into basically a Google spreadsheet, or an Excel — it used to be an Excel spreadsheet — and sit down with a developer, or if I’m building it myself…I forgot what are the top objects. Typically if it’s a web app, I look at web pages. If it’s a mobile app, I would look at screens. If it’s a desktop app, I’d look at screens or forms, I guess you’d call them. Then I’d try to throw some time in there for database development, and some project management, and database design, and that kind of stuff. Then go right to the screens and say, “How long it’s going to take to build each of these?” And throw estimates at everything in a big Excel spreadsheet, or Google spreadsheet these days. Then start working and deduct those as I go so I know where the project is. So it’s basically an entire project tracking mechanism just within the spreadsheet.
There are some more exotic stuff you can do that I’ve talked about in the podcast before, but you basically can say how many hours a day you’re working on it, and then you can set a date, using – there’s a workday function – where it just automatically tells you when you’re going to deliver this, based on how many days a week you work. So If you don’t work a few days, it just continues to push the date out. You can physically see at the bottom of that Excel spreadsheet continually getting pushed out. It’s pretty motivating when you see that.
The reason I do that, instead of stuffing everything into an issue tracker, like a FogBugz or Github Issues, or Codetree, is because early on you might have 50 things that all have to get done, and you’re kind of just hammering through them. I don’t want to have to update 50 issues independently. I’m just trying to aggregate everything, because you really are coding this in a block, right? And this is maybe a three- to six-month project, and if it’s one or two developers just sharing that doc with someone working with them like me basically driving the project, this is I found to be a lot more efficient than having every individual task in a tracker.
Once we start getting towards the end and it becomes more of a punch list thing, we were actually looking at maybe 10 or 12 individual tasks left in order to get to a certain milestone, and then you really do need to start measuring stuff, that’s when I switch over to more an issue tracker and enter them individually. Of course, at Drip we use Codetree, which is built over GitHub issues essentially. It’s like a nice sprinkling layer on top of that that helps your prioritize and do other stuff.
That’s really it. I’ve never been a fan of the heavyweight project management tools. I think, if you are managing 10 developers, or you’re on a big enterprise team where you have a lot of communication, you do need it. You know, you’re a big company. But for small startups, the gift that we have, or the advantage that we have, is that we move quickly. I’ve found that a lot of the PM tools that I’ve seen tend to weigh you down a bit more. Now with that said, I still have not tried Teamwork. I have an account that we got for MicroComf Europe, and I do want to try it, because I’ve heard so many good things about it, and I know that Peter and his team have certainly built something good there. So I’m tempted to do that, perhaps for a future project. So I think that would be the one othercaveat I would lend to it.
Mike [35:05]: Yeah, I think that in terms of the development side of things, I think that it’s more a matter of personal preference than anything else. There’s no right or wrong answer, it’s what works for you. What I was running into was that for the development team that I’ve got working with me on Bluetick, I wanted them to basically handle everything. Because of that, when I took all the different UI mockups that I’ve run through people who have placed preorders, I took a PDF of those mockups, sent them off to the development team and said, “Look, this is what you’re going to be responsible for building, and I want you to give me a time estimate of how long it’s going to take you to build each of these screens.” From those, they were able to break those down into individual tasks inside of FogBugz, and apply an estimate to those and say, “Okay, to put the screen together is going to take me, let’s say, two hours or three hours or whatever. And then to wire it up is going to take another hour. And to do unit testing. or whatever, it’s going to take another hour on top of that, whatever those numbers happen to be.
What that did for me is it allowed me to go from there and then look at the total report and make sure that none of their task estimates were more than four hours. If they were, I could go back to them and say, “Hey, you need to break this down a little bit further, because we need to be sure that this is probably more accurate than not.” Then using that information, I was able to go back in and, kind of, look at a report and say, “Where on the timeline is getting all of this stuff done going to fall? Is it going to be closer to four weeks, is it going to be closer to eight weeks?” Just having all of those hours added up was really helpful. The point is really what those hours add up to; how you do it, whether it’s in FogBugz or in a spreadsheet, it is almost immaterial. It’s more a matter a matter of personal preference than anything else.
Rob [36:17]: I think that’s a good point. It’s like, don’t get hung up on the tools. Seth Godin will often not talk about the tools he uses to write, because he doesn’t want everyone to try to use the tools he uses to write, because that’s not what makes him Seth Godin. I would say the same thing with project management. You can ask for advice, you can get a suggestion, try out a couple of different approaches. Obviously Mike and I have very different approaches. Try out both of them, and just pick one. Don’t go looking for the tool that’s going to make your project succeed, because it’s not the tool that’s going to do it. It’s you and your developers and your team that’s going to do it. You can even use some pretty shoddy tools and get some good work done. It’s happened in my career, where we’ve been forced to use things that don’t work that well, and you can still produce good product. Other times you can use the best tool available and you can turn up crap. It’s really much more you and you’re team in terms of actually getting things done on time.
Mike [37:00]: I think that about wraps us up for today. If you have a question for us, call it into our voice mail number, 1 888 801 9690, or you can email it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from ‘We’re Out of Control’ by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for startups in business, and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.
Scott
I’m not sure if this is still accurate. I just came across this Stripe blog post last month. As Mike mentioned I always thought when a card expired or was replaced all subscriptions on it would fail billing.
It appears though Stripe ‘solved’ this problem as of January 2015 and are able to automatically update card details for credit cards where accounts are still open/active.
https://stripe.com/blog/smarter-saved-cards
Matt Goldman
Thanks for the mention Rob and Mike!
@Scott: That’s not entirely true. Stripe’s “Card Updater” is awesome, and is really good at updating cards before they *expire* (I believe it catches around 70% of those), but there are many more reasons, both temporary and permanent, that a card may fail.
Even with Stripe’s Card Updater now enabled for all accounts, we are seeing 10-15% of all payments failing per month for B2B customers, and even higher for B2C customers.
You should definitely have something in place to recover those customers, or you’re churn is going to be outrageous. In many cases, we’ve seen this involuntary churn (due to billing issues) make up 50% of a company’s entire churn. And companies using Churn Buster are seeing recovery rates in the 50-70% range. So you’re leaving a lot on the table by not taking action. Stripe’s retries aren’t enough.
So to sum it up, Card Updater is great for reducing failures due to card expirations, but there are many other ways a card can fail like: hitting a spending limit, prepaid debit card going over the limit, temporary fraud shutdown, and switching from a Visa card to an Amex Card (in which there is no way for Stripe to know what to update).
– Matt
CEO, Churn Buster
P.S. Our Founder, Andrew, wrote in a bit more detail about this on Quora a while back: http://qr.ae/ROfZyz