Don't write it down

0:00Welcome 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 Base Camp 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?

0:34Don't. Listen, but then forget what people said seriously. I'm going to kick it off with that.

0:40David Heinemeier Hansson:Who wrote that? Did we write that? Just kidding. Yeah. You know, 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, is that especially for a product like Basecamp, we have like 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.

1:14David Heinemeier Hansson: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. 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.

1:43David Heinemeier Hansson:And for the most part, forget what I mean by that is like, 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 like can really, you know, move you to do something. So that's sort of the primary idea. That said, there are, 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.

2:16David Heinemeier Hansson: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. Yeah. And it's kind of fun to go through that and look at some of these words and the way people describe things occasionally. Like I'll remember a long time ago before we were doing this, though, customers used to call projects base camps. They'd be like, I have like a bunch of base camps. And in our head, that means like you have a lot of base camp accounts.

2:43David Heinemeier Hansson:And then you kind of pick up, oh, people call projects base camps. And like 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 sometime in Basecamp 3, we're 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. And David, on the tech side of the house, are you doing the same thing with customer feedback? 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.

3:17And 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 37 Signals, where you do need to restrain your immediate response Because we get a lot of requests where a gut reaction or a knee-jerk reaction, I should rather say, is, well, that's dumb.

3:55Like, you should just do this other thing instead. 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. They're software users. They know what doesn't feel right.

4:34They 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. Not the same thing as A, 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.

5:09One 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 to 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.

5:43They'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 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 important. And I think the greatest example of not having this is the greatest sort of cultural anecdote here was Microsoft, that 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.

6:29and then they rank 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, right? 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.

7:03You're not going to hear about all the sort of structural problems that the thing has that just isn'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 own vision for what the products should be. This also makes me think about roadmaps and your philosophy about that.

7:40We 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.

7:49David Heinemeier Hansson:Yeah, 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. Like we kind of know what 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. Like 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.

8:27David Heinemeier Hansson: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. 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 wanna 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.

8:52David Heinemeier Hansson: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 like, base camp's around for 22 years. So if you're afraid of uncertainty, like we've been around for over two decades, Clearly, like, 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.

9:22David Heinemeier Hansson:And longevity is sort of there. If you're worried that we don't know what we're doing next, like, 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. Like, 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.

9:52David Heinemeier Hansson:That's what a long roadmap would say to me. 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.

10:35You don't know whether you're going to like it. And you might very well feel a little bit suckered, right? You're buying a product that does not exist yet on this premise of a very vague promise. Usually it's like one line on that damn roadmap, right? Like 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.

11:12You 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 logged in and now all your data is there and resentment grows and blah, blah, blah.

11:29David Heinemeier Hansson: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? Like I'll buy it for that. It's a strange way to approach purchasing anything. And to David's point, I'll give you like a more concrete example, like the word calendar. Like 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.

11:55David Heinemeier Hansson:Like that's useless to me now. Like this is a word you'll hear a lot, which is useless. or like 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, I just wanna see four weeks at a time or I can't jump four years in advance. Like 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 like client access or guest access.

12:28David Heinemeier Hansson: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. And I will often get emails from customers saying, 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. 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, Like if you just add this one thing, we'll buy it.

12:59David Heinemeier Hansson: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.

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

13:44David Heinemeier Hansson:It always ends in regret, always. And it's not that the thing that we promise 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 we're like well it's usually like by the end of the year that's like the thing like you know it's it's like march like well we'll do that by the end of the year of course we will it's like you know nine months from now or whatever right 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 So it's always something I regret.

14:22David Heinemeier Hansson:And so basically we don't do that at all anymore. 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'd 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 Weasley 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.

15:04So I'll push it off just 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. I'm like, oh, I'm so glad we promised that. Because you know what? Even if you deliver, and even if you deliver what they want, you would have been better off just giving that surprise then. What 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.

15:46that'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 like 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 yeah there are a lot of stories

16:11David Heinemeier Hansson:who tell ourselves, you know, about those things. We're going to lose a customer. People are going to leave, you know, 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, right? They made these promises about, I don't even like, it was like next year or next iOS update or whatever. And it's been, you know, they've been delayed basically multiple years now. And they felt enormous amount of pressure clearly to say like, we're in this game and we need to be part of this. and they couldn't deliver on what they said.

16:42David Heinemeier Hansson: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 that. 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. 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.

17:27Like 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. Like, 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.

18:03Like he's looking in some internal product type for Apple intelligence and all he gets is Jimoji or whatever the fuck they called it, right? 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. Like how many things were Apple late on? Virtually everything, right? Like that's basically their motors of Barandi 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.

18:37Even 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. Like, 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 has been uttered inside companies as they realize that there's a huge technological revolution happening right now?

19:21We got to do something. How often has something ever turned into anything great? Never. 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 like, AI, AI, AI, and it really is having to, as a product owner, put boundaries of like what you want in the product versus just doing what people are requesting. Yes, because AI is such a great something bucket. It's the ultimate illusion of agreement. Like, can you do something with AI? What the fuck do you mean?

19:58Like 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:39You do 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 slob that consumers have also been rejecting as of late. Right. 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 their new opportunities, evaluating them and then turning them into something that's actually valuable.

21:21And 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. Like it's gotta have a final solid shape. Otherwise I'm just shipping gas, right? Like that doesn't work. We gotta get it solidified and we gotta get it good. And by the time it is good and it is solidified and we go like, hell yeah, it'll ship. Okay, that is a good place to wrap it up. Rework is a production of 37 Signals.