When is enough, enough? – REWORK

version one should just be extremely aerodynamic. Like what is the tightest, smoothest shape of a product we can make? >> At this point, I'd say, you know what, I've written enough programs. I've been writing programs for damn well 25 plus years. I don't need to write another piece of program. I do need to smoothen programs. >> Welcome to Rework, a podcast by 37 Signals about the better way to work and run your business. I'm your host, Kimberly Rhodess, joined as always by the co-founders of 37 Signals, Jason Freed and David Heinmire Hansen. We are putting the finishing touches on a product called Fizzy. It actually might be out by the time this podcast episode is live. But I thought we would talk a little bit today about how we know when it's done. You could continue building and polishing and tweaking forever, but at some point you have to rip the band-aid off. I think that's probably a challenge a lot of people find themselves in. So, let's chat about it. Jason, I know there's a lot happening in [music] the product in these like final hours, final days. When do you stop? >> You know, I've been thinking about this a lot actually because I've been trying to visualize a way to explain this. Other people have asked me this and because usually I go, well, you just kind of figure out what you use and what you don't and then you stop. And there's some of that, but that's not as ex um it doesn't really tell a story. The way I've been thinking about it recently is I want version one to be the most aerodynamic version of this thing that we're making and that every little extra thing sticks out, you know, it just like sticks out of this object and screws up the airflow. So version one should just be extremely aerodynamic. Like what is the tightest, smoothest shape of a product we can make? That's kind of what how I tend to think about it now or I've been trying to think about it that way now. And so part of this is like when you work when you use something that you're building and you go through it and you keep going through it as as you near the launch, you're like, do we need that little thing? Does is that thing creating drag? Do we need that? And you try to get rid of all the little things that are just getting in the way. And that to me is how you do it. So it's about smoothing this object out. Not saying that like we can't add stuff later, but version one has got to be very very aerodynamic. So that's how I've been thinking about it. >> I love it. Put fizzy in a wind tunnel >> kind of, you know, and it's it's actually kind of when you think about it that way, like I know like David brought up something about we have this feature called um saved views or saved filters basically. And he asked uh like you know, hey, how many people are using this? And there's like only a few people using it. And I I think it's a nice thing to have, but I'm actually at the the last minute here, I'm wondering like, do we need that? Is that a burr? Is that creating drag? Like, do we need it for V1? And there's been some other things that have come up that like I know we want in the product, but we don't need it for V1 necessarily. It's just going to create drag. It creates more surface area. And I'm just trying to think about things in in terms of a physical object because I think it's easier to to visualize what that physical object would be, would look like. Um, software is so virtual that it's very very hard for people to ultimately to visualize because you can just keep shoving stuff in there and there's no natural push back. But if things are sticking out and you imagine in a in a wind tunnel, you'd see that white fog or whatever, right? You'd see the wind and you go, "Ah, that's sticking out. We got to get rid of that." So that's my take. This harks back to one of the very first principles we pinned down on product development, which is half, not halfass. That the half that's left after you smooth everything out is invariably likely to be better than if you have a bunch of stuff that you didn't have time to smooth it all out. That's all a little rough. And I often look at these products that manage to do that half not halfass thing which is such an admiration. Jason, in fact, you wrote about the concept 2 rower uh I think last week which a perfect distillation for me. Anyone who doesn't know it, look it up afterwards. It's called the Concept 2 rower and it basically dominates the home high-end exercise equipment for rowers if you're into that stuff and you're not using water. And it's just a product that has barely changed in I don't know how long they've made it. I think at least 20 years or something like that. It has this LCD screen on it. Not a [ __ ] touch pad. An LCD screen with big fat rubber buttons that you have to press and can press when you're both sweaty and exhausted and whatever. And just doesn't do that much. It's just high quality. Not excessively high quality, not luxuriously high quality. just like really wellmade and very few parts and then some thoughtful little touches like the way you can lift it up and it has wheels on the front to easily move it and these other aspects where I've tried a lot of exercise equipment and very little of it especially these days feel like it has the concept to quality to it. So when Jason was blogging with us was like yes that's exactly it. Can we make software products that feel like it's a concept to rower where just it doesn't do more than that? In fact, so many of the things that I end up really enjoying comes from that simplicity of it. There's a bunch of different domains too were actually having to work a little harder to be able to accomplish some things as part of the enjoyment. I've been shooting Leica cameras for many years. They don't have autofocus, which is something I think most people, certainly these days, would take as an essential feature of a camera. What do you mean I have to move this little lever otherwise the picture isn't in focus? That sounds prehistoric or barbarian. And then you use it and you can use it and you're like, "Oh, huge part of the appeal. The joy of shooting a Leica camera is exactly the absence of all of this. the absence of menus, the absence of autofocus, the absence of a million other things. And I think it requires actually a fair amount of arrogant conviction to go like, do you know what? I know we're going to get requests for all these different things. We know it already. I mean, you don't even have to say anything. We could fill out a top 10 list of what people are going to ask for, and we're not going to ship with that. V1, the aerodynamic version, the concept 2 version, the just less version, the manual focus version. The other thing, and we've shipped a lot of things over the years, including um Hey, which we shipped about five years ago. There's several things in Hay that I look back upon now and think like, man, we should have smoothened that out. Jason, you remember the uh the magic door or the magic key? Like you could you had a special email address that could get around your screener. >> Speak easy code. Yeah, >> speak easy code. Now, the problem with that feature was it had such a good name >> that it was almost a darling too cute to kill >> and therefore we couldn't get rid of it, but I've never used the speak easy code. I don't know if you've ever used it. N >> but it was just it was one of those things you get excited about in the moment and then you look back upon it after we're like, "Ah man, we could have smoothened that out." And then there are other aspects of the feature sometimes that feels like it's such a simple thing that turns into basically be the thing, the major thing. Like we were quite late into the development of hay before we came up with the screener. >> Oh. >> Which is now perhaps the single most defining feature of hay. There's a million things that work together in beautiful harmony. But whenever I tell people about hey, I always explain the screener first that no one gets to reach your inbox unless you've said you want to hear from that person. That's just it's a very simple concept. It was not something was difficult or hard to make, but it was essential to it. And you actually accentuate some of those features more. The the few things, a handful of unique elements if you take all the other stuff away. >> Okay. So, a couple weeks ago, we talked about bringing in some beta testers or early adopters into Fizzy before the public launch. Tell me a little bit about getting feedback from those folks and then deciding whether to move forward with that feedback or like okay that's a V2 we're ready to launch with V1 version. >> Yeah I mean we're getting we're getting a good amount of feedback from people. Um and some of it is stuff that we know like yeah it doesn't have that. We know it doesn't have that and maybe down the road it will but right now it doesn't. Um and that's getting back to the like what is the smoothest version of this? What does it really need to have? Like that would be nice to have. It doesn't need that though. Um, what's been interesting, I was talking to Brian about this yesterday. He was surprised. Um, so one of the one of the really interesting things about Fizzy is that so it's a conbon tool. Traditionally, basically every other conbon tool I've ever seen has all the columns open all at the same time. All the cards revealed all at the same time. That's like what conbon historically is. With Fizzy, you can only have one column open at a time. The other ones collapse. And this seems like it could be controversial. I I believe in it very strongly. I've been pushing for it and I really like the way it works. He was surprised that no one who's been beta testing has complained about it because it is such an unusual approach to conbon and it would be the natural first thing for people to say, "Well, I can't open two columns at once." Technically, you have two at once. You have the maybe column which is always open, which is another thing that other conbon tools don't have. Um anyway, long story short is we we made this very conscious distinction between open closed one at a time kind of thing and it seems like it would be the controversial thing. So far though it has not been. It might be when the public gets in and 20 50 100 thousand people try it. Um but so far not come up once, you know. Uh and then it's usually the things that come up are these little nitpicky things which are totally fair game for anyone to to to notice because I've noticed them too. It's just we've decided not to do them. Um, but most of the beta feedback initially is not about um, uh, look mining for new features. It's closing little gaps, little holes, busted things that we didn't know about. It's making sure that our house is in order prior to opening it up to everyone else. That kind of thing. And that's been working out quite well so far. I think we've invited maybe six or 700 people at this point. >> Oh, >> yep. >> That's a lot. >> Yeah. I mean, not we invite them in. People sign up. We invite them in. You get a fraction of those people actually signing up. Um, but we've we've sent about six or 700 invites so far. >> Okay. David, on the technical side of things, are there other things that you're considering of like, nope, we're not ready versus like, h this can wait. We can make this like tweak to the code later. It's interesting because Fizzy in particular, we had a mission to try some really novel new architectural ideas out and we actually ended up yanking them in the 11th and a half hour like just before launch some of the audacious ideas we had on the database side of things we got a little cold feet and I think it's one of the those magic things that happen when you just before launch just before launch you look at some of the features you have and go like do you know what we should get rid of them before we launch or it needs this thing otherwise it's not ready it's not as common that that happens on the back end on the technical side of things but in this instance we had had this audacious science project requires a bunch of new tech approach to some of the database stuff where it just wasn't ready we did not have high enough confidence that it was going to go off without a hitch and we did not want to take that chance even though we had spent an awful lot of time working on it. Now that doesn't mean we can't bring it back. It doesn't mean we can't take some of the ideas in. But in the 11th hour, we actually pulled the plug on an audacious way of doing it and went back in some ways to something that was just a little more tried and true. Mixed in some of the insights we had picked up along the way working on this other novel stuff. But um that's a key part of it. The other thing for me is I've been reading through the whole fizzy codebase. We've had a wonderful team working on it. I have not been writing the majority of the code. I did some of the early work on it and then I did a bunch of other things for a long time and team did great work on it. And then I get the privilege of sitting down and reading this thing like it's a book end to end and just going like oh man I really like this. H you know what this part maybe uh could use a little doover. And I I love that polishing, that editing phase. It's like when in the rare circumstance I have the patience to put an essay aside instead of just [ __ ] hitting publish on Hey World as soon as I've written the last character, which is my normal MMO. If I occasionally leave it for the next day, I always have edits and I always make the essay better. It's just my impatience wins out over my perfectionism. But in this case, it was forced upon me. So I get this privilege of doing this editing phase where I can just carefully massage a few lines of code. And in fact just a few days ago I had the really satisfying experience of clicking with a wart that I did not like and I had looked at it a couple times over the few months. I was like I really don't like this. Ah it seems like such a long way around to fix this problem because I don't like four lines of code. So, I've been noodling on it for literally months, and then the epiphany, as it often is, just arrived in the shower. Oh, I could just do the Oh, and I go into the keyboard and I do the thing and I have this little commit that says minus 7 lines plus two. And you know what? It's funny how these things can be so satisfying. And you think this is a code base of thousands of lines of code and you're getting excited about five lines of code you were able to remove. Yeah, I do. I really do. It's about that smoothening aspect of it. The code has drag in very much the same way as the product itself does. And you can see that smooth surface. Sometimes, in fact, when I'm reading these things, a favorite tactic is, you know what, I lean back and I halfway squint at the code. And sometimes I can just see, do, you know what, that's not the right shape. There's just too many lines up here in this method and it's using too many other things. There's too much indirection. Where's this getting referenced from? I don't have this piece of context now that I'm reading it. That needs to be better. And the act of polishing and massaging the code in this way is actually one of the my favorite parts of writing code at all, making any kind of product is exactly this phase where you just sort of like you just going like you look at it and then you smooth it out a little more and then you look at it again and you go like yeah right there. Right there. There's not a character there's not a comma. There's not a colon that I could move inside this piece of code that would make it better. So satisfying. So satisfying. In fact, so satisfying that I would posit that this is the main reason I still bother programming. At this point, I'd say like, you know what? I've written enough programs. I've been writing programs for damn well 25 plus years. I don't need to write another piece of program. I do need to smoothen programs. And therefore, we must write new ones or occasionally bring out the old ones. they just keep smoothing them, make them more aerodynamic, make them more of a pleasure to read. I don't know why it is. I do know there are other programmers who share this satisfaction of deleting lines of code rather than putting them in. And then there are other programmers entirely who just get excited about solving problems. And I over the years have gotten more excited about the polishing than I have necessarily about solving the problem. And part of it is because we're solving problems in recurring ways. Much of what we do is an embrace of the crut monkey identity. Like what we we write to a database, we read from a database, we update a database, we delete a record in the database. Like that's it. And that's enough. That's enough. Like that problem is able to then power the solution to that problem is able to power something as beautiful as Fizzy. Like I was looking at it at Fizzy a few months back after I hadn't looked at it for a couple months going all in on Umachi and I just kept finding these little touches. One of the things I don't know like we have a couple of Easter eggs and some of them include sound and the one Easter egg I found or I didn't find but was instructed to look for with the sound I just went like isn't that delightful? Like we we're little crut monkeys dancing here in the background doing the little monkey dance for the create and update and delete and then like there's a [ __ ] harp playing [laughter] in the background from what we built. Like how is that not just the most amazing thing you've ever seen? These are sort of those small joys where perhaps some of it is like literally getting older and smelling the flowers like it you I used to think of it as a cliche like stop and smell the flowers. You know what? I [ __ ] stop and smell flowers now. I like I look at trees and I go like, "Man, that's a beautiful tree." Like, I wonder how old that tree is. And part of it is like I have this recurrent model going like, "Do you know what? If you were 20 year olds, you'd laugh at yourself right now." And and the other part goes like, "Yeah, that's right. That's the process of aging. You start appreciating new things, different things. And I now appreciate trees. And I appreciate smelling flowers. And I really uniquely appreciate polishing coat. I think that's the first mention of the Easter eggs in Fizzy. So, I'm excited [laughter] when people >> I didn't reveal it. I just said sounds, harps, music. >> I love it. Well, with that, we're going to wrap it up. Rework is a production of 37 signals. You can find show notes and transcripts [music] on our website, 37s signals.com/mpodcast. Full video episodes are on YouTube. And if you have a question for Jason or David, about a better way to work and run your business. [music] Leave us a video question, you can do that at 37signals.com/mpodcast question. You can also send us an email to rework@37s signals.com and I will link [music] in the show notes to the new fizzy product.

There’s a moment in every product where you have to stop tweaking and actually launch. This week, Jason Fried and David Heinemeier Hansson reflect on how 37signals decides when a product is truly ready for its first release. They share how they think about simplifying, sharpening, and ultimately knowing when it’s time to ship. *Key Takeaways* 00:00 – Episode highlights 00:33 – Recognizing when a product is ready to meet the world 03:29 – Strip things back to the essentials first 08:12 – Weighing real-world feedback from early users 10:44 – Add the final layer of polish without overdoing it *Links and Resources* Fizzy is a modern spin on kanban. Try it for free at https://www.fizzy.do "Quality: The Concept2 RowErg" from Jason's HEY World – https://world.hey.com/jason/quality-the-concept2-rowerg-7f7bb027 Record or upload a video question for Jason and David — https://www.37signals.com/podcastquestion Get a free Basecamp account at https://www.basecamp.com Books by 37signals – https://37signals.com/books 30-day free trial of HEY – https://www.hey.com/ Once. com – https://once.com/ Campfire – https://once.com/campfire HEY – https://www.hey.com/ The REWORK podcast – https://37signals.com/podcast/ Get some REWORK podcast merch – https://37signals.com/podcast/shop *Let's be social!* Twitter/X: https://x.com/37signals Instagram: https://www.instagram.com/37signalshq/ Rework is a production of 37signals. You can find show notes and transcripts on our website https://www.37signals.com/ Leave us a video question at www.37signals.com/podcastquestion or send an email to rework@37signals.com, and we might answer it on a future episode.