Quick Wins

Building and maintaining momentum is one of the most underrated things you can do when building products. Keep moving forward by shipping work early and often. The longer something takes, the less likely it is you’ll finish it. At 37signals, we work in six-week cycles, but even six weeks is a long time, so pepper in some easy, quick wins to keep that momentum going.

Show Notes

• 01:23 - The Six Week Cycle (Basecamp 3 Help)
• 02:50 - Jason Zimdars
• 06:57 - Sean Mitchell
• 06:59 - 37signals.com
• 07:12 - basecamp.com
• 10:18 - There’s no speed limit - Derek Sivers
• 12:28 - Goldilocks Zone (NASA)
• 18:14 - Setting the appetite (Shape Up)

Transcript

Shaun Hildner (00:01): Welcome to REWORK the 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, David Heinemeier-Hansson. How are you today?

David Heinemeier Hansson (00:13): Well, I was about to say great, Shaun, but then I realized that’s just a thing you say in America. I’m actually not great. I’m kind of shit. I have a cold, but here we go. Let’s go.

Shaun Hildner (00:22): Oh, I’m sorry. And welcome, Jason Fried. How are you?

Jason Fried (00:26): I’m in America. I’m great.

Shaun Hildner (00:31): This week we’re talking about getting those quick wins. And to start off, I think maybe can you explain the importance of momentum and especially how you build up momentum and how you maintain it?

Jason Fried (00:42): I think it’s highly underappreciated and incredibly important actually to just keep moving forward. Every time we, I think, over debate something or something takes too long or whatever, you just sort of get stuck. When you get stuck, indecision sneaks in, more opinions sneak in, more reasons not to do something sneak in. And it just gets frustrating. Then I think at some point you also start cutting corners because then you just want to get it done. And a lot of things start to fall away, I think in a bad way, when you just aren’t making forward progress.

Jason Fried (01:16): So this is one of the reasons why we do the six week cycles because you’ve got to ship or move on after six weeks at the most. This is about momentum. It’s about other things too, but a lot of it’s about momentum. Otherwise, you get stuck in a project for six months and there’s I think few things are more demoralizing than being stuck on something that just has no end in sight. So it’s not just really, really, really quick wins. It’s all wins, I think, just need to happen sooner rather than later so you can move on to the next thing and keep that pace up.

David Heinemeier Hansson (01:49): The funny thing is for us six week is a long slog.

Shaun Hildner (01:56): It’s like… That’s a long project.

David Heinemeier Hansson (01:56): Oh man, that’s a huge project. When I talk to a lot of people, they mean, “What do you mean you ship work in six weeks with two people?” I give, “What do you mean you don’t?” There’s just so much work that we do where I look at six week, and I go like, “Holy shit, that’s a long time.” And I get just so impatient. So that sense of momentum to get things rolling sometimes I need the fix of shipping. I think this is something that’s one of the few things that’s okay to be addicted to as a product maker, especially as a software maker, be addicted to shipping.

David Heinemeier Hansson (02:27): And I just get antsy if we haven’t shipped, if we haven’t done something that hasn’t improved the product, if we’re actively working on it. I think a good example of this was I think it was last cycle maybe where I hadn’t been programming for a couple weeks prior, and I was antsy. And we were working on some six weekers, and then I teamed up with one of our designers, JC, and we just took like, do you know what? We need to ship something? What can we ship quickly? Okay, in HEY, download all attachments.

David Heinemeier Hansson (02:57): We had kind of tried to work on that one before, and then it turned into a long thing because we thought we had to do it a certain way. And then I just connected with JC. Let’s do something in three days. Can we do something in three days? Can we get it out? Boom, out. That level of energy that you, the distance between making a decision that we’re going to do something and then seeing it in the wild in three days or in some cases one day, it’s just intoxicating. It is what I live for when it comes to software. I mean not everything can be a quick win, but the things that can be, oh man, they just feel so great. And they’re so great to sort of pepper in there, to keep you going between the long, big things. Sometimes we’ll work on something that’s really important, but it takes six weeks.

David Heinemeier Hansson (03:40): And when we make the announcement, it sounds like it was kind of not a big deal. For example, that download all attachments. It was something else. I think we have another chapter that talks about a crowd pleaser. It was something that people had just been asking for a long time, and we knew we should have done it, but it didn’t make the cut, whatever, treated it like a quick win and then boom. Just get it out there. And people are like, “Oh, this is great.” And we get a lot of applause for something like that, which always feels good. But it’s about having that mix that you have your long sometimes grinds to get some important stuff done, but then you got to keep sort the clock frequents going, that something is happening, not just to the customers who are watching, whether you’re alive or not, but also to your sense of self. Can we do this?

David Heinemeier Hansson (04:24): Another great example was Jason and I did this review of the signup process in Basecamp, I think about a month ago or something. We’ve been talking about, Yeah, do you know what? We should do some things, maybe we should slim it down." We jump on a call. Me, Jason, and Laura, who’s in charge of customer success. We walk through the step, and really just pause at everything that we just go, is this right? Do we need this? Do we not need this? And after that call, we were just like, there’s not just a momentum here. There is impatience and motivations to make something happen. The conclusion we came out of there was we should just cut off this long wizard flow we had that was asking you a bunch of different questions for a bunch of different reasons we no longer really believed in.

David Heinemeier Hansson (05:09): And you could totally imagine that you reach a conclusion like that. You have a meeting, you go through a thing, and then you go like, “That is something we should deal with. Okay, let’s see. We, can.” You go through a calendar, “Two and a half months from now, we can put that on the schedule and we can assign someone.” Or we can just fucking do it right now. Right fucking now. This week we’re shipping on fucking Friday. That’s what’s going to happen. And that’s what we did. And I mean, what’s kind of funny about that is sometimes quick wins can be so quick that they’re disorientating. And that one was a little bit, right? It was me, Jason, and Laura. And there’s a bunch of other people involved in this process and so on. And we were just like, “Oh yeah, it’s live.”

David Heinemeier Hansson (05:46): You’re like, “What’s live?” The thing we decided five minutes ago is live. So there’s some trade offs here, but I think quick wins are just so important for motivation. And motivation is so important for progress and productivity because productivity is not a fixed. You don’t have 100 items of productivity. If you are highly motivated to get something done, you have 250, and you can just get so much more done. This was the thing on that quick win tear where we did the download all attachments. We also did contact groups, which was this other thing where you can quickly in HEY write to 10 people and you can say, and that came because of the momentum of the other thing. Suddenly we went from steady state productivity of 100, boom 250, we’re on a roll. We’re going, let’s do this thing, right/

Shaun Hildner (06:33): What about you, Jason, do you do something similar? Will you take a break from a more long term project to just get something out there?

Jason Fried (06:42): Yes, there’s definitely times when you do that. I think, it’s sort of funny, it’s like a self-care thing, all this talk about self care. It’s like we just need to ship something. We need to do something, need to move. So Shaun and I had been working, the other Shaun, had been working on the new 37 signals.com site, and we just shipped a new version a few days ago with some new nav and some stuff. And this has been sitting around kind of unfinished because we’re working on the Basecamp.com site, but that’s taking longer just because it’s bigger, and we’re doing 50 screenshots right now and just a lot of that. And there was just this welled up feeling of, we’ve been working on a bunch of stuff, and it hasn’t seen the light of day. Let’s do this for us. Let’s just get this new site out there for us.

Jason Fried (07:27): And so we took a day or two and just kind of tightened that up and shipped that I think yesterday or the day before. So now there’s some new nav in place. It’s not a big deal. It doesn’t really matter that much, but it mattered because we kind of took it across the finish line and got it out to the public. And now we can say, it’s done, done. It’s out there. We’re happy with it. And we can move back to finishing this other big, huge project that’s been going on for a while. So sometimes you just have to do that. You just have to do that. Same thing’s true about writing. I’ve got a couple topics on my mind I’ve been thinking about writing about. And I kind of want to write them in detail, but I think I’m just going to probably write three paragraphs and be done, and just get the idea out there because it’s like that’s enough anyway. And so writing is another place where you can do that. But yeah, I think it’s important, very important.

David Heinemeier Hansson (08:11): To me, it’s totally that. It’s a release valve. There’s like a tension that builds up inside if we don’t ship or if I don’t write. And then at some point I’m just like, fuck it. I got to do something. I almost don’t kind of care what it is. I mean I do. But a lot of it is just to exercise your human capacity, my human capacity as a programmer, as a product person, as someone who can ship stuff, if that capacity, it doesn’t atrophy, but it’s like, it doesn’t get exercised. Right? It’s kind of like you’re on a roll, you’re going to the gym, and then suddenly you take a six week break. And then you go back to the gym. It kind of sucks. Right? I don’t want to get to the kind of sucks place. I don’t want to get out of the rhythm.

David Heinemeier Hansson (08:53): As a product organization we should always be in the rhythm of shipping. We should always be in the rhythm of improving. And I think the other thing, especially as 37signals grows larger, I kind of feel like Jason and I have an obligation to set the realm or the horizon of what’s possible. How quickly can we ship things? Does it need to go through a long convoluted process every single time? No, it doesn’t. There’s a bunch of things where you can have an idea in the morning and that’s deployed in the afternoon. And then there are even more things that you can have an idea on Monday, and it’s shipped by Wednesday. And then in my opinion, there’s a 50% of what we do that is theoretically possible to launch within a week. Now that doesn’t always happen. Shouldn’t always happen because it’ll ship at a certain rate of completeness or whatever.

David Heinemeier Hansson (09:42): But Jason and I have an obligation to continue to show the organization that’s doable. Not only is it doable, it’s desirable. It’s possible. We can, I was about to say cut corners, but that’s not true. We’re just taking a straighter line. And it’s just that a lot of the obstacles you imagine are just that imaginary and you can go just right fucking through it. I was just writing this other thing we were talking about or were thinking about, this thing about how do we onboard new programmers and teach them things and so on.

David Heinemeier Hansson (10:12): And the essay that kept ringing in my ears was Derek Sivers, There’s No Speed Limit. It’s a wonderful, wonderful essay. Just Google There’s No Speed Limit Derek Sivers, and you’ll find it. It’s like, I don’t know, six paragraphs. It’s not a long essay. And anyway, he tells this whole story basically about how he learned a full music education that’s supposed to take four years and a year or something because the standard pace is for chumps. That was the key line. The standard pace is for chumps. It is set for the average mediocre, whatever level of engagement, not even talent or whatever. And I kind of feel like we need to have this sense that there’s no speed limit. You can do huge things that customers love in three days. Absolutely.

Shaun Hildner (11:01): Jason, you were sort of talking about this a little bit earlier, how much of the six week cycle decision that we cut ourselves with, most projects are six weeks, is based on this ability to get the quick wins? Is it getting the quick wins and keeping your momentum up a byproduct of the six week cycle? Or was this when choosing six weeks were you taking into consideration, well, that’s quick enough that we can keep momentum up?

Jason Fried (11:23): There’s a few reasons why it’s six, and by the way, it could be seven or it could be five. It’s not like six is thatmagic. But conceptually, the idea is that it’s long enough to do significant amount of work and to ship significant features. It’s also not too long. So it forces you to have to cut things and to really understand what you’re doing and why you’re doing it. And even if you’re working on something you don’t like, it’s almost over before you begin. So it’s both long and short. It’s adequate and not quite. It sort of has that magic quality of it’s kind of a weird number, but also the perfect number.

Jason Fried (11:59): And most of the time, it forces us to cut. We typically don’t sit around twiddling our thumbs waiting for more work to do. It’s usually there’s not enough time, and that’s good. You want that, but you also don’t want to feel so compressed that you feel rushed, which I think is what four, three weeks would be if everything had to be done in that period of time, although certainly it’s possible. So I think six feels like a good, the Goldilocks zone basically, just right. And everything, by the way goes six weeks also just to be clear for listeners, right?

David Heinemeier Hansson (12:28): Exactly. This is the outer boundary. This is the maximum we will do, right? In fact, when we internally talk about quick wins, we’re usually talking about things that take a week, three days, or one day. We’re not talking about the six weeker so much, even though in another organizational context, it’d be like six weeks, what a quick win that is. That is actually on the outer boundary of ours, but it’s on this same spectrum of, we can do good big things quickly. That there isn’t this iron law that making good software just needs to take months and months on end, and it needs big teams and all these other things.

David Heinemeier Hansson (13:02): In fact that as Jason says, the software that comes out of a constrained process in our humble opinion is better. It’s not worse. It would not have been better to take the same feature we spend six weeks on and give it six months and five times the number of people. You would get exactly the kind of software that takes six months with five, six people like 10 X the amount of complexity, 10 X the amount of goal planning, 10 X the amount of configuration, 10 X the amount of all this other bullshit that’s against sort of the ethos of why people buy Basecamp for example, right?

David Heinemeier Hansson (13:37): We go through this often, and the number one thing I keep hearing, I mean, we hear a lot of things and there’s a lot of reasons, but one of the key things we keep hearing is, it’s just so easy to get someone to get started with Basecamp. I don’t need a manual. I don’t need training. There’s just enough. All of these things are products of a development cycle that’s bounded, that cannot produce this massive software, that cannot produce software that requires endless configuration and has all these other things in it. So you get the kind of software that you set up the boundaries to produce.

Shaun Hildner (14:10): Jason, you said something earlier that I thought was interesting. A quick win isn’t just about feeling good after working on something you really like doing, but having that deadline, a quick win can be counted as, well, at least I’m done with something that was kind of boring or I didn’t really want to be doing in the first place. Is that kind of what you’re saying about work you don’t necessarily are happy with? You’re not happy with?

Jason Fried (14:31): Yeah. I mean, work is work. Some days it’s not great. Sometimes we’re working on something that’s not particularly exciting. Sometimes you’re just not into it. That’s really what most work is kind of just stuff that needs to get done. And sometimes it’s particularly exciting, but oftentimes it’s just work. And it’s nice to know that there’s a bound that you’re not going to get stuck in this place where you’re on this conveyor belt, and you’re not really getting anywhere. You’re walking a lot but you’re not getting anywhere. And it’s just frustrating.

Jason Fried (15:03): So I think this is a great way to handle both ends because if you’re really into the thing, you also want customers to be able to use it. So you want it to ship. So there’s like the, I’m pumped for this. This is great. I want to get this out. And there’s also, eh, not the most exciting project in the world. Well, I’m almost done already anyway, and next cycle’s coming up. We can do something else. And hopefully, next time I’ll find something that’s a little bit more exciting. So it’s a really wonderful limit accelerant in some ways. It helps you get things out faster. And then also it holds certain things back until you cut them down to get them out. So it’s kind of a good combo of all worlds.

David Heinemeier Hansson (15:45): I think the other thing it provides is variety. If you’ve been working on six week projects for a couple cycles in a row and they’re big, heavy, medium, for us complicated projects in that they go six weeks and they require coordination. So you’re just ready for a change of pace. Mix it up, let’s play some short games here, just something that’s fast at a different pace. So this is also why we try to schedule people to be, if they’ve just been on a long six weeker, there was sort of a big thing. All right, for the next cycle, let’s hit them with some quick wins.

Shaun Hildner (16:17): Oh, that’s interesting.

David Heinemeier Hansson (16:18): Let’s have five small things on the menu that they can just bang out that aren’t really that convoluted or complicated to work on. And that just sense of pace, when you’ve done something that runs really long, you’re ready for the short stuff. When you’ve done the short stuff for a while, you’re ready for the in depth, deep dive stuff.

Shaun Hildner (16:35): I want to tackle a big thing. Sure. Yeah.

Jason Fried (16:37): It can also, by the way, be at a project level scope, not just individual, but we’re working on the next cycle right now. And there’s a bunch. We’re probably going to hit Basecamp, for example, with a bunch of smaller fan favorites that are just kind of quick wins, maybe get six or seven or eight things done next cycle versus three big things, that kind of thing. So you sort of want to ebb and flow with that. And that’s really nice about this period of time.

Shaun Hildner (17:01): We talked a lot about at the beginning of this episode, the benefit of getting these quick wins in is personal momentum or organizational momentum. But then you also mentioned that you just get it out in front of the customers with these smaller wins. Is that to get feedback or is that more for keeping momentum up? I guess, what are the other benefits of releasing early and often?

Jason Fried (17:24): Well, you’re making the product better, and you’re moving on to the next thing. And you’re able to, in a given period of time, let’s call it a year, you’re able to just improve the product 12 times. I mean, not if everything takes six weeks. But some things take six, 12 times, 12 things, 12 big improvements, or more, 20 or whatever, any given year, if you’re just stuck in that one thing, which is so easy to do. I mean, pretty much any of our projects could take longer. As we’d like to say, it’s not even just us. I think this is an old adage, but there’s a three month version of something, and there’s a six month version. There’s a nine month version. There’s a one year version. There’s also a three week version. These are all versions of the same idea. Ideas don’t come with fixed, this idea must take this long.

Jason Fried (18:08): It’s like, no, how much time do you want to give it? What’s your appetite for it? And then you work backwards from there. And so anyway, it’s just, you want to give customers new things because you want to improve the product. You want to solve problems that are existing because maybe they’re annoying people or there’s a bug that you need to fix. You want to set something up so you can do something else. Sometimes there’s a few things ahead of time that you’re kind of thinking about a sequence of, and you need to get something out before you can get something else done. There’s all the reasons. There’s all good reasons to get things out. I would say one thing you want to be careful of is too much rapid whiplash change. You wouldn’t want to keep radically changing how something works fundamentally six weeks at a time, because that could really confuse people. Otherwise, there’s no downsides to getting more stuff out quicker.

David Heinemeier Hansson (18:55): One of the key benefits that I really enjoy is that it’s a test of organizational fitness. Is this organization in shape to be able to do things quickly? Are you capable of turning something around from idea to shipping in say three days, do you have the technical capacity to do it? Can you run through the gamut of systems and validations and checks to push something out in the wild in that time? Do you have the organizational decision making power and progress to do it? Can you clear all the check boxes that you need to clear to push something into the wild? If you can’t do that in a day or three days or even a week, your organization’s just flappy, and it needs to get on a workout to be able to do those things.

David Heinemeier Hansson (19:42): Because if you just fall into like, well, everything can take more than six weeks. Everything can take three months or whatever. You simply lose the capacities to do these things. And it won’t be a big deal if it takes two days to put something to production, if it takes a week to arrive at consensus about whether we should do it because you’re just doing it every three weeks. In my opinion, that’s a flappy organization that needs to go in on a workout.

Shaun Hildner (20:09): It should also be said that we’re doing this while still working reasonable hours. I think it’s easy for someone to look at, let’s get these quick wins, which means I’m going to throw too many hours or too much money at something.

David Heinemeier Hansson (20:20): Oh, totally. Yes, this is about scope. In almost all cases, it’s about scope, not resources. It’s not about throwing more people at the problem. It’s not about throwing more hours at the problem. It’s about restating the problems so that they fit in that. And then of course also having an environment where it’s possible both in terms of decision making pace, but also in terms of technical capacity. Can you actually do it? Can you make something that’s good that people would want to use that’s not full of bugs and all these other things in a short amount of time? Do you work in an environment where that’s possible? This is where all these things work together. Why do we use Ruby on Rails? Well that’s because of that. Why do we focus so much time on pays, meetings are toxic. All these other topics we write about in REWORK, a lot of them about whipping the organization into a shape where it’s capable of delivering quick wins.

Shaun Hildner (21:11): Well, perfect. I think that’s actually a pretty good place to stop. I am back to collecting your questions for future shows. So if you have anything you’d like to ask Jason or David, you can leave a voicemail at 708 628-7850 or better yet record a voice memo on your phone and email it to hello@rework.fm. Next week, we’re talking about not being a hero. But for now I want to say thank you to Jason Fried.

Jason Fried (21:36): Thank you, Shaun.

Shaun Hildner (21:37): And thank you, David Heinemeier Hansson.

David Heinemeier Hansson (21:40): Thanks, Shaun.

Shaun Hildner (21:41): Hope you feel better. REWORK is a production of 37signals. Our theme music is by Clipart. We’re 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 @reworkpodcast. If you’re following along in the book, next week, we’ll be discussing the chapter, Don’t Be a Hero. And 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.