Show Notes
Transcript
[00:00] Rob: In this episode of “Startups For The Rest of Us” Mike and I will be talking about what feature to build next. This is “Startups For The Rest of Us” episode 212.
[00:08] Music
[00:15] Rob: 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 you’re first product, or you’re just thinking about it. I’m Rob.
[00:24] Mike: And I’m Mike
[00:25] Rob: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, Mike?
[00:30] Mike: Well, we got a really cool “thank you” email from a Mayo De Leon. He says, “Hi guys. I wanted to thank you for the great audio content. I tune your podcast in while on the treadmill. I’ve lost 16 pounds in four weeks just listening to the podcast and getting tons of incredible information. Thanks. And he’s the founder of Proposalware. I listen to a lot of podcasts, but I don’t think I’ve lost 16 pounds in four weeks.
[00:50] Rob: Yeah, I know. Very nice. We also got several new iTunes reviews. We’re up to 376 worldwide, most of them five-star. The first review is from Eric Stark from Sweden. He says, “With under 200 episodes under their belt, I’m impressed by the consistent high quality. Always some good nuggets of wisdom each week. We have one from R. Wilmer of the UK. He says, “Perfect timing for me, since this is something I need. So good I listen to it twice”. Then we have Chris Kodem from the Czech Republic saying, “There’s no other podcast I know of that so consistently delivers such great value week after week. Where plenty of other podcasts end up turning into a collection of tips and tricks, Mike and Rob manage to combine their own ongoing experiences as entrepreneurs, with detailed tactical advice, into a tight package that respects my time by keeping the fluff and banter to a manageable level. I highly recommend it.” So many thanks to everyone who has given us an iTunes review. If you have not, I really encourage you to give us five stars. You don’t need to write a review. And even if you are on something Sketcher or Downcast, if you review us in there it actually helps us as well. So we really appreciate it.
[01:54] Mike: Well, I spent a ton of time this past week working on the Micropreneur Academy Forums, and basically migrating everything to a new platform. Because the Micropreneur Academy was built on WordPress back in … When did we start it? 2009 or something like that? We went with Simplepress forums for the long time. Over the years its gotten kind of old, and it just doesn’t handle things very well. And then WP Engine shut off some of the full text search capabilities, which completely hosed the ability to search inside of the forums. So about a year ago we started looking around and saying “Okay. Well we really need to do something with the Micropreneur Academy itself, migrate to a new platform of some kind, or just do a major update of some kind. What we ended up doing was we ended up going out, finding a new platform. We looked at, I think, three different platforms that were on our short list, and only one of them really met a lot of our needs. So we spent probably the past eight or ten months working to try and get all of the content in such a way that can be moved over onto the new platform.
[02:50]We tested it out for MicroConf Europe and for MicroConf Vegas. This past week we, kind of, pulled the trigger and disabled all the forums on the Micropreneur Academy, moved all the content over, and then I’ve just basically been working through support issues for the past five or six days, trying to make sure everything is working and that everybody can get in. I think it’s gone reasonably well. I think there’s a lot of good comments in there, and the discussion have actually really moved forward.
[03:17] Rob: Yeah. That’s been a thing I’ve noticed. Obviously there are going to be hiccups when you gave a migration like this, with thousands of forum posts being moved to a new platform. But the fact that the number of conversations that are going on instantly increased from the time we moved over I think really says something about the platform and how much of a difference it makes in being able to allowing for conversation, allowing for good discussion. So, I’m happy with it. Micropreneur.com is still active. People can log into it. We have all of the content there, but the forum discussions themselves have now been moved into Founder Cafe, and I’m happy to call that the new home of the Micropreneur discussions.
[03:55] Mike: Yeah. So it’ll be interesting to get some of the bugs worked out. And once we can that done then we can start adding in a lot of the other things we’ve looked at, like adding a wiki, and integrating that in so that everybody can use it and collaborate on what sorts of tools are out there that they’re using, or reviews and analysis of the things that are working and not working for them. I think that will really help – just in general – the community, because it’s obviously stuff that people are going are going to suffer through on their own, but if people have already gone through that process of evaluating different pieces of software, or different services, it helps to be able to share that information. Before you could do it in the forums, but I don’t think that it was nearly as well organized as something like a wiki would be, and that’s going to be completely integrated into the New Founder Cafe.
[04:37] Rob : Right. So if you’re interested, if you have checked out the academy in the past, but left because maybe the discussions weren’t up to your liking, you might want to check it out. Micropreneur.com, if you enter your email there, we’ll let you know the next time we take a class.
[04:51]So, Gabe from “Just Add Content” sent us an email, and he wanted to give us a heads-up about the start-up class from “Y Combinator”. It’s at startupclass.samaltman.com. It’s actually a course at Stanford, and there are videos of the lectures that are only up for a certain amount of time, from what I can tell. There are notes and there’s all types of stuff. Now I actually found it in the Downcast Podcast Repo today, so I’m sure it’s in iTunes as well, if you search for “start-up class” and then look for a very simple logo that’s just, kind of, text on a black background. You can pick and choose which lectures you might want to listen to. It’s discussions from people like Paul Graham and Sam Altman, and a bunch of other influential and knowledgeable start-up folks. So I have not started listening to it yet, but I am very much looking forward to digging into this, because this is essentially something that they’re doing for their own founders, so it’s definitely going to have some good insights and tips I think will be useful to you if you are interested in this show.
[05:48] Mike : Very cool.
[05:49] Rob : Today we’re going to be talking about deciding what feature to build next, and the criteria that we use to figure out how to decide whether to build a feature if it’s requested, and then how to somehow prioritize those features. I think I should start by saying that this really is, as usual, a discussion about B2B apps. So, if you’re going to business-to-consumer you kind of need some good luck. You kind of need an amazing sense of product if you’re going to pull it off, and you don’t necessarily go based on user requests, because consumers don’t necessarily know what they want before you show it to them. I think this is really evident if you hear every person who is building a B2B app, what do they say when you talk about what features to build next? They say, “Talk to your customers.” Right? That’s the next thing you should do to guide the direction of your product. And you can’t just listen directly to what they say. You have to filter that, and you have to decide the direction you want it to take. But with B2C folks that’s where you hear the quotes like Steve Jobs saying, “It’s really hard to design products by focus group.” A lot of times people don’t know what they want until you show it to them. And I find it hilarious when people take that so out of context, and they day, “Yeah.
[06:58]That’s how you build a start-up. People don’t know what they want, and you just have to make the decision as the founder.” And it’s like, number one, you’re not Steve Jobs. You just don’t have the product sense that he does. You don’t have the experience. You don’t have the leverage and the resources and all of that stuff. Number two, unless you are doing a B2C company, whether that’s hardware or software or any of that other stuff, that advice is not helpful. I don’t know of very many, if any, B2B companies that are using that as their product direction. There’s actually this other quote that everybody attributes to Henry Ford. The quote is, “If I had asked people what they wanted they would have said, ‘Faster horses.'” Again, implying that your customers don’t know what they want, and that you should make the decision for them. My take is that that is not correct. Yes, if you want to build a billion dollar business, then maybe you need to innovate to the point that you are ahead of the curve and people don’t know what they want.
[07:54]So you should not be listening to this podcast. You should be going and building a slide deck and trying to pitch investors to raise your series-A of five million dollars, and then go try and build some B2C company. And that’s fine, but that’s really a different path. If you want to build a business that other businesses need – where you save them money, make them money, save them time – and you want to build a sustainable product in a repeatable process, then that’s what we’re talking about today is how to take incoming feature requests. Whether it’s early stage, or whether your product is far more mature and you’re still getting feature requests, that’s really what we’re going to be talking about today. It’s how to decide what features to build and then, hopefully, how to prioritize them.
[08:30] Mike : This is really about maximizing your chances of success.
[08:33] Rob : The first thing I want to tap into is trying to figure out the priority of when to build a feature. So the four questions that I think about when we’re talking about whether to build a feature, and this is in order of priority. Number one is a prospect asking for it. It’s someone who is not currently paying you, asking for you to build this feature. Priority number two is a customer asking for it. Priority number three is someone on your team – such as a developer, support, or salesperson asking for it. And priority number four is, “Do you think it will shift your product into a new market?” So, in other words, are you asking for it, but it is a little riskier. So let’s look at each of those individually now. The first one is, “Is a prospect asking for it?” So the reason that a prospect’s feature request tends to be the most important is because a prospect hasn’t paid you money yet, and their time frame is very limited. So if someone comes and says, “Hey, does your product do X?” and you tell them, “No it doesn’t, but we can build it.” you typically have a very limited time frame to get that done before they will move on to another product and decide on something else. So that’s why I’ve prioritized it high here, even above customers. And there is debate of whether you should listen to your customers to support them, or your prospects first. But in this order, I’ve put the prospect’s feature requests as number one.
[09:53] Mike: I think a lot of this is dependent on the price point and what stage you are in the company. Because the start-up that I worked at, what the sales reps would do is they would talk to people, and because the deal price points were extremely high, they would talk to people and essentially talk them into buying the software saying, “We will build this feature for you.” And they were basically promising features that had not yet been developed, or were kind of in the pipeline. And it was interesting to see them work that side of the sales angle, because they’re basically making promises that they can’t necessarily keep themselves, or depending on the back-end developers and engineers to do it for them. It was just interesting that they used that as a strategy for selling the products. It was like, “Oh, we don’t do that now, but we can. Give us a little bit to work that out for you.” But they were also dealing with time frames that were several months. So the price point there, because a higher price point product has a much longer sales cycle in it, it gives you that flexibility to do that, especially on more difficult problems that you are trying to solve, or more difficult features that you are trying to implement. If it’s a really hard problem to solve, it’s a lot harder to turn that around in a much shorter time frame, and as Rob said before, if the price point is low and your attention span from the customer is not very long, it’s going to be difficult to turn around some of those things.
[11:14] Rob: Right, and it may not be worth it, frankly. If you only have a $10 a month product, unless you really, really early on – let’s say first 20 or 30 customers – it’s typically not worth dealing in super fine detail with someone who’s requesting features. You know? You can take it and say, “Yeah, we’ll put it in our queue.” but then even to take the time to get back to them and say, “Hey, we implemented this. Are you ready to sign up?…blah…blah…blah.” on a $10 a month product, it just doesn’t justify. Like the LTV typically will not. You need just a higher lifetime value in order to be able to justify it. I think the other thing is, in my experience of doing this with my software products is, it’s worked out really well – with the higher end stuff, where it’s actually is worth working one-on-one with someone – is that when a prospect who hasn’t paid you any money starts asking you for things, try to define the finite list. The question that I use is I’ll say, “Is this the last thing that is keeping you from paying us money?” Because nothing is worse than building a feature and then having somebody come back and then saying, “Oh yeah, and then I need this other feature.” So now you’re on this constant thing trying to keep up with someone’s feature ideas in order for them to actually become a customer.
[12:23]Prospects like that – I don’t think they do it intentionally – but prospects like that are not necessarily going to be good for you. You really want to find people who are one step away from signing up, and they just need you to build one feature or maybe two, and you want to work on those people first, especially in the early days when you’re trying to get to revenue. Then you can come back and work on people who maybe take a little longer. I have someone in the queue right now who’s been thinking about it now for maybe six months, and we’ve been emailing here and there. And I know him, so it’s cool. He’s not a hard customer to deal with, but he has just been in constant thought about whether or not to move over, and it’s little by little he’s gained confidence in Drip. And the fact that I’ve kept him in my boomerang, kept him in Pipedrive and stuff, and touched base with him every month or two has eventually meant that he has come over. But it wasn’t one single feature that it took. It’s, kind of, a series that we’ve built.
[13:15] Rob: So the second priority that I have mentioned is whether a customer is asking for a feature. So the first was a prospect. The second is someone who is actively paying you money. Now the interesting things is if you have one-time software sales, then this actually becomes a lot less relevant, or it becomes a lower priority for you. Because if someone has paid you a large chunk up front, and maybe they’re paying you a small annual maintenance fee, they’re just not as valuable to you as a new prospect who could potentially land you a very large sale. With SaaS it doesn’t matter, because that money of an existing customer … In fact, with SaaS it’s actually a much more even trade, because a prospect and a customer, who are potentially paying you the same amount of money, are potentially worth the same to you – although a customer who is already paying you money could potentially be worth more. So, that’s where I was saying this priority could be shifted to where customer requests could be higher priority, but what I’ve typically found is, since switching cost are not zero with SaaS apps, that customers are not likely, if they have trust in you, they are not very likely to jump ship very easily. So as long as you are listening to customer requests and building them in a reasonable amount of time, you don’t need that tight turn-around like you do with prospects. Because a customer is not likely to say, “Well, I need this in the next week, or else I’m going to cancel.”
[14:33] Mike: Yeah. I think you bring up an interesting point there where, in some cases, it’s a difference between what type of product you have for this particular prioritization. With a SaaS customer, they’re coming back to you every month, but if it’s a customer where you sold them a perpetual license for either downloadable software, then you’ve gotten all of your money up front, and the return for you is your 20% maintenance cost at the end of the year. It depends on where your money is coming from at that point. It does make a difference when you’re trying to prioritize multiple feature requests.
[15:05] Rob: Right, and another thing to think about when a customer is asking for a feature is, “Is that customer a power user, or are they just a normal, everyday user? How much are they paying you every month?” and, “Are they maybe one of your more painful customers? Someone who may cause you trouble most of the time, and that you really wish would, kind of, go away?” There’s varying levels of the quality of customers, of how much you want to work with them, and how much they’re paying you. All that factors into where you want to prioritize features that they request.
[15:35]Then the third priority is, “Is someone on your team asking for it?” So, a developer, a person in support, or a person in sales. Typically, this will be influenced by their interaction with a customer. To be honest, I’m not quite sure why customers wouldn’t request something and people on your team would request it, but this happens to me. My support guy will email and say, “Hey, have you thought about building this?” Then I’ll say, “Why?” And he’ll say, “Well, I see customers are having trouble with this.” But maybe they didn’t know what to request, or didn’t know how to request it or something. So these should definitely be in the priority, but since it’s not something that you’re maybe going to email several customers when you’re done, and notify them, and potentially get new customers out of directly, it’s something that I prioritize as third out of fourth.
[16:17] Mike: I think these fall into a couple of different buckets. One is if customers aren’t asking for it, that’s a slightly different scenario. But when your support team comes back and says, “Hey, I think we should build this.” it could very well be that they have this cross-sectional view of all the different customers who are coming in with requests, and they can see something where one customer thinks, “Oh, I just didn’t understand the interface.” or, “This is confusing to me.” But your support rep sees that there were 50 different people who had a very similar problem in going through the sign-up process, or using a particular page, or something like that. So they get to see that, and the customer on their own isn’t going to ask for you to implement a new feature. But the support reps are going to look at that and say, “Hey, we’ve gotten a lot of calls about this particular thing, because people don’t understand how to use it, or it’s not clear. We should make some changes here to make the product better.” And that will ultimately cut down on your support costs. It’s not something anyone has asked for, but at the same time they do need that little bit of extra help.
[17:13]The other place where I can see people internally asking for stuff is to make their lives easier. So, for example, things like administrative interfaces, or the ability to log in as any given customer so that you can see exactly what it is that they’re seeing. Stuff like that is stuff that no customer is ever going to ask for, because you wouldn’t give it to them anyway. But your support team and your developers need that kind of stuff, and need to be able to do those kinds of things because it helps them do their jobs, and it helps them serve the customers. It’s interesting that you can look at this and say, “Oh, well anything that comes internally should be a third on the list of priorities – should be under customer requests.” But I think that that is not always the case. There’s definitely some flexibility here in terms of these prioritizations. It depends on exactly what it is.
[17:59] Rob: I agree, and that’s where this priority stuff really does come down to there always a big judgment call, and a gut instinct based on what the actual feature is. What I’ve typically found is that something might come internally. So, under this list it would be priority three, but then I’ve just been hearing rumblings over it from customers and from prospects, and there’s an underpinning of the request already being there. So I do think there’s a lot of judgment that has to go into this as well. [18:24]And the fourth priority is, “Do you think it will shift your product into a new market?” So this is essentially you coming up with feature ideas. And the reason that I couched it like, “Do you think it will shift you into a new market?’ and not just saying, “Does it come from you the founder?” is because spit-balling features and just coming up with new features is almost never a good idea. The only time that you should be considering generating your own features, and not just building stuff that prospects and customers are asking for, are if you think that it can push you into a new market and either widen your reach or actually get you into a new vertical. And so to give you an example of that, seven, eight months ago Drip was, essentially, a very small email marketing app. It could capture emails, and it could do auto-responders, and it could do some split testing. And then we were getting a lot of customer requests to do marketing automation. To be able to move people in and out of lists, to be able to tag them, do behavioral email and that kind of stuff. Now, I thought that those features would push us into a new market. So while those features did not come directly from me, that was a really big impetus to raise the priority of those, and to build them out. That’s what’s resulted in the spark of growth in Drip that wouldn’t have happened otherwise.
[19:39] Mike: I think for something like that you have to consider the ramifications of that – of shifting into a new market – because it has the potential to take you out of the one you’re currently in. So I think that there’s definitely some additional considerations you need to take into account when you’re deciding on something that could shift you into a new market, because you don’t want to necessarily be seen as no longer doing a particular thing. Your current customers aren’t going to necessarily care, because you’re solving their problem and they know that you’re solving their problem. But at the same time you have to be conscious of what adding some of those new features is going to say to prospects who have never heard of you before, or don’t know the history behind where you app has come from.
[20:18] Rob: So with those in mind, I have four questions that you should ask yourself when you’re thinking about building a new feature. Hopefully it will help deciding whether you should do it, and then how to prioritize it as well. So the first question is, “How many of your existing customers do you think will use it?”
[20:35]It’s always an estimate, and my estimates typically come in the form of like 5%, 20%, 50% or more, because it’s not relevant to get down to 7.5% or any type of detail like that. And this will come up in discussions pretty regularly, when we’re trying to decide to build a feature. Then, if only 5% of people will use it, the next question – the second of these questions – is, “Will a good chunk of your customers who use it be power-users?”. Because power-users are more loyal. They’ll end up paying you more money over their lifetime. So even if only a small chunk of people use it, are they going to be your power-users?
[21:13] Mike: Another question to ask yourself is, “Does the feature request fit in with your vision of the product?” This is something of a balance you need to strike. If you’re too narrow-minded and you’re not open to listening to customers and having them show you the way that they do things, then it can cut you off from implementing things that would attract a lot more customers. And I think that this is probably a problem that a lot of people struggle with, because you have this vision or this idea of what the product should look like in your head, and you say to yourself, “I know how to implement this. I know how it should be done.” Then you talk to customers, and suddenly maps that you’ve, kind of, laid out in your head get blown apart, and you have to go in a different direction. And it’s not to say that it’s going to be in a completely different direction – and sometimes that does happen – but there’s these minor alterations in course that you almost have to take in order to serve your customers better. Sometimes that can be difficult to make that transition from saying, “I know exactly what I’m going to do, and I know how to solve this particular problem.” to transitioning over to saying, “Okay, maybe I don’t understand this as well as my customers do. Let me have them show me what should be done.”
[22:17] Rob: And then the fourth question is, “Will this feature be over-extending your team’s capabilities?” What I mean by that is, we get a lot of feature requests that ask for things that are far outside of our core competency, and they don’t relate at all to marketing automation or email marketing. They are peripherally related. So it’s things like landing pages or shopping carts and payment processing and that kind of stuff. And we’ve seen some of our competitors that go out and build these things based on customer requests. So they are a conglomeration of really five or six different apps, because they added landing pages and shopping cart and all of that stuff in. But what they did is they over-extended their team’s capabilities. They basically built lower grade software. The software is not Best of Breed. So it’s not a collection of Best of Breed tools. It’s actually a big collection of so-so software tools. [23:11]So what’s happened is if you go to a Best of Breed landing page provider, and a Best of Breed shopping cart and payment provider, and Best of Breed marketing automation, and you combine those together using integrations, you can actually get a much better tool out of it. So, what these competitors have done is over-extended their teams. They’re not able to properly support the software. They’re not able to properly build enough features in it to keep up with everyone. That’s where they’re finding themselves. As the product matures, they still have a large customer base, but they’re finding themselves being, kind of, beaten on the lower end from new competitors who can come out and just build one piece of it. So, keep it in mind, if you try to extend out too far to areas which are not related to your core product – especially if you’re a really small team – that’s something to look out for.
[24:00] Mike: I feel like this supplies a lot more to established products that are trying to do new things with their products. If you were to take Mail Chimp, for example, and have them start doing landing page design so where they’re not only sending out emails, but they’re also designing the landing pages that the emails that are being sent are driving people to. It seems like that might be a natural extension of what it is that they do, but at the same time they may just not do it very well. It does shift the core focus of the developers and of the management team to a slightly different vertical, because now you’re saying, “Okay. Well, we’ve got this group of people who are sending out emails. Then we’ve got this other group of people who maybe just want landing pages, but we’re really focused on trying to get some collaboration between those two, and overlap as much as possible between the two so we can leverage one market to get into another. And that doesn’t always work out. Sometimes it’s better to just simply spin off a new product under, kind of, a new team. I do feel like, in some ways, this is a problem that applies to larger companies than much smaller companies.
[25:01] Rob: But I’ve seen it happen with the smaller guys too, because it’s pretty easy – especially early on – to get a lot of questions and requests and not know which ones to build or not. And a lot of them are going to come out of left field, especially if you have competitors who are large and already cover four or five different product spaces, like email marketing and landing pages and shopping cart. I mean, those really should be three “Best of Breed” products that are linked together. But if you have competitors that have already built all of that, then the first thing you’re going to get as soon as you start building is, “Oh! Can you do a shopping cart too?” And that alone is six to twelve months of development to build it well, and then you need an ongoing team just to keep adding new features to try to keep up with a Shopify, or a Magenta, or another cart that’s going to be really well-built. I’ve seen it happen in the smaller space. We certainly get these requests – that’s why I’m bringing it up – and we’re obviously not a big, massive company. And if we decided to go into those spaces, I personally think it would be a mistake.
We could have built a landing page provider by now. We could have built it in a month or two, but it wouldn’t be anywhere near as good as a Leadpages or an Unbounce, and the same goes with shopping carts.
[26:10]So I think the last thing to think about when you’re trying to prioritize and think about whether or not to build features is, if you do decide to build a feature, every time you should be asking yourself, “How can you hide it well enough in the user interface, so your app doesn’t become a hideous collection of check boxes and settings?” This is more basic UX stuff, but you use a lot apps – I think we all do – especially it tends to happen more in open-source, unfortunately, because I don’t know that there is someone maintaining the UX and managing that. But you see them, they’re just a bunch of settings, and you really can’t find you way around very well. That comes from just implementing everything and not really asking yourself these hard questions, of how many people will use it. And then thinking about the fact that things that most people will not use should not very visible in the UI. They should actually be hard to find. So whether you do that through having lighter text, having them being hidden until someone clicks something, having an advanced view that only shows all of the check boxes if you’re an advanced user. I mean, we have entire features that are completely hidden for all of our users until we uncheck a box in our admin area, and that’s purely to keep the product really useable for that 80 to 90% group that wants to do some basic stuff, and maybe exercise their muscles with email marketing. But the really advanced stuff, we hide it quite a bit in the UI. And I feel like that’s helped keep the core product from basically just bloating out.
[27:37] Mike: And that’s really just about establishing what the 80% of the market needs for your particular product, and as long as you can figure that out you’re addressing most of their needs. The rest of it’s a matter of figuring out, “What is not used by people very often, but some people still need it?” You know, those “power users” that need those advanced options. And I’ve used a lot of products where they have the special advanced menus for doing things, or they’ll have an interface where there’s all the basic options there, and then you can click on this link that expands this other area that will show you all of the advances options. But most people don’t need that, so they just use the basic menu.
[28:12] Rob: Yeah, and I’ve been quite surprised at the low level of usage of several of the features that we’ve built. Some pretty key features that several people requested are used by a handful of users. Now the users who use them love them, and they don’t want us to remove them from the product for sure. It’s the 80/20 rule, but it’s not even that – it’s like the 95/5 rule. It’s like just a couple percent of our people use them, but they really, really use them everyday. So that’s your challenge, right? You can’t build fifty different products for the 2 to 3% of people who use all the different features, because it would become bloatware. So you really have to spend time thinking about not only should you build the features, but then if you decide to build them, how can you keep that UI as simple and as elegant as possible, especially for new users getting started, because that’s where you don’t want to overwhelm people, during the on-boarding process.
[29:06] Mike: 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 “Out Of Control” by Moot, used under creative commons. Subscribe to us on iTunes by searching for “startups”, and visit www.startupsfortherestofus.com for a full transcript of each episode. Thanks for listening, and we’ll see you next time.
I found the Stanford class podcast Rob mentioned on my Beyond Pod app by searching for, “How to Start a Starup”. Thanks for the tip! Always looking for a good listen!