V1 is for Us
32:43 Share

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 Hansen. 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.

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 them off as a group. So I showed them 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. Is this random? Whatever. And we showed them off.

But the thing is, 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've got to really check yourself pretty quickly. Why are we building this again? 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. Version one is for us. Other people...

Hopefully we'll use it. We'll like it. We'll have the same needs that we have. We'll 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. 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 their 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.

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 a kind of a refresher course for ourselves. And for me also just be like, you know, I, I kind of regret that I said I put that out there the way I put it out there. So that was what that was about.

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 a figment of your imagination.

And I think that is really what drives a great B1. A great B1 has to be a solution to a problem. There can be all these other things we can add on top. There can be all these other things we can extend it into or other excursions you can do. But B1 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. And that's why we've always sucked. The joke from Office to all these products was B1 was going to be terrible. B2 was going to be a little better because now they've gotten some feedback from real customers. And B3, 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. 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. When you're solving your own problems, you're essentially giving yourself a 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 up front, without having to plan it?

all up front. You can let it just flow from the actual sort of problem-solution interaction, and it can bounce back and forth between those two walls 10 times, 50 times, 100 times. And then hopefully, by the time the ball stops bouncing, it's because you've actually solved the bulk of the problem, and now you're in a place that's better.

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 sort of this 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.

Yeah, that'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, 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 like no one else would use if you're tracking flowers, like 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. Like 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.

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. B1 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 and 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 B1 is for you is giving yourself permission to launch with way less than 100% of everything that you imagine other people will want. Because the fact of the matter is, if you're 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 a 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 tradeoff 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 ABCDE. And now your list is 100 points deep.

But you don't know exactly in which order you should do that. 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. Okay. So we talk a lot about hay and base camp 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 B1? And if so, how has that gone? Are there any examples of that? Like we won't do that again because of X product? Yeah.

I can say, for example, when we built High Rise originally, we started out, remember we had to start over after six months of starting on High Rise because we were imagining all these... Wait, hold on. You built it for six months and then scrapped it? Basically about six months. I have never heard this story before. Yeah. We're like, you know what? We wouldn't use this thing that we're making. We're not going to use this. The way I would think about it is like 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 like just trails into the forest and there's a path and then the path is gone. Like, 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, right? 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. 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 like 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 all need, we each need to know, needed to know like, who'd you talk to last? When did you talk to them about what, what do they know?

That kind of stuff. When do you need to follow up next? Like very concrete, real things. And so we got back to basics and build that. However, there were things in that product. Eventually, I don't think we launched with deals. I think we added deals later, but deals was a thing where we built for other people, which is like salespeople who are 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. It's 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 have continued that path into the, into the forest where we didn't know where we were going, we probably never would have shipped the product actually. And it would have been terrible. It would have 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, uh,

We explored some UI ideas early on that went nowhere. And that's okay. That's a little bit different than like conceptually not knowing where we're going. Sometimes you do have to play with an idea. I think I, 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 like not literally knowing where you're going at all.

I think what's so interesting about the HiRise 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 a mediocre conception of the problem paired with excellent execution can actually be competitive.

To this day, HiRise, which we stopped selling, I think we stopped selling it six or seven years ago to new customers, is

still has a dedicated core customer base who's happy with the product. It's a multi-million 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 otherwise solved it better. And this is one of the things we've returned to the high rise question several times over the years because

HiRise 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. Seven figures. Seven figures. Yeah.

That's a very large SaaS success. Eight figures, sorry, eight. Eight figures, yes. And people still ask about it, like still want to sign up for it. 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 high-rise is feeling a little outdated for you, you should go here. So it doesn't seem like anyone else have really cracked it, which just serves us up on a platter as a golden business opportunity. What we should do is build high-rise too.

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 and I, and I think we've had this discussion probably at least three times where we're like, you know what, we should do this. We end up with that problem.

that we don't have this problem. We would be building a CRM tool on behalf of other people, and we could do a very fine job of an institution, 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 it could be a, this could be a great business. I think we could hit it out of the park with HiRISE 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 HiRISE, 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. 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

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

37 singles 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 are 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 so that they all know whether it's good or not. Yeah, it's like impossible to dog food something when people don't actually need it to use it on a daily basis. So what's funny here is we just the last thing we released was Rightbook. And Rightbook 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 use it for our internal technical handbooks. These are, we call them run books sometimes. You're on call and dealing with an hay email issue. And we have essentially a manual for how to operate and service the hay product that the technical staff uses. And 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. I don't know how many times I've used search, 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 quote unquote 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 like, yes, this is exactly why we're using Rightbook. 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. 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 kind of 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 it 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 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 are 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

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. Okay, so let me ask you this because we've talked about V1 for new products 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 like after a product launches, then we're listening to what other people are saying?

We don't really do necessarily version two. I mean, we have with Basecamp in a sense, but they've been, those are year, multi-year versions. Or like updates, feature updates. Yeah. I think, you know, first of all, when you launch something new, the best thing to do is to sit back for a while and not do anything. Especially when you launch something new that's new new. Like Hay is radically different than Gmail on a lot of different fronts. And most of the people using Hay came from Gmail. Yeah.

they are 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. I don't know, 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? You go, oh, and that's a 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 that 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 like,

Why can't I archive my email and hey, it's like, well, technically you can delete your email, but we don't want you to even have to think about that. Like you've been trained by Gmail to feel like you must delete or archive things because your inbox, the way it's structured, like if you don't do that, it doesn't go away. And hey, once you've read something, it goes away naturally over time.

So it just like takes care of itself. But how would you know that until you've used the 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 like 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 just didn't know. I'm not used to that.

So that's the thing you got to be careful of, especially early on. 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 stock 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. 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? Like, 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 cars 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. When I'm faced with new products, I fall into exactly the same trap as every customer we have that come to Hay and complain about where's the trash button, right? 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. 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. It's 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. 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 it's 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?

So Kimberly, I'm going to give you some details too, which is kind of cool. It's kind of getting back to your previous question about like, when do you listen to feedback? So with the let it flow feature in Hay, which again, so for those who don't know, Hay'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 in

And we're like, well, it's going to go away over time. But some people are like, I just, I don't want to see it. Like it's out of sight, out of mind. When I dealt with it, I wanted it to be gone. I'm an inbox zero kind of person or whatever it might be. So one thing for us, we could have done, we could 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, but 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 them 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. You have a picture on your desktop, on your laptop or on your phone. 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 and

versus just falling back on, okay, we'll let you get rid of it. Fine. Just if you'll shut up, we'll let you get rid of it. Instead, I was like, no, no, we have a different idea. So what I like is, 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 like doing it the other way. Like, what can we do that's new and interesting?

And so now when you can teach your email and use, hey, like 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 just a, it's a new thing that you can now think about with email, which is, which is fun. So anyway. 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 it's

solutions. They don't think of the problems they have. They think, 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 take a little here. There's enough feedback. We got a lot. I think actually Let It Flow probably ranks in top three of topics for feedback when we launched Hay 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 it 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 things 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, right? 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. And that's where the really creative stuff comes from. That's where the product design comes.

comes from. We're not just taking these features and putting them 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, it's 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, to some degree, know them better than they know themselves. This is the old asking for a 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.

Okay, I want to do a future episode of every feature that has been started by one of your wives. That'll be next. In here, 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? Yeah, our family calendar. Yeah, totally. Yeah. 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 slash 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 708-628-7850. You can also text that number or send us an email to rework at 37signals.com.