SEASON 2 - EPISODE 0087 - DEC 13, 2023

Narrow As You Go

In their book, It Doesn’t Have to Be Crazy at Work, Jason Fried and David Heinemeier Hansson stress the importance of narrowing the scope as a project unfolds, emphasizing, “After the initial dust settles, the work required to finish a project should be dwindling over time, not expanding.”

But navigating this challenge is not always easy.

In this week’s episode of REWORK, Kimberly Rhodes sits down with Jason and David to explore the challenges and benefits of narrowing focus, particularly in the context of developing a new product.

Jason and David delve into the significance of clear deadlines, effective strategies for managing a constant influx of ideas, and the importance of adhering to the principle of “done is better than perfect” so you can ship.

Check out the full video episode on YouTube.

Key Takeaways

Why clear deadlines are crucial for honing, editing, and chiseling features to ensure a focused, timely delivery.
How to avoid feature “pile-up” as a project progresses in order to prevent last-minute chaos and ensure a smoother path to completion.
Start new product development with novel ideas to create a distinguishing factor for an audience seeking innovative solutions.
Not every idea can be integrated without compromising a project’s scope—be prepared to make decisions on what to include and what to postpone.
Use the role of working memory to focus on what truly matters without being overwhelmed by an endless list of ideas.
Resist the temptation to hoard ideas; instead, focus on a few key ideas that align with the project’s goals.
Done is better than perfect: small companies have the advantage of focusing on the perfect ratio between effort and value.

REWORK is a production of 37signals. You can find show notes and transcripts on our website. Full video episodes are available on YouTube and X (formerly known as Twitter).

If you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 or email, and we might answer it on a future episode.

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m your host Kimberly Rhodes. In their book, It Doesn’t Have to Be Crazy at Work. co-authors, Jason Fried and David Heinemeier Hansson write about the importance of narrowing scope as you go. They even write, “After the initial dust settles. The work required to finish a project should be dwindling over time, not expanding.” For those of us who’ve been involved in any kind of project, we know how hard this can be. And with me today are Jason and David to talk a little bit about this. I know we’re building a new product and I would imagine narrowing that scope is super important for that as well. You guys kind of talk me through this scoping.

Jason (00:40): Well, first it requires a deadline at some point because if you don’t have that, then there’s no going towards something that you need to narrow in on, otherwise you can just kinda keep going. So let’s say we are trying to ship something January 1st or something like that, right? And we’re two months out. You cannot be adding more things to the plate at this point. You’ve got to be in the place now where you’re kind of frozen essentially on features for the most part. And you’ve got to be in this honing mode, in this editing mode, in this chiseling mode, actually. There’s going to be a couple because you’re always going to find a couple things you probably do have to do near the end.

(01:24): What you want to avoid is what we tend to call like a pile up. You don’t want all this massive work just to be pushed off until the end, right before you need to launch this thing because you’re going to find other things you need to put in there too. And then you’ve got this big pile. So the pile should be getting shorter and smaller and tinier as you go if you ever want to get this thing out the door. Now, it doesn’t mean that you may have a huge pile of ideas, right beyond shipping. So you might narrow as you go and then at this huge thing, but that’s okay because you’re aiming for something which is getting this thing out the door and then you can always knock the pile down over time after that point. But what I’ve seen happen on a lot of projects is ideas keep bubbling up as they always do and they always tend to do, and it’s a limited time left and people just keep adding like, oh, wouldn’t it be cool if it did this and wouldn’t it be cool if it did that? And sometimes you can get away with that if they’re very quick one or two things, or if you trade them off against something else. But if you just keep throwing ideas in the pile, you’re never going to get the thing out the door and that’s why you’ve got to narrow as you go.

David (02:24): This is also why you got to start with the novel stuff first. As Jason’s keen in saying, when we started with the calendar, Jason had a bunch of specific novel ideas for the calendar that we had to start with first. We knew there were all sorts of baseline things we needed in place and that was true for HEY with email too, all sorts of baseline things we needed in place. But if you start with all of the baseline stuff first, you may very well get to the cutoff point and realize, you know what? There’s no reason for this thing to exist. We’ve just implemented the baseline. What is the baseline? The baseline is what everyone else has. So if you’re going to trade something off, if you’re launching a product particularly into a category that already has competitors, you have to start with some differentiation.

(03:07): You have to start with some novelty, you have to start with your new ideas. So what you’re trading off is the least important part of the baseline. Now, that may very well mean that there are some people who expect that these parts of the baseline should be in any product and you can’t sell to them on day one. Okay, that’s fine. You don’t have to sell to your entire addressable market on day one. It’s totally fine to appeal to a highly motivated, it used to, the meme used to be hair on fire audience or customer base who been looking for this type of novelty, their entire, I mean not life, but inquiry here into this product category that they needed something they really wanted. They were highly motivated to get this thing. You are providing that they’re willing to give up some of this baseline to get it, but you’re not going to be shipping that unless you start there.

(04:00): So we did this with the calendar, we did this with the email product, just starting with the things that are really out there, the things that are really different. And I think with, HEY, the email product was interesting, what didn’t make the cut? So for example, we didn’t ship with signatures. The product went live. There was not a way to have a repeatable signature on every email going out. That was just part of the baseline. We knew it was the baseline. We knew there were people who would go like, I can’t use this unless I can put in my titles and contact information and whatever. Alright, totally fine. But if we just ship the product that had that feature in it, no one was going to pick HEY because we had signatures. Tons of people picked hay because we had a screener, because we have this feature, because we have that feature.

(04:43): So you got to start with this. And then the other thing, as Jason said, the forcing function of a deadline is the crucial part. There used to be an era of software development, particularly in the games industry where it was fashionable to say, we’re going to work on it until it’s done. And until it’s done was this constantly receding mirage that kept moving further and further away. The best example of that was 3D Realms, the maker of a very popular game from the late nineties called Duke Nukem. They made so much money on the first version of Duke Nukem that they went like, the second version’s going to be so fantastic, we’re going to work on it until it’s done. I think the product was finally canceled after seven or eight years or maybe something was shipped and it was total crap. Humans need forcing functions of deadlines to produce good works. Not just like all the work, you got to be cutting the scope, but unless you have the forcing function, there’s no pressure to get to that level. So start with the novel stuff, embrace the forcing function of the deadline and you might end up with something interesting.

Kimberly (05:45): And I would imagine as you’re building a new product, there’s new ideas that are coming as you’re developing it. Like, one thing leads to another and like, oh, this would be a great idea. That would be a great idea. Obviously you have to narrow that down. What do you do with all those other ideas? How are you capturing them and considering them for future? Do you have a process for that?

Jason (06:02): Yeah, I mean the way I look at it is, it depends. New product development’s a little bit different than a current product development. So Basecamp is an existing product. We’re building this in the traditional Shape Up cycle process. We choose what we’re going to work on for the next six weeks and we don’t change. New product development’s a little bit different because it’s unformed. It has not shipped yet. New ideas come up and some things are considered that weren’t initially considered, but there’s something new that bubbles up out of nowhere and you’re like, we have to do this, but it’s got to be a trade-off. You’ve got all these cards, you got to figure out what you can only have eight in your hand at one time or something. So you got to trade a few into the deck and pick a few new ones up.

(06:42): And so this can happen. You can decide, for example, let’s just say we have two months to go and we had this idea that we’re going to do these three or four things and this other thing comes up. It’s like, we should actually do that. Then you got to trade something back. You go, okay, then wait, we’ll push this other thing and do this other thing first because there’s a certain novelty to it or an excitement around it, or we just have this energy that just bubbled up and we’re like, we should really just take advantage of this energy and this. Or we came upon some new ideas, some new tech, some new design thing that’s possible we didn’t know was possible before, whatever it might be. Okay, it’s not five things, it’s still four, but it’s just four different things now.

(07:21): And of course you can’t do that up until two days before you’re going to launch, but you can’t keep adding more stuff to the pile without taking some stuff off if you want to get something out the door. And then recognizing to your second question, what happens to all these other ideas? Well, you either forget them and they weren’t really that good to begin with or you just can’t wait to get to them because they keep coming up over and over and over. Or you forget them and they come up again in a new version like we were talking earlier, another podcast about that new feature in HEY we just launched the fuck no feature. That was an idea that actually we had in 2021, which we didn’t do anything with. And then finally in 2023 in October, we did. We actually had forgotten about it for two years, decided we weren’t going to do it two years ago, then forgot about it, and then it came up again.

(08:04): Sometimes that happens too. So I just think good ideas aren’t forgotten. It’s not like you’re forgetting someone’s name you met once. Okay, then you’re probably going to forget and it doesn’t really matter that much, or you can ask 'em again if you run into 'em or if you don’t, you’ll never see 'em again anyway. But if you have a good idea and you’ve shared it with someone else, maybe perhaps it’s just going to cycle around at some point. And so I’m not worried about losing good ideas. That’s something you should never really be worried about. The harder thing is to figure out how to get 'em done and not constantly push things off because you have a new, new idea every day. That’s kind of a real problem actually you want to avoid.

David (08:43): You definitely also want to avoid hoarding ideas. There are hundreds, thousands of ideas that we could put into any product and if we try to capture them all, record them all, we’re going to end up with very long lists of things that not only are never going to get done, they’re going to discourage us from doing anything. We’re going to look at a whole pile of things we could do and go like, Ugh, now we’ve got to review this. We’ve ended up in that boat several times. We have a lot of ideas we generate internally. We get a lot of ideas from customers all the time and due to lapses in occasional judgment, we’ve compiled some of those ideas on long lists. And then we’ve eventually just realized that once that list is like a hundred items long, 200 items long. In fact, we had one for HEY for a long time that was at least 250 items on it. You just have to declare bankruptcy and the bankruptcy is a liberation. This is what’s so instructive about why this is a good thing. You go, once you’ve retired that list, you don’t go like, oh no, what about all these ideas? I’ll forget about these ideas. You go, ah, man, what a load off that we got rid of this long list that we won’t ever get done anyway. Do you know what? Things on that list are accumulating endlessly? Because they’re just not that important. That’s the fact of it. If they were super duper important, they’d constantly be bubbling to top of mind and you couldn’t work or wait to be able to work on them, and that’s just not what’s happening. So I think to some extent these long lists where you try to capture things are a way for you to deal with whatever guilt you have about ideas that like, oh, this is someone’s idea.

(10:15): It’s got to be precious. We got to handle it in a structured way, otherwise we’re not paying respect to it. Do you know what? To some extent, fuck respect when it comes to these kinds of ideas. The respect of the idea is the respect of the moment is the respect for working memory. This is why I love the working memory of the human brain. It just can’t hold that much stuff. It is such a finely tuned machine for forgetting shit. That’s what it’s actually really good at. And you should embrace that capacity to forget things that are not that important and go, this is a feature, this is not a bug. It is really good that we forget things just that we are not constantly jamming more and more and more stuff into our head and we walk around with 300 unfinished ideas to give us anxiety all the time about the things that we’re not doing.

(11:00): If you can only remember about five things, you know what? You could probably work on those five things. So this is good. This should be embrace these long lists, no. I mean if at most, and we do this occasionally to some extent when it comes to customer feedback, because you want to be honest when you tell a customer, thanks for your suggestion, we’re going to consider it. So you can put it somewhere that you fulfill that obligation truthfully that you are putting it somewhere and in some abstract way, maybe it is being considered but not on sort of the main list that’s right in front of you all the time. It’ll go into a big bag and occasionally someone will look in that big bag and go through some of it and skim through some of it and go like, oh, maybe there’s something here.

(11:41): Maybe there’s, even if I zoom out and I can’t actually see all each individual idea, I can actually see a pattern if I’m zooming out and I could see here’s a grouping of ideas that are actually related. They don’t seem related. They didn’t seem related when they were right up in our face and we were all zoomed in, but if I zoom out a bit, I can see that there’s an area of pain here and we can address that in a really novel way. So that’s a way to deal with it that isn’t just a backlog. I think this is what, especially in software terminology is so often dreaded. I don’t hear a lot of people talk positively about the backlog. The backlog is usually this long list of stuff that just feels like an endless conveyor belt where you’ve signed up for certain ideas long in the past that you’re now obligated to work on.

(12:27): This is one of the reasons why we’re so big fans of this cycle idea that you get to reconsider your entire list every six to eight weeks. You’re not bound by the fact that, okay, now the list has 200 items on it, we better do them in order. First in, first out. No, shouldn’t be like that at all. First bubble to mind when it’s time to decide again, is more likely to be the correct answer than thing that we had entered into our database seven months ago and now it’s their turn. Don’t treat ideas like they have seniority. Don’t treat ideas like the oldest is the golden. No, absolutely not. You have to clear the table all the time. In fact, again, our brains are amazing at this. They can forget everything, even important things all the time. That’s good. Clean table.

Kimberly (13:17): Okay, so you’ve mentioned Jason, that we sometimes will ship a new product without everything that we necessarily want to down the road to be in it

Jason (13:24): Always. Not sometimes, actually. Always.

Kimberly (13:27): okay, I love that. So I feel like there’s a lot of people who, I mean I can say this of myself when I owned my own business that I want things to be perfect before I’m pushing them out. And I know here it’s like sometimes done is better than perfect. Kind of talk me through your thoughts about that, especially when it comes to a new product.

Jason (13:45): Yeah, I think the things that we choose to do are perfectly done. They’re not perfect in that they’re foolproof. Every edge case is considered, every interaction is as good as it could possibly be, but they’re perfectly done. Meaning they work really well, they’re clear, they’re concise, they’re thoughtful. There’s some delight in them here and there, but not overly so. They’re perfect in that way. The product is the collection of those perfect things. But I do think the word perfect, it’s important to define it because some people think perfect means, again, dialed into the nth degree, everything is micron level, perfect. That’s not what we talk about when we talk about perfect. There’s a feature coming up in the hey calendar for, I’m trying to be sort of abstract here for tracking things you do often, let’s say, and it’s so perfectly in my opinion, put together because it does so little, but it does those things really well and simply, and we built it in like two weeks and that’s what makes it perfect.

(14:54): It would’ve actually been worse had it been better in a sense, but it took 12 weeks. So on some metrics it’d be more perfect that way. Not on my metrics. It wouldn’t be. So I think it’s perfect as a very relative term. And so we’re looking for our version of perfect, a collection of perfect items like that. And then again, knowing that we’re not shipping this and we’re done. We’re going to move on to the cycle system and every six weeks we’re going to improve this in significant ways moving forward so we can pick more things off as we go.

David (15:26): Yeah, I think focusing on the perfect ratio between effort and value is really what gets me fired up. I love a good deal. I love a bargain in all facets of life. I love getting more than what I’m sort of paying for. And I think this is often how I try to think of things. If I contrast, I could do one thing and I’ll do it perfectly by the more conventional definition that all the edge cases, they’re all considered everything. Then I can get the one thing and I go like, oh, that’s a nice thing. Or I can get five things that are perfectly fine, perfectly enough, but I get five things. I go like, do you know what? In most cases I’d rather have the five things. I’d rather find the bargain. I’d rather find a deal. And I think this is one of those advantages that small companies have very often, that big companies don’t.

(16:16): Big companies have much more of an institutional preference drive bias towards completionism. Oh, we have to consider this because this department and legal says this and QA says that, and there’s a billion stakeholders will need their little piece of perfect. And before you know it, this thing is just the monstrosity. They can’t do small things well. When you are a small company and you don’t actually need to listen to input from 10 different departments on the thing that’s being put together, you can do something perfectly well, perfectly fine, which gives you an incredible amount of leverage. This is something when I look at the size of the development teams we have, and I contrast the kind of software that we produce to software being produced by larger shops, it often seems like we’re not existing in the same universe. What are they doing? Now, I know what they’re doing.

(17:05): They’re making things perfect. They’re making things perfect according to legal, according to accounting, according to all sorts of edge cases, according to scale, according to their constraints. Don’t get sucked in by that. Don’t accept someone else’s constraints and definition of perfection as like that’s what you’ve got to target to. We target that in all manners in the tools that we build. We don’t build tools that are perfect for gargantuan organizations. We build tools that are perfect for our shape and size of it. They may very well also be useful for other people, but they are perfect for us. And that perfection comes from fit to context, fit to situation, fit to number of people, and then suddenly, if you accumulate perfection in your tooling, perfection in your methodology, perfection in your selection, you can do these things that seem strange to large organizations. How can you get all this done in this amount of time with so few people? Yeah, because we’re striving for a different kind of perfection and I think just it’s invigorating to work like that, to really work fit for context and feel like you know what? We’re getting the most out of the things we have. We have less, we have far less. We have fewer people, less money, less time, less everything, but what we’re getting out of that is way more.

Kimberly (18:23): Okay, well, we’ve said perfect 278 times, so I think with that we’re going to wrap it up. REWORK is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. You can also watch video episodes on YouTube and Twitter, and if you have a question for Jason or David about a better way to work or run your business, leave us a voicemail at 708-628-7850. You can also text that number or send us an email to rework@37signals.com.