Rob Walling: [0:00] In this episode of Startups For the Rest of Us, Mike and I discuss a six‑hour Lean Analytics workshop put on by Andreas Klinger, called “Startup Metrics, a Love Story.” This is Startups For the Rest of Us, Episode 187.
Rob: [0:23] Welcome to Startups For the Rest of Us, the podcast that offers developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product, or you’re just thinking about it.
[0:31] I’m Rob.
Mike Taber: [0:31] And I’m Mike.
Rob: [0:32] We’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, Mike?
Mike: [0:36] A few weeks ago, we put out a call for people to email us in their stories and let us know if they’ve quit their jobs based on listening to this podcast. We got one in from Jerome Samuels.
[0:46] He says, “This is Jerome Samuels, founder at www.goalreports.com. I wanted to let you know that this week I quit my day job to focus fully on growing my two bootstrap startups. Thanks for all the great advice. I could have not have reached this point without your show.”
Rob: [0:59] Awesome. Congratulations, Jerome.
[1:01] When this podcast goes live, I’m going to be in Scotland speaking at the “Small is Beautiful” Conference and they actually emailed Sherry a couple of weeks ago and she’ll be speaking as well. They saw her MicroConf video for her attendee talk from last year and they wanted her to talk about anxiety and pressure and all that stuff and entrepreneurship.
Mike: [1:18] Very cool, so free trips to Scotland.
Rob: [1:19] Exactly. Seek me out at the conference. I’m having a little Micropreneur Meetup, a little dinner on Thursday evening at a local place in Glasglow. Lastly, we received a lot of good comments on the podcast recently. In episode 184, we talked about hosting recommendations and Andrew Connell brought up some other options aside from just the VM side or aside from virtual machines.
[1:43] Because you and I talked about using Amazon Web services and using EC2 stuff, where you have your own virtual machine that you’re able to control and you talked about Azure as your virtual machines. Andrew Connell brought up what’s called PAAS, platform as a service. Which is things like the true Azure, where you’re just uploading your code into this bucket and it’s executed.
[2:03] Heroku is the same way and the Google app engine is the same way, where you don’t have a VM, everything is taken care of for you. You don’t need to do backups. You don’t need server patches and server maintenance and all that stuff. Andrew’s a proponent of that and he mentions several options. There’s obviously Azure, Google app engine, and Heroku, like I said.
[2:23] I’m still not a fan of these platforms as a service providers or at least the way it’s being executed. Because what I noticed is that you don’t have a ton of control and if you need anything that’s nonstandard, you aren’t able to install it.
[2:35] I know we had looked at using Heroku for Drip, but you don’t have enough control to install some of the more exotic gems that we wanted it. For me, that it’s just a deal breaker to not have that control.
[2:45] I think these things may expand to the point to where they are able to better serve the needs of maybe more complex apps. At this point, it’s not something that I’ve used, so I have a tough time recommending it to other people.
Mike: [2:58] Yeah. AuditShark actually uses the Azure Platform as a service. I’ve used it. It’s got its pluses and minuses. Somebody who has like a lot of systems administration knowledge, I’m perfectly comfortable just firing up a VM and using that.
[3:13] I also build it on that platform knowing that I’m probably not going to be the one who’s going to be managing things long‑term. I don’t necessarily want somebody to have to hire somebody to manage virtual machines if I don’t have to.
[3:24] The plus side though is that if you go that route, you can always scale back and go over to a virtual machine at anytime. If you are on a virtual machine and you want to go to platform as a service, you have to re‑engineer some stuff.
[3:37] It depends on where you’ve started, and where you ultimately want to end up as to what is going to be the right choice for you, and what’s going to give you the most flexibility.
[3:45] All of that said, I think that there’s definitely large learning curves in terms of deployment and managing deployments, and pushing out new code bases, and being able to roll things back.
[3:56] It’s not nearly as simple when you get into platform as a service, because there’s all these different individual components. You have to manage each of them separately.
[4:05] If you want to roll back, it’s not as easy as just taking a database snapshot. You have to make sure those things are done in the right order, and it’s not just about doing them in the right order. It’s about making sure that you do them in a very tight time window.
[4:21] The problem is that none of them are necessarily fast when you want to do certain things. Like if you’re in SQL Server, you can go in, you can go onto the Command line, and you can actively kill a lot of the incoming database connections.
[4:33] I don’t know if you have that option with the Azure version of databases. I think it’s called “SQL Azure.” It’s a little bit harder to disconnect people in order to do a backup.
[4:43] Now, you can still have it do a backup, but it just feels like you have more control when you have direct SQL Server installed on the machine. That’s the way I feel when I’m using it.
[4:52] I feel like I have more control over everything and all the individual pieces when I’ve got a virtual machine. Plus, with a virtual machine, a lot of times you can just install everything all in one box. You take a snapshot of that box, and you’re done.
[5:05] When you’re using all these individual services, it’s not so clear cut. You can’t just take a snapshot of that one machine. Which is a benefit for redundancy purposes once you start scaling up really, really high, but it almost feels like going with a virtual machine.
[5:16] It might be a better fit for entrepreneurs when they’re dealing with much lower numbers of customers, because it’s going to take you awhile to get to that point.
[5:23] I’ve heard a lot of people say, “Oh, well, it takes six months, a year, or two years to get to the point where a SaaS application is bringing in enough revenue for it to fully support you and possibly one or two other developers. Do you really need all that stuff up front? And the answers is probably not.
Rob: [5:38] I think lock‑in was my other concern. If you built something specifically for Google App Engine or for Azure, and you wanted to put it somewhere else on a VM, my understanding is that you, after, then go make code changes to it, that it’s not actually as simple as just moving it over.
Mike: [5:51] Not necessarily, it depends on exactly what you’re doing and how you’re doing it. For the code that’s executing on Azure for example, if you’re writing an MBC or Web Forms applications, you’re going to essentially extract those pieces of it and just install it onto a VM, and you don’t have to worry about it. Basically, you’re just ripping a code out and you’re ripping configurations out.
Rob: [6:11] I got it.
Mike: [6:12] Versus, if you’re going from a VM over onto the Azure platform as your service, then you have to add these configurations in.
[6:17] For the back and storage, for example, you’d have the same issue. If you’re using blob storage or Azure tables, which are different than sequel tables. It’s basically no sequel system. You’re going to have lock‑in if you do that versus, if you’re going to go back to…Amazon’s got their key value pair storage, which is basically the same thing.
[6:38] There’s MongoDB, I think. There’s Redis. You choose any of those technologies, you’ve got vendor lock‑in, whether you like it or not. It’s all the same type of thing, it’s just a matter of which vendor you’re choosing.
Rob: [6:47] Right. And Andrew Connell also points out some benefits, though. He says you only pay for what you use, like a VM. You can have a VM with only 15 percent utilization, but you’re paying for the whole thing, whereas the platform as service stuff is really, truly a metered thing. Then there are some…Both AWS and Azure have the start‑up plans and allow you to do it free for quite a while.
Mike: [7:09] I think that that’s the big sales pitch for those, but at the end of the day, it’s probably not significant enough to actually matter in most cases, I don’t think, at least not at the small scales that we’re talking about.
Rob: [7:19] It depends on how big your VM is. If you go with someone like DigitalOcean or Linode.com, it can be really inexpensive. Cost may not be that big of a deal. I don’t think that scaling would be easier, that’s the last thing Andrew points out. Is that if you’re in Azure, scaling up should feasibly just be rotating a dial, whereas…I’d been surprised on EC2, as we’ve had to scale up. I mean, you basically need to instantiate a new VM, re‑install everything.
[7:43] We’ve always had a deploy script that does that, but it’s still…There is definitely time to move up. If we’re moving the database, there’s some downtime involved as we move the data over. If we’re moving code, we can round‑robin it. It is more cumbersome than I’d thought. It’s more like having physical boxes, than being on platform, as the service would be.
Mike: [8:03] If you go with your Azure, Rackspace, or anything like that, you can…I believe you can just redeploy those images and just give them more resources. I mean, I can sell them on the platform as a service on the Azure site, so I don’t really notice, but I know that with Rackspace, if I need a bigger machine, I just bring the thing down and add more resources and bring it back up again. It literally takes seconds to do.
Rob: [8:24] Right, yeah. EC2 has fixed instances. You can’t just add RAM to something. You have to move up to the next highest one, from what I understand. If you try to take your image and just change it to the next size one, it doesn’t work.
Mike: [8:39] They actually have it separated, probably on different hardware for the instance types.
Rob: [8:43] I got it.
Mike: [8:44] With Rackspace, I think they have this cloud infrastructure in the back‑end, and they bring it up on whatever hardware is available. It’s meant for that purpose. If I want to add more RAM to a machine or decrease the amount of RAM and hard‑drive space, I can just do it. Unlike on the Windows site, you can’t decrease it [inaudible 09:00] . Once you go up, you’re done, but with the Linux images, you can go up or down.
Rob: [9:05] Thanks, Andrew Connell, as always, for the insightful comment.
Rob: [9:12] Today, we’re talking about a six‑hour Lean Analytics workshop put on by Andreas Klinger. This slide deck caught my eye. It’s on slideshare.net. We’ll link out to it in the show notes. It’s called, “Startup Metrics, a Love Story.” It is so in‑depth. It’s one of the best examinations of early start‑up metrics. Not just SaaS metrics, but he talks about some BDC stuff, marketplace, metrics.
[9:35] I really just wanted to take a few points out of it. Obviously, since it’s six hours, it’s a 170‑something slides. There’s no chance we’ll be able to cover even 15 percent of it. We’re going to start with an opening thought. As I went through this, I was debating whether his slides only applied to deep innovation or whether they work with some tried‑and‑true just launching a new app.
[9:56] What I mean by that is, a lot of times when you read the “Lean Startup” book or you hear Steve Blank talking about stuff, his stuff doesn’t necessarily apply to a smaller niche app.
[10:05] Let’s say you just have a SaaS app that wants to help, electricians manage their projects, you’re not going out and trying to build the next Uber, or you’re trying to build the next Twitter, or the next Facebook, like some new idea that doesn’t exist. You’re really just applying an existing app idea to a new market, to a new niche.
[10:23] Something I don’t like about a lot of the start‑up talk, is it leaves out all the bootstrappers. What I liked about “Startup Metrics, A Love Story,” is that the more I got into it, the more I think it applies to stuff that we’re talking about. It applies to smaller SaaS apps. It applies to niche SaaS apps. He also does a good job of applying it to communities and marketplaces, like I said.
[10:42] I think it applies more broadly than you might think. Let’s dive into the first point. Andreas talks about, he says, “missing the mark.” He says, “The biggest risk of a start‑up is not the risk of time or money that you’re investing, it’s building almost the right thing.” And he says, “The pain is in seeing a successful competitor who does what you do, but has one little detail that you never focused on.”
[11:07] This is a fascinating point. To see how many people…You look at how MailChimp approached the market versus AWeber. That AWeber have been around for years, so is Constant Contact. And when MailChimp came on the scene, I remember thinking, “What, another one? Really, how are they going to do any of that”? And now they are, as far as I know, they are the biggest.
[11:26] They did a couple of things different that AWeber and Constant Contact had done, and that’s made them the leader. I think Buffer did the same thing. There were a number of competitors in the space that Buffer is in. When they came on the scene, I felt the same thing. “Really, these guys are going to do this? Aren’t there already this places that can buffer it? I already used Hootsuite that can do it.” And yet, they rocketed to the top.
[11:45] They’re like a low seven‑figure business and they’re doing great. The other one I was thinking about is Square. Square really made it a lot easier. They tweaked one or two little things, and they have just kicked the crap out of all the merchant accounts, even PayPal Web Payments Pro, which was the one I used to use, because it was easier. I really see what Andreas is saying. I like what he’s saying here about building almost the right thing, might be the most painful thing of starting a start‑up.
Mike: [12:08] I think that’s because you look at the things that somebody else’s done. You know how much time and effort you invested into it, and you just miss one detail. That’s just the most frustrating and aggravating thing. They’re successful and you’re not.
[12:20] I think that there’s probably a lot of people who are listening to this podcast who have built something, who have gone through that pain themselves. It’s Steve Jobs who said that’s easy to connect the dots looking backwards, but you can’t do that looking forward.
Rob: [12:32] Next thing Andreas talks about is product/market fit. I like this concept. This concept was coined by Marc Andreessen, who obviously was one of the co‑founders of Netscape. He’s a brilliant start‑up strategist. He’s in the realm of a Paul Graham. His quote…He said, “Product/market fit is being in a good market with a product that can satisfy that market.”
[12:55] As soon as he coined that, it was like a revelation in the start‑up space. Of all of us building stuff, whether it’s that revolutionary thing, or whether it’s just building another email marketing app or another SEO app, until you’ve found a product/market fit, you can’t scale, because you hit this point, and there’s actually a bunch of graphs in the slideshow that I think it’s pretty interesting.
[13:19] He basically shows, just bumping along, that your churn is too high, and people either aren’t signing up, because your value proposition isn’t there, or they’re signing up and churning out. I’ve experienced all of these things in the past couple of years, by the way, with the apps I’m building. Then there’s this line, and if you hit product/market fit, that’s where you start scaling up, and that’s where that magical hockey stick starts.
[13:39] I think the thing to think about, instead of thinking of product/market fit as a buzzword, is to realize that if you’ve built something that people are really not churning out of, that people are sticking around, and you see your churn go down, you just start to see growth. You have to be blocking and tackling.
[13:54] You have to be doing the marketing, driving people into your funnel, and optimizing things, but this is really the only point at which you can start to scale up the business, is after you’ve built a product that this market really wants and you start realizing how to reach that market.
Mike: [14:09] The most difficult piece of this is that you don’t know that you have product/market fit, and you don’t know what it’s going to take to get it, until you’ve already got it. People can think that they’re going to have product/market fit.
[14:20] They can talk to all the different potential customers and actual costumers that they have, but until they get to the point where they’re actually growing and their company is not churning out costumers, then you have to look backwards to figure out whether you’ve got product/market fit. You can’t look forward, and I think that’s probably the most difficult piece.
Rob: [14:38] Andreas points out, he says, “Early stage,” ‑‑ and he puts that in quotes ‑‑ “Early stage has nothing to do with how long you’ve been in business.” He’s defining it as being before product/market fit, and that’s when you’re in an early stage. You’re still iterating. You’re still trying to find that point at which you build something that people really, really want. He quotes a stat from a study.
[14:57] He says,”83 percent of start‑ups are pre‑product market fit.” That totally resonated with me. It’s like four out of five, basically, are pre‑product market fit. I totally see that. It’s like when you talk to somebody who’s just struggling to drive traffic or keep people around, or they get sign‑ups and nobody sticks around, that’s what’s happening.
[15:15] It’s like they haven’t built something that people want to where you can get to that growth. Remember, Paul Graham talks about with Y Combinator they’re looking for 5 to 10 percent weekly growth. They’re talking 20 to 40 percent monthly growth, month over month.
[15:31] That’s what, once something has product/market fit and once you’ve actually built something that people really want, that’s the kind of growth that they would expect. That’s what’s a no‑brainer to raise‑funding. That kind of growth is really the hockey‑stick of what people are talking about. Andreas points out, like 83 percent of start‑ups are before that point, they just haven’t found it.
Mike: [15:51] This isn’t to be confused with the problem/solution fit, either, because those things, they go hand in hand. You do need to get to both of them, but product/market fit is, obviously, a little bit different than problem/solution fit.
[16:03] With problem/solution fit you try to make sure that you’re solving the right problem that people are going to pay for, but product/market fit is really about identifying the people and the types of people who need that particular product. You do need both, but I don’t necessarily think that everyone truly understands the difference between them and is able to focus on both of them.
Rob: [16:24] It is challenging. I think I would define problem/solution fit as being before product/market fit, I think, almost in all cases, because you have to find that problem. You have to build a solution that works to solve that problem, and that’s what problem/solution fit is. Once you’ve done that for one person or for five people, then you now have to say, “OK. How do I make this into a product”?
[16:48] Problem/solution fit doesn’t imply that you really have a full‑fleshed product built out. Maybe you’re still doing stuff really manually. Maybe you’re still doing consulting, you’ve just found a problem that you know how to solve, now you have to then build a product and hope, and not just hope but iterate it and ask. Then, as you said, you have to take that next step, find the market for it, learn how to market to that. That’s when the whole business model stuff comes in plan.
Mike: [17:13] The issue that I see is that, just because you have solved the problem, doesn’t necessarily mean that people are willing to pay to have that problem solved. That’s where the product/market fit comes in.
Rob: [17:22] Absolutely.
Mike: [17:23] One does come before the other, but I think people focus too much on solving the problem and not necessarily enough on finding that market for it, where that will scale.
Rob: [17:32] The next thing Andreas points out, and I like this, is he talks about when analytics are not applicable. He says most web analytic stuff we talk about, including split testing, funnels, referral optimization, et cetera, is meant for after product/market fit.
[17:50] He goes through several slides where he points out how Google Analytics is not relevant at this point. Analytics, they just don’t do much for you before product/market fit, because you can’t optimize and aggregate at this point because you don’t know what you’ve built yet.
[18:05] This ties back to a couple conversations we’ve had. Remember? We answered a question that Andrey Butov had raised on Bootstrapped.fm podcast. He was talking about this specific thing about how to do really early stage stuff before you have even 500 unique visitors on your website. How do you do split testing and funnels?
[18:23] We basically came on and said you don’t. All that stuff is for after you have a critical mass. I hadn’t thought about it as being pre‑ and post‑product market fit. I just thought about it having enough traffic to do it, but I think Andreas brings up a good point here. It’s not worth optimizing these funnels until you know that you built something people want.
[18:41] I realized that I had been doing this intuitively with Drip. I don’t want to drive a bunch of traffic and optimize a bunch of funnels. I really haven’t because we’re still trying to find that thing that really applies to this product market and really keeps a lot of people from churning out.
Mike: [18:56] There’s a quote from Ash Maurya, who says that “We need to pivot before products’ market fit and optimize after,” which is totally true. If you’re not familiar with him, he’s the founder of Spark59, and he’s author of “Running Lean.” He has a blog called “Practice Trumps Theory.”
[19:12] It’s totally true. You have to make sure that you’re paying attention to analytics when they’re applicable and just completely ignoring them and throwing them out the window when they’re not because there are times when, no matter what the analytics say, they are wrong.
Rob: [19:25] Your question is probably, what would be the alternative to analytics? In this early stage you can’t look at Google analytics, don’t want to look at split tests and funnel reports and stuff. This ties in. I think why I like this, because it resonates a lot with stuff we’ve talked about on the podcast.
[19:39] If you look back at the slow launch that I did with Drip, I talked to every customer as I went through it. I didn’t look at any of these reports. You don’t need many people coming through your funnels in the early days. You just want them to stick around.
[19:52] The advice is don’t look at averages. Talk to customers individually. That’s really what the slow launch embodies, right? It was like getting one person in at a time, building what they needed, not just getting them on board but figuring out, do we have the features that are going to make you really want to stick around and really continue paying for this product?
[20:11] If not, let’s build those before we continue. That is the alternative to analytics. It’s literally talking to every customer, doing high‑touch sales, handling them, and getting them into your app in the very, very early days. Then the next step, still pre‑product market fit, is just start looking at things using cohort views.
[20:32] It involves looking at groups of people in as small of a group as you can because anytime you’re talking about averages at this point and looking at things in aggregate it tends to be really inaccurate. You want to look at the most granular level possible so that you can actually see trends with…instead of seeing that your overall churn average is 25 percent. It’s not helpful.
[20:53] What you want to do is you want to say, “What’s the overall churn for people in their first week, in their first month, in their second month, after their third month”? These things all will give you a completely different picture, especially at this point before you have enough critical mass to really have some smooth averages.
Mike: [21:09] Looking at those types of things, using the cohorts to view the trends, is really after you’ve got enough data and you’re in a position to start looking at the analytics themselves. As you said, the good news is you don’t need that many people in the early days to figure it out.
[21:21] You want people to stick around, but you also want to do that customer development and talk to each person individually. That’s really what you’re talking about, saying, “What is the alternative to analytics”? It’s customer development. If you don’t do that customer development, you’re not going to get the information you need to be able to mentally aggregate people.
[21:38] Our brains are wired to match patterns and recognize patterns. Sure, we can program that stuff, but it’s a lot more difficult to take those conversations and translate them into some data that we can look at.
[21:51] You have to rely on your brain a little bit to say, “Oh, this person said this thing. This other person said something else, but it was sort of similar. Oh, they’re probably talking about something that is very closely related. Let me dig into that a little bit more, and let me mentally group those people together.”
[22:06] Maybe you use those people as a cohort because they’re in the same industry or because they are trying to solve the same types of problems or have a similar size business, something along those lines.
Rob: [22:17] Early on with Drip right after the slow launch as soon as I started getting enough people using it that I could get some members, we built a dashboard where I could see the churn and see the lifetime value. Right away I knew that it was completely almost nonsensical. It wasn’t helpful at all.
[22:33] It didn’t help me guide the business because the numbers moved so quickly because of our low number of actual trial users. When you have 50/60 trials in the queue and just not that many paying customers, it’s not helpful to look at stuff in aggregate. The basics that I typically would look at is a customer’s lifetime. You just take one, and you divide it by your churn rate.
[22:56] If you’re losing six percent of your people per month, you divide 1 by 0.06, and you get just under 17 months. That would say on average people are sticking around for 17 months. Then you can look at your average revenue per user, and you multiply those two things. You can get your customer lifetime value, but that stuff isn’t helpful at this stage.
[23:14] The real question is, so what should you focus on in this pre‑product market fit stage? We actually discussed startup metrics for Pirates in Episode 112. The startup metrics for Pirates are acquisition, activation, retention, referral, and revenue. It’s AARRR, and this is coined by Dave McClure.
[23:35] This is in line with any type of funnel stuff that we would have talked about. The answer to the question, what should you focus on? If you look at this AARRR, you’re supposed to focus on retention. Retention is a function of user happiness.
[23:48] It describes not only someone visiting again but actually doing a core activity again, that they’re sticking around and using the app. If you’re thinking, “What should I focus on”? You have to build something that people are using and continuing to use. Again, that comes back to this idea of the slow launch.
[24:07] If I got someone in there and they’re using and they decide not to, then I need to figure out, A, can I build stuff that will help them use the app over and over that will make it a critical part of their workflow? Or do they happen to be in a demographic or group that I’m just not going to cater to for?
[24:25] That’s where you’re trying to figure out product/market fit because you may not be building a product for the blogging market as an example, which I wasn’t with Drip. When I did have a blogger come in and I had a couple, and I wasn’t able to retain them, I realized that, oh, it’s that I’m not going after that market.
[24:43] Whereas if I had an info marketer or someone with a SaaS app come in, use Drip, and then cancel, “Well, I have a real problem,” that’s what I was focusing on ‑‑ how to retain people that are in your target market.
Mike: [24:53] I think the one thing you left out there is that you really need to focus only on one core metric at a time because if you’re trying to change two different things at the same time, any actions that you make to instantiate that change, it’s going to be difficult to draw a correlation between whatever the action was and those end results.
[25:12] You may attribute some of those things incorrectly, and you don’t want to do that. You want to make absolutely sure that any changes that you’re making to the product or the marketing are explicitly coming out with one concrete result.
[25:24] If you’re not able to do that, then it’s going to make it a little bit more difficult for you to make decisions moving forward because you can change two different things that had one result over here, but maybe it was a combination of those two things that you changed that created that result. You doubled‑down on something, and it doesn’t work.
[25:41] You just wasted a ton of money because it was those two things in combination with each other, or you chose the wrong thing to double‑down on. You want to make sure that you’re only focusing on one thing, and that’s one reason why.
[25:50] Another reason is that it can be difficult to try and focus on more than one metric at a time. If you’re not focusing on just one of those metrics, then you can just easily do the wrong things.
Rob: [26:01] As a startup you’re obviously limited by time and money, especially for bootstrapping. You do it on the side like a lot of our listeners are. Trying to focus on even two metrics, you just don’t have the time to attack both of those things at once.
[26:17] When I’ve launched apps or when I’ve started to grow apps and I see that I’m not retaining people and that I’m bleeding out of the bottom of the funnel, I will stop all marketing because I don’t have the time at that point and the multitasking ability to be able to handle all the marketing that’s coming in, optimizing those funnels, and trying to retain people.
[26:36] That’s where I would go into this operation retention thing where I would try to find every reason that people were cancelling and just spend 30 to 60 days just taking care of that.
[26:45] Then I would circle back and focus again on the marketing and the funnels because I do believe that it’s virtually impossible to do both well. That’s really what Andreas is saying here. A startup should focus on only one core metric at a time.
Mike: [27:01] That wraps us up I think. If you want to find out more about this particular presentation, come to the website. You’ll find a link in the show notes that links over directly to the presentation over on SlideShare. If you have a question for us, you can call it into our voice mail number at 1‑888‑801‑9690 or email us at email@example.com.
[27:19] Our theme music is an excerpt from “We’re Outta Control” by MoOt used under Creative Commons. You can subscribe to us in iTunes by searching for “startups” or by RSS at Startupsfortherestofus.com where you’ll also find a full transcript of each episode. Thanks for listening, and we’ll see you next time.
Transcription by CastingWords