LinkIn outreach

Rob: In this episode of Startups for the Rest of Us, Jordan Gal and I discuss the LinkedIn outreach, how to divide time between new features and fixing bugs, and we answer more listener questions. This is Startups for the Rest of Us episode 452.

Welcome to Startups for the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you’ve built your first product or you’re just thinking about it. I’m Rob and today with Jordan, we’re going to share our experiences to help you avoid the same mistakes we made.

Welcome to this show. Each week, we talk about building startups in an organic, sustainable fashion that allows you to build yourself a better lifestyle, maintain freedom, purpose, and healthy relationships. Some weeks we talk through tactics, other weeks we do interviews⁠, we have founder hot seats, and some weeks we answer your questions. This week, I was very pleased to be able to sit down with Jordan Gal and answer some listener questions. I hope you enjoy this episode.

Jordan, thank you so much for joining me on the show today.

Jordan: Thanks very much for having me, Rob. It’s post-4th of July Q&A session. I’m excited.

Rob: I’m stoked to have you. Folks will know you from Bootstrapped Web and you run CartHook. Before we dive into the questions, I’m curious what your take is on where you’ve come from and where you are with CartHook because CartHook is approaching 30 employees. It’s a fast-growing SaaS app. When you look back a few years ago, I think when you and I first started talking—I angel invested in CartHook for those who don’t know—I think you were like 5K MRR.

Jordan: I was going to say way back in the day.

Rob: Yeah. It was really early like what? What is that like? Did you pinch yourself? Is it surreal? Did you dream of one day having a SaaS app with 30 people? I can’t imagine what that feels like.

Jordan: I think it’s the opposite for me that before this, the struggle was like a nightmare, and this is like, “Oh, this is where I was supposed to be.” That’s how it feels to me. This was the plan and I always telegraphed in my mind, like, “This is how it’s going to feel like when it’s the way it’s supposed to be.” Before that was just this annoying nightmare to go through to finally be like, “There we go. This is how it’s supposed to feel.”

Rob: It’s such a trip. As you go through it, it’s these small changes. I remember thinking, “Wow. If I had a team of 10⁠ or whatever, it would just be these huge thing and it would be so bazaar and it would be amazing.” When we got there, it was like this just feels normal now. You didn’t go from 0 to 10. I didn’t go from working alone having 10 people. We just hire them one at a time and you just build the team. Does this feel the same way to get to where you are?

Jordan: Yes. It feels incremental. In hindsight, it was fast. We worked from 4 people to 24 and we’re hiring a few now. That happened over the span of two years, I think that’s pretty fast for a 24 in two years. It was incremental along the way, weeks go by, months go by, new people get added. We have that additional element of having two offices, one inPortland, one in Slovenia. I would feel it in Portland when you hire a new employee. All of a sudden you have someone new in your day-to-day life, but we only have 11 people in Portland. Slovenia, I go back every 4 months. Everytime I go back, I have two new people to meet. That was more abrupt changes on the Slovenian side and the Portland growth felt more natural; it’s one by one.

Rob: Your role as CEO, I know in the early days, you do everything. You do anything that is falling through the cracks, basically. What’s your role like today with that many people? What are your top three high-level priorities over the course of six months or a year?

Jordan: It has changed and I’m happy with the change. I’m not very good at doing things day-to-day. I don’t have amazing work ethic, I don’t have good discipline, I can’t sit down and focus for many hours at a time. I’m just good at thinking and strategizing what should be done and I’m generally not that good at executing it. To have people now in positions where they are far better than I was in those positions feels good and right.

Now, the nature of the role is worrying about what’s going to happen externally, but mostly worrying about internal. Do people have what they need? Do they know what they need to do? Are they happy? Are they going to stick around? Are they happy with their interpersonal relationships inside the company? Does everyone know what we’re trying to accomplish? It’s a lot of like worrying and checking in on that worrying like looking under the hood a little bit to see, “Hey, is this functioning properly?” Every once in a while, something will pop out where it’s evident, “Ooh, this is wrong or broken.” I have to go to action mode for a week or two to fix it. That’s what it feels like.

Rob: I think it’s a venture capitalist that said that with venture-funded startups—which you are not, to be clear, you raised a couple of angel rounds but not taking institutional money—they view a CEO’s priorities as three things. One is hiring the high-level folks, not every individual when you hit the certain scale, but making sure that, basically the right people are getting on the bus, keeping enough money in bank so the company can make payroll.

Jordan: The money, the bank thing, that’s very clear. I used to think that relatively risk-loving in my personality, but what I have found in running this company and speaking to other founders is that I’m actually pretty conservative when it comes to the runway, to the cash on hand. Some people push it. They go 90 days, 60 days of cash and I’m always 12 months. I am very uncomfortable with less than 12 months of money in the bank.

For me, one of the driving forces is the mojo, for lack of a better term, the happiness that’s happening inside the company, how much people love their job, and that would get wrecked by layoffs. Not only do I want to avoid laying someone off because that just sucks all around, especially if it’s your fault, and that they have to pay the repercussions. At the same time, I really, really want to avoid what that would do to the energy in the team. So, I keep it pretty conservative.

Rob: It makes a lot of sense. It’s more like a bootstrapper mentality. That’s how a voice for you do is like a bootstrapper who happened to raise funding because he wanted to grow quickly and wanted to go into a space that was competitive, but still, you’re ethos has always been that. Much of the bootstrapper, that MicroConf ethos.

Jordan: Yes. That’s proving yourself out.

Rob: I remember the third thing the venture capitalist said. The reason I forgot it is because it’s just so fundamental, it almost doesn’t need to be stated, but it’s setting the vision for the company and the direction, the high level stuff. It’s obvious, right?

Jordan: Yes, but it’s surprisingly hard. Everyone tells you, the advice is always repeat yourself a hundred times more than you think. Once you’re sick of hearing yourself, that’s about right, all those things about repetition, but it is true that it is hard to keep everyone aligned on what you’re thinking. As the number of people grow, it becomes more and more challenging.

We, at this point, anyone that gets hired, I talk about that vision in the interview so they know where we want to go and the right fit person gets excited by that vision as opposed to, “Woah. This person is crazy.” Then, when someone joins and I do the first one-on-one with them a few days after they joined, I talked about the vision again and I always offer like, “I’ll go to the whiteboard right now.” It’s pretty much not their choice, I’d set them up in the white board anyway. Once a quarter, we also do it. Once a quarter, we talk about our roadmap, right back to the vision, right back to the core tenets. It’s becoming a lot of repetition and it’s still not enough.

Rob: I want to come back to the comment you made earlier. You said that you aren’t necessarily disciplined or get stuff done day-to-day. I question that reality. Maybe that’s the reality now when you have this big team, but back in the day when you were at 5K a month, I remember you were cold emailing, cold calling, doing sales calls, you were getting […] done. I wonder if it’s just the situation you’re in.

Jordan: You know what it is? It is the situation you’re in and I think I have some advantage in being a little older where I’ve gotten to myself more over time, so I’m able to fool myself or force myself into action. The cold email I would do and then I would outsource as soon as possible. Then, demo appointments would pop up in my calendar and it wouldn’t be my choice whether not to do them. It is just on my calendar. I’m doing it.

Rob: In code, we call that a forcing function. You just force yourself to do it. That’s funny.

Jordan: Yes. A lot of forced habits. Even if I don’t want to do this, I’m just going to commit to it anyway. Kind of like the first time you asked me to talk on stage at MicroConf. I was like, “No.” Just answer yes and then you’ll be forced to do it.

Rob: Then figure it out because, “I can’t back out of it once I told Rob yes.”

Jordan: Exactly.

Rob: That’s funny. Cool man. Thanks again for coming on the show. Are you ready to dive and do some listener questions?

Jordan: Yeah. We’ll see if we can be helpful.

Rob: First question is a voicemail about setting up developers who are taking deferred compensation.

Chris: Hey, Mike and Rob. This is Chris Bowls, I’m calling from Kentucky. Working on a new SaaS concept involving the building industry. I’m early right now, but I’ve got three developers who have agreed to take deferred compensation and stock before we began receiving revenue for their compensation. My question is, for these three developers, they’re all in the US, is it best to set them up as an employee, or as a contractor plus investor, or as an employee who is awarded shares? Do you recommend these developers have Class A or Class B shares with voting rights? I’m currently a solo founder, but one of these developers could transition into a CTO. What do you recommend for that? Thank you.

Rob: Obviously, you and I are not lawyers. We can’t give legal advice. I’m curious if you have a gut feel if your face with this scenario, a gut feel of how you would approach it, or even you would find the right answer to this. It’s not a clear-cut solution, at least from my perspective.

Jordan: It doesn’t sound clear-cut, but I think what happens often with business people like us is we conjure up legal realities that are wrong, then we start making assumptions based on that wrong belief, and then we complicate everything. I think this requires a re-orientation and that is best with a conversation with a real lawyer.

I think a lot of this stuff is a little off-base like voting rights. You don’t need to talk about voting rights. It’s early for voting rights. If you’re the founder, you don’t want to talk about Class A and Class B shares. It’s way too early for a lot of these stuff. I think a lawyer would help orient the person toward just getting things set up easily and cleanly. Same thing with independent contractor versus employee, I think you go independent contractor. You keep everything simple as possible before it has to be complicated. It ends up complicated, so why complicate it off to that.

Rob: Right, why start there? I think that’s my take, too. This one does sound sufficiently complex that I really do think that he should talk to a lawyer because I just think you can easily make a misstep with something like this. And I agree, the Class A, Class B, the voting, it doesn’t seem like it’s relevant yet.

Jordan: In our company, the only time that came up is when investors come on board. That’s still a question of whether or not you want to create a different class. Not all investors will force you to create a separate class. The separate class is the thing to avoid because what that creates is a situation where investors have X voting rights and you have different voting rights. Deferred compensation, not ideal, but you can understand how it happens if the developers are saying, “Yes. I’m willing to work and you don’t have the cash flow yet to pay me, so let’s defer it.” The second you touch employment, you’re talking social security taxes, you’re talking employment taxes, benefits, and so on. An independent contractor would keep that much cleaner.

Rob: As long as they fit the definition. I mean, the IRS has a definition of that. If you’re managing them day-to-day, directing them what to do and when, controlling their schedule, then they’re not independent contractor. You don’t want to mess with that kind of stuff. My guess is when you’re in this early stage, you could just give them a block of work and say, “Here’s the deliverable, here’s the deadline.” They can get it to you.

The fact that you have multiple developers working on it, I feel it might be easy to actually make that reality. I hope that was helpful, Chris. Not sure if it was, but if I were in your shoes and you don’t have a lawyer, I would head to upcounsel.com and just have a 30-minute counsel with someone could be helpful.

Our next question comes from Marcelo Erthal. He says, “Hey guys. I’m a digital entrepreneur and a big fan of your show. I’m in Rio de Janeiro, Brazil. We have a web app for the B2B market where we need to contact a specific person in the enterprise that we are prospecting.” I assume that means a specific title. “We found LinkedIn a great tool for this kind of job, but the problem is that when one of my sales guy leaves, he leaves with all the contacts and connections in the space, forcing the new person to start over again from scratch. Do you have an opinion on this? Should I have a LinkedIn profile owned by the company?” What do you think about this?

Jordan: I’ve never even considered that, but it sounds like a reasonable problem. My default was, “Oh, just do it under your own account,” but maybe you’re trying to connect with someone, you’re trying to have one of your salespeople to connect to them directly and then have a conversation. It would be pretty awkward to switch in the middle. What do you do about this?

Rob: It’s a tough one. My gut is that the company account is going to just be so impersonal. When you get contacted by a company account, unless there’s a human being attached to it with a headshot, it’s just a logo contacting you gets no response. I don’t feel like that’s really a good answer.

Jordan: I’m going to say, LinkedIn itself, it’s impressive that they’re making it work.

Rob: Yeah. That they’re making sales on LinkedIn.

Jordan: Yes. LinkedIn is tough. Maybe for enterprise, it’s different.

Rob: I can’t help but wonder if you could start the prospecting on LinkedIn, but then basically, bring them into a CRM essentially, or bring them in to somewhere where, when the salesperson leaves, they don’t have all the connections. I think of it like the hub and spoke model of social media where you have your Twitter account, your Instagram, your Pinterest, whatever, but you’re really trying to get them on your email list because your email list is the core thing that you own and everything else you’re just a digital sharecropper. Twitter, Facebook, whatever, they can ban you at anytime, you don’t really own those followers the way you do with email list.

I wonder if he couldn’t approach it in the same way where you are using LinkedIn as a channel but it’s just the spoke, and you’re actually trying to get them into either a conversation with you team or you’re trying to get their email address or you’re getting them into a CRM where you can have data about the interactions and all that. That’s what the big companies do. Even they have people prospecting on LinkedIn or cold calling or whatever, their relationship is documented in a CRM somewhere so that when that salesperson leaves, they don’t take everything with them.

Jordan: Yes. I think the personal connection and conversations that had been had on LinkedIn sounds like you’re going to lose. But if you get them into a CRM, then the company actually has that asset and that value. If you want to do that as early as possible in the LinkedIn process, my guess is a lot of CRM these days have direct integrations with LinkedIn. If you think about something like SalesLoft, they’re deeply integrated with LinkedIn, and that’s how I would approach it. It’s not really a prospect, it’s not really a lead until they’re in your CRM.

Rob: And unless your sales cycles are really long, there shouldn’t be so many hanging relationships at any given time. You have people who have become customers, you have people that you’re reaching out to, and then you have people who I guess didn’t become customers, but then you have that in-between and there’s always so many in that in-between for now. Well, I may buy in the next month or two. I feel like keeping that number small is probably the way to go.

Thanks for the question, Marcelo. I hope that was helpful. Our next question is a voicemail about how to balance time between new features, refactoring, and fixing bugs.

Colin: Hey guys. Thanks very much for the show, really enjoying it just now. I am Colin Gray. I run a podcasting company in Scotland, thepodcasthost.com, so we people start podcast. We also created a SaaS product last year called Alitu which helps people to produce podcasts and there’s a lot of automation for them.

The thing I’ve been struggling with as we’ve been running for a year now, I have a team of four developers, two full-time, two part-time. I’m struggling to figure out how we should be balancing our time between brand new features, fixing bugs, maintenance, refactoring, that type of stuff. I’m really interested to hear what you guys think around how you balance a new development work with the reliability work because we still get bugs, we still get people that get in touch, it’s not very many. We must be in the less than 2% […] by now in terms of reliability, but what do you think is reliability to aim for in terms of support tickets, bugs, that kind of stuff, and how much time should you be spending on that versus new features? Thanks very much.

Rob: I like this question. Thanks for sending that over, Colin. I think it’s a pretty common thing that, as first time founder, you wouldn’t even think about this before starting an app but at a certain point you have to. I’m curious to hear your thoughts, Jordan.

Jordan: This is the ongoing struggle between making progress on the roadmap and how much time it needs sprint to give to fixes and how much should you have a few sprints in a row that are just features and then a sprint entirely devoted to bug fixes. Everyone has a different way of doing these. A lot of it ends up on gut feel on where your customers are and what you need to be doing.

Generally speaking, I have a few thoughts on it. The thing I like to keep in mind is to make sure we never go too long without giving customers new features. Yes, we have all known issues internally and we’re thinking about, but we need to keep the momentum going. Momentum in the product, momentum in sales, momentum in all the different things, and pushing out new features keeps that momentum going.

For some of the detail that Colin talked about their year in, which tells me, yes it’s starting to pile up and you’re starting to deal with things that are popping back up, but it’s still relatively early on. I assume the codebase isn’t a hot mess the way it gets into it after a few years. The other thing he said was that they get a few support tickets here and there. It sounded from the words he was using and the tone of his voice that it’s pretty minimal. I would say that the tolerance for bugs is a big issue. I know our product is a check out product so the tolerance is extremely low if we have bugs that costs people money, so our tolerance is very low.

Depending on the type of bugs and the type of customers, those bugs might be annoying or might be absolute deal breakers. I think that helps guide you on how far to push it, on how hot to let the fire get before you start throwing water on it. I would lean more toward new features even at the discomfort of the shame and embarrassment of people getting in touch with things that are broken. That’s my general take on it. It sounds like he’s in a pretty good spot. It’s an ongoing struggle to figure out, but I would lean toward being a little bit uncomfortable and a little bit embarrassed.

Rob: I think that’s pretty good advice. I categorize these in my head into two buckets where it’s like there’s user-impacting or customer-impacting bugs or cruft, or there’s UI cruft. It may not be a bug, but it’s all the stuff that is maintenance, like bugs plus an old-looking interface, plus a clunky interface you know needs to be revamped, that impacts the users in that they notice it. That’s one bucket.

The other one is the cruft, bugs, and other stuff that users don’t notice but are a pain in the […] for your dev team. It’s stuff that needs to be refactored or it’s that one the alert that dumps too much information once every few weeks. It just floods the Slack channel or floods your error logs with something. It’s one-off things and users don’t know it, but you know it’s getting on the dev nerves.

I agree with you. You are going to want to probably let some of these go longer than you want to, but I would encourage that you let your developers, give them some leeway to fix the things that are bugging them. What we did in the early days when you’re just shooting from the hip all the time and it’s like, “Hey, what’s the next feature we should work on?” We were literally planning one feature out and we were doing that. We had three developers full-time. We were probably doing 50K MRR and we were still doing that approach. It was super agile and we could make decisions very quickly as we respond to customer needs.

At that point, we would often say, “Let’s just look in the stack and if there’s stuff that we think is bothering people or is bothering devs, just pull the next one off, spend the day, fix it,” and then we all felt good about ourselves and like, “Ah. We got that done.” Then went back to features. Another few weeks later, we’ll be like, “You know? We haven’t really attacked something like that in a while,” and we go back to it.

When we started formalizing it, as the team got bigger, by the time we had 8 or 10 developers, that’s when we started saying, “One morning a week,” which winds up being about 10% of your time because it’s about 3 or 4 hours, “everyone would pull one thing out of the queue, whether it was user-facing,” because a lot of the designers would do user-facing stuff and a lot of the devs would do the cruft that they wanted to refactor, you basically have one morning to pick something and fix it.

That became a cool cadence.It sounds like it would be drudgery, but they actually really like it because it makes their lives better and makes their lives easier. I always felt like there’s something between 10% and 20%. 20% was a full day and that felt like too much to give up every week to just fixing these stuff. Codebase would have been immaculate, but as you said, it negatively impacts your feature velocity. I think that’s how we’ve approached it.

Jordan: I like that. It does end up being seen and felt as a little break. We’ve had entire weeks where we go by and it’s almost a break. We’ve been pushing really hard on this ramp. We just went six weeks straight, all out. The end of it was stressful. Everything went to QA at the same time like it shouldn’t and then everything got out the door. A week of refactoring, going back, and polishing things up is almost a little bit of a breather.

The thing that we had to watch out for is that some engineers have a tendency to refactor as they go. They’ll be in the part of the codebase working on a feature, they’ll be touching an adjacent part of the code, and it won’t be up to snuff compared to what they’re building now. It has some logic in it that we thought was right 12 months ago and then the tendency to want to refactor that before coming back to the feature that you’re working on is dangerous. That’s how things start floating and not being on time. We definitely had to figure out the engineer personalities and help guide people away from too much refactoring.

Rob: I agree. Like with anything, it’s good to know the personalities of the people that you’re working with and know if they err on the side of being much more, “Hey, I’m just a hacker. I’m going to throw stuff in,” and then you know that they need heavy code review to bulletproof their code, and then other people take a really long time to build their stuff, but it is super bulletproof. You often have to encourage them to maybe go a little faster, let’s have a little bit of risk in this to get it done 20%–30% faster. I hope that was helpful, Colin.

Our next question is a bit of a long one. It’s from Dragos. He says, “Hey guys. First of all, I want to thank you for doing the podcast and giving your thoughts on so many entrepreneurial things. Writing to you about my startup, it started as a dream and ended as a lack of motivation and a desire to sell it.

More than a year ago, I started working on an idea where I would change the way people build WordPress sites, make it easier and smoother. It began as my problem because everytime I had to create a WordPress site, I had to search for a theme, buy it, do a bunch of other stuff.

Even if I was a developer, I didn’t have the knowledge of the technology required to build the app nor the cash needed to make an MVP so I borrowed money from my sister and I hired a small agency from Eastern Europe. Seven months later, I had a rough MVP…” Wow, seven months. That’s a long time. “A theme builder that allows people to create one page WordPress sites in just a few minutes.

During the development, I tried to create anticipation and manage to build a list of around 200 people. The problem is the post-launch. I only got one customer. Since then, I’ve had a few thousand visitors, but I have not had any new customers. I blame the execution, the fact that I do not know who my customers are, and I don’t know what to do next.

I’m in a position where I don’t have the technical knowledge which is AngularJS to continue the project. I don’t have motivation, I don’t believe in the idea like I did in the beginning, and I’m afraid to invest any other money. It’s easy to quit as I have tons of other ideas but should I persevere on the initial plan? How do I decide when to do that, when to stop, and just consider the startup a failure?” What do you think, sir? This is a tough one.

Jordan: It sounded like it was going to be a tough one, but then when you get to his tone toward the end, you start to realize this is just a failure. There’s nothing wrong with that. It’s time to move on. That’s my gut feeling after hearing this. The amount of energy and probably money also to turn this from where it is right now into something that works and turns out to be a success, I don’t think it sounds like it’s worth it. I don’t think he has the motivation and drive to do it. I would just choke it up to a lesson and move on.

Rob: I think I would agree with you. It’s funny when I said this is a tough one. I didn’t mean it with a tough decision but that’s how it sounded but it’s a tough email to read because I’ve been there. We’ve all been there and it’s hard.

Jordan: What makes it tough is that pretty much everybody listens to this, including you and I, have been in this exact same situation. It’s tough when you’re in it, but it is one of those things that people from the outside that have a bit colder approach to it, just look at it and say, “I’ve been there too. There’s no shame in it. It’s just one of those things you should just move from if it didn’t work.”

Rob: Yeah. I think if he had the motivation, that’s the thing from me. When you’re a bootstrapper or doing stuff from the side, you never run out of money. Running out of money is what kills venture-backed startups because they burn through the cash and they shut down. Since he’s not a developer, I guess he has run out of funding that he wants to put into it.

Realistically, if he was super motivated to do it, he could learn Angular himself or he could take some of the money he’s making out of his day job and invest it in. If he had the motivation and really thought it’s going to work, but when you don’t have the motivation or the desire, it doesn’t matter. That’s what kills startups. You just get fed up with it at a certain point, you don’t believe it in anymore, and if you still believed it was going to work, you could totally try to make a verticalized version of this like, “I’m going to make this for pet groomers, or for designers, or for whoever.” Pick a niche and you can try to go after it, but it doesn’t sound like that’s that interesting and he wants to move on to the next thing.

It’s the hard balance. I feel like it does come back to knowing yourself like do you tend to just skip from one thing to the next, to the next? In which case, you should stick with things longer than you normally do. But if you are someone who tends to just grind it out and spend two, three, four years working on things that then fail, well maybe you should move on quicker from things in the future. It sounds like given that it took seven months to get that MVP, which is brutal, and that he has said thousands of visitors, this is a real tough one to turn around.

Jordan: Yes. It’s almost a blessing in disguise that it got so little reception. The really dangerous ones are that get just enough reception to keep you motivated to keep going, but will probably not lead you to where you want to go.

Rob: Yeah. That take years and years to get to 5K MRR, 10K MRR, whatever, right?

Jordan: Yes and then say, “Oh, man. I should just stop it,” and then that sunk cost is even more painful. It’s never seen as a sunk cost. It’s always look back at, “Well, I’m two years in. Should I really stop it at this point or should I keep going?”

Rob: Our last question for the day comes from Robert. He says, “So many products fail, but when does fail early not apply? It’s not like fail early can be a universal practice because almost everything seems to fail anyway. None of the advice that seems reasonable seems to work without getting hung up and never shipping. When is it a good idea to spend extra time getting it right from the get-go? Have you ever seen someone fail because the MVP was shoddy, only to see something similar succeed with a higher quality MVP and a more thorough team? Likewise, have you seen a really thorough product with thorough marketing and industry experienced co-founders fail miserably?” There’s a lot of questions here.

Jordan: Yes but it sounds like he’s searching for what is it that makes things successful and other things fail. That is so intangible. There are so many factors there. That mystery has no solution. Everyone has seen these things. Great team, great product rate, everything total failure, and the opposite of someone who doesn’t know what they’re doing and get lucky or looks like lucky and have spectacular success. I don’t know if you can expect to find that intangible thing that makes something successful while others aren’t. It’s tough to define.

Rob: I agree and some parts of his question, of his letter or his email, he said so many products fail. When this fail early not apply? He’s talking about building an MVP that’s thorough versus not. I think back to last episode where Laura Roeder was talking about launching a competitor to pager duty. That’s where you can’t build a shoddy MVP.

I think another one is like to compete against MailChimp, like what we did with Drip. You’re building an ESP, you can’t have a shoddy MVP and get that done. Now, you can go circuitous and you can build an addon to things and then slowly branch in, but I think what I’m getting to is like a mature market where there’s a lot of competitors who have mature products, that’s where just an early MVP that doesn’t have a huge differentiation is very unlikely to get traction.

I think of Josh with Baremetrics years ago, where he is first to market with this one-click analytics. Even with Peldi with Balsamiq where he was the first one to really build this mockup tool in the way that he did it, you can build a pretty basic version because no else was doing it and that basic version was good enough. People would put up with either bugs or just a lack of features because it was a novel new thing and you really couldn’t get it anywhere else.

Jordan: It’s like it requires practice to get a sense of whether or not something is on the right track. I hear you on the MVP, but I think the MVP is internal facing. We know that this is not quite good enough but we’re just getting it out there. The reaction from the market that external pieces is what tells you whether or not you’re on the right track and should keep going or should stop.

Our check out was an MVP when we launched it and it effectively tortured people and then they would cancel but not before the torture. They went through some torture first. The reaction from the market was so strong that we knew we were on the right track. We couldn’t have a shoddy MVP in a check out product, but we did. The reaction was so strong that we said, “Okay. We’re just going to have to bite the bullet here for six months and re-build this thing again, but we know we’re on the right track.”

MVP is one thing. The market is the other. Beyond that, it takes some practice. I went to see Jason Fried talk in New York a good 10 years ago. Basecamp was the hottest thing ever then. I went to go see him talk and at the end of the conversation, I asked him effectively something to the effect of, “Why are you guys so good at this? Why is this product making money when others aren’t?” His response was that they effectively have more practice making money. The more practice they get, the better they get at it. The sense of whether or not a product is working, or the MVP is good enough, or the market is responding properly, I think that stuff just takes practice.

Rob: Thanks for the question, Robert. I hope that was helpful. I realize ‘it depends’ is not always the answer we want to hear, but some of these are just difficult to answer.

Thanks again for coming on the show today, man.

Jordan: Rob, thank you. I appreciate it.

Rob: It’s great having you. If people want to catch up with you every week or two, they can go to bootstrappedweb.com which is where your podcast lives.

Jordan: Every week or two, that’s very kind of you.

Rob: You like that? You ship two or three episodes a month, right?

Jordan: Yes. It’s the summer that throws us off, with all the travels, Brian’s out there in the world, but we’ve got big plans, come back strong in the fall. I’ve taken real effort into this […] to be more open. It’s turning into the low light podcast and those are my favorite business podcasts these days, the super successful stories. Sure it’s entertaining, but the values of someone like your last episode with Laura Roeder, that’s it right there, man.

Rob: It’s the struggles, right?

Jordan: Struggle especially when you come across someone like Laura where she’s ridiculously good at what she does and you get the sense that everything she does works. You have a podcast episode like that and it helps you identify everyone struggles. It’s always just helpful to hear someone in her shoes be open about it.

Rob: There was one line in my MicroConf talk this year that I keep coming back to and it is there are no Cinderella stories. You can look at any startup, she got to seven figures in a year. That’s crazy, but you know that under the covers, that was probably very hard to manage. The things that we see from the outside, they just look amazing, and it’s like, “I wish my company was doing that.” Maybe you do, maybe you don’t.

Jordan: I think that line in your talk, sparkle a lot of conversations in MicroConf that went somewhere to the effect of, if you’re jealous or envious of some situation, just go ask them about it. As soon as they start talking, you’ll realize, “Oh okay. It’s not that amazing.” It’s nothing that you should be envious about. As soon as you actually get the details, you’ll realize how hard it is.

Rob: The growth might be envious but the challenges are not. If you have a question you would like to hear us answer on the show, call our voicemail at 888-801-9690 or email us at questions@startupsfortherestofus.com. You can obviously attach an MP3 or a WAV file to that email. Our theme music is an excerpt from We’re Outta Control by MoOt, used under Creative Commons. Subscribe to us in iTunes or any podcatcher of your choice by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.