Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike answer a number of listener questions. The topics include marketing budget allocation, documentation for SaaS, and digital marketing.
Items mentioned in this episode:
Rob: In this episode of Startups For The Rest Of Us, Mike and I discuss allocating your marketing budget, minimum SaaS documentation, and we answer more listener questions. This is Startups For The Rest Of Us episode 380.
Welcome to Startups For the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you’ve built your first product or you’re just thinking about it. I’m Rob.
Mike: I’m Mike.
Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What is the word this week, sir?
Mike: Well, if I had a way to put an emoji in here, I’d put a sad face in because my new website is not live yet. I was expecting it to be done.
Rob: Yeah. It’s been a couple of weeks since we recorded last.
Mike: I handed the things off to a designer and he was working on it and then some stuff came up and he wasn’t able to finish it on the previously proposed schedule. Completely understandable stuff, completely out of his control, but I’m a little disappointed when things get pushed off a little bit. Still plugging forward and hoping that things will be pushed out and live within the next week or so anyway.
Rob: Got it. Next podcast episode I will give you a bunch of crap if it’s not live.
Mike: Yeah, sure. You can evaluate the design and I can tell you to go to hell.
Rob: “Hey, Mike. I would tweak these three things. Boy, that’s really an odd color,” and you’re like, “Dude, stop. It’s all done. I’m going with this.”
Mike: I like fluorescent orange.
Rob: Yeah, that’s funny.
Mike: I’m just kind of in a holding pattern right now waiting for that to get all squared away so that I can kind of launch some other marketing campaigns and see how things go.
Rob: That’s cool. It’ll be nice to get that. I’m excited to see it because we talked about it a couple of episodes ago. Your current site doesn’t do the product justice. I’m interested to see what it looks like. For me, I was in San Francisco last week at SaaStr. I will admit it, I liked it better this year than last year.
I’ve only been to two SaaStrs and my general appraisal is they’re way too damn big, way too big. They say that they’re 10,000 people there and it feels like more than that. I really think they should a, sell fewer tickets, and b, there’s this big emphasis on bring your whole team, so half of the people you talk to it’s like, “I run marketing for this startup. I am in support.”
Nothing against that but I don’t get a lot of value out of that. I wanna be with other founders or I wanna be, if it’s a marketing conference, I wanna be with people in marketing. But it’s this really broad swath of people. I find the lack of focus and the size to be detrimental to the conference. I think it would be better but I think the point there is different with MicroConf where it’s highly focused content, and we try to get the people together.
A lot of people were just there to network and business meetings. It wasn’t even hallway track conversation it was like, one guy I saw in the lobby, I’m trying to think. I think he recognized me or he recognized the Drip name of or the other. He said, “Yeah, a long time Drip user. I just lined up seven meeting a day. Here, I don’t go to any of this sessions.” There are people who came and did just that which I’m sure is fruitful but it’s an interesting way to view the conference. We had, I participated in about four or five meetings over the course of the three days myself.
Mike: I use to go do the Symantec and Altiris conferences out in Vegas and it was the same type of thing. There were people who would go solely so that they had easy access to people to line up meetings one after another. That was the only reason that they went. They didn’t go to any of the sessions or anything. They just go there to talk to people.
Rob: Yes. With that in mind, again, I went to somewhere between three and five meetings so I did miss a few sessions but with that in mind, my learning this year were that the panels, panels in general, not just at SaaStr, I’ve never seen a panel that’s any good. They’re always gonna be watered down and even if the topic is super intriguing, they’re just not well done.
That’s one of the reasons we don’t do panels at MicroConf. I think we’ve done one panel out of the 14 or 15 MicroConfs we’ve run. We set it up very specifically and we gave everybody a heads up and asked them to be super tactical but I just started avoiding the panels early on in the conference, the SaaStr conference. I was only going to the solo where it was one person, because I knew that they would have slides, and they would have thought through a premise, and be making a point, and having an opinion.
That’s what I really enjoyed about it where I saw several talks that were good. They were like, I’ll say, MicroConf quality with a high bar with a lot of – from experienced people like a former product leader at box.net, as an example. You know that she has a lot of experience and knows what she’s talking about.
Mike: Yeah, I’m with you. I’ve never really seen panels work out very well to the point that they’re interesting and you get any reasonable takeaways from them. I wonder if that has a lot to do with, I don’t think it’s just the format, but I also think that it’s a matter of trying to give everybody either equal opportunity to talk or I think another contributing factor is the issue of having questions that aren’t necessarily, I’ll say, as well prepared as a talk.
Because if somebody’s up on stage, they’ve given their talk generally a fair amount of thought behind it, have a story arc or something like that. There’s background, they can do lead ins to different pieces of the story but with a panel, you can’t do that at all. It’s very difficult to establish rapport and create some sort of an arc that people can follow.
Rob: It’s a good point. We’re touching on some things that could be fixed. I was talking to Jason Cohen, he was there, he did a talk and then he and I were hanging out, talking. We were having this exact conversation and he suggested, “You know what? If you instead made it a debate, it would be way more interesting.” It’s a panel but it’s essentially a debate and then I said, “Wow, but then don’t do three-person panels, just have two.”
Can you imagine Jason Cohen, Hiten Shah up on stage? “Alright, I want one of you to take the side of bootstrapping, one to take the side of raising funding, and then we’re gonna go through six topics.” We’re gonna say, “Alright, how does this impact hiring? Go.” And the two of them debate. Then, “How does this impact how fast you can grow? Go.” Just run through these topics. That, I was suddenly intrigued by.
Mike: Yeah, that is something interesting. As soon as you started mentioning that and saying that you’re gonna have two people like Hiten Shah and Jason Cohen up on stage and kind of debating something, I was like, “What happens when they agree on something?” Well, yeah, you have one of them take opposing sides, that makes more sense.
Rob: You have to set it up in advance to either that even if they don’t fully believe it, they just do it. Folks who are on the debating team or have done debate, you just have to do that. You sometimes have to debate something, you have to be on the side that you don’t agree with or you pick issues that you do know that they’re on the opposite sides of. You and I could debate things like…
Mike: Who’s gonna win an arm wrestling match?
Rob: Who’s gonna win an arm wrestling match, inbound and outbound email, because you’re outbound and I’m inb–anyway. Coming up with things off the cuff is not my strong – this is why I prepare talks.
Alright, we’re gonna answer some listener questions this week. First question is a voicemail. It’s about allocating your marketing budget. This question comes to us from our very own Craig Hewitt, the founder of PodcastMotor, and Seriously Simple Podcasting.
Mike: And Castos now.
Rob: And Castos now. “Hey, Rob and Mike. This is Craig Hewitt from the Rogue Startups podcast. I had a question for you guys today about how you would think about allocating marketing. Say you have $1000 month you wanna spend on marketing for a SaaS tool, how would you think about allocating that money for different things like content, or SEO, or paid acquisition, and let’s say that it’s a relatively young SaaS product that is, say, below a few thousand dollars a month at MRR. Interested to hear your thoughts on how you would approach this problem and if you have any specific answers that you think would be kind of best practices. As always, love the show, thanks for everything you guys do.”
Mike: I think this is an interesting question because the parameters of the problem here is that you have $1000 for the month and what marketing activities do you prioritize for your business or how do you go about evaluating them. I think, in some ways, the question is almost misphrased because not everything is going to have a dollar cost associated with it, especially if you’re bootstrapping and you’re early on, and you are able to do things yourself.
For example, if you’re doing SEO, there is not really a dollar cost associated with that. It’s actually more of your time than anything else versus if you’re doing paid advertising where clearly, there is a budget that you have to set aside, and you have to be able to do that or if you’re paying people to write articles, but at the same time, you can also write those articles yourself. It’s a question of resource allocation, not necessarily just dollars. There’s the time of yourself for doing it, and then there’s the money associated with those things, and then there’s the output of that. How much are you going to be able to reach people? How broad is your reach going to be after you spend the money and the time?
I think that that’s probably the most important thing to focus on is what is your reach going to be based on the resources you have spend. If you spend half your time for the month and you’re able to get 10x the reach, then if you were to spend $1000 or even $2000, then you’re going over your budget at that point, but you’re not gonna be able to get to as many people. I would look at it in terms of reach and then refine that over time because you’re probably not gonna get it right in the first month, you’re probably not even gonna get it right by the third or fourth month. You’ll be able to narrow it down and you’ll be able to start eliminating different options.
But I would probably focus on most three different things in any given month, and then at the end of every month evaluate them against one another to see how far of a reach did you get, and was it qualified. Did you reach the right people? Because if you’re not reaching the right people, and you’re not getting to a scale that you need, then it means that that channel or whatever it was that you were trying is basically worthless. It doesn’t do anything for you.
If you get in front of them and you are doing it at a rate that is, I’ll say reasonable, it’s gonna depend a lot on what your channel is because 1% in one channel could be, you should expect 50% in another. But as long as it’s reasonable, then I would essentially double down on that, and refine it, and optimize it.
But if you can’t get anywhere close to what is reasonable based on what objectively other people are telling you that they’re seeing in their industries, then I would switch to a different tactic and see if that one works out because it’s gonna be different for every type of business, every type of product.
Rob: Yeah, the way I would think about this is it’s actually an approach that I used to do. Well, I did it for HitTail and did it for Drip, and I saw Noah Kagan doing something similar but better. It’s basically take a Google spreadsheet or an Excel spreadsheet and write out all your marketing approaches, and then try to guesstimate how many trials you think or visitors you think you can drive from it.
You put the cost, estimated level of effort for hours whether that’s for you or someone on your team is doing it, and then you just try to sort them, you come up with a simple algorithm, just sort probably by impact unless there’s something that’s substantially more and more effort. You just want pure volume of trials, or new customers, or revenue, however you wanna measure that.
Early in the SaaS apps career, assuming you have product market fit where people are using it, paying for it, return is low, all you’re trying to do is find marketing approaches that work. You’re very likely, for small SaaS app, you’re gonna find one, maybe two. You’d love to have 10 but it’s gonna be one or two that’s gonna have the most impact over time. I like to think of them, there is short term, there is long term.
The short term ones are doing a joint venture mailing where you email your list – I’m gonna say podcast because we know that Craig runs Castos which is a podcast hosting and let’s just assume that that’s what he’s looking at. You’d find either a podcast blog or someone who does a podcast about podcasting, ask them to mention it, and you would also mention their podcast too to your audience or something like that. That’s a little bit of a quirky way to do it but you get the idea.
Maybe there’s another podcasting SaaS that helps with recording like ZenCastr or something and you do a JV with them where they email your people and you email yours. Then there’s just straight up affiliate stuff. That’s where you can approach people and just say, “Look, I’ll pay you 30% perpetual or 20% perpetual topline revenue from anybody you refer. Here’s your link.” See how many people will do that. There’d be podcast advertising.
The reason I keep coming back to podcast is because your audience’s podcast hosts are most likely to listen to other podcasts, and so you can just start buying spots on those podcasts that are talking to other content creators. There’s paid ads which these days I’m gonna say is Facebook. AdWords is gonna be very unlikely, it’s just gonna be too expensive for you to get to work although you could try it, outbound email. These are all the short term things.
When I say short term, they can work for a long time, but they can give you a short term boost. They’ll instantly, if you do a JV mailing, boom, you’ll get much customers that day, hopefully, you do. Then you have to do another one every month in order to make it work. Then there’s these longer kind of flywheel things, stuff like SEO, content marketing even, I’ll say, guest post is kind of in the middle there. Guest posts can get you a one-time shot but they also build up SEO overtime.
You may wanna do both but honestly, if I were in your shoes, and I were just getting started, I would go for a bunch of the short wins because when you’re doing, I don’t know Craig’s revenue, but I’m gonna try when Hittail was doing $1500 or $2000 a month, all I wanted to do was get it to $5000 or $10,000 a month. I didn’t care if it was unsustainable, or the marketing approaches completely didn’t scale at all.
As soon as I got to $5000 or $10,000, I had so many more options. I can hire better people, I can hire more people, I had huge budget than the market. I wasn’t constrained to the $1000. I didn’t have very high expenses so I had $5000 or $8000 a month to market this thing. Now things really open up for you. Then you can start doing multiple. “Alright, I’m gonna get a blog going with landing pages and blah, blah, blah.”
I have to admit, if I was marketing a podcast hosting service, I love the idea of – you know where all your customers are. They’re all in the iTunes store. It’s like the best deal ever, to be marketing to that audience. It’s not a huge audience but you know where they all are. You know that the business podcast and any kind of for profit podcast that takes advertising is making money.
There’s a lot of hobbyist podcasts talking about whatever, dungeons and dragons, movies, or whatever, that’s more like a B2C sale. You’re gonna want to stick to the more popular ones and you’re gonna want to stick to certain categories that common sense is gonna tell you, “These people have money and they’re gonna be willing to pay for it.” That would probably, to me, be the very first thing I do is either have VA scrape or write a scraper because you know all the iTunes pages are all on the web, in the browser.
Hopefully Craig hasn’t already come up with this. It’s like some secret sauce thing but I’m totally giving it away but I’m just coming off the top of my head and thinking how I would begin to approach it. Maybe I would test some paid advertising but probably not before I did outbound email, joint venture mailings, trying to get some affiliates to work with me, and even joint venture webinars are interesting, I don’t know if that one’s gonna work in this space but to basically latch onto someone else’s audiences and be like, “Hey, let’s either do a webinar to each other’s audiences,” or you say, “Hey, can I do it to your audience Mr. Podcaster? You fill the seats and I’ll give you cut of whatever the people buy.”
I realized that’s a long answer but that’s how I would think about it and with $1000 a month, I would, like I said, I would test things until something works because that’s something working buys you the luxury of being able to do multiple things at once. While I was testing, I would really stick to one thing at a time, and I would hustle, and I’d learn everything about it that I know. I’d read up on it and immerse myself in it for one to two weeks of just consuming content about it, and buying the Udemy course, and watching the MicroConf talk, and talking to XYZ expert about it, calling them up on clarity, paying them their $3 a minute that they need. Once I’ve figured I have my head around it, I would just dive in deep.
This is what I did with HitTail back in 2012, I think it was. I just picked the topic that I thought would work and dove into it. I spent one to two months just hammering on it. If it didn’t work, I moved on to the next one. The ones that did, they made that up. They made it so that I was able to grow it as substantially as I did.
Great question, Craig. I appreciate you sending that in.
Our next question is another voicemail. It’s about what documentation you might need for a SaaS. “Hi, Mike and Rob. Thanks so much for your podcast. It’s been so useful over the years I’ve been listening to it.
My question today is around documentation. What do both of you think you need, a standard, to run a SaaS online business? I’m looking for things like a test document to do routine tests on new releases, for example, checking everything is still working, documentation on service, processes, service definitions, the list could be endless. But I’d really like to hear from you in terms of what you think you need structurally, in terms of documentation set to operate, to run your businesses. Also, what was required, do you think, for selling businesses well or would be seen to be required by someone looking to invest or purchase your business? Thanks for this again.”
Mike: I think there’s actually two questions here. One is what is the documentation you need internally to run the business and then the second one is what do you need to have in place in order to sell the business. I think that there’s two answers to that. It can be on completely opposite extremes.
In order to run the business, at the very least, again this may depend on how complicated your business is, but there are businesses that are run with everything in the founder’s head and that’s really all they need because it’s small enough and it makes enough money. There’s not a lot of things that they need to do on a day-to-day basis that are gonna be things that they’re going to forget how to do. Then as your business gets more complicated and as you add more people into the business, that’s where you need to start documenting things and having things, processes written down so that whoever you bring in to help you out, they can follow those, and you don’t have to micromanage them because that’s really why you’re bringing somebody into the business is so that they can do things without you having to do them yourself.
Some of it is for scalability purposes of the business, some of it is just you don’t have enough hours in a day, but all of those things need to be documented so that you don’t have to still be involved in those things that you’re hiring somebody else to do. When you get to the point where you’re selling the business, that’s probably where there’s gonna be a lot more documentation that’s going to be needed so when somebody comes in to take over the business, they are going to be able to pick up the business and run without you having to be involved.
Again, this is a little bit more advanced. If you’re gonna be there for the next year or two, it’s probably not as big a deal. If somebody is acquiring your business and you’re required to be with them for the next 18 months, or 24 months, or 36 months, whatever happens to be, that’s probably less important but it still probably needs to be done at some point along the way because they don’t want to run into a situation where, let’s say, you stepped out on the street, you got hit by a bus and killed, they bought this asset that they don’t know how to leverage and you continue to make money from, that’s a very valid concern for the acquirer.
But if it’s something small and it’s very simple to run and operate, you’re probably gonna need less documentation. There is that slide and scale and it really depends a lot on your business complexity, revenue, number of employees, and overall risk tolerance, I’ll say.
Rob: Yeah. When I think of internal documentation, which is what we’re talking about here, I think of two types; I think of processes, non-technical processes, “This is how you do a marketing campaign.” Or, “This is how you check support. This is how you respond to these,” kind of a Wiki type thing. Then I think of kind of the technical docs of if stuff goes down, this is how you repair it, this is what the architectural schema is like in the end points and stuff.
Again, that’s all internal. If you have an API that’s external, you obviously need to document that but let’s just keep internal docs in mind. For internal processes, I never created documents until I was ready to hand it off to a person. If I was doing it myself, I did not spend the time. That has always worked. It’s just like in time documentation. Often, the way I would document it is I would bring the person on it and say, “Alright, here’s your job, it’s to check sporty mails and respond to these. Please look through the history and see I’ve responded, and I’m gonna throw together a Google doc, or I would throw together a Screencast.” And then I’d say, “Can you turn that into a Wiki? So that if we bring a second person on, then you can train them using the materials.” I have put the burden on the person doing it. I delegate that to them to create the processes.
This is just the way I do it. This is way more time-efficient for me. I don’t enjoy creating the processes. If you do, then by all means, you can do it. It’s gonna be better than the person creating it themselves. But for me, I’m trying to get stuff done in the business and I don’t wanna spend a bunch of time writing a bunch of stuff up for technical documentation.
If you’re a single developer and you’re working on it, I would veer very much on the side of less documentation purely because a lot of us came from these enterprise backgrounds, I was coding in Java, and .net, and doing these big consultant projects, and we had to document everything, you don’t wanna do that for your startup. It’s a waste of time. Until you’re bringing more people on and trying to get them ramped up, and even then, even these days where it’s as complicated as Drip is, we basically have a GitHub Wiki where we have articles written by internal developers on different subsystems, and then we do have these things called Runbooks. I’m not sure if you’ve heard this term but it’s a developer term, kind of a DevOps term to describe how to run a system.
If you get a page that something is down, if you got a text that something’s down, you go to the Runbook for that subsystem and it’s supposed to tell you how to troubleshoot and how to do things. Those are valuable. We did not have those until we were at probably 8-10 engineers. It didn’t feel like we did it too late, it didn’t at all. I’m glad we have them now but it wasn’t like we were running around for years with our hair on fire because we didn’t have this documentation.
With that said, Derrick was more stressed out than I would’ve liked and that he would’ve liked because we didn’t delegate this stuff soon enough, and Derrick was on call for years. It was too much. That is how the one regret is it would’ve been nice to have some Runbooks early on. But to document a system, extensive, detailed system documentation falls out of sync so fast when you’re in a startup, and not doing waterfall development, like we did 10 years ago. I would go very documentation light until there comes a time when you need it and then you can document it. That’s a good question. Thanks for sending that in. I hope that helps.
Our next question is from Eoin from Bitesize Irish Gaelic. He’s a developer and he has a question about hiring a developer to write code. He says, “Hi Mike and Rob. What are your thoughts on hiring a developer contractor rather than doing my own development? Do you generally see more leverage in stepping away from development? I’m thinking of Michael Gerber’s book, The E Myth Revisited. I lean towards not being a developer/technician,” as he calls it, “in my business.
Having said that, there’s time and energy involved in hiring and delegating, and on Odesk, a good developer can be $40 an hour. Admittedly, what probably muddies the water on my question is I like development. I’ve had a few developers working on my projects over the years and it’s hard psychologically to let go of the development to someone else. I found the best flow to be developing new features for my webapp, that’s not to say I get great satisfaction from trying to work straight to growing up the business, this really is my life’s work. Possibly, a better way for me to ask the question about it is how can I train my thinking to allow myself to get out of the way of my business’ growth?”
What do you think, Mike?
Mike: Well, there’s obviously definitely opportunities to hire somebody as a developer and pull yourself out of that particular role. As long as you hire the right person, that can be awesome because it will remove you from the heavy lifting of writing the code day in and day out, and having to flip back and forth between things like marketing activities, and sales activities, and then going hardcore into the software development, and then diving into customer support.
The ability to replace yourself in one of those areas that requires a lot of mental overhead is, I won’t say priceless, but there’s a lot of value in being able to do that. That said, I would also ask the question what is it that you are probably the best at? Is it writing code? Is it going to be that for you? Or are you much better at doing marketing activities? I would kind of make the conscious decision about whichever one of those roles you provide the most value for, you take on that responsibility and probably stay there.
It’s not to say that if you’re a developer you can’t learn marketing or that you’re not gonna be any good at it. But what is is that you enjoy doing, what is it that really kind of excites you, and drives you forward everyday. Because if you like diving back into the coding and you do it constantly, it’s gonna be difficult for you to step away from that and hand it over to somebody else and let them make all the difficult decisions.
You can, in some cases, stay heavily involved in the development side of things, if you wanna switch over to marketing, if that’s your passion, but I will say that it’s difficult to do both heavy marketing activities and also be heavily involved in the product architecture side of things especially if it gets to any level of complexity. It’s gonna be difficult. I would just keep those things in mind but it’s a balancing act.
There’s no one right way that’s going to work in every situation. It’s really about what is going to work for you and what is gonna be less distracting for you because if you’re in the middle of an email campaign, and you’re thinking, “God, I wish I can go in and fix this code,” for example and then you start doing it. You’re actually hurting yourself even if you have somebody else there who can do it and they are tasked with that.
You’re basically hurting the relationship or the parameters of the employee-contractor agreement by taking things over and doing them. Because then, it’s gonna feel to them like, “Oh, this person doesn’t trust me,” or “I’m being micromanaged.” Then you introduce yourself to a world of other problems that you had no idea that you were gonna run into.
Rob: Yeah. And to add one more piece of information, because we often shorten emails people send, and I skipped one paragraph. He said, “I run this business while working a full time job and I have a family. I spend around 45 minutes per day on ‘rock activities’.” Means developing new features, analyzing customer survey, planning new price points, like doing really solid stuff. Then another 45 minutes managing part time employees and generally trying to keep up with his inbox.
He’s very, very time constrained. That’s another data point. I think I’ll speak to his situation and then I’ll speak more generally. I think given his situation, it sounds, given that his time is so constrained, this is when I start to think about hiring help. At first it was VAs, then it was contractors even though I could write the code, and really enjoyed writing the code, with only 45 minutes a day for rock activities or big rock activities. I would seriously think about trying to find a good developer.
I think that’s the thing is he’s saying, “How can I train my thinking to allow myself to get out of the way?” It sounds like he already knows what the right answer is in his situation. I think that, assuming that the webapp features and having more of them are gonna help the business grow, and that there is enough competition that is warranted because sometimes, that’s not the case. Sometimes the app is good and it just needs marketing in which case I wouldn’t hire a developer, just let the app sit there, it’s a single feature, and it has a product market fit, and you just need to dump marketing into it, then go do that.
But if you really do need on-going development to continue acquiring new customers and/or compete with competitors, I would heavily, heavily lean in this situation towards finding a good contractor. I’m glad he suggested a $40/hour contract because I think at $15/hour, it can introduce a lot of headaches because you find kind of less experienced people and they can write crappy codes.
So yes, there is a hurdle, a mental hurdle to get over, I think I’ve repeated it to myself over and over, “Is this hassle worth it if it grows the business and allows me to quit my job?” What is your number one goal here? Is it to quit your job? Is it to have enough money to live on from your business and what’s the fastest way to get there? It’s probably, in this case, assuming you do need to develop features, it’s gonna be hiring someone.
I would also look, everyone else has done this, I shouldn’t say everyone else but a lot of people have done this. I made this work on a shoestring budget and almost exactly – [inaudible 00:28:47] you’re talking about, and so have many other people. Hiring developers when we were developers and it felt weird, and yes, you micromanage it first. You just figure it out.
As entrepreneurs, we tend to have growth mindsets, we tend to be somewhat flexible even if we don’t think we [inaudible 00:29:01] the code, and eventually you will, I think, feel better about it.
More generally when people ask this question, I kind of say, “What do you really wanna do? What’s gonna make you happy? What is your goal here?” My goal early on was to quit consulting and quit my job. That was more important to me than continuing coding even though I really, really liked to code.
For me, the quickest way to get there was to buy webapps or to pay contractors to build things because I was working 8-10 hours a day. I was booked full time, billing $100, $150 an hour, it didn’t make sense for me to take days when I was earning that money and go write something when I can hire someone back then for $20/hr, that was decent. That was my number one goal. I was willing to sacrifice writing code even though I loved it. Some people are not and that’s okay.
I listen to the Art of Product podcast with my co-founder Derrick and Ben Orenstein who a lot of folks know from MicroConf and Thoughtbot. I’m pretty sure at one point he said, “Yeah, if I’m gonna do a software product, I wanna write the code. I don’t wanna get out of it.” That’s okay. You can totally do this. You look at what Derrick did. Derrick still wrote a bunch of the code on Drip, or all the code for the first year.
In that case, he found essentially a non-technical co-founder in me. For Ben, I would just say okay, go into the business. But that can strain on you. You can do whatever you want. You’re just gonna have to move a little slower which is fine. You’re probably gonna have to contract out to do other things that normally I would tell you to do, like being the Chief Operations Office, handling and helping with support, and hiring.
If you’re really in the code, you need to be shielded from that. You’re gonna need to find somebody that can help shield you. Build a simpler product because you can’t build, and market, and do sales, and do all these things for a bigger product if you’re not gonna delegate the code. It’s gonna be a challenge for you long term.
But there are people that do it. Peter the CEO of Teamwork, he still writes some code. I’m sure he would admit that it’s probably not the best use of his time at times with a 100-150 person company, but he enjoys it so much that he still wants to be part of it. I think there’s leeway here but best practices, what I would advise, what I think maximizes your chance of success, and will get you there faster, is to stop writing code.
But I totally think you can succeed while still writing code if it really, really is what you wanna do, and you love it. I’ll add one final note. I still write code on the weekends. I wrote some crappy PHP script a few weeks ago just to scrape some websites and hit some APIs because it’s fun, for no other purpose and to do it. Even though I don’t do it for my job, I do have the freedom now to kind of do it for fun and really enjoy it.
I think we have time for one more question today. This one is about digital marketing and whether it works for B2B SaaS. This is from Alistair Scott from riskmemo.com. He says, “What’s the best marketing channels for B2B SaaS business? Is digital marketing such as Facebook, AdWords, etcetera, a viable technique for a B2B SaaS business or is it too broad?”
I don’t know if he’s talking about digital marketing or paid advertising because Facebook and AdWords are really more paid advertising. “My app will be ready to market in a couple of months, and I only need to target a specific role in a company, the person responsible for health and safety. I’m getting very promising feedback from people within my network but test digital marketing campaigns as a smoke test haven’t been successful. Your thoughts are much appreciated.”
Mike: I think this is a really hard question to answer because there’s so many variables involved in doing what appears to be just paid advertising which I think that’s what he’s referring to when he says digital marketing because there’s lots of other forms of digital marketing.
You could write ebooks for example. I’ve seen companies who write ebooks and then they publish it on Amazon and use that as a marketing channel. Now that’s digital marketing, but at the same time, you could also argue that it’s not necessarily marketing because you’ve got a book that you’re selling but you could say that’s a product, it’s a revenue stream. But at the same time, if you have a longer term goal of converting to people who are buying the book into customers of your SaaS application, and the book tells them how to do it, but your SaaS does it for them, then in theory that’s a marketing channel for you. It’s digital marketing.
I would differentiate between those two and say that digital marketing can absolutely work but it really depends on the specific implementation of it. In terms of doing paid advertising, it’s hard for me to say. I feel like there are certain types of industries where paid ads are simply not going to work. It’s not because they can’t work, it’s because the ROI does not work. The numbers themselves don’t make sense. If you have to spend $50 to get a customer and their lifetime value is only $30, yes, you can spend money and acquire those customers but you’re losing money every single time so you can’t sell at a loss and make it up on volume. It’s not gonna happen.
Rob: You make it up on volume.
Mike: Yeah, you can’t do that. I mean, you can but you’re gonna go broke. That’s the bottomline. You can try to spend your way out of it and maybe it’s possible that you have to do that in the short term to figure out something that you can tweak and optimize because your first cuts at it are not going to probably work out very well. You’re still learning what to do, what things work, what the software does, and how you target different types of people, and different companies. There’s a learning curve associated with it.
You’re not gonna be the best at it when you first go out there and try it but eventually over time, your costs are going to go down because you’re gonna get better at it, and you’re gonna be able to outperform your competitors, and get in front of the right people. That said, even after you have all that, it still may not work out financially because you’re still losing money on it. It could be that there’s other things that you have to do aside from paid advertising. But I think that if you’re selling a B2B SaaS product, in most cases, doing online marketing in some format, is probably going to drive revenue for you especially if it’s a low touch sales process.
If it’s high touch, the digital marketing may bring awareness, but you may very well have to do outbound campaigns, and cold calling, and direct marketing, and things like that. I would combine it if that’s the case but this sounds to me like this question’s really aimed directly at how do I do digital marketing to make it successful.
Rob: Yeah. The answer to will this work is I don’t know until you try it. That’s what I would do. I would think that your odds are gonna be…
Mike: Well, it sounds like he has tried it and it hasn’t worked.
Rob: Yeah, I guess you’re right. Here’s what I would think. Facebook, I can’t imagine it working for this. I don’t think you can get someone’s title from Facebook. Can you, in the ads? I don’t know what their segmentation is like these days.
Mike: I don’t know. I don’t think so.
Rob: Here’s the two things I would try for this; outbound email and LinkedIn advertising. Yep, LinkedIn advertising because you can then target based on someone’s title, their job title. You can title regions and all that stuff. Then outbound email, because then you just go somewhere, find a list, outbound email or calling, whatever it is. Because then you can find the list of people. It’s cold calling in essence but at least you know that they are the role that you need if it’s that specific.
I could see toying around with some AdWords because you don’t necessarily need someone to be the role but you need them to searching for something that implies they need your software. The problem with that is it’s gonna be too expensive. I don’t know any AdWords keywords anymore that are possibly affordable unless your LTV is just through the roof. Those are the two things I would try. Facebook, probably not. AdWords, probably too expensive. Thanks or the question. I hope that helps.
Mike: I think that about wraps us up for today. If you have a question, you can call it 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. Subscribe to us in iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening, we’ll see you next time.
Episode 342 | SaaS Development Shortcuts
/
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about SaaS development shortcuts. They discuss the gap between what you think needs to be done versus what really needs to be done and give you tips on how to move faster.
Items mentioned in this episode:
Transcript
Mike: In this episode of Startups For the Rest of Us, Rob and I are going to be talking about SaaS Development Shortcuts. This is Startups For the Rest of Us episode 342.
Welcome to Startups For the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you built you first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s going on this week, Rob?
Rob: It’s been a good week and it’s memorial day weekend coming up so we are flying to California for a couple of days, just like a three or four day trip to see some folks, just looking forward to it. We haven’t been on a trip for I guess since MicroConf which is maybe six weeks ago, it’s not that long ago but looking forward to getting some sun and it’s also nice and warm up where we’re going. Kind of just easing into it. How about you?
Mike: I have to go see a specialist and have some x-rays taken because I might have a torn rotator cuff.
Rob: That is such a bummer, man.
Mike: I know. It’s not bad. If it’s a tear, it’s really small. I think it’s not bad enough where they look at it and say, “Yes, this is obviously a tear. It might just be inflamed and some other stuff.” They’re going to start with some x-rays and see if there’s any fluid buildup or some bone spurs or something like that. If that comes back kind of inconclusive then they’ll move on and do a whole shoulder MRI and see what comes out of that.
Rob: Yeah, that’s a bummer. If they find it then they have to do surgery and then you’re not able to type with that arm for a while.
Mike: Yeah. They also said that because I still have good range of motion, it just hurts when I move in certain positions that physical therapy might be something that they could work with, anti inflammatories or various other things but I’m hoping that I can dodge that surgery bullet. To be honest, that’s not something I want to go through.
Rob: Yeah, totally. It’s always a bummer to get hurt. Nowadays, when I get injured, it’s not like we’re that old but it’s like I remember getting injured running track when I was 21 and you just heal quick, your body is in really good shape and you’re younger. These types of things now, it’s going to take you awhile to get over that. You’ve also had back issues. You just don’t heal as well as you did 20 years ago or whatever.
Mike: Yeah. That actually came to mind like, “I’m not as young as I used to be. I just don’t heal as quickly.” Back then, in your 20s, you can take the bumps and bruises and shake them off and you’ll be back at it the next day. This is just like that dull ache and I’m like, “Oh, this is just going to go on and on.”
Rob: Yeah, totally. Cool, what else? What are we talking about this week?
Mike: Today we’re going to be talking about SaaS Development Shortcuts. I pulled some of this from my MicroConf talk. The basic idea is that there were some parts of my talk where I highlighted where there are gaps between what we think needs to be done versus what really needs to be done. In these places, there are some shortcuts that you can take to avoid doing work now that you can presumably do later. Some of it, you can just avoid indefinitely but there’s other pieces of it that you can push off to the future because it’s going to either take a lot of work or there’s going to be a long time for you to see any results or benefits from doing that work.
There’s workarounds that you can put in place to avoid doing it now. In some cases, you’ll take on some technical data or some other types of work data that you just have to defer really. But by doing so, it allows you to concentrate on the more important things now versus delaying your launch or delaying getting sales or just delaying moving your product further than it would if you took the month or three months or whatever to implement the things that you were looking at.
Rob: Yeah. There’s a lot of these tradeoffs that go into building any type of software, that go into building any type of business. A lot of things that you have to think about and think to yourself, do we have to do this now? Can we push it off? If we push it off, does it create more of a hassle later on? Does it create more debt later on? Not monetary debt, obviously, but technical or business debt. Or is it the same amount? Is it the same amount in three months if I build the knowledge base today, if I build the knowledge base in six months, is it the same amount of work versus when you’re in code, if you take a shortcut, we all know that technical debt will actually get worse over time. There are some of these that get worse if you don’t do them and some are the same or maybe it’s a linear progression. These are the kinds of things you have to think about as you’re trying to figure out what you can delay.
Mike: What we’re going to do is we’re going to walk around some of the different things that we might think that we need but could be delayed with various workarounds and we’ll talk about what some of those workarounds entail and then we’ll talk about some of the things that are really difficult to find workarounds for. And then we’re going to dive into some general guidelines for deciding how to push things off and whether or not you should do them now or schedule them in the near future, kind of how to prioritize them.
To kick things off with the things that we might think that we need, the first one is a sales website. It’s interesting that I ran into this where my traditional thinking all along has been, “You need a sales website in order to sell your products, to tell people what it is, what it does, how it works, how they would use it, what the value is.” What I realized is that if you’re doing direct sales with people, you don’t have to do any of that. You can get away with a lot less than you need to.
For example, I’ve got Bluetick up over 20 customers, around 20 to 25 right now. I still only have I think 3 pages on my website. One of them is a privacy policy, another one is a terms of service and the third one is just the landing page where basically it gives you an overview of what it does and asks you for an email address either to signup, to get an invitation code or to join the mailing list and go through a five part email course. That’s it. I’ve got to this point really without having a website.
Rob: This is an easy one when you’re doing direct sales. With Drip, I wasn’t even doing direct sales but it was onboarding, it’s really what I think about it as. It’s like people wanted to try, always doing emails back and forth and all we had was still that landing page from months and months of onboarding and we did the same thing, got into the high teens, low 20s in terms of customers that way.
Given that you’re still probably trying to find a product market fit at this point, it almost doesn’t makes sense to build a website because you don’t really know what your positioning is, you don’t know what your feature set is, this is still early customer development. I think there are a lot better places your time can be spent than going and trying to hack together some entire website.
Mike: The interesting part about all the stuff that you just said is that because you don’t know what to put on the website, most of it is probably going to be wrong anyway. Going that direct sales route allows you to have the conversations and get people’s feedback and understand truly what it is that they are trying to solve for and what the terminology is that they use and what resonates with them.
Once you’ve done that enough, you get to a certain point where then it makes more sense to build the sales website because you have enough information from those conversations to be able to build something that is going to be effective and pitching towards people that don’t know who you are and you haven’t had a referral or had no conversations or had nothing explained to them, that’s really the position that it puts you in. That really leads into the second one which is marketing automation.
I think people look at marketing automation as a panacea for all types of sales problems but the reality is that it’s very difficult to automate a sales process when you don’t even know what it is that people think yet or what they’re really looking for and that’s what that direct sales approach is going to solve for you.
Rob: Yeah, I agree there too. As much of a proponent as I am of email marketing and marketing automation in general, which is more advanced form of email marketing, it’s just too early at this point. Until you hit the point where you really do feel like you have a good idea of your positioning, you’re going to start to feel like you know what content people need in order to understand your product. There are questions about how you use the product but there’s also questions about the higher level architecture like, “What are best practices for sales nurturing?” That’s what you’re going to get, Mike.
We kept getting what are best practices for email automation or marketing automation? How do I structure my tags? What should I use custom fields for? How is this different than email marketing? It’s a higher level stuff, that’s the kind of stuff that you’re going to either be sending to people via email or you’re going to start pushing some blog post out at some point. That’s at the point where I think you should tip into now I’m going to actually add lead nurturing stuff and build some workflows and start doing behavior tagging because at that point you just have such a better idea of where your business is.
It’s almost a waste of time if you only have 100 website visitors or you only have 20 customers. You really need to get to the point where you’re getting 500 or 1000 uniques a month to where you’re getting at least a handful of new subscribers to go through that stuff.
Mike: The caveat here is that marketing automation is a very broad term and it doesn’t mean that there aren’t certain tactics that you can pull out of the marketing automation playbook that would be beneficial for you. For example, I just saw that Drip sent out an email with a pointer to a mechanism used by Christoph Englehardt who’s a good friend of the show, comes to MicroConf Europe, has taken notes for MicroConf Europe as well. In that article, he went over the idea of using Drip to send an email to people after you’ve captured their email address to pull them back and help with abandoned shopping cart emails. That’s a tactic that you can use to help pull people back to your website.
I actually use it for Bluetick right now where if somebody goes in, they request an invitation code that pops them over to a survey page. If they don’t fill out the survey page, it sends them an email from Drip about 10 minutes later. My hope and intent is that they will fill out the survey because they’re right there. But if they don’t, then they get a follow up email from Drip a little while later. Interestingly enough, I got an email earlier this week from somebody saying, “Hey, how did you do that? Because I’d love to know a little bit more information about it.” We actually have a demo scheduled here pretty soon. It’s tactics like that that can really help. You don’t have to go out and implement everything that’s marketing automation related but there are certain tactics that you can pull from it.
Rob: Another thing that I tend to push off, because it doesn’t get harder to do this in three or six months, it doesn’t build debt, is documentation. At first, when you’re doing hand onboarding, you’re doing direct sales, really the documentation that I had was the emails back and forth with people. I just started gathering those up. First it was an FAQ doc and then I realized some of them needed to really be flashed out. That was the best way to kick off our knowledge base.
First there was nothing. As soon as we get to the point where I knew we’re going to be emailing several thousand people on our launch list, I knew we needed something. What I did is knowing that writing documentation was going to take forever, I went in and I recorded about maybe somewhere between eight and a dozen Screencasts. Three to five minute Screencast where I walk through. This is what a campaign is. This is just basic stuff. This is what this setting does, there wasn’t a ton in the app.
I just slapped up again, that was 8 to 12KB articles. It was in a WordPress, there’s a WordPress theme, I think, that allows you to make a KB and I just put up there and that’s it. We had 8, 9, 10 KB articles at the start. Screencast or not, the ideal way to consume that, it was very fast for me to make them but within the first few months people are saying, “I really want to be able to read through them. I was at the airport, the WiFi was bad and I couldn’t play them.” Overtime, I actually paid someone to turn those Screencast into documents, like actual KB articles.
That’s the progression. You don’t need to write all the documentation upfront. It would be great if you could but you just don’t have the time. That’s the idea, you start with nothing and it really is just manual and you’re going to have more support upfront because of that but then you move into something lighter, for me that was Screencast, for you it may be something different and then ultimately you build that out over time.
Mike: The next item on the list for something you can push off until later is a billing system. It sounds like a billing system is probably not something you want to push off because you want to be able to start getting revenue as quickly as possible. There are hacks around having a billing system in place. Instead of having an automated billing process in place, you could send people manual invoices. There’s tons of different pieces of software out there that allow you to send somebody an invoice and then have them pay you, you could easily do something like that through PayPal, you could send them a PayPal invoice once a month.
Yes, that doesn’t scale but that’s not the point. The point is to allow you to avoid building out that billing system until you get to a point where it is difficult for you to keep up. Another thing that you could do is you could manually enter people’s credit cards in Stripe using the backend. There’s a WordPress plugin called WP Simple Pay which is from Phil Derksen who’s also a MicroConf attendee and friend of ours. That WordPress plugin can be used to capture those credit cards and help you with that stuff without you being involved directly and taking the credit card and entering it in.
If you want to automate some things a little bit, as Rob said, there’s that natural progression. Over time, you can add more and more things into it until you get to a point where it is fully automated and it helps you move things forward. But until you need it, there’s no point spending a lot of time doing it because a billing system can be very, very complicated. At the start, you don’t need all that complexity.
Rob: With Drip, we didn’t actually use any of those approaches, we just had a little Rail script that Derick cranked up. I think it took him less than a day. We wind up building that five days before the first billing was going to run, we were signing people up and I think we got 30-day trial so we got 25 days into the trial and I’m like, “Alright Derek, we got to get something that’s going to bill people on a couple days.” It was super simple at first, it was literally this is an amount and this is how much you’re getting billed.
Again, over the coming month, you have to upgrade and automatic downgrade and prorating and whatever else goes along with it. We built that into it but we started pretty simple. I agree, you don’t need as much logic as you think you do in the early days in billing.
Mike: One of the more common things that you probably need to implement in a SaaS application is permission system. Depending on whether you’re going to do it like a single tenant or multi tenant model on the backend, you may need to implement permissions inside the system to allow certain people access some resources and then prevent others from accessing those same resources.
This can get very, very complicated, especially if you get into the idea of having group accounts and some people with certain roles or permissions. Again, there are lots of white papers and documentations you can read out there about different ways of implementing the permission systems or claim system and it does get complicated. But in the early days, you really don’t need any of that. All you need is the ability for somebody to login and see their data and not see somebody else’s. You don’t need to create all this additional complexity with groups and roles and permissions and stuff like that, you could really get started with one user.
To Rob’s point earlier, there are certain types of debt that you’re taking on. In this case, it’s a technical debt and that can be difficult to get around. But in the early days, if you need to get around that just to help prove out the idea and make sure that things are working and people are getting value out of the app, this is one of the shortcuts that you can take. You have to be forewarned that it is technical debts you’re taking on when you use this approach but it could be what you need to do.
Rob: Yup. When we first launched Drip, it was just one login and then people wanted to invite whatever teammates and so then we had to add the ability to have additional folks. The only thing we had was owner and I think we called it an admin or something was the other role. 6, 12 months down the line, we kept getting requests for like, “I don’t want some people to mess with our settings.” We added a member, there is three tiers, owner, admin, member.
We have been able to maintain that. We are tens of thousands of users and four years into a pretty substantial SaaS app. We do get periodic requests to add more granular stuff and we started talking about that internally, what that would look like. But the good thing is now, we really understand our customer, we really understand our audience and we have had enough request for it asking in different ways. I want people to be able to come in but not export anybody or not be able to view my subscribers or not be able to send anybody. There’s all these different things.
We’re not making it up in a vacuum, it’s not like we just dream up how we think that they might use it, we have real usage patterns and real feature requests. I’m very much in agreement with you on this one. If you need multiple logins, that’s fine but as soon as you get to anything granular at all, I would pump that so far down the line unless that’s a core, core competency of your app which I’m guessing it’s not going to be.
Mike: One thing that I recently did was I repurposed our impersonation mechanism and applied it to people’s accounts to let them have multiple users inside the same account. It works fine. It’s not great, there’s certainly a lot of work that needs to be done there but for the time being it allows people to use the products and have different logins physically associated with the same account. Like I said, it’s a tradeoff but it does work. Early on, your customers are probably going to be pretty understanding about that stuff.
Rob: Another one is password reset and account management type stuff, it’s a lot of time to implement versus the actual number of minutes anyone is going to use it or the number of times someone is going to use it in the first three months of your app. I know that pretty sure we had a reset password button and I think it may have fired off an email to us or something that’s like, “Reset my password.”
Again, this is very, very early on, you’re at 20, 30, 40 customers, you’re going to get one a week and you can just do it manually and people understand. It’s not until you go a little broader and again you’re going to have to really start to scale up that you need to build this out.
Mike: Funny enough that I had mentioned this is my MicroConf talk as well but the password reset in Bluetick did not work at all for nine months. We implemented it probably six months ago but it did not work for the longest time and we would just go in and manually do if somebody came back and said, “Hey, my password reset didn’t work.” There was literally only three people who would ask in those nine months. It’s one of those really low frequency things that is important and needs to be taken care of but you can manually handle it if need be. I did have a manual backend where I could go in and I could reset somebody’s password, they just couldn’t do it themselves.
The next one is a big thing which is reporting. I think in most cases, the challenge with reporting is that unless your app is specifically designed to provide reporting services for somebody, then you can probably get away with very little reporting in the first version. Most of the reason that you would want to pump this down the road is because you don’t necessarily know what people want to be reporting on. As you have conversations with people, you’re going to learn more about it. When you are initially looking at building reports, you’re guessing what people want and it’s just not going to be helpful to you because you’re going to build a bunch of things, people are going to say, “Hey, could you do this instead?”
Now you’ve built a bunch of things that essentially you have to support longer term because you’ve already built them and put them in the app and people are expecting that those things are probably going to stick around but now you’ve got all this legacy code there and it wasn’t really what people were looking for anyway. I think that in most cases it’s best to just put this down the road and not bother with the initially. [00:19:13] had done a recent episode in the Startup chat where they talked about killing features. You can kill features like this but if you only have two reports, it’s really hard to take away one of them.
Rob: Another thing you can push off to get further down the road is the classic marketing strategies, the ones that require long iteration cycles, higher workloads like SEO and content marketing. These are things that take a long time to ramp up to, it’s not something you should push off so long because it’s not like you’re going to launch a blog and then start getting traction with either content marketing or SEO immediately.
Again, when you are under that 50 person mark, it’s just not something that you want to scale to. If you are not doing these other things of building a password reset and building a billing system, you’re not there yet, you don’t actually want to drive this type of cold traffic to your site and stuff. Everyone talks about it, they talk about this, they talk about split testing, these are things that you need to do later on, you need to wait until you’re starting to scale up marketing and you feel like the app and your team is at a place where it can really onboard people, you have documentation and you’re ready to start dealing with really new users to see how they come in and how they get onboarded and how they convert.
Mike: The next one is new feature development. The rule of thumb that I’ve taken lately is that unless I get a certain number of people asking for something or saying that that’s important, or if they’re not a customer yet and they say that, “I need this in order to be able to sign on.” It’s a deal breaker to them, I generally push that off to the side in favor of other things that more people have asked for or are higher priority because it’s not something that is being asked for a lot, therefore, it’s just less important than those other things. I’m not going to spend my time building something that very few people are going to use or it’s not going to be used very often. Instead, I’ll spend my time working on those things that people are going to use a lot, that are getting asked for a lot because those are clearly most important.
The other ones are stuff that they’re nice to have sometimes, it’s just people are asking a question because they want to know the answer to it, not because they’re actually interested in using it. That’s an interesting side note that I’ve discovered is when somebody asked you something, a great way to deflect the question is to ask him if it’s important to them. Sometimes they’ll just say, “No I was just asking, I was just wondering.” If you have that developer mindset where how do I solve problem X that somebody just presented me? You can very easily find yourself going off into the weeds and trying to do something that’s going to take you a while to do when the person was just asking, they just wanted to know because they were curious, not because they needed it.
The last one is being able to provide real time results for people. This delves partially into reporting but also if you need to do any sort of complex calculations or you’re not sure how you’re going to get the data from one place to another and it needs to be done manually for the time being until you go to a point where you automate it.
This could be any sort of situation like if you have to deal with a government website, for example, and you have to feed data into it, those are notoriously terrible when it comes to APIs and being able to send data into them. A lot of times you have to resort to various hacks like using Selenium to automate a browser, to go plugin all the different fields and stuff. Instead of doing that, hire somebody to go in and type in stuff that customers have entered, you’ve made it easy for them to either import the data or put stuff in in a way that makes sense and then you have somebody that go in and type it all in.
Most people would say, “This is a SaaS application and that should be real time.” But it doesn’t need to be, most of the time when you’re looking at those types of things, there’s customer expectations about how long it should take and then there’s also what they really needed return to them. If the time period is a 24 or 48 hour window, it’s probably not that big of a deal. Unless your whole value proposition is that it is automated and very fast, in those types of cases you probably have to do all the leg work and automation upfront. But a lot of times you can get away with just pushing it down the road. Once it gets to a scale where you can’t handle it or it is causing you far too much to not have it automated, that’s when you go down that path.
Rob: Let’s take a look at three things that are difficult to get around, things that you’re going to have to implement upfront and the things that you should be focusing on. The first one are the core parts of your value proposition. Things like features, reports, if they’re absolutely needed, automation, if that’s really what your app does. Without this, you don’t really have much value. This is probably the core piece of finding product market fit and building something people want, you should be focusing on the features that are driving value for your prospects and customers.
Mike: The next one is probably a judgment call but I find that user impersonation is really difficult to get around. You can use screen sharing, so if somebody runs into a problem, you can get on a call with them using a variety of different tools and share their screen and look at what it is that they’re seeing. That type of thing is impossible to do without the other person being present and allowing you to essentially watch them as they login and go do whatever it is.
It’s a lot easier in many cases to have an impersonation mechanism in place so that you can flip a flag on your account or in the database directly and just say, “Hey, log me in as that person.” Then you will be able to see exactly what they would see. If they come back and they have questions about how do I do this or how do I that or why is this showing up in my account this way, it allows you to go into their account, take screenshots and then send them those screenshots or do a Screencast and explain to them what it is that they’re seeing. If you’re seeing data that shouldn’t be there, then it’s a lot easier to do it without the customer present and having you say why is this there? I don’t understand myself, we wrote it. You’re in a much better position if you have that impersonation ability.
Rob: By impersonation you mean like being able to login as one of your customers, is that right?
Mike: Yes.
Rob: I totally agree, this is a huge one. We call it ghosting, you ghost in as them. But it’s incredible to be able to see the app as your customers see exactly what they need. If you don’t have that ability, it’s like you’re digging through raw data that’ll send you a bug and you can’t reproduce it but as soon as you can login as them, that’s a big deal. This is something I would build very, very early on.
The third one that’s difficult to get around is not having any type of sales channel. You need to be able to get to customers somehow. Referrals can be one, this direct sales model, you could be doing outbound cold outreach, you could just have an email list of 50 people and you email them one at a time and you’re bringing them in. You need some type of sales channel to be bringing people in for this to be worth it. Until you get the feedback, you can get a little bit of revenue and you can start building something that you hope a broader audience wants.
Mike: Actually, emailing them individually, that’s what Bluetick does. It allows you to iterate through those people and email them individually as if it was coming directly from you and you can very quickly go through large numbers of people, personalized automation at scale. But I agree. It’s difficult if you don’t have a sales channel at all, you can’t do that with five people.
Rob: That’s Bluetick.io ladies and gentlemen.
Mike: Now we’re going to move on to general guidelines for deciding what to push off. There are a couple of different criteria you can look at. The first one is is there a manual workaround of some kind? It doesn’t need to be something that is quick and easy or automated. If it takes writing sequel and running against the database manually for an individual customer to do those types of things, then it counts as a manual workaround. It doesn’t mean that it’s easy but if it’s easier to do that than it is to spend a week or two writing code, then chances are good that you can start with that and not have to go through that couple of weeks of writing code that may not be used very often.
That leads directly into the second thing which is it’s not something that you or a customer would do very often. If it’s not used very much, then there’s no real point in automating it and writing the code to do those operations.
Rob: Another guideline for thinking about when to push stuff off is if it’s going to take a long time to automate. There are even things that happen fairly frequently that if it’s like two or three months of dev time to implement, you might still be doing manually or having someone on your team do manually a year, two, three years into your business. It’s always a balance. If you can build two killer features in two months or you can build this one background task that only happens once a week or once a day or five times a day, there really is a balance to human automation versus code automation.
Another guideline that leads right into is you’re not really sure what to automate. If you have some stuff that seems like it takes manual time but maybe you don’t know how to automate it or you’re not sure exactly how that would work, then it’s a good reason to push this off. What I found is things do become clearer over time. The more people you get, the more customers you get and the further along your app gets, things just mature and it becomes easier to tell how to automate things and what you should automate.
Mike: The last situation where you should consider pushing something off is if it’s a feature or a task that different customers are going to want different things or are probably going to want different things. This is where reporting falls square into this bucket but there are certainly other things where if there’s a presentation layer over the top of the data that customers might say, “I want to see these columns versus those columns. I want to be able to filter certain things out of the data right on the screen.”
Those are the situations where you can take the stands, here it is out of the box and we will get to those things down the road when they become more important or when enough people ask for them. But because different customers are going to have those different requirements or different needs around it, you can build a lot of customization around presenting data but people are going to want different things and it can take you a long time to build even just those individual pieces.
Rob: I think that about wraps us up for the day. If you have a question for us, you can call our voicemail number at 888-8019-690 or email us at questions@startupsfortherestofus.com.
Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thank you for listening. We will see you next time.
