Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about how to build more successful integrations. They discuss how to approach the different areas of risk including work estimates, API integration, co-marketing opportunities and more.
Items mentioned in this episode:
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 Mike.
Rob: And I’m Rob.
Mike: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. How are you doing this week, Rob?
Rob: Doing pretty good, man. Just doing a lot of work on TinySeed. It’s been fun to start have more and more exposure to more and more startups. We’ve had a lot of exposure to a lot of different founders of startups over the years through all the stuff that we do with MicroConf and book, blog, podcast, etc. Then I felt like I leveled up when I started angel investing and got in depth views, ongoing longitudinal of a more companies and TinySeed feels like another leveling up for me. It’s just seeing a lot of different data, a lot of different applications, and seeing what’s working, and what’s not, tactics, strategies, approaches, even what is working with the founders who are successful and not, that’s been a fun thing to continue to begin to.
Mike: That’s cool.
Rob: How about you?
Mike: Well, on my end, I’m in the midst of rolling out some Bluetick updates. The main focus here is to provide, I don’t want to say platform, but more of a mechanism for me to do more in the future in terms of displaying emails inside of the applications. Right now, I can send emails out and you could see those emails, but you can’t see the replies to those emails in there or see the history there. Some of these updates are going to allow people to do that and also, give people the capability to inject Bluetick into existing conversations which is not something that it’s capable of right now.
I had actually answered somebody’s question through Twitter the other day. They were asking, “Can it do that?” I was like, “Not yet, but that’s on the roadmap but it’s coming soon. It’s coming in the future.” This will put me in a much better position to be able to do that. And then there’s also various things with the Google authentication stuff that’s in there. Frankly, I’m worried about how that’s going to turn out because it’s a completely opaque process. I have no idea what the end result is going to be so I’m still, I don’t want to say sweating it out, but what is going to be the end result of this.
Rob: Sorry. I don’t know what else to say. That sucks. Goodluck is probably…
Mike: I guess. I mean, there’s really nothing to say. It’s just waiting for them to go in. I don’t know what their checklist looks like, I don’t know what they do or anything. It’s a huge hole, I’ve no visibility here and it sucks. There’s nothing I can do either which is the worst part. It’s just they’re going to either approve it or reject it and they’re going to move on with whatever their timeline is which they’ve been fairly vague about until just very recently where they’re like, “Oh, yeah. You only have three days left.” I’m still waiting to hear from them so if anyone here works in Google and is involved in that process, please email me.
Rob: Yeah, email Mike. Due to some recent fixes that I mentioned last episode, fixes to our WordPress theme, comments are now appearing to end-users and there were a couple that I want to read through.
Episode 436: How to Respond to Customer Suggestions. Steve says, “Great podcast. I’ve made every mistake mentioned in here plus a few more. We have one additional solution while working with customer request. I had found that if a customer wants a specific feature and it makes sense to them in a product, though they want it now and you see it down the road, charge them to put it in now. We charge it as an expedited feature release, it has helped us grow Skills DB Pro…” which is his product, “…to an enterprise level offering while getting paid along the way. One more bootstrapping thought.”
I think that’s a good one. It’s not something that I tend to do with SaaS apps, but back when I had these one more time downloadable stuff, we definitely did it on a number of my products especially the ones that were smaller where a few thousand dollars and kind of expedited feature, this actually moved the needle on the product versus if you’re doing million or more, worst if you have a seven-figure SaaS app then try to charge a few grand to expedite a feature, it’s almost not worth the hassle is how I found it. But I think that was a cool suggestion that some folks might be able to take advantage of.
Mike: Awesome. Anything else?
Rob: Yeah, we have a comment on episode 437 where we talked about MicroConf Europe. I think this was back when we were still trying to figure out where it’s going to be or maybe we even said Croatia, but Rob said, not me, a different Rob says, “Come to Barcelona.” What do we say to that, Mike?
Mike: Do you live in Barcelona?
Rob: No. Well, that’s the first thing because everybody wants us to come to their city, but we have. We came to Barcelona twice.
Mike: Yup.
Rob: We tend to go to cities two years in a row and then we move on to keep things varied. Episode 440, How to Build Case Studies That Don’t Suck. Sarah said, “Great episode as always. You mentioned a book called the Hero’s Journey. There seems to be a few around with that name, can you give any additional details of the right one?” I don’t know if I mentioned a book, but I did mention Joseph Campbell’s Hero’s Journey. I never read a book about it. I tend to go Google and there’s this amazing diagrams and in-depth articles. I mean, the first result on Google is amazing, and it’ll give you the whole overview. Then maybe Joseph Campbell wrote a book called the Hero’s Journey. You can totally go to Google for that but frankly, just getting the idea of what a hero’s journey is like is pretty easy to do from the googs.
Last comment for the day, episode 441 where we answered some listener questions, and then in our aftershow, we talked about the first MicroConf Dungeons and Dragons game. Patrick Mckenzie, his character died early on and he became the final enemy, he was the boss, he was voicing the boss. Christoph Engelhardt chimed in and he said, “My biggest question is what kind of enemy in Dungeons and Dragons game constantly mutters ‘charge more’. Okay, I’ll see myself out.” I thought that was worthy of mention. One of the few funny lines I’m sure that will happen in today’s episode; one of the very, very few, Mike.
Mike: I don’t think I’ll be in any of this.
Rob: That was it. That was all one and done. Today, we’re talking about successful integrations. You want to dig us in?
Mike: Sure. I kind of based this outline loosely on some of the challenges that I’ve encountered integrating with other apps, taking Bluetick and just whether it’s integrating with IMAP servers or going into Zapier or other third-party applications or even using certain libraries, like code libraries. Some of this is retrospective like, “If I were to go back and do it again, how would I approach it?” Because there’s certainly things that I look at now and I would’ve done very differently and then there’s other things where I don’t know how much I would have changed or how much it would have changed, what the end result of that was. I think that these are the things that I’ve learned along the way of doing it and that are generally applicable to most people if they’re going to look to integrations.
I’m sure you have a ton of experience here in terms of taking Drip and integrating it with, I think it was like 30 or 35 different other applications, and incorporating them with Drip throughout it’s, I’ll say, rise to fame.
Rob: Yeah, I mean there was that, there was HitTail. I did, I don’t know, it wasn’t half a dozen, but it was approaching that, DotNetInvoice did a few. I had multiple apps, many apps I would say, that we’ve done integrations. Some successful, some not, some technically successful but revenue-wise, they weren’t that great and then others that were pretty simple and easy-to-build that wound up having a big impact on revenue. Yeah, a lot of learning and some do’s and don’ts along the way.
Mike: Before we dive in, what I want to do is provide a definition of this so that we’re working from the same page here. I’ve loosely defined integration as, it’s a part of your business where there’s something that’s handled internally and is reliant upon a third-party. Essentially, it’s outside of your direct control and there’s varying degrees of visibility and influence that you have over whatever the processing is or procedure or how it works. Some of the examples of those are things like code libraries or third-party APIs. Baremetrics, for example, is heavily reliant upon Stripe’s APIs. If those Stripe APIs went away, the business goes away.
I think a lot of discussions we’ve had in years passed about integrating with Twitter is they decided on a whim to go a route and either change the process of who is authorized to interact with their APIs or who has them available or even what you can do with them. Obviously, all these large companies like Google, and Facebook, Twitter, they all have varying things that they want to do in the future and those may directly conflict with you as an entrepreneur. These are areas of risks. Those are the types of things that you want to keep in mind when you want to integrate with somebody or something outside of your company. That could be software integrations, it could be business processes, it could even be a joint venture that you’re doing with somebody.
But I think the focus today is going to be more on the technical side of things but also taking into account the inter-business relationships as well because you have to know that the person you’re working with or the business entity on the other side isn’t going to totally screw you and if they do or if they could, what ways might those be. It’s really just providing some visibility to those areas of risk.
Rob: Right. Building your app on someone else’s platform where if they turned off the knob, you would lose 50%-80% of your revenue overnight, that’s one thing, and that’s platform risk. You can de-risk it by going to multiple platforms, sometimes you don’t need to de-risk it. It does impact sales multiples, if you ever try to sell a SaaS app that is entirely reliant on a platform and you don’t have an official contract, it’s a risk, so it requires to look at it and factor it in.
We’re not going to dive into all of that today. This is more about building individual integrations. You’d think about Drip that has all these incoming stuff from Stripe and from Shopify and from Event Pride, any one of those going away would have been a bummer because people want it and used it but it would not have been business-ending. That’s really more of the integrations we’re talking about today. We’re talking about both the process, the dev side of building it, the business development side of, how can you leverage that to get more customers and leads and we could touch on like deployment support and that kind of stuff.
Mike: As you’ve said, the best case scenario is really, if something goes away maybe you’ve lost some time or money and that’s about it but the worst case is everything that you’ve built is effectively gone and that kind of leads towards building on somebody else’s platform and you just have to evaluate that as a risk. We’re going to start through this list.
The first one is what level of effort is going to take to build something. I’ll […] up this by saying that I think in most cases, your estimate to build an integration are going to be too low by a lot. That will change over time as you get more familiar with building integrations and you create more infrastructure in your own application in order to build those things but what I’ve found is that there’s a few different places where I thought things were going to be in a certain way and it turns out that they weren’t.
For example, documentation is an area where when you’re trying to build a third-party integration or integrating to something else, I found documentation tends to be lacking, even if the documentation is there and it seems to be extensive, what I’ve found is that a lot of times that documentation is inaccurate and it’s because companies don’t keep their documentation up to date. There are places where it will say one thing and is absolutely not true or it documents in a certain way and it says, “Hey, this is how it works.” When you go start implementing it, it turns out it doesn’t actually work that way. These things sound like they shouldn’t be that big of a deal but in some cases, they really are. If you designed everything in a certain way, those things really throw a wrench into your plans.
Rob: Yeah. There’s an interesting X factor or a variable that is outside of your control that gets thrown in when you’re dealing with someone else’s API. It could be bugginess or it could be docs that are out of date. There’s a bunch of different things. It’s different when you’re just building your own app. You know there are going to be things that you can’t control in terms of, “Oh, I run into this problem. I couldn’t solve it quick enough. There’s a bug I couldn’t find for two hours,” or whatever, but external APIs can be one of the most frustrating things to develop against.
Here’s the thing, we got to the point with Drip since we’ve built so many of them, we basically almost by looking at documentation and whether we knew the founders or not, whether it’s a big company or a small company, we could gauge like, “Oh, this is Fortune 500 integration and they’re using SOAP. This is going to take a week to build,” versus, “Oh, it’s a REST API written by some […] developers that we know. We can probably literally build what we need in four hours.” I mean there were integrations we would get done in half a day. It’s because we have a whole repeatable system and a bunch of code on our side to help do that copy/paste and polymorphism and that kind of stuff but we would ballpark engage, “Yeah, I think this one is going to be a lot worse.” It’s like all APIs are certainly not created equal.
Mike: Another thing I’ve run into is there’s time that you’re going to have to do some sort of black box testing to figure out how things really work especially when you’re going up against external resources or external APIs that are providing data for you. Interesting thing I ran into was there was a code library I was using that says, “Oh, if you pull this information back, you get a list of strings over here and you get a list of integers over there and they represent the same thing.” Early on, I was trying to work with those and pull the data back and one of them took five seconds and the other one took 60 but it’s supposed to be identical data. The numbers, the integers should have been a lot faster and they weren’t. I ended up using just the strings, that worked fine.
Recently, I’ve gone back, and I’ve been doing some more test performance on that section of things and came back and said, “Why is this taking so long? It shouldn’t take that long.” I found some access to some additional logging capabilities and I printed it out and it turns out they’re actually returning not just those numbers but also a set of dates. I was like, “Wait a second. Why is this requesting dates?” It’s not even actually requesting one of the information I asked for, it’s requesting this other thing, and then just interpreting it and throwing those integers in there. It actually doesn’t even work. Like, “Wow, that’s just painfully wrong.”
Rob: That’s amazing.
Mike: Yeah. It works but only because of some other thing that happens to be going on. It’s issuing the wrong command to the server but those are the types of things that you’re going to run into and you won’t, since you don’t have the visibility into those things, you can’t troubleshoot somebody else’s code or somebody else’s server. It makes it difficult to find those things and it just takes longer. You have to do timing performance, benchmarks, and see how much memory allocation needs to be done for different things. You may not be able to do everything all in one shot. Those are the types of things that—it just takes longer, makes the process of implementing especially the early integrations that you do, just makes it take that much longer.
Rob: Here’s something I’ll say on how to streamline this. If you’re only going to build a few, then just do what you’re going to do and go straightforward. There are reasons to do this: a, it makes your product more sticky because you can get data from more places and therefore users get more value out of it; b, it makes your customers lives easier; and c, it can be a co-promotion opportunity. Off the top of my head, those are the top three reasons to do it.
If you’re going to build a bunch of them, then you’re going to want to standardize on the code side and like I said, develop something where it’s easy to just pop them in, you don’t have to build custom UI for each one. I mean, again, look at the Drip UI and we just pop an item in the dropdown list to add the next trigger or action that’s triggering something in Drip or sending out an action, something that goes out of Drip.
The other thing to think about is or the way we were doing it was, if I recall, we have three levels. We had a V1, V2, V3 of any integration that we did almost without fail where we would build a very simple integration first, and that was our V1, and that would typically take less than a day to build. Sometimes, it only had one or two triggers, one or two actions, something like that. It was easy to build, we’ve got two, three API, we’d push it live, we’d promote it, we’d see who used it, we’d see the request.
The best-case scenario is that we’ve got a bunch of people saying, “Oh, this is cool except for it doesn’t do this for me.” It’s almost like customer development where we’re iterating on the feature, almost like it was its own product because Drip had—off the top of my head—I’m going to say 20 different triggers and Stripe has 20 or 30 different actions. Well, there is no reason to build essentially 50 endpoints, 20 in and 30 out. Again, don’t quote me on those exact numbers but you get the idea of what I’m saying. There’s a lot. It’s a lot of work, it’s a lot of code to do.
If you build two in, two out, pretty simple, you throw it live and then as people ask for stuff, you can add another one in almost minutes. I mean, you have to write unit test and stuff but it’s very trivial to add. If you get enough people asking about it, well, you take it to that next level where it’s a tighter integration, you can add OAuth later. At first you can paste an API key which is a little janky but then OAuth becomes the V2, and you just build tighter and invest more in that, the more people who use it. That was how we did it and it seemed to work out pretty well in general.
Having the ability to watch the actual user behavior on your integrations before investing weeks of time is hugely valuable because it can save you a lot of time. There were integrations that we built, that V1, and 20 people used it out of thousands of customers, and we never did OAuth and we never added that extra week or two of development on it because there was no business case to do.
Mike: What I like about the strategy you just outlined—doing the V1 and then V2 and then V3—is that it allows you to come back and start very simple. Then as you start to see the technical problems with it, but also the features and functionality they’re missing, that customers are asking for, it allows you to fill them in afterwards. You don’t have to worry about as much about going back and rewriting some of those things that you’ve already built in order to satisfy what the customers need because you didn’t build very much to begin with. You did it really more or less to help pull that information out of the customers and find out what it is that they wanted and then take that forward.
That’s actually a mistake that I’ve probably made early on with integrating with Zapier is that I put too many things in there, but it was partly because customers were asking me to do a lot. I don’t what to answer how I would change that, but I think that I would probably spend a little bit more time on going back and verifying with Zapier directly like how this should have been done.
Rob: Yeah, it’s easy to over build. You get in there and you think they need to be able to do everything that they can do through the Bluetick UI or everything that the API offers, they need to be able to do that in Zapier. I would say that’s not true for a V1. You may miss something, but take your best guess, 80/20 it. What are the 2 out of 10 things that you think or you know people are using or your gut feel of what you think they’ll use which is sometimes you just don’t have the data and then pop it in. When they’re like, “Oh, I also want to do XYZ.” Well then you put that in your queue, and you build it out as soon as you can.
Integrations are—they’re a curious thing because I remember with HitTail, we skipped this with Drip too, but it was like, “Do you integrate with Shopify?” It’s like, “What do you mean by that? What does an integration mean in your head? Does that mean that we’re taking data in from them and we’re triggering things? Does that mean you want us to pull data and display it as a report? Does that mean you want us to push things into your Shopify store?”
Same as Stripe, “Do you integrate with Stripe?” It’s like, “Yeah, we do but what do you need it to do?” It was often digging in questions and then they would have a use case typically. It’s like, “Well, I want once someone purchase, I want to be able to mark them as a customer and drip.” It’s like, “Well, yeah, of course. We do that.” Or, “Once an invoice is created on the second Tuesday of every month, I want this and that to happen.” It’s like, “Oh, we don’t handle that use case, but we can build that.”
Saying integrating with Basecamp or Highrise or with Slack, that can mean a whole slew of things. Integrating with Slack can literally be, “Oh, I’ll just dump a message in there when someone says something.” It’s an integration but it might not be what everyone has in mind. You often want to dig in if people are asking for these things and find out really what is your exact use case and then just build those one at a time but build it in a framework such that it’s easy to add other functions.
Mike: Yeah. The question that I’ve kind of usually responded to for those types of request is, “What is it that you’re trying to do?” Because usually, that’ll entice people enough to give you the information that you need to either extrapolate it or what you need to build or what sorts of things they’re trying to do and whether it’s even remotely possible. If it is, then you can dig in a little bit more with the technical stuff but usually, at a high-level, it gives you enough information to say, “Yes, this conversation is even worth pursuing or it isn’t.”
Rob: Right.
Mike: Next step we’re going to dig into is the actual API integration itself whether you’re calling an external API or they’re trying to call back to yours from an external application. What I found is that, because there’s so many different ways to design an API, it’s probably not going to be likely that your API is going to be able to be used directly by the other application. This applies whether it’s having to respond to webhooks or accepting them or tracking them or just make external function calls.
If you have an external application that’s calling into yours, they already have a standard way of doing it. You may need to change how your product works. If you’ve already built an API, it may not be the easiest thing in the world to change your API especially if you have other customers interacting with it or your application depends on it. Bluetick for example is a single-page application and it’s got an API specifically for the app itself, it’s also got a public API and then I have additional endpoints that I’ve created.
This is one of the, I’ll say, hacks that I’ve learned is that creating your own dedicated endpoints for other apps could be in your best interest to do. It sucks to have to maintain them in addition to the other code that you have, but it may be the best way to go about providing a mechanism for them to talk to your app without having to rewrite all the different things in your app. Even if you would have just two of them that need to call into your application, they may be doing things differently between each other and then your application may be doing something else as well which makes it hard. You can’t standardize on one thing that’s different for three different people. A dedicated endpoint for each of them is a good way around that. I won’t say the best way, but it is a way that is workable.
Rob: Another thing to think about is rate limiting. I think I’ve talked a little bit about how segment, well, there are few people, segment was the most notorious for it a couple of years ago, but they would accidentally DDoS us. Someone would activate something, and it would just hammer your API and we had rate limiting in place. We had a Ruby Gem that basically sent back, I believe it’s a 304 response, 403, there’s some response where you encode. It’s like, you’ve been rate limited, you can send this much per hour, and wait this long before you can send your next batch and they just weren’t honoring that. There were several that weren’t honoring so you have to code the work around those. I know that Zapier has rate limits and we coded early on to help with those.
It’s one of those things that in the early days doesn’t matter and as you scale, it matters a lot because it’ll either take your API down, it could take your app down, your database down, it can take web servers down, or it can mean, if you’re not queuing things and you’re hitting and you’re getting rate limited, you could lose customer data. If you are queuing them, it could back your queues up because you have all this retrial logic. If a failure happens, it’ll just fill your queues up and say you have to expect rate limits and it’s a bunch of code, it solve problem logically but it can require a lot of code on your end to properly implement rate limiting.
Mike: Another thing that’s similar to that which is parallel request. You may end up with request that are coming in on your API that are close enough to each other where if that resource doesn’t exist, for example, then it needs to be created. If you don’t have your transactions set up properly in your code, then you can end up with duplicate resources created inside your app and then suddenly, things start to fall over because it’s basically what amounts to a raise condition, which you never would’ve run into in normal interactions with your app because users aren’t clicking on things with milliseconds between each request. If that happens to your app, if it’s coming to an external API, that can easily happen. You do have to be careful and cautious about those types of things which some frameworks are good about transactions and some are not so much.
Another thing to think about when you’re looking to integrate with an external API is what customers are using that and what visibility do you have for the other side of things. If you’re receiving commands or queries from another system, can you log into that system and see what has been initiated, can you see what has been satisfied, can you see the errors that we’re running to? Because a lot of those things, you may not necessarily have the information on your own servers like there could be requests that’s going out. You may see the request come in, but you don’t necessarily know if it was responded to properly or it’s sending back the wrong data.
If your code is incorrect or it’s not responding properly, how would you know that? The only way to know that is to go to the other side and look from there. Being able to monitor things both internally and externally is important. You don’t always get that external viewpoint that you need, and you may not be able to track them down to particular customers either. If you see an incoming request not just, why did it come in, and where did it come from, who is the vendor, but what customer of yours is that request associated with. If you can’t see those things, it makes it difficult to troubleshoot, it makes it difficult for you to offer support for your own customers.
Rob: Another think to think about is when you are building the integration, who can you contact for support. Is the documentation—we’ve already covered a little bit—is it good, is it buggy, is it correct or not? Do you have email access, phone access to a developer on there? Because you’re going to run into problems, and do you have access to a developer? Do you just email their general support that they have specific integration support?
We love integrating with the three-person startup where two of the founders were developers. I mean, those went so smoothly, they could fix things so quickly, and they knew how everything worked. You’d email them and be like, “Hey, there’s a problem here. This is the result we’re getting.” And they’re like, “Fixed.” It was so good. The larger the teams get and if you’re sending an email again, to Salesforce, to their support, to try to get integration, it’s an absolute nightmare. You hear back a week later, and they don’t understand your question at all, and they don’t escalate you, blah, blah, blah. Those are kind of the two extremes that I’d point out but it’s something to think about when building this.
Mike: The last one, typically comes around when there are webhooks of like, “How do you go about testing them?” This also applies to just you sending information over but how do you go about making sure that the stuff you’re developing has a test area on the other side? Are you working with production data? I would hope not but there are cases where you are going to have to do that which means that you have to create an account on their side and use that to do all of your testing and effectively it’s in production but on your side it’s not. That makes it hard because you have to keep things straight locally like, “Oh, is this information here that we’re working with in production or not on their side?” You may have internal flags or toggles or fields that you use to keep track of that stuff, but it can get complicated especially if you’re trying to document that. It’s got to be documented in places where it’s easily accessible by you to understand what’s going on both side and which environment it’s going on.
Rob: And then, as you get it built, there’s going to be an approval in publication process and again, with smaller startups there’s typically not much of a process. You send an email, you say, “Hey, this is live. We’re going to push this live in our UI next Tuesday.” They’re like, “Cool.” With Zapier or Salesforce or someone who’s doing a lot of integrations or having a lot of people integrate with them, they are going to have a process, they’re going to have a checklist of requirements. You’re going to want to look at approval timelines because I know some apps take weeks and/or months to get approval publication timeline after it’s approved.
Is there a beta period? This is something that Zapier I think does well. It feels like a pain when you’re doing it, or it feels like hoops to jump through but they’re doing it because they want to keep the quality of the service side. If they don’t have the beta period and all that where you have to get 10 users using it because they want to force you to work out the bugs basically. I think they do a good job of that. Then how will you get support during beta? How will you provide support to your folks during beta? It’s all things to think about to get it live. Oftentimes, writing the code is the least time intensive piece of this whole process.
Mike: Yeah. I think the piece of this process that does take the most time is just making sure that there is that trust factor there on both sides that, “Hey, this is going to work and is generally going to be good for everyone who’s using it but if it’s not working or it’s buggy or there’s problems of any kind where there’s transaction delays or things are just overly slow or they’re using too much memory or there’s scaling issues on either side, all of those things can essentially erode the credibility of the integration.
At that point, one side of the other is going to want to back things off a little bit and introduces this additional delay. Delay factored just from becoming comfortable with it is important, but you also need to have ways to resolve that. This begs the question of, “How are discrepancies or disputes handled” Those disputes or discrepancies can be like, “We expected this data, we got this data instead.” Or it could be something along the lines of, “This isn’t working right. Why is it taking so long?” Or it maybe it could be a designer or an architectural issue, “Oh, you said that you want to send us data XY and Z but it’s also including this other thing. Why is it doing that? I don’t think that it should.” You have to have someone resolve that.
Sometimes, you’re talking directly to developers. Sometimes, you’re talking to an anonymous email box where you have no idea who’s answering it or what their ability to make change is or even knowledge of the entire system is. Each of those is going to be a different approach but they’re things that you have to be aware of especially when you’re working with larger companies or smaller ones.
Rob: Then something we’ve alluded to several times during the episode is I mentioned there my top three reasons for building integrations and one of them is the comarketing opportunity, the business development so to speak, which is to be able to both promote who you’re integrating with and for them to promote you in one way or another. There are a lot of ways to do this such as joint webinar is a pretty good way. You think about it, if you’re integrating with another startup, you both want the exposure to each other’s audience. If you’re integrating with Stripe or Facebook or Google or whoever, you’re not going to get that, but it’s nice to think about high-touch opportunity to show how the integrating works and the benefit it provides—so joint webinar is one.
Certainly, I found a lot of success with the joint email. We email our list, you email yours. Copromote blog posts also on both announcement blogs for each company. There are the functionality updates whether they handle that via email or in-app or whatever. You can offer in-app announcement on both. Even providing customized landing page that says, “Welcome, Pipedrive users. Welcome, Stripe users.” That they can link to from the other place that you can get is in their app directory, their integrations directory. There’s typically one in the app and out on their public market website. That’s another place you want to be.
From there, we found that building custom landing page for some of them, but not all, worked really well and increased conversions quite a bit. There were a couple of integrations where the clickthrough from the in-app or from their integrations directory on the marketing site to our landing page and then sign-up for a trial was something like 30%. It was outrageously high. We asked for credit card upfront. Typically, the number is very small, and it was 20%-30% and it was shocking. We did so much to tune that page and split test it but the ones where we were getting 3% or 4%, you obviously don’t care as much about those.
But those comarketing opportunities can be fascinating because if you get a big email sent out to 30,000 of their marketing list or customer list or whatever, you can get a nice bump there. But then if you get in their app directory or you get in these other longer, living links basically, you not only get the SEO juice from that, but you then get that flywheel of traffic. I’s not huge, again, maybe it’s 100 visitors a month, so it’s not a huge amount but if you’re getting 10%, 20%, 30% of those to sign-up for a trial, that’s 10, 20, 30 trials every month that shows up. Then you multiply that by 10, 20, 30 integrations and you start to see how you can potentially build a flywheel out of this.
Again, you can’t just take this advice and apply it to your app without thinking, “Does this make sense? Is it going to provide the value? Do I have the leverage for these folks to do all of this?” That is the integration marketing playbook that can help grow your business not only as a one-time thing but as a sustainable approach. With that, I think we’re wrapped up for the day.
If you have a question for us, call our voicemail number 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt. It’s used under Creative Commons. Subscribe to us on iTunes by searching for Startups and visit startupsfortherestofus.com for full transcript of each episode. Thanks for listening. We’ll see you next time.
Episode 445 | Why Absolute Thinking Is ALWAYS Bad
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about some of the pitfalls of absolute thinking. Things are rarely black and white, they are more nuanced and on a spectrum. The guys explore the advantages to this approach.
Items mentioned in this episode:
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.
Mike: And I’m Mike.
Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. Did you catch the joke? The sarcasm in the title there?
Mike: Just a little. Is it always though? Is it always bad?
Rob: Always bad. We’re going to dive into always and never, absolute, thinking in this episode. But before we do that, what’s the word this week, sir?
Mike: I’m still going through hell that is the Google authentication approval process. I feel like it’s on of those ongoing sagas, kind of like Game of Thrones right now, where like the last episode’s coming up and you’re just like, “Ugh, just let it end.” It’s going to take a little while. They sent me an email. I asked them for more information. They said, “We signed up.” This is me going on a rant here. But they signed up for Bluetick apparently and then they ran into the credit card screen, and then they email me saying, “We need you to make our account so that we can log into your application and bypass the payment information.” I’m just thinking to myself, I’m like, “You’re Google. I imagine that somewhere, there’s a credit card that you could put it in for the 14-day trial.” I would just imagined it that would be the case some place.
Of course, I email them. It was a week later, still nothing from them. I was just like, “I need an email address. What email address did you signed up with?” I didn’t hear a word from them and then they’re like, “You have five days to comply.” I’m like, “Come on!”
Rob: Oh, boy.
Mike: This coming Monday is when they’re like, “You have five days to comply. These are the steps that we’re going through. We’re going to start notifying people, your users that are connected.” I’m like, “Come on!” It’s just ridiculous. I don’t know how that all is going to turnout over the next couple of weeks. It’s just frustrating and irritating.
Of course, at the bottom of it, it’s one of those worst case scenarios where they’re going to detail about, “You’re not going to be able to add any new users using Google Gmail accounts.” I’m like, “Come on!” Basically, they’re taking aim and saying, “Well, if you don’t do this, we’re going to tank your business” Like, “Thanks.”
Rob: It’s a little bit like dealing with the state government or the federal government.
Mike: Only with them, you can just pay a fine or penalty or late fee or something like that. They’re threatening to shut things off. I’m just like, “This just sucks!”
Rob: Would you say, never build on top of Google, Mike? […] for the next episode, never trust Google. It’s not never but know what you’re getting into. Is that it?
Mike: I think what it would boil down to is that if a company removes, don’t be evil from their company motto. It is probably not wise to rely on them not being evil.
Rob: Right. You might say, “I will never build on Google again.” Or, “Know the pros and cons of basically building a business that relies on them.” That’s tough. It’s a similar thing that I’ve dealt with with setting up payroll in multiple states where you like Gusto, I guess, Zenefits, and there’s a few others that like it appears that it makes it just magical like, “Get payroll running. It’s no problem.” Then you have to sign up for at least two janky online web accounts that were built in 1997 with state governments to get the revenue, Office of the Revenue of the state, and then, it’s like the unemployment stuff so that it can pay into this. Then, you have to give Gusto access. That never works the first four times.
It’s not threatening to tank a business but it is something that adds a bunch of back and forth, that’s frustrating, that you can’t actually get it done, that you really can’t outsource to someone. That was the thing that I always struggled with. You almost need a chief operating officer or an office manager who’s really going to dig in and do it but it’s kind of something you just have to deal with. It’s just a headache that wastes time and it’s not the fun part—one of the many not fun parts—of running a business.
Mike: Yeah. The other thing is how opaque the whole process is. It’s Google. They’re kind of like Facebook or Apple. You have no way to talk to a real person. I guess with Apple, it’s a little different, you could go to the Apple store. Even then, if you need to talk to somebody, an engineer or something like that, I’ve only heard of one situation where somebody was able to get an Apple engineer who was in the design engineering office in Apple. It was because something literally caught on fire, with some charging cable or something like that. It was like the second or third time that it happened. They’re like, “I want to talk to that person.” That’s the only one that I have ever heard of. Just getting somebody to talk to, to say, “How is this supposed to actually work? What’s the next step? How do I talk to somebody about getting either a waiver or something like that or an extension?” Nothing, there’s no information, and they’re not forthcoming with it. Anyway, I will leave it at that. How about you?
Rob: Yeah. We can stop. Google Rants for the Rest of Us. I wanted to give a shoutout and a thank you to Rich Staats. He runs secretstache.com which is a WordPress agency. It’s spelled s-t-a-c-h-e like a mustache, secretstache.com. It’s a WordPress agency. You and I have met him at different Big Snow Tiny Conf. He comes to MicroConf as well. We were having some issues, to put it mildly, some minor issues with the Startups for the Rest of Us website because it’s on a, do we think a nine-year-old WordPress theme? Eight-year-old? Nine-year-old? It’s pretty ancient. It’s like 70 in human years.
Mike: Yeah.
Rob: It’s not like an eight-year-old WordPress theme. I think it’s nine years.
Mike: Yeah.
Rob: Anyways, he dove in. He helped us out, really appreciated it. Now, our comments appear. When people are making comments, we can see them in the admin, but they wouldn’t appear on the actual episode. As such, we have few comments that I haven’t read through over the past couple of months.
Episode 432, you and I talked about How to Indirectly Overcome Sales Objections and Matt made a comment. He said, “Great episode! I love the idea of using KB articles to overcome sales objections. I’m trying to figure out what knowledgebase I should use. It looks like they can get pretty pricey. Mike, I like the look of your KB at support.bluetick.io. Is that something you built yourself or are you somehow using a service for that?
Mike: I’m using Teamwork Desk for that. It’s just a redirect with my DNS. It just redirects support.bluetick.io over to that. It’s all completely hosted there. They’ve got stuff where it integrates into their desk products as well. If I’m answering a question or somebody has a problem and there’s a KB article on it, I can link directly to that KB article from within Teamwork Desk. Works quite well. You can have multiple mailboxes setup, it’s charged per user. I found it to work pretty well so far. That’s what I use.
I think there’s a lot of other ones that do something similar where they will have a KB article hosted for you or a set of KB articles. But that was one that I found that was simple and easy to get into. It just kind of worked and met my needs for the time being.
Rob: It makes a lot of sense. When you’re small, you have a support system—email support—where you’re already using it. I would say Teamwork Desk or Help Scout would be my two top recommendations for that. Both of them have built in KBS. It’s probably a little bit of extra money per month. I don’t even know, but that’s a totally viable option if you want it hosted.
What we did at Drip, and it worked out fine. I don’t know at this point that I would do it again. I was trying to be budget conscious and I don’t want to pay a bunch of money at that time. We had a WordPress install, it was on WP Engine, and we used the KnowHow theme and customized it a little bit to look like we have Drip colors. It worked great for us. It was essentially free because I already was paying for this WP Engine account. That’s another option. Of course then, you have all the maintenance and all that stuff that goes along with WordPress. It just feels like it gets worse and worse overtime. Those are some two relatively inexpensive options depending on how you want to go.
Mike: Yeah. I went with Teamwork Desk mainly because it also offered—I forgot what they call them—but it’s basically a part time account as well for free. If you have somebody who needs to log into the ticketing system and they only need to see tickets once in a while or you only need them to have answer once in a while then, the part time agents basically takeover. They can answer, I think, up to 10 for free. Then, your regular users, I think, I’m still only paying $8 or $10 a month or something like that. It’s really cheap for what I’m using.
I didn’t need very much either. It’s not like I needed higher end stuff where I need to have advance workflows. I didn’t really care about sending out satisfactions surveys to people because it’s not like I was getting a larger number of tickets. I’m still not. It’s not like I need to move off it. It’s a great place to start though.
Rob: Indeed. We have another comment. It was episode 433 where we answered several listener questions. In that episode, we talked about VidHug which is a B2C service that, if I recall, was doing around 500 or 600 a month MRR. You could send out a link. It was kind of B2C. Let’s say it was your grandma’s birthday and you could send all the links out to all the relatives. They could record something on their iPhone and it was stitched together a happy birthday video. That was the concept.
Tyler made a comment. He said, “Hey, Rob and Mike. Don’t if they’d be interested, but VidHug sounds like a great idea for small businesses looking for testimonials. They can invite their customers to leave testimonials then the company can use those videos for Facebook ads as social proof. That could be a B2B opportunity with recurring revenue. Was wondering if you could pass that along because I would pay for that now. Just a thought I had while listening. Keep up the great work! Thanks, guys!”
I thought that was kind of clever. Probably a better use because I think the VidHug founder had asked about switching to B2B and going after HR and having them do welcome videos and stuff. I almost like this better because it’s an easier sales process than going after HR departments.
Mike: Yeah. The only downside, I would say, that I see there is if you’re going after testimonials, how many testimonials do people go after in a particular year? You’re not going to constantly be doing that. It almost feels like there’s a—I don’t want to say it’s a one time fee, but it’s like a fee for a three-month period or something like that. You’re using it and it’s used during that time period and then after that, you’re probably not going to use it again for another six months or year or something like that. The pricing might be an issue. How you price it might be an issue. But if you don’t care that it’s recurring then it doesn’t matter. If you’re just going after customers to get them as customers and try to establish revenue, then it doesn’t matter.
Rob: Yup. I would agree with that. You could do a three-month or you can do an annual and just make it annual-only pricing or something.
Last comment for the day before we dive in. Episode 434, SaaS KPIs You Should Focus on From Day 1. Oh, this is a comment relating to when you sent out, I believe it was this scholarship applications, and you forgot the email. You forgot to put the email in the form and you had something like 70 of them or something that you had to go through. Anna says, “Lol! I totally noticed that you didn’t have an email field in the MicroConf application. I just figured that we were living in a post-email world and you’d DM everyone on Twitter. That did make me feel like I was way too old though and that MicroConf was going to be too hip for me, so I’m glad to hear that it was an accident!” We’re not in a post-email world. […] of getting there, so I thought that was funny.
Mike: It’s funny because I was still able to track down pretty much everybody on there. I don’t think there was anyone I couldn’t trackdown or wasn’t able to eventually get an email address for. Yeah, I’m shocked. I had enough information to be able to track people down, but it was still time consuming. It’s not a post-email world, but I guess given enough time, you could make it a post-email world but you’d have to have enough information too.
Rob: Right. Cool. Let’s dive in. Today as I said, the title’s a bit of a joke, Why Absolute Thinking is Always Bad. The alternate title is Why Absolute Thinking Can be Toxic to you, your business, and other people who are kind of listening to you. I think, if you’re wondering what absolute thinking is, it’s that very black and white view of things. Examples of that are, if you see someone say, “This always works. You should always do this.” Always is the key. “This never works. You should never do this.” Often times, it’s like, “I should do this.” Maybe that’s an absolute feeling but it’s kind of like an assumption or a burden you’re putting on yourself.
The reason I want to talk about this today, because we were talking about it before recording, and you were like, “What’s the point of pointing out that something as bad?” It’s because I believe that successful founders, and frankly, successful humans, that I like to have conversations with, stay away from absolute thinking and see the nuance in complex things instead of trying to break them down to black or white or zero to ones. I believe the entire startup community itself will be better off if there’s just less of this. If there are fewer of us that believe that there are these absolute, “You should always never do this.” We have examples later on, on this episode of actual examples that I’ve heard over the years, frankly.
I believe it’s a fallacy. It’s thinking that it isn’t true. It’s more than semantics. It’s not digging in. When someone says, “Always,” and they mean 95% of the time, that’s a very different thing. There are exceptions to most of these things. There are times when absolute thinking is useful with ethics and in genocide. There are things when, “Yes, this is always bad.” That’s why the title is a joke. I think we’re going to give some specific examples of marketing approaches and that kind of stuff that I think will lend a little more detail to what we’re thinking about here.
Mike: This almost goes back a little bit to what I kind of opened up MicroConf with this year which is the fact that the matter is, when we go to MicroConf, and we’re talking to all these other founders, that we’re essentially raising the bar for every single person there just because we’re learning from each other. I definitely think this is one of those things where we can learn a lot from it.
I do want to dig a little bit to the piece that you said on, if somebody says, “Always do this.” What they really mean is 95% of the time. How do you differentiate between what they meant to say versus what they actually said? A lot of time, I see a lot of these stuff come up on Twitter, for example, or in places where there’s not a lot of room to expound upon what the person actually meant. Then, there will be people who’ll jumpin in the comments and just rip them apart and say, “That’s not always true.” Or, “Well, actually this and that” How do you differentiate between that? Is it just you have to rely on your own personal knowledge of that? Because if you don’t know anything about it, how would you know it’s 95% versus 50%?
Rob: Yeah. That’s the problem. That’s why words matter. If you say ‘almost’ without exception, or ‘in almost all cases’, or ‘nine times out of ten’, that tends to be how we talk in the podcast. That tends to be how Jason Fried talks now. He didn’t used to be. He used to be more absolute but something I like about his Q & A this year at MicroConf is that he wasn’t nearly as black and white on things as I thinks he was 10 years ago. When I hear Jason Cohen talk, I don’t know that I’ve heard him say ‘always’ or ‘never’. It’s very much same way we think and talk about things where it’s like, “Yeah, in some cases, this and that but as a general rule,” blah blah blah. “As a rule of thumb, I will always…” We already talked about that. You will probably never write another app that relies on Google but you wouldn’t say never do that. You’re not going to tell everyone else they shouldn’t do that because there are pros and cons to it.
That’s where I think it is, the words that matter, language does matter. I think, that’s something we’ve seen over the past 20 years of a lot of language being adopted and people not saying, “Hey, you guys,” anymore when it’s a group of men and women because words matter. That’s what I’m saying here. I think saying ‘always’ and ‘never’ especially if you all caps it on Twitter to make a point, I think that’s detrimental to the folks who don’t know the difference like you’re saying. I also think it can veer the conversation off in a direction that just doesn’t matter. Let’s not debate if it’s the last 5% or the last 1% or whatever. It’s just being careful about how you say things and how you think about things. I think that’s the important part.
Mike: Yeah. I agree with you. The conversation can easily go off into the weeds just because somebody said always and what they really meant was 95% of the time. I think that in most cases, a simple correction but Twitter is also not known for making it easy to go back and edit those things, and provide a correction in a way that makes it visible to everyone who’s going to see it. It just extends the conversation. Rather than continue going off into the weeds, let’s circle us back a little and talk a little bit about the nuances of that.
Rob: What I would say is just be more careful with your first post. Be very thoughtful when you’re going to write and publish a blogpost or say that tweet or whatever. I, very intentionally, try to avoid absolute language and I have for years. Again, the folks who I admire, the folks who I see who are successful, in general, they always do that. No, they don’t always do that but in general, that’s the behavior I see as well.
Coming back to nuance, most of the topics that we’re going to talk about is in the startup space, in the bootstrap space, or in the whole startup ecosystem world of tens and thousands, hundred of thousands of companies, there’s nuance to these things. It tends to be much more a spectrum or a continuum of 1-100 maybe instead of this 0-1 binary thinking.
I remember getting in a conversation, I believe it was on Hacker News, I don’t even remember. But someone posted, “You should never outsource the development of your SaaS product. Never. Never.” I mean, that’s okay advice. It was like, “If you don’t build it, you have zero chance of it working.” That’s just patently not true. It’s not even a 5% exception. I would say that there’s a bunch of stuff that can add up from 1-100. If you’re going to be a solo SaaS founder, let’s say, if you have any of these skills, it will mean you have a higher chance of success. One of those is the development […] is the ability to build your own product. The other one is the ability to manage and hire people. Another one is the ability to market. Another one is the ability to think about the product and build good UX. On and on and on.
If I recall, in that Hacker News article, I made a list of 10 things. I said, “Just weight each of them as a 10 if you have them or 9.9 because you never get to 100.” If you have all 10 of those then you’re at 99 out of 100, you just have the huge chance of success. But most of us don’t, most of us none of us have, all 10 of the things that I threw out. That was a way of thinking about it where it’s like if I were to add it for myself, I have 70 out of 100. People I really respect have 80 out of 100 or whatever.
They have a better chance than others but that’s all it is, it’s a chance. You should always never do these things. It’s more like, “Let’s look at the factors and the list of pros and cons.” I realized, looking at pros and cons is complicated. It takes an advanced frontal lobe developed. That’s why kids often have a hard time doing this. It can be hard and it hurts your brain to think about it. I think that’s important because higher level thinking involves this nuance.
Mike: I wonder if that nuance also comes with time and experience too. The couple of things you had mentioned about these examples of somebody going on social media saying, “She should never outsource those core things.”
I remember there was a couple of articles from Joel Spolsky—I’m looking at them now. One of them is titled, Things You Should Never Do, Part 1. This is from April 6, 2000. He’s talking about basically rewriting an entire application from scratch. It kind of goes into the history of Netscape. The next one is from October 14th of 2001 which is, In Defense of Not-Invented-Here Syndrome. He says, “The best advice I can offer: If it’s a core business function — do it yourself, no matter what.” Both of those things are incredibly absolute. He’s essentially saying, “Never ever do these things.”
I think if you start reading beyond the statements and looking into the context of what he’s providing and all the things around it, you’ll see the rationale. You’ll see the reason why he’s saying that. I think that that context is important for the statement, not necessarily just the statement itself. You’ve got to stake that context into account along with the statement. Staking the statement alone is essentially taking it out of that context. It’s very easy to manipulate it and twist it to say something that he didn’t quite mean. He said it, he didn’t mean that though.
Rob: Yeah. That’s a good point. I bet if you ask Joel today, in 19 years later, I bet he would see a little more nuance in it, I would guess. I think that comes with experience. I think that comes with knowledge and wisdom, just doing more things, and maybe he wouldn’t. Mike, I bet you and I could go to our—you’re in my blogs or essays—right now and find some evidence of some absolute thinking. I bet it’s 10 years ago. I bet it was when I thought I knew everything. I hear my kids, or I hear kids in general, say these black and white things like, “I never get to do this.” Actually, you did that last week. It’s a way of them kind of being dramatic or trying to call attention or showing how really bad it is for them when it’s kind of not, when they’re exaggerating for effect. That kind of leads into this thing about frontal lobe development.
Sherry and I had this conversation where, if you watch a lot of kids movies, they’re very black and white, there’s a good person and a bad person. A protagonist and an antagonist. As you develop and you watch shows like Game of Thrones or Breaking Bad, there’s this really strong nuance. Obviously, I haven’t watched Game of Thrones or Breaking Bad with my 13-year-old, but I have watched shows that have more nuance like in the MCU, in Black Panther, the villain in the first movie, he wasn’t bad. Thanos is another one. He does want to kill half of the people but he has a pretty good reason for it and he believes it. He’s not just doing things to be evil, he actually believe he’s doing good when he does it. It takes development to learn that.
Sherry has talked about how the frontal lobe is your advanced thinking and it doesn’t fully develop until early 20s. I think women are few years ahead of men with that. But this is one of the reasons why you thought you knew everything when you were 16 and why I thought I knew everything when I was 18 or when I was in high school. As you get older, if you get experience and you get knowledge outside of your little box, you don’t live in your little box but you travel and you meet other people with your thoughts. You’re allowed to be shaped. A lot of these happens in college. When you’re 18, you know everything. When you’re 28, you’ll realize you know less. When you’re 38, you’ll realize you know even less and so on.
Mike: Eventually, you get to be our age and you know nothing.
Rob: You know nothing.
Mike: You know nothing Rob Walling.
Rob: Yes. You know how little you know. That’s part of it.
Mike: I don’t want to say, but the way that this comes across is age is just in terms of people being younger. As you become more mature, you get older. You just naturally develop this. I think it’s a datapoint for you look in the mirror and say, “Is this type of thinking actually helpful for me or for other people?” The answer in general, I think, is no. But you have to be aware of it first. You just can’t just magically, you hit a certain age then suddenly you are aware of this. It’s something that develops over time through repeated experience and exposure. I think that’s what we’re trying to do here is, just expose people to the idea that those absolutes without the contexts are probably detrimental not just to you but to other people as well.
Rob: To your audience, that’s really the point. That’s right. It’s detrimental to you and the folks who you’re speaking to who don’t know better.
Mike: Right.
Rob: It’s not that. That’s something you pointed out over there. I am glad you called that out. My intent is not to say, “Oh, as you get older, you get out of absolute thinking.” That was one example of frontal lobe development. But I’ve known folks who were in their late teens who I felt like they had the life experience. They were 18 and they were as not absolute as I was when I was 38. You know what I mean, they were way ahead.
It’s not just some absolute scale of, “As you get older, you get better with this.” I do think it’s probably quite a bit of your upbringing. I was brought up for a black and white. It took me years to break free of that. I think if you’re brought up with more nuance and with parents who really talk things through in a non-absolute way. I think you’re ahead of the game. I think when you have life experience, you’ve traveled outside your home country, and you’ve met a lot of people with different viewpoints, and evaluated those, I think you’re ahead of the game. Again, I’ve know kids, 17, 18, 20, or whatever, who are way ahead of me and other folks that we might encounter on a day-to-day basis.
I think, piggybacking on the experience thing—I’m totally guilty of this, I was guilty of this—when I had my first success back in 2005, 2007, I was like, “Boom! I know it.” The first time entrepreneur typically thinks they have it all figured out. I did too. A few years later, you tend to realize that you didn’t. In research circles, they call it the N-of-1. N is how many subjects you have in an experiment or in a research study. An N of 10,000, meaning you’ve talked to 10,000 people or you researched them or whatever, that gets to be a pretty good number. It’s statistically significant. Depending on how everything varies, an N of 500 can be totally valid. An N-of-1 is a little bit of a joke. It’s basically an anecdote.
I say this because Sherry was a researcher for a while. She did a residency at Yale. There were a lot of researchers there and that was one of their jokes. It was, “Your anecdote is not my data.” Or the singular form of data is not anecdote.
Mike: That’s almost like when I see arguments of people, “Well, that didn’t happened to me,” and they’re arguing against data that they disagree with because of what their experience was. It doesn’t invalidate their experience but they feel like it does. But the data itself indicates something completely different. I can think of any number of things where that stuff has come up. One example that comes up specifically is Patrick Campbell of MicroConf had recently said and provided some data that said, “Companies that are remote first, I believe, are less successful or make less money.”
Rob: Grow slower.
Mike: Oh, that’s what it was. They grow slower than companies that are not which kind of flies in the face of a lot of kind of what we see. It’s not necessarily directly confrontational to it, but a lot of us don’t necessarily have the context of other companies either. I think that’s one of those dangerous things where you have a certain point of view and you believe it is correct but the data doesn’t necessarily prove or support that. You think that you’re right but you don’t necessarily have any data to prove that you’re right or wrong but you have that core belief. Because you’re growing a remote company, you don’t want to hear that growing a remote company is going to be slower or is going to slow down your growth.
Rob: Yeah. That’s a good example of that. Examples of it I talked about earlier, we looked at some specific things that I think I’ve heard people say over the past, let’s say 15 years of doing this. Common example is, they try a marketing approach, it doesn’t work and then saying, “This never works for anyone ever.” Or, “This can’t work with SaaS.” Or, “This can’t work with B2C.” It’s generalizing a single experience. Even if you try something two to three times, it doesn’t work, it’s not accurate to say it never works.
Paid acquisition is one that a lot of people try and give up on where we see a similar niche or the same vertical making it work. I think content marketing is another one or SEO. You can go on and on with success stories and failures stories. […] to say, “It never or always works.” It’s not helpful to say that.
I think another one I used to hear is never buy an app. You should build all your apps from scratch because the code will be too crappy, there’ll be too much risk, and too many problems. All those things are true that there is problems, and risks, and the code is crappy and all that stuff. But the absolute of always/never isn’t. There are just pros and cons and you have to look at them.
The, “Never hire contractors. Only hire W2 employees.” I think venture capital tends to lean towards that. I’m talking about building up a whole team. Let’s say I’m going to have a team of 20. Some folks might want to be a solopreneur and have 10 contractors or 20 contractors, for that matter. That can work. We see folks doing product-type of services and have it work but it’s a different model. There’s context to it. It’s like a venture capitalist says, “Your employees have to be loyal and your people are what make this company. If you’re going to build it into a $100 million venture-funded business then this is the model we see working and we’re pattern matching, and so they say do that. Similar to venture capitalists tend to want you to have an office versus having a remote team in general. That’s the pattern that they see working. It’s not an always/never thing.
Mike: I think that what’s make it difficult when you don’t necessarily have a lot of familiarity with that topic or that particular subject because you don’t have enough of your own context, so you’re relying on the words of somebody else. Kind of back to what you said, and we’ve reiterated it a couple of times, the words themselves matter. If you’re going to go down the road of trying to give advice or talk about a particular topic in whatever realm you’re doing it, it’s beneficial to most people to provide data points, provide context about what percentages of the time this is accurate. It’s not to say that you’re always going to be accurate.
I think I’ve just answered an email a couple of days ago from somebody asking about Bluetick and how it would integrate in with exchange server. I said, “I don’t know your environment, but the majority of the time,” I forget what percentage I said. It was like 80% or 90%. I was like, “80% or 90% of the time when I’ve see this, this is what it looks like. There are other cases when it looks like this or that. […] of my suspicions based on what you have said but I can’t be 100% accurate.” I distinctly remember saying, “I can’t be 100% accurate because I don’t know.” There’s always those little details that you’re not going to know.
I think it’s important to make sure that you quantify some of those details, so people would know where the dark areas are, so that they’d know where there might be more information or context that they may need to have to completely understand what it is you’re trying to say in the general sense as opposed to making things absolute.
Rob: I like to think of it like this. First, learn the rules. Then, master the rules. Then, learn when and how you should break the rules. When I say rules, I actually mean rules of thumb. A rule makes it sound like it’s an absolute, but rules of thumb that are generally accepted whether it’s common knowledge or whether you ask an expert and they have their own mental model of it. We pointed out Saas KPIs—that was a pretty popular episode a while back—those are just rule of thumbs that we’ve seen in over hundreds and hundreds of businesses.
First, learn those and then learn when they shouldn’t work. If you stop just learning the rules and then deciding you have all these rules and they’re always in ‘nevers’, you’ve stopped before mastery. It’s the same thing of like becoming a black belt in martial arts. Blackbelt is once you’ve learned the basics, then you start mastering it. Then, you become a 2nd, 3rd, 4th level. Black belt, it’s not the end, it’s really the beginning of knowing all the “rules of thumb” or all the tactics and techniques. From there, you then build on that.
Same thing with writing. You’ll see prolific successful writers. Whether it’s a Hemingway or a Stephen King or anyone in the middle, at some point they learn some rules. Then they master them. Then they learn how to break them. They did stuff differently and that’s what makes them great.
Picasso is another one. There’s a Picasso museum. I don’t remember if it’s the one in Barcelona or there’s one in Antibes in France where it shows him in his early years. He just sits and paint for a decade. He paints all the stuff that everyone else is doing. He starts of not good then he gets better and better and better. Eventually, he’s a really good painter. But he’s just one of many. He’s learned the rules and he’s master the rules. Then he started breaking the rules and everyone is like, “What the hell is this guy doing with these crazy paintings?” He invented cubism. That was mastery. He didn’t sit there and say, “A painting should always have this form and that form. This type of shape and that type of shape. He started trying to break those rules and seeing what happened. That’s how I feel about this––the absolute. These rules are helpful for giving us guardrails when you’re early on but at a certain point, you then learn. There’s nuance and pros and cons to them.
Mike: I do wonder whether you get to that certain point and how are you judged afterwards. If you’re trying to break those “rules”, is it because you’re trying to experiment to figure out something new and something that is completely and fundamentally different from everything else? Or you’re just a nutcase? But the results of that is kind of how you’re judged afterwards. He’d done that and created cubism. Nobody liked it or thought everything of it. We would not have ever heard about it right now.
I’m not saying that that’s bad and you should experiment. I’m just pointing out that, I think that is a natural evolution of what that process looks like. It may not turn into anything but that doesn’t mean you should experiment with it.
Rob: Right. That’s the thing. I think the bottomline is it’s important to form an opinion. It’s important that we’ll be able to discuss our opinions, be opened to being convinced otherwise by smart people who have different experiences, seeing the nuance and things. That’s the bottomline. Again, I come back to someone like the folks who I respect and who I see who are a, successful, and also, have good relationships with fellow humans whether it’s a spouse, or children, they have good family life, they have friends. They’re just people I want to be more like. Jason Cohen, Hiten Shah, we have dozens and dozens of folks that we know that do this. They are the folks who I see embodying this thinking, who learned the rules, that mastered the rules, and then learned when and where to break them. It’s very, very rare you’ll hear any of them say that, “It’s this hard and fast always/never.”
I really like Jason Cohen’s recent post on smartbear.com, it’s called Kung-fu. It was all about his rules; his rules of thumb. He said, “Look, everyone’s different. Your mileage may vary. But these are things that I’ve learned.” There were things like, it wasn’t, “Don’t do freemium.” It was, “I don’t like freemium. I’m not going to use it and here’s why.” I think that is super important to kind of couch something like that. It really comes back to flexibility and nuance.
Even a growth mindset versus a fixed mindset. I’ve talked about that book Mindset by Carol Dweck. Growth mindset believes you can and should change overtime. Even your opinions and some of your beliefs can be malleable. That’s helpful and leads to success in a lot of things.
Mike: I think overarching point here is just to educate yourself. Not just about the things you’re working on but about how other businesses in general work. Because I think it gives you more of a mental model or a framework to work from and be able to be a little bit more objective about the things you’re looking at. It seems like it would be easier in some ways to be more ignorant and just say, “I know what I’m doing. I’m going to do things in this particular way because I know that it is going to work.”
I think being able to second guess yourself and being able to be a little bit more objective about the decisions that you make, or that other people are making, the advice you’re receiving from people, is extremely beneficial just because it gives you enough mental model to work from something where you’re not sure. You’ve got these dark spots and you’re aware of those dark spots. You know that there’s places where there’s some—I don’t want to call it risk—but some percentages that could go either way. At least knowing where those places are is important.
Rob: Yeah. When I’m thinking about a decision or something like this where I might have an absolute in my head, I often will couch it as like, “Well, I’m 51/49 on this.” Or I’ll say, “I’m 95/5 on this.” I rarely go higher than 95. There tends to be the exception or the doubt. It’s not just so clear cut.
Before you take us out, Mike, there’s a few absolutes that I want to throw out that as you listen to them, each of them has totally valid exceptions even though they feel like, “Wow, maybe it should be true.” I challenge the listener to think about the complete valid sections to each of these things.
Always write unit test when coding. Always grandfather on price increases. Never trust Google or Facebook. Never build on someone else’s platform and have your business totally reliant on it. Never go B2C. Never raise funding. There are more we could throw out.
In general, are those things true? Yeah, I would say so. Yeah, I think those are good rules of thumb. Are there totally valid times to break them? Indeed, sir. Absolute thinking, while it’s not always bad, we would conjecture that, I think all of us, you and I included, I think we can all get better at.
Mike: You would say that it’s not always bad but it’s not always good?
Rob: Not always good. Let’s raise the bar. Let’s raise the bar of the conversation. I think that’s the point.
Mike: With that, we’ll wrap things up. If you have a question for us, you can call it in to our voicemail number of 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com.
Our theme music is an excerpt from We’re Outta Control by MoOt. It’s used under Creative Commons. Subscribe to us on iTunes by searching for Startups and visit startupsfortherestofus.com for full transcripts of each episode. Thanks for listening. We’ll see you next time.
Episode 444 | Our Biggest Regrets, Feelings of Isolation, Impact of Management Tasks on Deep Work and More Listener Questions
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike answer a number of listener questions on topics including what are their biggest regrets, how to deal with the loneliness of building a startup, and task management.
Items mentioned in this episode:
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 build your first product or you’re just thinking about it. I’m Mike.
Rob: And I’m definitely not sick today.
Mike: And we are here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, definitely not sick today?
Rob: As bad as this sounds and as much as I hope not to be a pain in our listener’s ears, I actually feel better today than I did yesterday and the day before. You know how sometimes the voice stuff lags what actually feeling bad?
Mike: Yeah.
Rob: That’s how it is now. I’m not 100% for sure but definitely able to record a podcast. I just don’t know if my voice is going to hold, so at a certain point I may just drop off and be like, “I don’t know, Mike. You answer the questions.”
Mike: I’m just going to mute you and I’ll replace you with a text-to-speech converter or something like that.
Rob: Yes, that would be great. But the show must go on, am I right, Mike?
Mike: I suppose it does.
Rob: The show must go on. For me this week, I’m excited MicroConf Europe tickets are on sale. It’s in lovely Dubrovnik, Croatia again at that amazing hotel, where we’re amassing an ocean view, second week October. microconfeurope.com has the full details. Although I just look at it and the speakers are last year’s speakers. We’ll have to get that corrected. We haven’t selected any speakers yet, but know that it’ll be a good show.
Mike: I’m definitely looking forward to going back there although I do remember thinking to myself that because the hotel was built into a cliff right against the ocean, my engineering days came back to me as like I wonder what would happen or what it would take for the whole thing to fall into the ocean.
Rob: I’m hoping that they’ve thought of that. Way to go, Mike, five people just decided not to come because of what you said. I think they’ve thought of that and as far as I know they don’t have earthquakes there. You would never build something like that in California or if you did, you’d really have a lot of supports and such seismic stuff.
Mike: For whatever reason, my brain just goes to those types of things, whether it’s a plane or a giant bridge or something like that. I just think I remember one time, my wife and I were driving back from Massachusetts to New York because that’s where my family is, and there’s this bridge that goes over the Hudson where we stopped on the bridge because traffic was just so bad. We were at a complete standstill and the bridge was popping up and down. Not a lot but it was like four, five, six inches, something like that but you could feel it. The entire car was just bouncing up and down a little bit. All I could think of is that video from grade school or from high school where they show you this bridge that basically just rips itself apart in California.
Rob: It’s in Washington.
Mike: Was it Washington?
Rob: Yeah, in Seattle or that area.
Mike: Oh yes. The Seattle Sound, I think. So that just came to mind. We were out of reason like these giant structures like that is all I can think of sometimes.
Rob: Yeah, I find this as software engineers. Oftentimes, you’re trying to think of everything that could go wrong and when you transfer that into life, sometimes it’s not such an adaptive quality. Sherry will suggest things, “Hey, let’s go visit Mike.” “Here’s six things that could go wrong with that. Again, that’s actually not helpful. How about instead of that, you go on and you select an Airbnb and look-up for the tickets?”
What else? You have a webinar last week, right?
Mike: Yeah, I had a webinar. It was a couple of days ago and I went a little bit longer than I thought I would. I thought it was coming around 40 minutes and it ended up coming around 50–55 just because I went into more depth on a couple of things than I had probably originally expected to. But it was pretty good.
I think there were 46 or 48 people who registered for it. I got their contact information and the list that I got also included their company names, their job titles, where they’re located, the size of the companies, a lot of interesting things there. So, definitely adding those people into my mailing list and working from there.
It was fun. I’ll definitely do it again. It’s just a question of whether or not they would have me and whether it’s applicable to the audience still.
Rob: That makes sense. Did you get any positive feedback or did you get much feedback?
Mike: Very little feedback. There is one person who submitted feedback out of the people who attended. I also got information about who attended and who didn’t. So, there’s emails that go out to them after where it sends them a link to the video. I’ve got a copy of the video as well. It’s typical webinar stuff.
Rob: We did a bunch of webinars in the early days of Drip. Some of them we found worked really well and others were complete bust and waste of time. You don’t know for another week, another month, depending on who sticks around and listens and who basically stops reading your emails or whatever other way you contact them. Curious to hear a fit, figure if it’s worth your time, and maybe 2–3 weeks I think you have a decent sense of that.
Mike: Definitely. The other thing that I’ve been looking at lately is that I’ve been testing out a new email client called Mailbird. You and I talked about this very briefly before the podcast and we decided to talk about it on the podcast. I find that most of the time I look at my email through Google Chrome and I have most of my different emails from different domains forwarded in there so that I have the one email client.
I was looking at Mailbird just because it has a unified mailbox where you can see and view all of your emails in one place regardless of what IMAP servers they’re coming from and what domains they’re coming from, et cetera, so I can see everything there. I’m not going to have to forward things over if I don’t want to but I could. I could continue doing that, but the one problem I’ve had with that is that the mail servers tend to rewrite the headers. If it’s forwarded in email, then the SPF records are no longer valid because it’s basically being rewritten. It no longer matches the original, which isn’t a big deal because I’m the one receiving them. But it still screws up the reporting staff that they get on a weekly basis about my sent emails. But you said you were assessing out something else as well. What’s that and why?
Rob: Mailbird I can’t use because I’m on a Mac. It’s Windows only. I was going to check it out, I was on the site. I straight-up Google best Mac Gmail client because I like Gmail, I like the paradigm of it, and it’s so slow in my Chrome browser now. I will go to type an email, you know that I know all the keyboard shortcuts, I’m like, “Label this as that, then type five words,” and it’s playing catch up with me. It’s getting worse and worse.
I know everyone’s thinking Superhuman, “Go use Superhuman.” Yes, I will check them out at some point, but I really wanted to consider going back to a desktop client, both for the speed and just the native feel. I found an app called Mailplane and it basically mimics the Gmail interface in a desktop wrapper in a sense. There’s also a calendar you can flip back and forth.
At first I really struggled with the fact that it wasn’t just a tab in a browser, but now I’m starting to like it. I have it on a completely separate monitor than my browser and when I click a link it opens in a browser on the other side instead of opening it in a new tab and throwing me out Gmail for not holding Command-Down and opening a new tab. I started liking the workflow. I like that all the keyboard shortcuts as the same, I label things constantly, I archive things constantly, I delete things, and I snooze or boomerang them. Those are the four most important things I do. Of course I compose and send, but those four things have to be super fast, they have to be keyboard shortcuts, and I do that both on mobile and on my desktop in essence.
The one place where it falls down is it doesn’t have the snooze keyboard shortcut, which is B, and I can’t install Boomerang on it which also has the B keyboard shortcut. I may bail on it, go back to the drawing board, and try out something like Airmail, or I know Spark’s good, or take a look at Superhuman. I struggle with wanting to do Superhuman. I think some of the hype drives me away from it and also $30 a month, obviously, I can’t afford that. I struggle to pay that or something. It’s so stupid because I’m in my inbox constantly and if it saves me any amount of time, it will pay for itself in a day.
Mike: I think it’s probably the price anchoring you have to Gmail, which has been free for 15 years now and you’re like, I don’t want to pay $30 a month for something like that.
Rob: Yeah and it’s also I know that I have to relearn or I’m expecting to relearn a bunch of keyboard shortcuts. While I can totally do that when I switched from Windows to Mac, that was a complete trucking of my productivity at the time. But I got over. It took me two, three, four weeks, and I was good.
I’m sure that if I switch to Superhuman, it will be all good. But I also want to look the product mature a little bit and see what direction it heads because every time I do this switch, I’m always wary of like, “Here they go. They got acquired and now they shut them down,” which has happened with three of the mobile email clients I’ve used, or they themselves start getting slow over time, or things go wrong with the business model and they start showing so much ads, whatever.
I know they’re charging $30 a month, so that should mean that, (a) they shouldn’t get shut down or acquired, and (b) they’re not going to do ads. All of the objections I’ve actually brought up are probably not going to happen but I often don’t trust these Silicon Valley startups in these early days because you just don’t know what’s going to happen and I don’t want my whole world to be invested in this single app that is quite disruptive to leave.
Mike: Two things here. One is I was looking at the Mailplane app website and there is something there that says flat-out that they had support Boomerang as a third-party extension, so there might be a way to basically add that into the app itself, maybe as a plugin or an extension or something like that. The other thing is that, it’s interesting that you and I are probably on the same page there where just because it’s a Silicon Valley startup and they’ve got funding, we actually put less emphasis on them being a viable product, versus the bootstrap companies where the largest company say, “Hey, I’m not going to trust you because where’s your funding? You might go out of business tomorrow,” versus I almost feel the Silicon Valley startups.
Actually, it’s the opposite. That’s just the way I view it. It seems like you feel the same way about this and I think it’s partially a function of whether or not they’re charging for their service or it’s a, “Let’s try and get as many users as we can, and try to figure out a business model to make money later.”
Rob: That’s it and since Superhuman are charging, it does remove some of those doubts, but still I’m pretty skeptical on one side. I’m like, “Yeah, you’re going to make me switch over and learn all the stuff, it’s going to make me faster, and then in six months, you’re going to do whatever. You’re going to pull a medium.” Again, anything I can think of is unlikely to happen because I was gonna say, “You’re going to pull a medium and start charging,” but they are already charging.
It just makes me skeptical that they don’t have my best interest at heart and what they have is hyper growth at heart, and they’re going to be willing to sacrifice whether it’s my user experience or whatever in order to further their business. I’m just not convinced. I’m not trying to pick on them. Just in general that’s how I view these startups. I think I will move there, eventually. That’s probably where I’ll wind up. But the fact that you just told me Boomerang is available at Mailplane, I don’t know if I have a reason to move anymore because I just click down extensions, I installed it, and it looks like it’s working. That does change the game for me. Thanks, Mike. I appreciate that.
Mike: There’s a bunch of other extensions there, too. I know you use them, so.
Rob: Yeah, but Boomerang was at the top when I went to extensions. It was literally the first on the list and I just downloaded it while you are talking, I configured it, and it’s looks like I’m all good now. It will be interesting. I like to question my assumptions and one of my assumptions is that I really want to stick with the interface. I’ve been using Gmail since 2006. Is that when it came out? I mean, I was really early on.
Mike: It came out before then because Bluetick I can see where my earliest emails were sent and received and I didn’t get into Gmail for at least a year or two. I think it came out in 2003 but my earliest emails were from 2005.
Rob: And I’m somewhere in there, 2005–2006. It’s not just I’m used to it, but the keyboard shortcuts and the actions all makes sense, and I’m very fast. It’s like using them or using an “old” editor that people move on from, but when you’re really good you can actually be in the command-line the whole time. I feel like that’s how I sync with Gmail.
Obviously, there’s an Outlook mail client or there’s a bunch of good desktop Mac clients for Gmail, but enough of the paradigms or trying to be different, and it’s not just keyboard trope. It’s just the whole interface. When you’re looking in different places for different things, I’m not sure I want to give my productivity gap much of a hit over the course of weeks or months and I’m not just sure it’s worth it to relearn a new tool.
Mike: That’s actually what attracts me to Mailbird was because all of the keyboard shortcuts were the same as Gmail. It’s just like, “Oh, I can just hit the V or…” I honestly don’t remember what the shortcuts are. I just do them at this point, but adding a label to something, or moving it, or throwing it to the trash, those things are just keyboard shortcuts that I just use. I think one of them is Control-Pound or Shift-Pound or something like that, and there’s one, it’s a V and add a label to it and move, and all that stuff. It’s just there and it’s very intuitive, very much alike. Not intuitive because shortcuts are not intuitive, but once you learn them, they just become second nature. For the most part, the ones that I use are there and it’s helpful.
The only thing I don’t like is that in Gmail I have have stars in emails and then I have one’s that are marked important and then ones that basically everything else below that. I have three different sections and it doesn’t have that. It only has two. So, it’s like, “Oh, well.” I mean, I’ll live. It’s not like I’m going to stop using it because of that. It was cheap, so.
Rob: Yeah and it’s just keyboard shortcuts. I’m sure Superhuman probably duplicated the Gmail ones, but there’s other things. A little known fact, actually, Mike. Before I started Drip, I was actually pretty heavily considering building a mobile email client that was all the things. It was fast and there’s some add-on. I remember you and I talked about it. I was like,“Yeah, this is on my list,” and you’re like, “Boy, that’s kind of a Silicon Valley play.” You’re like, “How are you going to make money at that?” and I was like, “Yeah, that’s what I’m struggling with because it’s not a normal SaaS model.”
I thought for a bit of why I should do basically a SaaS email client and again, make it fast and make it do all the things, build on top of Gmail in a way that they’re not innovating on, and I thought to myself no one would pay for that. They wouldn’t pay a price. I don’t want to charge $5 a month. What’s funny is, I think that was my bias because I don’t want to pay for an email client, but also, it was 2012 and I don’t think Gmail had the problems that it has today with the slowness and all that. It didn’t have that problem in 2012.
I think timing is also a factor. It’s not just that I have the idea, but you also need to be there at the right time and you need to execute on it. The Superhuman guys has done a great job, as we’ve heard years of customer development in essence to get to where they are today, and that was obviously a ton of work to get there. It’s not just, “Oh, you had the same idea and the Superhuman guys did it.” They did a really good job of it, executed to perfection.
Mike: That’s actually a very odd coincidence that you mentioned those specific things about the speed because I think it was about two years before that that they had acquired the business that your co-founder in TinySeed, Einar has. He was building and it was to make mobile search very fast. Then fast forward a couple of years and the search is no longer dog slow.
Rob: Yeah, it’s a trip. You wonder if Gmail, in the background, are they’re innovating and they’re going to basically release something that’s going to makes them superfast and that implement some of the things Superhuman does. That’s the other thing. Since it’s on top of G Suite or Gmail, they have platform risk right now. As an idea like Gmail or Google could feasibly shut them down. It would be a bad move or an anti-competitive move, but we’ve seen this happen with Twitter API restrictions and all that stuff. Facebook do that, wouldn’t put a pass Google and it could be a pretty big issue for Superhuman moving forward if they become a multi-million dollar business, deck a million dollar business. Who’s to say Gmail won’t either just implement the features and it’s still free or screw around with API access and that kind of stuff?
Mike: It’s funny you mentioned that because I’ve actually been going through a bunch of approval processes with Google. I don’t know if I talked about this before, but because I’m accessing customer information through OAuth, I had to go through this approval process and they say…
Rob: You did talk about it. A couple of episodes ago you mentioned it’s pretty cumbersome.
Mike: And I’m still going through that. I’ve sent them a bunch more information and I’m just waiting now to see if anything else that they need and I haven’t heard anything back for at least a week or two. That’s certainly something that could happen, but it’s more of a result of me just accessing things through IMAP. I don’t know how they actually access that data but if it’s through IMAP, then there’s got to be a reasonable way to get access to it because there’s no way I could see that Google could say, “Look, nobody can access through IMAP anymore. You have to use OAuth tokens and et cetera. I suppose I could end-of-life that access down the road but they’re going to have to wait while people, their email clients switch over and add that type of support.
Rob: And that concludes this episode of Gmail Clients for the Rest of Us. That was a longer tangent that I thought we would go on, but I think it’s still interesting stuff. We touched on a couple of relevant points of platform risk, about finding the right client, because if you’re in it so many hours of the day, it’s important stuff, and then switching cost and that kind of stuff.
Mike: With all that said, I think we’ll switch over and actually start doing some of these listener questions that we get them in before the end of this episode. The first one comes from Steven Moon. It came into Twitter and he said, “With so many years of experience behind you, both in the startup space, what would you say were some of your biggest regrets?”
Rob: This is a tough one. I gave it some thought in advance of the episode because it’s not something I think about that much. I tend to make pretty calculated decisions, I tend take longer to makes decisions than some people, and I try to make it with all the information I have at the time. If I make a decision with that and it turns out to have a negative outcome, I don’t consider it a regret because I did what I thought was best at the time. I don’t make many impulsive decisions. Those are the decisions that I would tend to regret, are things that I didn’t take the time to think it through or made an emotional decision instead of trying to look at the data and making the best decision.
With that said, I think that something that I regret early on—this is 2005, maybe 2010—is that I was too timid. I was scared of making people mad. I was too much of a developer to do marketing. That transition actually happened during that time period, but in the early days, even before 2005, I didn’t want to market because I considered it some bad thing. SEO, AdWords, taking out ads. I don’t know adjusting to all that and even doing sales. It wasn’t something that I really wanted to do and I wished that I’ve gotten there sooner. Eventually, I realized, “Oh, this is valuable. A fun product provides value, reaching to people, for who it’s going to have value for, is an important thing.”
I think another thing that I regret is I thought that I could do everything myself early on. Frankly, I did everything myself for a while and then I hit the ceiling on that. Then I hired contractors and VAs, which worked to a point. I guess I don’t have regrets that I did that, but then eventually knowing that I needed a deeper network of people, has changed my world and allows me to do things a lot faster and a lot easier than just trying to go it on my own. These are lessons I’ve learned along the way and I guess my regret is I didn’t learn earlier. I think those tend to be my regrets. I have another one but how about you? You want to weigh in on something?
Mike: I think some of mine are similar to yours. Essentially, they were learning experiences and the one that definitely comes to mind is not really thinking through things before just doing them. I wouldn’t say that I was unnecessarily impulsive in many ways, but I would definitely say that I didn’t pause to look at the big picture enough.
For example, when I was in college, I did not do very well. Even going back into high school, I did very well in high school because it was high school and it was easy to make. But unfortunately, the by-product of that was I didn’t know how to learn things. I either figured it out and just did whatever needed to be done or I just said, “I’ll be able to figure this out.”
What tend to happen is I leave things to the last minute because I want to do other stuff and I wouldn’t spend the time to focus on my studies or actually really trying to understand stuff. It’s either I could do the problems or I couldn’t. I feel like I didn’t have a good understanding of how I learned when I got to college and I really struggled when I got to college because of that, because I relied on me just showing up and being in class to understand stuff. When I didn’t, I had a hard time sitting down and actually doing homework or studying because that was just not how I had wired myself.
That took a really long time to break. It took four or five years to break that habit. I fortunately did when by the time I got to grad school but it took way longer than it really should have. It was because I didn’t think about the longer term consequences of what those actions could potentially be but I didn’t necessarily know what those consequences would be, either.
Rob: Right because you’re 17. I think he was asking in terms of startups. How does that relate to your business? Your professional career? Or does it?
Mike: It does. I have to intentionally set aside time to think about the bigger picture and if I don’t, I could easily find myself just going down the rabbit hole and not thinking about, “Is this the right thing I should be doing? Is this the most important stuff for me to be spending my time on?” I can easily burn a lot of time doing stuff that actually doesn’t move the needle or isn’t very important if I’m not very cautious and conscious of that.
It’s more of being aware that that’s a flaw of mine that I have to keep in mind and being very intentional about setting aside time to come up and look at the big picture. If you look back in my day with AutoShark, that was a huge problem because I just put my head down and kept going. What I really should have done was take a few steps back and look at the bigger picture and be a little bit more objective about stuff.
Rob: That makes sense and knowing that’s your previous position, you should ask yourself that now, what it would look like to take a step back? It’s a rhetorical question but that’s the thing about knowing our strengths and weaknesses is now that I’m older, I know a lot of my weaknesses. I don’t know that I know them all but I really tune in when I start the same things that I realize, or maybe not 100% true, or just an emotional thought, or me just trying to justify what I feel like I want to do, rather than what should be done, and those are weaknesses.
Or when I am a negative self-talker. I talked before if I don’t get enough sleep, I’m super negative and I’m almost look like someone who’s depressed. I’m unmotivated for that day. I’m unmotivated and I’ll just be like, “Nothing’s going to work. This whole thing isn’t even going to work. Why are we even doing this?” I literally have that in my head and I will always say like, “Dude, this is a temporary thing. You’re just in a weird state. Go take a nap.” I’ll come back and I feel better about it, but I didn’t realize that until five or ten years ago. I think that that’s an important thing, to know yourself.
Mike: The way that I deal with it now is I do a lot of journaling and I use that to track whether or not I’m making progress on stuff or getting things done that I need to get done because I will write those things down, but again, that’s just a personal productivity hack more than anything else of make sure that I’m staying aware of those things.
I would say that the other major regret I have, I’m not sure if I label it as a regret but being under the belief or assumption that I would be youthful forever. I definitely found that as I’ve gotten older, things do not heal nearly as quickly as they used to, I need more sleep that I used to, and just a lot of stuff with my personal health that I was like, “Oh, I’m invincible. I’m twenty-something years old and nothing will ever happen to me.” Fast forward 10 or 15 years and your body starts to give out on you in certain ways and you’re like, “Huh, that sucks,” and there’s nothing you can do about it.
Rob: That makes sense. The other regret I can think of is that I didn’t take good enough care of myself while growing Drip. There’s self-care. What’s funny is it’s what my life talks about all the time. That’s what ZenFounder is, about taking care of yourself. There’s a certain point where I was just bearing the burden of a lot of stuff. I wasn’t working on the things I liked but I knew they had to get done and it’s that recipe for burnout where I’m capable of doing them but they don’t bring me joy and I didn’t want to interrupt anybody else’s day because everybody else was either selling or onboarding or writing code and that’s what’s needed to push the business forward.
If I pulled anyone else into it, this is a fallacy. You tell yourself like, “I’m just going to grind it out. The business is going fast, everything’s working. Why would I screw that up, pull people off, and move slower than these other things?” Anytime I got budget, I hired a support person or a developer or someone else to move the business forward and really should have made some different decisions there.
I didn’t take good enough care of myself, I did start to enter burnout at a certain point, and that sucks. There were a few times in my professional career and the most recent one was during Drip. I think I want to avoid it for the rest if possible, because it takes toll on you and your relationships is the problem. You can recover but if you’ve damaged relationships, it takes a while to repair those.
Mike: Moving on to our second question. This one comes from Dick Polipnick and he says, “What do you think of buying a small company that already serves your target customers and building your SaaS idea on top of it?”
Rob: He’s saying buying a small company that is not a SaaS company, right? It’s either one-time download software or it’s an info product? What do you think he’s implying here?
Mike: I think it could be either one of those. It could also be a services business of some kind? I wouldn’t say it’s as big as an agency. I think the implication here is it’s a small company that’s probably one person or maybe it’s just a book or something like that. That seems odd. I don’t think that’s it, actually.
Rob: If it’s a small consulting agency, I wouldn’t buy an agency unless I wanted to do agency work. Going from agency to product, the work is hard. Ask anyone who’s trying to do it because you have so many things going on. It’s a well-worn story. It’s possible, but it’s a slog. I would not invest money into acquiring an agency. If it’s like an ebook or a one-time downloadable software and there was an audience there that you felt like could buy a SaaS or would be interested in something that’s pretty a direct path to it, I’m not opposed to the idea of it.
The concern I have is, if you spend this money—let’s say it’s $30,000, $50,000, $100,000, it’s a chunk of change—then what if you’re wrong? What if now you have this info product that you don’t really want to run or you have this one-time download software that you don’t really want to maintain and they don’t really want the SaaS? You can’t ask them now because you don’t have access to the audience.
I’m not saying don’t do it, but I’m saying how can you prove that I bought this or disprove that hypothesis without spending the money? Can you work with the current owner to survey the audience to find out if they do want the SaaS? Or maybe you do? Maybe if it’s a one-time software and you buy it, and the SaaS doesn’t work out, you’re okay with that. One-time software is not terrible. I mean, I had done it, it was for years, and it was a great revenue stream.
So, I’m not opposed to it but I do feel like you have to answer a lot of questions. Even if you answer, I would ask, “It’s like acquiring yourself into the stair step?” which is something that I did and very few people do, but I didn’t intend to build SaaS on top of the things I acquired. Those were really just income revenue streams. So, not opposed to it, but I do have some questions that I want answered before doing it.
Mike: I think the piece that’s probably the most important is how you validate that is the right move and that those people are going to want to purchase a SaaS? If there’s already people who are purchasing the SaaS products in that particular target market that is similar to what it is that you want to build, then great. Are you buying it because of the company and what it offers? Or you buying it because you want to plug it in and you see it as a new channel that you can tap into because they’re offering something that nobody else does in this particular market?
So, thanks for the question. The next one that we have is from Daniel Fellows and he says, “Question for you. How do you deal with the loneliness of building your startup?
Rob: I think that’s the reason I started my blog back in 2005 was the loneliness of trying to do something that I didn’t know if anyone else was doing it. I didn’t know if any other single founder software startups that were raising funding. There was nobody.
I starting blogging and trying to find other people. That turned into my book, then this podcast, MicroConf, so I deal with the loneliness by having this community. Whether I have been part of building it like we have been or whether I just became a part of it later, I rely on this community as much as anyone to keep me from feeling that loneliness. That is a reason.
We did the podcast for a number of reasons, but I think part of it is to be able to talk about this stuff, both with you and with the audience, and to get questions and comments and all that stuff is helpful.
Going to MicroConf basically three times a year in essence is a big one for me and I always get a bump from there, realizing that there’s a bunch of other people doing this with us. On their own but with us. And then of course, Mastermind groups. That’s been a huge thing. I have always been a proponent of it years and years. That gives you that touch point every other week or however often your do it, to know that there are people that are in your corner.
I didn’t do this when I was growing startups because I was so focused on grinding out day to day, but finding founders, entrepreneurs locally, Sherry’s been doing a good job of that here in Minneapolis of finding local entrepreneurs and having them over for dinner once a month. We’ll just get two couples over here and have a nice dinner. Sometimes the conversation involves work and other times it doesn’t, but having that shared ethos of being a founder makes conversation super interesting and cool. How about you?
Mike: I agree with everything you said. The one other thing that I would add is finding something that is outside of your business where you can use to socialize with other people that is not work- or business-related. I think that’s something that I definitely neglected that early on in my career where it’s just I worked all the time and beyond that I didn’t do much else.
I didn’t really have a life outside of the business and I think that’s probably, I wouldn’t say a huge regret but it’s definitely something that I probably should have done a little differently if I were really thinking about it or thinking about the future. I think I’m definitely on the right track there these days, but it’s something that I would probably emphasize a lot more if I were to go back and do things over again.
I feel like having time away from your business when you’re not thinking about it and you’re not talking to people who are also running their own businesses as helpful just as a way to recharge. If you’re spending all of your time thinking about it, it starts to creep into places where it really shouldn’t, like when you try to sleep at night and you toss and turn just because you’ve got business on your mind at all times.
There are always interesting problems but it’s helpful to have something else that is completely distracting and completely irrelevant to your business that you can do that will take your mind off of it. I find a lot of times that there are problems that I’m working on where the solutions just come to me very quickly if I’m not thinking about it.
Rob: It’s a good point. It’s something I didn’t do until the last 2–3 years actually. I believe I was doing some tabletop gaming before that, but before the exit in 2016, that I really ramped it up after that. That’s something that I’ve enjoyed having as a hobby. I really neglected my hobbies for a decade plus and I don’t regret that actually and wished that I have done more hobbies because I did take that time and I got stuff done.
The reason I was able to put out as much content as I did and we’re into all the multiple things as I was thinking about them a lot. Eventually, that can take a toll on you. I think having maybe one hobby that’s not super time-consuming can be helpful. But since I didn’t do it, that’s not something I can necessarily recommend. I know it’s best practice, but I think the other stuff we’ve talked about with masterminds and such is that’s what I did, so that’s what I feel better about telling people with a straight face. Not to just do what I say now as I do, but you can do it as I do and I think just to keep from being lonely.
Mike: For our last question of the day, we’re going to take one from Graham Blake and he says, “As a single founder whose business has succeeded, I find I have less time to do the things that made it succeed. I delegated a fair bit but the management of a bunch of small areas reduces the time I have to deep dive on stuff. How do you organize things? You can still do the most valuable work while keeping the machine running smoothly. My biggest difficulties are that most of my valuable work involves deep focus, which is generally writing a video production. I have to give feedback on work that is being done for me, but if I ignore this for too long, it creates bottlenecks.”
Rob: This is a hard one. It’s the maker’s schedule versus the manager’s schedule from Paul Graham’s writings where the manager is interruptive, you’re responding, you’re trying to keep people going, and the maker is where you need deep focus. Trying to be both of those is very hard. I don’t know that there’s a great answer to it other than to hire someone to manage all the little ins and outs so that you are no longer a manager. Trying to be both is hard.
There’s really two solutions here. Step away from the making, hire somebody to do that, or step away from the managing and hire someone to do that. I realize neither of those is easy nor straightforward, but we’re entrepreneurs and we do things that are not easy or straightforward. That’s what I would look to do longer term if I look out six months or a year, I would look to get completely out of one of those or the other and you need to ask yourself which one you want to do.
We’re bootstrappers. You can do what it is that you want to do. That’s why we design these businesses around us and then figure out a path to get there. It may not be hire one person to manage everyone right from the start. Maybe it’s someone with enough skill that they can manage part of your team, part of the contractors or whatever. But you need to remove yourself from the deep dive if you don’t want to be doing that or you need to allow yourself to deep dive if you want to.
Mike: I think it’s really hard to cross that line because there’s a chasm between what you’re looking for from people versus what you’re actually getting. Until you get to a certain scale, it’s hard to put people in there if you can’t afford to hire managers, for example. I think that getting to the point where you’ve gone one direction or the other is the difficult choice the most people have in front of them.
I’m sure you’ve run into this in the past where you’ve got something that you’ve outsourced to someone and then they come back with it, but you still need to spend time going through it and looking at it, making sure everything’s right. Really, the only short-term solution I see for that is time-blocking in some way, shape, or form so that you are not trying to do too much context switching between the creative time versus that management time.
If you try to slot it in on a daily basis, it’s just not going to work. I’ve found that if I allocate time for it once or twice a week or something like that, maybe Tuesdays and Fridays or something along those lines, you can get more done because you’re not context-switching between those things as much. Anything else that comes up, you have to be diligent about making sure that those questions don’t come into a channel where it’s going to be disruptive to you.
I was constantly telling people, “Hey, don’t send me a Slack message. Send me an email and I will review it when I get it. Otherwise, that Slack message is going to be disruptive for me. It’s going to screw up my schedule of being able to work on this stuff.” You just have to be diligent about making sure that the expectations are that you will review stuff on Friday and you’ll go over it with them on Tuesday, for example. That way, you can email them, say, “This is what my thinking is,” or, “Here’s a short video of what my thoughts are.”
Got something else I would rather recommend is trying to cut down on the synchronize time that you have to spend with people. If you can do a short recording of it and send it to them as feedback versus getting on a call with them so you both have to be available. I find that calls tend to be disruptive just because if it’s 20 minutes or half an hour before the call, you’re really hesitant to start on anything that has any level of involvement because you know you’ve got a call coming up and you don’t want to have to stop. It’s about being conscious of where you’re time is going to be wasted and these are going to waste half an hour of your time before and after the call.
Rob: Those are all good points and I really want to highlight the one of just changing the expectation of communication and saying, “By default, use email because it asynchronous. By default, let’s not schedule calls. Maybe use Voxer where we can leave a voicemail and go back-and-forth on that, then turn off alerts, and check it twice a day or something. But if stuff is urgent, then you can text me or Slack me and interrupt me. If it’s super urgent, you are blocked, and you need an answer within, let’s say 10 or 15 minutes, then use an interruptive medium. But if not, don’t. Just use Slack for everything.”
That’s always when I would onboard new people. Anytime, actually, with TinySeed, with Drip, with whatever, that’s my thing. It’s like, “Let’s not Slack by default. This is dumb. Let’s not text by default. I don’t need to be interrupted and you’re interrupting what I’m trying to do.” That could be a first step. We just don’t know if it seems using Slack for everything is just throwing them into a loop, or you can say, “Hey, everybody. I’m going D&D. Do not disturb for the next two hours. I will not get back to you. If the building is burning down and the site is completely down, then break my D&D. Otherwise, do not expect a response.”
Frankly, if you’re a software video production company, that should be the default. I think two or three hours every morning, two or three hours every afternoon, everyone should be doing that. Now, that doesn’t work if you’re a manager and you have blah-blah-blah. Yeah, I get it. But that should be the default and you should be able to break that rule if you have a specific role, or if you have a specific week, or you need a lot of collaboration or whatever.
I can’t believe my voice at a certain point that I thought was not going to make it through this episode, but I’m glad you were talking at points because it gave me a chance to recharge it. I’m feeling good. We answered a bunch of listener questions today.
If you have a question for us, you can call them into our voicemail number at 888-801-9690. Voicemails always go to the top of the stack unless I screw up and forget to move them there. You can also email it to us. You can just attach or send us a Dropbox link to an audio file, or you can do the old-fashioned and just send us some text to questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt. It’s used under Creative Commons. You can subscribe to us in iTunes, Stitcher, Overcast, Downcast, and all the other good ones. Just search for ‘startups.’ We tend to be in the top few. You can visit startupsfortherestofus.com to see a full transcript of each episode. Thanks for listening. We’ll see you next time.
Episode 443 | Determining Which Signals Matter, Staying on Task Without Extrinsic Motivation, and More Listener Questions
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike answer a number of listener questions on topics including which signals matter, staying on task without external motivation, and how they manage their time.
Items mentioned in this episode:
Mike: Yes. It’s one of the Star Destroyers but I don’t remember which one. I figure whether it’s the Super Star Destroyer or is it just one of the other ones?
Rob: I believe it’s Darth Vader’s Star Destroyer.
Mike: Yeah? Okay.
Rob: Exeˈcutor. What’s funny is I used to call it the Eˈxecutor when I was I kid because it’s spelled like that but I learned it’s called the Exeˈcutor. Here’s my question for the day. How many bounty hunters are on the Exeˈcutor when the rebels are hiding in the asteroid field?
Mike: Bounty hunters? Geeze.
Rob: This is The Empire Strikes Back.
Mike: Yup. They’re all standing around and he says like, “No disintegrations.”
Rob: Exactly and Robot Chicken has done a great parody of this. If anyone has not seen that, go type it. ‘Robot Chicken Star Wars Bounty Hunters.’ How many?
Mike: Oh gosh. How many exactly? There’s between four and six. If I had to guess, I’d go on the higher end. There’s probably six or seven, actually. I’ll go with seven.
Rob: Final answer?
Mike: Sure.
Rob: It is six. Very close, sir. I was at five, but Boba Fett, Dengar, Zuckuss, 4-LOM, Bossk, and IG-88.
In this episode of Startups for the Rest of Us, Mike and I discuss determining which signals matter, staying on task without extrinsic motivation, and more listener questions. This is Startups for the Rest of Us Episode 443.
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 build your first product or you’re just thinking about it. I’m Rob.
Mike: And I’m Mike.
Rob: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. Where this week, sir?
Mike: Yesterday, I was putting together a video for Google. Last fall, they’ve decided that they were going to come out with their new privacy policy and they’re basically pushing it on everybody who’s using their APIs. They’re saying, “Oh well, if you are using our API and you’re getting data from our customers,” technically they are my customers, “if you’re getting data from Google from those people because they are supplying their credentials and it’s passing through us, you have to conform to these new rules around what you’re going to be doing with data and how you surface that to the users.”
They just basically announced it in October or something like that and they said, “Oh, these new things are coming but we don’t really have any details on it yet.” But over the past couple of months they’ve really started pushing forward with the approval process and I had to send them a video that walk through exactly how people authenticate through Bluetick, every single place where data that I get from Google is used, how it’s used, show in the privacy policy and everything else, and I’m just like, “This sucks.”
What sucked even more is I created this 30-minute video and then I went to basically dump it unto YouTube, because of course you can’t submit it in any other way except by putting the video on YouTube, and I found out that there was no sound so I had to do it all over again. I had to re-record it. I was like, “This sucks,” and I tested the sound before like the first time, too. I tested it, it worked, then I did the video, and no sound. I was like, “Come on.”
Rob: That is no good. So, you basically just […] a bunch of times on something that really did not move you business forward.
Mike: Exactly. Of course, this whole thing does not really move my business forward, but I don’t know. I still have concerns about the whole thing because they say that depending on what you’re doing, you may need to go through a third party security review and I’m like, “Oh and that will cost anywhere from $15,000–$75,000,” and I’m like, “Uh, yeah. I don’t know about that.”
Rob: Interesting. They must have an exception, I’m guessing, for small companies? I mean, that seems like an odd thing to saddle you with.
Mike: Yeah, I don’t know.
Rob: It’s like it’s PCI has self-certification. There are often things like that where it’s a pain in the neck to do but there is some out. I guess it gets serious backlash. If there’s not, that’s not good because you’ve had this in place for a while and then they’ve changed policy?
Mike: Mm-hmm.
Rob: Huh? Google changing something and hurting someone’s business? That’s news. Shocker.
Mike: The sad part about that is that I specifically built Bluetick using IMAPS so I wouldn’t rely on their API, so that if they decided to change things on me then I basically wouldn’t be affected. Guess how that is working out for me right now?
Rob: Yeah, sorry to hear that. It’s tough to rely on any third-party. I talked about when I had HitTail, how we were reliant on Google keywords, and then they did not provide it. Then we got into the Webmaster Tools and then they broke that. They break that every six months. It was really frustrating.
That was a big reason that when I wanted to start my next startup, I didn’t want to be reliant, and then you just wound up being reliant. You’re relying on somebody at some point. You’re relying on Amazon or Google for hosting and it’s hard to switch. Yes, there are options but it’s a tremendous amount of effort to switch.
Even just sending emails, as you and I know, getting in spam, inboxes, and on blacklists like that, you become reliant on them, and then you have to go build all this infrastructure to keep you from spamming people. This is another example. You do something, it makes sense, it makes it easier for your customers, and in this case it kind of get you into a bunch of extra work to just maintain this thing.
Mike: It is a double-edged sword, though, and it creates this hurdle that if anyone wants to come in after the fact and try to build that, it just makes it more difficult for them. Just by virtue of building your app and making it better over time, that does the same thing, certainly so. I don’t know. Still trying to work through it. I sent it off to them. I send the video to them and in less than an hour later, they got back to me and said, “Okay, now this other thing needs to be fixed.” I’m like, “All right.” I fixed that and burned another three or four hours fixing that because they’re like, “You can’t have non-production systems using the same client ID.” I’m like, “Dear God, it’s the same thing.” So, I’m like, “All right.” I don’t know. I have to switch everything over, modify my build server and everything else.
Rob: Anything else beside from technical and integration challenges going on with old Bluetick?
Mike: I’ve got my webinar that I’m doing which, by the time this episode comes out, it will have been yesterday. I’m doing that for hr.com and we’ll see how that goes. I got to get them the final PDFs to the slides so that they can post it in the website and then get the presentation on Monday. It ought to be good.
Rob: Sounds good. On my end, just opposite pushing forward with TinySeed and things are going well there. I’m having a great time and I’m very excited about the batch that’s coming together quickly. We have almost all of the startups you selected, made offers, sent paperwork and that kind of stuff.
There’s a bunch of stuff I think I’ve said on the podcast in the past, like legal is the bottleneck and had been now for a month of two. We’ve been selecting and making offers but without the final paperwork, which is […] third party who isn’t moving nearly as fast, isn’t moving with the same urgency that we are, put it that way, has been a little bit frustrating.
I’m looking forward to getting past this point because not only did we have to incorporate and set-up multiple, where now all I see is a limited partnership in all this stuff, which takes time. Then we have to have all these docs drawn up and we won’t next time. Batch number two will not have the same level of foundation-building and will have a lot more way. We’ll know more of what we’re getting into and have better systems to do it. But realistically, the systems are not what are holding us back at this point. It really is this reliance on a third party who is moving at a glacial pace compared to us. So, I look forward to being out from under that here pretty soon
Mike: It’s interesting that you say that because it reminds me of, don’t know the inside story on this but my guess is that, that’s probably the exact reason why Stripe came out with Atlas was to help founders get past all of that stuff, so that they just didn’t have to worry about the pace of getting all the legal stuff taken cared of. It just reminds me of that.
Rob: Totally. It’s friction and it’s something, specifically with Atlas, that every company that’s not a sole proprietorship has to do. They just want there to be more of those companies. They want to have that rising tide so they can remove that friction. I remember the first time with […] I was like, “Wow, they’re really going outside their core competency,” but now I get what their long-term vision is, is that they just want more businesses that are able to get online. Of course, that’s what Stripe Atlas allows you to do super easy.
I said it before. I wish there was Stripe Atlas for accelerators and for funds. There are some pre-made things for it. They’re ridiculously expensive to the point of being a non-starter. So, we get to do it from scratch. Good thing I’m used to doing that, huh? No one thinks from scratch.
In other news, we have a few more podcast reviews. I’ll just read one of them. From wking-io, he said, “I could listen all day. I do not own my own SaaS but I work for a small info product startup and this information is so valuable. I’m able to see this information in practice and know that I will have a head start whenever the moment strikes for my own app from all the info Rob and Mike shares.”
Thank you for that review. We love a five star rating or if you’d prefer spending more time writing review, either one is fine, in […], Apple podcast, wherever greater podcast are sold, we appreciate it. Mike, when is the last time that you got something useful from Twitter?
Mike: I connected last week when somebody had lunch with them and we connected over Twitter directly. So, we coordinated that […] as you could say.
Rob: That was a very long pause. The editor edited that out but to the listener, Mike was silent for about seven on eight seconds. Number two, did you have each other’s email or did you literally meet and connect? If Twitter had not existed, would you guys have been able to coordinate that?
Mike: We probably would have. It was somebody who joined the MicroConf Academy years ago and he’s been eyeing MicroConf. It’s Josh from […]. We did lunch maybe Tuesday. Monday or Tuesday. It was Monday this week. He was in town from Maryland and just wanted to say hi, so we got together and chatted for a while about our businesses and how things were going.
It was a good time but other than that, it’s been a while since I’ve ever gotten any real value from Twitter. You’re right. Evidently, there’s a huge pause because quite frankly, I don’t log into Twitter very often anymore because it’s a lot of noise. I guess that’s what Twitter is for is for noise.
Rob: Noise and arguments. I’m not a hater but I’m been trying to figure out how do I get myself off of it because I find it a bit more of a distraction than anything. With that said, I haven’t gotten anything valuable from Twitter in a for a very long time except for yesterday and today. I knew we were recording this episode. We didn’t have enough questions to fill out a full episode and with one tweet, got frankly enough for probably two episodes or more. So, I want to give a shout out to Twitter for bringing the thunder once every six months for me or whatever.
Anyway, enough of the Twitterating. Our first question was posed on Twitter. It wasn’t even directly to us. It was probably a few weeks ago when I emailed it to my Trello board and got it over here. Justin Jackson posted on Twitter and he said, “One challenge I’d had as a founder, tracking and trying to triangulate thousands of qualitative data points. Somehow, you have to decide which signals matter. But even then, plotting all those data points on a map and deciding on a direction is tough.” Then Alli Blum replied then and said, “Same. I think about this pretty much all day, everyday.”
I think we should discuss because I have thoughts on this. Basically, how do you do this? That’s the question here is how do you as a founder do that? Probably the best question is, you have a bunch of qualitative data, how do you decide on a direction when there are conflicting signals?
Mike: I don’t like this answer. I’ll tell you that before I give it.
Rob: It depends? No, just kidding.
Mike: No. Even worse than that. It’s like a lot of gut feel. You go with what feels important at the time because it’s hard to take some of that data and say, “This is justifiably more important than that,” really based on whatever rules you try to put in place. It’s hard to put rules down on paper that are immutable. There’s always things that are changing and there’s always stuff that’s going to factor in to those decisions.
For example, the video that I had to do for Google. It wasn’t really all that important and I pushed it off for a long time because it just wasn’t important. Then, there was a deadline where it’s like, “Okay, you got a week before we just outright reject your application.” It’s like, “Okay, I have to do this now.” It’s because the priority has bumped up, because there’s a hard line in the sand, and it has to get done by that time or there’s consequences.
I feel like a lot of my decision-making around priorities tends to be driven by negative consequences of not doing something, as opposed to there’s going to be positive outcome for X, Y, or Z. There’s so many things that are going on at any given time and you have to try and juggle them all at once. It’s hard to do that.
Rob: I actually think that’s a good answer. I think gut feel is the first thing that came to my mind. I think rules of thumb are something that, if you could possibly apply rules of thumb or expertise from other people who’ve gone down before it, then start there. If not, it’s a ton of gut feel.
Justin has identified the edges of where we can have a startup blueprint and where you’re drawing your own map, with a map ends in essence. I actually have a tattoo on my shoulder that is a map and there’s a hand drawing at the edges. It’s a metaphor for exactly this, of going off the beaten path. Originally, it was like, “Well, I’m not going to work 9–5, a salary job. I’m going to go be a contractor,” and people are like, “Woah. that’s risky,” and then, “I’m not going to do salaried work anymore. I’m going to build products.” “Wow. that’s really risky. You’re hard. Can you even do that?” Then while you’re building those products, there’s no map anymore or very little map.
Frankly 10–15 years ago there was almost no map. Things like this podcast, even lean startup, customer development, SaaStr, and MicroConf have enabled us to develop a mental model. There are books that come out on the topic as […]. It helps all of us have kind of a lose map or a lose blueprint, but there’s always an edge to that. This is the point where you have a bunch of data points to decide another action. There’s no map and this is where what separates the, I would say, a poor founder from a mediocre one, a mediocre from a good, a good from a great, is how well they’re able to make these decisions.
I would also say that this is, at least for me, gotten easier over time. I feel like I’ve gotten better at it because here’s what it is. It’s making decisions without sufficient data. You don’t have all the necessary data to actually make the decisions, so you have to fill the rest in in your head. I believe there’s almost never a right answer to these things. There’s always multiple right, multiple tough, wrong answers.
I also believe that most decisions are reversible; almost all decisions. There are very few that are not. To some, you may think are not reversible. They may come with a monetary cost. They may come with a relationship cost. They may come with agony, pain, time, whatever, but almost every decision is reversible. The ones that are truly not are the ones that I now agonize over and everything else. I tend to make a pretty quick gut feel decision, realizing that if we need to change course later, you can.
Mike: I’ve looked at all these different data points and see them as signals that point at a certain direction. But some of them are more important than others, and based on the situation or timeline or things that you’re dealing with, some of them are going to come out on top. If you have rules on paper, it’s very hard to create a set of rules that say exactly what to do or how to track those things and to determine what matters.
As you said, I think that that’s a really good point about the fact that there are these guidelines and rules of thumb that you can follow. But at the same time, they’re just signals. That’s all it means. There isn’t a right or wrong answer, unless you’re looking at it in retrospect. In retrospect, there is always a right answer, or a best answer, or an optimal answer. But because you probably are working with only about 30%–40% of the complete picture at any given time, I call it guessing a little bit. It’s more like educated model recognition of what’s going on.
That’s why MicroConf is just so important and these conferences and communities where other people have seen those types of things. They can recognize it essentially on your behalf, if you have not been there before and you are not able to directly recognize it. That’s why mentors help. that’s why accelerator programs work. Like Paul Graham, I would imagine who walk into just about any startup and give pretty solid feedback about why it will or won’t work, and probably be very reasonably accurate on it, just by virtue of having talked to 1500 to 2000 or 3000 startup founders, and helping them through all those different situations.
Rob: There’s a book called Decisive by Chip and Dan Heath. It’s about how to make decisions. I believe Ruben Gomez from […] turn me onto that. I listened to it a couple of years ago and something they say in that book is, just because the outcome turns out bad doesn’t mean it was the wrong decision. Those two things are not linked. You make the best decision you can, with the data you have, and with the information, the gut feeling or whatever else, the intuition, whatever you want to call it, and then you do the best you can. You reverse it if you need to or you correct-course as you move forward.
Mike: I think that’s actually a problem for a lot of people, myself included. A large extent is trying to figure out, “Can I just make a decision and move on?” or even just recognizing that you’re a reasonably smart person, you’re going to make the best decision with the information you have at the time, and it may turn out to have been a sub-optimal answer or solution to whatever it is that you’re trying to do.
Waiting is not necessarily going to help you very much. You’re basically just wasting time at that point when you could have been trying to move something forward in one direction or the other. Maybe it was the wrong direction but, as you said, those types of things tend to be reversible. It could take some pain but if you wait around for enough information, you have wasted so much time and then you still have to do it. So, moving is better than not moving.
Rob: Yeah. Opportunity cost of postponing, or agonizing, or waiting, procrastinating, whatever word you want to look for of a decision. It’s hard and that’s why most people don’t do this, don’t start companies because it’s too uncharted, it scary, it takes a while to get used to, and it’s uncomfortable. I think that that’s when you know that you probably want to doing things right, but you know that when you’re in a zone of personal growth, is when you’re doing things that are making you feel not comfortable. That’s when you’re going to get better. So, cool. Glad that Justin threw that out on Twitter.
Our next question is about how to stay on task with no extrinsic motivation, no external motivation. It’s from Mike Manfrin. He’s @manfrin on Twitter. He says, “How the hell do you stay on task when you have no extrinsic motivation? I’ve been letting myself spiral out second- and third-guessing design decisions and getting absolutely paralyzed with choice and scope, that I end up doing no work towards my startup.” Ken Wallace chimed in, “Think about having a mastermind because those folks can guide you,” and I actually think that’s a good thing we should throw out. I mean, that’s often with the bigger decisions. That’s where I rely on is someone in a mastermind. What other thoughts do you have here for Mr. Manfrin?
Mike: It’s interesting that this question comes out because I just talked about it. It’s very easy to run into that situation where you are not sure what to do, so you wait and you second-guess yourself. You don’t do the work because you’re second- and third-guessing your design decisions, thinking that if you look at the problem more or you try to gather more data is going to help you in some way shape or form, and it usually doesn’t. I think that’s a very different problem than not having motivation, whether it’s intrinsic or extrinsic. That’s a different problem than being in a situation where you second-guess yourself and you’re not sure what to do, so you try and gather more information. I think those are two completely different problems.
Rob: I agree. He says, “How do you stay on task when you have no external motivation?” I definitely had time especially when I start to burn out, or when I’m feeling depressed, or when I don’t get enough sleep, there are seasonal times when it’s dark outside and cold and stuff, where I am unmotivated to do things, and I really struggle just to stay on task. Those are the times where I strategically break out caffeine, I turn on bright lights, I turn on loud music. I use all the sensory options that I have to try to get myself into a zone. I try to get into a routine where when I hear this playlist start or when I hear this single song and listening looping start, that I force myself to get in and do things. Now, the nice part is it’s probably been a year or more since I felt that way, but I’ve gone through months and months of stretches of that. That’s how I do it.
He’s also then asking, he’s spiraling out second-guessing design decisions, getting paralyzed with choice and scope. This does tie into that first question or first proclamation that Justin made of how do you make these decisions and not get paralyzed with choice. That’s where we said this is hard, it’s gut feel, you can undo things later. I think a lot of us as developers don’t want to make the wrong choice because we feel like we’ll have to rewrite all this code. Refactoring’s a pain in the butt and if we make this decision decision in the database, then we’ll never live it down, never be able to correct it.
While it will be painful to correct, these things are reversible. That’s where I tell myself actively if I find myself being hung up and for the first thing is to identify that you’re doing this, and being like, “I’m not being productive right now because of this, because of this decision, or this item in my Trello board, or this email. Why am I not doing that? Am I stressed about it? I just don’t want to face it, am I scared that I’m going to make the wrong decision?”
There’s a bunch of things that I will try to identify and then I’ll say, “Okay, if I’m stressed about it, then why? And then why? And then why? Keep asking the whys to get to the true source of it, to figure out if I’m actually stressed, or if it’s a design decision then I will either think to myself like, “Well, I’m going to call up XYZ person, who I know has a great design and usability sense, and I’m going to ask for 15 minute of their time and say, ‘Can you help me with this?’ so that I have some sense of calm about the decision.” Or maybe I just make a gut feel, I go forward, and hope it’s the right decision.
These are tactics that I would use trying to get other people involved. I do think Ken Wallace’s suggestion of having a mastermind so that you can bring these things to people on a regular basis, is a good one. Can of course run MastermindJam, which matches people up in the startup space into a mastermind.
Mike: But I think that those are also with two different pieces. One was recognizing it and then two actually addressing the problem. I think the recognition of it is something that tends to take much longer than it probably should for most people. I found that myself. I mentally know that I’m not making progress on something, but I don’t necessarily allocate time to analyze my productivity at noon, for example. I don’t have 15 minutes of this to decide and say, “Am I making progress today? Am I doing what I expected to do? Am I procrastinating doing stuff or just not doing things because I don’t want to or I’m afraid to make mistakes?”
I think the identification pieces, the part that creeps up on us, and it last fast longer than it should if we aren’t on the lookout for it at all times. What I do, for example, I do a lot of journaling. I have an app that sends me an email and says like, “Hey, write into this little thing here and you can explain what your day is supposed to be like,” for example. I do that on a fairly regular basis. I’d say probably at least three or four, if not five days a week. Then I will notice the following day if I’m not making progress on something because I’ll be a little annoyed, usually my sleep will be suffering, and I’ll say, “Oh, I didn’t get a good night sleep last night because I was thinking about this,” and it makes me think about that stuff.
So, it’s kind of a forcing function. That’s something that people can think about. I won’t say journal your way out of it. I don’t look at it as full-fledged journaling. I might write a couple of sentences or maybe a paragraph or two. It’s usually the stuff that bothers me and that just brings it to my attention. Maybe if I start writing a lot, I know that I need to pay attention to it, maybe take a step back, but otherwise I could easily go a couple of weeks or a month or two without really noticing, and then all of a sudden it’s like, “Oh I’ve burned two months and I’ve got nothing done.”
Rob: That’s a good point. The faster you get basically knowing yourself at noticing that you’re having negative thought patterns, or negative behaviors, or behaviors that are causing you to procrastinate, or go in circles or whatever, the faster you’re able to do that and identify it, the faster you’re then able to actively attack it, get through it, and make progress. I think this is something that all of us struggle with in one form or another and I think this is something that you get better at over time if you focus on it.
This is so much of what my wife, Sherry, does on the ZenFounder podcast and in her writings and such, is looking at how these thought patterns come about, how to identify them, how to get through them. I’ve been saying for quite a while that I think 60%–70% of entrepreneurship is mental. I think more than half of entrepreneurship is purely just dealing with your own psychology, your own things, that self-sabotaging behavior, procrastination, whatever it is that you struggle with, if you can learn to overcome that, you will have such an easier time and make so much more progress so much faster.
I’m saying this from personal experience, that getting into you own psychology, whether that’s with a spouse, or a mastermind, or trained professional who is either a therapist or business coach or whatever, I think it’s invaluable. Thanks for the question. I hope that was helpful.
Our next question is from @GregDigneo on Twitter. He says, “My question revolves how you and Mike manage your time. Rob you’ve built and exited a company. You guys are both parents, you run a conference, you have the podcast, you write books. My loose question is, what is your day/week look like?” He’s asking in a couple of different ways. It’s like, how do you manage your time and what is a typical day/week look like? I think he’s probably looking for the days or the weeks where we’re more productive, not the ones where I stare at my computer for three hours, don’t get anything done, and then just wander off to go for a walk because I realize I’m not actually focused.
Mike: I tend to look at it on a weekly basis. My week’s, for the most part, are pretty similar. I work from home and the weeks that I tend to get screwed up is when the kids are home from school. Let’s see here. If I’m starting on Monday, Monday is usually my heavy work day, so I have it blocked off from my calendar. Even if somebody wants to schedule time with me using Calendly, they simply can’t. I have a hidden calendar that I can send them a link if I really needed to talk to somebody on a Monday, but typically I don’t hand that out to people and it’s usually on a case-by-case basis.
Tuesdays is not blocked off but I tend to get a fair amount of work done on Tuesdays as well Monday. I usually will work late, so seven or eight o’clock at night just because I tend not to have anything else going on. Tuesdays is a little bit lighter. In the evenings on Tuesday night, I have a D&D game that I play every week and then Seeker Wednesdays, I probably do less work. On Thursday, I do less work. Fridays, I try to get things done and set up for the following week. Saturdays, do a bunch of stuff around the house and take the kids to whatever they have, music lessons, or soccer, or what have you. Saturday night I have another online D&D game that I play and then Sunday is usually do whatever, usually cleaning up around the house and stuff like that. My week is pretty straightforward for the most part. How about you? Do you do it on a daily basis or a weekly basis?
Rob: I tend to think about things on a daily basis. Most of my days are different from one another. Sherry and I collaboratively home school one of our kids. He’s older, he’s almost 13, so it’s not like we’re sitting there teaching him stuff. He’s online taking courses, making progress on his own, and then we just have to monitor and poke in.
Some of my days I’m on and I know I can schedule fewer calls that day because I don’t want to be interrupted, and then other days I’m just completely focused on work. I look at it at a day-by-day basis. What I’ve noticed about myself is that I used to code. When I was writing code, I could sit and write it for 12 hours straight. I used to do that. That was actually my optimal way of functioning is to sit down, get momentum, break very briefly to eat or use the bathroom, and then get back. I would do 12-, 14-hour code days and get two or three days worth of progress done in that amount of time.
I don’t know if it has since I’ve gotten older or if it’s that I don’t code anymore because the coding was a very logical left brain. There’s some creative in it, but compared to what I’m doing now where I’m actually actively producing content, having to think things through, and these higher-level decisions, they’re a lot more taxing on my good glucose, so to speak. There’s only so much good brain functioning that you can have.
Writers who write books, Stephen King, these highly productive writers, they don’t write for 10 hours a day. They tend to get up, write in the morning between three and four hours tops, and then they spend the rest of the day doing other things because there’s only so much good focus you have.
Now, what I’ve found is that I’m highly productive in short bursts of, say, one to two hours. I try to have a forcing function that forces me to stop, because if I don’t, I will tend to just work two, three, four hours straight, and I feel my productivity just descend over the subsequent last one or two hours that I’m working. I have different forcing functions. Oftentimes, it is a child getting home from school or I take two of the kids to Jiu-jitsu. It’s only about an hour that we’re sitting there and I get so much done in that hour. And it’s the worst working conditions. It is terrible. I’m hunched, I have no plug, I have no chair. I’m literally hunched against the wall like I’m in junior high gym or something. I’m sitting almost like Indian style with my back to the wall, terrible posture, I have a laptop there, and I get more email done in that 45–60 minutes than I do two hours sitting at my house. I have no external monitors, I have nothing. It’s loud but there’s something about that space and the fact that I know my time is so compressed that I just hammer through to-dos and I hammer through emails.
That’s just one example but I have a bunch of times like that during the week that I’m finding there’s kids’ music lessons, there’s other things where I find that if I force myself to only have this much time, that I get the work done faster. That’s kind of a personal hack that I’ve been doing lately.
I think another thing is these are low-level how to get things done quicker on a higher level. I say ‘no’ to everything except for what’s on my goal list for the year. If you look at running a conference, you and I just do that. That’s on the to-do list. I feel like I’m pretty efficient about it, I feel like I focus on it when I need to, and then I make it a priority. The podcast is something that we’ve essentially automated almost all of it. You and I show up for two hours every other week and that’s two episodes. We walk away and the next two episodes go live. We don’t do anything else. We’ve automated, we paid for years. Since 10 episodes in, we paid for an editor who post the episode, who writes the show notes, who does all that stuff.
Writing the books. When I’m going to write a book I will make that a priority and I will work on it everyday. If I was writing or revising my book right now, I would probably do at least an hour of that once a day and then I would continue to do my other stuff. I wouldn’t say ‘yes’ to a bunch of things. I say no to some interviews. I say no to a lot of opportunities to jump on a call with someone to explore this or that. I say no to speaking at some conferences. Not all, but if I don’t think it’s a valid use of my time, I save the two travel days and the time to write the talk and all that. I push that towards things that I feel like are my highest priorities, that are in my goals, and things that hopefully will bring the most value to me, but also most valuable to this community that we’ve built and more value to more people.
That’s something else that I had to tone down is I don’t do as nearly as many as one-on-one things because I find that I can be more valuable by writing a book, or recording a podcast, or writing a conference talk that is going to be distributed to thousands or tens of thousands of people. I also don’t like things that are ephemeral, things that don’t stick around. To me, a blog post is better than a tweet because a tweet’s gone. A book is better than a blog post because a book sticks around for a long term. This is a lesson I that I’ve learned over the years is to focus on those things that help more people, that stick around longer, that have deeper meaning, and that bring more value to both yourself and people that will be consuming it.
That was a longer answer than I thought. It was more than I had thought to say on that topic but I think that was a good question. I think at a higher level it’s about priorities and saying no to everything else, number one, and then number two it’s about staying motivated over the long term, showing up every day, and getting […] done. Relentless execution is this phrase that I’ve used. It’s a personal moniker that I have adopted. Relentless execution.
That doesn’t mean you go crazy and work 20-hour days. I haven’t work more than 40 hours a week during the decade. There may have been these short stints like when I was revamping HitTail. I worked 60-hour weeks for about six weeks and then I pair back. To me, a 35- to 40-hour a week schedule is ideal, sometimes 30 depending on the season of the year, but I find that I get more done when I actually have shorter weeks and I’m forced to make quick decisions and get stuff done.
Mike: I do as well. You know at the back of your mind that you have as much time to work on something as you want, when you can just take as much time as you need, then it will take forever. I think it’s, what is it? Taylor’s Law that the amount of work will expand to fill the available time. I find the same thing. I will hold off on making decisions because I know that I have time to ruminate on it, or I will take longer to do something just because I have the time available. That’s actually what makes my Mondays a little bit tough is that, because I get myself a lot more time on that day, sometimes I’m not necessarily as productive. Then I find that sometimes on Tuesdays I will be more productive even though I have less time available to me to do work.
Rob: I can totally see that. To come back to Greg’s question, he says, “What is your day or week look like?” I feel like everyday for me tends to be different. I do like hitting things hard Monday morning by getting up and I ask myself the question, what has to get done today or what has to get done this week? What will move the business forward the most?
When it was Drip it was like, “Well, it’s getting everyone on the whole team on the same page and getting this decision made about what feature to build or this big deal we’re trying to close.” Now with TinySeed, it’s choosing the batch and it’s getting that forward. Those go right to the top of the list even if I get in my email box and it has 50 things, the things that are on the topic of what I have to get done that day, I skim through it. I take care of all that stuff first and everything else is on the side.
I would say that my days probably don’t look like you think they do. I start work a bit later than you probably think and I end it earlier that you think. I didn’t used to do that. Again, I think that’s where we’re coming back to is forcing yourself to get stuff done on a shorter time frame. It comes back to the cult of the Silicon Valley startup hours where they’re like, “I’m working 80-hour weeks or 90-hour weeks,” or whatever.
Your productivity plummets. There been a bunch of studies that have shown that it plummets after 40, 50, 60 hours a week. They’ve done it in construction, with construction workers when they go to 610s and 710s. When you were estimating those jobs, you have this major markdown factor. There’s books published by the electrical contractors who say, “These are guidelines and it will drop 30% over 50 hours and it drops 40% over 60 hours. It’s not just for those last 20 hours. It starts to fatigue and then your entire 70 hours that you’re working become 60% as effective.
It’s this crazy thing and that’s where the Silicon Valley startups who say or the founders who say, “Oh, I’m just working all these hours.” I’m always thinking, “What are you doing? What are you actually accomplishing during that time?” I find that I’ve been able to get quite a bit done in my career and my life. I don’t do that, really never have, even when I was coding. When I talk about coding, there’s 12- or 14-hour days. It was my early 20s, we had no kids, and what I would do as a contractor-consultant I would code that long day and I take the next day off.
It wasn’t that I was working long weeks. It was that I prefer to batch my work into a single stint, so to speak. I felt like it was more productive once I’ve got everything loaded up into my head—the mental model—I hated stopping and losing all of that, and had to regain that the next time that I sat down.
Mike: I would agree with that. I do wonder about some of the studies and stuff where they say, “Oh if you’re working more hours, then it’s not as good. You’re not nearly as productive.” I do find that there are times when you just get into a rhythm and you’re in the zone. If you break out of it, take breaks and shorter days or something like that, it’s kind of hard to load your brain up with all the stuff and all the little details that need to be there in order for you to get certain types of work done. I’m not necessarily saying that it’s broadly applicable, but there are times especially when it’s coding, taking a break is extremely disruptive. It’s so much easier to just down there and bang that stuff for four or six hours or eight hours, and if you’re still being productive then there’s not a great reason to stop except for those forcing functions.
Rob: Thanks for the question, Greg. I hope that one was helpful. If you want to connect with Mike or I on Twitter, I am @robwalling and he is @SingleFounder. I feel like that probably wraps this up for the week, Mike.
Mike: I think it does. If you have a question for us, you can call 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 We’re Outta Control by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for ‘startups’ and visit startupsfortherestofus.com for a full transcript to each episode. Thanks for listening and we’ll see you next time.