Episode 136 | AuditShark, Drip, and HitTail Updates

Show Notes


[00:00] Rob: In this episode of Startups for the Rest of Us, Mike and I are going to be talking about AuditShark, Drip and HitTail. This is Startups for the Rest of Us episode 136.

[00:09] Music

[00:17]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.

[00:25] Mike: And I’m Mike.

[00:26] Rob: And we’re here to share our experiences to help people avoid the same mistakes we’ve made. What’s the good word this week, Mike?

[00:31] Mike: I’m sweating in Texas.

[00:33] Rob: And it’s swampy.

[00:35] Mike: Swampy is a good way to put it.

[00:37] Rob: Well we’re going to be talking today on the show. It’s going to be an update show where we talk a lot about projects we’ve been working on recently, progress we made or lack thereof in some cases. We got a comment on last week’s episode, episode 135 where we answered several listeners’ questions. And Ray piped in. He put a comment on the blog.

[00:55] And he said the question about the 19-year-old who doesn’t have any programming experience. I think I’d be tempted to suggest that he try and complete some of the free online courses that are all the rage at the moment. They are available I think for HTML, CSS, Ruby on Rails for example. It might be a quick way to build some basic skills quickly.

[01:12] It would be difficult to pick a technology stack if you have no experience. I would do that first then look at some freelancing job. With no skills I think even finding the right freelance jobs and getting them would be almost impossible. I thought we said that. Did we skip that step? Because that’s the first thing we should have said is first learn something and then go to oDesk and try to get contracts.

[01:31] Mike: Part of the comment also kind of includes that idea that he doesn’t know the technology stack, so he doesn’t necessarily know where to start. And we kind of give some ideas about where to start, which was go to the Ruby on Rails route or PHP or something along those lines just to get your feet wet in a way that’s not going to overwhelm you.

[0 1:51] Rob: Thanks for the clarification there, Ray. The other thing we got was an email from Matt Vanderpool and he attended MicroConf last month. The subject line of his email is heartfelt thank you for putting on MicroConf. And he says, hey Rob and Mike. I wanted to extend a heartfelt thank you to both of you for organizing MicroConf.

[02:10] I also wanted to tell you a little about what MicroConf has done for QAtab. Matt has an app called QAtab that’s at QAtab.com and it helps company improve their QA process. He says in the four months before MicroConf I did nothing with QAtab. I was too busy and didn’t have the time to work on it. In one month since MicroConf, I have reduced my consulting time so that I could work on QAtab.

[02:32] Added support for integrating with external ticketing systems based on information from Tom Fakes who I met at MicroConf. Set up a weekly meeting for product accountability with Najaf Ali who I met at MicroConf. Identified and reviewed competitors to help me determine what makes QAtab different. And then he list five or six other things all dealing with either dealing with information he got from MicroConf or people he met at MicroConf.

[02:54] He says I don’t know if I would ever make this progress without it. The talks were great and the networking was even better. Almost everyone who I explained the QAtab concept to immediately got it and that was very helpful. I think it was this kind of feedback that I was missing and that I really needed to keep going. Again thank you.

[03:11] So, we want to extend obviously a thank you to Matt for writing such a detailed email. Yeah, really just for letting us know the difference it makes and that’s frankly why we’re starting to do two of them. Certainly if it works out and it continues to make this kind of difference for people it’s kind of a no brainer.

[03:27] Mike: Yeah. We’ll have to take into account those people who are trying to get us to do three or four a year but we’ll see what happens.

[03:34] Rob: I saw an Asia request and an Australia, New Zealand request come through. We’re going to need some staff to help with those.

[03:40] Music

[03:43] Rob: So Mike, we haven’t heard much about details of AuditShark. What’s going on with that probably for a couple of months?

[03:51] Mike: So for people who haven’t heard much of what I’ve been working on AuditShark is a product designed for auditing web servers. Basically your infrastructure servers to make sure that you’re following best practices for security. Cause there are literally thousands and thousands of ways to configure a server. But not all of them are necessarily the right way or good way that isn’t going to end up in your server getting hacked.

[04:13] So, AuditShark is designed to check all this different pieces of information on your servers to make sure that the server is configured correctly out of the box, you know when you first start configuring it. And then to continually make sure that it’s still configured the right way in case those baseline recommendations change or if the server changes itself.

[04:30] For example, somebody actually does get into your server and hacks into it, chances are good that they’re going to start making some changes to it. And those are the type of things that you want to be notified about. These are not things that you’re going to go back into the server and check on a daily. You’d rather have software that will do that.

[04:47] So that’s what AuditShark is designed to do. From a problem standpoint obviously it’s giving you some at least piece of mind that at somebody is going in and taking a look at these servers, making sure that it is set up correctly. Those are the type of things that people I’ve spoken to find fairly valuable about it.

[05:03] So, over the past few weeks, I’ve been making a very focus effort to kind of get the product more or less the feature complete where it is enough to put in front of somebody where they would actually get value out of it. So to help with that I hire a developer to start building some of these control points. I spent some time doing some training for them.

[05:20] Over the past couple of weeks, he’s put together roughly between 100 and 150 different security checks that are built in the product now and they’re all targeted at Windows 2008. That’s just more or less the starting point. Next up on the docket is going after sequel server 2008. And then after that, I’m going to start taking a look to figure out whether we want to do more Windows checks and go down the route of Windows 2012 and the sequel 2012.

[05:46] Or, if we want to start going more towards the Linux side of things with Linux, Linux-based apps such as Apache or MySQL. Or, if we go after more of a platform specific approach where we’re going to maybe say Ruby on Rails, Gems or things like that. But essentially in order to make those decisions, I have to do a little bit more customer development.

[06:06] Rob: And does that mean are you are able to ask them in advance and figure it out or do you have to go through the process of actually installing it on their server, getting them to use it and then making a decision.

[06:16] Mike: No, I can just talk to them. I can ask them the questions. I can look at my spreadsheet to figure out what the numbers are of the people who are interested in different things and just go after the largest pieces. Figure out who is, one, willing to pay the most for it, and then two, what the largest number of people who are willing to pay that amount.

[06:35] You know just do a little bit of multiplication, you can figure out what’s going to be the most profitable area to go after next; at least for my launch list and the people that I talked to so far. Obviously, if I start progressing and marketing a lot more then that could change dramatically very very quickly. But it’s at least a starting point to give me an idea.

[06:53] But the fact that he was able to put together roughly 50 control points a week indicates to me that over the course of the next month or two months, it wouldn’t be a stretch to have like another 250, 300, 400 control points build where these are all each individuals checks and security checks that are being done on somebody’s machine that would be reported on a daily basis.

[07:14] And I think that regardless of the system that you’re running, there’s going to be value in that. And that’s really what I was – I spent a lot of time and effort getting to the point where I know that the system actually provides that value because that is the value proposition. If it doesn’t deliver, it’s very difficult to justify charging for it.

[07:31] Rob: Right, that makes sense. And have you limited this to or do you know yet who’s going to get the most value out of it. Like is it SAS operator, is it downloadable software companies. Is there any group or demographic that it’s particularly resonated with?

[07:46] Mike: Not that I have differentiated it. I mean I can certainly make guesses about it. My suspicion is that any company that basis 95% to 99% of its revenue off of its web servers they would be a good candidate for it. Because they’re going to want to make sure that those servers don’t go down whether it’s because of bad configurations or hackers getting in.

[08:09] We talked a little bit about Rudy a couple of weeks ago where his backups were failing. And he didn’t know that that was going on. I could very well build a control point that checks and validates your backup for example. And if your backups are failing, let’s say I check the log files for backups or there are very specific things that I can look at, I can tell you whether your backups are failing.

[08:29] And then it’s not six months, nine months down the road when your entire server crashes and then suddenly you find that your backups were failing seven months ago and you’re completely toast. Then something like that would provide a lot of value. But it is for those types of people who have the vast majority of revenue of their revenue come in from those servers.

[08:48] Because they basically are mission critical. If you lose those servers, you lose your business. Now again that’s just hypothetical, theories. I can stay here and talk till I’m blue in the face and say, “Yeah, that’s sounds reasonable.” But until I go talk to customers and say is this why you’re buying this product, it’s hard to make those judgment calls.

[09:04] Rob: Right. Cause the answer you gave me was the problem that you solved. You talked about a problem someone has and how AuditShark can solve it. And that totally make sense. Problem solutions [feed] I think you’re going to find that. What I’m asking about is the next step, product market [feed]. It’s what market are you going to focus on first with your limited resources being a single founder. You can’t go after every one who has 90% of the revenue from their web server cause that’s a huge huge market, and you just can’t possibly market to them. So that’s what I was probing after is who is that demographic.

[09:37] Mike: It’s probably going to be SAS operators initially just because I’m kind of plugged into that network to some degree, so I understand kind of the pulse of the market a little bit. And I understand a lot about how web severs work. What the problems around running them are. What the remediation issues are. I can certainly offer a value of there in terms of not just my knowledge but in the products applicability to solving those situations. So, it seems to me like that’s a reasonable place to start. Whether I stay there or not, it depends a lot on how the market responds to what I’m offering.

[0:10:09] Rob: I like it. That’s a good answer. At least you have one that’s not broad cause that is definitely a market that you have reached into.

[10:17] Music

[10:18] Mike: You’d mentioned a while ago that you were working on a couple of information products and I know that one of the first things was the video course on hiring a VA. I think you’d done a bunch of stuff back in January where you had somebody come in and do a lot of videos of you. How is that coming along?

[10:35] Rob: It was ready to launch. I mean I had all the videos by January and I was hoping to launch it in January. And then HitTail had a big spike and a bunch of press. You know it was great stuff. HitTail grew very very fast early in the year, and it took my attention off of the video course basically. I have kind of a goal to launch three courses this year, just smaller things that really focus on particular pain point.

[11:00] And so I put the video, the VA video course on hold. But I’d been getting emails about it probably one or two a month from you know whoever, listeners, people who hear about it and asking if I’ve launched it yet or where I’m going to launch it. Cause I don’t have a landing page for this one. This is probably the first time I’ve ever done this. I just plan to send it to basically my email newsletter list.

[11:23] It’s softwarebyrob.com. I have a newsletter for that. I’m going to test that out in thinking that in the next – it’s going to probably be 7 to 14 days that I’m going to get it out. It’s all uploaded. I have transcripts. I have audio versions. I have course notes. There’re really just one or two final pieces. I have a job description that I use, already uploaded that I use to hire VA’s.

[11:44] And then there’s just a couple like I want to get a sample screencast and a sample Google doc that I share to showing how simple it actually is to train someone to do something. So I’m excited. It’s fun. I like sharing this kind of information and being able to justify going into such depth. You can’t do it on a podcast. You can’t really do it in a talk at a conference going deeper than I’ve gone probably since my book. You know that’s the last time I really dove into something with this much detail and being able to handover so many like accompanying resources.

[12:15] Mike: That was really cool. I’d be interested in seeing that. I know there are a lot of people who I reply to and there were several people I talked to at MicroConf who were asking me. They’re like you’re involved in a lot. You do a lot of different things. How do you get all this stuff done? And I’m like the magic of it is I don’t actually do most of it. So as you said it’s through VA’s and you get other people to basically work through your processes.

[12:38] Rob: Yeah. That’s right. With HitTail, it’s kind of been a trip. One of my main marketing channels just stopped working very abruptly. It’s an algorithmic thing. Its paid acquisition that I’d been doing for about eight or nine months. And I stopped it for MicroConf because I was too busy. And when I came back and re-uped it just like ads aren’t appearing even with the same bids.

[13:00] It’s been kind of a shocker. It’s not the majority of growth but it has been the longest term and most stable, and it is a big chunk of the monthly growth that’s been happening over the past probably eight to nine months. And so the nice part is that it’s a SAS app. And SAS is beautiful because the money keeps coming in. It may not gross substantially this month.

[13:25] It’s been growing between 10% and 30% a month for 15 months. And the growth this month will be single digit at best. But it’s SAS. Like the revenue still comes in. It’s not like with the single download software product that I’ve had were when growth stops it really drops down substantially and you lose 50% or 80% of your revenue in a month.

[13:45] Mike: That’s nice to hear. As long as you’ve got that growth coming in, I think the thing that would concern me and obviously I’m not, you know, seeing all your numbers and everything. But if I were in that position what would concern me is the fact that if you lose like a major growth engine, does that mean that in another month or two because that growth engine is lost, now as you start to shed people who came in through that engine, are you going to start going in the other direction. Are you going to start to shrink because that growth is no longer being powered by that particular channel?

[14:17] Rob: Absolutely. If your churn is too high and you don’t have that large funnel of trials coming in, you will start to shrink. I’ve plotted it all out cause it’s been going on for about six weeks now. And it’s funny. I’m like working with an ad provider and all this stuff and they don’t really know how their system works. It’s like this black box algorithm.

[14:35] And there’s no flags on my account. There’s nothing. They’re like we don’t know why it’s not running. I mean it’s bizarre. So I’m doing all types of crazy testing like running the same ad but pointing it to just a completely different website like pointing it to my blog to see if the ad shows up. You’re right. If you lose a major growth engine and your churn is too high then of course a SAS app will shrink over time.

[14:57] This is obviously a concern. It’s not something – I don’t want to play it off and say since it’s SAS I’m immune to X, Y and Z cause it certainly not the case at all. And this is a major major issue on my play right now which is a bit of a bummer because I had all these processes in place that essentially are ensuring the growth, the continued growth of it daily even though I’m not focusing on it.

[15:17] And when something like this happens this is where I’ve had to pull away from what I was working on which was Drip. And I had to pull away from it and come back and so now I’m getting less done on the new project. That’s just a balancing act. When processes failed and you have to step back I think it’s the part that I don’t enjoy about having a lot of spinning plates is when one that I started spinning a long time ago that’s been going well for a long suddenly starts to wobble and I have to take my attention off of the new ones.

[15:45] Mike: Yeah. That’s always hard. That’s also one of the reason you don’t automate everything upfront because if that automation fails for whatever reasons, it’s going to take a long time to begin with, but then if that automation fails then it’s going to take you exponentially more time to figure out how to go back and fix everything especially, depending on what it is if it’s complicated or somebody changes your API or changes their webpage and your parsing it. It could just be really difficult. But, yeah, when those processes breakdown sometimes there’s just nothing you can do. You have to back and take a look at it.

[16:15] Rob: Right. So let’s bounce back to some of the things on your list. What else is new?

[16:20] Mike: Last week I was trying to get a customer installed. And basically run into a couple of things because I wanted to get some of the control points that I talked about that I was having the new developer worked on out into the system and test it. So we were making a lot of changes all at once. And I don’t know whether it was directly related to something that we did or whether it’s just the sheer number of control points that were added to the system that basically results were not coming back anymore. So I just basically found this out over the past day or two because the policies that I put in place to go out and audit my test machines, they’re just not sending the results back anymore. They used to. They were doing it fine every single day and now it’s a black hole.

[17:01] Rob: That’s not good.

[17:02] Mike: I think that I’ve got enough log in code in place to figure it out. It’s just that I haven’t had the time to sit down on the servers and figure out exactly what’s going on. I mean it may very well be something as simple as a configuration change in a config file some place on the server. But it could be something that’s a lot more complicated than that.

[17:21] And I know that this whole mechanism for passing that data back has got to change at some point. I think it was Gabriel Weinberg had written an article talking about scalability and how it can usually see the next order of magnitude of growth, but two orders of magnitude things are going to be so completely then it’s very difficult to figure out what’s going on or what it’s going to look like.

[17:42] And I think that it’s kind of at stage right now where you know before I was always passing back a handful of control points where it was less than ten. And at this point, I’m sending back pretty close to a 150. So, it really is a full order of magnitude higher than it was before. I don’t know what the problem is. It could be something simple.

[18:02] It may require some radical changes. I’m hoping its not radical changes. But again, it’s a problem where I’ve got to deal with it and I’ve got to deal with now. Because obviously I don’t want to start putting a lot more customers into this and then having them log in and have them not be able to do anything at all because the system just doesn’t work anymore.

[18:20] Rob: Right. That’s a pretty major one to find early on. This is exactly why we roll out to one customer at a time and test things. I mean it is a beta test in this case. But it’s also it’s also I guess one of the other big benefits that we talked about a lot is you’re learning what features your customers needs. And they push the limits of these things, right. Cause you just wouldn’t likely test with that many control points.

[18:41] Mike: Oh no, I would. I could easily foresee somebody running 500 or a 1000 or even 1500 or 2000 control points against a single machine because you’re not going to want to do those manually. Cause even if it took you like 5 seconds to check each one of them. I could easily see somebody doing that in a production environment. And this is only a 100 to 150. So, it’s got to get fixed. It absolutely has to get fixed.

[19:05] Rob: Very good. So basically the month since MicroConf has not treated me well at all. I just know after a month, just about out from under the email load that had piled up. Then the HitTail growth is stalled and now Drip…

[19:18] Mike: Is this tales from the dark side?

[19:20] Rob: It is man. It’s just one of those bad months. I was down like last week and the week before, I was really bummed about these things and they were impacted me. I was really shocked by it and surprise and everything. And I’m just kind of like dealing with it now. I’m realizing I’ll figure out a solution eventually. And the same thing with Drip.

[19:37] So with Drip probably three and a half to four weeks ago, we started with our customer no. 1. Cause HitTail has been using Drip for a while and it works and Drip is sending email and everything works great. We try to get customer no. 1 on the system and right away it was like you don’t have this feature that I absolutely need. So we implemented it.

[19:56] Then there were a couple more that he needed then we implemented them. As we went down the line, it just turned out his use case was way too complicated. He had so many landing pages and list and the interactive and he had custom segments and he had API calls. Not that stuff is that bad, but at this point in Drip’s lifecycle, it’s just not there. We can’t build all that.

[20:16] We could spend another month building it for him. And maybe it’s 1 out of 50 or 1 out of 100 potential customers has all the problem he did. So the cool part is that he is able to switch, since he’s a founder as well, he was able to switch pretty quickly from customer to kind of adviser. And we had a long hang out with myself and Derek who’s coding it and customer no.1.

[20:39] And he’s basically like you know you really got to think I don’t know if I would build all these features yet. And so that’s what we decided to do. We basically pull the plug on just on getting customer no. 1 on the app. And so we’ve had to switch up the plan a little bit and take evasive action and I have 16 other early access customers.

[20:57] And so now I’m choosing one who has a pretty simple use case and we started talking. And I would love to get him on board like today. But as this is going on, Derek and I started talking and he realized this just during the conversation that we have to do some refactoring of the data model that it was… Yup, you know how painful that’s going to be.

[21:17] Mike: Yup.

[21:18] Rob: So it felt like a one two punch man. Basically Derek, he’s like do you have time to chat. And I’m like this is not good. We never chat unless something is wrong you know. We started talking and it was basically a 90-minute Skype chat of me trying to figure out how we could avoid doing this. It’s about eight working days. Once we get data in the system and we have users on it, it would be one of those changes where it would literally take three to six man months to fix down the line if we have to migrate everybody.

[21:47] So it was that kind of thing where its like this gets us 80% of the way there but it’s going to be catastrophic if we ever had to add one additional variation of this or one additional piece of flexibility. We just saw quickly how that architecture had max itself out. So we’re several days into that. I think probably 3-4 days from now that would be done.

[22:08] And then we’ll be circling back and getting our next customer no. 1 on. But the good news I realized is that feature we built for our first customer no. 1 we are going to need. We’re going to need for ourselves or for this next customer no. 1. So we didn’t lose time per se. We didn’t waste time.

[22:29] Mike: Yeah. I think the one thing that you’ve mentioned that’s really important for some people to think about is that you may have your heart set on signing on this customer no.1 But understand and realize that it may not work out with that customer. They may have use cases or needs that are going to be so far above and beyond what the rest of your customers are going to want or need that it’s actually not worth building it for them.

[22:52] Because you’re going to end up doing all this customizations that are never going to be used by anybody else or going to be very difficult or going to be so time consuming that it’s going to set you so far back from launching that at the end of days it’s not going to be profitable. Or, you’re going to lose motivation or you’re just going to have the money to be able to make ends meet to roll it out to everybody.

[23:09] So being able to walk away from that customer no. 1 and say, “Look we just can’t help you right now. We maybe able to do it at some point in the future. But now is just not the right time.” In some cases, that’s the right decision to make. It’s not an easy decision to make. But sometimes it’s the right one.

[23:24] Rob: That’s what I was going to say. It was not an easy decision at all. It was not clear cut. At a certain point, it just starts feeling institutively wrong like you were doing so much work. And I kept asking myself the question how many other users of my first hundred are going to need what we’re building here. And that answer was like none or one.

[23:45] It was just such a small percentage that I know we can get quite a few people using and paying for the app without these features. And again it’s a judgment call. Someone else may have made a different one. But the thing that struck me was no matter how many emails and how many times I discussed it with customer no. 1 and tried to thoroughly understand his use case, there were still these little things that creep up once he tried to implement.

[24:07] It just goes back to that recommendation of get people actually using your app cause expect things to come up that you haven’t accounted for. I don’t know if I honestly believe you can account for things until they really start touching the code.

[24:21] Mike: There’s always the difference between like you know you can explain an idea to somebody else. And until you’ve explained it to them three or four times and actually showed them what you’re talking about, it is so hard to convey some of that stuff. I mean that’s part of why when we’re talking about outsourcing code to developers, that’s why it makes the screen mockup so incredibly important.

[24:41] Because it allows you to show them quickly what you’re talking about. Versus having them read a spec that they’re only going to skim anyway and they’re not going really understand it even if you’re talking to it right in there ear. So hey, I’ve got some of my own tales from the dark side. I’m letting go one of my developers. I had to get on to him a number of times over the past several months.

[24:59] And it’s really just not working out. I mean the relationship just kind of limp along for about six months. And I feel like I’ve tolerated it because I felt like I didn’t necessarily have a choice and I didn’t want to put the time and effort in to finding somebody else. But I’ve decided to just kill the relationship and focus more on people who are actually working out.

[25:16] Rob: That’s a bummer. I’m sorry to hear that. You have a couple of domestic developers, is that right?

[25:21] Mike: Yeah.

[25:22] Rob: Here in the US.

[25:23] Mike: He’s not one of them.

[25:24] Rob: Oh, he’s not. Okay.

[25:26] Mike: No. No.

[25:27] Rob: Well that’s bummer. I mean you have other help. Are they able to step up and make up for him or are you going to have to go on a search for someone?

[25:33] Mike: The lead developer who I have working on the policy builder and then the other developer I have who is using the policy builders, that’s really where a lot of the problems are. And we’ve had these discussions internally where we’re looking and all of the problems with the policy builder with the synchronization, and none of it is really major but collectively it tends to be a pain.

[25:55] So we’re actually looking at that stuff in trying to figure out what is the future of this going to look like. What are we going to do in the future? How is it going to work? We’ve talked about some different architecture consideration. It almost seems like the original thought that I’ve had a long time is to take the policy builder and put it in the web, so you didn’t have to have this additional downloadable component.

[26:12] And it looks like that’s probably the direction that we’re going to go. For now, we’re going to leave things the way that they are just because it would be an incredible waste of time and effort to back off and put things on hold and go back and rebuild it in the web. So, we’re just going to leave things the way they are. We’re going to basically work through the issue as we best as we can.

[26:32] The developer who’s building a lot of the control points had a lot of good feedback for me in terms of what the policy builders needs. But a lot of those suggestions are directly applicable to taking it and making it web base as well. She’s like in jQuery or something along those lines.

[26:47] I think that that that’s ultimately the direction we’ll go. And if that’s the case then this developer was working on that policy builder. So, if I basically halt the development there and put it in maintenance mode, it doesn’t necessarily matter that I’ve kind of lost him.

[27:01] Rob: That’s funny. I haven’t realized that the policy builder wasn’t web base yet. I can see the headaches of trying to build it on the web instead of as a desktop app. But I agree with you. I think it’s  no brainer long term cause then you don’t have to support people downloading it and installing and running into all those issues that are hard to troubleshoot as opposed to you having kind of a SAS thing that you can maintain and fix right on the fly.

[27:24] Mike: Yeah. I mean the other thing with the policy builder is that there’s going to be people out there who have Mac. I mean there’s going to be a lot of people who have Mac and its Windows only right now. So moving it into the web it solves a lot of those problems. The other thing that it does is it allows us to avoid any database synchronization problems.

[27:42] You don’t have to have a sequel server on the client to run it. There’re some things along licensing that I can probably get away with a couple of components that I won’t need anymore. The major issue that it kind of brings in is how to test things. So once you’ve built a policy or control point, how do you test it?

[27:59] And for something like that I think that we’re going to move more towards an always connected model where if you push task down to a machine, because it’s going to maintain a constant connection out to AuditShark and the Cloud then it will always be able to contact it. Will you be able to do it through the UI, which will be pretty neat if we can get it working?

[28:17] And I don’t see any reason why we can’t. It’s just a matter of wiring all that stuff up and that’s a nontrivial amount of work. So that’s kind of the reason for putting things kind of in a maintenance mode for that while in parallel we walk down the road of building this other stuff.

[28:31] Rob: Absolutely. At this point man, I mean we’re both kind of in the same boat, right. We’re approaching launch on something. And I find myself everyday saying that’s a great feature. I’m entering in FogBugs  and putting it in at priority 6 or 7. Like a great feature. We’re going to build it in six months. That’s typically the timeframe. You know I’ll say we’re building for 2.0.

[28:49] There’re some awesome features. I can think of a hundred of features I would want in an email marketing tool. But we can put them in a bug tracker and implement them later. Cause right now we just to go to implement the shortest path to providing actual monetizable value to people and that’s the same boat you’re in. Writing less code and doing more things to get you closer to launch frankly.

[29:13] Mike: Yeah. And the nice thing about that is if you can get to launch and it starts to gain traction then obviously you’re going to be gaining revenue from it. And you can bring more people on to build that version 2.0 kind of in parallel while you got version 1.0 in maintenance mode.

[29:28] Rob: So my last update for the day is also dealing with Drip. I have this really interesting experience last week. About two weeks we bailed on trying to get customer no. 1 on. And then we decided to re-factor. So we were in kind of just stand still mode, and I was looking at the future set and really asking myself what exactly are building and is this still in line with my original vision of Drip that I had way back.

[29:52] Is that still something people are willing to pay for? Does it provide value to a market? The answer was I think so but I don’t really know. And so I was trying to think how do I answer this better. How do I find out what people really want because I’ve had so many one off conversation whether it’s at MicroConf or whether it’s over Skype or whether it’s one on one via email.

[30:12] And when people say, “I’m really looking forward to Drip. I asked them, “What exactly do you think it does?” Because I haven’t spelled out what the features are and everybody has a different answer. Some people want behavioral email. Some people want workflow based email. You know there’re all these things that people want and I was trying to figure out how many of them each of these things.

[30:29] So realizing that the launch list. I have an email list of about 1400 people who’ve expressed interest in Drip. And they’ve come from all different sources from probably listeners of this podcast to people who heard about it at MicroConf to ads that I’ve run sending them through a landing page. And so I created a Google forum. I love Google forum. It’s like Wufoo but its super simple.

[30:53] You create this form. They have quite a few options. Nothing like Wufoo cause it’s free and everything goes into a Google doc spreadsheet when the info comes in. So, I created one of those. I send out a link. I’m trying to keep it as short as possible and I got a lot of responses. I got 22% response rate answer some really key questions.

[31:13] And some of them were directly in line with my hypothesis and other send me in a different direction frankly. But the most important thing is it really improves my mental state of like are we wondering here. Are we really building something people want and it totally confirmed that. Because an overwhelming number of people who responded and the percentage of people responded want exactly what we’ve already built to be honest.

[31:38] If we were refactoring right now based on what Drip is today and based on how I described it in this survey, we have a kind of critical mass in that group. But the key thing that we asked that I almost didn’t ask I added in last was question no. 1 was basically saying are you a and then there were choices. Are you a startup founder/software entrepreneur or are you an email marketer or a general marketer or other.

[32:04] And then there was a text box. So other wound up being like consultants and just kind of some random people. That was key because then all of the other responses I could segment in that Google spreadsheet and I could just order by one thing. And then I could look at how many startup founders said that particular thing and then how many email marketers said that particular thing.

[32:26] And that was a key insight that I’m glad I’ve done. So folks out there if you are going to send out a survey, try to get – you don’t want to ask five questions about who they are. You want to boil it down to one so that it doesn’t really clog up the survey.

[32:39] Mike: Yeah. That’s a good thing to ask. One of the things I’ve been doing is talking a look at the email addresses of the people who’ve been signing up for the AuditShark launch list. And using Rapportive you can basically backtrack their email address to see who they are, where they work at and what their title is at that company.

[32:55] And that’s extremely helpful for figuring out whether it’s more of a qualified lead than somebody who is just kind of idly interested. I mean if they sign up for AuditShark and they got like a Gmail account, chances are pretty good so far that I found that they’re not necessarily interested. It’s more because it’s a podcast listener or they’ve heard about it from a blog or something like.

[33:14] They’re kind of idly curious. Whereas I’ve gotten a lot of other emails that have come in and I’ve been able to backtrack it to companies for legitimate corporate email addresses and some of the titles are like operations, engineers or sys admin at such and such company. And it’s clear that they’re looking to solve a very specific problem. And you can reply to those people.

[33:36] You can go back to them either one on one with a survey like that with some very detailed and specific questions. By cross segmenting those types of people, you can send them different questions. So that you can essentially say okay sys admin are interested in these types of things.

[33:50]Let me drill in for the next sys admin who comes along let me send them a survey that kind of drills in to try and get more information about what a sys admin would look for as opposed to somebody who is just kind of curious or kind of drive by person.

[34:05] Rob: Yeah. That’s a really good point. I’m glad you mention that cause I’ve forgotten to mention that one of the choices after identifying who they were, I asked them what’s the no. 1 you think Drip is going to do. Like what are you most excited about. Give them a few choices and one of those choices was I’m just curious about Drip.

[34:20] And having that alone I think like 20% of the respondents said that and that was great. Because I was able to basically not listen to their opinion as much cause it’s not as important as a founder opinion who can actually use this today and really has a desire to use it.

[34:35] Mike: Yeah. And that’s definitely a differentiating factor between them. If you know what they do or what they are interested in, it helps you determine whether or not to ignore the things that they have to say. And it sounds a little callous, but at the time you have to as a startup founder you have to choose what advice you listen to. And you have to have some way of doing that. And that’s a good way of doing that.

[34:55] Rob: Right. I wouldn’t say ignore. I’d say prioritize. It just has to be prioritized lower than some of the other groups that I look at. There were a couple of other things I learned from the survey. I won’t go into too much detail but the one I already said so far which that is all the features that we have built so far including the ones for customer no. 1 are important to people. And that was a nice confirmation.

[35:16] Another one is that there were a lot of startup and software founders which I would have expected. You know confirmed it basically with data. And then another one was it was kind of the opposite side of the coin. There was an advanced feature which is like split testing, right. Splitting testing auto responder sequences against each other as well as subject lines. I mean really going in depth.

[35:38] It’s a very hard thing to build but it was on our docket and we pulled it off because our intuition was that people didn’t want anything that complicated. But it was the exact opposite. People are like this is a major feature that I want now like it was a big deal. So we’re turning around on that.

[35:54] And then another one was email workflow and trying to almost like infusion stuff. Not quite behavior but where you have really complex rules engines. I’ve heard from so many people that they wanted that. And so, I was entertaining the idea, wondering if we have to go down that path cause that’s not a fun thing to build. Frankly, we found that a smaller percentage wanted that than almost anything else.

[36:15] So, although, it’s a vocal group or  it’s a group of people that I’ve talked to a lot cause I’ve heard that suggestion a lot, it’s not something that we’re not going to build tomorrow. And so again, we’re not going to ignore that feature but it’s prioritized lower than some of these other things that we’re talking about.

[36:30] Mike: The feature for AB testing or split testing any of the email campaigns not just the content of them but like the headlines and stuff to drive people in, yeah that’s definitely a feature that you should be working on for a second. I totally agree with the people who responded in that survey.

[36:47] Rob: Yeah. It was a long thought process. I won’t go into it. That was originally one of the value props I had mentioned when I was pitching Drip to anybody was it could do that. Because I don’t know of any other system that allows you to split task sequences, its auto responder sequences.

[37:01] It’s always you cans split test individual campaigns, individual blast emails but not sequences. But I have fought through; I had a series of discussions and such. We’ve moved it off cause it’s a lot of work to build. But as you said a lot of folks are interested in it so we will be building it.

[37:16] Mike: Cool.

[37:17] Rob: Yeah. This really reminds me why having a launch list is so crucial. I’ve been doing one on one interview with people like I said we email and Skype. But it’s really hard to get like a higher level idea from that. You get specific request and it’s hard to know how many others have that same problem. What the survey data did combined with those interviews is it gives me a much higher confidence in the direction we’re taking.

[37:37] It makes me feel better about what we’re building and it makes me, I don’t know. Just have a better outlook on it. It makes me want to move fast and get things done. So it’s not like we don’t already tell people to have a landing page and a launch list but one more reason to have something like that in place.

[37:52] Mike: Maybe you should have one for the VA videos.

[37:54] Rob: Oh my god. We’ll see how that goes. It’s going to be such an I told you so. Everyone is going to point.

[38:01] Mike: I can see it as the twitter hash tag right now.

[38:04] Rob: Hash tag I told you so.

[38:06] Mike: No we’ll see how that goes.

[38:07] Music

[38:10] Mike: I was reworking some of the marketing stuff on the website right now as well. I reworked the sign up process a little bit to emphasize some of the things that I took away from MicroConf like the 60 day money back guarantee versus a free trial, giving people a little bit more information on the sign up, doing annual plans versus just a  monthly plan.

[38:30] Offering that to them upfront as opposed to basically offering it after they’ve already signed up. So I’m looking at doing those types of things. And the only other thing I have going on is about an hour after this podcast ends I’ll be doing our first mastermind group call this evening.

[38:45] Rob: Very nice. That’s a good move. Are you excited about it?

[38:49] Mike: Yeah. I am. I mean it’s just kind of exploratory at the moment. I mean we’ll do a couple and see how thing go. Maybe do one every other week the next every for the next six or eight weeks or something like that. And then I think everybody will kind of evaluate where things are at. Whether its meeting everyone’s needs or not or if we need to change anything. But I’m kind of excited and interested in seeing how things go but we arrange it at MicroConf, so another notch on the plus column for MicroConf.

[39:16] Rob: Yeah. Very cool. I’m looking forward to hearing how that goes and I’m sure listeners will be interested in updates in the future.

[39:22] Mike: Well if you have a question for us, you can call us into our voicemail number at 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt used under Creative Commons. You can subscribe to us on iTunes by searching for startups or via RSS at startupsfortherestofus.com where you’ll also find a full transcript of each episode. Thanks for listening. We’ll see you next time.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

8 Responses to “Episode 136 | AuditShark, Drip, and HitTail Updates”

  1. Hi Mike,

    re: Audit Shark

    You shouldn’t touch a Linux port until you have proven the product is working and working well for Windows.

    Concentrate on Windows, SQL Server and IIS.

    I’d even have a base product that tests for standard holes of all sub products – then have more advanced versions for each major component.
    So the standard package does 100 (for example) tests for the major holes for a reasonable price – the full tests would then do hundreds of tests for each major software component.
    I’m personally not a Windows fanboy – but Windows developers are used to paying for software so it would be the best place to start.
    Also I believe it may be easier to target Windows developers with a number of major dev websites/forums/publications.

    I’ve been a long time listener and recent commenter 😉 and like the idea of Audit Shark – I think as Rob has mentioned and as you have hinted at – I think you are searching for the niche that could see its usage skyrocket. It may be for some not so common 3rd party applications that dev’s have difficultly configuring – either way I think you should concentrate on the big 3 to start with, Windows Server/SQL Server/IIS.

    Good luck.

  2. I think you misunderstand. Linux is already working fine, as is Windows. It’s the policies that need to be built and they simply use the scripting engine that I wrote to perform their checks. It’s sort of like I wrote an OS, but there’s no applications to run, so it’s not terribly useful. The policies are where it’s at.

    I have a contractor working on these so the major effort on my part is talking to customers, not building out the policies.

    Windows 2008 is done. Windows 2012 is in the works. SQL will be next, unless it becomes too time consuming to implement some of these things due to missing functionality. In that case, it’s either IIS, or some Linux stuff.

    I agree that there are likely opportunities for limited numbers of audit checks. $X/month for 100 checks/day for a specific OS/platform. I’m not sure if there’s additional need or desire for advanced customizations. Maybe there is, maybe not. It’s quite possible that the SMB space wouldn’t care, while the enterprise space would require it.

    I also agree that the core three on Windows (OS, SQL, IIS) are going to be key moving forward. But that’s something I’m still trying to nail down for sure.

  3. You should have links to the startups you mention in these notes.

  4. @Sam – We do our best. If you hear any links we don’t have here feel free to post them into the comments (we very well may copy them into the main show notes as well).

  5. @Mike, Sorry, yes I did misunderstand. It does make sense to test the Linux market if there is minimal work.

    Another option maybe to try and partner with other vendors of large software applications. They might even be able to help with the policies for their own apps – you would probably need to get some little wins before you could convince other partners though.

  6. I agree. It has to have some credibility first.

  7. At 32:39, do you mean Rapportive rather than Reportive?

  8. Yes, Rapportive. That was an error in the transcription.