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.
