SEASON 2 - EPISODE 129 - OCTOBER 30, 2024

V1 is for Us

In this week’s episode of The REWORK Podcast, 37signals’ co-founders Jason Fried and David Heinemeier Hansson share their approach to product design, explaining why the first version of a product (V1) is always built for the company’s internal use case. They discuss responding to user feedback and the importance of actively using their own products to uncover issues. They also dive into the challenges they’ve faced when building software for someone else’s needs vs. their own.

Watch the full video episode on YouTube

Key Takeaways

00:35 - The problem with imagined use cases
07:21 - A trimmed down V1 gives you permission to focus on what’s most important
10:28 - The story of Highrise
17:27 - “Dogfooding” to help identify and address product issues
20:48 - Avoid the temptation to react too quickly to early customer feedback
23:11 - Design breakthroughs come to life by creating innovative solutions

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 I’m joined as always by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. Well, if you’ve listened to the podcast for any period of time, you’ve heard Jason and David talk about building software for us, that 37signals uses all of its own products. We use Basecamp to build Basecamp, and just how that is an important focus for the company. I thought we would talk more about it today. Jason, you recently explained to the company, again, that this is an important priority for us. Kind of tell us a little bit about that.

Jason (00:34): Yeah, so we just had our meetup in Montreal and we showed off two products that we’re working on internally. These have been sort of discussed internally, but we’ve never showed ‘em off as a group. So I showed ‘em off with two of the designers and I was sort of referencing use cases like this could be used for this and this could be used for that. And we even showed examples of it being used for tracking which flowers you have in your garden as this random whatever. But the thing is, and I gave the presentation and it made the points, but I actually had this tinge of regret afterwards, which was why am I showing things that it could do? Why do we have to imagine use cases? Whenever you do that, you got to really check yourself pretty quickly. Why are we building this again?

(01:16): Because we’re imagining how people might want to use it. They might use it for that reason, but it can’t be built for an imaginary reason. It has to be built for a real reason. And by the way, these products we’re building are built for a real reason, but I felt like I had to justify them in a sense, or it was like a demo. So let me show you all the things it can do, but it was a red flag. And so I posted something yesterday actually internally saying like, hey, we need to get back to remembering why we’re building these things and specifically why we’re building version one. And version one is for us. Other people hopefully will use it, will like it, will have the same needs that we have, will want the same product for the reasons we want it, but it has to be for us, it has to be tied to our use cases.

(01:53): And in fact, we should tie even a tighter knot and not have to imagine any external use cases. That’s not to say that it can’t be used for other things. For example, when we built Basecamp, version one of Basecamp was entirely 100% our use cases, and it turns out a lot of other companies have very similar things they need to do, and it turns out that they’re not just in the web design field, which is what we were in, but they’re churches and schools and publishers and manufacturers, they all have something very similar to what we had, which was we need a way to communicate with people we’re working with, tell them where things are, get their feedback on the record, set up some milestones and deadlines, some to-dos so people know what to do. All those things are universal regardless of what industry you’re in.

(02:34): And I think the thing that we’re working on can be widely applicable, but we don’t need to make those cases. We can just make our case and the product will be better for it. So I wrote this up internally, I’ll be writing something up publicly by the time this is out, there’ll be something up publicly about this, but it was just kind of a refresher course for ourselves and for me also just be like, I regret that I put that out there the way I put it out there. So that was what that was about.

David (02:58): I think the problem with these imaginary use cases is that it becomes very difficult to gauge the quality of your implementation when you’re holding it up against the fantasy. You can gauge whether you’re solving a real problem, you actually have, because you see whether it disappears or at least whether it gets better. And you can’t do that if the problem is just the figment of your imagination. And I think that is really what drives a great v1. A great v1 has to be a solution to a problem. There could be all these other things we can add on top. There could be all these other things we could extend it into or other excursions you can do. But v1 must solve something real. It must take some pain away, preferably. And I think it’s one of the reasons why if you looked at the historic model of some companies like Microsoft where they would start with a v1 of something that did not have the sense that they were solving their own problems, they were solving for imaginary customers.

(04:00): And that’s why v1 always sucked. The joke from office to all these products was v1 was going to be terrible, v2 was going to be a little better because now they’ve gotten some feedback from real customers and v3 that was the one you wanted to jump in on. That was when it got real because now the company had not just imaginary problems to work on, but they had the real feedback to come into it. And I think, you know what? We’re not willing to wait for v3 before we make good software. And the only way we know how to skip through all of that is by starting with the real problems that we can solve for ourselves. The other aspect of this is it’s just easier to drive motivation that way. And not just motivation, but even the nitty gritty of what should we work on next?

(04:44): When you’re starting on a new product, there’s usually a billion different things you can work on, a different version of the feature, additional features, but when you’re working on solving your own problems, that road paves itself. You’ll fix one thing and you’re using it and you’re using, and you’ll immediately notice what the next most important thing is. So when you’re solving your own problems, you’re essentially giving yourself the roadmap to completion that just goes straight through, what do I need? What is the next thing that I need? Without having to imagine it all upfront, without having to plan it all up front. You can let it just flow from the actual sort of problem-solution interaction and it bounce back and forth between those two walls 10 times, 50 times, a hundred times, and then hopefully by the time the bolt stops bouncing, it’s because you’ve actually solved the bulk of the problem and now you’re in a place that’s better.

(05:42): And that’s really the main realization, especially for us when we’re solving our own problems. Whatever problem we’re trying to solve, we’re already trying to solve it. We will have patched something together, we will be using a tool that’s not quite right for that use case, and then it becomes quite easy to evaluate this sort of duct tape version that we were already doing, whether we were doing it on email or our own systems or using someone else’s. Is that better than the new thing we came up with? By the time the new thing is substantially better, we’ll know it’s time to release.

Jason (06:12): Yeah, it’s a great point. In fact, this thing we’re building, we’re already doing this in Basecamp, this thing that this thing is going to do, sorry for being vague again, it’s just too early not to be vague. We’re doing it today. And the truth is pretty much whatever product you’re making, someone’s already doing it some way, they’re already doing it one way or another. So to David’s point, there’s a crossover point where you’re like, oh, this is better than what we have and what’s actually exciting about this, and when I wrote this post yesterday, it already just triggered a bunch of ideas in my head because now I feel like I have the freedom to actually pay more attention to what we really, really need and not worry about the fact that some of it might be kind of specific to our need. Before, it’s easy to push that off and go, that’s a weird thing that no one else would use. If you’re tracking flowers, you wouldn’t use this other thing. But if you’re tracking this other thing, you absolutely need that. And now there’s no excuses anymore. If we’re just building the thing that we need for the thing that we’re tracking, it allows us to be very specific and make features that really make sense for us and not actually reject the things that we really need, but realize that they might not fit for other use cases. So it’s great.

David (07:21): What I love about that too is it’s not just guiding you, it’s giving you permission. When we worked on HEY for example, we were very adamant about following this principle. V1 is for us. Email is an incredibly deep problem domain. We knew from the outset there was no way we were going to match every feature that exists in Gmail, but we were going to match the ones we needed, Jason or I in particular for our daily heavy email use. And one of the examples of something we did not need was signatures. HEY launched without automated signatures. You had to either manually write it or my preferred style, not have one at all. Now, it was one of the things we added quite quickly after launch because it turns out there are a lot of people who use signatures in emails for all sorts of reasons, but committing to the idea that v1 is for you is giving yourself permission to launch with way less than a hundred percent of everything that you imagine other people will want.

(08:21): Because the fact of the matter is if you just matching everyone with their existing solutions, do you know what? There’s no reason for them to pick you. You have to be novel, you have to be above, you have to be different, and that’s the place to start. So with HEY, we really started on solving the kinds of problems that did not have a solution in Gmail, did not have an compelling answer. The Screener, for example, there’s no such thing in Gmail as putting everyone who writes you for the first time into this quarantine box. So focusing our time on that versus on a signature feature, that’s the right trade-off for V1. Now after V1, that’s when you get the feedback, that’s when you hear from everyone. But even that, even postponing that moment is great because it’s very easy also to imagine, oh, people of course going to want A, B, C, D, E, and now your list is a hundred points steep, but you dunno exactly in which order you should do that.

(09:17): When we released HEY, the v1 was awesome for us, and then we got the direct feedback from people actually using the product, not a focus group, not a what would you use if I had this product to sell you, but an actual user going like, oh, I really like your novel ideas, but I really need this and I really need that. And that feedback again, just takes the guessing out of the planning because it almost takes the planning out of it and you’re just reacting to reality, which the fewer abstractions you can have between yourself and reality in this interchange as you’re developing problems I find the easier it is, the less coordination you need, the less sophisticated planning, the less sophisticated tracking. It becomes more basic because in the large part you are just trying to nail those basics and you’re letting the product to a large degree drive itself.

Kimberly (10:08): Okay, so we talk a lot about HEY and Basecamp here on this podcast. I’m curious with the company’s history, we’ve made lots of products over the years. Have there been products that you’ve made not for yourselves as a v1, and if so, how has that gone? Are there any examples of that? We won’t do that again because of X product.

Jason (10:28): I can say for example, when we built Highrise originally, we started out, remember we had to start over after six months of starting on Highrise because we were imagining all these…

Kimberly (10:36): Wait, hold on, you built it for six months and then scrapped it?

Jason (10:40): Basically about six months.

Kimberly (10:41): I’ve never heard this story before.

Jason (10:43): Yeah, we’re like, you know what this is, we wouldn’t use this thing that we’re making. We’re not going to use this. The way I will think about it is you’re going down this paved road and then at some point the paving goes away and then you’re on a dirt road and then the dirt road sort of just trails into the forest and there’s a path and then the path is gone. I don’t know where we’re going anymore. I have no idea. I kind of know how we got here, but I don’t know where to go now. That’s the scariest place to be in product development is not knowing where to go next. And that’s where we were. We’re like, because at that point you can go anywhere. Well, let’s imagine this. Let’s imagine that. And everything is equally great because the ideas maybe are good, but they don’t apply, they don’t make sense.

(11:19): So we ended up scrapping it about six months in and we started with a new direction, which is, okay, let’s get back to why are we building this? David and I had this issue where we were talking to a lot of people in the press and lawyers and accountants and people like that, and we had these conversations that we had to pass the baton on because maybe I wasn’t available for it and David was or David was and I wasn’t or whatever it was. And we each needed to to know who’d you talk to last? When did you talk to ‘em about what? What do they know? That kind of stuff. When do you need to follow up next? Very concrete, real things. And so we got back to basics and built that. However, there were things in that product eventually, I don’t think we launched with Deals.

(12:04): I think we added Deals later, but Deals was a thing where we built for other people, which is like salespeople who were trying to close deals and it was mediocre at best. I think the implementation was good, but the idea was mediocre at best because we didn’t really sell things. We don’t track people in a funnel, we don’t do that. So we had to imagine what would it be like to do that? And you can talk to a bunch of people and get a bunch of ideas, but you still have to imagine it at some level because you can’t fill in all the gaps with your own experience. So that happened, and I mean ultimately the product turned out great, but if we would’ve continued that path into the forest where we didn’t know where we were going, we probably never would’ve shipped the product actually.

(12:44): And it would’ve been terrible. It would’ve been literally terrible. Even if the execution of the individual features was good, there would not have been a cohesive idea that made any sense. And so that’s why we redid that. And there’s been other things. Basecamp 3, we explored some UI ideas early on that went nowhere, and that’s okay. That’s a little bit different than conceptually not knowing where we’re going. Sometimes you do have to play with an idea. I think let’s try this, and you’re like, this doesn’t work, and you can back off of that and then just re-execute the idea the same idea in a different way. That’s different than not literally knowing where you’re going at all.

David (13:23): I think what’s so interesting about the Highrise example, this CRM tool is first of all what we ended up building, even though only part of the problem was a problem Jason or I shared with the potential customer base was surprisingly good. And this is just an interesting piece of feedback in the sense that sometimes even just the mediocre conception of the problem paired with excellent execution can actually be competitive. To this day, Highrise, which we stopped selling, I think we stopped selling it six or seven years ago to new customers, still has a dedicated core customer base who’s happy with the product. It’s a multimillion dollar a year SaaS business in and of itself all these years later because we cracked something in that problem space, even if we weren’t necessarily always thrilled with the conceptual purity of what we had cracked and no one had else had otherwise solved it better. And this is one of the things we’ve returned to the Highrise question several times over the years because Highrise is probably the second most successful product we’ve ever launched. At its height, it was a huge SaaS business, not as big as Basecamp, but number two.

Jason (14:36): Seven figures.

David (14:37): Seven figures, that’s a very large SaaS success.

Jason (14:41): Eight figures, sorry, eight.

David (14:43): Eight figures. Yes.

Kimberly (14:44): And people still ask about it, still want to sign up for it,

David (14:47): People still ask about it, they still request more to it, they’re still using it. And when I look at the landscape of SaaS or of CRM tools, I often fail to see anything I would find as an obvious recommendation. Oh if Highrise is feeling a little outdated for you, you should go here. So it doesn’t seem like anyone else have really cracked it, which is surfaces up on a platter as a golden business opportunity. What we should do is build Highrise 2. Clearly there’s an existing customer base, there’s an existing opening in the market, people really want it. And we’ve proven before that that was a huge success. And whenever we get down that path, Jason or I, and I think we’ve had this discussion probably at least three times where we’re like, do you know what? We should do this. We end up with that problem, that we don’t have this problem.

(15:32): We would be building a CRM tool on behalf of other people and we could do a very fine job of an execution, but we could do a mediocre job at analyzing the problems and coming up with something good. And do you know what? That’s just not as fun. That’s really the root of this. It’s not that this could be a great business. I think we could hit it out of the park with Highrise 2 compared to what we had, but not compared to our standards of tackling a problem that we have all the time. I think especially with Highrise, we saw this phenomenon too where Jason and I had to find a problem that we really did have, and that was why the core of the product was solid, but the majority of people we involved from the rest of the company, they didn’t have this problem at all.

(16:18): They had no connection to the underlying problem space, and they were entirely reliant on hearing from customers and trying to guess what customers would enjoy. They had very little ability to gauge the quality of what they were solving, and that’s just really difficult. So even if you have a problem space where the founders or the product managers have some conception, you’re putting yourself up for a little bit of an uphill road if the people implementing it don’t have any relation to the problem. Versus something like Basecamp. Literally every single person at 37signals uses Basecamp all day long. We could have any one of them tell us whether almost any feature is good or bad, and that is what allows our quality to stay as high. So committing to that and making sure that all new products that we work on fall into this category, that at the very least it’s got to be Jason and I, our problem, we have to know the problem. And preferably it’s got to be something that a fair share of the rest of the company also has. And even better if it’s something everyone can have an opinion on, such that they all know whether it’s good or not.

Kimberly (17:27): Yeah, it’s like impossible to dog food something when people don’t actually need it, to use it on a daily basis.

David (17:32): So what’s funny here is, the last thing we released was Writebook. And Writebook was a slam dunk for a bunch of different things that we do, but it wasn’t or isn’t even yet quite the slam dunk for one of the key use cases we had in mind, which was to it for our internal technical handbooks. These are, we call ‘em runbooks sometimes. You’re on call and dealing with a HEY email issue and we have essentially a manual for how to operate and service the HEY product that the technical staff uses and do you know what? One of the things that was missing was search. So we were using a system before that had search. Writebook didn’t have search because the initial focus of it was more on a narrative. You’re reading a book from one end to the other end, you don’t need to, search is not that important.

(18:21): I don’t know how many times I’ve used searched say on my Kindle. I just usually read a book from one end to the other. Not that important. When it comes to run books, very important. It’s actually reference material. It’s a reference manual. You look it up. So we had inserted Writebook as dogfooding into it, and we had like, a small rebellion. Just a few weeks ago we had a small rebellion where the people doing the technical work, who were being “forced” to use Writebook, were in open revolt. I’m not going to use Writebook anymore for this. It’s just not suitable. And I really had to grab hold of that and go, yes, this is exactly why we’re using Writebook. This is exactly why there will not be permission granted for you to use something else because we need to capture this dissatisfaction. We want this product to be good for reference material because that’s what we will use it for on a weekly basis going forward.

(19:13): We have to solve these problems. And I actually really enjoyed that wrestling with one of our own problems and one of our own products not kinda quite fully fitting and having to realize, you know what? We have to make this fit. Because the moment we take something like Writebook and we put back on the shelf and we don’t really use it, that’s when software goes to shit. When companies themselves are not really using it. This is the essence of dogfooding. You start not noticing what seems totally obvious to every customer who’s downloading it and trying to use it. This is something that I marvel over many times when I use SaaS software. You go through their onboarding flow and just how could someone miss this? This is right in front of every new customer. Well, the people who were working on it are very rarely new customers. Jason and I had that experience walking through onboarding on some of our products in the past where we go like, wait, what? This is the screen that’s number three. What the hell is that doing there? That’s a terrible way of onboarding people. That’s what everyone sees. So it’s one of those weird circumstances where when you make a product, sometimes you are the last to know about the most obvious faults and flaws that product has if you’re not right in the hot path of what a normal user or customer would be exposed to.

Kimberly (20:31): Okay. Let me ask you this because we’ve talked about V1 for new product only for us internally, what our needs are. Tell me a little bit about V2 and V3. Like when does customer feedback come in? Is that not until V3 or is it after a product launches then we’re listening to what other are saying.

Jason (20:48): We don’t really do necessarily version two. I mean we have with Basecamp in a sense, but those are year, multi-year versions.

Kimberly (20:55): Or like updates. Feature updates.

Jason (20:58): Yeah. I think first of all, when you launch something new, the best thing to do is just sit back for a while and not do anything. Especially when you launch something new that’s new, new. HEY is radically different than Gmail on a lot of different fronts and most of the people using HEY came from Gmail, they’re going to naturally knee jerk and expect it to be like Gmail. Some stuff you just need to get used to, you need to grow into. Some stuff we could have done wrong, but it’s very hard to parse that out initially. Complaints, praise, it all floods in, you just sit back and let it wash over and then you kind of start to pay attention in a few months, maybe sometimes or a few weeks, whatever it is, depending, and you’re like, now what’s coming up? What’s coming up now that people are used to this thing or have tried this thing?

(21:40): You go, oh, and that’s that’s really good point. Or yeah, that isn’t as good as it could be or, gosh, I hadn’t thought about that, but that would really make a lot of sense and I want that too. So that’s what you do. But what you got to be very careful of is knee jerking, especially when there’s something brand new that’s different because the momentum and the history the people are going to bring to a product, the expectations they have are typically of what they’ve been doing in the past. And so if you’re just going to revert back to the way people did everything before then you’re not breaking new ground anymore. You’re actually patching up the ground and going backwards. Sometimes you got to break new ground for a while before people get it. I still hear from people today, why can’t I archive my email in HEY?

(22:18): And it’s like, well, technically you can delete your email, but we don’t want you to even have to think about that. You’ve been trained by Gmail to feel like you must delete or archive things because your inbox, the way it’s structured, if you don’t do that, it doesn’t go away. In HEY, once you’ve read something, it goes away naturally over time, so it just takes care of itself. But how would you know that until you’ve used a thing for six weeks, you’re like, oh yeah, that’s actually kind of nice. I don’t have to think about archiving everything or making a decision. I can read it and decide later or never and it takes care of itself. So I still get that from people and we still kind of refer to it as letting it flow. Just get used to letting it flow, let it flow for a while, see how it goes. And some people will still protest, but many people go, yeah, you know what, that is better. I didn’t know. I’m not used to that. So that’s the thing you got to be careful of, especially early on.

David (23:11): A great example of this for me recently, even knowing this, even internalizing this, even repeating this to myself when I hear customer feedback was, I got a new car, I got a Tesla. And that Tesla did not have a stalk to put the car in gear. It had a swipe, and just as soon as I heard that it had a swipe that to go forward or put it in reverse was something I had to interact with a piece of software I recoiled. I was like, that is the stupidest idea I’ve ever heard. What if I need to do a three point turn? It’s going to be just swiping back and forth. It’s going to be so annoying. And unfortunately, I had the email address of one of the people involved with the design of this model, and I sent this email five seconds after I had used the car, right?

(23:58): This is so stupid. I wish it just had the thing I was used to. And what he wrote back to me was exactly what Jason said. He was like, give it five minutes. And I’m like, I’m never going to change my mind. And now begrudgingly, I have to accept that that’s just not a problem at all. You somehow get used to the swiping, you’re not even looking. There’s no problem with three point turns. I’m no slower. In fact, if anything, maybe I’m even faster. Like the physical moving of some of these reverse or forward gear levers you can have in traditional costs can actually be slower. And I use that example to remind me all the time that even when you know this, it’s very difficult. Changing habits, changing expectations. Humans just don’t like that at all. I’m a human. I don’t like that at all.

(24:48): When I’m faced with new products, I fall into exactly the same trap as every customer we have that come to HEY and complain about where’s the trash button. So I think some of this comes with a confidence too, that you’ve picked the way it is for a reason. Sometimes you get feedback and you’re like, oh, I hadn’t designed that at all. I don’t know why it’s like that, but how emails flow in HEY? No, that was a very conscious decision that came from Jason and I using Gmail for literally two decades and realizing why do I constantly have to clean up after myself? This is a computer, can’t it just clean up after itself? Why am I putting everything back into the right boxes? Can we just let it flow? So when you have that and you get feedback, the easy thing is to go like, oh, I got it wrong.

(25:37): We better change that really quick. We’re getting all this feedback and this is why you have to lean back and go, do you know what? I should have some confidence that we are good software designers and if we have thought something through, it’s not crap just because the early knee-jerk reaction from even a lot of people is, I don’t like it. A lot of things are acquired tastes. And when you acquire that taste, it’s not even necessarily that you just go to not mind it anymore. For a lot of people, you grow to really love it. That a lot of people who’ve found something that they initially didn’t like, this even goes with designs, oh, I don’t like how that car, for example, looks. I’ve had that with a bunch of cars and then six months later or three months later, I’m like, oh, this is one of the most beautiful things ever.

(26:20): How does that work? I don’t know. But having the confidence in your decision making and having confidence in your own abilities as a product designer I think is just really important because you’re never going to be able to push through with real breakthroughs unless you have some of that, because everyone casts everything that they use in the context of something similar that they were already doing. And if you’re just going to cave to all of that, you’re going to end up with what they already had and then what’s the point of whatever you’re making anyway?

Jason (26:52): So Kimberly, I’m going to give you some details here, which is kind of cool. It’s kind of getting back to your previous question about when do you listen to feedback. So with the Let It Flow feature and HEY, which again, so for those who don’t know, HEY’s inbox is divided into two sections. So New for You, unread emails are always grouped at the top, and then stuff you’ve seen is at the bottom and stuff gets pushed off at the bottom over time. Okay? That’s structurally how it’s set up. Some of the feedback we got was like, I don’t like to see stuff that I already dealt with. And we’re like, well, it’s going to go away over time, but some people are like, I don’t want to see it. It’s out of sight, out of mind when I’ve dealt with it. I want it to be gone.

(27:28): I’m an inbox zero kind of person or whatever it might be. So one thing for us we could have done, we have added a preference, for example, or maybe we added an archive button or there’s a lot of things we could have done, but what we did was we said, no, philosophically let it flow is correct. We’re going to stand by that. What we are going to do is do something brand new. No one’s done before because they haven’t had this section called previously seen before, is we’re going to let you put a piece of artwork over this section. So it’s going to hide the emails that you’ve seen that you don’t want to see anymore, and you’re going to be able to replace ‘em with a picture of your family or a vacation or something that you actually want to look at, just like you do on your desktop, how you have a picture on your desktop, on your laptop or on your phone.

(28:09): Why shouldn’t email have what we call cover art? And so it allowed us to say, we’re not changing the idea, but for those who want to cover it up, we’re actually going to give you something else that’s more interesting versus just falling back on, okay, we’ll let you get rid of it, fine, if you’ll shut up, we’ll let you get rid of it. Instead of was like, no, no, we have a different idea. So what I like is I like the challenge of figuring out an alternate solution to a problem that I understand is a problem for some people, but not just giving into it and doing it the other way. What can we do that’s new and interesting? And so now when you can teach your email and use HEY, you get to look at your family if you want, or you get to look at a vacation photo that you took or a place you’re going. We hired a bunch of artists to create a bunch of them for us as well, so if you want to use one of those, you can use one of those. So it’s a new thing that you can now think about with email, which is fun. So anyway.

David (29:01): What I love about that is it’s such a perfect example of not listening to the requests that users make, but listening to the problems that they have. This will come to you as, I need a delete feature. I need a trash or an archive. That’s what I had in Gmail. That’s what I want, but that’s not your problem. Your problem is I don’t want to see things I’ve dealt with. But it’s never articulated like that because that’s just not how most people think. They think in solutions. They don’t think of the problems they have. They’re thinking, what would I do to make this go away? And what is this I want to make go away? I don’t even necessarily know. I can’t necessarily even articulate that my problem is I don’t want to see things I’ve dealt with. I just think archive button, delete button, and this is where Jason went in and went, all right, let’s dig a little here.

(29:54): There’s enough feedback. We got a lot. I think I actually let it flow, probably rans in top three of topics for feedback when we launched HEY and for new users who adopted it. So there was enough there where we couldn’t just lean back, wait five minutes and it would go away. It was clear this wasn’t going away. And I heard about personally, like every week until we implemented cover art from my wife who were very annoyed by the fact that she couldn’t make the thing she dealt with go away. And I kept trying to argue the philosophical point, just let it flow. And she heard the point, presumably over several weeks and it wasn’t enough. So the underlying digging here is, okay, I hear what you’re requesting that’s coming in here, but what I really need to hear is what the problem is. And we need to dig in that.

(30:44): And that’s where the really creative stuff comes from. That’s where the product design comes from. We’re not just taking these features and putting ‘em into fucking some Jira feature factory thing and then stuff is just spit out on the other side. No, there’s actually a filter, an analysis that goes into listening to requests, trying to dig in, find the underlying problem, and then come up with something novel in response. And now what I love about the cover art feature is that I’ve heard from so many people who totally had the, I don’t want to see things I’ve dealt with problem, who love cover art way more than they ever loved their delete button than they ever loved their archive button. It’s not that we just solved the problem that they had is that you delight them in turn. And I think that’s how you create a deep bond with someone with a product when you’re able to some degree know them better than they know themselves. This is the old asking for faster horse, getting a car issue, right? You’re not going to hear the novel product design in most cases from people directly. You have to come up with that.

Kimberly (31:53): Okay, I want to do a future episode of every feature that has been started by one of your wives. That’ll be next.

David (32:02): In HEY there’s a good bit, actually. I wouldn’t say, I mean half of the calendar, Jason, isn’t that basically your family use of a calendar, paper calendar?

Jason (32:09): Yeah. Our family calendar. Yeah, totally. Yeah.

Kimberly (32:12): Okay. Well, that is a perfect explanation of how we do V1 for ourselves and our families. Until next time, 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 X. 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.