SEASON 2 - EPISODE 195 - July 15, 2026

Don't write it down

Customer feedback is valuable, but not all of it deserves a spot on your to-do list. In this episode, Jason Fried and David Heinemeier Hansson revisit a chapter from their book REWORK, sharing how 37signals filters feedback, why roadmaps can do more harm than good, and what happens when companies let fear drive their product decisions.

Watch the full video episode on YouTube

Key Takeaways

00:40 - Why writing down every customer request can work against you
03:08 - Handling feedback on the technical and open source side
07:37 - Why 37signals doesn’t really use time specific roadmaps
09:54 - How vague promises set customers up for disappointment
13:33 - Avoiding promised feature regret
16:10 - Don’t let the fear of losing customers steer your decisions
19:29 - Resisting the pressure to just "do something”
19:29 - Resisting the pressure to just "do something”

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. Joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. This week I want to talk a little bit about one of the chapters of their book REWORK called “Don’t Write It Down,” and it’s all about customer feedback, when you should ignore it, when you should make notes about it. I thought we’d talk about this in reference to Basecamp 5 just a bit. Jason, I’m going to kick it off with you, but first I want to read you just the first couple of sentences of this chapter, which says, “How should you keep track of what customers want? Don’t. Listen, but then forget what people said Seriously.” I’m going to kick it off with that.

Jason (00:40): Who wrote that? Did we write that? Just kidding. Yeah. The idea behind that, which is still I think very true, although there’s some reasons to write a few things down, we can talk about that. But the primary thing is that, especially for a product like Basecamp, we have lots and lots and lots and lots of people using it. So you get a lot of feedback and you hear a lot of things. And the things you keep hearing over and over and over are the things you’re going to be reminded of that are probably the important things. Every individual customer has an important thing to say about their own scenario, their own situation, their own reality, their own perspective, and it’s all valuable for them. But we have to build a product for the customer base at large. And so you have to be careful not to design by anecdote or fix by anecdote or change by anecdote because someone can write a really strong point and they could be making a great point that other people are making too.

(01:28): Maybe they can make a point that no one’s making, but still you don’t want to just respond to one person’s feedback. And I think when you begin to jot things down and make lists and record stuff, you’re like, well, now you feel like there’s an obligation to do something about it or do something with it. So our point of view is listen for sure. And for the most part, forget. What I mean by that is don’t institutionalize that thing. Don’t write that thing down. Don’t make it official necessarily. Just keep listening. And the things that keep coming up over and over and over and over are just obvious then. And those become the higher priority items rather than just the good storytelling bits that can really move you to do something. So that’s sort of the primary idea. That said, we do keep track of certain things that customers write that have really interesting language or sort of some unique scenarios occasionally because there’s some insights you can get from that that you won’t hear from a lot of other people.

(02:17): So if there is an interesting email or there’s something that’s described in an interesting way, our customer service team writes it down and adds it to this project called Support: Voice of the Customer, I believe is the name of the project. And it’s kind of fun to go through that and look at some of these words and the way people describe things occasionally. I’ll remember a long time ago before we were doing this though, customers used to call projects Basecamps. They’d be like, “I have a bunch of Basecamps.” And in our head, that means you have a lot of Basecamp accounts and then you kind of pick up, oh, people call projects Basecamps. And we wouldn’t have known that otherwise. It didn’t come up a lot, but it came up enough. And so that was kind of a nice thing to bump into and just kind of recognize that. And for a while, I think we actually did that, maybe it was sometime in Basecamp 3. We were thinking about calling projects Basecamps. We may have even done it for a bit. I’m not even sure what we did there. But anyway, that was an insight that came up.

Kimberly (03:04): And David, on the tech side of the house, are you doing the same thing with customer feedback?

David (03:09): It’s similar in many ways because on the tech side, we also have customers in the sense that we release a lot of open source software that we’re responsible for. And there’s a bunch of people who use that and they have opinions about how that should change, how that should evolve. But the wonderful thing about the open source customer is they don’t pay us any money, so I don’t feel bad about telling them to fuck off when they’re totally wrong about where something should go. And this is actually a great outlet because you need kind of that shadow to be a presentable professional person when you’re dealing with actual customers like we have at 37signals where you do need to restrain your immediate response because we get a lot of requests where a gut reaction or knee-jerk reaction I should rather say is, “Well, that’s dumb. You should just do this other thing instead.”

(03:58): And as Jason says, the magic here is not or even rarely what they’re suggesting that they want in the product. It’s what they’re revealing that doesn’t work for them or isn’t obvious or it’s just a pain or doesn’t resonate with the language that they’re using. And it’s those anecdotes that actually contain the real magic. That’s where the real gold is. It’s not, could you add this extra checkpoint on this specific screen? Because as it so happens, most customers are not software designers. Their software users, they know what doesn’t feel right. They don’t necessarily know how to make it right and certainly not for a broad class of customers that encompasses everyone we have to service. So you really have to divorce this idea that the customer describes their problems and they are 100% right about those problems.

(04:51): Not the same thing as what you should do in what order you should do it, how you should do it. All of those things you almost have to make it go through the sieve. And then what’s left is just that pain point. It’s just like, this is a real issue. And what’s fascinating about these anecdotes is they often come in very different shapes. One person will suggest this specific feature. Another person will suggest another feature that doesn’t seem like it’s related at all, but it’s all coming from the same core hurt. And your job as a software designer is to realize this constellation of problems is actually the same thing. And there’s a grander simplification that we should make. Because what happens a lot when customers try to design your software for you is they want a patch. They want to just put some duct tape on something that’s sticking up, but you go like, no, actually the reason this thing is sticking up is because the rivets are not the right tolerance.

(05:43): They’re not the right torque or the airflow over the thing is pulling it apart. So just slapping some duct tape on it, do you know what, might fix the issue temporarily, but it’s going to make the whole thing look awful and ultimately it doesn’t solve the underlying problem. So we have that issue on both sides of the fence. And I think that’s why having faith in your own ability to be a software designer, whether you’re designing a piece of open source infrastructure or you’re designing a consumer or professional product is just really important. And I think the greatest example of not having this or the greatest sort of cultural anecdote here was Microsoft. Apple’s charge against Microsoft back in the day was that this is what all they did was they just tabulated all the requests coming in from customers and then they ranked them.

Oh, this thing has 47 requests. So therefore that is the most important thing we should work on. And then another thing has 35 requests, therefore it’s number two. Totally wrong. And it’s not just wrong because software users are not great software designers. It’s also wrong because you will only hear about the kind of inconveniences and hurt that’s sticking out that a piece of duct tape could fix. You’re not going to hear about all the customers who didn’t sign up for your product because it didn’t have the right shape at all for them to be enticed to use it. You’re not going to hear about all the sort of structural problems that the thing has that just aren’t obvious and can’t be articulated by a single customer in an easy way. And that’s your job to represent all of those interests. You take in all the verbal and written communication that you get from customers. And then you are also obliged to advocate for everyone who did not sign up, everyone who did not bother to write support when something is broken. And just as importantly, your ambition for what the products should be.

Kimberly (07:36): This also makes me think about roadmaps and your philosophy about that. We have people writing in like, is this feature on your roadmap? Can you tell me when this feature is coming to the product? Kind of tell us your philosophy about that.

Jason (07:49): Yeah. I mean, we don’t really have one. We have roughly what we’re working on now. Now extends out a few weeks. It used to extend out six weeks. Now it’s a little bit less than that perhaps. But let’s just call it a month. We kind of know we’re roughly working on over the next month. And it’s not that we’re trying to hide the backlog or the roadmap. We just don’t have them. It’s not like there’s like a smoke-filled room in the back where all the secrets are. We don’t have them. We really literally figure it out as we go. And part of that is you launch something new, like the work we put out there into the world, a new feature or something, and that can create ripples in the product that then lead us to new things and new discoveries and new ideas. So if you just lay things out before they exist in the product and you lay out months worth of work before it exists in the product, you’re not leaving yourself open to opportunities that come up because you do one thing and then you do something else.

(08:38): And then you do this thing and someone’s like, oh, that’s a great idea, but what about this? You’re like, oh, that is an interesting idea. And then you start to follow that trail. So we just want to have optionality to follow whatever trail makes sense depending on where we are. The other thing is that it just doesn’t make any sense to think that far ahead. Things change. And also, why dilute your energy and distribute it out seven months? You can only work on so many things right now, just work on those things. And then just when that’s done, think about what you want to do next. It just feels like it’s the right way to do things. And for customers who feel like there’s uncertainty there, the best thing I would always point to is Basecamp’s around for 22 years. So if you’re afraid of uncertainty, we’ve been around for over two decades.

(09:15): Clearly this is a good path forward. The product’s very successful and we figure it out as we go and we always kind of have. And longevity is sort of there. If you’re worried that we don’t know what we’re doing next, we’ve been doing it well for quite a long time. I think that helps to make people feel a lot more comfortable actually versus like, well, this company is making predictions about what they’re going to do over the next six months.That’s not really that comforting. To me, I’d actually be like, that’s actually a bad idea. I feel like they’re not then agile and able to adjust when necessary. I feel like they’re actually quite rigid and not actually paying attention anymore. They paid attention a long time ago and now they’re not paying attention. That’s what a long roadmap would say to me.

David (09:55): I think the other problem is that roadmaps are breeding ground for illusions of agreement, that you think because there’s a bullet point on some roadmap that vaguely sounds like it’s addressing a desire you have for the product, that it’s actually going to fulfill that desire. Very often you’re going to get a feature that’s in the vicinity of this problem, but it doesn’t solve what you’re trying to achieve very well or it doesn’t feel right. It doesn’t have the right shape. It doesn’t have the right handle. And now you’ve bought a product on a premise of future features that you don’t know what shape they’re going to take in their final form. You don’t know whether you’re going to like it and you might very well feel a little bit suckered. You’re buying a product that does not exist yet on this premise of a very vague promise.

(10:46): Usually it’s like one line on that damn roadmap. In Q4, we will deal with whatever, upload permission, something. And then Q4 rolls around and you get this feature and you’re like, “Well, that’s not solving the problem.” And now there’s a bit of snookering there. So I think in general, the good way of buying products is to buy as they exist today. And then anything that comes after that is gravy. You should not be basing your purchase decisions on, “Well, this thing I kind of feel like I really need is coming in Q4.” No, that’s not the way to buy and it’s a way to get greatly disappointed. Now you feel locked in and now all your data’s there and resentment grows and blah, blah, blah.

Jason (11:29): And I think most times when you buy things, you buy things for the way they are now. Like you buy a car for the way it is now. So it’s an odd thing that you’re like, “Well, what is this going to be in nine months? I’ll buy it for that.” It’s a strange way to approach purchasing anything. And to David’s point, I’ll give you a more concrete example, like the word calendar. We’re adding a calendar. Let’s just say someone’s like, “We’re adding a calendar to our product.” It’s like, “Oh, great. I like a calendar. Who doesn’t want a calendar?” And then a calendar comes out and it’s like, “Well, this calendar doesn’t sync with Outlook.That’s useless to me now.” This is a word you’ll hear a lot, which is useless. Or this calendar doesn’t have an agenda view, or I can’t look at a week view, or I don’t like six weeks at a time.

(12:07): I just want to see four weeks at a time. Or I can’t jump four years in advance. People will find all the things that it doesn’t do, but when they hear the word calendar, they’re imagining it’s going to do everything that they want a calendar to do. But naturally it can’t do everything they want a calendar to do because there’s trade-offs in everything. And this is the problem with like, oh, that’s coming or client access or guest access. There’s these broad terms which don’t mean anything other than the wrapping paper, but what’s on the inside? Who knows? And so you can’t be buying things for that. We’ll often get emails from customers saying like, “If you guys would just add this one thing, we’ll buy it.” This is a common thing. And I don’t blame them for saying that, but people do say this all the time.

(12:48): And of course the answer is they still wouldn’t buy it because they’d find one more thing or the thing we delivered wouldn’t be exactly the thing they wanted. And so for anyone listening who’s getting customers or getting prospects or saying, “If you just add this one thing, we’ll buy it.” Or “if you just lower the price 10%, we’ll buy it,” whatever. It’s often not the case. Because again, what they’re imagining is not actually what you’re going to be producing and developing and delivering. So yeah, this idea of illusion of agreement, which goes all the way back to our book Getting Real, where we talk about the illusion of agreement internally while building features. It’s even more of an illusion when you’re describing it to people on the outside who don’t share the same vocabulary, who don’t have the same mindset about what something might mean. So the illusion becomes bigger and more magical and stranger and more impossible to describe as you get outside your own ecosystem, basically.

Kimberly (13:33): Has there ever been a time that we’ve forward promised something like, oh yeah, we’re going to definitely add that. And has that worked out and we’re good with that? Or is that something you regret?

Jason (13:44): It always ends in regret always. And it’s not that the thing that we promised isn’t maybe a good thing that we wanted to deliver. It’s that the promise was set on a timeline way ahead of time. It’s usually by the end of the year. That’s the thing. It’s like March. Well, we’ll do that by the end of the year. Of course we will. It’s like nine months from now or whatever. That’s the thing I always regret. Not necessarily the feature, even though I regret that too, but the bigger thing is like, okay, well, here’s a deadline now that we set for ourselves and we’re going to push off as far as we can. And then all these other things are going to come up and now we have to put one of those aside because of this promise we made nine months ago. It’s always something I regret. And so basically we don’t do that at all anymore.

David (14:24): And this is where all these lessons come from, hard worn mistakes of us promising things or setting out we’re going to do these three things. And the reason it usually turns into regret is that you’re promising this in the future because you don’t want to work on it now. And there is actually the tell. If this was truly so important, you just work on it now. Why are you promising it by the end of the year? You should just be on it right now. But it’s a way to say yes in a weasely way. It’s a way to say yes in a, well, I don’t have to deal with the consequences of that yes today where I actually want to pursue a bunch of other things that I think is important for the evolution of the product. So I’ll push it off such that it’s a later yes, such that it’s Jason in three months who have to deal with that problem. Not Jason today who has to deal with that problem. And I think that’s virtually never a good idea. I can’t actually recall ever us having made a public promise like that where it panned out on the other side like, oh, I’m so glad we’ve promised that. Because you know what? Even if you deliver and even if you deliver what they want, you would’ve been better off just giving that surprise then.

Jason (15:33): Yeah.

David (15:34): Was this anticipation for? What was all of this promissory note for? Well, it was sort of because maybe you’re afraid that if you don’t make that promise, they’re going to leave. That’s a really bad place to be in terms of making decisions about where your product should go. You should not be acting out of this fear. Oh my god, if we don’t do this one thing, then a bunch of people are going to leave. Okay, either that’s real, the threat is imminent and you address it imminently or it’s a figment of your imagination. It’s just sort of brewing in your unconsciousness and you should find a way to deal with that.

Jason (16:10): Yeah. There are a lot of stories we tell ourselves about those things. We’re going to lose a customer, people are going to leave. Maybe. It’s totally possible. But yeah, if it’s really that important… I mean, the most public example of this I think is Apple with Apple Intelligence. They made these promises about, it was like next year or next iOS update or whatever. And they’ve been delayed basically multiple years now. And they felt enormous amount of pressure clearly to say we’re in this game and we need to be part of this. And they couldn’t deliver on what they said. And so now rather than saying like, we’re working on it, we’re working on it to make it better and better and better, whatever they would say. They’re like, we actually missed deadlines. Now we’re behind. They’ve made themselves behind actually by establishing deadlines they couldn’t hit publicly, very publicly. And I understand the pressure. I mean, you can see how this can happen. We are all humans in the end. And there’s a lot of other things going on there with stock price and the market’s expectations and all these things, but it rarely pans out. Not a good idea.

David (17:13): And I think one of the reasons it often ends up in that situation is that the people in charge simply do not have the courage to say no, to stand by their convictions, because the reason you’re getting into this situation is something is misaligned. Where you want to take the product is not straight lining up with it. Either you’re working on something that you don’t yet have the expertise to deliver on, that was clearly the case with Apple Intelligence. They just did not have the team. They didn’t have the technology. They were not ready to launch. They need a lot more time. And I know we mythologize Steve Jobs all the time, but I think that’s a good thing. Especially now that he’s not around to disprove our mythologies around him. We can just take it as this higher ideal, this higher virtue that you imagine Steve just saying like, “This is shit.” He’s looking at some internal product type for Apple Intelligence and all he gets is Genmoji or whatever the fuck they called it.

(18:10): And he would just look at it like, “This is shit. We’re not going to launch this. We’re not going to talk about it. We’re going to get it right and then we’re going to release it.” And maybe we’re late. How many things were Apple late on?Virtually everything? That’s basically their modus operandi is like, “We’re going to be late, but then we’re going to be good.” And they broke that fundamental brand promise with Apple Intelligence and in my opinion, a bunch of other things too. But I think it’s just such a crystallizing example. Even Apple, trillion dollar company is weak and in some ways slightly pathetic when it comes to these questions when suddenly the stakes are high enough. So first of all, you’re excused if you’re also a little weak when even Tim Cook can sit at the top of that behemoth and go like, “Oh my God, I can’t just not say anything. We got to do something.” I mean, that’s actually the phrase, we got to do something. That is very often sort of that expression of fear. I don’t know what. Just something. We got to have something about AI. We got to do something with AI. How many times do you think that phrase have been uttered inside companies as they realize that there’s a huge technological revolution happening right now? We got to do something. How often has something ever turned into anything great? Never.

Kimberly (19:29): I actually was going to bring up AI because I was thinking this is probably, you know, in the last six months some of the feedback, especially David on the technical side that we’ve gotten of AI, AI, AI. And it really is having to, as the product owner, put boundaries of what you want in the product versus just doing what people are requesting.

David (19:49): Yes, because AI is such a great something bucket. It’s the ultimate illusion of agreement. Can you do something with AI? What the fuck do you mean? Can you do something with computer? That makes about as much sense. It needs to be shaped. It needs to be validated. It needs to be good. Like anything else in any part of commerce, in any kind of product, in any kind of service, you don’t want to deliver something. No one wants to buy something. They want to buy good. They want to buy great actually. They don’t most of the time just want to buy good. They want to buy something great. And that very rarely ever comes out of something. Now, that doesn’t mean that you should just ignore the whole world and all the technology changes that are happening and you can just stick to whatever you’ve been doing for 20 years, as it is in our case.

(20:39): You have to be responsive to things changing. But having these knee jerk reactions that are bred out of fear, that are bred out of delivering something just produces the kind of slop that consumers have also been rejecting as of late. Microsoft famously have had to yank out all the AI something that they jammed into MS Paint and they jammed into all sorts of parts of the product where it just didn’t fit and that something made it worse and it made it cumbersome and customers didn’t want it. So as with anything, it’s this balancing act of realizing there are new opportunities, evaluating them and then turning them into something that’s actually valuable. And I mean, we’ve talked about this on the show several times where we’ve tried a lot of things around AI and we’ve gone quite far down, oh, can it help us do this? Can it help us do that? And we’ve occasionally, well, often found like, oh yeah, there’s a glimmer. I can’t ship a glimmer. It’s got to have a final solid shape. Otherwise, I’m just shipping gas. That doesn’t work. We got to get it solidified and we got to get it good. And by the time it is good and it is solidified and we go like, hell yeah, it’ll ship.

Kimberly (21:49): Okay, that is a good place to wrap it up. REWORK is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube. And if you have a question for Jason or David about a better way to work and run your business, leave us a voicemail, a video recording. You can do that at 37signals.com/podcastquestion or email us at rework@37signals.com.

(22:11): David, I’m going to put on a pillow, “I can’t ship a glimmer.”