Episode 386 | Balancing Feature Development with Marketing, the Cost of Technical Debt, and More Listener Questions

Rob: In this episode of Startups for the Rest of Us, Mike and I talk about balancing feature development with marketing, the cost of technical debt, and answer more listener questions. This is Startups for the Rest of Us Episode 386.

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 have the plague.

Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. You were sick all weekend?

Mike: Yeah. My eldest son got sick the last Wednesday, I think it was. It was like Wednesday and Thursday and we sent him back to school on Friday. Then my wife got sick between Friday and Saturday and then I got sick between Saturday and Sunday. It’s been a rough week to say the least.

Rob: Yeah. That’s brutal. Being sick just tears you up, means you can’t get anything done, especially when you don’t have vacation time, you don’t have to paid time off and you’re trying to drive a  business forward, it’s like every hour is precious.

Mike: Yeah. Fortunately for us, it was kind of over the weekend but still we’re recording now, we don’t usually record till Thursday but today’s Monday and after this podcast episode, I’m probably gonna go to bed.

Rob: Right, right. Yeah. Today, we’re actually continuing kind of a continuation of last week’s episode. I had picked out several questions last week that you and I were gonna go through and answer and we only got through a couple of them because the GDPR conversation was so extensive. I think that was a good thing. I think we went in depth and gave ideas and feedback but it meant that we had this big block of unanswered questions and I wanted to keep going with them.

Now we have a few voicemails and some others today. But before we do that, I want to tell you, I know I haven’t talked about Drip features in a while but I’m pretty excited about this upcoming feature. We’ve been working on it for–I’m trying to think–it’s gotta have to be about four months now so it’s one of the larger features we’ve embarked on but it’s a visual email builder.

Mike: Oh, nice. What’s that involve?

Rob: A lot of stuff. Yeah, you can imagine not only the frontend which is obviously a lot of dynamic stuff, a lot of Javascript and pointing and clicking and moving things around the screen but then taking something that is essentially JSON and translating into the table-based email render to HTML is a challenge.

We found some AltSize and trade secret workarounds that we found, we’ve really done a lot of research and I think I’ve done a good job with it. But what I’ve heard from folks who have built visual email builders is building the visual portion of it is one project and it will takes six months or nine months, depending on how many […] we have on it and how good they are. Then just doing the table-based rendering and getting all of that to work and working all the clients is at whole separate project. It can take as long as building the actual visual builder. This is why a lot of upstart ESPs don’t build them because the time investment is so extensive.

Mike: When you say rendering the stuff and the clients–I understand what you mean by the differences between them–but when you go back to the visual email builder, what advantages does that have over what Drip does now?

Rob: Right. Today, Drip just has a nice little WYSIWYG text editor and I’m still gonna use that. I never use visual email builders because I like the personal interaction or it just feels more like you’re getting a plain-text email when you send using our standard plain-text template. This is how I’ve always recommended doing it. I believe the conversation rates are higher when you do that.

However, there are a few industries where they have done tests–so they’ve done tests across many industries in terms of visual email with a lot of images and table-based layout, two columns and this and that versus just something that kind of looks like a plain-text email, much like we send out to a MicroConf list, or I send out to my blogs Software by Rob list, they tend to be more personal. It’s from Rob Walling, Founder, it looks like he’s actually typing it to you. But there are few industries—ecommerce is one and travel is another—where having back these more exotic layouts and emails can and will convert better.

Since we do have a large ecommerce contingent and since we’ve been focusing on commerce-based businesses, people who are selling things, we have found a time to break ground on a visual builder. It allows you to do the things where you see the fancy, neat template, you can just insert your images and have that layout. It’s not something I’m gonna recommend for everybody but there are instances and match your converts better.

Mike: Got it. Kind of like if you go over to MailChimp for example, they’ve got like 30 or 50 different templates you can choose from and okay, that makes sense.

Rob: Exactly.

Mike: That makes sense.

Rob: Right. We won’t have 30 or 50 templates to start with but obviously that’s a direction that you’ll wind up going and it’s become table stakes. Again, in certain industries if you’re doing ecommerce and you’re working with companies using let’s say a platform like Shopify, BigCommerce, or WooCommerce, or if they have their own custom solution for ecommerce, they tend to want to send emails with a lot of images and not just to frustrate top to bottom flow where it’s image-text, image-text, you wanna have things that just look nicer than that.

Mike: Yeah. Things that come to mind for that are things like Amazon, Newegg, or ThinkGeek, all those, it’s exactly the same. I totally get what you’re saying where that’s going, but it totally makes sense.

Rob: Yup. The reason I’m excited about it is because I feel much like we did with workflows, we went back to the first principles and said, “What did everyone else do wrong? What do we hate about builders? How can we do this differently?” It isn’t just look at what everyone did and copy the best features, just like we’re doing things that are different than anyone else. There are obviously gonna be commonalities. There’s stuff on the left that you’re text and your image block and your divider and whatever, then there’s the email on the right. That’s common stuff but there’s certain paradigms that we use that I think are superior and gonna make for a better user experience.

The team has been working hard on it and everytime I see it down the road, I’m like, “Man, this is super cool, actually. I wanna use this even though I don’t really…” Like I said, I don’t use other visual builders as a rule when I’m writing my emails because I’ve always liked the more plain-text feel.

Mike: Awesome. Let’s dive right into the episode and they’ve got a couple of questions outlined here. Let’s get started on this.

Rob: For sure. Our first one is a voicemail and it’s about how to balance feature development and marketing specifically for an IOS app. But let’s hear the question and we can figure out what form we wanna answer it.

Steven: Hi Mike and Rob. This is Steven Johnson with […] Plus, an iOS and Mac app for hikers. My website is […]studios.com. I have a question about how you work […] user feedback. I’ve been getting a lot of feedback about my app on the Apple Watch, it’s still like I’m missing out on some opportunities as well as on just keeping up with where the market’s going.

However, right now I’ve really been prioritizing a lot of marketing efforts, working on conversion rates, lowering churn, […] partnerships with business development and […] by knowing […] you talk a lot about having more marketing always speeds out features and I completely agree with that. I’m just trying to figure out how do I kind of balance these two priorities and knowing how to balance user requests that come in, especially one that feel like the market’s making changes and I feel like am I missing out on something, maybe I am and maybe I’m not, but I know that there’s opportunities that I’m not capturing with my marketing, I know there’s conversion opportunities as well as churn that I need to work on. I’m just curious about your thoughts on that. Thanks for the show. Love what you guys do. Thanks.

Mike: I think this is an interesting question mainly because it’s an iOS and Mac app but there’s also the recurring annual subscription from productivity. I think the prices–there is a free plan–but then they range from $20 a year up to $80 a year which is of around what, $5-$8 a month, something along those lines. I think that the challenge here is identifying why that churn happens. Is it legitimately because people are churning out and they’re no longer using it or is it just they find that the app doesn’t help them nearly as much as they thought it would? I think it’d be easy to assume that, “Oh, you should be doing this.” Or, “You should be implementing that feature.” But I think I might dive a little bit more into the churn itself and start ask a lot more detailed questions about why the people aren’t using that.

My concerns/fear here would be that what you’re offering people is conceptually what they want but either the implementation itself is not really what they’re looking for or it doesn’t really quite match up with what the value proposition they were sold on is and it could turn out to be that somebody tries one app and they think that it’s gonna work and once they get out of the field and they’re using it, it sort of works or does most of what they want but it’s not quite enough so they just decide to switch and use something else. Maybe look at your performance metrics or your usability metrics to see like are people actually using it after three or four months in or is it that they’ve paid for and it was a low enough price point that they said, “Well, I paid $50 for this and it’s not a big deal so I’ll just try this other thing over here for another $50.”

As I said, the fear/concern that I would have is something that people use and it may just not be able to deliver on the promise. It’s not to say that you can never deliver on that promise. The fear that I have is it even possible to do what it is that they really want. I don’t know the answer to that, you have to ask people to find out. But as you said, the other component is like do you invest more on the marketing side and try and ramp it up or do you drill in and start trying to fix those things and add more features?

I think the first place to start to find out why people are churning out and what the fundamental issue is there and from there look back and say is it important enough for you to fix? The reason I say that is because there’s a question for road map and what is the most important to you, not roadmap, runway is more it than anything else, are you able to make ends meet with the app the way it is or are you chewing through runway and sort of losing money on it as you’re going along? In that case, you need to lean more towards scaling things up and then fixing things versus being able to make ends meet on a regular basis and you don’t have to worry about it as much. At that point, you can dig in and start fixing things in the app. That’s probably the place that I would start. Rob, I’m sure you have some thoughts on this as well.

Rob: Yeah. This is the age-old question. I think it’s a really good one to think about. I think in general, as developers, we think features are the answer, and in general, they are not. Not to say, all at all times because in certain markets, in certain niches, it really will make a big difference like Drip launching workflows was game changing for us, it doubled our month over month growth. It can happen.

But so many of the little features that are constantly being requested, if you have thousands of users you’re gonna get 50 or 100 feature requests a month and most of them you need to not build. Not only to keep the product simple enough that it doesn’t become bloated, but because you just don’t have the time to build them all. The caller is so much closer to his business than we are so it’s hard for me to make a recommendation to him, but my recommendation in general would be stir away from the mindset that I just need this one more feature to do this thing, unless everyone’s requesting it.

There comes a certain point where 10% of your feature requests are for the exact same feature. At that point, that’s when we break down–in the early days, we build a lot more now, we have a team of 18 developers or whatever, but in the early days when we were super cash and resource trapped, it was pretty much no by default and yes to these highly focused things that we knew were gonna move the needle. That’s how I balance it.

I think that the caller’s approach to doing joint ventures and focusing on marketing is genius. That’s exactly what I would be doing because the more marketing you do, assuming it’s effective, the more revenue you get, and that revenue will allow you to then hire a contractor in essence or perhaps the first time employee, how ever you wanna work it. But hire a developer that you can supervise because that will then, I should take one step back first, first person I would hire is a part-time VA to handle all your support, if you’re still handling that, because that will free up.

Then start thinking about hiring someone to write the code and this is the part that developers always struggle with because no one “is going to write the code as well as I do.” However, if you can free up 12-30 hours of your time in a week and features are still moving forward and you have some budget to pay someone, it can be game changing for your business and that frees you up to focus on really moving the needle.

I think marketing in the early days is such a big deal because you need to get the revenue to allow yourself to start stepping away from certain roles that while you may enjoy doing them are probably in the early days are less effective and what more if the needle is matched.

Thanks for the question. I hope that was helpful. Our next question is about overcoming hesitations about partnerships to move the business forward.

Joshua: Hi Mike and Rob. This is Joshua from [Perspexa Labs]. First, thanks so much to this podcast. Every episode is invaluable. My question is this, how do I overcome my hesitancy of partnering with someone to move the business forward?

For context, I run a B2B SaaS company that offers monthly subs in the range of 100-350 a month, and we’ve plateaued about $2,500 in MRR I co-founded the business with an office colleague but I just realized circumstances he really isn’t able to participate materially in the business anymore and our product is solid at this point but I know we need to move the needle and sell the marketing in a big way. Try as I might, I just can’t seem to crack that nut.

I know that finding the right person to bring onboard will probably do wonders and turn us into a vital business but on a do-it-yourself-er and I just have trouble, one, convince myself that I ought to do this, and two, coming up with the vital way to achieve it. Any advice for effectively a solopreneur who doesn’t wanna be stuck in a half business for forever? Thanks so much for the both of you. Everyone, go leave a review to this podcast on iTunes. Thanks guys. Bye.

Rob: Joshua was kind enough to also send us an email with a bit more background and he said, “The main product outreach is at [perspexalabs.com], we’ve got a core group of customers and service businesses like pest control and electricity and we’ll soon be getting into healthcare providers because our revenue is only $2,500 a month with margins of around 70%. It’s not enough yet to pay salaries. I’m guessing that bringing someone onboard will probably need to be an equity arrangement which I’d be fine with.

With regards to my own efforts to sales and marketing I’ve gone to the Traction book and tried several different approaches including online ads, cold-calls, cold-email outreach and attended a very targeted trade show. That really hasn’t generated fruit as nearly all of our current customers are referrals from other customers. Unmentioned to my question bills are related issue, should I let my current co-founder remain in the business? I’d really like him to be here if we can get into healthcare because of his connections, but I know this isn’t the first priority anymore.” What do you think, Mike? It’s a tough one.

Mike: Yeah. I think you can almost divide this into two entirely different things. One of which is what to do about the co-founder and then the other is how do you move the business forward when you’ve got $2,500 a month and not enough money to do a lot and you’ve also obviously got the co-founder onboard and I don’t know what the relationship there is in specifically call that out.

Rob: It sounds like it’s still amicable and he’d like to keep him on if they were to go into healthcare but not if they don’t. You don’t know if they vested so the first thing is that you should have done four year vesting probably so that your co-founder wouldn’t own the entire percentage that they had. Because if they decide to leave, that will go back into the pool to get the next person.

Mike: I think, with regards to what to do about the co-founder, that’s probably the first thing to do. It sounds like you wanna keep them on but the question is how much is he going to be able to contribute. As Rob said, the vesting schedule maybe he owns 25% because he’s stuck around a year, 50% because he’s stuck around for 2 years. That seems to me like the first thing to look at and try and figure out and if he has to walk away because he’s just not involved, that doesn’t mean he still doesn’t own a certain percentage of the business anymore and can’t contribute under the […] capacity or something along those lines. That’s something I think you have to work out with your co-founder and sit down and have an honest conversation about what him stepping away from the business really means for the business and for the relationship between you guys.

Then once you’ve figured that out, the next question to tackle is what do you do about the business itself. I think you didn’t specify what your own personal situation is or whether you’re taking money from the business and living off of it. But with the $2,500 a month, it sounds to me like because you’re a do-it-yourself-er, it might be a viable strategy to go out and find a business coach who can walk you through a bunch of different things and that does a couple of things.

One, is it avoids handing equity over to somebody else, and two, it still allows you to do those things yourself and you get that personalized assistance from somebody else and a sounding board from somebody who’s vested in the business because you are paying them to give you ideas and take a hard look at what it is that you’re doing and how effective those things are but you’re still doing those things yourself and you still don’t necessarily hand over control to a third party or a co-founder or another partner in the business and avoid some of those other issues that maybe you’re struggling with right now.

I don’t think that it’s wise to introduce too many changes all at once. That could be a nice bridge scenario where you are involving somebody else but you’re not handing over the reins to somebody else in a co-founder capacity while you’re having your current co-founder step away from the business a little bit. That’s probably where I’d start looking and see if that makes sense to you.

Rob: Yeah. I think you’re right, there are two separate issues here, it’s existing co-founder and then pulling on a new partner. I think given that the business you have to de-risk the business a small amount that bringing on a new partner, you could obviously give equity without giving an enormous amount. It wouldn’t need to be a third of the equity or something. It depends on your aspirations and think where the business is headed and who you can find but I’m thinking in the 10%-20% range given where you are. If you were gonna go raise funding and you’re gonna go try to find like a COO or something or a CTO, they get 5%, but you’re in a little bit different situation because it doesn’t sound like you’re gonna get so big so fast, that that’s gonna be warranted. As a result you have to bump that equity to 10% or 15% or whatever. But at this point, in my opinion wouldn’t just be an even split.

I think the hard part is finding that person and vetting them and it’s like a marriage because you guys are gonna have shared ownership of things and breaking that up later can be like a divorce. I think getting over your hesitation is one thing, but I think the harder thing is to find someone who is good enough or who’s gonna work with your style, who’s willing to be in the trenches with you, who I think it really wants to stick around and is able to work because it sounds like this is gonna be nights and weekends, people are not cut out for that in general, most people just think they wanna do it and then a month or two months and they just flick out or they just decide not to do it.

I think finding someone who meets all this criteria is really hard but I think if you can, then what I would look at doing is definitely have kind of a trial period, maybe 90 days, just to say how things feel, I would definitely have four year vesting on that with the one year cliff, meaning they don’t get any shares until they’ve been around for a year. I think that’s how I would approach it and I would look to be meeting people in person so I would be going to the MicroConfs and the businesses software and these conferences where there are folks who could potentially be in that pool for you separately regarding your current co-founder. I think you just need to make the choice sooner rather than later whether they’re going to healthcare. If you’re gonna go onto it and he wants to stay around, you wanna keep him around, that’s great, and if you’re not, then I think the decision is made there.

I know it’s not always that crystal clear but it does, given that information you’ve provided, seem perhaps how I would perceive. Thanks for the question, hope that was helpful.

The next question is about technical debt. Mike, does technical debt really come back to bite you?

Mike: Oh, yeah. No question on that.

Rob: Alright. The subject line of the email is actually, “Have technical debt decisions been easy to pay down later or did they really come back to bite you?” He says, “Love the show, listened for the past year, really love the practical advice. I’m looking for your technical perspective about what matters in the early days of getting a site running while keeping customers happy with mission critical data, building a data heavy B2B SaaS startup.

The frontend is in Angular, the backend is in Rails, intermediate self-taught developers, new things I haven’t done before can sometimes take a week or two to figure out. I’m making early technical debt tradeoffs hosting using Heroku versus AWS, database PostgreSQL versus Aurora, and the other miscellaneous things relating to data structures.

I’m not looking for technical help but the question is more geared to your experience of how much this stuff matters up front and really needs to be solved to get functional versus it’s not too hard to change it later. Theoretically important but won’t kill you so pick the simpler thing even if you know you’ll need it to change it after launch. Am I wasting a lot of time by taking the shortcut now and having to pull the app apart later to move it around when I have real customers using it in production?”

Mike, this is not gonna be as long as GDPR, I promise, but I feel like we have a lot to say on this, so go. Just start rolling with this. What do you think?

Mike: Yeah. Do we have like beeps cued up immediately for all the profanity that’s about to be dropped on this?

Rob: Yeah. Technical debt, it’s a *.

Mike: Yes, it is, yes, it is. I think looking back on this particular piece of it, some of the things that he had brought up, the things like hosting and the database selection and the data structures that you’re using on a backend, some of those can be really hard to change later on, versely impossible. In some cases, you’re looking at a complete rewrite.

You at least have to have enough technical knowledge to make those decisions in a way that is not going to completely kill the app later on or force you to do an absolute rewrite from the ground up. That said, I do know people who have done complete rewrites after they’ve gotten to a point where they’ve gotten customers onboard and it basically delays things, you may have to take three, six, nine months of accepting the fact that you’re just not gonna make any progress on the features in order to fix that fundamental positions that will bust it.

Then, there’s kind of a second level which is where you’re trying to make decisions about how do you structure the data or how do you create the database in such a way that it makes easy to do certain queries or provide a solid error handling, error returns to the API for example. I think in those cases, you can mitigate them to some extent by using dependency injection and creating these interfaces that sit in front of it and if you need to rewrite one, then you can, you’re almost swapping out an entire layer of the application for another in a very specific way.

I’ll give an example with Bluetick, like the backend storage system for storing emails has been rewritten four times. It’s because at first it was like let’s just get something working and then it was trying to optimize for local storage and then the next level was things are not working in local storage because there’s so much data coming in at all times like I just can’t scale that much on one machine and then I kind of move everything into the cloud and into the Azure tables in no sequel storage. Then the fourth rewrite was essentially making that more scalable and optimized.

Each level on the way like there was some level of rewrite but because it was essentially being able to flip a switch and say instead of using this set of data structures, you can do those on a per user basis or on small sub-segments of the users and not affect others. I would definitely do some research on dependency injection.

The other nice by-product of them is that it helps with writing unit test to be able to make sure that those things that are working from one version of your rewrite to the next in that particular component or module. Beyond that, there’s always gonna be things that you run into where you think that one way is a good way to solve a technical challenge and you turn around and find that it just wasn’t, you get down in the weed sometimes and you realize that you made a really, really big mistake and the only way to resolve that at that point is to rewrite it and there’s nothing you can do at that point.

The only way to have mitigated those four types of problems is to run into them and then realize after the fact that it was a mistake. It’s really hard to generalize from one application or problem space to the next and say like, “Oh, you should never do it this way. You should always do it this way.” Those things don’t apply. Each problem space has its own unique way of storing data or things that need to be surfaced to the user and you don’t always know what those are until afterwards. Sometimes, you just make the best decision that you have and you find out later that it was wrong, there’s nothing you can do.

Rob: Yeah. I would just say in general, technical debt is underrated in the startup space. I think people think that it’s not a big deal and it’s a way bigger deal than most people do because if you aren’t technical, it’s hard to understand why you can’t just quickly rewrite a piece or quickly change a decision you made later. These metaphors don’t always work but it’s akin to building a building and then needing to go back and replace the concrete foundation because you poured it incorrectly. You literally have to jack the building up and it’s just painstaking and agonizing to replace that and that’s what code is. You’re building things on top of each other.

I think of it like a 4×4 matrix where there’s basically two binary things. One is I know that this is a shortcut and I’m gonna take it anyways versus I don’t know this is a shortcut like I accidentally introduced technical debt. I think that’s the switch you’re talking about.

Then I think the other one is it’s easy to undo later versus it’s a complete fiasco to undo it. You can imagine that 4×4 matrix and we’ll go through all of those matching up but obviously any decision you make on purpose to introduce technical debt, you need to explore and thought experiment like how hard is this to undo later. If it’s hard, then don’t do it.

There were a lot of decisions Derrick and I made in the early days that were very slow, they caused Drip development to be very slow in the early days and it was pretty agonizing when we were bleeding cash and we couldn’t get the features out the door to keep people from churning because it was a very specific feature set that people wanted, and it was taking us months to build them and it was because Derrick wanted to build them very carefully with extensive unit test and he wanna do it right and he had to refactor the database twice in the first year of the app, because the app went from a very simple thing to very complicated thing.

It was agonizing but it was the right decision, because now, it would be catastrophic right now, we would probably have to have rewritten major parts of Drip. I don’t know if it would have impacted the acquisition or if it just would have been post acquisition or what it would have been but it would have been really hard and between he and I, we figured out a good sense of what was gonna be hard to change later–things that are easier to change later like you said where you can just build an interface and then swap it out later. Obviously those are the ones that you can maybe take shortcuts on.

But I think some people take shortcuts on like not running unit test, some people make cold-quality shortcuts where they just start hacking things together and later on, everything’s buggy because you took a shortcut and you didn’t build that right in the first place. In general, I have seen no less than half a dozen or maybe closer to a dozen companies get to the point where they’re between 10k and 50k MRR, they’re growing fast and they have to rewrite their entire codebase. I’ve seen some that have done it more than ones.

It is so painful to spend six months of standing still while your competition gains on you because you took shortcuts in the early days. Now, you’re just hanging out, waiting to build more features until your codebase can be completely rewritten. I would say proceed with caution, obviously, you’re always gonna have some level of technical debt, but be very deliberate about those choices because I think it’s easy to be in such a hurry to get to the point where you have more revenue and this is certainly a tradeoff because in the early, early days, when you just trying to get to $5,000 or $10,000 revenue, you’re gonna have to make some trade offs but try to take shortcuts on things that are easy to change later. That’s how I think about it.

Mike: I think one of the biggest places to make that trade off is that when you’re looking at unit tests, I’m not saying you write unit tests for everything because I certainly don’t think that that has a ton of value for a startup but I do think that there’s value in having like continuous integration server of some kind or a build system put in place so that later on you don’t have to figure out, “Okay, how am I gonna deploy my app?” You want that to be a systematic thing where you can literally just click a button and it runs through everything and is able to deploy the app.

But with that comes at least some level of unit tests or a mechanism for running those, and even if you don’t write a ton of unit tests, as bugs come in, you should be adding those unit tests to make sure that if a bug comes in and it breaks something that you had a unit test in there so that later on, as you’re making other changes, it doesn’t break that again.

Like I said, I don’t think you should write unit tests for everything, but I do think that as those bugs come in you should be writing them to make sure that once you fix a particular problem that you don’t have to refix it 3, 4, 5, 10 different times moving forward because it just keeps coming up.

Rob: Thanks for the question. I hope that was helpful.

Next question is from Jay Pablo Fernandez and he says, “I just finished going through all my newsletter subscribers and I noticed there are a few industries that are well-represented such as education, health, IT and government. When it comes to my product, they all use it in the same way. The feature set they made is pretty much the same. I wouldn’t say they are verticals in the SaaS way of thinking. I can sell to all of them or I can focus on one industry. Are there any advantages to either approach?”

Mike: I think this is a tough question, as you said you don’t wanna paint yourself into a corner and make people think that you don’t serve their industry. I think what I would do in this case sn focus on the specific problem that you solve and then maybe have different case studies for each of those industries and even segment your list a little bit so that when you talk to them, when you’re sending out newsletters or you’re sending out articles to them, maybe you’ll only send an article that highlights a case study for the electric and gas industry to those people who were subscribers that fit into that bucket. It seems to me like that would probably be an appropriate way to go, but at the same time there’s value to be had to for saying, “Hey, this also works in other industries because there’s gonna be some crossover between them.”

Let’s say that you have a case study on the nuclear power plant industry, if it’s safe enough for them to use, pure application, then whatever other industry they happen to be in, they would probably translate that and say, “Oh, well, if these guys are using it, then surely it’s passed master and I could use it as well.” I would think about it in terms of just trying to make sure that you’re covering enough of each of them but not focusing so hard on any of them that it makes people think that, “Oh, this is not for me.”

Rob: I think I might try to run an experiment. He has this list and he has these four sectors, four verticals, and I would consider trying to do physically exploratory calls, I don’t know if you wanna call it customer development or even just sales calls, if the product’s already there, across all of them, and figure out that you wanna validate your assumption that they use it in the same way with the same feature set. Because I find that a little bit hard to believe, just having run the apps that I’ve run, different industries tend to want slightly different feature sets and have a slightly to just enough it settle but by the time you really get and they start using it, it becomes a pain-in-the-butt to have four different industries or wanting something just slightly, “Oh, just tweak this one thing, oh, can I just have a setting to do this? But we have a permission in the reporting thing.” It’s just enough that there will be a difference. I guess it’s what I’m guessing.

If you have the time to do this upfront and just have a bunch of phone calls with these folks and try to do the demos and try to figure out is it truly gonna be something that they all can use, then that’s fine. But I do think you’re gonna find differences in payment terms, like you said sales cycle because government’s gonna take forever to come through, maybe in your early days since you’re trying to get ahead of funding running out or whatever, you go after the ones that close quickest, which I don’t know if that’d be IT, education, sure it seems like it’s gonna take a long time too, so focus on the one that are gonna close the quickest and get the early value in order to keep around long enough to focus on all four.

But I would try to answer that question, there’s still a question in my mind of is the product actually gonna serve all four? If that’s the case and you can work your entire list and work all four of them at once and try to get as many customers paying you on day one, then that’s what I would do. Right now, you’re just trying to get revenue and see how people use the app and if they’re gonna get value out of the app and there are across four different industries, then you’re gonna learn more about all four and maybe later you decide to focus down on one industry.

I do think that there are some advantages focusing on one industry in terms of how your marketing can really speak to people so you’re gonna close more deals probably, how you are sales conversation can focus on them, how your features set can focus, and how word of mouth would be such a big component of it. Assuming that people in your industry hang out at conferences, or hang out online, word of mouth if you just become the defacto in in the industry and in a vertical then you can land and expand words like, “Alright, we are the go-to for this task in the IT space. Now we’re gonna start adding on these other verticals.”

That’s the other way to approach it. It’s just a pick one based on your information so far, your best guess, and then later on, a year or two down the line, once you own a big chunk of this, you’ll expand into the others but I feel like you don’t have enough information to do either approach right now and I would try to close as many deals as I could, see if they actually will all use it and then try to make the decision once you have a little more information.

For our final question of the day, we have a question from Ed Freyfogle. He was a MicroConf Europe speaker this year. He says, “Hey, guys. Long time listener, first time asker. One target audience of my SaaS service is academic researchers. They are not the best customers as typically they’re low budget and they only need this service for a project or semester. Nevertheless their niche seems to like my service. Often they ask for academic discounts. My pricing is already very affordable and I offer discounts for annual purchases. Still, I can’t help but wonder if I might be able to grow this niche by offering an academic discount.

Alternatively, I have also thought about selling to universities and offering them a bulk rate. But so far I’ve always been busy with other things so I haven’t acted on this idea. I’m wondering if you guys have any advice on academic discounts in general, how to ensure they are not abused by other customers and selling to universities. Thanks for the great show, I learn a lot.”

This is a tough question. I like the fact that he’s thinking pretty strategically about it. I think that if you haven’t had the time to try to sell to the universities and offer them a bulk rate, if you haven’t made the time, it’s probably not that important. That’s where I found like this is right. It’s like you go toward the money’s coming in and your biggest fires are. I’m guessing that unless you are to hire someone to handle that that it’s not gonna make it to the top of your to-do list anytime soon.

I tend to think about discounts in two ways. There is academic and then there’s non-profit discounts. I don’t know if you have a non-profit discount as well, that’s something that I would consider modelling it after and there you just ask for proof of their non-profit status which can totally be abused. I think with DotNetInvoice we had profit one and it was maybe 1 in 20 or 1 in 30 who ask for it and show the stock seemed a little bit like, “You signed up with this just to get the discount.”

In terms of academic stuff, it depends on what volume you have coming in, it’s like if it really isn’t education it’s 1 in 50 people ask for it. You can always have an unpublished academic discount and you just need to get proof from them, I don’t know it’s a student ID or if it’s a professor ID, what it is, but it’s gonna be a process, it’s fairly lightweight. I personally don’t see a huge drawback to doing it. I’m curious when people email and ask for academic discounts and you say no, how many sales do you think you loose? Is it worth even doing any of this effort to get those sales?

Your pricing is already reasonable, if you offered another 20%, 30%, 40% off for academic discounts and that’s probably the range, I would think, although I haven’t done any research about this, but mentally it would be in that range. Is that worth it if you have to go through validation of some type of ID, I don’t know, there’s some trade offs here.

If the volume is high enough that you’re asking this question, I would probably just do an experiment where the next time I got an email about it, I would say, “Yes, we have a 25% discount, but you have to prove you’re a student or you’re faculty.” See where it goes from there and handle it as a one off to start and then I don’t know if it has support people or not, but if you distract them to do that and then tally up in a Google Spreadsheet how often it gets asked and which sales come through, you can start getting at least a little bit of data about it.

Those are my initial thoughts without a ton of experience, to back that up, it’s more of the got feel, so much of entrepreneurship is making enough as you go along. It’s just figuring out what’s the priority and making the best judgment call based on the information you have. What do you think, Mike? You have other thoughts?

Mike: I’ve looked at the academic discounts in the past. You just do a quick search for academic discounts for software and you’ll find that they can be upwards of 85% which is extremely high especially for something like a SaaS, I mean. Is the money that you’re getting even enough to offset the cost of you actually doing business for that person? I don’t know the answer to that. I think you need to figure out what that is.

Rob: Yeah. I know that Microsoft and Adobe and those guys discount because they’ve been pirated so much. Too often students who don’t have the money and they do these huge discounts. When you’re a SaaS app, especially when you’re Bootstrap like this and cash is important, there’s no chance I would offer a discount that large.

Mike: Yeah. I mean I think that part of the reason that those types of companies offer discounts that are high is one, it’s downloadable software so they don’t have to worry about their own cost, and two, they’re really just trying to make sure that there’s some form of legitimacy for the software that you’re using and giving that high of a discount helps them to get market penetration so that Microsoft has 90% market penetration on the best app for Office and Windows.

I agree, I wouldn’t go that high, but it’s not to say that you couldn’t have a discount for students versus a discount for academic researchers/the university itself. Because if somebody’s using it for a class, then they’re probably not going to be able to pay nearly as much as the person who’s doing it for the university and offering it on behalf of the class itself. I might think about that, but I do agree with Rob that you probably want to go through and run at least some tests to find out like what is it that people are using it for.

Something else to consider is that if somebody is purchasing it on behalf of the classroom because they’re teaching it, what’s the value of having those people in the class know about your product and then they leave and graduate and go out and do things in the workforce and having them know, “Hey, I can come over to opencagedata.com and buy this stuff off-the-shelf and we use it in our classroom so it has a lot of legitimacy.” There’s probably some value in that, I don’t know what that level is because I mean if you go through like an engineering degree, chances are good you’ll probably use Autocad some place along the way. When you get out into the industry like you first thought is, “Oh, I need to create some 3D models of something. Where’s the copy of Autocad?” There’s a student discount that you can get but once you get out in that at the real world, your company has to pay for it.

Having those people go to their bosses and say, “Hey, I use this data over here from opencagedata.com. We should buy a license for that.” There’s value there. I don’t know what that is but I definitely think there’s some value there. I would look into it, I don’t know how much time and effort I would spend on it because the return on that is probably gonna be wild. It’s gonna be a couple of years.

Rob: Yeah. Those are good points. I like your idea of not making an academic discount but making it a student discount. It’s an interesting thing because students really don’t have the money whereas if a university is buying it for a class, they do have some budget, and he’s right, his prices are reasonable like a university should be able to afford it.

Mike: Even with like a student. A student could probably get away with a free trial or even like the extra small plan that they have there for like a class or project or something like that but the university, if it’s for a class, and they’re buying it on behalf of the students for a class, I’ll offer them a 30% discount if you’re a student and you just want to use it for yourself, maybe it’s a 60% discount. I don’t know, but if you separate them, I think that there’s a way of targeting those people in that way that says, “Oh, we give individual students 60% and for universities we give them 30%.” It shows that you’re doing both. It shows you’re helping out on both sides.

Rob: It’s a question of whether or not the volume of incoming request warrant spending the time to figure all this out. If the answer is no, we have reasonable prices and we aren’t able to support any of these because you don’t have the bandwidth. It’s less about money and it’s more about Bootstrap startup with not a lot of time and just having yet another program to maintain and then we have to get a fax of your idea or an email with a screenshot and then check that off that it’s approved and then they just want more process that you have to wait if that’s gonna be worth it for in order to make another few discounted sales.

Mike: Thanks for the question, Ed. I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 1-888-801-96-90 or you can email 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 and we’ll see you next time.