Episode 206 | Drip, AuditShark, Enterprise Sales and Podcasts

Startups For the Rest of Us

Episode 206 | Drip, AuditShark, Enterprise Sales and Podcasts

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 /

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

• Facebook
• LinkedIn
• Twitter
• Email

Show Notes

• Drip
• HitTail
• AuditShark
• Zapier
• New Relic
• How to Build a Rocketship podcast
• Bootstapped Web podcast
• Big Snow Tiny Conf
• The Linchpin podcast
• The History of Rome
• Hardcore History
• Daily Tech News Show with Tom Merritt

Transcript

[00:00] Rob: In this episode of “Startups for the Rest of Us,” Mike and I update you on Drip, AuditShark and other things that have been on our mind. This is “Startups for the Rest of Us,” episode 206.

[00:09] Music

[00:17] Rob: 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:29] Rob: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. So, what’s the word this week, sir?

[00:31] Mike: Well, I’ve been actively firing myself from virtually every job I have. [Laugh]

[00:34] Rob: That’s a good way to do it.

[00:36] Mike: Well, I’ve been bringing on a couple of developers, and I brought on somebody to kind of do, like, DevOps stuff for me. And I handed of the build server stuff to him. I had somebody reach out to me on Twitter, asking me some questions about it probably a month or two ago. And he actually offered to do some stuff with me, but I’ve already got somebody who could do that kind of stuff. The question was, “Would you be willing to pay for it?” And it’s like, “Well, yes, I would; but I also have somebody in-house who can do that kind of stuff.”

[01:02] Rob: Right.

[01:03] Mike: So, I handed it off to him. And he’s done a good job with it. He set up the build server. He did a bunch in conversions. He’s upgrading the software. The admin password on our server expired. It’s like, “Okay. Well, that’s something we should clearly probably be doing ourselves”; because, you know, it’s kind of a best practice for security purposes anyway. So, he wrote up a process on how to do it and then changed the password and, you know, we’re setting up a system so that it’ll start reminding us to go in and change those passwords on a regular basis. And it’s nice to be able to have those people on your team that kind of understand that the processes are really what help drive the business and create value behind the company.

[01:39] Rob: Right, right. And if you’re listening to this and you don’t know what “DevOps” means, it’s essentially keeping your developers productive, and it’s often doing stuff like performance testing and maybe performance tuning. It’s helping with keeping the servers running and patched and all that type of infrastructure stuff. It’s stuff that, if you’re not a developer, you typically think developers do; but, frankly, developers should be creating things and building and writing new code; and they shouldn’t be worried about the underlying plumbing. And so when you hit any type of scale, even if you get maybe two or three developers cranking pretty hard, one of them needs to be a part-time DevOps person. Or, you need to find one; because enough stuff starts to crop up with scaling and performance and all that, that somebody typically needs to take care of it.

[02:21] Mike: When I was on my personal retreat last month, one of the conclusions that I came to was that, as kind of the founder of the business, my job isn’t necessarily to do any specific thing – other than to identify the things that are most important and figure out how to do them and put a process in place so that I can essentially backfill it when I’m done figuring it out.

[02:40] Rob: Exactly.

[02:41] Mike: And that’s kind of what I’ve been focusing a lot of my efforts on over the past month or so, and so far it’s been working out really well. So, I hired a couple of new developers. I’ve got somebody whose sole job is to make updates to the website. I’ve got two people whose sole job is to work on AuditShark, and I’ve got one guy whose sole job at the moment is to basically just do the DevOps stuff. And then my sole job at the moment is just to do sales and marketing, and I’m trying to figure out how to fire myself from that as well at some point in the future – or, at least put processes in place for certain pieces of it. So, for example, like scheduling webinars and setting things up and then delivering the webinars. Once I’ve got the process down for how to do that and how to make it effective, then I can document the process, hand it off to somebody and do everything else –

[03:25] Rob: Exactly.

[03:25] Mike: – and move on to the next problem.

[03:27] Rob: Exactly. The key thing you said there is until it’s effective, because anything before that is premature optimization – right – and you’re trying to create a process around something that doesn’t work yet. I always plan when I’m doing things that I need to get it to effectiveness. And if it never gets to effectiveness, then I scrap it. But once you get to effectiveness, then you’re right. You have to find someone else to do that because, as the founder, your time is more valuable.

[03:46]I am almost wrapped up with a two-hour audio documentary of the process of building and launching Drip, and it was essentially culled from nine hours of audio. It was the conversations that Derrick and I had over the course of about nine months. And every week, essentially we recorded a podcast; and some episodes are, like, eight minutes; and some were up to 30 minutes. So, it’s a total of nine hours. Trying to get it to around two hours, and it really tells the story from just after inception until we launched last November. It was a trip to hear all the things that are really boring about it. Like, if I released the whole nine hours, there are just entire things we talk about that are really important at the time, but are completely boring to listen to. And then, frankly, it’s agonizing to listen to some parts; and those are the best parts. Those are the most interesting parts, where we hit these huge roadblocks, and you hear myself or Derrick just talking about how hard it is and how much of a struggle it is and how bad we’re feeling about it.

[04:44] Mike: If there was no conflict, then there’d be no story. [Laughs]

[04:47] Rob: Right, right.  But the victories are also pretty cool, too – you know, getting through the struggles and then finally getting people in. And you can feel the excitement in our voices, and you can just feel the momentum build over time. And so it’s cool. It’s nice because it’s longitudinal – right? It’s, like, nine months; and it just flips. You know, five minutes, and then there’s a little musical interlude. And then – boom – we’re week later. And so you can instantly hear. You can binge-watch it. You know, it’s more like watching “House of Cards” rather than watching a season of “Breaking Bad,” where you have to sit there and wait for the next episode to come out. So, hopefully, I’ll have that out sometime in early November.

[05:21] Mike: Cool. Well, I started on a new section of the website that I’m kind of designing how I want it to go, but it’s essentially going to be a series of videos demonstrating how to use AuditShark to solve a variety of different IT-related problems. It was contacted by somebody who had had an employee quit. That employee was in the IT department, and they said, “Well, we need to know where this person had access to stuff.” You know, somebody leaves the organization, and you need to know what sorts of access rights they had on different machines around the company. So, at that point, it almost takes a security review to say, “Okay. Well,” you know, “where did they have access?” What sorts of sensitive information were they privy to? Do they still have access to that?” because that’s a really big one. Just disabling somebody’s account and active directory is not the cure-all that some people think it is. You know, there may be a VPN account that’s disconnected from that, and you might not know about it. Or, there’s local accounts on different machines that you can then use to escalate privileges, and there’s all kinds of different ways around it. But unless you have the ability to go out and look at your network and pull this information in, then you don’t know really what to do.

[06:25]So, the point is that I’m going to put together a series of videos on how to use AuditShark to solve a variety of security issues in the IT department. There’s a couple different reasons for that. One is kind of educational material so that people can understand how to use the product. So, if they come to the website, [and] they see this section of videos, they can take a look at them and see not only how the product works, but what types of problems it can solve. And then the second piece is that, if I’m able to do it right, then I could also leverage those pages for SEO; because the videos are going to show up a little bit higher in Google for ranking for different key terms. So, I’m going to try to experiment with those and try to figure out how to put that out there and achieve both of those goals at the same time.

[07:06] Rob: Right. Very nice. Yeah, you do need a video site map in order for Google to detect those. I like the idea.

[07:12]With Drip, I have the same thing at kb.getdrip.com, our knowledge base. And it’s just a simple knowledge base, and I have a section called “Rule Blueprints,” and it’s basically blueprints for different ways that people are using Drip. So, one is SaaS, registration and onboarding without trial. And you could, like, a four-minute walk-through of how I have all that set up and then send educational emails based on in-app? actions – right? And there’s a short video to show how someone could do that. So, it’s the same type of stuff. You’re trying to get scenarios into people’s head of how you can actually attack those and accomplish them with your app.

[07:49] Mike: They’re not interested in buying your app. They’re interested in buying a solution to a problem. And if you lay out those problems, that’s what they’re interested in. If you can map those problems on your website to the problems that they’re having and clearly demonstrate that you’re able to solve them in a way that’s acceptable to them, [that] builds trust; but it also builds confidence in your abilities to deliver something that’s going to solve their problem.

[08:10] Rob: Right. And you know what I want? For these videos to be able to be turned into almost a step-by-step thing with a few screen shots. And I would definitely pay money for that, because I have a bunch of screen casts in the kb that are really good, but I’m already starting to get requests – and I knew that I would. People want a full, text version of it, because they’re at the airport; or, they’re on a modem, or whatever, and they can’t get access to the video. Or, they don’t want to watch the video, or whatever. The thing is recording a video is five times faster than actually typing out a to-do and putting the screen shots and all that stuff in. I’ve timed it as I’ve checked it. And so for now, I’m more focused on improving the product than improving the docs. But if someone could save me the time, and I can put out screencasts and then have them magically turn into a well-written – not just a transcript, but a well-written, step-by-step thing, that’s worth some money to me, for sure.

[09:02] Mike: Well, funny you should mention that, but if you go to cascadecontent.com, you will find exactly that.

[09:08] Rob: Wow. Look at this! Drip is on the move. It feels good to get to this point, but it’s finally growing. It’s starting to grow at the rate that I want it to be. And, you know, if you remember my MicroConf talk from a couple years ago, I talked about building early on. There’s building, there’s learning and then scaling. And the building part is only minorly agonizing, because you’re impatient and want to get to where you can scale. The learning part is terrible, because the whole time, everything’s up in the air. You’re trying to figure out, “What are we building?” “Why are building this?” “Should we build this feature?” Who are we building it for?” “Who are our customers?” and every criticism that comes through, you’re really sensitive to; because you just don’t have a lot of feedback yet on your app, and you’re trying to get to scaling. And then once you start to scale up and you start the growth and you figure out some repeatable stuff and you’ve actually build some features people want – that’s really when things start to get fun, in my opinion.

[10:00]It’s a bit of a false dichotomy, because it’s not like, “Oh, we’re not learning anymore.” We’re definitely still learning and still adding features quickly, but we’ve built something that enough people want now that there’s been a noticeable drop in churn. It’s actually the lowest churn that I’ve ever had on any of my apps. And with growth picking up at the same time, it’s just noticeable. You know, it’s really time for me – I’ve started scaling up marketing, but the more people that I can get even to the home page, or just get interested in Drip, the faster the growth will happen. It’s got a bit of a vanity metric, because you can measure different months; but over the past 13 months, it’s averaged 19 percent growth month over month. But early on, like 11 to 12 months ago, the revenue was so small, that that number is kind of – you know, it’s like a triple-digit growth that month. So, if you go back six months, I think it’s like – I don’t know – 17 percent. So, that’s a little more realistic.

[10:50]So, it really is getting to a place where things are starting to pick up, and it finally feels good. It’s like things are paying off.

[10:57] Mike: Yeah, I think one of the reasons you find that your churn is so low is it’s difficult to move off of Drip. It would be a huge amount of work to take all of your marketing stuff out of Drip and put it into some other marketing platform. It’s a huge barrier to leave.

[11:13] Rob: It’s not actually that big, if you think about it. In fact, we make it as easy to leave as MailChimp or Aweber does, you know? It’s the same type of thing. You just need to copy and paste some emails and export subscribers.

[11:24] Mike: Sure, but mentally it’s a huge roadblock.

[11:25] Rob: Yes, that’s right. That’s right. It is. There was one customer who wanted to leave, and we helped him move his stuff over. It’s not an issue. But we have definitely helped more – several dozen people, frankly, move over from other services.

[11:37]The churn rate being low is a combination because, depending on your business, typically, your first 60 days, maybe 90 days of churn is pretty high if you ask for a credit card up front; because some people will stick around just because they don’t want to cancel and they kind of think they’re going to use it. And then once people are onboarded and they’re using it actively, then that’s your real churn rate. That’s what I consider your actual churn rate. But before that, you might have a 30 percent churn rate in your first 60 days, and then you might have a 3 percent churn rate per month after that. So, when I say that I’ve had the lowest churn rate I’ve ever had, I actually mean both – that initial 60-day period and ongoing after that. So, I think it’s a combination of getting more people onboarded and getting value out of the app. And I think that goes to all the time we spent on our onboarding process. I also think it’s that people are getting a lot of value out of the app.

[12:29] Mike: You know, part of that’s going to be the types of customers that you’re targeting, because obviously you don’t want to target customers who are not going to be a good fit, which means that they would leave earlier than they might otherwise. So, it’s kind of like people are investing in the platform because they think that it’s going to work out and help their marketing efforts. And if the churn rate is low, then clearly that is probably the case.

[12:51]Well, I’ve started using Zapier a lot more for automating various tasks, and if you’re not familiar with Zapier, it’s essentially a service that you can subscribe to that will leverage the APIs and the hooks between different applications. So, there’s [sic] things for Basecamp and Gmail. And I think there’re some things in there for Drip as well –

[13:08] Rob: Yeah.

[13:09] Mike: – but Google Docs. I mean they have a laundry list of – I think it’s over 100 different applications that they hook into, and you can send data back and forth between them using these things called “Zaps.” I’ve started using it to essentially start doing things that are I’ll say more tedious than anything else. So, for example, my bookkeeper – there was a bill that was actually missed the other day. I happened to catch it in time, but it was only because I happened to be logged into American Express at the time, so I made the payment. It wasn’t a big deal. What I did was I went in and set up a Zap so that on the 15th of the month, it would just go in and create tasks automatically so that when she’s done with each of them, she just checks them off. So, that way, one of them doesn’t get missed.

[13:49]So, I’ve started using that for weekly and monthly tasks that people need to be doing and then using it to kind of move data back and forth to help with automation of various things that a lot of times they’ll just get done when I get to them as opposed to just having them happen on a scheduled basis.

[14:09] Rob: Yeah, that’s a nice way to go. Anytime you can take advantage of that, automation’s a big win. I’m a big fan of Zapier, and you know what I found out? I talked to Wade, who’s the founder, and he said they pronounce it as “Zap-ear.” I think they have more than 250 apps now integrated, and you’re right. Drip is one of them, and it’s crazy that stuff that you can do without writing any code if you know how to utilize Zapier. The documentation page for Drip, actually – you know, we have our REST API, our Java Script API. We have API wrappers, and then one of them is Zero Code API. And I say use Zapier to connect Drip to hundreds of web services without writing code and just link over to the Zap on there for Drip. But that was per their suggestion. I actually think it’s kind of a clever thing, because if you’re a non-developer and you want to tie into our API, Zapier really is the easiest way to do that.

[15:02]So, scaling issues – they’re tough. It seems like every two months, we run into something that takes one of us out of pocket for a couple days. But I ran a big import last week that choked things for a few hours and, frankly, it was painful. And Derrick went and rewrote some code, and then we upgraded the servers the next day, and now we have – I think we’re up to eight production servers, maybe nine, because we have a bunch of job servers in a database in the front end and all this stuff. But it’s the real-time analytics, the real-time reporting stuff that kills you. And we’ve had to scale up faster than I thought we would and, luckily, we’ve been preemptive about it. We’ve had very few issues – no issues in months that have really affected any customers, but it’s about every two to three months [that] we’re seeing something crop up where we notice things are slowing down, and we have to implement caching, and we have to add a server to this, and we have to rewrite and optimize this thing.

[15:51]And this is actually where that DevOps thing comes in. The reason I’m also thinking about it is I have a DBA who is someone who optimizes apps. And I mentioned him a couple episodes ago. He’s at rubytreesoftware.com. His name is Creston. He, I think, is going to be helping us by looking through; doing stuff that, frankly, my developers aren’t that interested in doing; and I’m not in doing it either – which is finding those performance issues and either making recommendations for how to fix them, or actually going in and refactoring code to make things faster; because to date, I’ve been throwing money a the problem – right – just throwing more processing power: bigger servers, more servers, scaling up and out. And at this point, I think we need to find that 5X win, and I only think that’s going to happen by actually getting in there and rubbing elbows with the code.

[16:38] Mike: I know what you mean about having people go in and do things that’ll help make it more scalable. I mentioned in the past that I brought on somebody whose sole job is to write unit tests. And over the past five weeks or so – four or five weeks – he’s added, like, 200 unit tests to the system. It’s been really nice to see all those tests go in. The fact that the vast majority of them are still passing – there’re certain ones that are not passing just because I don’t have the back-end infrastructure to actually run the tests properly. But the rest of them, he’s finding things that probably shouldn’t fail, or wouldn’t be an issue in the production code, but they probably need to be fixed. And it’s nice to see that there’s that reliability that is being baked directly into the product. And infrastructure really isn’t any different. I mean if you have a DevOps guy who can go in there and really take a look at that real-time analytics and say, “Oh, well, did you know that at 3:45 a.m. yesterday, there was a spike, and the spike lasted for five minutes? We need to figure out what that was.” If you’re not actively monitoring all that stuff, you can run into those bigger issues down the road.

[17:43] Rob: Yep, totally agree. I have become a big fan of New Relic. Finally installed it on our servers, and there’s both, like, a Ruby gem that goes in the app itself and can report on some stuff, and then you install it on the server. And the server stuff is amazing. I mean it just gives you – all the reporting that you would normally get by defaulting graphs and stuff from a Windows server, like with PerfMon; but it gives it to you for all the LINUX servers, and then it’ll alert you if things go over 90 percent CPU usage, or running out of disk space, or all this stuff. And with eight or nine servers now running, plus however many – I think we’re running three for HitTail – it’s enough that you just can’t manage that all on your own, you know? And so having the alerts, even though some of them are false alarms, is really helpful. And so there’s a pretty beefy free tier with New Relic. And if you’re on LINUX servers and you’re not using it, I would recommend that you give it a shot; because it gives us a lot of data that we’ve used to troubleshoot things and to see, like you said, spikes. There’re CPU spikes. There’s RAM spikes. There’s all types of stuff that we just weren’t picking up on before we had it installed.

[18:48] Mike: Yeah, I think it’s things like the RAM and CPU spikes that are not inherently visible to most people. I mean I have New Relic installed on my Windows server. It’s interesting the sheer amount of data that you can get out of it and the granularity that you can get out of it as well, just being able to drill in there and see all that information. And it can give you insights that you wouldn’t necessarily have otherwise without that monitoring software. I mean without it, you’re really blind. You have no idea what’s going on. And the only time you do know when something is wrong is if a customer calls and says, “Hey, I can’t get to my data,” or, “The site’s down.” Your default assumption or belief is that the application and server are up and running, and sometimes they’re not.

[19:26]So, hey, I think you mentioned a couple of weeks ago that you still maintain Inbox Zero on a regular basis?

[19:31] Rob: I do. Well, I come close to it most days, yes.

[19:34] Mike: I’ve been failing more and more regularly to come anywhere close to Inbox Zero.

[19:39] Rob: [Crosstalk] – right? What’s the cause of that?

[19:40] Mike: I think it’s because I’m neglecting my email. The fact of the matter is there’ll be email that’ll sit there, and I just haven’t really decided what to do with it. Or, it’s stuff that I know that I need to come back to later on, so I’m like, “Oh, I’ll put this on my task list”; but I don’t necessarily take it out of my inbox, because it’s something that I need to – like, I need the information in there, as opposed to just the high-level task, to go do it. Know what I mean?

[20:02] Rob: Right.Yeah, that’s a bummer. You know, the way that I’ve handled that is, if you go into that email and you hit “Forward” and then forward it to your Trello board, it’ll take the body of it and forward it into the Trello issue. And so then you have all the information. And even if for some reason it gets truncated, at least you have the subject line, and you can always go search for it in Gmail. So, that’s what I’ve done, because I can’t stand having clutter in my inbox if I’m trying to get to Inbox Zero.

[20:25] Mike: I just need to figure out how to get some of those things out of there. Some of them are just bugs [and/in?] cases from from Fogbugz that people have done, and I just need to go back and review it to make sure that everything is functioning the way that it’s supposed to. Or, I need to go do a code review, or something like that. And it’s like, “Oh, well, I need to know where that email is.” And I suppose I could probably say, “Okay. Well, here’s the case number,” or whatever and just link to it –

[20:45] Rob: Right.

[20:45] Mike: – but it just sits in my inbox to let me know that I have to do it.

[20:48] Rob: To be honest, that’s been one of the biggest for me, too – is exactly that. It’s Fogbugz issues that I need to QA, or I need to get back to someone on. Those are the ones that I struggle with the most, because if I get five or six of them, do I really want to create five or six new Trello things and then reorder everything? Or, do I just want to crank through them in one batch at some point in the future?

[21:04] Mike: Yeah, that’s exactly the same issue with me. It’s easier to just leave them in my inbox and then come back and deal with five or six of them, or ten of them at a time than it is to create the five, or six, or ten different things in Trello.

[21:15] Rob: So, I have a few favorite, new podcasts I wanted to mention. Some of them are in the tech space, but of the handful that I’ve really enjoyed over the past several months, the first is “How to Build a Rocket Ship.” And this is by MicroConf attendees Matt and Joelle. And then they have another guy who works with them, named Michael. It’s 20-minute interviews with startup founders, and it’s really well down. It’s nice that it’s short, and it’s nice that it tends to cover one topic, and you don’t hear the same stuff that you’ve heard from people like Hiten Shah or Ruben, or me, who’ve been on other podcasts. They pick a topic, and they dive into it. “How to Build a Rocket Ship” is one of my new faves. Have you been listening to it?

[21:52] Mike: I have, yeah. Actually, I heard your interview with them a couple of weeks ago. I heard Hiten Shah’s as well.

[21:57] Rob: Yeah, it’s good stuff. The next one I like is “Bootstrapped Web,” and this is Brian Casel. And he’s switched formats, and he now has a co-host named Jordan, and they’re talking about their businesses, and they’re giving tips. I mean it’s a similar format to “Startups for the Rest of Us,” where they give their own story, but they also share tips. And so far, I think it’s a big improvement over where they were at, and so I’ve been listening to that.

[22:18] Mike: Yeah. I haven’t listened to that one, but Brian is putting on a – it’s called “Big Snow, Tiny Conf” up in Vermont. And that’s in January. And I think last year they did it, and they only had – it was, like, five people. But it’s basically like a ski or snowboarding vacation for a couple of days, and you just go up there and talk about business. And in some ways, it’s kind of like a mini mastermind group, but it’s a very compressed schedule from, like, a Monday to a Thursday. And then they do attendee talks and stuff like that. But it’s limited to, I think, eight or ten. He also puts it on with another guy named Brad, who is also at MicroConf, but we can link that up in the show notes.

[22:55] Rob: A couple more that I’ve been listening to. One is “The Linchpin” podcast, and that’s from Damian Thompson over at linchpin.net. And he also changed format from interview to he and a co-host discussing stuff. And then the last two are pretty nerdy. One is called “The History of Rome.” It is really the history of Rome, and it’s a dude who’s obviously a Ph.D. It’s ten- to 15-minute episodes. It’s really cool. What I like about it [is] it’s just really palatable. You know? It’s a little bit like Dan Carlin’s “Hardcore History,” if you’re ever listened to that, except it’s super short. It’s, like, ten- to 12-minute episodes. There’s 176 of them, and it’s done. Like, he did the history of Rome. There’s no more to be done, so he ended it. I’m like maybe 60 episodes in, and at times it’s a bit dry because it’s the history of a civilization; but fascinating just to hear the rise and the impending fall of this – and to understand it at a deeper level than I ever have, because I never really cared about this stuff in the past. So, it’s [as] good as, or better than, any audio book I could get on the subject, I’m sure.

[23:51]And then my last one is “Daily Tech News Show.” It’s with Tom Merritt. I’ve been a fan of Tom Merritt for years. It’s my favorite daily tech news show, and it helps me keep up-to-date with stuff that’s going on. It doesn’t help me in my work at all, but it is that thing that helps relax me on my drive into work or on my drive home. So, I just wanted to mention those in case folks are looking for new listens.

[24:12] Mike: Well, I think the only other thing that I have is that I’ve been a lot of personalized and one-on-one discussions for AuditShark. And I found that those seemed like the best way to close sales. I think there’s [sic] a couple different reasons for that. One is you get somebody on the phone, and if they clearly know what they’re talking about and, you know, it’s easy to talk to them about the different problems that you’re having, and they can walk you through how they can solve those problems, then it’s easier to buy into what the solution is. And the other thing is that getting to the point where you’ve got that one-on-one discussion with somebody, you’re getting a lot more – the focus of their time. If you send them an email, they might look at it for, like, a minute or two. But if you have an hour-long discussion with somebody, you’re getting a lot of in-depth information not only to them, but from them. And that’s been kind of the basis for a lot of the changes that we’ve been making internally within the products to make it do different things. And it’s not necessarily somebody says, “Hey, could you do this?” It’s more like, “Well, I like the product, but these are the types of things that I’m doing,” and you have to read between the lines a little bit to figure out what it is that they’re actually trying to do versus what they’re telling you they want to do; because sometimes what they are doing and what is the right solution for them are not the same thing.

[25:21] Rob: Right. And often they will state a solution that is very limiting. They’ll request a feature that only they would ever use. But if you’re thinking from a higher-level perspective of “how could everyone use this?” you can often make it more configurable. Or, you can build a feature in a different way that’s more flexible and that can fix their issue, but also perhaps implement another feature that you’ve already had requested. So, there’s definitely an art to this, to trying to interpret what users are asking for and figuring out if you should build it and how to build it.

[25:51] Mike: Yeah. The other thing I’ve noticed is that the sales cycle for this is probably a lot longer than I’d like it to be. It’s several months long. So, I’d really like to try to start identifying ways to bring that down. I feel like part of it’s features, and as much as I hate to say that – but in some cases, there really are. There’s [sic] certain things that people have said, “Yeah, this is great, but we really need it to do this in order to move forward.”

[26:13]The other thing that I’ve found is that people need customization, which is a kind of interesting piece of it; because in some cases, that can just be services. So, doing services engagement where, if they buy the software and they buy these services to go with it, we’ll build a bunch of stuff for them in the policies itself; because it’s different than writing code for the products; because the policies are more applicable to their environment, but the product is built to have these policies, that you create them and then plug them in through the engine, and then it pulls back the information that you’re requesting. So, that’s more of a customization piece, but it’s custom for their environment. And it’s been an interesting to position that as sort of an upsell opportunity as well.

[26:51] Rob: Yeah, I was going to say that. I mean I think that could be a great way, especially early on, to make a good chunk of money and try to fund it – maybe not something that’s scalable, but maybe it is. I mean you’ve heard the term “consultingware,” which is where you have the big, $300,000 enterprise product. And then you sell – or, maybe it’s a $100,000 enterprise product, and then you sell $900,000 of consulting services on it, you know, to make it this seven-figure deal. And while you don’t have to get ridiculous like that, starting off with a $5,000 product, you know, with $10,000 or $15,000 of customization is an interesting way to increase the initial sticker price there.

[27:25]The thing you said about sales cycles being long – that’s not surprising to me, because it’s enterprise sales. Right? I mean you’re essentially selling into companies that are going to be moving slow. So, two to three months doesn’t even feel that long to me.

[27:36] Mike: Yeah, most of it’s about just kind of getting their attention and getting on their schedule, because they have to get it on their schedule and say, “Okay. Well, why should I even pay attention to you?” because these tend to be the upper-level people that I’m talking to in companies, and I’ve found that a lot of the companies that I’m talking to are under 500 employees. I just need to find ways to reduce that time period, because if I can’t reduce that time period, then it’s hard to scale up revenue without just stuffing the funnel with tons of people and running around like a chicken with my head cut off, trying to follow up on everybody.

[28:07] Rob: Well, that’s what I was going to say. I think that’s what most enterprise sales people do is they stuff the funnel and run around like a chicken with no head. I don’t know how you’re going to reduce that sales cycle. I mean those companies are just slower movers than we are. And I would think it’d be more like six months if it’s truly an enterprise that has to get budget approval and get their IT department to prioritize it and that kind of stuff.

[28:28] Mike: The enterprise ones I would expect no less than six or eight months; but, like, that’s why I’m trying to target a lot more of the smaller companies, because they tend to have smaller budgets, for sure; but they also have a lower number of resources. So, any tool that you can bring into the environment which allows them to automate some of the things that they’re doing and make it less tedious or expensive for them to do it in terms of resources and time – that’s kind of a no-brainer for them. So, those are the places where I’m seeing a lot of traction and a lot of success. They take one look at it, and if they have a need for it, it’s a no-brainer. They know exactly what they want, what they’re looking for; and they kind of have an idea of what the next steps are, but even in those cases, a lot of what I find is they’re just so busy doing their existing work, that they don’t have a lot of time to dedicate to actually doing the evaluation. They love the idea. They like it, and they want to move forward; but finding time for them to actually commit to looking at and moving forward – that’s where the challenge is. I can certainly schedule webinars and things like that and go over things with people one on one, but that doesn’t necessarily free up their time commitments for all the other IT-related stuff that they’re doing.

[29:36] Rob: Right, yeah. And that’s a struggle of one-on-one sales – right – of enterprise sales. And that’s what the good salesmen that I’ve known – I mean like Steli I’m sure if you talked to him about it, he would have a number of thoughts about how to get around that. Actually, Damian Thompson, from linchpin.net, he’s a very good sales guy. And he – we should have him on the show at some point to talk about this, because I think what you’re asking is a common question. And having never done a lot of enterprise one-on-one sales, I don’t necessarily have the answers; but I do know that these are the ways that good salespeople are different. It’s funny, because we can identify good developers, and I know a good developer, and I know the difference between a good developer and a bad developer. It’s harder with salespeople aside from bottom line. “Well, how much did they sell?” But I think there’s some subtle things, and they kind of get this intuitive sense of how to do exactly what you’re saying. Like, they find ways to get past those roadblocks, and there’s a certain amount of natural ability in doing that; but I also think that there’s definitely a lot that can be taught.

[30:33] Mike: If you have a question or a comment for us, you can call it in to our voicemail number at 1.888.801.9690. Or, 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. Subscribe to us on iTunes by searching for “startups,” and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening, and we’ll see you next time.