Episode 127 | 7 Tips for Finishing Your Product

Show Notes


[00:00] Mike: This is Startups for the Rest of Us: Episode 127.

[00:02] Music

[00:10] Mike: Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product or you’re just thinking about it. I’m Mike.

[00:17] Rob: And I’m Rob.

[00:18] Mike: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s up this week, Rob?

[00:22] Rob: Well, what’s up because I heard you’re working from a brand new piece of hardware. You ditched the MacBook Air —

[00:27] Mike: For a MacBook Pro right now —

[00:29] Rob: Oh, geez —

[00:29] Mike: I saw that guy on Twitter who had mentioned that I was probably going to have to now that you’ve got your new MacBook Air and probably, you know, I just followed his advice. It really what it was. [Laughter]

[00:36] Rob: You heard that I had 8 gigs of RAM and have to — about hard drive and got jealous?

[00:40] Mike: Yup, I did. So now, I’ve get 16 gigs of RAM. So —

[00:43] Rob: That’s so unbelievable, man. Yeah, that’s a great piece of machinery.

[00:46] Mike: If I had the model that you have right now, I probably wouldn’t have bothered to upgrade but disk I/O on the new machine that I just got has three times of what it was on my old MacBook Air which the model that you have is newer. So, you know, it has better disk I/O more RAM and all these other things. So, if I had that one, I probably wouldn’t have upgrade it but this is a little over two years old at this point and there were some things that I needed to be able to do that I just couldn’t do. I’d be on the road and couldn’t run things that I needed to run.

[01:11] Rob: Sure. Well, hey, I’m starting an experiment this week. I am outsourcing the creation of my MicroConf presentation. Not the content itself but just the creation of the slide deck and I’m doing it for a couple of reasons. I sat down just to kind of do a rough outline, get in to a text file and you open up UltraEdit and I started typing what I wanted to see on each slide and I got to the end and I have, I don’t know, 40 slides took me a couple of hours to think through it all. I added as many numbers as I could. It’s a 250-line text file and I looked at it and I thought to myself, you know what? Like going from here in to slides is actually kind of a trivial task like it’s super time-consuming. I bet it’ll take eight to ten hours at least to get all that in to a format that’s nice and I’ve realized like there are people that Keynote way better than I do. For a starters  I’ve never used Keynote  but secondarily, someone’s going to just – they’re going to be more of an expert at just presentations and doing things visually.

[02:05] So, I hopped on oDesk and I found sure enough there are people who are like Keynote and PowerPoint and just presentation gurus. And so, I have an open job right now. I’m down about three candidates and I’m going to send them over my outline and have them each do the first five slides and see what they come up with. So, I’m kind of…kind of stoked about it. I’m interested to see if this pans out. Obviously, it’s an experiment, right?

[02:25] Mike: Yeah, I definitely did that at least one of the past two years. I don’t – I think it was the first year where I was looking for a lot of different images and I had somebody else go through and that’d be – I kind of told them what I wanted and then just went through and picked out all the images and stuff and put it together for me but it does worked out. But that’s a good idea to go to oDesk. I hadn’t thought about that. So, I do want to give a special thanks to Dan and Ian from the Lifestyle Business Podcast for helping us out with our April Fool’s Day episode. I saw some tweets and feedback messages here and there which definitely caught a couple of people unaware and definitely pranked them.

[02:53] Rob: For the record, that was your idea just out of the blue, right? Like the week before April 1, you’re like, “Hey, we should do this,” and I’m like, “Man, I don’t know if we have enough time to pull that together.” You e-mailed Dan and Ian and we got it together quick. That was good. I think it turned out well. It looks like some folks were tricked for a little while and others knew right away that, you know, it was April Fool’s Day right on the guard.

[03:13] Mike: Yup, yup.

[03:13] Music

[03:16] Mike: Today we’re going to talk about Seven Tips for Finishing Your Product. There’s probably millions of abandoned software products out there that are sitting in source code repositories or on hard disks from developers who’ve started something and then just never finished it. And today, what we’re going to do is we’re going to walk through seven tips for ensuring that you finish the product that you start.

[03:34] Rob: You asked me how many products do you think that you started that never finished and so that’s the – to be clear, I did launched several products that failed and I’m not including any of those but I bet I have at least ten and maybe fifteen half completed codebases that I got at least eight to twenty hours in to and just abandon. And some of them I got 80 to a hundred hours into – and really started…started getting in to it  and then just kind of left it by the wayside when I lost motivation. From all the interactions we have with founders constantly we know that people, you know, are abandoning apps, not finishing their products and so, you know, hopefully, these…these tips we pulled from our experiences are helpful.

[04:13] Mike: So, first tip that we have is “Don’t chase everything that moves.” You really need to be selective about the types of things that you start and some of this goes back to doing your due diligence and pre-marketing efforts to make sure that whatever products it is that you’re going to be launching or attempting to build is something that people actually want because if you get to a point where you’re 80, 100, 200 hours in to it and then you start talking to people or then you start seeing competition that you didn’t see before because you weren’t really doing that due diligence, you probably going to lose motivation and you know, it can be very distracting to have all these different ideas in your head.

[04:48] It’s always exciting to start a new product and when you start it, you have a lot of motivation upfront but unless you have the commitment to follow through with it, then you’re obviously not going to finish it. So, if you start chasing everything that’s going to become a huge problem and you’re not going to finished most of the things that you do start. So, definitely be selective about the things that you start and understand whether or not there’s going to be a market for those things.

[05:12] Rob: This is such a tough balance. One time, it was about five years ago when I was working with – this is back when I was in New Haven, Connecticut working with a couple of Yale MBAs and they were trying to get angel funding for this idea we had. And at a certain point, we cranked through several different ideas and we went and tried to do customer development. This was before it was called that but we are trying to talk to end users and figure out what their needs were and it was a long process and we did that for one idea and then we scrapped it. And then we did it for a second idea and we scrapped it. And this – months go by during this time and you start to get ante and you start to feel like you’re wasting time.

[05:44] And what I realized is that that it really – there were two types of people – of the three of us, there were two types of personalities. One guy finally said, “You know, we just need to pick an idea and go with it.” In my head, that sounds good but then you’re not vetting anything, right? You don’t have a lot of confidence that that  idea is going to go and you are just randomly choosing how you’re going to spend the next year or two of your life. And so, obviously, he was the personality of he just wanted to get moving with the app and I bet all of us have a little bit of that in us. I, on the other hand, really wanted to know that what we were going to build was going to be worthwhile that people needed it, right? That there is actually a market need and that we’re building something that people wanted.

[06:23] I think those are kind of the two sides of this coin and all of us have some of those two. It’s, you know, it’s not a dichotomy. You’re not either or but you have some of each and knowing yourself and knowing whether you are more of a person who is just going to jump on the first thing or who’s going to just sit and analysis paralysis for months and months, knowing that about yourself is very important to actually get something off the ground that has a reasonable chance of success.

[06:45] Music

[06:48] Mike: So, tip number two is to “Budget your time, energy and other resources.” And if you butt it off too much for a particular project all at one, you are a lot less likely to stick with it. So, you need to budget how you’re going to reach any of the major milestones by setting up a schedule for the different resources you have available and whether those resources are time, they’re money, they’re could be contractors that you have that are working for you or maybe you set aside a couple of thousand dollars and you need them to meet certain milestones by certain time periods or certain amounts of money that you’ve set aside for them to accomplished those tasks, those things you really need to keep a tight watch on so that you are meeting those milestones. Because if you start falling behind, it’s going to be very difficult to catch up later because you can’t catch up when it comes to code, if you got ten different things that you need to implement and you’re behind and you’ve only implemented three of them, it’s very difficult to catch up on the rest of them and still maintain some level of quality standards.

[07:45] Rob: I think the rule of thumb we’ve thrown around on this podcast in the past is whether you are building it yourself in your spare time or you’ve hired someone to build it, you want to get to launch in four months, ideally four months or less and no more than six months. That’s when people really start losing motivation. That’s where we see people drifting off and not finishing their app. And I’ve noticed, you know, working on Drip now since late November, early December, you know, one of the big things that has kept us going is knowing that our version 1.0 is just around the corner like it always feels a few weeks away and that’s good thing, right? We know we have a short development timeframe. We know that we kept the 1.0 to a minimum feature set and it does – it’s not like we designed the schedule “All right, at the end of 2013 we’re going to be done,” because that is – it’s that’s demotivation. It’s just too far out. You’re putting too many eggs in one basket and you’re adding a lot of risks to the project, risks that you never going to finish it and risks that once you get there that you’ve wasted a year of your spare time.

[08:44] So, I actually have a question for you. When you first started AuditShark, you worked…worked on it for several years now. Did you have a timeframe in mind like did you think that you were going to finish it in six months or did you even think about a timeframe or did you know we’re you like, “Ah, this is probably a 2-year development project since I’m doing it on the side”?

[09:03] Mike: I intentionally avoided putting together a timeline because I knew that it was such a large undertaking. If you look at my project file forward, it’s not called AuditShark. It’s called Redwood and part of the reason it’s called Redwood it was because I knew that it was just a massive, massive project and the idea is obviously a Redwood is a giant tree. Putting that in there as the project, it made me think about that on occasion that this is a long-term goal. This is a massive project that it’s not going to be finished overnight.

[09:31] Rob: So, in a way, you’ve kind of broken this rule, right? You didn’t necessarily budget – but you didn’t look at a schedule, right? You didn’t really have a horizon in mind. How did you think you’ve overcome that because it seems like that would be demotivating for me to continue saying like, “God, you know, it’s another few months, another few months,” and then see that for a year or two?

[09:46] Mike: But the thing is it’s different because I would say that – in a way I did budget my energy because if I put together this schedule it was two or three years long, it would have been demotivation and by intentionally avoiding it and basically doing the opposite by not putting together that schedule, I did budget my energy because I can break off little bits and pieces of it and implement those things and it doesn’t impact my morale. It doesn’t impact my ability to get some of those things done.

[10:13] Rob: Got it and knowing what you know now, do you think that if you started it over again from scratch that you could get it done in six months, that you could get something launched that people could use in this timeframe that we talked about the 4 to 6-month timeframe?

[10:28] Mike: It’s hard to say because there’s a lot of a code that for certain components that I didn’t build and I spent a lot of time managing building of those and while I was managing it, I wasn’t necessarily working on it myself. So, if I were to do everything, all of those things in parallel, I probably could have but at the same time, I would have spent a huge amount of time upfront in doing probably a pretty massive spec for it that I would have had to hand off to somebody or hand off to multiple people. I think that it could have been done but I really would have to had that spec upfront because there are certain things that I did where they ended up being more like prototypes in the way that they were put together and some things became production code, some things I ended up having to go back to the drawing board because it just didn’t worked out.

[11:11] Rob: Right and early on your expectation of the market or the market that AuditShark would serve turned out to be different than you had expected. So, I’m sure that added months to it as well.

[11:21] Mike: Right. So, let’s move on to number three. The third one is “If it works, ship it.” It doesn’t need to be perfect and in fact, it will take years for the product to be perfect but with each iteration, it’s going to be better than last iteration. What you need to do is you need to iterate more and don’t waste time on one massive first pass in order to get everything right because perfection is not the goal. You want to get the product out there so that people are using it and paying you for it and that’s really what your goal is. Your goal is to get people who are going to give you money for it. If you wait until it’s perfect, it’s never going to be finished.

[11:52] You need to be able to overlook a lot of the small things because there’s things that you’re going to do or have in the interface that are like, “Oh, I don’t know if that’s worthy or quite right.”  At the end of the day, it doesn’t matter when you’re first launching and it made two, three or five years down the road but your goal is to get that first piece out there and then iterate over time to make it better because it’s a lot easier to iterate on something that already exists versus building something massive from scratch.

[12:17] Rob: If you are personally relatively unknown and you don’t have a massive launch list and you are really building something up from scratch or you don’t have a lot of traffic upfront, then I absolutely think that you should get something out there as quickly as possible just like Mike said get a couple of people using it. Don’t launch to everybody on day one. You know, as soon as you have something working launched everybody, that’s a terrible way to do it. You do the small limited beta maybe with one user or it might be with three. You get some feedback then you get the next few in, the new few then you slowly open it wider as you’re gaining more confidence in your ability of the app to provide what it needs, you know, to your customers as you add features, as you fix bugs, as you’re able to support it all these things.

[12:57] On the other side, if you already have let’s say an audience or you already have a large mailing list or you already have a large personal brand or you just already have a lot of people watching what you’re doing, I think you need to be a little more careful with this because obviously if you put something out that is very V.1, people are going to be more looking to rack on it, right and to rag on you and to say, “Oh, look at so and so put up this app. It sucks.” So, you have to be – I mean I’m saying this obviously being aware that I’m launching Drip in six or eight weeks and we are putting polish on it that I wouldn’t have put on an app that I launched six or seven years ago. But I have this list of thirteen, they’re the early access list and then I have a mailing list of, you know, over a thousand at this point.

[13:37] I’m not just going to e-mail all these people and say, “Hey, come on and use the app.” First, we’re going to be customer number zero. I’m going to install it on HitTail and we’re going to iterate for about a week, maybe two with the on boarding, with, you know, tweaking things and to me, that’s – we haven’t shipped yet technically, but we are iterating on it. We’re not going to be adding new features at that point, right, assuming it can do everything we need. Then we’re going to get customer number one from that early access list and we’re going to go to the same  cycle. Probably spend a week, maybe two and then we’ll probably get two or three more.

[14:04] So, I see it as going and taking it in phases and whether you do have a large launch list or not, taking it in steps is the way to go. And in my opinion, as soon as one customer is using it and paying you for it, you have “shipped it”. If you are making progress a little bit of a time and you’re iterating and people are getting value out of it and paying you for it, even if you haven’t launch it to the world, I still think I would say that that counts and that is a better way to go, a gradual approach rather than, you know, unleashing it to thousands on day one.

[14:34] Mike: Tip number four is “To do what you enjoy and outsource the rest.” For the core tasks that you need to accomplish with launching a product, you need to understand why it is that you don’t enjoy those things. Is it because you are just not interested in them? Is it because you’re not familiar with them? Is it because you feel like you’re not any good at them? And understanding that is kind of key to getting your product out the door.

[14:55] Rob: Let’s talk about a few tasks that the people might enjoy or not enjoy. E-mail support, I don’t know many people who enjoy that ongoing. I think early on as the founder, you do want to do some e-mail support especially as a bootstrap founder where you don’t have a team. It gives you a lot of insight in to what your customers are doing, thinking, saying, the problems they’re having and all that. But as the months tick on, as you get more customers, you get more support and you start seeing the same things over and over, that’s where you’re going to stop enjoying it and most founders I see who continue to do that up to that point, start to get a little burned out. And so, that I mean it’s obviously since it is a recurring task, it can be fairly systematize pretty easily. I would say that that’s when you should outsource early.

[15:34] Mike: All that information is great for after you have launched your product but let’s back up a little bit. What about before you’ve launched a product? What sorts of things can you outsource or what sorts of things to people not like about launching products or not good at them?

[15:48] Rob: Yeah, boy, that’s a long list. I mean I know some folks like myself I don’t enjoy design at all, right, because I’m not good at it. And so, that’s something that I’ve outsourced heavily since day one and if you are not good at it or you don’t enjoy designing, I think that is a no-brainer to outsource because there are a lot of good designers out there. Some folks I know don’t know how or don’t enjoy the coding side of it, for sure, that’s something we’ve espoused on the podcast. I think there’s also research tasks online, research either of competition or a potential customer, potential beta testers, all that stuff. Hitting up Google is not a hard task to do and if you outline some good criteria, it’s pretty easy to find someone who can do research for you.

[16:26] I also think, you know, even stuff like once you get a design back from a designer, you need to slice it in to the HTML CSS. You need to then turn it in to dynamic files at the Ruby, PHP or .NET, whatever…whatever your poison is. All of that is quite easily outsource to folks. It’s whether you have the time or the money and whether you want to do it or not but I definitely think that constructing the website is certainly something if you’re a developer that you can do but I would actually encourage you to spend more time on this other stuff like getting you’re marketing message down and getting your value proposition, your positioning, figuring out which of those are key elements and you know, really doubling down on those. That allows you to then to write your website content, allows you to put together a marketing plan.

[17:11] I haven’t heard of anyone outsourcing a marketing plan unless they have a lot of money like that you need to hire an agency if you want someone to really head that up. The small bootstrap founders I know, that’s the one thing you don’t outsource. You can outsource pieces of your marketing but you don’t outsource the vision of it and the deep, deep level understanding. That’s where entrepreneurs who are bootstrapping who are successful tend to excel. And then, you know, I think the other thing you mention was customer development, talking to customers realizing how most people aren’t going to enjoy that. I mean I don’t think anyone I know actually enjoys going out without a product and trying to get people’s pain points and talking to someone cold calling them, cold e-mailing them.

[17:49] Once you talk to them, it’s a lot of fun because you realized that they aren’t actually mad at you, right? The people are wanting to talk to you because you could potentially help them down the line especially if you’re not selling to them right now [0:18:00]. They are really open to talking to your about your ideas and about giving you feedback. But I think there is this kind of this fear or this myth that the customer development is really hard and I think each of us feel that that fear when we do go to cold call or cold meet-up with a potential customer. No, I haven’t heard of anyone outsourcing it. I know, you know, you mentioned outsourcing some things but certainly a customer development I think is something that the founders have to do themselves.

[18:24] Mike: Part of my point was to make sure that if there are core tasks that have to accomplish like customer development that you understand why it is that you don’t enjoy them. Is it because you’re afraid of doing them? Is it because you don’t think you’re very good at them? And you know, customer development especially when you don’t have a product as you said, it’s very difficult for somebody to just start reaching out to people and saying, “Hey, would you be interested in this,” or “Is something like this going to solve problems that you’re encountering,” because you don’t actually have anything that you can show them. All you can do is talk to them about it and that can be a little scary, a little disconcerting but at the same time, I mean I’ve had some really good conversations over the past couple of weeks with some extremely large companies who have a particular problem that AuditShark does not currently solve but it could down the road and it fits very, very well in to kind of a more enterprisy offering for them.

[19:12] So, those kind of conversations for me at least have kind of driven, I’ll say the future of the product and is not that I’m going to go implementing them today. I don’t think it’s going to be for probably six or eight months before I start getting there but it starts to help shape your vision of what the product is going to become down the road.

[19:30] Rob: Why do you think it’s so important that the founder needs to learn why they don’t like the core tasks?

[19:34] Mike: I think if you don’t understand why you don’t like it, then you simply avoid doing it and if you are avoiding doing it, then obviously you’re not going to get any value out of it but at the same time like for example, customer development, if you just don’t do customer development, then you get in to a situation where you’re probably 12 or 18 months in to the process because you haven’t talk to anybody and you’ve tried to launch it two or three times and it just hasn’t gone anywhere because you didn’t talk to anybody about it and nobody wants it. Nobody cares because you’re not actually solving someone’s problem and it’s – and it all comes back to the reason being that you did not talk to people.

[20:11] So, if you understand that you don’t like doing that then it’s something that you can consciously make decisions about and consciously address whereas if you’re not acknowledging it then you probably just going to avoid it. So, tip number five is “To track your progress.” And there are a lot of different ways that you can track progress, you know, maybe it’s based on your features or different customer development tasks, marketing tasks. You can use all kinds of different things. You can use spreadsheets. You can use bug tracking. You can use burn down charts, pretty much anything goes at this point. I mean you can even use Trello to basically line up all of your different to-do tasks and then move them around as needed but the idea here is that you really want to understand where you are in the process and be able to track that stuff and figure out roughly when you’re going to be done and if you are able to zero in on a specific date or a deadline for completing all of those tasks, that can help in in your motivational factors.

[21:07] Rob: I think most people avoid doing estimates at the beginning of a project because I think that they don’t want to be wrong because that makes them feel bad and I think perhaps they don’t want to face the music of well, if I really build this like I think I’m going to it, it is going to take eight or nine months — since I can only work 15 hours a week. I can’t underscore how critical being able to see your progress on an ongoing basis, how critical it is to your motivation to seeing an estimated completion date either stands still as you work or move itself backwards if you get ahead. I mean actually become an earlier date and knowing that you are burning the stuff down.

[21:44] You know, I think over the years I’ve used FogBugz for this. I’ve used Excel spreadsheets. Joel Spolsky had – what is it called? It was like a project estimate sheet. If you Google that, you’ll find it. And I also have – I have it in a Google doc now and that’s what we’re using for Drip and there’s this awesome function called work day where you can just say you give it a date which is now and then you add up all the remaining hours and – in those holidays, it has default holidays. You can add in holidays and it will give you a date that this project is going to be completed and it excludes weekends. It excludes major holidays. It’s pretty crazy how accurate this thing can be and even like it’s what we talked about last episode even if it’s off by a few days or by a week, it is still so much more clear than if you have nothing and are just basically driving in the dark.

[22:30] Mike: Yeah, the one thing about that that I found is that in order for that to work, you really have to be diligent about going in to every single line item and making sure that you assigned a time estimate too because if you don’t, then you’re just not going to get good results out of it. But I really like the way FogBugz does it because they give you a probability that you’re going to complete it on any given date and then there’s this, you know, range of probabilities across, you know, some multiple dates that says, you know, there’s a 90% chance you’ll be done with it by, you know, April 30th but there’s only a 50% chance you’ll be done with it by April 15th.

[23:07] Rob: Yeah, I think that’s a great way to go. Those estimates though if you don’t have any history in their system of estimating and then completing things, it has no idea how good of an estimator you are and overtime —

[23:16] Mike: Yeah.

[23:16] Rob:…as you build history, it will become more and more exact, you know, in terms of the estimates because it knows you’re personally a better estimator and if someone else is a worse estimator, it’ll take that in to accounts. And so, when you first thought it out, it’s actually not very accurate but you have to follow this and track your time and you do have to do line items just like if it was an Excel spreadsheet. You do have to say, “It took me this long,” so that FogBugz knows, you know, knows how long it took you and knows how to adjust your estimates up and down.

[23:41] That’s a thing, when I’m using Excel spreadsheet, I mean there’s no…no better way that I have found to be honest. You have to figure out for yourself what you’re going to actually update. You can’t have a thousand line items at half an hour each, right? That’s not going to work. I mean you have to narrow it down to 50 or a hundred or some small enough number that when you’re done working and you log out for the night, that you go in there and it should take 30 seconds to just scan through, boom, I work four hours on this and you’re done, you know, and if there are over dues, then you put them in there and the spreadsheet will show. It will pull something out. I mean it’s not a hundred percent accurate but even if it’s only 90 or 95, it’s a shocking how much this will do towards keeping you motivated to finishing the project.

[24:25] Mike: And some of what you just said leads in to tip number six which is “To set goals and celebrate your milestones.” One of the things that I’ve done with AuditShark is that inside of FogBugz which is where I do the vast majority of the tracking for it, I’ve set up different milestones based on a specific date. So, instead of looking at this giant list of a thousand or just 2000 line items, what I’ll do is I will assign them to individual dates. So, I might have I call them sprints inside the…inside of FogBugz but I’ll basically set up all these different milestones and say sprint 17, 18, et cetera. And I’ll just assign them to be completed on a specific date and then I’ll take a bunch of cases and assign them to a particular sprint and I’ll say, “Okay, I’ll want these things to be done on this particular date and they’ll be part of this sprint.”

[25:07] And if it starts to get too many things in there, I’ll start looking through those and seeing what I can push out in to the future. In that way, when I’m looking at these different milestones, it’s easy for me to see whether or not I’m trying to squeeze too much work effort in to a too short of a time period, it also allows me to see whether or not I’m essentially keeping up with all of the tasks that I put on my plate or the tasks that I put on other people’s plates.

[25:33] So, the last tip that we have is “To know when to give up and move on.” Don’t be pigheaded and simply keep going on your products because you committed to the idea. If Google releases something that renders your product, your relevant, you need to move on and you need to be able to recognize that there are certain factors that are just way beyond your control that there’s literally nothing you can do about them and when those things come up, you need to just give up and go find something else.

[25:58] Rob: Let’s bat around a few factors that could be  reasons to move on and maybe some factors of things that you shouldn’t move on but may, you know, maybe you think you should but you shouldn’t actually do it.

[26:08] Mike: So, the – I guess the first one that comes to mind for me is literally if Google or Microsoft or somebody like that comes out with an idea that is almost exactly what you’re working on. Now, if you’re doing something that is a very niche product and Microsoft has something that does that in a general way but you have something that is targeted for a particular niche that could use it, I think you’re probably okay. However, what was it? Was it Kiko that had a calendar, a web-based calendar system —

[26:38] Rob: Yeah.

[26:39] Mike: …and then they ended up shutting it down after Google came out with the Google Calendar.

[26:43] Rob: Right and I wonder if, you know, could they have pivoted that in to a niche? Or do they even want to or do they have too much money raised that going in to a niche play would have just rendered the business model useless and made it a non-success because if you are a bootstrapper and you’ve built Kiko, I actually think you could have still even with the free Google Calendar, you could have built a business out of it if you convince people in a niche that you could provide them more value and of course, you did provide them more value and then charge money because it’s a differentiator. There are still calendars that people pay for out there.

[27:15] Mike: Yeah, I think that the issue there was that they because they were angel funded, you know, what sort of investment are you going to be able to get back? Who’s going to end up buying that? And maybe they built it with the intention of possibly Google acquiring it down the road or maybe that was kind of their initial thought when they were coming out with ideas of who would buy it. I think that what you just said rings true as where if it was a bootstrapper who did it, you could definitely pivot it. But when you’re talking about that particular product with an angel or VC funded backing, I think that it becomes a lot more difficult to say, “Oh, well we were going to go big with this but we’re going to go smaller now.” I think there’s justifications become much more difficult in those conversations or much more difficult. It’s easier to just shut the thing down and say, “Look, Google is coming out with this. They’re offering it for free. There’s not very many places  that this can go anymore.”

[28:02] Rob: I have a scenario. What if you’re in a middle of building your app? You’re maybe three months in. It’s going to take six months and there are really isn’t a major competitor in that space and then suddenly two other startups launched in that space whether they’re funded or not, they launched and they have decent products and you can tell they know what they’re doing. Do you think that’s a reason to shut it down?

[28:19] Mike: I’m not sure. I mean I’m not in that situation but I think that I would probably keep an eye on them but if you’re a three months in and your total development time was six months, it seems to me like having those two competitors, you know, if there were no competitors before now there’s two, in some ways that’s a validation of the market and it means that there is, you know, money there and people are willing to pay for. So, I don’t know as I would back off at that point. If you are doing something, you know, say several years ago and like the mobile management space and you know, obviously nobody was there at the time and then everybody started going there or everyone started building all these mobile management applications and now if you look at the landscape, there’s like 50 or 60 different companies who are doing something in this area and it’s a little bit late to be jumping in, I think that’s a completely different scenario though because, you know, obviously the time cycle is longer and then you’ve also got that fact that if you’re early in versus a late comer, those are a lot of different factors that go in to it.

[29:14] Rob: Yeah, I think I had to agree with you on that if – that if you’re in process and you’re – at least have the launch date in sight and new competitors cropped up then it wouldn’t be a big deal not if – if one of those new competitors was as you said Google and Microsoft, that would make me pause and reevaluate and if it wasn’t two competitors but it was nine competitors by some bizarre coincidence, everyone moved in to that space. So, that would also make me at least pause and reevaluate and consider shutting down the doors. It’s obviously whereas case by case basis. I mean it’s – it’s very specific. There’s a lot of factors that play in to this. I think the thing is you want to try to keep a rational head as much as you can because it’s easy to get discouraged and to let emotion get in to it, right? To let your emotion drive you down to become kind of disillusion with the idea. You get bored with it, “Oh, I would – you know, it’s not going to be successful anyways  because these two new competitors have cropped in,” that is really easy to do if you are a one-person team and not getting any positive feedback or not getting any of the goals and celebrations of your milestones.

[30:12] Mike: Right but there’s always for any given piece of software where there’s a gorilla – I mean there’s always room for much smaller competitors and it really depends a lot on the niche that you’re going in to but as you said I mean if it’s a difference between two people cropping up, two new competitors versus nine or ten in this space of a couple of months, I would agree with you that if it were nine or ten that popped up, I might just give up at that point and go find something else that’s just probably going to be less competitive. If it’s only two, I don’t know as I would worry about it as much especially if one of those two was funded in any way because you never know, you may get down the road and they may become the gorilla but people are looking for an alternative to it.

[30:49] Rob: So, to recap our Seven Tips for Finishing Your Product. Number one is “Don’t chase everything that moves.” Number two is “Budget your time, energy and other resources.” Number three is “If it works, ship it.” Number four, “Do what you enjoy and outsource the rest.” Number five, “Track your progress.” Number six, “Set goals and celebrate your milestones” and number seven is “Know when to give up and move on.”

[31:09] Music

[31:12] Rob: If you have a question for us, call our voicemail number at 888-801-9690 or e-mail us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for startups or via RSS at startupsfortherestofus.com where you’ll also find a full transcript of each episode. Thanks for listening. We’ll see you next time.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

One Response to “Episode 127 | 7 Tips for Finishing Your Product”

  1. Mike, finish your product!