
Show Notes
In this episode of Startups For The Rest Of Us, Craig Hewitt returns to the show to answer a number of listener questions on topics including productized services, podcasting, and more.
Items mentioned in this episode:
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing startups. Whether you’ve built your fifth start up or you’re thinking about your first. I’m Rob and today with Craig Hewitt, we’re here to share our experiences to help you avoid the mistakes we’ve made.
Welcome back to the show. As you know on this show, we value building real businesses with real customers who pay us real money. We value the freedom to work on projects that are interesting to us. We value the purpose that it brings us to start our own endeavors and to have equity and ownership, and we value relationships, whether that’s relationships with our family or our friends. We don’t decimate our personal life for the gain of our company. We are ambitious founders, but we are not willing to sacrifice our life or our health to get to where we want to go. We know that starting a company is hard. More than half of being a startup founder is managing your own psychology.
Joining me again today is our guest, Craig Hewitt. He’s the founder of Castos. I did an interview with him a few episodes ago, and I did a call out for questions that folks have for him about his experience about his interview. I wanted to bring him back on the show and it’s something I want to start doing, assuming there is enough demand for it. If you didn’t hear that interview, Craig has grown Castos to six team members, including himself. They are a member of the inaugural TinySeed batch and Craig is really crushing it with Castos, his podcast hosting platform.
Before we dive into that, I want to give some special thanks to Kenneth Khaw for his epic enterprise sales tip. He sent an email to me after David Heller’s hot seat episode, where we dug into David’s enterprise sales issues with things taking too long. Kenneth Khaw obviously has tons of credentials around being in enterprise enterprise sales for 12 years and he had some tips for David, including screenshots, a long write up, and talking about summarizing a quote in one page, providing variations of a quote, figuring out what the get over the line number is for negotiating. He really dug into it.
That was super cool, super appreciated, and David just wants to tell us, “Wow, he really spent a lot of time on this,” so it’s much appreciated that the community can give back to someone like David who is pushing forward and trying to solve problems. That was great when we can share our expertise with one another.
Lastly, another reminder that TinySeed applications for our second batch open on November 1st. Those who don’t know, I run TinySeed, the first startup accelerator designed for bootstrappers and we fund companies in batches for a year-long remote accelerator. If you’re interested, head over to tinyseed.com, enter your email there, and we will notify you when the applications’ available.
With that, let’s dig into some questions with Craig Hewitt. Craig, thanks so much for coming back on the show.
Craig: My pleasure. Thanks for having me, Rob.
Rob: I am excited to dig into some questions today. We got a few questions that were asked directly to you and then there’s a few more general mail bag questions. The first question came from Matt Stainer and he said, “Why TinySeed? Going into it, what were you hoping to get out of it? Now that you’ve been in a while, how’s it going? I ask because as I understand it, TinySeed is focused on helping founders and ‘move from nights and weekends to full-time focus.’ Essentially quit their day job and go all in on your startup. And yet, it sounds like you are already full-time on Castos with six employees. So I’m curious what drew you to TinySeed. Thanks, Matt.”
Craig: That’s a really good question. This was a question I asked myself a lot and had a lot of real heart-to-heart with my wife, and even with other people coming in the space that I know, trust, and respect. Really now, what it came down to is the terms for TinySeed are really, really favorable for founders who want to run a business for a long time just as a high-growth lifestyle business. Not on the VC track but want to accelerate the growth of their business, past what they can do by pure bootstrapping.
If it’s like you mentioned, some of the copy on the website might be let you quit your nights and weekends and focus on this full-time, that would obviously accelerate the growth of business. For us, we had a pretty solid beginning of product market fit when we applied and I thought that joining TinySeed, both for the mentorship and for the funding, would allow us to accelerate that. Rob, we’ve for five months into it now. I think it definitely has. We’re growing faster the we were before and the business is absolutely a better business now than it was six months ago.
I think what drew me to it was the people behind it and the opportunities that will allow me professionally and personally to develop but also to put Castos on the map and give us access to resources both financially and mentors and network that I don’t have access to myself, and really at a pretty reasonable cost. I won’t say it’s a cheap cost because it’s not. Giving up a piece of your company is always a big decision and a really super personal one, but I think that the trade-off is really reasonable in this respect.
Rob: I remember you felt a lot about it. You and I had a number of conversations as I did with most of the founders that wound up making into the batch. There were conversations about us feeling people out and there was them feeling us out and saying, “What is this going to be like.” We had an interesting almost conundrum of we were startup, too, and this was our first batch. I think it will be much, much easier. I expected to be much easier with the second batch because it’s just more proven. We have more products market fit now. There are a lot of conversations then.
The other interesting thing is we did start out with a thesis of “I think we’ll fund a lot of founders who will move from nights and weekends to full-time” and if I recall correctly, we funded 10 companies and I think two of them and maybe three went from had a day job to went full-time. Everyone else was already working on it.
Even that hypothesis we had is not entirely accurate. Now, one of them has a small software product that essentially provides him with the full-time income, so he didn’t need to have a day job. Another founding team moved to a cheaper place. They did geo-arbitrage. They moved from the US to a much cheaper and that allowed them to live full-time even though they didn’t have a US full-time income coming in.
There were exception-ish things, but overall, if we haven’t already updated on the website, I think we need to in terms of you figure out really who your best prospects, the people who can use this the most, and message to them.
You said Castos is growing and it’s absolutely in a better position today than it was when it joined TinySeed. Honestly, I haven’t talked a lot about TinySeed on the podcast because I never want the podcast to feel like a sales pitch for anything I’m doing. I would talk about my journey building HitTail, or journey doing MicroConf, or journey of Drip, but I try really hard to keep that balance of I’m not just sitting here pitching what I’m doing.
Actually, I have a couple of people ask me to bring someone on to interview me about what’s going on, not necessarily talk about TinySeed but what’s going on with me, my founder’s journey. I think that can be interesting.
All that said, I haven’t talked to […] about it, but I’m curious. You’ve now been in for almost four months at this point; it’s a third of the accelerator. Without putting you on the spot, is it what you expected in terms of the benefits?
Obviously, there is money, and then there’s the mentorship—our list of mentors is pretty solid—then there’s the office hours themselves of hang-out or kind of the mastermind, the community of it, of being in Slack and being on the weekly calls, then the in-person event, and even the network. Even beyond the mentors if you say, “Hey, I need an intro to somebody.” My network and a lot of the mentor’s network are at your disposal. Has it been what you expected and do you feel like it’s contributed to your success over the past four or five months?
Craig: The money is really nice. I think that a lot of people that take money that have a bootstrapper mindset—Josh from Baremetrics talk about this a lot—they haven’t spent a lot of the money they took, and we haven’t either. We used it as a cushion—it’s a big cushion for me—but we’re not burning hardly any money right now. We’ve hired a lot of full-time person-and-a-half since joining TinySeed. That’s been really nice. It makes me feel good to have a lot of reserves and the business is really sound at this point.
It’s cool that comes through in everything we do because we’re able to take a longer-term approach to building the business, features, marketing approaches and things like that, that we don’t have to worry about making payroll next month or next week because we have money in the bank. Where if things went sideways, we’ll be good for a while. That’s how we are using the money.
The best part really is the network and the community, the difference being the network is with the mentors and the mentor’s networks because we definitely have gone second and third layer with some of the mentors that I’ve talked to and they said, “Hey, if you want to talk to this person, we can intro you over here.” I probably have two or three calls a week with either you and Einar, or a mentor, or a mentor’s friend, or a connection that I’ve made somewhere like that. Then we all, the 10 companies, are in Slack all the time sharing stories. We have a fail whale channel, so sharing our successes and learning opportunities. That’s really great because a lot of us are solo founders.
There’s two founding teams in the cohort, but it gets lonely sometimes out here, especially to have people that are doing exactly the same thing that you’re doing. We’re all building SaaS apps that are less than whatever $50,000 a month. We were all in the same boat pretty much. So, it’s a really homogeneous group. That’s what makes a lot of the discussions really interesting among the founding teams. I think that’s the biggest surprise, though, is that the value of the network of mentors, the support of the other companies, and the founders has been awesome.
I know that we numbered the TinySeed 2019 Slack channel that’s just for us. I know there’ll be a TinySeed 2020 and 2021 stuff that I still will definitely be active in our little part in our channel within the group, just with us and the other 11 people because these are really valuable relationships.
Rob: Awesome. That’s what I would hope to hear from anyone who does become part of the batch. Thanks for the question, Matt. Appreciate that. I hope context was helpful.
Our next question is from Meryl Johnston. She is the founder of Bean Ninjas, which is a pretty well-known productized accounting service. I believe they focus on Xero, but they’re pretty well-known. They’ve sponsored a lot of conferences and Meryl is actually one of the TinySeed mentors. She says, “Hi, Rob. I think it’s a great idea to get Craig back on for another episode to answer questions from the listeners.” Meryl sent a voicemail, so let’s dive into that now.
Meryl: Hi, Rob and Craig. It’s Meryl Johnston here from Bean Ninjas. I’ve got a question for you both. Cool content, by the way. I like the idea of having an interview and then giving listeners the opportunity to ask follow-up questions, which you then answer on a podcast. Going back, understanding is that you started with consulting before you transitioned to products and then software, and that Craig used a productized service business model to then leverage your network and skills, and maybe branding as well, to then going to software.
My transition was also from I went from consulting. I did that for nine months, then created a productized service, and then you see it with been moving into digital products. Based on my own experience, I think there is that when you, in building a skillset, as an entrepreneur while running a service business and in my experience it was a faster way to leave a job and transition to working full-time in their business than if I had created products from day one.
So, my question to you both is, if you were starting from scratch again and is transitioning from a job to running a business, and you didn’t yet have much business, you didn’t have much of the network, and didn’t have a lot of capital behind you, what kind of business would you start? Rob, would it be consulting? And Craig, would it be a productized service?
Rob: That’s a good question. Thanks for that, Meryl. What do you think, Craig? Have you thought about this?
Craig: Yeah, I have pretty strong feelings about this. I think a productized service model or even consulting is a fantastic way to transition out of a day job into running your own business. The reason is, as opposed to software where there’s a ton of time and financial overhead that you need before you can start making any money, you can put up a WordPress site with WooCommerce or Gravity Forms or whatever and start making money literally today.
Justin McGill launched the first version of LeadFuze and this 24-hour challenge to himself. We launched Podcast Motor in maybe a week, and that was because it was my third time ever putting up a WordPress site. We were doing $10,000 a month within a couple of months. You compare that to what a SaaS founder has to do to get that $10,000 a month. It’s like moving planets to get to that kind of MRR for SaaS, especially the first time.
I think that if someone has a skill set or a passion and you can create a productized service around it, you absolutely should do that if you goal is to get out of a day job and into this world. But I think Meryl really nailed it on the head when she said leverage because that’s how I view what we’re doing now.
Rob, you probably see it from consulting to your first software product to what you’re doing now is another form of leverage. I just see that a unit of work I do now in Castos is worth a lot more to the value of the entity than a unit of work that I do into Podcast Motor which is our productized service. I think it’s just because creating a piece of software and a team that supports that is more scalable, probably has better margins, and in some ways is easier to run at a higher level.
I think it’s a fantastic way to start and I think that like Meryl is getting into, getting into a digital or software product is really great because they’re more complicated and if you’ve learned some of the things like marketing, project management, and customer service through a productized service, then you have a really good chance at being successful on software.
Rob: For me, I honestly don’t know. I have an inclination of what I would do, but I think if someone came to me for a blanket advice, I would say, “Look, I had a day job and I want to work for myself. I would say there’s the Robert Kiyosaki levels. I’m not a Poor Dad Rich Dad fan, but I do like this one paradigm he has where it’s like, you’re employed for someone else, then you’re self-employed, which typically is consulting where it’s dollars for hours, then you’re an entrepreneur which is where other people work for you, and as you said, it’s that moment of leverage when you have a whole team, and then it’s investor where you’re no longer running the day-to-day and you’re putting money into other businesses.
So, I would first decide do you just want to recur self in this terms of self-employed or do you want to go as far as to be the entrepreneur and let’s just say to have a product business in this context and then go from there? For me, if I could go back, I wished that I could have kept the day job and had it not just drive me up the wall. I hated my day job. I really, really despised working in a cubicle. I liked some of my co-workers and I didn’t like others. I didn’t like that I couldn’t choose who to work with and I didn’t like that a bunch of the policies seemed just dumb. I didn’t like that we’re forced to write really crappy code a lot of the time.
Our CEO is a sales guy and he would go out and sell something. It would be like, “Hey, we have to ship this in six weeks,” and we’re like, “Yeah, that’s four months of effort.” He’s like, I don’t care. Get it done.” So, then we go get it done and then […] would break because we wrote […] code. Then he’d come down and I was like, “This is dumb. Why isn’t someone smarter here?” That seemed to just be an ongoing thing.
Had I been a little more chill or been able to deal a little better with it or just found jobs that weren’t like that because there are certainly jobs that exist and there are people that are calmer and I would like to say I’m unemployable. I am just not going to be a good employee. But if some is like, “Look. I’m at my day job. I’m making $125,000 or $150,000 as a salesperson or as a developer. I work 40 hours a week, I don’t think about it when I get home, and it doesn’t suck the life out of me,” I would say keep doing that and launch something on the side.
Maybe your first step is consulting. Maybe it is productized consulting like you did, Craig, and like Meryl has done, but maybe it’s a stair step approach. Maybe it’s that WordPress plugin, or you write an ebook, or maybe it’s a Shopify add-on, or any one-time sale product. I definitely went to the consulting route because I wanted to be out of a day job in a hurry and I thought that consulting, to be honest, was the end goal for me originally. I thought that would fix all my woes and as I got out, bill $100–$125 an hour. It’s like, “Oh my gosh, this is great, I’m making more money that I ever had.”
I didn’t dislike it as much as I dislike salaried employment for sure, but it definitely got old after a couple of years. For me, it was about I wasn’t building anything that would last. There is no permanence to it. I didn’t build anything that I owned, I had no equity, and my consulting “firm” was never sellable. I thought to myself, “Am I going to do this for 20 years?” and that didn’t appeal to me.
It’s hard when you’re doing consulting and you’re addicted to the incoming cash. It’s really hard to justify. I could work another hour. I used to be booked 60 hours a week, I would say. I didn’t work that much, but I could have worked that much. So, I would look at it like, “All right. It is Saturday afternoon and I could put in three hours and I could make $375 or I could work on this beach towel website that is doing $200 a month.” It was a very hard transition.
So, for me, going from consulting to products was actually harder than if I had just kept the day job because at the day job, I wouldn’t have had that extra motivation to work more on it. Does that make sense?
Craig: Yeah and I think that’s where consulting and productized services differ. Brian Casel talk about this with Audience Ops. You’re able to take a productized service that has a team that supports it, and systems, and processes, and documentation to—I don’t know—say, run itself, because nothing runs itself. But I spend an hour a day on Podcast Motor right now, maybe two on a bad day or whatever, a good day, and it’s a solid mid six-figure business. You could never do that with consulting because you’re directly trading dollars for hours or hours for dollars. I think that’s the difference.
I agree with all you said, Rob, that most high-leveraged thing you might be able to do is keep your day job because you can just save a bunch of money, maybe, and go buy your way into freedom, you can buy an app. Or you can get experience and something that will then allow you to be successful when you do go out on your own.
I had a sales background before and it’s hugely beneficial to me in the biz world to know how to sell stuff. If you have the opportunity, get into a sales or marketing role where you can learn that side of the business and of the world. I think that might set you up for success. I won’t say more, but it will definitely give you a leg-up versus just going on flailing around and figuring out on your own if you’re able to hold down that day job.
Rob: Yup. I think that if you can learn skill sets either at the day job or as you’re consulting or productized consulting, if you can learn skill sets there that add to your product tool belt—your product marketing, your product sales, your product development, whatever—that’s a big win. That’s something that I found.
Again when I was solo consulting, I had 1–3 clients at any one time, my marketing was my blog, I invoiced using Excel spreadsheets, it was very stripped down, and I didn’t have direct copy, I didn’t learn marketing, I didn’t learn AdWords, I didn’t learn any of that from consulting.
When I look back on my experience, if I had any regrets, is that my salary job. I learned to code for sure, got better at it. So I was already coding before that. That obviously helped me with products. Eventually, you top out and you’re working on different problems than you work if you had a little SaaS website or whatever.
When I transitioned to consulting, I don’t feel like I really learned much that later helped me to translate it into supporting and building a product. Whereas productized services, it sounds like to me from what you’ve said and what I’ve observed that there’s a lot more parallels between that and, say, SaaS. Would you agree with that?
Craig: Everything about it is the same except for the software. It’s marketing, it’s customer service, it’s processes and deliverables, and then SaaS adds on project management of development teams, testing of technology and stuff like that.
Rob: Yup, it really is a nice proxy for that. It’s not just a revenue stream. I already mentioned it in the intro, but if you haven’t already heard Craig’s story, if you go back to episode 459, he tells a story of how he had a day job, launched Podcast Motor which is his productized service, left the day job, and then leveraged that into essentially a WordPress plugin and doing Castos. Not only did it provide revenue, but it provided that whole skill set and the learning curve that you didn’t have to do while you’re communicating with developers and designers, building and supporting a product, and doing all that stuff.
Thanks again for the question, Meryl. I hope that was helpful. Our next question is from Cain about how to run a beta. He references an episode from 2012 where Mike and I talked about running a beta, and he said he’d love to hear a little more on how to select the beta users and figure out beta phases. Any references, similar discussion happen on Matt Wensing’s podcast which is called Out of Beta, not coincidentally I hope, which made me think to look and see what you guys had on this subject.
Craig, I know that you had beta periods with Castos. Talk about that.
Craig: We don’t. No, we don’t have any beta testers or beta functionality in the app.
Rob: Really? Have you never? Were you in beta early on? Or did you just never have a beta?
Craig: No. We just launched.
Rob: I guess to define it so people know, typically I don’t call it beta. I typically call it early access. Beta implies that it is a buggy product and it’s pre-launch. It’s a preview you can use, but beware of the bugs. Typically, we might nuke the data. There’s different agreements and such. Google is famous for having Gmail in beta for five years or something. But betas are, (a) not required, and (b) these days, I would like not to have a buggy product.
When we did Drip, we did early access and we tried to make sure there’s minimal bugs. It wasn’t about testing, it was more about customer development. User experience or fun rather than, “Oh, they clicked on a link and something crashed.”
With that said, I had assumed wrongly, obviously, that you had run a beta with Castos in the early days. So, you just launched straight away.
Craig: Yeah. We just dove head first. I also think there’s two parts to beta. One is before you launch and then the other is beta testing or beta releasing features after you’ve launched. You develop a new feature, you release it to a small cohort of your total user base to let them test it before you go throw it out to the whole world.
We very much would like to do the latter now because we have thousands of users and we don’t want to release something to everybody that could be buggy or whatever. We have extensive unit test and staging environments, and we have testers that run through everything before it goes out the door. But I would still like to take the time to develop feature flags or beta flags for certain users.
I think that if you have an established product, it’s super valuable because you can pick the people that have been around for a long time and you know they really care about you and your product and are going to be there even if you ship something that isn’t the best experience the first time. Those are the perfect beta testers. They’re the people that love what you do no matter what but will give you a lot of latitude if you ship a feature that’s in beta that might be a little rough around the edges.
That’s how I would select those people. You probably know who they are. They’ve been around for a long time, your exchanges with them and support are really positive, they refer other people over to you. Those are the characteristics of what I would consider a good beta user to be and they’re inquisitive, natural, learning people, still go poke around and give you constructive feedback without being overly critical in a non-productive way.
When it comes to beta, that’s the only place I really see a good use for beta. We launched Castos and just launched it. It was not pretty, but it worked. I think we only did it because we tested the hell out of it in staging and had confidence that the product and the market had good alignment because there are other people doing similar things. It’s not like we’re creating a whole new product segment or something like that. That’s why we just launched it.
Rob: And how did that go? How were the results? Because you referenced it was not pretty.
Craig: We had some technical issues with deployment. I think that just happens sometimes. We learn and do things smarter and better now, but that would have happened even if we would have released it as a beta, I think. We would have these issues.
I think people might get hung up on this a little bit and there’s a lot of discussion around this, like when is a launch really a launch, when do you come out of beta, and what does that mean? I think it’s fuzzy, to be honest with you and maybe not super important, like how and where do you draw those lines?
You get the thing out there, have some people use it, make sure it’s not going to break the world, then release it and start getting real, new, fresh customers or trial users so you can see unbiased people using your app. I think that’s the real thing that you want to get to, is how does this person I don’t know and won’t give me that extra leeway, how are they interacting with what I build? Because that’s the real acid test.
How did you guys do both beta period when you were launching Drip and then did you beta release features to certain users?
Rob: Yeah, we did. This is what I would do today. The fact that I’m referring back to Drip doesn’t change […]. This is still […]. The first, let’s say, 10 or 15 customers we let in that weren’t paying yet, they were just on an unlimited free trial and I said, “Look. Once you start really using this and get value out of it, then you pay and I’m just going to monitor it.” So, I would just boomerang emails back to them every 2–3 weeks, checking on their account, touch base with them. It was a very manual process.
Those people knew we were building something new and we said, “Look. We don’t expect it to be buggy and we test the crap out of this stuff. There is a possibility of bugs, but we don’t expect any.” The people were early adopters, obviously, and the way we hand-picked those people was that I looked at people, a lot of them actually either had a dire need for it or they were folks who ran other SaaS apps.
The reason I did that because I knew that they would give helpful, constructive feedback from a product-minded perspective. I had the luxury of folks on the launch list who, when they gave their email, I could tell that they ran another SaaS app. Again, when you have a lay person, they can know a problem that they have, but they’ll often try to propose a solution and that’s not a good solution for you to build into your product.
Having folks like Ruben Gamez from Bidsketch, Jeff Epstein from Ambassador, Brennan Dunn from then Planscope but now with RightMessage, it’s folks who have a pretty good knowledge of that, and then there were some folks that were from ecommerce and there was a couple of bloggers, but they were all folks who I think had good ideas and, as you said, didn’t have a bunch of noise.
That’s the struggle you run into is if you get 15 or 20 people in there and they’re all have diverse goals—you get a blogger, then you get a photographer, then you get someone who runs ecomm, and you SaaS—they’ll have just wildly different request for you and that starts getting complicated. It starts making it hard to figure out what to do next.
And then really, our beta, I say, truly ran—again it’s called early access—from about July to November. It’s five months long. The reason we did that is we have this big launch list and we were still doing customer development. We hadn’t even proven that we build something people were going to pay for. Podcast hosting existed and you knew that if you build a platform, customers will pay you for it. You just needed a channel. That’s how I would see Castos.
With Drip, we were trying to build something new and I didn’t know if we sent an email to the 3500 person launch list, if everyone would just show up and leave. So, we were pretty cautious about who we let in. Then, we just did 300 people at a time every couple of weeks, let them in, build some features.
That was quite stable during that time. I think we only had one bug that missent email, like double send it to a group or something, which is a big deal. That sucks when you are running an ASP to oversend or to miss a schedule. If someone wants it to send at 11:00 AM and it sends three hours later, that’s a problem. More so than some apps, you have the leeway of it not being mission-critical but any ASP can be that.
It could have been more compressed, for sure. I think that also comes back to Derick and I work 40-hour weeks. If we had worked 70-hour weeks, we probably could have gotten it then in two months, but that was a lifestyle choice. That wasn’t the time when I was going to work long hours. That’s not totally on-topic with beta, but that is how we ran it.
To your other point, you said you beta test features. The answer is yes, we have feature flags from the start where we could just ship something and I’m trying to think about split testing or even automation and such, and it was just a checkbox. In the admin panel we would open it up for three four early access folks, send them an email, “Hey, you have this. Check it out. You want to test it.” Get feedback, iterate quickly, and then slowly either release it to a few more people if you are still in doubt or at that point, then we’d actually launch the feature to the whole audience.
Do you guys do that as well? Are you able to feature gate to specific users?
Craig: Yeah. We’re able to do that to really just the admins. It’s myself and our lead developer. Basically, both who have podcasts, so we’re able to run stuff on our podcasts. I guess we definitely have beta versions of the plugin. We manage a WordPress plugin called Seriously Simple Podcasting that integrates with Castos and we absolutely run beta versions of that on our live and test sites all the time. I think that’s more important because not like a SaaS app where you can ship it and then if it’s not exactly right just fix it, push new code, and everyone is happy.
With a WordPress plugin, people’s sites can break or their podcasting go down or whatever, so we are ultraconservative with what we ship there. We test beta versions of the plugin for weeks sometimes, just on our live site to make sure everything is cool. That’s another thing to consider. So, if you have a Shopify app or a WordPress plugin or something like that, running a proper beta program there is very important for different reasons than a SaaS app where you push it, if it’s nice […] right, just fix it and push it again. That’s what we do a lot of times and it works.
Rob: So, thanks for the question, Cain, I hope that was helpful. We will answer one more question and this one is about podcast sponsorships. He asked it for Startups for the Rest of Us but it’s cool that you’re on the show because you have your own podcast. He says, “I’m a long-time listener on your podcast and I’ve followed your startup journey over the years. I, myself have worked for several VC-backed startups until about 10 years ago when I got interested in bootstrapped companies and decided to be a marketing consultant for non VC-backed companies.
I was recently looking at podcast sponsorship opportunities and I read your FAQ that you’re not interested in sponsors. I thought to reach out more out of curiosity. Why did you decide to not have ads? I assume doing a podcast is a time-consuming effort and while not all endeavors need to be money-making, I’m curious what the motivation is for why you do the podcast. I figure you want to help other entrepreneurs, but is that it?” and that’s from […].
So, Craig, you run a podcast and you don’t sponsors. Why is that?
Craig: We coach a lot of our clients, particularly on the Podcast Motor side of things on the why you do a podcast. I think around monetizing a podcast, there are two distinct routes you can take. One is directly monetizing your podcast which is ads or now becoming more popular is selling premium subscription so you can charge $5 or $10 a month for access to limited content or something like that. That’s directly monetizing your podcast.
The other way that I would argue and the vast majority of situations is more lucrative and maybe easier is to indirectly monetize your podcast with products, or services, or conferences, or membership sites, which is what you guys do. Most or all of our customers at Podcast Motor, which are a lot of startups and successful entrepreneurs that everyone that listens to this podcast has heard of, that’s what they do. We have very, very few people who monetize their podcasts just through advertising or through this premium subscription memberships that are becoming popular now.
I think the reason is you have to have enormous download volume to make good money through sponsorships. I know you guys have a really successful podcast, Rob, but you wouldn’t make nearly the money that you might through other things that you can do with having a whole bunch of people that are interested in what you’re doing. Then you have a conference or a membership site that people can become a part of if they like what they hear on the podcast.
That’s a really natural way to use content marketing and podcasting is a form of content marketing. That’s what we really like to see and is more successful and easier for people to do. I think that’s why you don’t see a lot of ads in podcasts, especially in our space.
Rob: I would second that. I think that’s a good way to think about it. Mike and I toyed around with sponsorships. Some listeners might recall us making an announcement nine months or a year ago and saying, “Hey, were thinking about this. If you want to sponsor, email in,” and we just never made it that far.
We got a few emails and, to be honest, managing a sponsorship program is quite a lot of work. It’s enterprise sales in a way and you’re going to many conversations, there’s going to be lead times. Then you’re going to need to follow-up on invoice and get paid. Then you need to work on ad copy because most people do not know how to advertise on podcast. Typically, the first ad copy you get is not very good, so then you’re rewriting that.
It’s not as if you’re cashing a check for free. It is an amount of effort, it is another side job for two software entrepreneurs who also run multiple conferences, also have a podcast, and also write books. It’s just one more thing to tack on and it’s always been like how much value will this actually provide? So that’s it. I would never say never. Might we have sponsorships someday? Maybe. I’m not opposed to them. I just want them to be a fit and I want them to be the right choice both for us and for the audience.
To you point about monetizing indirectly, when we started the podcast, I remember we had the Micropreneur Academy already and I remember I viewed it as a way to not only build more credibility but also have a more personal connection to the audience that I was already building on the blog.
To be honest, I really did want to build a community of folks like us because I knew five people who are doing what we’re doing in 2009 when I started writing my book. I could list them in one hand of like, “These are the solo software entrepreneurs,” Every time I would hear about one of them, it’s like, “What? This is just crazy. There are that many people.”
As the blog started going and after I published my book, more people started coming out of the woodwork. The podcast I really view it as an avenue to just get more of us together. Of course, in 2011 it was finally like, “I think we might actually get together in a room,” and our delusions of grandeur of 200 people in a room quickly turned into, “Uh-oh. How are we going to sell enough tickets to fill 105 seats?”
I think the first MicroConf […] be 105 and I had to discount tickets late there, but all of that became more important than making a couple of grand a month. I don’t know how much we’d make if we monetize the podcast, but I just think that other stuff is more important than the platform. I don’t do it to directly monetize. I just never thought of it that way.
I do it for all of these other things and it’s to continue to be a voice in the community, but also to continue making sure that this community of bootstrappers, independent startups, and indie funded startups that this thing keeps moving forward. I’m playing long ball and I believe we have decades and decades of growth, and this is the new frontier. 99% of companies don’t need venture funding and that’s us. So, let’s band together.
I don’t know. I don’t want to get grandiose and act like that I hate it. That’s what I thought from day one because it wasn’t that deliberate, but that’s where I see it now and that’s why I’m spending my focus, instead of doing enterprise sales, asking for invoices, and rewriting ad copy, I’m focusing on the MicroConfs, the TinySeed, the blogging, and all the other stuff to try to push that forward.
Craig: Yeah, the leverage we talked about from Meryl’s question, right? That the podcast is your probably biggest form of reach and you’re able to do a lot of things now with it that you could never do just by making some ad money.
Rob: Yeah, it’s a good point. That’s a good question. Thanks for sending it in, […]. Craig, thanks again. That was super fun. As your first Q&A episode, how did that feel?
Craig: It was great, a lot of fun, really interesting questions, and thanks for having me on. It was a blast.
Rob: Absolutely. So, if folks want to know what you’re up to, they can head to castos.com for your podcast hosting services and @TheCraigHewitt on Twitter, is that right?
Craig: That’s it, yup.
Rob: Awesome. Talk to you again soon.
Craig: Thanks, Rob.
Rob: And if you have a question for the show, whether it’s myself or a guest, leave us a voice mail at (888) 801-9690 or email us an MP3, or an Ogg-Vorbis, or attach a Dropbox link, or even just write your question out in text, old school style, questions@startupsfortherestofus.com.
As you know, our theme music is an excerpt from We’re Outta Control by MoOt, used under Creative Commons. You can subscribe to us by searching for ‘startups’ in pretty much any of the podcast players. Visit startupsfortherestofus.com to see our cool, still relatively new website to find a transcript of each episode.
Frankly, just sign-up for the email list. I’ve been emailing just a little bit more but not too much, and I think it’s good to stay in touch with the community. I love it if you would go to startupsfortherestofus.com, enter your email, and we promise to only send you stuff that’s on-topic and relevant for you as a startup founder. Thank you for listening. We’ll see you next time.
Episode 331 | Transitioning from Productized Services to SaaS with Brian Casel

/
Show Notes
In this episode of Startups For The Rest Of Us, Mike interviews Brian Casel, Founder of AudienceOps, about transitioning from productized services to SaaS. Brian discusses what AudienceOps was like 6 months into development, he touches on team management and how he handles developing a new product while supporting an existing one.
Items mentioned in this episode:
- Audience Ops
- Ops Calendar
- Brian on Twitter
- Brian’s website & newsletter
- Brian’s Productize course
- Boostrapped Web Podcast
- Big Snow Tiny Conf
Transcript
Mike [00:00]: In this episode of ‘Startups for The Rest of Us,’ I’m going to be talking to Brian Casel about transitioning from productized services to SaaS. This is ‘Startups for The Rest of Us’ episode 331.
Mike [00:17]: Welcome to ‘Startups for The Rest of Us,’ the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you built your first product or you’re just thinking about it.
I’m Mike.
Brian [00:25]: And I’m Brian.
Mike [00:26]: And we’re here to share experience to help you avoid the same mistakes we’ve made. How are you doing this week, Brian?
Brian [00:30]: Doing good, Mike. Thanks for having me on.
Mike [00:31]: Yeah, no problem. So, for the audience here, in case they’re not familiar with who you are, Brian Casel was the founder of Restaurant Engine which he sold a couple of years ago. He’s also been a speaker at MicroConf and he is the current founder and CEO of Audience Ops. And then he’s also the co-host of Big Snow Tiny Conf which I attended a few weeks ago, and he’s also the co-host of the Bootstrapped Web Podcast with Jordan Gal. Did I leave anything out?
Brian [00:57]: Yup. That’s about everything I’m focused on right now. I also write about productized services and things on personal blog. But yeah, these days I’m really pretty much all in on the audience apps business, that’s what I’ve been doing.
Mike [01:10]: Yup, and we’ll link a bunch of those things up in the show notes. But one of the things I want to talk to you today about was the fact that you’re essentially running a business that is a productized service called Audience Ops. And for the listeners who aren’t familiar with it, can you give a brief description of what Audience Ops is and what it does?
Brian [01:26]: Yeah. So, Audience Ops is a content marketing company. And we’re going on almost two years now since I started it. And so basically, we make it easy for businesses to do content and do it well. And now, as we’re going into 2017 here, we’ve kind of expanded our line of different products to help accomplish that goal. So we’ve had our service side of the business and basically, there are two versions of the service now. There’s the content service where we write the content.
We basically write your blog content for you and manage the whole process from start to finish. And now we have Audience Ops Express where if you’re doing content, you can send us your drafts and we will handle all of the legwork to get it published like proofreading the images, the formatting setup, transcribing your audio or video, whatever it is that you can basically send on limited content pieces to us and we’ll handle all the legwork from there.
So that’s the service side of it. And then this year, we’re now in the process of launching our software called Ops Calendar. And that’s essentially a content calendar tool that streamlines and automates a lot of the parts of the production process for doing content. So it’s got like smart checklist which automate recurring tasks and delegating those based on one year content as publishing. You can track analytics to see traffic and conversion numbers on a post by post basis right there in your calendar.
You can manage a list of content ideas and have those going to your calendar and into production schedule social media. So it kind of pulls all the disjointed pieces of doing content marketing all together in one place. And so that tool has been in development for the last six months. And right now in March 2017, we’re just now rolling it out to – so we’ve had some beta costumers in it and now we’re starting to roll it out to customers on our early access list.
Mike [03:11]: So before Audience Ops, you had run Restaurant Engine. Now, would you have classified that as a productized service?
Brian [03:18]: Yeah. So I think Restaurant Engine evolved into a productized service. It started like purely as a SaaS. It was a website builder for restaurants. And what I learned in the first year or two was that those customers really valued the done-for-you aspect. I was doing concierge onboarding just to get people onboard. Like, we will set up your website for you, started doing that for free just to get them onboard. And then I started charging for it and then we started requiring that service for all customers. And eventually, it became kind of that software plus service productized service model, if you will.
I mean, that’s where I really started to learn the value of combining software with service. So not only providing the tool but providing the done-for-you aspect. But then when I started Audience Ops, having really sunk my teeth into that productized service model, I decided to start that business with the productized service model first as a way to launch it, establish it, grow revenue really quickly and also just grow its, like its brand if you will and our credibility in the content marketing space which now two years into it are what we started this process about 18 months into it, we’re able to expand into other products for this same space doing content marketing.
Mike [04:32]: I think what I find interesting about the journey is that you started out with Restaurant Engine trying to build it into a SaaS product and realized that that was not going to work and you transitioned it into a productized service. And then when you started Audience Ops, you kind of made the deliberate choice of, “Hey, I’m going to create this as a productized service because I know how to sell that.” And then now two years into it, you’re looking at creating a SaaS based on that productized service.
Brian [04:56]: Yeah, essentially. I identified a few specific pain points through the process of delivering our service and doing content on a regular weekly basis, and we’ve used a variety of different tools and we still do. But having identified those pains through the process of doing content, that’s what led to the initial concept for Ops Calendar and then that also led to validating that other people have those pain points too which eventually led to investing and building it and getting it out there.
Mike [05:28]: From I guess a boarder perspective, you seem to have done the gamut of all the different types of products. You’ve had your productized course which is especially an info product. And then you’ve also had a productized service and now you’re working on a SaaS product, and previously as I said before, Restaurant Engine was intended to be a SaaS product and it didn’t turn out that way.
But I guess, could you contrast a little bit the differences between starting in a productized service versus starting a SaaS? Because obviously, I think that there’s timeline differences and there’s experience differences and there’s all these things that go into one versus the other. For the listeners, can you contrast those things a little bit which one’s easier? What are some of the pros and cons of doing a productized service, for example, versus a SaaS application or just kind of the classic SaaS?
Brian [06:13]: Yeah, sure. So, in my view, just from like a viability standpoint, the idea of building and launching a SaaS product requires a pretty heavy investment of time and money. Whether you’re a developer or not, and I consider myself a non-technical founder. I mean, I do the design and the frontend stuff but I don’t code the backend. So in my case to build a SaaS software, I knew going into it, that would require investing quite a bit of money into hiring other developers but also a lot of my time. And I knew from experience of running Restaurant Engine that it takes several months to, maybe longer, to even build the initial version that users can actually use and then a year or longer to even make it a viable recurring revenue business that could potentially replace part or all of your income.
And so, that was the math that I was looking at in 2015, when I was looking to get into my next business. I was considering various ideas. Coming out of Restaurant Engine, I was looking at different ideas of what I should kind of sink my teeth into as my next business. And I look at making it a productized service first because I knew that that’s something that I can actually launch to paying customers very, very quickly, even charge a higher price point for it and have a recurring revenue model with that.
And literally within the first 30 days, we had our first clients onboard for Audience Ops for our done-for-you content service. And that grew pretty quickly over the first 18 months to a point where it enabled me to build a team around it, build a process and a system, and then ultimately, well, really early on, really, I was able to remove myself from the day-to-day process of delivering that service because I had the team and the systems in place.
So that freed me up to focus on growing into other products. I wouldn’t have really been able to make the math work on building a software from the very beginning and that’s why I went with the productized service. But secondly I wouldn’t have identified the pain points associated with doing content in terms of how it would relate to a software tool until a year or two into it. So I think both kind of led to that.
Mike [08:24]: Right. So it’s partially a function of the runway, so to speak, and the time that it takes to get up and running. And then there’s the other side of it is the learning component about how do I actually solve this problem in a way that makes sense for the customers of the product.
Brian [08:38]: Yeah, absolutely. I mean, this is a fully self-funded business. That’s how I’ve always handled it throughout all of my businesses up until now and still going forward. And so, we’re very cash flow sensitive kind of profit first type of mentality from start to finish. And that’s ultimately what made it possible for me to even consider investing thousands of dollars a month to just hire developers, not to mention the cost of marketing a new SaaS product. So yeah, lie this business has been working off of the profits from the productized service and then that continues to fund the development going forward.
Mike [09:13]: One of the things I wanted you to help kind of contrast for the list of terms is the difference in financial and starting that service based or productized service business versus starting a SaaS. So, you’re about six months in on the SaaS application. You said you’re spending a couple of thousand dollars a month for developers. So, ballpark are we talking somewhere between $12,000 and $20,000 that you’ve put into building the SaaS so far?
Brian [09:37]: Yeah. I’d say that’s about accurate probably closer to 20 so far.
Mike [09:41]: Okay. So, about negative 20 and this is after 6 months. And for the Audience Ops service, in six months, roughly what was the revenue?
Brian [09:50]: Well, six months in, it’s probably somewhere around maybe 10k to 15k a month MRR. And so early on in like the first three to six months, I actually took it deliberately very slow. We took on a few clients early on and then we kind of paused the service to get our process as in team employees, and then started to ramp up against starting from six months, probably around the 12-month mark. I think we were up to somewhere around 30k MRR. And I think it was probably around that point, around 10 to 12 months into the business.
I mean, I basically had my own salary kind of covered. I’ve always just kind of paid myself the base amount of what I need to live and support my family. And so, again, as the productized service, I’ve been able to cover that from pretty early on in the business. But then by around 10 to 12 months in is when I started to put aside whatever extra profit that was left over after all expenses were paid from the business and after I was covered. And I’ve put it aside maybe roughly 2,000 to 3,000 a month in profit. And that grew and that deviated from month to month.
So, I started doing that around 10 to 12 months in. And then by around 18 months is when I had a bit of a savings, like a business savings account saved up, and then I invested that to start. That basically jumpstarted the investment into hiring developers, but still through this day, the services continue to fund the development going forward.
Mike [11:19]: Yeah. And I kind of want to make that distinction very clear because just in terms of finances loan, SaaS scene is kind of a holy grail on the software world because it’s recurring revenue. But at the same time, if you’re looking at a productized service, you said to yourself that Audience Ops was making around $15,000 a month and you just literally said, you were taking it slow. You could’ve probably pushed on the gas harder if you wanted to. But six months in, you’re pointing $15,000 a month from it. Whereas six months in on the development of the SaaS, you’re still technically a zero because you’re not charging customers yet. You’ve spent closer to $20,000 on it so you’re at the negative.
And just kind of do the math on those and you’re probably at – if I had a guess, we’re probably at $60,000 in revenue from the productized service versus zero and plus you’re also running the deficit because you’ve spent $20,000 on it. And it’s just a very start contrast between those two things. And I think it begs the question, if you’re doing well with that productized service or it’s easy to build something like that and get it up and running and make it profitable, why would somebody even ever want to do a SaaS?
Brian [12:22]: Yeah, that’s a good question. So, we see this a lot, right? You look at those top-line MRR revenue numbers and they seem so dreamy. I refer it to many and they would seem very dreamy to me looking at it just a couple of years ago. The reality of the productized service model is that there are a lot of cost associated with it. Obviously, there’s more people involved. Like, we have a pretty large team. Our team is fully remove all over the world but all of our writers and all of our project managers are in the U.S.
So as the revenue goes up and as we bring on clients, our costs go up and our team grows. And that’s what led me to the decision that, “Okay, this year in 2017, I need to look at diversifying our product line and growing into more scalable products such as software and even our Audience Ops Express services is a little bit more scalable than our content service.” That’s not other say that the content service is not able grow and scale. It’s just not as scalable as something like a software service.
The tradeoff of course is that the productized service can grow much quicker. It can remain profitable the whole way through. Whereas the SaaS, even if you’re charging somewhere around $99 a month or more for a B2B software which may seem like a relatively higher, I don’t know, these days it’s all relative price points, right, but it just takes a long time to get enough customers to make that viable. And I realized that going in. And so that’s why I continued to work both sides of it basically the service side and the software side.
And with the service especially a recurring productized service, we deal with a lot of the same issues that a typical SaaS would turn and optimizing our onboarding process and retention and that sort of stuff. So yeah, it all kind of plays into it.
Mike [14:14]: Yeah. I mean, I think that there’s that confusion when you start looking at those numbers and saying, “Oh, well, the business is making $15,000 a month and it’s a service business.” But you don’t realize that there’s got to be probably five or six different people involved and they’re all working part-time in a business like that. And it’s the manual labor or just in general the labor cost associated with running any productized service are all around providing those services because it’s not like the software side where whether you’re running something once or 50 million times, it almost doesn’t matter to you. The cost is almost the same versus if you have to pay somebody to do something once, maybe it’s $50. You have to pay them 100 time to do it, it’s 5,000.
Brian [14:54]: Well, yeah. I mean, the way that I was looking at it especially going into this year was as the service keeps growing. Like, if the service were to double or triple in size in terms of clients and revenue, that would mean that our team would close to double at least. And then I started to look at like, “Well, what does that picture look like?” And then that’s just a very large team with lots of people and I wanted to get into. I still want to keep the team relatively small.
The other side of this is people think about productized service is like, “Well, that’s just kind of consulting or that’s like freelancing or building an agency,” and yes, it is manual services. There’s no doubt about that. But the way that I approach it is it’s a very focused, systematic, process driven service where we really do one thing and we have a very defined production line, and I’ve got people in place who handle very specific pieces of the process.
So unlike an agency which might take on anything and everything. If you’re a marketing agency or a design, development agency, like you take on so many different projects and different types of clients, for us, we bring on a client. They go through our standard onboarding process then they go into our standard delivery model for content and production and publishing and it works pretty well. We’ve got a fantastic team of talented people but they all really rely on our processes. And that’s what enables me to not be involved in the day-to-day service stuff.
I do coach the team a bit and I work on our processes and things but my role is really to make sure that the operation runs efficiently and then to free up most of my time to work with the developers and design the SaaS and then think about marketing and all that kind of stuff.
Mike [16:33]: Right. I guess the underlying point there is that when you start a business or anybody starts a business, the person who is the founder generally can do most things. And it’s very easy to, I think, fall onto a trap where you look at something whether it’s a specific problem or a service that somebody’s offering and say, “Well, I can do that faster and cheaper and offer it at even a better price or maybe a higher price,” because you’re offering higher quality. And then you almost trick yourself into thinking that, “Oh, well, if I scale this up, let me just multiply myself by 10 and I’ll have 10 times revenue, 10 times the profit margin.”
And I think what inevitably happens is your profit margins tend to go down because there’s management overhead that you don’t take into account as you build out the team. And I imagine at this point, your Audience Ops is at a point where you’ve got middle management, so to speak, that are managing teams of different people whether writers or the people who are posting the content. I mean, there’s a lot of stuff that goes into it and people don’t take into account that there’s that management overhead that will eat into the profit margins.
Brian[17:32]: Yeah, exactly. I mean, we pay the writers and we also have like client managers who are client facing. So I’ve kind of delegated the client facing communication stuff even like calls and emails and stuff. And then we have a team manager and her job is kind of more internally and she kind of keeps track of the people on the team and keeping them updated. And then I’m looped in like I have every two weeks to do a call with the managers and I’m in touch with everybody on the team pretty regularly.
So, I would say there’s one more piece to this on how the productized service relates to the SaaS. It’s not just about a funding source to invest in the SaaS. It’s also, I built it as Audience Ops the company. We’re a content marketing company and like I said, we wouldn’t have identified the pain points that would led to the SaaS product unless we have done the service. But also, I think it gives us a lot of credibility in terms of building software tools or even our training stuff if we hadn’t done content marketing at this level of scale and we continue to do it and I use content marketing heavily in my previous company.
So I think those kinds, like establishing the service and the company as a content marketing focused company with that sort of credibility leads in nicely to – it’s almost like an obvious next step for us to release software tools for doing content market.
Mike [18:54]: Now, I guess kind of playing off for that a little bit. Because there’s overlap in terms of what the service does and what the Ops Calendar does, what sort of team over lap did you have with the new product, with the calendar itself. Because obviously, you’ve got all the writers and the managers in place to essentially optimize the entire process around publishing content for your customers. How much of that were you able to reuse when building the Ops Calendar?
Brian [19:19]: Yeah, it’s a good question. Really largely, the people working on the Ops Calendar and the service are mostly separate. I mean, we’re all in the same slack room together but I did have to go out and hire. So we have two developers who I brought on specifically to work on Ops Calendar, just given the technology that that’s built with, we didn’t have that type of developer in house. We did have a WordPress developer who I’ve been working on with.
So Audience Ops also sells a couple of small WordPress plug-ins like our content upgrades plug-in and we built and launched that over a year ago at a really great WordPress developer who builds that and he continues to maintain that plug-in. So I did loop him in on Ops Calendar. So we have just released the WordPress integration between our calendar tool and your WordPress site. And so, since he’s the WordPress expert and I had been working with him before, I brought him in just for that piece. But beyond that, really from day to day in terms of developing the product, I’ve been working with the developers and then the team is a bit separate.
I am of course looping the team in on the progress of Ops Calendar and right now as the tool has kind of matured a little bit, now we’re starting to actually work it into our process for delivering content for our clients and for ourselves. And I’m starting to use it for my own content on my own blog. And so the team on Audience Ops is essentially a customer, if you will, of Ops Calendar, obviously we got paying for it but it’s working through a process and clients of Audience Ops service were using Ops Calendar to serve them as well so they could access to it as well.
Mike [21:00]: Right. The underlying challenge I think is that you had to essentially bring on new team members in order to develop this product just because you didn’t have that talent or the focus that you could divide off from what they were currently doing into building this new product. It was really, you bring in a couple of extra people and put an umbrella around them or kind of a small divider that says, “Hey, you guys are going to work over here on this other thing and we’re not going to merge things together or have you guys work together on stuff until you reach a certain point where the product is essentially usable by the team,” and that could take several months between four and six months. You said that you’re at about right now, correct?
Brian [21:38]: Yeah, exactly. Yup.
Mike [21:40]: So, I guess what are the challenges associated with running those two different things side by side, because you’ve obviously got to keep the Audience Ops system up and running and making sure everybody is doing what they’re supposed to do, what your customers are getting service so you’re bringing on new customers. And at the same time, you’re also building this second product that has – I mean, you obviously got like the beta customers who signed up for it and agreed to pay for it early on. But what are the challenges associated with managing those two desperate teams? Because I think that there’s very big differences between them and the goals that they have and the responsibilities?
Brian [22:14]: Yeah. I’d say just the challenge for me personally is managing multiple things at the same time. So I do jump back and forth between working with the team on the service, coaching the managers, or improving our processes and systems there to these days really spending most of my time working with the developers and I handle kind of like the design and the user experience and the product, kind of managing the product on the SaaS side. That’s really where I spend most of my energy. I’d say a third thing that I do is just overall marketing for the business, working at our marketing funnels and making plans there.
Yeah. So I mean, it’s kind of tough to jump back and forth between those things but at the same time, I do think that that’s part of the role of the founder in a way. Obviously, I’m not doing everything myself. A lot of it is kind of managing and giving input on things. So a lot of the technical time-consuming work of coding software or writing content, that stuff is not necessarily on my plate. I’m taking more of a strategic level giving input, giving direction, and that sort of stuff. And that’s what I spend most of my time doing. That’s where I think where I add the most value to the team.
I think that, again, the services and the software are so connected. It’s not like what I did years ago when I was launching Restaurant Engine where I – like on the side I was doing web design consulting work, and then in my nights and weekends or early mornings or whatever, I would plug away at my little SaaS, bootstrapped SaaS startup where they’re completely separate worlds, and I don’t feel like that today. Like today, I’m really just building this Audience Ops business that has a line of different products but they all really serve the same mission which is to make doing content easy and effective for businesses, and yes, just kind of pushing on that in different areas of the business.
Mike [24:07]: So, I guess now that you have built this productized service and then in addition, you went in and started the SaaS application o the side and it’s obviously all in to the same umbrella, I think that there’s definitely a lot of advantages to what you have done versus I think that somebody have talked to MicroConf several years ago about having products that were very, very different from one another and not related. So you couldn’t leverage the same audiences and obviously in this case, you have created things in such a way that those audiences do overlap. They do kind of lead into each other in the same ecosystem. And I’m curious to know what is it that in building the SaaS app kind of under that umbrella, what would you have done differently next time that you maybe saw as mistakes or things that held you back this time going through that process?
Brian [24:52]: I think probably the classic thing that most especially non-technical founders face is just the pace of development. I think I had a bit of a learning curve early on there. And I’m not totally new to developing software. I had worked on Restaurant Engine and other things in the past. But I think on the one hand, we made a pretty good pace. Like, we’re actually launching it to paying customers now six months in, but at the same time, just having an understanding of like, “All right. We’re going to have all these features built out and ready to launch by certain dates.” I had probably two or three months into the development process. I had a wakeup call to see, “Okay. This is actually how long it takes to build even just the baseline architecture and the core parts of the app.”
And then what ends up happening was about four months into development, I decided to hire a second developer. So I have one full-time developer and now the second developer is on part-time just for the sake of increasing speed and being able to have two people work on different features simultaneously. And so that’s helped to speed things up a bit but yeah, that was one of the challenges I think.
Mike [25:56]: It’s interesting that you bring that up because I think you and I had talked a while back about the pace of development and I kind of – I actually warned you at the time because I ran into the exact same thing where I underestimated things and how long they would take and even after that, you kind of experienced the same thing. And I don’t think this is unique. I think that everyone does this to some extent. They look at something and say, “Oh, well, this is how long I think it’s going to take.” And then, things go sideways or there’s other things you just miss and don’t take into account. And it takes so much longer than you ever think that it’s going to. And I’m curious to know what your thoughts on why that is. I have my own thoughts and I kind of want to get your take on it though.
Brian [26:34]: Well, yeah, I mean, I’m sure you’re in tuned with the technical aspects of what takes so long. But for my perspective as, I don’t know, I kind of consider myself a semi-technical person. So –
Mike [26:45]: But I don’t think that that’s the problem. So like I’m a technical person and I still get it wrong. So I’m curious to know like as a non-technical person, what do you see is the problems and then maybe we can kind of collaborate to figure out, “Okay. Why is it that everybody gets this wrong, not just technical or non-technical people?”
Brian [26:59]: Well, I think one reason why we’re actually now able to get it out the door to customers like only 6 months in and not 12 months in is because I’ve started to make more decisions about, what are the features that we actually need and what are the features that can come later. And I think early on, I had a much longer list of features that I wanted to launch with. But now, as we get to this point, I’m a little bit more ruthless about speed and get it out the door. We have a very high bar for quality. So every feature that we do build has to meet a certain level of quality in terms of user experience and functionality and lack of bugs and all that.
But the decision to do that other big feature later instead of now, pushing those things off, definitely helps. And the way that I’ve been able to do that is by really being in constant contact with our customers especially that we have a group of 14 beta customers who prepaid and they were the first users to start using it a couple of months ago. I mean, regular communication with them as well as people on the early access list. And what I’ve been able to find out is there are few features that people just keep upvoting or keep asking about and keep hammering that these are the ones that they really care about. And then are few other features that I think are nice to have that we will certainly use. Other people may find nice to use but they don’t necessarily have to be in this version that we’re sending out to customers today. And so I think there’s that decision process.
I think the other thing is one thing again as like a semi-technical founder in the fact that I had to hire those developers that are new. So that we were just getting to know each other in the first month or two of working together. And part of the reason why it went so slowly early on was because they were not necessarily aware of how technical I could be for them to explain some of the technical challenges.
And so what would happen a couple of times early on was they’d hit some walls, some technical challenges with one of the requirements that I put in. And then they would kind of go and try to work on it and troubleshoot it for three, four, or five days at a time and I’m not aware of what that technical challenge is. But if they brought it to my attention earlier, then I could tell you, “Oh. Well, okay, I understand what the challenge is. We could just tweak the design in this way and just eliminate days of development from a user experience that’s not a big deal.”
So it took about a month or two for me and my developer to really get on the same page in terms of how we can communicate technical challenges. And once we got that kind of squared away, we’re able to move much faster because we actually are able to collaborate on those technical hurdles even though I can’t do the coding myself, I can help think through, “Okay, for a design standpoint, we can re-architect it at this way or, okay, this is what’s really important that that piece is not as important,” and we can communicate that much clear and that helps us move a lot faster.
Mike [29:55]: Yeah. Being able to prioritize those things is kind of critical and so incredibly important to the entire process that it’s hard to underemphasize how much that plays a factor into the speed of the development, how quickly you get things out the door. And one thing that you had said, the one word that jumped out while you’re talking was the word “ruthless” and being ruthless in terms of saying, “We are not going to do that right now because that’s not important.”
And one thing that kind of jumps to mind, Brian, as an example of when I was working on Bluetick was there was a password reset feature that you could literally see on the front page. You go there and you enter in your email address. And you would expect that it would email you and say, “Hey. Here is your new password or here’s a mechanism for using that.” And over the course of nine months, I had literally three people use it and it didn’t work any of those three times because it was never wired up. It was like we never implemented that feature. It was there, you could see it but then I would get emails from people saying, “Hey, I tried the password reset. It didn’t work. How do I get my password reset?” And I would manually do it.
But it would’ve taken a while to get that done. It doesn’t sound hard and it really isn’t but it takes a couple of days to get it right. And that was something, I kind of made the conscious decision to say, “This actually isn’t that important.” It was on the designs so it ended up in the UI. But that’s one of those things where I made the conscious decision that I’m not going to do this. And I’m sure you have your own examples of things where you’re like, “Let’s just remove that.”
Brian [31:20]: Yeah, absolutely. I mean, again, I’m constantly in contact with people who come through the early access list or the beta users and I’m always asking them, “Why are you asking about that? What are you trying to accomplish? Or what was it about the other tools that fell short for you?” And I’m always trying to get their underlying goal or their frustration, and then I’m trying to figure out like, “Well, can our app already do that or what is the feature that they’ll be waiting for?”
Just the other thing that I see just a lot in this community is I think a lack of a sense of urgency. And this comes back to the whole self-funding aspect. I mean, and also from a marketing standpoint and rolling out and launching a new product. I feel the sense of urgency because, A, we can’t just develop this thing forever and not have revenue, that we’ll run out of money too quickly. But B, people are joining this early access list and they’ve been joining it for six months or more and every day that ticks by that I’m not contacting them or inviting them to start using the app, I feel like ticks away at like the chance that they actually will still need the app when I do send them that email invite.
So, I’m trying to minimize that length of time as much as possible and I think right now we’re at the – I think that the app is beyond an MVP stage at this point but it’s like the minimum viable level of development that I can start to have customers use the thing, and even start to give me feedback and objections about, “Okay. Some users may use it but some users still may have objections.” And I’ve been getting that kind of feedback from beta customers but I think now is that next step to get it out the door.
Mike [33:02]: Yeah. I totally agree with what you just said about waiting too long for getting those people in there and having them use it. I mean, I literally run into that with Bluetick where because some of the development cycles took so long and the tech stack just took too long to get pieces in there. It got to the point where some people who were on that early access list, they kind of looked at and said, “Look, it’s been so long that either this just doesn’t turn out to be a need for me right now or it’s not a good fit, or let’s revisit this in a few months because right now it’s not a good time.” It’s disappointing but at the same time I also kind of expected that not every single one of those early access customers would eventually become a paying customer and you have to expect that. But at the same time, because it’s been so long on my side, some of those people are just not going to convert because they’ve either found other solutions or they’ve realized, “Hey, this isn’t actually a dire pressing need that I have.”
Brian [33:53]: Yeah. One thing that I’ve been doing. And so everybody who joins the early access list on the next page, they see a survey. And they’ve answered a bunch of questions that goes to my email inbox. I read and I reply to just about every single one of those. And what I do is, I just place a star on those responses to that survey that I think are just really engaged. And so, the ones who just send like a one-word answer to the questions, I probably won’t star them. But the ones who send three, four, five paragraphs and then they reply to my email and we have a whole email exchange, I give them a star.
And so those are going to be the prioritized people who I invite first and the first batch and the second batch. And so, yeah, I want to make sure that those people who clearly have this pain and they’re actively seeking a solution and they’re willing to give me all this feedback before even seeing the thing, I want to make sure that they get in there first.
Mike [34:45]: Awesome. Well, I guess any parting words of wisdom for somebody who is potentially thinking about transitioning from a productized service into building a SaaS.
Brian [34:55]: Yeah. I mean, again, I think I see it really as that bridge to build the company first and then expand into doing something like a SaaS. And I think the key is to get the productized service running to a point where it doesn’t require you to be in there in the day to day, so that you can free up all that extra time and mental energy to think about, “Okay, where does this thing go next and where are those opportunities for the next product that would make sense in this line of products from this business?” At least that’s how I’ve been thinking about it. And so I think the key is to put those systems in process and in place to free yourself up.
Mike [35:32]: Awesome. Well, Brian, I just want to say thanks a lot for coming on and talking to people about how to transition from a productized service into a SaaS. What are the best places where people can find you if they want to look up more information or get in touch with you about this?
Brian [35:43]: Sure. So, the site is audienceops.com, that’s where the services are and Ops Calendar is over at opscalendar.com. And my personal site is CasJm.com and that’s where I write a lot about productized services and my personal newsletter. And then I co-host the podcast with Jordan Gal, Bootstrapped Web.
Mike [36:03]: And then people can also get in touch with you on Twitter at CasJam, right?
Brian [36:06]: Yes. Yeah. I still use Twitter.
Mike [36:10]: Yes, that’s an iffy question these days. We’ll see what happens with Twitter.
Brian [36:13]: Right.
Mike [36:14]: Well, Brian, again, thanks so much for coming on. I really appreciate it. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from ‘We’re Outta Control’ by MoOt used under creative comments. 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.