SEASON 2 - EPISODE 127 - OCTOBER 16, 2024

Say No by Default

In their book REWORK, 37signals’ co-founders Jason Fried and David Heinemeier Hansson write about the power of saying no. This week on the podcast, they revisit that idea, diving into the hidden costs of saying yes and the burden of commitments that often come with it. They also discuss how saying no preserves simplicity and helps maintain focus.

Watch the full video episode on YouTube

Key Takeaways

00:45 - Saying yes often comes at the cost of time or ongoing responsibility
03:00 - Yes feels good until it’s time to fulfill the commitment
07:58 - Adding features to products often results in layered complications
14:53 - Saying no is more difficult when you have the capacity to say yes
19:51 - The courage to say no creates space for simplicity
29:30 - The best way to say to no to customer requests

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, and as always, I’m joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. In their book Rework, they write about saying no. In fact, they say it’s even more important to say no more often than actually saying yes. In fact, they write, “You rarely regret saying no, but you often wind up regretting saying yes.” Guys, I thought we would talk about it today. Not only making decisions in terms of the products, what you’re saying yes and no to, but also in terms of your business, what you’re saying yes and no to. I don’t know who wants to jump in on this in terms of the product first maybe?

Jason (00:43): I think the point about regretting yes is actually a good place to start because that’s in many ways more interesting to me than the saying no part. Saying no obviously is a very, very specific instrument. When you say yes to something, it’s kind of a blunt force instrument because in effect you’re saying no to maybe hundreds of other things that you could consider because you’ve already taken something on. And oftentimes what we’ve found is that when you take some things on, you can end up with a lot of regret down the road. You experiment with something because you think it’s a cool idea and then you’re left with sort of the remnants of that idea sort of baked into a website somewhere, or you have seven additional pages on your website you didn’t know about or had some pricing thing you implemented and forgot about.

(01:23): Or the person who was doing that is no longer here and now there’s this thing that’s sort of hanging out there in the wind. And that is one of the biggest penalties of saying yes to too many things is that you end up having a few too many things going on. You can’t really keep track of all of them necessarily, and they end up increasing the surface area of the business, of a website, of a product, whatever it might be. And you look back on that a year later and you’re like, not only do we wish we didn’t say yes to this, but now we have to unwind it, which is additional work. So is all the work you put into doing it now you have to unwind it or if you don’t unwind it, which most companies end up not really unwinding it fully and we’re guilty of this too.

(02:00): Again, you end up with these sort of artifacts that you don’t even know about kind of hanging around and then when you want to make some changes later you’re like, oh, we can’t or we can, but it’s going to be a real pain in the ass because we’ve got all the other things to deal with. And this happens also with pricing plans and experiments that you do inside of a product. You’re like, you want to make some change. You’re like, well, we changed the way this worked and now to make that change it’s a lot harder because this other thing that we didn’t end up doing is still there. So anyway, I think it’s just really important to keep in mind all the costs that go into actually taking something on and then the cost you will incur either by unwinding it or leaving it in place and having to work around it.

(02:37): There’s just a lot of that stuff. Now that’s not to say you should never say yes, of course you should from time to time and pick the things you want to do and hopefully do them well, but most things you choose to do probably won’t work or won’t matter anyway. And then you’re left with a lot of these remnants. And so I think that’s why no is such a powerful thing because it’s not only no to all the present work, but it’s also no to all this future work. And then you can pick battles more carefully.

David (03:00): What I find interesting about saying yes is how often it’s a cop out from having a hard discussion about whether we should do this or not. It is very easy in a lot of social situations, including at work, including with customers, including with team members to embrace all the good ideas. Someone raises a point, that’s a great idea, we should do that. Boom, stick it onto the roadmap. One of us, Jason and I go like, oh, we should really do this. Boom, stick it onto the roadmap. Customers are constantly requesting things. The easiest thing in the world is to say, that’s a great idea, we’re going to do it. And now you’ve signed up for a commitment and the problem with commitments is that they accumulate and you get more and more of them. And before you know it, you have already spent the next three months, six months, a year worth of decision-making opportunity on all these commitments that you’ve just said yes to because it was easy.

(04:01): And that’s not how you get a great product. You don’t get a great product by saying yes to everyone all the time. You get a great product by saying no to almost everything almost all the time. And that takes a certain degree of discipline that it’s very hard to stick with, especially as you grow. The hardest thing in the world is to keep that nerve to say no. Once you have a team that actually could, once you could say yes to something. In the early days of Basecamp, it was very easy to say no because there really wasn’t anything. I was literally the sole person on the technical side doing things. We just had Jason and Ryan on the design side of things. The natural forces gave us an environment where saying, no, were simply the only option. We’re no longer that blessed. We now have a company of 60 plus people.

(04:52): We could do a lot of things. We can even do quite a lot of things at the same time. We can even commit to doing things three months from now or six months from now. And you know what? Every single time we’ve done that, every single time we’ve signed up for a commitment, every single time we’ve taken the easy way out of saying yes, we’ve ended up regretting it, which is exactly what that point in REWORK is about. How often it happens that you say yes and it feels good right in that moment it feels amazing. Saying yes is the best thing in the world for diffusing a situation with a customer or with a colleague. Yes, your idea is great, we’re going to do it, right? And it feels so great right up until you have to actually do the work and then it doesn’t feel so great.

(05:35): Then you’re like, why am I stuck with this when actually right now I have better ideas. I have things I’m more excited about things I’d rather do. And I see this not just with the product, not just with the company. I see it with my damn calendar all the time. The number of times I say yes to some engagement, meeting someone for a quick thing or appearing on a damn podcast or showing up for a conference, it feels so easy to say yes when that thing is three months out. And then when that week rolls around and it pops up on my HEY calendar, I’m like, motherfucker, why did you do this to yourself again? Jesus, can you just say no? And I think, well, Jason and I are actually quite good at saying no and even still we fall in with both feet all the time saying yes to way too much stuff.

(06:24): And the final thing I’ll say on that is it is not the yeses I look back upon and go like, oh man, that was amazing we said yes to that. It is all the things we said no to, which is this novel territory. Steve Jobs has about a million quotes on saying no almost all the time and whatever. But that’s what’s so alluring about this topic. Even though we all know that we’re supposed to say no all the time, we don’t. We don’t because it’s really difficult and this is why you need the reminder all the time that yeah, do you know what? It’s still hard and we still fall into it. I’m sure we’ve actually just in the last few years we’ve signed up a couple of times committing to a certain feature or certain rollout every single time without fail, we’ve regretted it.

Jason (07:06): Another way to think about it is that yes is very cheap now, but very expensive later.

(07:11): And because it’s so cheap now, it’s so easy to say, it’s so easy to spend yes, it doesn’t cost anything right now. So a nice way to think about it in general if you’re looking for a framework is like, would you say yes now if you had to do it tomorrow? So if David gets invited to a conference, would you go to the conference if it was tomorrow? You’d probably be like, no. But it’s easier to say yes to something that’s four months down the road because you don’t incur any costs right now. So that’s something I’ve been trying to do is try to pull it forward and go, yes now? What would I say to right now if I had to do that? Actually literally do that work right now. Now that sometimes talks you out of things that you probably should do, but I think it’s a good rule of thumb in general.

Kimberly (07:49): Are there any product decisions that you’ve made over the last 25 years that you’re like, oh, we shouldn’t have done that. You can think of as just a good example.

Jason (07:58): I mean, it depends how you count it ‘cause there’s lots of things we’ve done that has not panned out. So economically, financially, there’s plenty of things that would’ve been better off not doing probably, but again, depends how you consider it. I think some of those things were really fun to do and was good for us to do and good for us to experiment with. I would say the stuff we’ve been doing recently with ONCE hasn’t panned out financially in a way where we could run the business on it, but do I regret doing it? No, I think it’s still a great thing and we’re still going to do some more of these and see where it all pans out over time. We might be early, this might be a bad idea. So far it’s been okay. I don’t regret that, but certainly it’s been work. It’s whenever we add something to a product that creates this hard to back out of complexity that I tend to regret, like we’ve experimented with client access in our products over many years.

(08:44): So a lot of our customers are client services firm, design firms, architects, that kind of thing, marketing firms, and they invite their clients. And we’ve had various variations on this over the years and some of those variations have been much simpler than others, and the ones that were far more complex, we had different views and an entirely different experience for clients. There was an email only all this stuff, the ideas were really cool. We spent a lot of time putting them together and it turns out that it was just pretty complicated in the end, a bit too contrived and backing out of that was very, very hard because people got used to that. Some people got used to it and some people were grabbing on for dear life, they don’t want it to go away. Or we may have changed some pricing scheme or some whatever, something or other, and you’re like, ah, this just created more complexity down the road.

(09:26): That’s the stuff that bugs me most is when we do things that limit our optionality later on. Like my dream, I dunno it’s the wrong word, but would be just to have the smallest, tightest, simplest little thing that you could do anything with tomorrow versus having all these things to have to consider like we do now. Just because there’s legacy and there’s time and there’s a shit ton of customers who use our stuff. You can’t just go changing everything. So the more stuff you put out there, more stuff people get used to and you end up in some ways with things that aren’t quite as good as you know they could be, but it’s too costly at this point to change. And that’s always frustrating. Not to say that we wouldn’t have done them anyway because they were the right thing to do at the time. So another thing is just don’t beat yourself up too much over the yeses sometimes because at that moment it was probably the right thing to do, but you are left with the consequences of it. And so sometimes I do wish we didn’t have as many consequences laying around.

David (10:19): I’ll give you two examples. One is a technical example and the other is a product example. And the technical example is whenever we’ve tried to save work by reusing parts between products, I have ended up regretting it.

(10:35): We have a variety of infrastructures around user accounts and logging in, for example. We have an internal system called Signal ID which was built on the premise that when we had more products than we do it now, you could use a single account and you could sign into multiple things at the same time. And as Jason said, at the time, there were great arguments for why we went the way we did, but now that we’re settled with that, I wish we hadn’t. I wish we had just built each individual product to be as self-contained as possible with as little overlap and dependency as possible. I think that’s perhaps another way of putting it. In the technical world and programming world, there’s often this talk about dependencies, that once your products start depending on other things, those things either break whatever you’re working on when they change underneath you or you can’t update those dependency because you have old products stuck in the past.

(11:32): And we have certainly seen that where we have old products, heritage products that we’re still servicing for the customers who’ve signed up for them. So we can’t just break it all. It still has to continue to work, it still has to continue to be secure, but now it’s depending on these other relations. And now the current version of Basecamp for example, has parts of some of it’s login flow and onboarding flow, it’s not as good as it could be, and the reason it isn’t is because we’re carrying around the baggage of all those dependencies and all those interrelations to all the products. And going forward, this was one of the things we changed with HEY. We looked at with HEY, should we use Signal ID, this internal system that we have and went no, we’re not going to do that. We’re going to give HEY its own login system and it’s going to own it and it can own the entire journey from start to finish. And there are some technical reasons why that made sense because email is quite special in that regard. You don’t have another backup email in the same way and there’s some other criticalities, but I’m really happy we did it that way. The other example is when we translated Basecamp back in I think 2009 or 2008, we rolled out translations in I think maybe eight different languages.

Kimberly (12:44): Oh!

David (12:45): And it was a popular request. It still is a popular request to some degree and people used it. There were a small subset of people who were like, do you know what? I can’t get other folks in France to use Basecamp with me unless the interface is in French. Great, let’s do it. And we did it and it felt good for about five minutes and then the very next time we had to work on a feature, we went, oh no!

(13:09): Really? I can’t launch this before I vetted all the eight or 12 or however many translations we had. We can’t roll anything out. It felt like we had just taken on such an enormous drag that every single change now I had to go through these multiple steps of translations and at least at the time, AI wasn’t exactly as good as doing it is now. So it meant working directly with either professional translator or volunteer translators, then you had to double check the work because I can’t tell whether that’s a proper French sentence. And we pride ourselves that Basecamp is really good in part because the copywriting is really good. So we ended up feeling, do you know what? Even though we can see the numbers here, this is doing something good, to some degree there are people who sign up for Basecamp now who wouldn’t have signed up, otherwise it’s not worth it.

(14:00): I wouldn’t have done it again, and I would not do translations in that same way again unless maybe AI got so good that it felt like it was fewer cost option. But I was actually just talking to a company owner last week who had done translations with AI where they weren’t able to bet the final outcome and they had egg on their face repeatedly and they had some very, let’s just say disappointed customers when the AI said something in Spanish, it really shouldn’t have said that had come out of an automatic translation process. So that’s one of those things where I think you really got to think about it. I think most businesses certainly in the US, is the translation worth it? Is the baggage you take on worth the initial percentage point you can pick up? I think you have to be quite far into the growth of your business before that makes sense.

Kimberly (14:53): It kind of sounds like from these examples you guys are sharing that it would be easier now for you guys to say no by default than early in the business because now a yes has much more layers of complication because of the way the business has grown and the product has grown than when you first started out. Does that sound true?

David (15:11): No.

Kimberly (15:11): No?

David (15:11): No. I think it’s harder and I think the problem is that…

Kimberly (15:15): It’s harder to say no now?

David (15:18): It’s harder to say no now because we know we can.

(15:21): We know we can say yes, we can say yes to almost everything and find a way to make it work because we have enough productive capacity at the company to do it. It is so much easier to say no when there literally is no other choice. That’s the real benefit of constraints. Real hard constraints, not enough time, not enough team, not enough money that you simply can’t indulge your primal instincts and your primal instinct is to say yes. This is why when you look at large companies that have been very successful, they are really struggling with this. It is very difficult for a Microsoft or even an Apple and they’re good in other ways to successfully say no to some of these things that kind of feels like they should do internally because there’s no back pressure. If you don’t have any back pressure saying like, okay, if you say yes to this thing, we immediately have to say no to five other things.

(16:15): The trade-off then becomes very apparent versus the situation we’re in now and that a lot of larger companies are in, the trade-off is more remote, it’s more abstract. We actually do get to say yes to a lot of things and then we might regret it three months down the line, six months down the line that Jason says, now we’re saddled with all of this complexity. The next time we go to revisit something, that’s not what small teams face. They phase the, okay, I do this this week, well then I can’t do the other five things. And it’s so much easier actually to operate like that. And I wistfully look back upon some of those days and go like it was nice that immediacy, that immediate trade off, that it wasn’t about far future. It wasn’t abstracted, it was very practical. It was very week to week. If I do the thing, I can’t do the other thing. I miss a little bit of that sometimes.

Jason (17:02): I’ll give you another very specific example. We’re currently redesigning the Basecamp marketing site, and I’m redoing the pricing page which presents the plans that we have. And I got to be honest, I am not happy with it. And it’s not the design, it’s the fact that we’ve gotten complicated with our pricing. We have two packages, which doesn’t sound complicated, it’s not really, but there’s some subtle differentiation between the two that need to be described in a way that I wish we didn’t have to describe it. I wish it was simply you pay per user or there’s just unlimited pricing, like fixed pricing. So the main difference is 15 bucks a user, you pay for as many users as you have or $299 a month and you get unlimited people. That’s really fundamentally the difference, but it’s not the whole story. And so when you’re selling something to somebody, you kind of do need to detail the differences so people don’t think they’re getting the exact same thing.

(17:57): So I sort of regret the fact that we went down the path of differentiating the plans beyond simply price. What you end up seeing is when you look at the design and you read through it and you present it, you go, this is simply mirroring the internal complexity that we’ve injected into the app. And it bugs me. It bugs me. I wish we could just be like, there’s two prices. You get the damn same thing. This is how it used to be. You get every feature we have, everything’s the exact same, you just decide how you want to pay. It’d be so much easier. But then we’re like, well if we add this, we’ll incentivize people to go over here and if we add this will incentivize people to go over there. And then maybe it does and maybe it doesn’t and even if it did, is it worth it as the question. All these things come back, you can justify these individual moves very simply in a sense by testing them.

(18:47): Oh yeah, we make more revenue if we do it this way. But there’s a cost also I think, and the cost creeps up on you slowly and the cost is that eventually things get more complicated. Now it’s a choice that’s hard versus a choice that was easy. For us it seems to have benefited us in some way up to a certain point. And then customers are like, I don’t know what to do. I don’t know which one to pick. Am I going to pick? Now they have buyer’s remorse. Did I pick the wrong one the whole thing versus before it was like I know how I want to pay. So anyway, and that just multiplied over when you’re around for a long time, that can be multiplied in a bunch of different ways. There’s a lot of different things that we do in a product that have all these little subtle adjustments and tweaks that again, independently all make sense. But as you add them up and then you reflect back on them because you either have to explain them or teach them or show them or differentiate them, you’re like, man, this is more complicated than it needs to be. Now it’s not terribly complicated. We’re okay, but it still bugs me aesthetically that the differences are so subtle, yet they still have to be explained and it makes everything more complicated.

David (19:51): That to me is the essence of why saying no to that level of complication in the business and in the product takes courage because you literally have to say, here’s something…

Jason (20:01): We’re cowards, we’re cowards.

David (20:02): We are, to some extent, some of the time

Jason (20:04): For sure.

David (20:04): I think we’re all cowards. And you see the cowardice across the industry and this is why it’s so rare when you get, especially at much higher level than we’re at, you get that level of courage. And again, this example has been beaten to that and I even hate to bring it up again, but when Steve Jobs came back to Apple, he looked at the sprawling product line, they had a bunch of different computers, they were doing deals with other computer makers that could run the software and he said, we’re not going to do any of that. Here’s a quadrant. It’s going to have four slots. There’s going to be a professional laptop and a professional desktop. There’s going to be a consumer laptop and there’s going to be a consumer desktop. There’s going to be an iBook and a power book.

(20:44): There’s going to be whatever, a cube and an iMac, four things, that’s what we’re going to sell. We’re going to just take all the other complexity and flush it out of the business. And I look upon that as I’m like, do you know what aesthetically that to me, so satisfying, so satisfying. When you see that quadrant and you go like, do you know what all that makes perfect sense. It really adds up. I don’t have to think that much one way or the other. Now you look at that same company and you fast forward to now they’re, I don’t know, a thousand times bigger than they were, 10,000 times bigger than they were back in ’99 or 2000 when jobs did this. And you try to understand the iPad lineup and its relationship with the pencil. I would challenge any Apple executive to rationalize that.

(21:31): I think they have three different versions of the pencils that work with different versions of the iPad. There’s I think five different iPads in the whole lineup including an iPad Air that’s actually heavier than the Pro. And you look at the whole thing and you go, here is a lack of courage. Here is a hyper optimization where someone goes, you know what? On this P&L, this product is still selling, even though it’s maybe old, there’s like a $20 price difference in the pencils that justifies that we fit into some slot. We’re trying to fit in all the slots we can possibly get. No, no, no, get back to the quadrant. And even a quadrant for an iPad is ridiculous to have four of those, right? Have some damn courage. Be willing to say, do you know what? We’re going to give up some micro specializations here of the product tree and that’s going to cost us maybe something in the short term, but the payoff is that we’re going to have a product lineup as a whole.

(22:33): That’s very easy to understand. That’s straightforward and all this. The other example I’ve given I think about five times on this podcast is Pinkberry. That whole idea that you come in and there’s two flavors. You get the chocolate one or you get the tart one. That’s it. To me, that’s the pinnacle of an aesthetically pleasing business model is when you can look at such clarity in the offering and go like, dude, I don’t need small text. We don’t need font eight on this page. I don’t need the small type, I don’t need the asterisk, I don’t need the chart that compares all the things. It’s just straightforward and that’s amazing. Now having said all that, maybe that isn’t the way to maximize your profit. I’m sure there’s some very good product planners at Apple who have found a way to maximize things and maybe it does make sense on that level, but it offends me. It offends my aesthetics, it offends my sensibilities. And that’s why Jason actually hearing you talk through this, which should inject some courage into the lineup and just fucking find a way to get rid of it.

Jason (23:38): I know, and this is the thing that’s so interesting is that what ends up happening, this is exactly what we’ve been talking about. It’s very realistic, but we have tens of thousands of customers on these different existing plans and so well, if we just equalize them, and the only difference is now the way you pay, we could solve the problem for sure, but at some point you’re like, I just don’t don’t want to. It’s exhausting and I’d rather spend my time elsewhere. But it is interesting just how this happens. And I think this is also one of the reasons why when you make a brand new product where we’re currently working on two brand new products, it gives you a chance to really, and I think this is part of what’s satisfying about making new things, is you can hopefully not, I’m not going to say make the same mistakes.

(24:20): These aren’t mistakes necessarily what we’re talking about. They’re just bumps, they’re complications and sometimes you just live with them and sometimes you don’t. But when you do something brand new, you don’t have any legacy or any baggage and it’s just kind of nice to do that, to be like, alright, maybe this new thing we should have is just this one price. You buy it or you don’t. I like that versus tier. I’m not going to take credit here, but we kind of invented the freemium tier stuff 20 years ago and in some ways I regret that and we’ve gone back and forth. We actually for a long time with Basecamp had one thing. A hundred bucks a month flat out that was it. I kind of missed those days to be honest, although it didn’t fit everybody. And then you’re like, well, we’re letting some customers go who could give us less mone who would be customers. There’s all these trade-offs, right? So it’s easy to reminisce and be romantic about a certain time in your business’s life, but there’s other things you couldn’t do then too. So it’s always a delicate balance and it is a push and pull and a debate and it can be frustrating internally and sometimes you don’t know what the right thing to do is, but I think making websites and explaining things is the thing that really focuses me on realizing how complicated or how simple something is.

David (25:30): It’s the same thing on the technical side. We’re working on a major new release of Rails 8 right now, and what I find so often is when it comes down to the finish line and I have to explain what we built, I have to give a demo of what we built, I find all the ways where things are just too complicated. I can’t explain this. We have to change it. It has to be different because I’m not going to say this stupid thing. This thing is stupid. I know why it’s there. I know it’s there. I can hear your explanation for why it’s there, but it’s stupid to say it. I don’t want to have to say it. So we have to find a way around it. And I think as Jason says, this is what is such a relief when working on new products is that new products, they don’t have any value.

(26:14): You’ve literally not sold them yet, right? There’s not a revenue base. You’re not beholden to all the gold you’ve accumulated, which gives you maximum confidence to have maximum courage, which is also one of the reasons that another principle we’ve been following with new product releases is that B one should just be stuff that we want, should just be the most out there version that’s really pushing the boundaries because as soon as something has value, as soon as it has customers, it become endlessly harder to summon that level of courage because now the courage might offend someone, might turn someone away, and that means money walks out the door more or less literally. And you go like, that’s going to be hard. But when you’re in the valueless space, it’s when you have maximum opportunity to simply just do the right thing, do the smooth thing, right?

(27:03): Anything that’s been out there, been weathered by reality, by customers, it’s going to start developing little cracks and you can look at that and you go, do you know what? Some of these products that we have, these heritage products, they’re full of little cracks and whatever, and I can actually appreciate that that’s beautiful as sort of like a weathered face like, oh, that’s a 60-year-old who lived life. Good for them. I envy to have that many right wrinkles in the right places at some point, and I can look at the old product, but there’s also just some exuberance of youth here. And as a product person, having access to that and having access to be your most radical in terms of introducing something and working on something is really satisfying. And I think actually that more than anything, that draw to the radical, that draw to the smoothness was what brought us back into this mode of making a lot of new things. I mean, we went through a mode, a phase of the company’s history where we really didn’t work on new things. We were just making Basecamp better and doubling down on that and that was great, but also we couldn’t do that forever. At some point, I think you’re going to just feel that pull, right? I want to get back to smooth pebbles,

Jason (28:18): And by the way, I just want, it’s funny because I’m looking around at other products while we’re talking here for a second, the differentiation that’s annoying me. We only have three things that are different really between these plans, and I’m looking at some of these competitor sites and there’s dozens of things that are different. So we’re doing pretty well, but it still frustrates me that we’re not just like it’s this or that. It’s like you go to the store and you see two jars of peanut butter, the same brand. You’re like, one’s smaller, one’s bigger. We need a little, we need a lot. It should be that easy to buy something. And software’s actually become quite hard to buy because there’s a lot of different tiers. Some of our competitors have six different pricing tiers, and then they’re all different prices. Then below that are these charts where you go across and just have 12 features.

(29:00): This one has, this one only has eight of them. This one has four of them. This one doesn’t have any of them, but you can buy them a la carte and that is complicated. But then again, there’s probably reasons for it. So anyway, it’s interesting, and I think the good thing to think about though too is we all do this to ourselves so we can justify either direction. It just sort of depends what we’re after. I’m sure there’s ways to optimize our offerings to make more money and do all the things, but it might be more complicated than we have the taste for. So you got to figure it out as you go.

Kimberly (29:30): Okay. I have one question before we wrap it up. I want to read you guys something from this chapter of REWORK and get your thoughts on it because it kind of goes along with what you guys are saying about courage, and I’m wondering if you have advice for people. You say, “People avoid saying no because confrontation makes them uncomfortable.” So I’m curious when that comes to product decisions, especially when we have customers requesting things. Do you have any tips for someone who might be listening? Like, it’s hard to tell a customer no.

David (29:58): Yeah, don’t tell ‘em either way. Say thank you. That’s it. Under no circumstances should you allow yourself in a customer interaction to get drawn into on the spot a commitment. That’s what most customers want. They want a commitment. They’re making a request. What they most like to see back as a commitment, but you’re playing yourself and all your other customers if you keep doing that over and over again. Say thank you and mean it. It’s not just thank you, go away. Thank you. I mean, I am floored sometimes by the level of diligence and care that our customers will put into some of the feature requests. They’re writing paragraphs and paragraphs and paragraphs really explaining why they need the thing, why the current thing doesn’t work as well for their problem. That’s amazing. That is a gift of epic proportions to anyone who’s willing to listen.

(30:49): That does not mean you’re just going to go off and build what they’ve asked for. What they’ve asked for is in almost all cases, very particular to their situation. It doesn’t zoom out. It doesn’t try to solve the problem in a generic way, in necessarily even a smooth way. Oftentimes what customers will request is like, can you just put a toggle on the side of the thing? Because then I could flip it when I want to do one thing and I can flip it when I do the other thing and just go like, yes. If I just put on one toggle, maybe I could make it work, but I can’t put on a thousand toggles and I have a thousand feature requests. So it’s not going to work like that. As software developers and designers, we have to work on people’s behalf. We cannot work on their request.

(31:31): It’s going to turn into a mess in about five minutes if you do that. So say thank you. Put it in a pile. Take it out occasionally, read through it. Get inspiration, see patterns, see like, oh, they wanted that thing and this person who asked for a completely different thing, they actually have the same problem. And if we go with the third way here that neither of them suggested we’re going to solve both of their problems. No worries. And they’re both going to be thankful and happy for the solution, but we’re going to be much more happy because we solved five people’s problems, 10 people’s problem, a thousand people’s problem, not one person’s idiosyncratic solution.

Kimberly (32:08): Well, that’s great advice. 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 37 signals.com/podcast. Full video episodes are on YouTube and Twitter, and if you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 7 0 8 6 2 8 7 8 5 0. You can also text that number or send us an email to rework@37signals.com