For the next 4 weeks, I’ll be releasing an episode on Tuesdays and Thursdays, to gear up for MicroConf on April 9th. These episodes will be focused on self-funded, often solo-founders. Some are on the smaller side, while others have ARRs over 7-figures, but they all have valuable lessons to share for any founder.
If you already have a team or have raised money, don’t skip these weeks. To succeed as a self-funded startup, you need to be hyper focused and these guests share the tactics that have allowed them to build a business with limited resources.
And if you are just starting out, then these guests will help give you a plan of action so you can avoid some of the same mistakes they made.
Regardless of where you’re at with your startup, I know you’ll get actionable lessons out of this series.
Today, on the Early-Stage Founder Show, I’m talking with Mike Taber, co-host of MicroConf and the Startups for the Rest of Us Podcast, founder of Moon River Software, and the author behind The Single Founder Handbook.
In our chat, we talk about Mike’s new startup, Bluetick, and cover everything from how he validated the idea to why having a pre-existing audience isn’t necessarily a big advantage, but where we really dive in is how he handles the balancing act of improving the product while also marketing it.
If you struggle to know where to focus your limited efforts, then this is the episode for you.
00:27 Mike discusses his background and the journey that led him from building custom computers to designing and creating his newest app Bluetick.
- 02:08 History of his consulting business Moon River Consulting.
- 03:24 Emergence as an entrepreneur.
- 04:35 Realization of need for independent income due to global financial instability.
06:19 Mike begins explaining the ins and outs of Bluetick.
- 07:09 Applications for Bluetick and what sets it apart from other automation apps.
- 08:33 Specifically explains how Bluetick is different from cold email tools.
- 08:47 The inspiration for Bluetick.
- 10:39 The main point of Bluetick.
14:22 How Mike validated the need for Bluetick by getting paying customers before making the app.
- 17:36 How Brian Casel used the same validation process for his own app and dangers to look out for.
- 19:14 Why having a pre-existing audience isn't necessarily an advantage when bringing a new app to market.
20:56 The balancing act of growing your product while engaged in marketing.
- 23:00 What Mike would have done differently in building Bluetick if he could make use of hindsight.
- 24:12 Using Upwork to find designers and contractors. The pros and cons.
- 26:40 Where Bluetick is currently in its development.
27:54 Effectively prioritizing your tasks for maximum efficiency.
- 29:32 The basic internal process in five steps.
- 31:52 A word on the importance of leverage.
- 32:55 What needs to be in place before Bluetick is properly launched.
- 35:00 Advice for startup founders in beta.
- 38:15 What do you currently spend too much time doing?
- 39:28 What do you not spend enough time doing?
- 39:35 What are you hoping to accomplish with Bluetick in the next three months?
Aligning Projects with Business Goals by Anthony Eden
Rob Walling on Life After Acquisition(Podcast)
How Mike Taber Funds His Software Company Via Consulting (Podcast)
The UI Audit by Jane Portman
Tiny Marketing Wins by Justin Jackson
SaaS Email Marketing Handbook by Christoph Engelhardt
Where to learn more:
To enter for a chance to win the Online Business Starter Kit, including the four resources listed above, just head to the giveaway page and submit your free entry before 8:00 am Eastern on March 22nd.
Andy: Mike, thanks so much for joining me today.
Mike: Thanks for having me on. I appreciate it.
Andy: So usually I have guests just dive right in to what their current project is, but you have a great story that played a really big role in the self-funded startup world, so I want to make sure that listeners are familiar with that story. So can you just start off by sharing your entrepreneurial journey leading up to your current project of BlueTick. [00: 00: 19]
Mike: How far do you want me to go back?
Andy: I guess we'll do the highlights.
Mike: Let's see here. I guess if we're starting from the very beginning, I think my first business was back in '99. And that was a just a business I started building computers on the side. I was making about $3-400 dollars a piece from each of those computers.
At the time, Dell was selling very crappy hardware. You could make your arguments one way or the other about what they're doing today, but at the time, they were just not very good. And I knew that I could build a white box computer just using off-the-shelf components a lot better. And I had a lot of people coming to me to build gaming machines.
It was kind of like Alienware before Alienware was even around. And I did pretty well with it, but after a couple of years I shut that down. I started a gaming company shortly after that with my cousin, and shut that down several years later. And then in 2005, I ended up going full-time on my business, which I started after working at a funded startup for a couple years. They sold for $75 million dollars and I made out like a bandit with a grand total of, I think, $16 thousand. Which was .0001 percent.
Andy: Most people would assume, hearing you were an early employee at a startup like that, they think you can just go kick back on your yacht and you are set.
Mike: I was the fourth engineer hired and I got almost nothing.
Mike: And it kind of gave me the idea, or the green light that, "Hey look, you can still be that early founder and it doesn't matter. You really need to be the founder if you're going to go for a funded startup and make a lot of money from it when it sells.
Andy: From there you launched Moon River Consulting and what was that?
Mike: So I actually owned two different businesses at the same time. Moon River Software started in 2005, and the oddly named company was doing consulting at the time. And then a couple years later, I decided there was enough consulting businesses that I should spin it off into it's own division, and I started Moon River Consulting as a separate S corporation. It had relationships with Alterra and Symantec and several others. It was more of an enterprise consulting arrangement more than anything else.
We just had a bunch of partners and we were very specialized in a couple of different products. There was really nobody else in the world that could do what we were doing, and although several of them tried, they really just couldn't replicate it because a lot of that consulting was based on the product that I had helped build from 2003 – 2005 before it sold. So, because of that in-depth knowledge, I knew exactly how things worked, because I had helped build it. And it was very difficult to translate that to other people who weren't working directly with me.
Andy: What was the journey like from there, where you're selling your time pretty much, your expertise that you developed while building a product for somebody else? How did you go from that to then really being entrepreneurial in the sense of building your own products?
Mike: Well around that time, it was about the time that Basecamp had come out and started selling some of the related things that they were coming out with. Obviously they developed Ruby On Rails about that time, and it was probably about that time that I recognized it's possible to build small products and put them out there and make a living doing that.
And in 2008 time-frame my consultant business essentially tanked, because the entire world economy tanked. And I realized very, very quickly over the course of three or four months where I went from $90,000 in the black to about $150,000 swing the other way. And I went almost six-figures into the red in the space of four months. Just because of payroll associated with the business and I realized very quickly that that business — if people cut back on consulting or the economy starts to go down, consulting businesses are the first ones to go. That's the first expense that they're going to cut.
It made me really think about it and say, "How do I want to be reliant upon people around me?" and I realized that building those products and having that source of income that was independent of the other things that were going on was really the way to go. But, it took me awhile to figure out how to do that and what to do.
I started working around that time with Rob Wallin who is the founder of HitTail, founder of Drip. He has probably another dozen things that he's launched as well. But he and I worked together to put together the Micropreneur Academy back in 2009, and it was essentially to help us understand how to sell software better, but to also teach people what we were learning.
So we built over the course of a year, we came out with [inaudible 00: 05: 11] Podcast a year later and then in 2011we launched MicroConf to help self-funded startups have a place to go where they could find other people. And throughout that entire time, I've been building small products here and there and launching them and learning more. The most recent one which we'll probably talk about a little bit more, which is Bluetick, which is for warm lead follow-up.
Andy: And so, looking at your website and hearing you talk, this was definitely a level view of that journey, and if people want to get more details into that [00: 05: 43] I'll link up to some of the interviews you did with Robb and some of the other resources where you go deeper into those things.
But truly, you and Robb both have done a lot to advance the solo-founder and self-funded startup movement. And MicroConf is coming up in, at the time of this recording, about a month. We were talking before this call about how excited I am for that. So listeners, check out that stuff, there's a lot of great material that Mike and Robb have both put out there. But for today, let's just dive into Bluetick. First the question, what is Bluetick?
Mike: So Bluetick is a tool for automating your follow-up sequences. It's aimed at people who are doing those personalized follow-ups. There's a big difference between something that you're going to use for your newsletter, whether it's MailChimp or AWebber or Constant Contact, or Drip or any of these other marketing automation tools, where the idea is that you want to kind of cast a wide net, and get people interested and nurture them over time.
At some point in that customer's journey, they essentially convert over to the point where you're going to have that one on one conversation with them. And in an effort to get them either to a demo or get them into a trail, or maybe it's just a services engagement where you're trying to figure out, "Ok we understand what it is that's supposed to be done, let's put a proposal in front of you and see what you think of it and then try to get to a purchase agreement."
So there are several places where it could be used, but it's more in conjunction with marketing automation software instead of a replacement for it. And that's a key piece that some people look at and say, "Well why would I use that, I've got Drip?"
And it's for those situations where you want to do that personalized automation, but the volume is too high for you to basically stay on top of, and it's difficult to do that when you start scaling it up. If you've only got five people that you're talking to, it's not a big deal. If you have 50 or 100, or 1000 that are coming to you on a weekly or a monthly basis, it's really, really difficult to keep up with those. I've talked to people who are spending four or five hours a day, every single day, just sending out emails to follow up with people. They say, "Well I sent out three emails to this person, they haven't gotten back to me yet." And then they have to follow up with the people who actually are responding to them. It's just difficult to manage that once you get to a certain scale.
Andy: For me, whenever I hear about automated email follow-ups and that sort of thing, I immediately think of the dozens and dozens and dozens of tools that are up there for cold email. I know this is not that. This is not necessarily a cold email tool, but for listeners who aren't quite sure how it fits in to the puzzle, can you explain what makes it different from some of those other cold email tools.
Mike: Yeah, so the basic technology or process is almost identical. So that's why when you look at something like Bluetick, you immediately think of cold, outbound emails, because that's typically what it's used for. What I found was, and I'll give you the specific use case for me that kind of came up that led me to develop Bluetick, was the fact that when we run MicroConf, we have a list of people that have sponsored MicroConf in the past, or who we would like to bring on as sponsors, and I have to send them emails and say, "Hey, can we get on a call and talk, I want to see if you'd be interested in sponsoring MicroConf. Here's the rate card, etc." But there's a process to that conversation. So, depending on whether or not the person has sponsored in the past, or if they are a new potential sponsor, there's essentially two different directions that you can go with that conversation, and two different places where that conversation is going to start.
So in Bluetick, you would set that up as two different email sequences. One of them aimed at one type of person, the other one aimed at the other. The goal is to get them to a phone call or a conversation, but even before you get to that, you really need them to buy into it and you need a response of some kind. And if you don't get it, you need to email them again, and some of these people are people that I know. I know them personally, I work with them on a personal level or a professional level, and what tends to happen is that people will see the email and they say, "Oh it's Mike, I'll get back to this later today, it's not a big deal if it waits."
Which is fine, I have no issue with that, however, I do need an answer. So, at some point I need to make a decision, I need to follow up because this has slipped down so far in this person's radar that it's not at the top again. So, that little reminder there that comes from Bluetick that says, "Hey just wanted to check in to see if you've taken a look at this yet." And they say, "Oh shoot, I forgot. I didn't get back to Mike last week. I meant to, let me do it now." Or, after the third email, or the fourth email.
And I've had some people go through five, six, seven emails before they finally get back to me. Just because they've been busy, then they were on vacation, and sometimes it just takes those little warm touches, so to speak, to make sure that that conversation advances.
And that's really the point of Bluetick. To make sure the conversation advances and you're getting the responses back that you need in order to move the person through the sales funnel. And that moving them through could be moving them to a "no". That's fine, but it's better to be actively told no than to just assume the person says no because you didn't ask them yet.
Andy: Right. And I mean, looking to what you had said before we got on the call about how it's different. You mentioned that other cold email tools primarily focused on just on getting a reply. They're going to send this follow up sequence until they get a reply and then that's it, it's done, the tool's pretty much over with at that point.
But you were talking about how, really just following up the process around whether or not the prospect actually did something, which could be a reply, but it could also be something like filling out a form, filling out a survey, scheduling a meeting or something. You also have a Zapier integration that allows it to trigger different goals, and that alone seems a lot different than the other approaches out there, because it's not always just about that reply. Sometimes it is just collecting data, sometimes they do just need to submit something. And if you are just following up endlessly until they actually reply to the email, that's not the best use case. So, I thought that was a cool distinction that you made. I like how you have it all set up, because it honestly makes sense to me.
Mike: Yeah, and that's a very difficult concept to get across to people. Especially when you're trying to make it a short, succinct description of what it is. People say, "Could you please describe Bluetick in a sentence or two," and it's difficult to do that because you almost have to have a basis of understanding of what you're talking about when you're trying to explain it to somebody. You need to make sure that they understand what you're saying and that the terminology is level sense so to speak. Once you have that, then you can kind of go into the description of what it does.
At its core, Bluetick is really a goal-based automation sequence for personal follow-ups. I almost feel like there's too many buzzwords in there, to be perfectly honest, but the reality is the goal in most cases is going to be you want to reply.
But as you said, you can embed the links in there that take it out to Calendly or YouCanBook.Me or where ever, and you can embed in that URL that so and so clicked this link, so it's attached to that direct person, and then when they go through and they schedule the call, for example, it will go through Zapier. Zapier feeds back into Bluetick and says, "Hey mark this person as goal completed in this sequence," and if appropriate, move them to another sequence or just pull them out of it.
There's lots of things you can do there at that point, but it's really, at the core, automating that sales process. And you have to understand what your sales process looks like. It's not a silver bullet, it's not going to solve a lot of your problems, you have to know what your problem is first and then see if Bluetick is an appropriate solution. Because it may not be.
Andy: And so this came out of a personal need. It was something that you saw when you were following up with sponsors. How big of a pain it was to handle manually. I know a lot of people, even in the early stages of a startup, will just use something like Trello to keep track of who they need to contact. I feel like I remember hearing a story from Nathan Barry, where even as ConvertKit was scaling pretty quickly, he was tracking everything in Trello. "Oh I need a follow up with these people, I need to do this, I need to do that."
Those systems can get unwieldy very quickly, so this came out of your own need, but once you started developing it and once you had that NVP, what was the process of actually bringing people into the product to use it?
Mike: So, I guess I'll go back a little bit before that. In order to validate the product, I actually got over a dozen people to pay me up front for it. And that's not something I've heard any other people doing. I've heard people talk about that, and say, "Yes, that's a good idea, you should do that," but I never actually heard of anybody pointing to someone who says, "Yes I did this and this is what the results of it were." So, to my knowledge I'm the first one that I can verifiably point to and say, "Hey this person did that." But I literally took people's money before I even had a product. I had not even written code yet and I had people's money in hand and credit cards.
Andy: How did that go?
Mike: So, the interesting thing is, what I did was I basically followed my process that I was going to build Bluetick based on. So I had this process of where I had a spreadsheet and I had all these people's names that I was following up with, and then the number of times I contacted them, where it was in the sales process. And I used that process to follow up with people to get them to the demo, to get them to the point where I said, "Hey is this a problem you're interested in solving, yes or no?"
And if they said yes, I put them on a list and just marked them, and then I spent about a week or two building Balsamiq mock-ups, which, if you're not familiar with Balsamiq, is a wire-framing tool that allows you build and mock up what the UI for an application looks like.
And I spent a week and a half, two weeks building that and then I went back to them and said, "Hey, this is what the application is going to look like, what do you think?" And if they said, "Great, it looks like it would solve my problems," I said "Awesome, here's a webpage, are you willing to pre-pay for it?"
And I asked them for at least one month of prepaid service, they could select up to six. Most people selected either two or three, most of them were around three. I think I had nine people give me three months of pre-payments, two people gave me two months, and then one person gave me one month. And then over time, of course, that increased, but the validation that I got there was, yes, this is something people have a problem with and they're willing to pay for it.
Andy: It's funny that you mention that because I was actually talking with Brian Cassel and for his new product, The Ops Calendar, that's a very similar process to what he followed. Actually getting people to pay up front. I know exactly what you're saying. This was something I was thinking about when Brian was talking about it. I hear so much of the startup advice, especially for self-funded companies, is you need to validate.
And don't just validate by asking people if they're interested, you validate by asking them to take out their credit card and pay. But I've heard very few examples of people doing that. So it's cool to see you following what others are preaching and seeing how that works as an early way to make sure you're actually on to something. Because so many people will say, "Oh yeah, yeah, this sounds really interesting, let me know when you release it." They might just want to be polite. They don't want to say, "Oh I don't actually want this," but getting the credit card out, asking them to pay is where the real pains come out. Because if it doesn't actually solve that painful of a problem, they're probably not going to pay. It might be interesting, but they're not going to take the time to use it.
Mike: It's funny you mention Brian Cassel, because he called me up before he went through that process and he grilled me on what I had done to pre-sell Bluetick. So I had a pretty extended conversation with him about that, and it's great to see that it worked out. It seems to have been working out for him as well, and that's probably something I'm going to be talking a little bit more at MicroConf, but I think that the basic idea of doing that is sound.
There is some danger in doing that and assuming that everything is going to work out. So, for example, not every single one of those people is going to convert into a paying customer. And depending on who they are, they may want to just support you and aren't necessarily as interested in using the product. They may think it's interesting, and would like to give it a shot and support you, but that's not necessarily the right person to sign on for that. So, I will put that up as a red flag that that's not a full-proof plan. It's better than nothing, and it's better than just building something for nine months heads down and then realizing nobody is going to pay for it, but there are still problems with it. There's some refinements that need to be made.
Andy: Right, and it's something you and Brian both have. Audiences of people who look to hear what you're saying on different topics. For you, it's a lot of the self-funded, solo founder, thought leadership that you put out there, and for Brian it's a lot on the product ties, consulting and on content marketing. So with that, obviously having an audience that you can launch to is a huge leg up over just going in cold.
Mike: I actually disagree with that.
Andy: You think so?
Mike: Yeah. I disagree with that. I believe that it will help you get some initial traction, especially if you can pinpoint people in your audience that you believe can use it, and you can solve their problem, because you have the relationship to go to them and say, "Hey can I just talk to you for a little while, versus going to a cold lead that maybe you acquired through a Facebook ad or a Twitter ad and they have no idea who you are. It just makes it easier to have those conversations or at least to get in the door and have that conversation, but I don't think that, again it's a double-edged sword because some people will just give you money to help you out.
Andy: That's what I was going to dig into, because I know with Brendan Dunn's stuff, I have learned so much from Brendan and if he puts out a new product, I will almost just buy it, partly to support him, but also because he does a lot of cool stuff, I want check this out, but it's not necessarily me saying this is something hugely valuable to me. It's not as much validation, it's more saying, "I trust you, I'm going to give it a shot" but it's not as big of an endorsement as if I'd never heard of you or what you were working on before then.
Mike: That's totally right. I definitely hear what you're saying there.
Andy: And so it's an interesting take, because that is something where a lot of people don't talk about that either. First they talk about pre-selling, then no one actually does it, and then second, they don't mention some of the double-edged sword aspects of the pre-selling. Sometimes, if you do have this audience, people might want to support you and aren't truly endorsing the product so I'm glad we talked about that distinction and went into that a bit.
What I want to go to next is the struggles you've run into growing the product while doing marketing tasks as well. That was one thing we talked about before, which is how you balance that while being a solo-founder. So can you speak to that all Mike?
Mike: So in the early days of the development, when I had pre-sold Bluetick I literally had nothing more than the Balsamiq mock-ups, and that's what people were paying for. Essentially, the idea, the concept, and what was going to be built, and once I got what I felt was a critical mass, which was I think I got to 10-12 paying people before I decided to move forward, but what I did was, I went on to Upwork and I hired three developers to start building it.
And the time-frame was really short and I knew that. It was very aggressive. We were going to try and build this thing and get at least a minimal working prototype out the door in about three months. So while they were doing that, I was supposed to be doing customer development and trying to acquire more people through marketing efforts. But what ended up happening, is I ended up doing a lot of time micro-managing the developers, because I was not nearly as clear about what the vision for the product was and how everything needed to work.
And I was kind of trusting their expertise and experience to work together and collaborate to build out some of the more complicated pieces. Because the product has turned out to be much more complicated than I had originally envisioned, and unfortunately turning all of that technology stack over to them turned out to be a mistake. I ended up spending the next six months after they had gotten the minimal prototype going through and fixing things and adding things that should have been built that weren't, or making things work. Adding in unit testing, fixing bugs, and there was a lot of things wrong.
That was the early struggles that I had with it, after those six months, which kind of put me at the end of 2016, things got significantly better, but it was a long painful struggle until the product got to a point where I felt like, "Hey this is actually solving that people are probably willing to pay for."
Andy: Would you have done something differently at that point? Looking back on it now, would you have tried to do more of the development yourself rather than Upwork? What would you have done differently?
Mike: I probably would have spent more time building out the specs and specifically what needed to be built, and how. That's probably the struggle that I had, I was trying to move quicker than I should have, and instead of taking the time to basically design everything right the first time, I kind of through it at them and said, "Hey you guys know what you're doing, at least at a technical level, so go ahead and put this together."
But because they hadn't had the conversations with the customers, I hadn't effectively translated that to them. So they didn't really understand what it was that they were supposed to be building, or why, or rationale. The unfortunate thing with contractors that you'll tend to run into, is that depending on who they are, sometimes they feel leery of just burning time, for example, or figuring things out, or prototyping. They don't want to try something and not have it correct, so they will do things, that are quite frankly, the wrong things to do. Or they won't research what the different options are and then pick the best one. Because they don't want to waste your money.
Andy: They want to focus on activity. They want to write code.
Mike: Yes. Yes. And it's very difficult, in some cases, to make them understand that what you're looking for is, "I want the best solution that you can come up with and even if that means going in a few different directions and back-peddling, that's ok." But some, especially the contractors you find on Upwork, they tend to not want to do that because of the terms and conditions ,and what they're used to working with. People just want something done. They want to be measured on activity.
Andy: And that's the thing, is that so many of the ways that people complain about contractors, especially through sites like Upwork, those behaviours are developed because of the way many, many, many clients treat them. Where it's that, they'll look at the screen shots and they're say, "what were you searching around for this for a half an hour? I don't want to pay for that, I pay for you to write code."
For someone who knows software, like you, someone who understands that there is some research needed to go along to make sure you're building the right thing. That's crazy. But they're doing that for a reason and now that you're familiar with that, I'm sure there's — you would have had a different plan going in on how to handle those contractors.
Mike: Yeah, it's something I kind of new in the back of my mind, like I said, I felt like I was going to stay as much away from the technology stack as I possibly could, because one of my previous startups kind of flamed out and burned hard, and I spent way too much time trying to build it. I probably spent three or four years trying to build it and market it and it never really went anywhere.
And Bluetick has, I'll say, significantly more traction, much earlier. And that's a great thing to see but at the same time, I'm still juggling a lot of things. I'm still getting pulled in a lot of different directions and really, you kind of alluded to this, but at the end of the day, the failure of those developers is not because they didn't do the right things, it's more because I didn't provide them with the right direction. So that's my fault. That's not really their fault.
Ultimately, you have to take the responsibility for the errors in your own startup and move forward with them. You can't dwell on them too much. You have to move forward. I would not have changed outsourcing it, I might have changed the process of how I did it and what I gave to them.
Andy: Once you did have a more stable product out there, you mentioned you were juggling a lot of different things. What are some of those responsibilities? What is taking up your time today?
Mike: Right now, it's mostly edge case bug fixes, and sorting through how to prioritize certain things that need to go into the product that customers are asking for. Then I'm trying to balance that with the marketing efforts to onboard more customers.
One of the things you run into, is that if somebody runs into a bug, you know what the bug is, you don't want other people to run into it, so you're somewhat hesitant to onboard more customers, because you know they're probably going to run into that bug as well. So, it's a very delicate balancing act between, "Can I live with this bug and the possibility that somebody else that I onboard is going to run into it, or is that ok, can I fix it on the back end?"
How much time and effort is it going to fix? Let's say something is busted and you can do it but the customer can't. Are you going to have to field their support requests for it? Maybe you won't. Let's say it's an import problem. If they don't use the import feature it doesn't matter. You have to balance those things and juggling back and forth between them, especially with a complicated code base is really, really hard.
Andy: And so how do you prioritize what to work on? How do you prioritize these bugs that need to get done before making a push with marketing? Because you think they need to be solved, otherwise more people are going to have these issues. How do you know that's the case? What framework, how do you think through those questions?
Mike: Give me one second here. I'm just looking at my spreadsheet here. I'm more than happy to share this with people. I did not write it. I'm just trying to look up the guys name so I can give credit where credit is due. Here it is. So in terms of prioritization, there's a link that I can give you that's a blog post that's written by Anthony Eden. He shared it either on his blog or on a DNSimple.com website.
He walked through this process that they've started using internally to prioritize things. I essentially adapted that process that he came up with to help me understand and objectively prioritize things that I'm working on.
The basic process is, you write down the things that need to be done and then there's five different categories that you can rate each of those individual tasks. And they call them projects, but they're a bigger company, so it works for them to do that. Essentially you rate of those individual things and these five categories.
The first one's profit impact. The second one's urgency, the third one is the risk factor of current operations, the fourth one is growth contribution, which is how much of an impact it's going to make on the growth of the business overall moving forward in the long-term, and then the fifth one is effort. How much effort is it going to take to build that. And once you start objectively putting numbers on each of those things, there's a quick calculation you can use to get to a score.
And it can become very, very evident, very quickly, which things are really important and which ones you feel are important that actually aren't. And that objectivity is huge. It's something I've struggled with quite a bit, it's like "Oh, this really needs to be fixed", and then I start going through and I start putting numbers on these and I realize that I feel that it's important, but it's really not. The customers are not telling me that it's important, and it's not going to impact the growth, it's not going to impact profit. Is it really that important? And the score tells me that it's not. I feel that it is, but if I can't justify giving that a higher score on certain things, then it's really not.
Andy: And it's something where I think any early stage founder is going to feel like they're being pulled in a lot of different directions. That's just the nature of running a small, growing startup at these stages. There's a lot you need to do.
And there's a couple ways you can do it. One, which is pretty common. Just putting out whatever fires come up in the order that they come up. If something happens, you fix that immediately. But that doesn't really get you ahead. That's not deliberate. That's not the best way of doing it.
Having some sort of framework where you can take a step back, be deliberate about your process, prioritize things, and make sure that what you're working on right now is the most leverageable, is the best thing to work on, I think just puts you at a huge advantage. So I appreciate you sharing that framework, because that is something that a lot of people lack. And it's easier just in the moment to fly by the seat of your pants, but you are not going to be thanking yourself for doing that down the road.
Mike: The word that you used there is leverage, and that's exactly the right one to use in this particular case. It's one of those features or tasks that are going to provide you the most leverage. And if you're focusing on the things that are not, so for example, "Is this the right image I should be using on the billing page?" That has zero billing on how well things are going to go for you. Until you get much, much further down the road to the point where you are doing optimizations, it has no impact whatsoever. So, that should go way, way at the bottom of the list. But sometimes we get into the moment and we feel like something is important, and it's not. Being able to have this as an objective benchmark, that's the really important piece of it and it just helps give you that sense of, "I'm making the right decision here. And I also separate between technical tasks and marketing tasks and even between technical and marketing tasks, you can see, "Ok these marketing tasks are way more important than these technical tasks."
Andy: Do you have a certain point in mind where once these features are done, once these bugs are fixed, once xyz happen, you'll be ready to do a true, full public launch?
Mike: It's a good question. I feel like I need a certain — it's not really about the features that are in place, it's more about the traction with the existing users, and are enough people using it on a very regular basis and are they happy with it. And do I feel that I have the marketing messages in place that are going to be able to amplify the product and amplify each other in such a way that I can move dramatically quicker when it comes to the marketing and scaling efforts.
The technical side of stuff, there's always going to be new features that need to be added, there's always going to be new bugs that need to be fixed, and that kind of goes back to that idea of having this objective benchmark of what things you should be working on versus which ones can wait 'till down the road, because there's always going to be more work to do.
Theoretically, you can push off launching your product for years and years, because there's always more to do. For me, it's more about getting to a certain number of paying customers and then at that point, scaling up the marketing efforts, because when I feel like when I get to that point, enough people will have been exercising the product that I know where the problems are in terms of on-boarding, so there's a few core things that somebody needs to do inside of my product effectively, and if they don't do those things, then they're not going to be successful with it.
So, I need to figure out what those are and part of doing that is on-boarding people, see where they run into problems, tweak the product a little bit, make messaging or error messages clearer, or icons and things like that so they can use the product more effectively. And once they have that, and I add another person in and they don't run into those things, they're going to run into them further down the road.
But once all those things are straightened out, that's when I feel that the product will be in better position and it's really about through-put. It's just getting people in, using it. It's not about features or anything like that, because it's hard to predict what they really need and what things on the page are going to impact how they use it.
Andy: True. I like how you say it wasn't about features. And this goes back to something you had said before the call that you could ramp up marketing right now and just have people pour in, but if they're just churning out right away because the on-boarding's not where it needs to be, because of something that you're missing, it's a waste of time, effort, resources, all of that. So I like how you said you want to make sure that you've learned enough so that you can avoid as much of that early churn as possible.
So for some parting advice for founders, who are struggling with that decision: Should we launch or should we stay in the smaller beta, what would you recommend that they think about to make that decision?
Mike: I would look at how many people you're on-boarding and whether or not they're doing the things that you need them to do. I wrote a kind of an in-application dashboard that allows me to go in and essentially see a lot of relevant stats.
I get emails on a daily basis that tells me what users are doing inside the app. Those types of things, the users never see, but they're critically important for you as the founder to understand how people are using the app. And if they're not using it, there's a problem with the app, or you're not solving the right problems for the customer. So I would look at those things first, and again, this advice is probably for people who are really in that early stage where you're either just about to launch, or you're in the process of launching. You're really not full-time on the product yet. But that stuff that is really important to pay attention to. Before you even start writing code for anything, think about how many customers are actually going to see or use that and is it important to do that now. Can it wait?
And that goes back to being objective about the features, because you can build the best feature in the world, but if nobody hears about it, then it doesn't matter, it doesn't exist. So, really think about does this need to be done? Honestly, I have a bunch of paying customers, I still don't have a way for people to sign up in the application and get an account created for themselves. That's kind of manual. You can't update your billing information. I went nine months without having the password reset link work. The page was there, you could click through it, it just didn't work. So, think about whether anyone is going to use this piece of it and is it going to move the needle for you. Because if it's not, it's not worth doing.
Andy: I think that sums it all up. You need to deliver and really find ways to be objective about what will or will not move the needle. For the prioritization framework, that's a great way of being objective about things. But the other part is you just need to see what people are doing. You might be able to say, if I can get people to do this, then everything is great. If they follow this on-boarding sequence, it's perfect, but if they don't actually follow it in practice in their use of the app, then you need to go back and figure out why. And really re-evaluate that. So you gave us a ton there Mike, and I really appreciate that.
But before we wrap up, I like to ask all of my guests a few rapid fire questions. I'll go through them quickly, but your answers don't need to be short.
The first one is, what do you currently spend too much time doing?
Mike: Going back and forth between things. I'm juggling way too many things right now. So MicroConf is coming up and I'm dealing with all the sponsors with that. And I've got to do the support for Bluetick, plus some of the feature development, plus the marketing. So, I spend a lot of time, I'l say contact switching between those things. That's probably the place where I spend the most time.
So, I've tried to alleviate that by dedicating certain days to doing certain things. So, like Monday is marketing Monday for me, and Tuesday I try to go through and fix bugs inside the product. Wednesday is either feature development or more bug fixes, and then Thursdays are reviewing what my sales funnel looks like and following up with people as needed, or double checking my automation stuff is in place.
So I kind of alternate back and forth, but that time boxing tends to help to some extent. But I still get pulled in. Somebody drops an email to me in the middle of the day, and it's on a Thursday or a Friday and it's from a sponsor. I kind of need to deal with it. That contact switch is really, really hard though.
Andy: What do you not spend enough time doing?
Mike: Well, the opposite of that would be getting the work done.
Andy: What are you hoping to accomplish with Bluetick in the next three months?
Mike: My goal is to get it to the point where the on-boarding itself is ironed out and I feel comfortable going to a larger list and just emailing them and having more of an open invite. I've not yet put it in front of somebody, where I've said, just go to town and let me know what you run into. So, that's something that I'm looking forward to getting to a point of doing, but I'm not there yet, so I still do manual on-boarding with people. I still walk them through their application and help them set up certain things, because it's not intuitive.
Andy: So what is the biggest obstacle to you getting there? Is it just finding the time or getting enough learning to improve the manual on-boarding, or what is it you see as the biggest potential obstacle for allowing you to do that?
Mike: It's learning enough about what the problems are. So, I'll give you a prime example of setting up your mailbox. It's something inside the application that you have to do in order to use it. You literally can't use the application unless you've done that. The problem is that I haven't put enough people through that process in order to understand all of the different problems that they're going to run into. So, I can put somebody through it and say, "Hey let me know what you run into", but when they only ever do that once in the application, but it is the biggest roadblock to using it, I feel compelled to walk them through it and make sure that it gets done.
So, backing off of that is going to be important, but I just don't have enough data to figure out what are all the things that need to be fixed here, or how can I set up the automation such that if they don't do that, then it sends them an email, or walks them through it or sends them videos. Things like that. I just don't have enough data points really.
Andy: Interesting. Honestly, Mike, you gave us so much today, so first I want to say thank you for your time and coming on the show. If listeners do want to learn more and hear more from you, see just what you're up to, where are the best places for them to go?
Mike: There's a couple of them. The first one is probably to my blog. I've got a newsletter there that people can sign up for. You can go over to SingleFounder.com. I'm also on Twitter. The handle is @SingleFounder. If you're interested in taking a look, I've also got a book called, "The Single Founder Handbook" at SingleFounderHandbook.com. I think that's probably it.
Andy: I know also that, speaking of the book, I was speaking with Kristoph last week and so you guys are doing a giveaway. Can you speak about that?
Mike: Yeah! So what we did was Kristoph, Justin Jackson and James Portman and I got together and we're offering a give-away for people and it's called, "The Online Business Startup-Kit Giveaway" and it includes James' "UI Audit" book, and it includes Justin Jackson's, "Tiny Marketing Wins" and includes my SingleFounder Handbook, and it also includes Kristoph's "SaaS Email Marketing Handbook".
The goal of these books and courses is to give you everything you need to start and grow a successful business online. From your mindset all the way through to the design of the application, email marketing, and then improving your marketing over time, so you that you can add more customers to your product.
We're doing this giveaway until the end of the month. I forget when it ends. I think it's March 22nd. So, you can go over to GiveAway.SaasEmailMarketing.Net and that will probably make it into the show notes I assume. So you go over there and sign up for it. We're giving away the hirer tier packages for that. It's $800 or $900 worth of books and courses that you can get for free.
Andy: Like you said, I'll make sure to get all of that linked up in the show notes. Honestly, there's a ton in that package. If you enjoyed any of the tidbits that Mike gave in this interview, definitely check out the giveaway and definitely check out his book, because there is much, much more in there. So I'll get all of that linked up in the show notes so it is easy for you to find. But Mike, thank you so much for taking the time and talking to me today.
Mike: Yeah, no problem. One other resource that people might want to go to is MicroConf.com and up in the header navigation, there is a link to videos and we make all the videos for all the past MicroConfs back to 2012 publicly available. So, if you're interested in watching any of those, there's probably 40 or 50 hours worth of videos that are from founders who have spoken at MicroConf that you can go and learn from those guys for free.
Andy: And there's a ton of great content there. Watching those videos is actually got me to my first MicroConf about three years back, and so I'm really excited to get back there and I would encourage all of the listeners to check out some of those resources. So again, Mike, thank you so much.
Mike: No problem, thanks a lot for having me