Launch Now

If you had to launch your thing in just two weeks what would you cut out? Put off anything you don’t absolutely need for launch. You can always build that stuff later when you have more information. It’s best to just get it out there!

Show Notes

• 05:06 - The Screener
• 07:22 - HEY World

Transcript

Shaun Hildner (00:01): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Shaun Hildner, and as always, I am joined by 37signals co-founders and the authors of REWORK. Jason Fried, how are you this morning?

Jason Fried (00:15): I’m okay. How are you, Shaun?

Shaun Hildner (00:16): Wonderful. David Heinemeier Hansson, how are you this afternoon?

David Heinemeier Hansson (00:21): Good, good, good.

Shaun Hildner (00:22): Good. Well, the title of this episode is probably going to spoil this answer, but when is the right time to launch your new product?

David Heinemeier Hansson (00:30): Now, now.

Jason Fried (00:33): Yesterday, yesterday is probably slightly more accurate answer. It basically, probably before you expect, before you imagine it to be done. I think there’s a sense that things have to be just right, just perfect. There’s all these things everyone’s going to notice that you haven’t done yet. It’s probably not true. You could probably launch a lot earlier than you expect. Quality should be there. The things you choose to do, should be quality, but you probably don’t need to do as many of the things that you want to do, or that you think you need to do.

Shaun Hildner (01:06): Do you want to start with this famous story about launching base camp without any way to bill for Basecamp?

Jason Fried (01:12): Yeah. When we first launched Basecamp in 2004, we had prices. It was like what, I think, 19.39, 59 or something like that per month, depending on the tier you were on. We’d be happy to get you to sign up and get your account ready, but we couldn’t bill you. We didn’t have a way to bill you.

Shaun Hildner (01:31): Were you even collecting credit card numbers?

Jason Fried (01:33): No. Basically, the reason why, and there’s a few reasons why this happened, but fundamentally, the interesting thing is that we couldn’t bill you. That gave us 30 days to build a billing system. When you only have 30 days before you want to get paid, you make it work in 30 days. It could have taken 90 days. It could have taken 120 days. We wanted to get paid in 30 days, so we built something in 30 days. What was interesting was that the initial idea for billing Basecamp was billing annually. That’s what we wanted to do, but our bank, our merchant account provider wouldn’t allow that because it was too risky. They wouldn’t let us charge a customer, let’s call it 500 bucks for a year, because they didn’t know if we’d be in business in three months and then they’d be on the hook for it.

Shaun Hildner (02:18): This is pretty early on in the idea of paying for software on a monthly basis.

Jason Fried (02:23): It was not really something people did.

Shaun Hildner (02:26): Yeah.

Jason Fried (02:27): They essentially pushed us to bill monthly. That’s how that whole thing came to be. That’s why we had to change things and scramble at the last minute.

David Heinemeier Hansson (02:34): But I think it’s also interesting to look at just the raw feature set of the first version of Basecamp. There’s no way to share files. We did not have file sharing. You’d think such a fundamental part of collaboration is file sharing, but we started when we began building Basecamp at the epicenter, which we thought it’s communication. It’s basically having posts, and having comments on those posts. Then we rolled into … Well, the to-dos are really crucial. We launched with far less than what you would think would be necessary to do it, but I think part of the angle here too, is whether you’re competing with something that already is, because HEY launched late, compared to this recommendation, to some extent, in the fact that HEY competes with something very established, email, clients and services. The bar is set by something like Gmail is quite high, versus when we launched Basecamp, we were competing against non-consumption.

David Heinemeier Hansson (03:41): I think this is one of those times when it’s really good to stress that when you have the opportunity to compete against non-consumption, that is not other software providers who are trying to target exactly the same problem as you’re targeting so that you have to match in the eyes of prospective customers their feature set, you have much more leeway to launch with less, far less than you think. But even if you take something like HEY, we did not have signatures, for example. We did not have vacation responders. We did not have a bunch of features that are considered table stakes for an email product. We could have spent another year. It took over a year to build a bunch of those things, but the proof was in the pudding. What we put out was blue ocean enough, if you will. It was enough new novel stuff that existed in that realm of like, “Oh, I’d never thought that was something I wanted to buy,” that it made up for the fact that there was a bunch of things missing.

David Heinemeier Hansson (04:47): I think that the knowing what you can miss is directly correlated to what do you bring to the table that’s novel? I think that’s what I like about this launch now thing. Something has to be really worth it. With HEY, we had a handful of features, like the screener, for example, that comes out totally out of left field. No one’s ever really done something like this on a major email product. That was enough for a lot of people to seem to go like, “I need that thing. I’m willing to give up a bunch of other things.”

David Heinemeier Hansson (05:17): We’ve talked about the Tesla sample in the past, where they’re like, “Hey, this is a car that runs on batteries. I want that. I want the battery car with the computer, the big computer screen in it. I’m willing to give up fit and finish. I’m willing to give up a bunch of normal car things.” I think this helps you steer you in that direction, and also just gives you permission to do something sooner with less money. Launch now is partly, hey, if you’re going to launch quickly with not a lot of people, you can do it for much, much less.

Shaun Hildner (05:49): Sure, sure.

David Heinemeier Hansson (05:50): You don’t need to raise a bunch of money and all the other things

Shaun Hildner (05:52): Going back to that, the Basecamp and billing example, because you didn’t have to spend the time before launch building out billing, or you decided not to build out a way to bill people, what was that time and energy spent on?

Jason Fried (06:05): Well, I think you could say it wasn’t spent. I’m sure we did other things also, but the real answer is it wasn’t spent. It meant we could launch in February of 2004, instead of March, or instead of April, or instead of May. I think that’s really the way to look at that thing. It’s not like, if you save time, you have to put it somewhere else. You can also just not use it. That I think is the deeper benefit here that we’re trying to get to, is the sooner something’s out … Again, it can’t be shitty, but the sooner that it’s out, the more eyes you get on it, the more people start to find out about it, the more acceleration you get from it, the more you learn about it yourself, the more customers tell you about it, the sooner you can tell if it’s going to work or not. You need those answers. The longer you wait for them, you don’t have them. It sounds ridiculous, but you don’t have them and you need them. That’s what you do with the extra time, is you get the thing out.

David Heinemeier Hansson (06:54): As entrepreneurs, as product builders, you should always have more ideas. There’s always just that one more thing you can build, and then there’s one more thing after that. This is a way to cap that, by saying, “Do you know what? If you’re not uncomfortable by the time you’re launching, it’s way too late.” To give you permission to say, “Ah, I think we really need this thing.” We were like, “No, just go.”

David Heinemeier Hansson (07:16): I’ll take another example from HEY, which was when we launched HEY World. HEY World is this, essentially, newsletter blocking service that we attached to HEY. Jason and I basically built it in just under two weeks. There’s a bunch of stuff that, at the time we were building, we’re like, “Oh, it’d be really nice to have that. It’d be really nice to have that.” We had a long discussion, for example, about how do we need to deal with content moderation? How do we need to deal with if bad content is posted? You can scare yourself into not launching forever, because there’ll always be some risk factor. There’ll always be some edge case scenario you can envision in your head might plausibly happen, and if you try to prepare for every contingency, before you leave, you got to ship containers of stuff, and all you need is a damn backpack. What fits in the backpack is what you leave with, not all the shit you could fit in 50 containers.

David Heinemeier Hansson (08:16): That was one of the things, even internally, at Basecamp, when Jason and I were almost making a point to ship this uncomfortably quickly. Let’s just run to launch. Rush to launch. A bunch of people were like, “Ah, I’m not sure about that. Here’s all these reasons why that might not work,” and so forth. We launched it. In that particular case, none of it mattered. Even the time we had spent on the content moderation thing, and we had spent some amount of time deliberating over, that was totally freaking wasted. Never had a problem with it. It doesn’t mean it’s not feasible. A problem could occur in the future, but clearly that wasn’t something we needed to do to launch now. It’s one of those things that’s actually so much easier to do when it’s early and the people building this stuff are also the people whose ass is on the line, in the sense of the business. It’s more reasonable for you to accept some risks here, launching now and launching with things that might go wrong. Eventually, some of those things are going to go wrong. Eventually, you’re going to guess wrong on some of it. Some of it’s going to come back to bite you.

David Heinemeier Hansson (09:24): I think the bigger a company gets, the harder it gets for the people who are working on it, but aren’t responsible for whether the thing fails or not, and don’t want their ass on the line for it. There’s a reason why you have that whole term, cover your ass, is because you don’t want to be in the shooting line for it. But, when Jason and I were building something like HEY World, we could just do it fully, like startup early day style. It’s just a great reminder that it’s possible to build something like HEY World in two weeks, which ended up being a great success, and thousands and thousands of people posted to it. It’s been a driver of signups and all these other things, basically just doing 5% of the work.

Shaun Hildner (10:03): I love this thought experiment that you lay out, and this kind of relates to that. If I only gave myself two weeks to launch, what would I cut out? Is that still the way that you develop?

Jason Fried (10:14): Yeah. There has to be some point that is mostly fixed. You can bend that sign a little bit, a day or two, it can be a week, but it has to be in the ground, otherwise, the instincts will be like David was saying. There’s always one more thing to do. There’s always another idea you can do. There’s always a way to make it better. There’s always this thing you forgot to do. There’s always this edge case you picked up in the last five minutes that you need to deal with. New ideas should and will continue to come at you if you’re thinking about this stuff. It’s never going to end. You have to work against your own nature. Although, you could say sometimes your nature is like, get this thing out the door, but really, what’s really pushing against you are, there are always more ideas. There’s never enough time. Why not make time?

Jason Fried (11:01): Well, that’s the problem. You make time, this thing never gets out the door and it pushes other things away. I think the other thing to keep in mind is, time is, in this case, sort of like a conveyor belt. It pushes everything else too. It’s not like … Time doesn’t really happen in a vacuum. It can if you have dozens of teams working on things in parallel. Most companies don’t. Most people have something going on, and if they’re doing this, they can’t do something else. Thinking about time in that way, this is actually very costly. If we keep pushing this out, we’re pushing other things off. That’s a nice way to start to think about it and go, “Is it worth it?”

Shaun Hildner (11:38): Jason, you were saying that you can’t make it shitty. How do you make these cuts, and how do you push this deadline without sacrificing quality?

Jason Fried (11:45): Well, you can make it shitty. That’s a sliding scale. It’s like, what does that really mean? Of course, one thing we talk about internally a lot is, and this is always a debate, which is what degree of fidelity matters in this case, on this thing? Objectively, you could look at something and go, “It’s not high enough quality because it doesn’t do X, Y, or Z,” but you might also go, “In this case, it doesn’t really matter. Let’s put the X, Y, and Z on this other thing instead.” It’s a debate, and a discussion, and a conversation for every piece. Some stuff’s obvious. Some stuff’s not. Some stuff there’s miscommunication.

Jason Fried (12:26): David and I have been debating this one feature for a few weeks, on what level of fidelity should apply on certain things? We have a different point of view on it. Some of the stuff, you just debate, and some of the stuff you just decide not to do. Some of the stuff you decide to do. There’s not a process you can throw something on to get the answer, other than debating, discussing, making cases, and then also being mindful of time, because debating and discussing takes time too. Sure, it could take three or four days, and then you just burn three or four days. Maybe you only had two weeks then, and then you just can’t do it. That could be worth it too.

Jason Fried (13:03): That happens sometimes. It doesn’t happen that often, but it does sometimes. That’s just one of the trade offs you have to live with when you have a living, breathing product that different people have different points of view on it. Time’s a factor, and talent’s a factor, who’s around, who’s available to do the work. Again, it’s a very messy process in reality, which is actually, that’s funny. I was talking to someone about this yesterday. Brian, who’s helping head out product strategy here, he was saying that he loves reading these long … Sometimes, companies put out these really long case study posts of how a project went. I love reading those too, but I think they’re probably 90% bullshit, because what actually happens is a lot messier. We had this beautiful discussion, and this sketch went to here, and this insight came, and we built this thing. That’s all part of the story, but the real story is it’s messy. You don’t really know. You kind of think something’s going to work. You get in an argument about it. You debate something. You agree on something. You do it and you still don’t like it. There’s a lot of stuff that goes nowhere, goes sideways. That’s kind of the real work, is really more like that. It’s really messy and dirty, ultimately. You end up with something that’s good in the end, but it’s not these beautiful narratives.

Jason Fried (14:20): The narratives to me are the retelling of the story after the fact. You’re going to tell the good version of the story, but if someone had a camera over your shoulders, it’d be … It’s actually interesting to watch. The Beatles documentary, I think, was a pretty good example of that. It’s pretty boring, pretty messy, pretty slow. Things go nowhere. Sometimes, there’s a breakthrough. It’s not this beautiful process.

David Heinemeier Hansson (14:45): I think the other factor here though, I like to distinguish between fidelity and quality, in the sense that quality, for me, when we talk about it internally, is it well built? You have a target. Fidelity is what the end user sees, and how it works, or is it smooth, or something, but under all those degrees of fidelity is a process that built that. It’s the back of the cabinet stuff. Do you just throw the components in there and just like, “Eh, we’ll fix it in post. We’ll fix it some other day. We’ll fix it later.”? No, totally willing to move the dial in fidelity. I think actually that fidelity dial is one of the most important ones for our productivity, because, at least as a product decider, if you will, it’s easy to just say, “Just make the best of everything.”

David Heinemeier Hansson (15:39): There’s no skill in that. “Give me a hundred percent. Make it the very best of the best.” There’s no skill in that. Everyone can say they want the best of the best. The skill is in figuring out when it matters. There’s some interactions where you want the best of the best, because that is just a crucial point that defines the whole product, or it’s the feel of it. Then there’s just as much skill in realizing when, “Meh,” will do. It’s something that you do very rarely. It doesn’t matter at all. It’s not part of a main flow. It can be very low fidelity, and no one gives a damn that it’s low fidelity. If that’s the case, you get to build something for 5% of what it would cost to build the high fidelity diversion, but both of those version, the 5% version and the 100% fidelity version comes in proper quality or not, in terms of the implementation. In terms of how you approach the work. Is your competence apply to it?

David Heinemeier Hansson (16:39): This is one of the reasons, for example, I love cheap cars, in the sense of a very low priced car. Someone had to make a bunch of very hard decisions about how to spend two extra dollars on that knob. There’s some pricing person who’s sitting there, “Do you know what? This slightly nicer knob is $2.15 and we can get one that’s a little crappier that’s a $1.95.” You have to add all this up. There’s 5,000 parts in a car, and you want to sell it for $18,000, or whatever it is, on the low end. Those are hard decisions. They’re exactly those kind of decisions, “Does it matter? Is this the thing they’ll notice? Or will they notice this other thing? Is it the quality of the leather of the steering wheel and we could get way with some scratchy plastics in the trunk or something?”

David Heinemeier Hansson (17:33): There’s real skill to that, far more so, in my opinion, often then some super car where there’s, cost is no object. We will just build the best of best. That’s also worth appreciating, but to me, there’s far more skill in figuring out exactly, how do you put a $18,000 car together? Again, the Tesla example. Elon is targeting, is it 25,000 or something? You’re like, “It’s not there yet. We can’t make it yet because the number of compromises we’d have to make to get there. It’s just not possible,” but you can just imagine sitting in on those discussions is like, “Could we save a hundred bucks on this?” People would be like, “I don’t know. I don’t know.”

David Heinemeier Hansson (18:12): This was the same thing. Again, that example, the car comes out and traditional car makers go, “This is a totally crappy car for $40,000. They traded off all these other things we would never make the trade ups.” That’s what’s so interesting. This is what differentiate products of all kinds, that all these trade ups needs to be made when you’re trying to sell something in a market, at a given price, to a given consumer. That really is what product management and stewardship, and design, at the end of the day is. There’s just such a huge variety because you can turn on all these million dials, but for me to be happy at work, wherever those dials end up, implementation has to be good. Can’t do crappy work.

Shaun Hildner (18:53): Well, perfect. I think that’s a pretty good place to stop. Can we pop open the old listener mailbag for a second? Let’s do it. This week, we have a question from Mark.

Mark (19:03): Hello, Shaun, and Jason and David. I have a question about QA, and the quality process for you. You’ve spoken before about having one designer and one developer on a team working on a feature. You’ve also talked about not being proponents of strict TDD, so where does quality testing come into your process?

David Heinemeier Hansson (19:27): Great segue from what we just talked about. We only ship good software, in the terms of well built software. At all levels of fidelity, but well built. To me, that comes down to a level of confidence. Do I have confidence that the criticality of what we’re working on right now is going to land in the hands of customers and be good? What do we need to get to that level of confidence?

David Heinemeier Hansson (19:57): It’s funny. Jason just mentioned this at a product discussion we were having. We were going back and forth about elements of it. One of the elements is this live updating field that takes data and saves data. This is one of those things where I look at that and go like, “That’s actually quite high criticality.” If you’re taking live data in and you can have it open on multiple devices, you could potentially overwrite data. You could lose data. That really matters. Versus, for example, presentation of data. Let’s say there’s data that already exists and you’re looking at a screen that’s presenting that data. Maybe the presentation is a little off. You can fix that bug, and no data is lost. No data is corrupted. That is lower criticality, so I need less confidence to do that. If I need less confidence, I can write fewer tests. I can put it through a shorter QA process, versus when we’re doing things that mutate data, or otherwise deal with very sensitive stuff, we do a much longer process. We have not only just a QA person, we also have a QA firm that we work with externally, and we apply more of that. The higher the criticality is, and the higher the level of confidence that we want to have before we ship.

David Heinemeier Hansson (21:08): But it’s just like the fidelity thing. I worked on a handful of features a few weeks ago, where we shipped three things in four days. They were all low criticality. I turned the process dial down to zero. There was no explicit QA process. We didn’t involve the outside firm. We didn’t do all of those things. I just tested it to a level of confidence where I’m like, “It’s not going to break as soon as we launch it because I haven’t looked at it at all,” but if there’s a minor issue, whatever, I’ll just fix it. One of the three had a minor issue, and I just fixed it, and I pushed it. I think that comes back to that, are you fluid enough that you can vary your process? If you are, you can get so much more bang for your buck, but the bottom line is, it’s got to be good. Good is a derivative of the confidence you have if you are a competent builder.

Shaun Hildner (21:59): Well, awesome. I think that is a fantastic place to stop. Thank you, Mark. If any of you out there have questions for Jason and David, leave us a voicemail at (708) 628-7850, or better yet, record a voice memo on your phone and email it to hello@rework.fm. That’ll do it for this episode. Next time, we’re talking about the illusions of agreement. I will see both of you next time on REWORK. For now, I want to say thank you to David Heinemeier Hansson.

David Heinemeier Hansson (22:30): Thanks Shaun.

Shaun Hildner (22:31): And thank you, Jason Fried.

Jason Fried (22:33): Thank you, Shaun.

Shaun Hildner (22:34): We’ll see you next time. See you then.

Shaun Hildner (22:45): REWORK is a production of 37signals. Our theme music is by Clipart. We are on the web at rework.fm, where you can find show notes and transcripts for this, and every episode of REWORK. We’re also on Twitter at REWORK podcast. If you’re following along in the book, next week, we’ll be discussing the chapter, Illusions of Agreement. If you like this show, I’d really appreciate it if you would leave us a review on Apple podcast, Spotify, Overcast, or wherever you’re listening to this.