In this episode of Startups For The Rest Of Us , Rob and Mike answer a number of listener questions on topics including SaaS pricing, subdomains, and building affordable MVP’s.
Items mentioned in this episode:
Welcome to Startups For The Rest Of Us. The podcast that helps developers, designers, and entrepreneurs to 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: And I’m Mike.
Rob: And we’re here to share out experiences to help you avoid the same mistakes we’ve made. Where this week, sir?
Mike: You remember a few weeks ago when I said I had gone unto meetup.com, and had started a Dungeons & Dragons group, and gotten a couple of people together, and started playing a campaign?
Mike: Because I’m signed up for and have a paid account now, they started emailing me about various groups, like, “Hey, you might be interested in this,” and I was told that I should join the Massachusetts cannabis marketing and sales group.
Rob: You totally should. That’s a growth market, man.
Rob: Is it legal in Massachusetts?
Mike: It is. Although I don’t think anybody’s licensed to actually sell it yet, that happened two years ago, they said, “Yes, this is now legal in Massachusetts for recreational use.” but they still had to go through all these regulatory hurdles, and people had to get certified, and all these other stuff. They’re like, “Yes, you can use it recreationally, but nobody can sell it to you.” that was the situation for a couple of years, I think that they’re supposedly sometime this summer, starting to do that but I don’t know. Maybe the deadline has already passed. I don’t know.
Rob: Because I was back in California, I think it was when I was at SaaStr, so it was probably, February or March of this year, and it’s legal there. It’s been medically legal for years, so they already have the dispensaries, and they legalized it. I think it was maybe, less than a year later, they were allowed to sell it for recreational use.
I was walking around at night with some friends from the conference, co-workers, there was a lot of pot smoke that you could smell, and it was like, “Oh, yeah.” Of course, I was looking around like, “Oh man, they can’t be doing that, right?” it’s just this sense you get when you smell that. But it’s like, “No, no. It’s just legal, and you can do it on the corner.” It’s such a trip, such a trip. It’s going to be weird to get used to. The way it’s going, it’s going to be legal in all 50 States, eventually. It’ll be an interesting thing to adjust to.
Mike: Yeah. Definitely can be interesting. I just found it funny that they’re like, “Oh, you should join this group.”
Rob: Totally. They know who you are, Mike, deep down.
Mike: I guess, maybe. I don’t know. How about you?
Rob: I’ve been doing some smart home stuff which is something I’ve been interested in for years. But since we had a rental for the past couple of years, obviously, I wasn’t going to put a bunch of stuff in a rental. I now have several Alexas—oops, I just activated.
Mike: We should leave this in. This is good radio.
Rob: Yeah, I have several Echos in the house. I need to, not say A-L-E-X-A. I’m enjoying them. I’m enjoying that you can use them as intercoms because our house has a lot of stairs. There’s three or four stories—depending on how you count.
Mike: I found out about that the other day that you could use it as an intercom. I didn’t know that you could do that. You can just drop into some other room in the house. Although I was told there’s a—not a security loophole or something like that—but something associated with it where you have to disable it by default. Otherwise, if somebody in your contact list, they know you have one, they can drop into your living room and just talk to you through the intercom, I think over the internet, and I didn’t know that.
Rob: Oh, interesting.
Mike: Yeah. It doesn’t sound good.
Rob: Yeah. I enjoyed doing it most from the Echo app on my phone. You can just click a couple of times, and then boom, you’re just speaking out of one of the Amazon Echos. Our kids’ playroom is way downstairs, and it’s easier than running down and telling them dinner is ready. It’s pretty nice.
I’ve definitely bought into the Echo ecosystem, and I like their direction that’s going. I got a Nest for the first time. I tried installing Nest at our old house, but it wasn’t compatible. I have a Nest here, and I can now control that of course with the app, and it’s smart thermostat, and that’s fun. You can even tell the Echo to adjust the temperature, I believe. I haven’t activated that yet.
We moved into this house, it’s in the Midwest, it was built right around 2000, and they wired the whole thing for in-home speakers. There’s speakers in almost every room. There’s this big central places where he had a receiver, a tuner, CD player, and all this stuff. I’m thinking, in the 90s, that’s what I would have done. When in college, I would love big speakers from dorm room to dorm room, as I moved around or apartment to apartment, and you had your receiver, you had your amp and all that stuff.
Now I went online, and I was like, “There’s got to be an easier way here. I want to be able to stream everything.” I researched it, and of course, Sonos is the leader in that space. While I don’t love how proprietary Sonos is, even down to the fact that I can’t just stream from Spotify through my Sonos but I believe that you have to use the Sonos app, and you […] it into your Spotify account like, “I don’t want to use the Sonos app.”
Mike: Oh, geez.
Rob: I know. I know. I need to double-check that because they may have opened it up, but last time I looked, you weren’t able to kind of just airplay it–the equivalent of that through the Sonos thing. But anyway, they have this thing called, Sonos Connect: Amp. The Amp part means it has an amp in it that you can connect to speakers. I just got one, just as an experiment. I put in on the first floor, and sure enough, it takes the place of all of this equipment he had, the speaker wires go in the back, and there’s volume knobs on every wall in the house.
I was going to bail on it altogether and just not do it. But Sherri’s like, “No, no, no. If we have people over, there’d be multiple…” because you can do multiple floors, and there’s all this stuff. All that to say, I reluctantly implemented Sonos in this smart home thing, but man, it’s cool. You can tell your Echo to start this on Spotify on the Sonos, and it will do it, and you go to the wall and turn it up. It’s magical, man. It’s pretty interesting. It feels like we’re living in the future.
Mike: That’s pretty cool. I bought a new amplifier maybe two or three years ago because my old one was 12, 15 years old. Actually, it was more than that. It’s probably close to 20. It still works great. It’s just that it didn’t have any of the connections. It didn’t have an HDMI connection. It still had all the component outputs or inputs and everything else. I couldn’t hook it up to any new equipment that I had, like a Blu-ray player and stuff like that. I was like, “Alright, fine.” I brought it down, and I bought a new amp.
I was looking at all the different options, and it seemed to me like a lot of that type of equipment, is very much like car technology where they’ll build something into it like Spotify or something like that, and it’s obsolete almost the second you buy it. They’re terribly useful. It sucks that it feels like that type of technology is still on that trend, where everything is proprietary, and it’s so hard to connect stuff, and it’s expensive too, but at the same time, it doesn’t really wear out. I still got speakers that were almost 20 years old, and they’re still in great working condition. I don’t really have any need to buy new ones, except for the fact that if something breaks. That’s it.
Rob: Yeah, that makes sense. I agree. I was concerned when I bought this Sonos. I had to research it because I was, “Do they even support speaker outputs anymore? There’s exterior speakers in the patios, is it going to drive those? Is it going to connect to all the stuff?” Sure enough on the back, it looked like it had the right ports and it wound up doing it. They’re called banana clips.
I agree. Trying to interface this newfangled technology with stuff that has existed for 30, 40 years, maybe even longer. I remember twisting speaker wires together. I had four speakers in my dorm room. Certainly, it was quadraphonic, it was a stereo, but I would twist them together, ran them into the amp, and do all the stuff, and that technology is now having to interface with, like you said, this Spotify stuff.
I did evaluate not doing Sonos. There are, obviously, other brands that have streaming music devices that have amps built-in, but they just all seem, like you said, bolted on, and antiquated. I don’t know. It’s interesting to see how this is going to shake out. I’m interested to see how it’s going to shake out over the next few years.
Obviously, I’m investing in ecosystems now. I’ve been on the Alexa ecosystem now. I’m in obviously now, on the Sonos a little bit. I think I’m probably going to have to get at least one more […] perhaps too because there’s different zones and stuff. But I’m trying to pick market leaders because I don’t want to buy the Betamax, and suddenly have to bail on it because they just killed the line or whatever.
Mike: Well, that just means you’ll have to find the one that is selling porn with it, that will be the winner.
Rob: I do think, I might need to stand corrected because I opened Spotify while we were talking, and it does look like I can just connect to the Sonos downstairs, and just stream it through there instead of using their app. I’ll test that later to prove it out. I know for a while they didn’t do that. But if it does it now, they must have added it in the past whatever, six months or something.
Mike: It seems to me, for that type of technology, anything that comes to streaming, you just want something where you can connect to it with Bluetooth or something like that, or with even just a cable, and then from there, it just acts as a dummy piece of equipment that just does its thing, and that’s its sole purpose is, and then you plug other stuff into it. It seems most people would really just want to do that.
My wife used to work at an electronic house, and they had all these high-end stereo systems going up to $100,000-$150,000. Don’t get wrong, they were beautiful, but the reality is you’re going to spend that much money on a stereo system for some downstairs place. Their target market was people who had nothing better to do with their money. Sure, that makes sense, but I think for the average user, it doesn’t matter that much.
Rob: Yeah, that’s the thing. Like you sad, I wouldn’t want to use a cable because the Sonos is in a cabinet set away but Bluetooth or I believe it’s just via wifi because it connects to wifi obviously, and it had its own identity. Once I […] it connects over that. I’m not Bluetooth-connected to Sonos at all. The phone just know where it is.
Rob: With that, should we do a whole episode?
Mike: We could talk about all the different problems of those too. There was some kid’s device that was out there that connected into the WiFi, but it also would record pretty much anything, and it would send it back to the servers to the company that made it, it wasn’t encrypted, and it was using it to do voice recognition. They were basically collecting voice data from kids. It was like, “Oh boy. That’s not good,” and it’s all not encrypted either. That’s a big problem.
Rob: Yeah. That’s the thing too. The IoT is the term for this—Internet of Things. Everything is going to be on the internet at some point, is what they’re saying. The IoT devices are much like the Nest and the Sonos and even smart toasters, smart microwaves, smart fridges, and all the stuff that’s supposed to be coming.
That stuff is said to be a hacker’s dream. Most of it, it’s super insecure. Some of it, if it doesn’t get patched, then it’s easy to hack. Even a lot of it that is patched is easy to hack into. They’re saying that’s the coming wave of hacks. That’s going to be the zombie nets of the future. Because that’s how folks do DDoSes—they go out, and they take control of a bunch of old PCs that are unpatched, and then they do attacks, distributed denial-of-service, from all those things. They’re saying that the Internet of Things is going to be tenfold or a hundredfold the number of devices. It’s going to have that much power.
Mike: Yeah. I shudder for people who have to deal with those types of problems.
Rob: Seriously, yup. Cool. Let’s dive in. We have some listener questions. We have some comments on some prior episodes. Our first comment is on episode 403 which was titled, Should You Love What You’re Working On? and it’s from Martin. He just came to startupsfortherestofus.com and entered a comment at the bottom of episode 403’s blog post.
He said, “Hi, Rob and Mike. Thanks for another great episode. When you guys talked about love versus opportunity, I was reminded of the idea that it can take hard work to cultivate a passion. If I remember correctly, Cal Newport talks about this idea in one of his books. I don’t know about you guys, but I’ve noticed that there are a lot of things where you need to put in the work first before you start to enjoy them. I’m currently working as a software consultant, and I remembered that the reason I picked up programming in the first place was because as a kid, I was into video games. Now many years later, I really enjoyed developing software, often more than playing games. I think that’s true of many things. For example, when you’re just starting with any kind of sport, and you suck at it, it’s often not that great, but once you put some effort into it and you start to improve, you suddenly get why people enjoyed doing it.”
I think Martin has a good point. Thanks for posting, Martin. This is how I felt about playing music–playing the guitar. When I first started it, it was really hard, and then definitely the better I got, the more I wanted to play my guitar. What do you think about this?
Mike: I remember reading about this. I think that Josh Kaufman wrote a book about learning different things. I’m pretty sure he had a graph in there that showed that. There’s a skill level versus enjoyment. When you first start doing something new, you suck at it which is to be expected, but you don’t enjoy it at all. Then once you get a little skilled at it, then you really start to enjoy it because you feel you know what you’re doing, so you’re on the cusp of always learning this new stuff, but you’re also enjoying the journey. Once you get much more advanced, then it’s about putting the time and effort to practice, and get the muscle memory or the mental connections made so you don’t have to really think about it when you’re doing it. Pretty sure it was Josh’s book that—I can’t remember the name of the book off the top of my head—but I think that that was in there.
Rob: It’s called The First 20 Hours: How to Learn Anything Fast.
Mike: Yes, that was it. Yup. It’s a fascinating read, too. If you are interested in learning new things and the process of learning new things, I’d definitely recommend picking up that book and checking it out. He goes through several different things that he learned, like the ukulele, sailboarding, and a couple of other things. It’s just fascinating how he learned about how to learn stuff.
I always had a problem with that when I was in college. When I got to college, I just authorized, “Go ahead,” relied on my natural ability to just remember things, pay attention in class, and then do well on tests. When I get to college, you have to do the homework. That was always a problem for me in college, but it worked itself out eventually, but it took years for that to happen.
Rob: Yup. For sure, I felt the same thing. The First 20 Hours by Josh Kaufman. It’s also on audible which is I believe how I read that book. Thanks for the comment, Martin. Our first question of the day is from Michael Needle. He’s from alltheguides.com. He says, “Mike and Rob, first, thanks for all you do. I previously called in about building a marketplace, alltheguides.com, to connect adventure travelers and guides. I’m close to finishing the platform, and I took your advice on building one segment first. I went with guides to have providers ready when clients come,” which is the way I believe we should have recommended that you do. It’s a two-sided marketplace, and we said when you start with two-side marketplace you have to get that one side done first.
Now back to his email. “Now ahead of the platform launch, I want to make sure I can bring the clients to the site, the customers, the consumers. I thought I’d follow your advice by starting an informative blog in order to get emails.” Adventure Travel Ideas, I think is the idea of the blog. Here’s the question. “I already have a landing page up from my platform. I assume it would be better to have the lead gen on a different domain as opposed to a subdomain. I just assume that subdomains will be less likely to draw initial visitors. Am I wrong on this? Or if I’m right, and I should go with a different domain, what is the best way to nudge my list towards the platform once it’s launched? Thanks again, guys. You provide invaluable advice and inspiration.” What do you think, Mike?
Mike: I think there’s a natural inclination to believe that you should put your landing page and stuff like that on some sort of a subdomain and that’s how you’re driving traffic to them. But the reality is, I think is that if you’re doing tour guides in a marketplace like this, I don’t think people necessarily really care about the subdomain. I think what really comes into it with the subdomain is that you’re trying to establish new website according to Google, and do all the SEO, and the site ranking, and get that up based on how Google looks at it.
You could instead focus that energy on a subdirectory in your main domain and use that to essentially focus your efforts and increase the authority of that domain versus trying to do it with one subdomain and then another— that’s probably the approach that I would go with. I guess there’s a few different examples I would point to like Craigslist, Angie’s List, and Reddit. Reddit’s got all those different subReddits and stuff in it, but they’re all under, most of them in different subdirectories.
Rob: The reddits? Yup. It’s reddit.com/r/whatever, /startups or whatever.
Mike: Right and that’s not necessarily a two-sided market, but Craiglist is. Based on the location, they will have subdirectories, which are a geographic location, but I wouldn’t worry too much about the subdirectories, at the moment. I guess I’m curious to know whether or not you’re trying to use those subdomains as like the location, like city name, or something like that. Maybe it would make more sense in that case, but at the same time, you could also just use it like it as a different subdirectory as well, and you’ll benefit, for the site authority, through that.
Rob: That’s the thing, and now Google has come out and said, “Oh, subdomain, subdirectory, there’s no difference.” I still think there’s some difference. I still believe, deep down, that subdirectory is better for SEO. I do like your point there. I think if you are going to start a blog, I would try to do it in subdomain, if possible. It’s not always possible to do that. You might need to do reverse-proxy and do some things if you’re running WordPress because you don’t tend to want to run WordPress on a production app server. When I say don’t tend to want to, I mean don’t do it. There’s just too many security holes.
If you want to host it somewhere, I’d go with somebody like the VPNGINE or Pagely or whatever. I think I may have misspoken earlier and said subdomain, but what I mean was subdirectory, if you can do a subdirectory, that’s what I would do.
I don’t think this matters actually, that much. When using a different domain for the lead gen, I would probably lean towards subdirectory, and if you need to use a subdomain, I don’t know—its just apples and oranges, this is small stuff. If you’re going to drive ads to it, it doesn’t matter, nobody cares, they’ll just click on the ad, and they’d go see it. If you’re going to try for SEO then like Mike and I were saying, I would lean towards subdirectory, if possible, I think it’s pretty clean, but in all cases, I don’t know that it matters that much.
Mike: Yeah. The one really nice thing about having everything underneath the same domains—and you’re not dealing with subdomains—is redirecting people back and forth, and then also dealing with the fact that, like any tracking analytics where you’re trying to track like, “Did somebody hit this subdomain and then this other subdomain?” and then you got cookies back and forth between them. With marketing tools, it becomes an absolute nightmare.
You’re much better off just having it all on one domain and then you don’t have to worry about that because the cookies are going to be able to work all on that domain between different directories, versus, like a Google Analytics tracking code. Something as simple as that is going to be an absolute nightmare to work across multiple domains.
Rob: Yeah, and it’s possible, you just got to know how to do it. It’s not out-of-the-box trivial. Sharing cookies is a pain, and then you’ll get the, “Hey, this person came from one of your domains to the other, and they show up as a new visitor.” It’s not ideal. Anyway, I hope that helps.
Our next question is from long-time listeners and friends of ours. Folks that we’ve known that have come to MicroConfs–Dan Taylor and Simon Payne. Dan Taylor runs appsevents.com, which is an events company that runs more than 300 annuals events. Simon Payne was the co-founder of Lead Pages. They both live in Prague, actually, in Czech Republic. Simon was working on an app with Dan Taylor, and Simon has also launched a WordPress button called Convert Player. That’s pretty cool.
Anyway, they wrote in. They said, “Hi, Rob and Mike. Two long-time listeners here, Dan and Simon. We’ve developed and released a SaaS app called EventsFrame. It’s eventsframe.com. It’s ticketing and attendee management system, with fixed low monthly pricing for unlimited events and unlimited attendees. We’ve moved all of my company, AppsEvents more than 300 annual events to this, and done a full public launch last month. We already have paid sign-ups from our listings on sites like Capterra, some content marketing, and some basic Facebook ads, which have converted this in paying customers, which is a good sign. We’re doing an AppSumo launch in a couple of weeks to get a bunch of users on this system, which is taking a lot of our focus, but we’re planning for how we grow this long-term, as Simon and I are focusing all our time on this project.”
“Our question is on pricing. As you know, systems like Eventbrite take a percentage of ticket price, and most systems follow a similar model. With AppsEvents, I was spending thousands of dollars a year on Eventbrite fees. We want to go for a fixed price for unlimited events and attendees. Our initial idea is $97 a month. Now the issue with this is that people running one several small events might prefer a percentage of ticket price, as there is no upfront cost. And on the other end, large event producers would pay a lot more than $97 a month,” or I think he’s saying they should pay a lot more than that cost they’re getting more value. “We guess some pricing tiers could be good. But any ideas to help with our process would be greatly appreciated. All the best, Dan and Simon.” What do you think?
Mike: This is something that I actually looked into pretty heavily and struggled with several years ago. Back when I was running AuditShark, one of the ideas that I had come up with was, ironically, Bluetick, because I was doing a lot of outreach to people and I just needed to follow-up with them and keep on them. But also, as a side note, I was also helping out on the sponsorships side for MicroConf. For that particular problem, I found that I had to do the same thing.
I said, “Oh if I had this product or tool in place that would allow me to do that outreach as an event organizer that would help me out a lot.” I looked around. A bunch of different things didn’t really work very well for what my use case was. I said, “Well, could I build this? Is this something that I could basically move away from AuditShark?” because at the time, it wasn’t really on the best path, and I recognized that at the time.
Anyway, I looked into specifics of whether or not I could target event organizers with that. What I realized was that there’s a wide range of types of event organizers. Some of them, that’s all they do, they organize events like the AppsEvents company. They will organize hundreds of events every single year, and then there’s ones like MicroConf where we do it a couple of times a year, and that’s it.
For ones like that, a monthly pricing model really doesn’t work well because of the fact that you’re only running a couple of events. If you’re doing it on a regular basis, sure, it makes a lot more sense. But as you pointed out, it makes a lot more sense to just do with a percentage of the ticket price for those types of customers.
The other thing I would look at is, Eventbrite, yes, they do charge a percentage of the ticket, but they also give the event organizers the ability to pass that cost onto the attendees. That’s actually what we do with MicroConf. It’s only a couple of percent, but at the same time, it raises the ticket price by that amount. The question you have to ask is, “Well, as the event organizer, is that something that’s going to turn away people? Are they going to, not buy a ticket because they have to pay that extra fee?” That’s again, for the event coordinator to decide. But your problem is, how are you charging?
For us, Eventbrite is I’ll say, “free” and that we’re passing those cost on, and then on the other side, we’re paying the cost of the payment processing, which we would have to pay, regardless. Whether Eventbrite handles it or we do it through PayPal or Stripe or whoever, that fee has to be paid. But our payment to Eventbrite is basically, covered by the attendees buying those tickets, which make it free for us, which makes it a lot more attractive than a $97 a month plan or even a $50 a month plan. Coupled with the fact that, we also don’t run more than a couple of events a year. Why should we be paying for that over the course of the entire year if we’re only running events in a certain time window, I’ll say?
That’s exactly the problem that I ran into when I was trying to identify, “Well, how can I build this email follow-up product aimed at event organizers?” Event organizers, if they run a lot of events, awesome. They’re a good target. But if they don’t, then having them pay a monthly fee is not going to work.
Rob: Yeah. Basically, what Dan and Simon are talking about doing is doing pricing innovation in the events space. While I think it certainly saved Dan money from a customer perspective—he was paying Eventbrite thousands a year—I’m not sure it makes sense to do this from a business perspective.
There’s a reason that most of these events software companies charge the way they do. The reason, as you’ve laid it out, if your event is free, you don’t pay EventBrite anything. If you only sell 20 tickets, and they’re $5 each, then I believe you pay Eventbrite 2.5% of that. If they do the processing, they charge you 3% fee, payment processing fee or we use PayPal, and obviously, it’s whatever it is, 2.9% or 3% there.
Or, if you sell $100,000 worth of tickets in a year, then yeah, you do pay $2500, so I get the […] Eventbrite. It makes sense from a customer perspective of being like, “Man, I’m paying EventBrite so much money,” but now that you’re on the other side of it, and you’re running a business, my thought is like, “Yes, that’s how you want it. You want it so that the people who are getting a little bit of value out of this system aren’t paying that much for it and it scales up perfectly linearly with how they do it.”
If you sell $100,000 for the tickets, you’re probably making a chunk of money. We can argue about whether $2500 is too much money, but you definitely are getting quite a bit of value out of the system if you’re selling $100,000 worth.
Trying to do pricing innovation is a challenge. Is it business model canvas? That something that if you read that book, do you remember the book?
Mike: Yeah, I remember it. There was a whole worksheet that went with it.
Rob: Yup and that talks a lot about trying to do pricing innovation. I don’t know if it has practical enough tips to help you sort this out. But I will say that I tried to innovate on pricing in the early days of Drip, and instead of doing per subscriber just like MailChimp and everybody else is doing, I tried to do new subscribers per month, and it was a bad idea. Not only did they confuse people, but as we started to scale up, we were not growing nearly as fast as we should have.
That’s the thing that you’re going to run into is you’re going to have people who come and are selling half a million dollars’ worth of tickets on your system and they’re going to be paying $97 or even if you do tiers, it’s not going to be that much. They’re not going to be paying you 2.5% of $500,000.
I think since people are used to this, and it is a lucrative model. If anything, you could try to be the low-cost provider which I don’t think is a terrible idea in this space. I don’t know enough about the whole space. I know that EventBrite, yes, it does feel expensive to a lot of people, and it’s clunky, so you have those two things. They have a ton of features, but they’re a little more expensive than everybody wants them to be, and they’re arguably quite a bit harder to use, although they have a lot of features.
This is like going after a QuickBooks or InfusionSoft or Marketo—kind of going after that. If you make your software infinitely usable and slightly less expensive, but you still keep the same model, maybe only try 2.5%, I don’t know. I know you have other bootstrap competitors around you, look at what they’re doing. That’s probably where I would start is doing just a big survey of all the pricing structures of all the events SaaS apps, and mapping that out on a big sheet of paper or mind map or something, and trying to think that through.
I think in the end, you are going to want to be a percentage of revenue is my guess, because otherwise, you’re going to constantly have this problem. Try to think if there’s any way around it with tiers, try to think creatively. It’s like you could have a free tier or you can’t charge for events, and then you could have your $50 a month tier where you go to a certain amount of ticket sales. In essence, you’re taking a percentage, but you’re not, you’re just having tiers of it. That would maybe be the only other thing that I would consider. But man, just taking 1.5%, 2.5%, it’s so clean. It makes your pricing look so clean. It’s simple, and everybody understands that.
Mike: I think the problem that you just alluded to is that, depending on the size of the event that you’re dealing with, if it’s 5 or 10 people, you might have one price tier, and then if it’s 50, you could have another. Whether or not you deal with those, like what’s the price point of those? If it’s $25,000, but they only allow five people in it, is it a free account? Depending on the value that you’re providing to them, that’s really what you’re pricing should be based on.
I think you almost get into this territory of, you have an unlimited number of pricing tiers because how high could those ticket prices go or what is it that you actually basing it on? Is it the number of attendees or is it ticket price? Or is it a combination of the two? Once you get into that territory, it gets overly complicated, and people don’t want to deal with it because they’re like, “This pricing model is too confusing for me. I feel like I’m going to get screwed, so I’m going with the competitor because I understand it.”
Rob: Thanks for the question, Dan and Simon. I hope that was helpful and I definitely wish you guys the best of luck with EventsFrame.
Our next question is from Alex, and he says, “Hi again. Thanks for all the great content. I feel like I’m in a bit of a dilemma. I have an idea that I would like to turn into a business. It’s for a job site. I have the requirements, more or less hammered out to the point I can have a developer build it. I’ve recently been in the process of getting quotes from various companies, and freelancers to build it but I’m hesitant to make this jump. Aside from the inherent risk of it just failing, I’m concerned I will spend all my money on the MVP then quickly run out of money to fund any iterations on the site. I don’t know anyone willing to help me build this for free, and I also don’t know the first thing about raising money or how to prepare for that. I guess my question is, how would you approach building an MVP in the most affordable way?”
One thing I’ll throw out before you dive in Mike is, you’ll not be able to raise money, maybe from family and friends, but you’re not going to be able to raise money without a working app these days. It’s just kind of table stakes. Although he asked us, “How would you approach building an MVP is the most affordable way?” I don’t know that’s a question we should answer. I think the question we should answer is, how do you validate this more before building an MVP. Would you agree?
Mike: Yeah, I would agree. That’s the next step is like, what is the MVP? What question are you trying to answer? The question I think you’re trying to answer is, “How do I know if I should dump this money into this type of product?” I think the answer to that is the same thing that I did with Bluetick. Go to balsamiq.com, and buy a copy of Balsamiq for $80, and mock everything up. Then go try, and sell that to people, and see if people are actually interested in buying what it is that you have.
That will do a couple of different things for you. One is, it will help you find the types of people that you need to talk to, and the second thing it will do is, it’ll give you enough information to say like, “Is this something that people would actually pay for?” and that’s the answer to your question is, if you can get enough people and find the market for it and tap into a channel of people to talk to, to get them excited about it, and find out if they’re going to pay for it, then sure, go for it.
But if you can’t get past that part, if you can’t find the people to talk to, it’s never going to work. You’re just not going to be able to turn it into a working product, regardless whether you have code written or not. That’s not the problem. The problem is trying to find those customers and make sure they are willing to pay for it. There’s obvious concerns here about, Alex’s voice about, “I’m concerned about making the jump because of the risk of it failing,” and that’s how you make sure that it’s not going to fail.
Rob: Yup, I would agree with that. I think the question you need to ask yourself is, “How can you validate this before dumping a bunch of money into it and doing as much of that as possible?” Sometimes, an MVP is not even software. We’ve talked about this in the past. An MVP might be you with an Excel spreadsheet or a Google spreadsheet. It might be you manually writing things, taking in a list of keyword someone gives you, manually running an algorithm on them in Excel, and then giving back the keywords they’re most likely to rank for. That is basically what I would have done if I had built an MVP for HitTail, as an example, or any keyword tool.
There are ways to do it without needing to hire anyone to write a line of code. My second book, which is a collection of essays, is called Start Marketing The Day You Start Coding, but now, I think it’s Start Marketing Or At Least Validating Well Before You Start Coding. With Drip, I had 11 people who said that they would pay $99 a month for what we were going to build before we broke ground on code. I wanted 10, happened to get 11, then Derrick started writing code.
I know for Bluetick you got pre-orders. There is a lot of hustle that can happen up front. It’s hard work. This is the stuff that, “Well, is anyone going to trust me? Who am I? Is anyone going to trust me if I don’t have the software after the software ?” No, that’s an excuse. Yes, it would be better if you had all the software, and could just start marketing it. But that’s not the case.
I think your concern is valid, that going out and building an MVP, it’s very, very unlikely that’s going to have product fit, so you’re going to have to iterate. If you don’t have the money or the time or the skills to iterate on that, then you need to figure out how to get to the point where you feel more confident.
Here’s the thing. If you try to recruit a developer to build it for free—we’ve talked about this in the past—nope, no developer is going to want to do that. If you go to a developer and you say, “Hey, I built all these mockups, I have 25 phone calls, and I got 10 pre-orders, they paid for a quarter, three months of service, and they’ve all committed to—assuming it works and does what I say—it’s going to be $50 or $100 a month after that, boom, we’re going to be at $1000 MRR,” yes, that’s a lot of hustle, and it’s a lot of work, but that’s how you recruit a co-founder or at least a developer who is willing to build it maybe for an equity share or something like that.
I like the way you’re thinking about it. I’m glad you’re hesitant to just dive into the MVP, but I don’t think you should look at building an MVP as software in the most affordable way. I think you should look at, not automating them, doing stuff manually, and think of, “How can I possibly validate this?” The first step is going to be customer conversations, then it’s going to be trying to get pre-orders, then it’s going to be doing it manually until the software’s built, then it’s building a crappy software MVP, and then it’s doing a better job. I bet there’s a lot of steps between where you are today and basically, paying someone to build a complete SaaS app.
Mike: I think part of it just stems from the classic misunderstanding of what an MVP is because MVP has the word Product in it, and that’s not really what it means. I talked about this in my book, Single Founder Handbook, and I quote Wikipedia from […]. It says, “An MVP is not a minimal product. It is a strategy and process directed toward making and selling a product to customers.” What you have to understand there is that it explicitly calls out an MVP as a process, not as a product. Building a product is not your MVP; answering a question is what your MVP is. The first thing that you have to start with is, “What is my question?” and here it’s, “How do I know that I need to pay people to develop software?” It’s all the stuff before that that Rob just talked about, like talk to customers, find out what they really want, and whether they’re going to pay for it, that’s all the stuff that you need to do..
Thanks for the question, Alex. I hope that was really helpful. I think that about wraps us up for the day. If you have a question for us, you can email it to email@example.com, or you can send us a voicemail by calling 1-888-801-9690. 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.
In this episode of Startups For The Rest Of Us, Rob and Mike take a group of listener questions including Per User Pricing for SaaS, Drip Email Sequences for Freemium, and SaaS Subscription vs. Commission Pricing.
Items mentioned in this episode:
Rob [00:00:00]: In this episode of “Startups for the Rest of Us,” Mike and I discuss per-user pricing for SaaS apps, Drip email sequences for Freemium and SaaS subscription versus commission pricing. This is “Startups for the Rest of Us,” episode 263.
Rob [00:00:21]: “Welcome to Startups for the Rest of Us,” the podcast that helps developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product or you’re just thinking about it. I’m Rob.
Mike [00:00:30]: And I’m Mike.
Rob [00:00:30]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. So, where you this week, sir?
Rob [00:01:13]: Yeah, and so far, so good with Discourse, huh? I mean it seems to be a pretty good platform. We had looked at it – was it two and-a-half years ago when we moved from basically WordPress forms over to our current platform, which is Communifire? I think it was –
Mike [00:01:25]: Yeah, it was about that.
Rob [00:01:26]: – a while ago.
Mike [00:01:26]: Yeah, it was –
Rob [00:01:27]: At the time, Discourse was, like – I don’t know – an alpha or something, because it was pretty early-stage. But we had our eye on it, and we actually looked at it at that point, and our experience with Communifire has been mixed, and it isn’t exactly meeting the needs of what we want to do. So, we feel like moving over to Discourse is a good choice. A lot of people are familiar with it, and the usability is really good, right? Jeff Howard has done a good job making really usable forms.
Mike [00:01:50]: Yeah, so definitely looking forward to that. Hopefully, we’ll be done by the end of the month.
Rob [00:01:53]: Awesome.
Mike [00:01:54]: What about you?
Rob [00:01:54]: Well, we have two job openings right now with Drip. If you’re a content marketer and you want to help us with the blog and help crank out content – it’s not just about writing, but it’s about promotion and all that stuff – definitely get in touch with me. I’m hiring in the next couple weeks, soon as I find someone. It’s pretty much, I would say, anywhere in the world. Ideally, it’s within three hours of Pacific time zone either way, but we’re looking for someone with experience. You can email me directly, or hit the Start Ups for the Rest of Us site and contact me through there. The other thing we’re looking for is someone with a lot of UX experience, like a mid-level to senior UX person. Some Rails experience would be ideal, but we can work. If you know Python or know some type of service ad language, even if you’re not an expert, what we really need is heavy UX experience.
[00:02:39] So, things are growing and moving, and I think we’re going to probably have some more job openings here in the next few months as well.
Mike [00:02:45]: Very cool. So, what are we talking about this week?
Rob [00:02:47]: Well, we’re going to answer a group of listener questions. They continue to stack up, and we have some pretty good ones related to SaaS – pricing and development platforms and stuff like that. So, let’s dive into our first one. This first question is from Vincent Pruyer [phonetic], and he’s from wearewizards.io. He says, “Hey, guys. Thanks for the podcast. Lots of interesting stuff every week. We currently have a side project. It’s a password manager called ‘Passopolis.com.’ It was originally from another company, and then they open-sourced it when they shut down, and we’re currently running it for free and thinking about how we can monetize it. Our main competitor is LastPass, and it’s around $24 per user per year, and this kind of pricing only seems sustainable once you get to 100,000 users because the pricing is so low. If we decide to monetize it, we’d need to invest in design and do some other stuff.”
[00:03:34] To summarize Vincent’s question, he’s wondering if they should do this low per-user pricing, if they could compete at that – looking at, like, 10 to 12 British pounds per user per year – or, doing tiers, where it’s like one to five users is 30 pounds a year and six to ten is 100 pounds. But, really, his question is, “Should we just keep running it for free and not try to actually monetize this? Or, do you see a way to make this work?”
Mike [00:03:57]: Well, I think this is a pretty hard question to answer. One of the things that I see here is that it’s definitely aimed at the consumer market, or at least it feels that way; because in order to monetize it, especially if you’re going to try and compete against LastPass, the pricing on LastPass is just so low that you’re going to need a ton of users in order to be able to make ends meet. You could run it as a side project, but that’s probably all it’s ever going to be; and your number of users still has to be very, very high in order for it to just work, in general, for you.
[00:04:26] I think that it’d probably make a little bit more sense to look at other ways that you can solve similar, but related, problems using the same type of technology and possibly target businesses instead. So, if you’re looking, for example, at – your main competitor’s LastPass at this point. I think I might try and compete against something like Passpack, where you are instead selling it to teams of people and specifically at teams of, let’s say, five people or more and then charge those people on a monthly basis and give them team management of accounts. You could use that in situations where you have a bunch of people who are working together, and they need shared credentials to different machines, for example; or, to different websites for a variety of different reasons. But I think that competing head-to-head against LastPass is probably not the wisest choice in this situation.
Rob [00:05:12]: Because you’re not just competing against LastPass. There’s one password and a bazillion other of these password managers; and trying to make money, if you’re bootstrapping, charging $10 or, I guess in this case, 10 pounds sterling per year is insane. I mean the price points just aren’t there, and as Vincent pointed out, you need 10,000 paying users to make $100,000 a year; and just trying to find 10,000 users, unless you have just this enormous funnel and enormous channel of people using it now, there’s just no way you’re going to get there. You don’t have the team. You don’t have the traffic sources to get that many people.
[00:05:48] The worst thing I think you could do is to try out that pricing and get 100 or 500 paying customers. The problem with that is once you’ve done that, now you kind of owe them something. They’ve paid for a year, and you’re stuck to supporting them, and you really haven’t made much money. If you got 10,000 customers, that’d be great. If you have zero paying customers, then you’re home free; but once you make this leap into this really cheap pricing and you have to support these people for a year, and you’ve only made hundreds or a few thousand bucks, it’s not going to be worth it.
[00:06:15] I agree with Mike. There’s no way I would try to compete directly with LastPass on this. They’re just so far ahead. Unless you have a major differentiator, that’s where I would look for – is the competitive advantage you have is that, since it’s open source, I imagine you have some type of user base. Well, what is that user base contributing or asking to be built that’s different than LastPass that would allow you, in one sentence or one headline, to describe how we are the opposite of LastPass, how we’re way better, or way different.
[00:06:40]: You look at how Gabriel Weinberg is competing with Google. He has DuckDuckGo as a search engine, and he’s been on the podcast a couple times, I think, now. He didn’t do it by trying to compete head-to-head with Google. He figured out “how can I be different than Google in a way that I can sum up in one sentence?” And, typically, he uses the phrase, “Google tracks you. We don’t.” Right? It’s about privacy and tracking. Now, there’s also some other points: where they’re only going to have one ad at the top. They do some other stuff, but that’s been his big focus, and that’s the only way he’s competing with Google. It’s not by trying to be better than Google, or cheaper than Google, or faster than Google; because you can’t out-Google them.
[00:07:13] I think the same goes with LastPass. They’re just too big. You can’t out-LastPass LastPass. Figure out a major differentiator, whether it’s what Mike said, where you’re actually pivoting into another space; or, that you just pick a niche and you are the best password manager for web designers, or whatever. Maybe you add something that allows them to share with their clients, that no one else does, then you have a real differentiator. Then you don’t charge 10 pounds per year. That’s when you charge 50 or 100, or you charge monthly because you are so much better for that small group of people, that it’s warranted and they’re willing to pay for it. I hope that helps, Vincent.
[00:07:46] Our next question is from Chris Sciora [phonetic]. He’s from gomobileiq.com. and he says, “Hey, guys. It sounds like both of you started with a handful of different languages in the past. Maybe C# for Mike, and Rob has also definitely used .NET. Rob recently using Rails for developing the last, two web applications; and he’s indicated he doesn’t have much experience with it, certainly not enough to actually write the apps. Without arguing about the merits of the different frameworks, I’m curious what benefits you saw by making that change. It effectively removes you permanently from the development review process, while adding another layer of complexity. What were the reasons for dropping a familiar platform and effectively starting from scratch?”
Mike [00:08:24]: Well, I think this is mainly aimed at you. My take on the different languages is, in most cases, you’re going to use the best tool for the job; and I think that if you’re going to go in a direction for using something where you don’t know the technology at all, then it would probably be an intentional choice to help keep you out of the technology. That would probably be the main reason that I would go in that direction; but, Rob, obviously you have your own reasons for having chosen Rails. Was it based on pricing? Just finding people who knew that technology? What was it?
Rob [00:08:53]: Your first point of intentionally keeping yourself out of the development is actually a good one. That was part of the reason, is that I found with all the products I had – from Dot Invoice to HitTail to WeddingToolbox and the other ones that I was managing – that I kept getting pulled into these little fixes and these little issues and these little bugs, and I would kill half a day troubleshooting something in PHP or, heaven forbid, in ColdFusion with WeddingToolbox. Not being able to do it is actually a benefit to me, because it means that I just can’t these days. That’s giving something up. You have to get over the fact that you can’t go in and do it.
[00:09:33] At the same time, though, I was able to find a trusted resource who I knew could help support it, and that was Derek, right? He was contracting for me at the time. He’s now cofounder of Drip, and early on, we discussed what language should we build Drip in. He knows Rails like the back of his hand. He’s very knowledgeable and just a senior, senior dev in it; knows about architecture and how it works. So, that was kind of a no-brainer, right – the fact that he knew it so well. Then, you can find Rails developers. Rails developers have heavy UX emphasis, typically, and wanted to make it very UX-friendly.
[00:10:04] Finally, I had run into real issues. I got an acquisition offer on HitTail several years ago, and since it was written in ASP.net stuff, the person didn’t want it. They really wanted something in PHP, Python, or Rails. If you’re going to build line-of-business enterprise apps, then, yeah, Java.net – those are great. But if you’re going to build startups, essentially; or web applications, and you want to be able to find developers that aren’t really expensive, find developers that have the startup mentality in general and maybe someday be able to sell it, or transition it to another company – whether that’s your plan from the start, or not – building in an enterprise language like a .NET or a Java will be to your detriment. That’s where I’d say Python and Rails would be my top two choices. I think PHP would be another one that’s perfectly reasonable. We can go into the merits of doing everything in node and using bits and that, but it probably isn’t worth the time of it.
[00:10:56] The bottom line is the reason that I dropped the platform is: 1) so that I wouldn’t get sucked into development; 2) because Derek knew the language really well; and 3) because it makes it easier to find people to work on; and if someday there was some exit event, or someone merged, or there was ever that need to transition it to another team, it’s just an easier transition when you’re using a language like this.
Mike [00:11:17]: I’ll just interject here to point out that I’ve heard that as well in terms of using something like Rails, or Python, or anything like that. Those types of languages, it’s easier to find the developers, especially the ones who are motivated to self-teach and are in the startup space. The pricing for apps that are built with those tends to be a little bit higher, so if you’re looking longer-term, I’ve heard that as well. It’s just the types of technologies that people tend to be more interested in acquiring then the C#s and Javas of the world.
Rob 00:11:50]: All right. Our next question is from Nathan Rimmer. His subject line was “20 percent of IT spending creates no value. I need your advice on how to fix that.” He says, “I’m a requirements analyst and a startup fanatic. I’m a huge fan of the podcast. Studies show that about 20 percent of IT spending creates no value. It’s like throwing a fifth of your IT budget out the window. This is a huge problem for startups who have limited funding, which is pretty much everyone. Reclaiming the lost value would allow startups to employ more people,” et cetera, et cetera.
[00:12:18] As you know, there are frameworks for coding and product development, like Bootstrap [?] startup, but there’s no framework for creating, communicating and managing business requirements. I see there’s a fundamental need in reclaiming the lost 20 percent. I’d love to hear any thoughts you have on what a business requirements framework should contain or take into account. I’d even be interested to hear if you think it isn’t needed.” So, what do you think?
Mike [00:12:37]: I think the first mistake here is assuming that startups and enterprise companies that have a full-blown IT department are the same, and that’s just a blatant falsehood. I don’t think that those two things are even remotely close to each other, so when you start looking at studies like this that come back and say 20 percent of IT spending creates no value, my inclination would be to believe that something like that comes from Gartner or Forester. Those are wildly different environments than a startup that’s got less than ten employees, for example. So, to try and equate them is just a nonstarter. There’s just no equivalence there.
[00:13:12] The other inclination I have is that when you’re looking at this type of spending, that 20 percent of IT spending is probably on technologies that are purchased because they are – either this person was sold on a dream of – some sales rep came in and said, “Hey, buy this software, and these particular problems will go away.” Or, they purchased a bunch of consulting, and the project was mismanaged, so all that money basically went out the window. Those are very, very common things that I’ve seen when I’ve been doing consulting, so those are the types of things that would factor into studies like this. I think that, honestly, this is just probably bad data. Maybe that’s a gross assumption on my part; but my guess is that, because it’s not applicable to startups, you can’t really draw a line of equivalency between them.
Rob [00:13:56]: Yeah, I would second that. I also think that, since the environments are so different, that this requirements framework that Nathan was asking about is much, much less applicable, if not totally inapplicable. It depends on what you mean by “startup,” but let’s just say it’s someone that’s less than 20 employees or a company that’s less than 30 employees. At that level, basically just a kanban process, where you’re writing stuff down on notecards and you’re sticking them up on a wall, or you’re using a Trello board, is a really good way to get requirements across; or, simply using an issue tracker. We use Codetree, which is over GitHub issues, and there has not been a single feature that we have released in Drip that has required more than a few paragraphs of discussion and description in our issue tracker.
[00:14:40] We don’t spec out these massive, waterfall projects like you do in IT, where you have these requirements that you have to manage, and you have this – you know, you used to have the 300-page spec doc. None of that is done in the startups that I know that are moving quickly. We release multiple features per week, sometimes multiple per day, and so each is individually specked out and is its own, little, tiny micro issue. So, for startups, honestly, I just don’t see the need. Maybe for enterprise IT there needs to be some framework, but I wouldn’t even be able to speak to that now. I’ve been out of that so long.
I hope that helps, Nathan. Thanks for sending in your question.
[00:15:12] Our next question is from Christopher Gimmer, and he says, “Hi, Mike and Rob. Huge fan of the show. I had a question about auto responders for freemium SaaS products. With a typical SaaS trial, you’re hoping to help users find value and convert to paid before the trial runs out. With a freemium product, there’s no time limit and not everyone will be interested in a paid version. Just wondering what kind of advice you would give on how to set up an auto responder for a freemium product. Would it be any different than a normal trial sequence?”
Mike [00:15:39] Yeah, I think that there’s a couple of different things that you can do – different approaches, I’ll say. The first approach is when you have somebody come into a funnel like that, are you trying to sell them directly on the higher-level version of the product, or are you just trying to get them in the door to start using it? I think the answer to that depends a little bit on how complicated your product is to get up and running for people and how valuable it becomes to them over time. Obviously, in a SaaS scenario, you want to be charging people on a recurring basis if the value of your product goes up over time. So, something like – to throw to an example here, bug tracking software, or anything where you’re aggregating data over a time period. Over time, hopefully, the users are sending more data into that system so that as they use it more and more, it becomes more valuable to them.
[00:16:27] Now, if you’re trying to get them to just use the product, then you probably want to get them onto a paid version, assuming that they’re a big enough customer that they’re going to be using it extensively. Or, if they’re on the smaller side, you just want to encourage them to use it in case they end up larger companies later on and be able to bring it in the door. In each of those situations, you’re going to do one of two things. You’re going to try to get them onto a paid plan first and then essentially back off if they end up going into the freemium plan for the product and then over time, try and pitch them on the benefits.
[00:17:00] I think that when you start seeing their usage of the product over time, you can check to see whether or not they’re going to run up against any of your internal barriers for that freemium product. So, let’s say that you’ve got BugTracker. You only allow them to track 100 bugs, for example; or, only manage two or three projects at a time; or, only have a certain number of users. When they get close to that user limit, you hit them with an email that says, “Hey, you’re getting close to this limit. Would you like to upgrade?” That’s a trick that came from Patrick McKinsey at one of the previous MicroConfs, but there’s lots of ways that you can monitor what their usage is and then perform specific, targeted emails to identify those people and try and get them to upgrade; but I don’t think that you want to beat them over the head with it every, single week. Then just on a rolling basis, maybe every three or six months, try and pitch them on the benefits of upgrading to a paid plan.
[00:17:49] What about you, Rob? What do you think?
Rob [00:17:50] Yeah, the sequence is worlds different than free trial. When you have a free trial that runs out, you have a time pressure there, and you are trying to get them on board before the end of that free trial. With a freemium product, like you said, you’re trying to get them to activate. That’s the first thing I’d focus on – is just hitting them up once, twice a week and saying, “Hey, you haven’t done this yet.” “Hey, you haven’t set that up,” because if they never do that, then they’re never going to use the product, and they’re never going to upgrade to free. So, you really want to get them to use the product, or get them to say, “Stop emailing me.” It’s kind of like that follow-up thing from Steli. If you’re getting this big traffic of freemium and no one’s activating, that’s a real problem, so the email should gently nudge them to do that. Then as their usage increases, touch base with them via these point-in-time emails based on actions or based on levels in their account. Then let them know that, “Hey, we do have these extra features,” or, “We have more that you can get by using our paid plan.”
[00:18:40] Just like you said, I’d probably pitch it more often than every three to six months. I would think about, say, every six weeks to three months. If you do have this free user base and you really do have something that’s much more valuable to them, I feel like it’s worth mentioning. And you don’t do it directly. Maybe every six weeks you don’t pitch them with this direct hard sales pitch. Maybe that is every three to six months, but in between there you want to touch base with them about new stuff you’re releasing and then have just a little pitch. You know, if you’re using marketing automation and you have tags, then you’ll know that they’re freemium, and you can actually put something different in there than if they’re an actual paying customer. In even a feature announcement email, you can basically include a paragraph only if they’re on the free plan and say, “Hey, this stuff’s only available to paying customers.”
Rob [00:19:20] Yeah, I definitely think this trial sequence is quite a bit different than freemium. You really just need to think through what their journey is and how different it is from a typical paid trial. I hope that helps, Christopher.
[00:19:33] Our next question is from Caesar, and he asks about when to show pricing. He says, “I’m struggling a bit about when should I show pricing on my marketing website. Should I do this right from the beta? Should I do it after the beta? Should I show the cheapest tier first and for the rest have people contact us? Should I start inviting testers even if they don’t know about pricing? I realize most of the answers will be ‘it depends,’ but it’d probably be interesting to hear your experience about it.”
Mike [00:19:59]: I think when you’re early on and you’re still trying to figure out what the value of the product that you’re billing is worth to people, it’s a lot harder to figure out what to charge people. One thing that you might want to try is essentially just asking those people who are early on, “What is this worth to your business?” “Is it going to cost you to not use this particular software?” That will help give you an idea of what the value proposition is going to be to them in terms of dollars for the product.
[00:20:27] Once you’ve done that, you can start showing that information, but I think that you need to start taking orders from people. It can just be maybe your first 20, or 30, or even 50 customers. Maybe every, single one of them pays something different; but if you don’t post the pricing, then you can have each one of them pay something completely different, and nobody’s going to know anyone – not unless they start talking to each other and say, “Hey, I’m only paying this,” or, “I’m paying that.” You want to figure out what it is that people are willing to pay for it, and why; because your feelings of what the value are of the product are probably going to be different than what your customers feel it’s worth. That’s a common theme among people in the startup world – is that they’re essentially undercharging for their products because they don’t understand the value that it provides to their customers.
[00:21:12] Then there’s also – the flipside of it is maybe you think that it’s worth a lot more than it is, and the only people who are going to be able to tell you that is the people who are cutting you a check. So, charging them different amounts for the first 50 or 100 people is probably fine. Maybe it’s only the first ten or 15 people, but if you can get an idea of what those prices are and talk through why those beta customers think that those prices are justified, then it gives you a better idea of what to put on your home page.
Rob [00:21:37]: Yeah. If you’re pre-launch and you’re still hand-holding folks into your app – at that point with Drip, we didn’t even have a marketing website. I don’t even think we had placeholder text. We were literally just getting people in. I had told them in an early email, “I think our pricing for this long-term is going to be between 49 and 99 a month for our lowest plan.” That was kind of the first thing we said, but I did let them know up front that we were going to be charging. This was not going to be some free-forever plan. So, if you’re still handholding, you have the luxury of being able to do that one on one.
[00:22:11] If you’re not and you’re starting to let larger groups in, I would be charging by that point. If you’re starting to let 100, 200, 500 people in, that’s the point where I know my pricing; or, at least I have an idea of it, and I’ve picked a price. Then I’m going to test it with that first group. I don’t believe betas should be free. I think beta testing is you’re building it. You’re doing unit testing. Then you do integration testing with everything together. Then you test the crap out of it with your own stuff, and then you get maybe ten people who you one-on-one handhold through the app, and you get them all set up. You’re going to have worked out a ton of stuff by that point, and from then on you’re done. Beta’s done. This is not something where you let 100 people use it for free until you decide on pricing.
[00:22:52] Maybe you give them a really long trial, if that’s what it takes. We were doing – if I recall, with our early beta testers, I didn’t know how long the trial would be at all, and some people got months and months to try it out; because we just didn’t know. We were trying to build features to make it valuable enough for them. Once we got out of that, it’s pretty much been a 21-day trial since day one. A few people have asked for extensions based on extenuating circumstances, but that’s it.
[00:23:15] Then in terms of the other part of this question, he asked if you should show pricing on the marketing site, or just show the cheapest tier and have “Contact Us.” If you’re selling to enterprise and you’re going to do the whole figure out how much people can spend and negotiate pricing, then, yeah, everything should be “Contact Us.” But if you are just selling a typical SaaS app or a downloadable app, I think you should have all your tiers up there and then a big enterprise tier that says, “Contact Us” for people who do want to spend a lot of money and get more. There’s always a need for someone who wants to spend $10,000 on your software, but aside from that, I don’t see a ton of value in trying to obfuscate your tiers or hide pricing from people.
So, thanks for the question, Caesar. I hope that was helpful.
[00:23:53] Our next question is from Jeff, and he asks about SaaS subscriptions versus commission pricing. He says, “Hi, guys. I’ve listened to a couple shows where you discuss SaaS pricing models, and I haven’t heard you mention commission-based pricing at all. We recently launched our SaaS offering, which is a marketplace platform around the wedding industry.”
[00:24:11] So, stepping in here, I think what he’s saying is they have kind of a two-sided marketplace where they have brides and grooms who are about to get married, and then they have providers. I would guess it’s like people who sell wedding cakes and flowers and maybe wedding planning services and venues and that kind of stuff. So, I wouldn’t actually call this really a SaaS offering as much as it’s just a wedding marketplace. Now back to his email.
[00:24:32] He says, “We’ve had great traffic to the site, but our conversion rates have been pretty low. Our packages include a percentage commission on sales, and I’m wondering if that is turning people off to the product. We’ve tried emailing our customers along with everyone that’s expressed interest, but we didn’t get much of a response. I’m curious to hear your thoughts on commission-based pricing for a marketplace site like this. My gut is telling me that it must not work in most instances since there doesn’t appear to be many SaaS offerings out there that are using this pricing model.”
Mike [00:24:59] If I understand this correctly, what he’s essentially saying is they have a marketplace platform for the wedding industry, and they have brides and grooms who’re getting married on one side of it and then the vendors on the other side. One of the two complaints, or issues, that they have is they’ve got a lot of traffic, but their conversion rates have been really low.
If you’re charging the vendors, but not the brides and grooms, then that would almost be expected; because the brides and grooms that are visiting the website are probably going to outnumber the vendors by a pretty wide margin. That’s going to drive your apparent conversion rate pretty far lower than it probably otherwise should be counted. You might have, let’s say, 10,000 brides and grooms who visit, but you only have 200 vendors that visit. Well –
Rob [00:25:43]: Right.
Mike [00:25:43]: – how do you know which 200 vendors there are versus the 10,000 people? And what number are you going to count it against?
Rob [00:25:48]: I would agree –
Mike [00:25:49]: So, I think that –
Rob [00:25:49]: – and I think we should clarify here he says, “We’ve had great traffic, but our conversion rate has been pretty low.” We’re making the assumption that he means that it’s the vendor conversion rate.
Mike [00:26:01]: Yeah, so that’s –
Rob [00:26:01]: And I’m not 100 percent sure.
Mike [00:26:03]: Yeah, I’m not either, so – that’s just a point for him to take home, though, is that might be an issue if that’s what he’s looking at and he’s just not thinking about that piece of that – that division between the two – as one issue.
[00:26:15] The other thing is that if you are charging the vendors and you’re charging them on a commission basis, essentially what you’re doing is – let’s say that somebody buys a $50,000 wedding package and you’re charging the vendor, let’s say, 5 percent, something like that. Well, that becomes a $2500 fee that that vendor has to pay versus if you have a static pricing tier for each of these things, then it would be, let’s say, $500 for them.
[00:26:42] Since you and I run MicroConf, one of the things that we really don’t like is having to deal with any sort of variable costs. It is a lot easier to run an event when you know exactly how many people are going to show up, because you know exactly what your budget is, and you can plan and anticipate things in advance. You can make decisions about what you’re going to spend and what you’re not going to spend. But if you’re a vendor, and you’re on this marketplace, and your costs are going to be variable, it makes it much more difficult to get a handle on some of that stuff. Quite frankly, there’s a lot to be said for just avoiding the hassle of even bothering.
[00:27:19] I would wonder whether or not a commission-based pricing structure is even the way to go here. Maybe it’s a flat fee on a per-event basis. That would be my thought; but, again, if you’re having a hard time seeking feedback from people and getting responses from them, then it seems to me like there’s a completely different problem that you actually have to tackle, which is why are you even not getting feedback from these people?
Rob [00:27:43]: Yeah. Let’s just be clear here. In no circumstance should you charge the consumers here, because they’re going to be super price-sensitive. It’s the vendors that you should be charging, so I think we’re just making the assumption that that’s going on. If not, then you should definitely do that. I can’t imagine at this stage charging a subscription fee to the vendors, because I can’t imagine a vendor that’s going to want to pay for a completely unproven solution. Maybe if you have millions of people coming and you have tons of money going through your system, you can move to subscription fees; but at this point, you’re probably going to need either a flat fee per event like Mike said, or a flat commission.
[00:28:18] I think a flat commission is fine. I probably wouldn’t call it a “commission,” though. I typically call it, like, a “transaction fee.” If you look at Gumroad, or another platform like this, that’s what they add on. If you’re going to pick 5 percent or 10 percent, that’s fine. Mike’s objection to it being variable, I think, is a valid one; and I think the way you could get around that is have a maximum. You could say it’s 5 or 10 percent, and it’s capped at 250 bucks, or 500 bucks – just a maximum somewhere. Maybe for different vendor types, it’s different amounts because, obviously, flowers might only be a few thousand and a venue might be more than that.
[00:28:51] To be honest, it doesn’t sound to me like this is the major issue, if you have all this in place. I would guess that there’s something else at play here, and that people aren’t engaged – or, that none of the people who visited were actually vendors and that everybody who came in was a consumer, and that’s why you got a lot of traffic and no one converted. So, this is a tricky one. There’s a lot to dig in here.
[00:29:11] I think, in general, my advice would be don’t try to bootstrap a marketplace; because they’re really, really hard. Even if you make this work and you start getting people signed up, making 5 or 10 percent on a fraction of these transactions, you have to be at scale to make any money at it. We just saw last week Gumroad laid off 90 percent of their employees. If you go to Tech [?] and search for it, you can see that even them, who – everybody in our space knows who they are, but they’re trying to take these tiny, tiny, little snippets of fees from these transactions; and it seems to me that they just couldn’t get enough volume, because unless you’re doing Uber-level, or Stripe-level volumes of transactions, then you’re not making any real money. You’re making thousands or tens of thousands a month, and that’s not enough to justify all the employees and all the support you need to handle a set like this.
[00:29:59] So, that’s our two cents. Hope that’s helpful, Jeff.
[00:30:01] Our last question for the day is from Ely Gescheit [phonetic], and he says, “I’m a big fan of the show. I’ve listened to you for the past couple years. My startup is focused on helping the building industry, such as town planners, architects, et cetera. However, the app could also be applied to the legal profession, because it essentially converts boring legislation into a more user-friendly format. There are around 600 town planners listed in Sydney, Australia, on Yellow Pages and around 10,000 lawyers. My initial idea was to focus the app on the building industry and later pivot to the legal profession. The idea behind this was to test the waters with a smaller target market. Given the app will be more scalable in the legal profession, I’m thinking of switching my strategy and focusing on legal first and then moving into building.”
[00:30:43] To me, the risk trying to target a smaller market is really high, and I’m not sure whether it will even be worth all the effort for just a small market. What are your thoughts?
Mike [00:30:51]: I think I’d be very hesitant to target either town planners or lawyers, regardless of the numbers. Essentially, when you start weighing these against each other – the numbers he throws out are 600 town planners versus 10,000 lawyers that he’s identified. With town planners, you’re going to be dealing with government paperwork and government budgets, and they’re going to be on strict timelines. They’re going to have to plan it in advance, and your sales cycle is probably going to be longer for most of them. That’s a blatant assumption, but you could just make some phone calls to five or ten town planners and ask what their purchasing process looks like and find out pretty quickly how long it’s going to take to onboard them as a customer based on however much it is that you’re going to be charging them.
[00:31:31] For the lawyers, I know people who have startups in the legal space, and it’s not always easy to get customers. Sometimes it is. Sometimes you can get to the right people very quickly and they are willing to talk to you as long as you are going to be providing a service to them that you can essentially pitch very quickly and that they can see a justifiable ROI on it; but you’re still probably going to do a lot of handholding, because those types of customers are probably not searching online for stuff. The legal profession is – in a way, they’re stuck in the ‘80s. They use fax machines for everything. They’re somewhat technology-averse, and you’re probably going to have to find a way to gather them as customers, and it’s not going to be through a lot of the things that we talk about on this podcast, like SEO and online marketing and things like that. You’re going to have to really go after them.
[00:32:19] With those things said, I don’t know if it actually makes a heck of a lot of difference which one you go after. What I would do is, if you’re still in this early stage, talk to ten, or 15, or 20 of them and test the waters a little bit and see which one of those two things is going to do better for you. Come up with a short list of identifying factors or traits that you would like to see and then ask those questions and find out if those are actually present in that particular market. If they’re not, maybe you kill the idea and move on to something else, or move over to the other market instead. Come up with a list of pros and cons for each of them, iterate through them and then see what the numbers come out; because it seems like you can get a lot of the information you need just by talking to ten or 15 people in each of those two industries.
Rob [00:33:03]: Yeah, I’m also pretty bearish on this idea, especially if it’s your first app. I would go for a smaller, easier win that you can market online. But if you really enjoy high-tech sales and you’re willing to do six-month sales cycles, and you’re building something that either of these niches would pay – let’s say $12,000 a year is probably the smallest annual contract value I would do when targeting these niches. I’m pulling that out of the air a little bit, but if you build something that’s 50 bucks a month or 99 bucks a month, you’re nuts to try to go after these markets. They’re just too hard to sell into when you’re getting started, especially if it’s your first time doing it. You don’t have any competitive advantage in these markets.
[00:33:42] So, all that to say I would think really hard if not all of those things are in place. If you’re thinking that you can set up a marketing side and drive SEO traffic and pay-per-click traffic and convert on an app that’s 20, 50, $100 a month, this does not sound like that idea.
Mike [00:33:59] Thanks for the question, Ely. Hope you found it helpful.
[00:34:01] If you have a question for us, you can call it in to our voicemail number at 1.888.801.9690, or you can email it to us at: firstname.lastname@example.org. Our theme music is an excerpt from “We’re Outta Control” by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for “startups” and visit startupsfortherestofus.com for a full transcript of each episode.
[00:38:18] Thanks for listening, and we’ll see you next time.