When is enough, enough?

10 Dec 2025 · 18 min

Ask about this episode

Ask anything about it. ChatGPT or Claude reads this page and answers with the times it was said.

Connect VO and ask about every podcast you hear, including the moments you saved. Add to ChatGPT · Add to Claude

In short

REWORK Podcast Episode Summary: When is enough, enough?

Episode Overview In this episode of the REWORK podcast, co-founders Jason Fried and David Heinemeier Hansson discuss the delicate balance of product development: knowing when to stop tweaking and launch a product. Their reflections center on the recent development of their product, Fizzy, and the principles guiding their decisions.

Key Takeaways

  1. Recognizing Readiness (00:12)
  2. Importance of knowing when a product is ready for launch.
  1. Simplification (02:55)
  2. Emphasis on stripping a product down to its essentials to achieve clarity and focus.
  1. Real-World Feedback (07:32)
  2. The value of early user feedback in refining the product.
  1. Final Touches (10:03)
  2. Adding the final layer of polish while avoiding over-complication.

---

Detailed Insights

  1. Recognizing Readiness
  2. The Launch Dilemma: Jason articulates the challenge of knowing when a product is done, comparing the process to aerodynamics. He believes the first version should be "aerodynamic," with unnecessary features stripped away.
  3. Metaphor of Aerodynamics: He likens features to drag in a physical object, suggesting that any additional element that complicates the user experience should be reconsidered before launch.
  1. Simplification
  2. “Half, not half-assed” Principle: Jason mentions a foundational principle of their approach: focusing on a core set of features that can be polished rather than releasing a cluttered product that lacks clarity.
  3. Visualizing the Product: He encourages thinking about a software product as a physical object, making it easier for teams to identify and eliminate features that do not contribute positively to the user experience.
  1. Real-World Feedback
  2. Beta Testing Insights: The conversation transitions to the importance of beta testers. Jason notes that initial feedback from around 600-700 beta users has primarily focused on minor fixes rather than new feature requests.
  3. Unique Approach to Kanban: Their product Fizzy introduces a novel Kanban system where only one column is open at a time, which has not drawn complaints, contrary to expectations.
  1. Final Touches
  2. Polishing Code: David shares his experience in reviewing the codebase, comparing it to editing writing. He emphasizes the satisfaction of refining code and removing unnecessary complexity.
  3. Balancing Novelty and Reliability: They discuss the decision to pull back on ambitious technical features just before launch, highlighting the importance of confidence in the product’s architecture.

---

Key Concepts Discussed

  • Aerodynamics in Product Design: The metaphor of aerodynamics to describe the need for simplicity and focus in product design.
  • Feedback and Iteration: The iterative process of product development, where real-world usage informs final adjustments.
  • The Joy of Polishing: Finding satisfaction in the meticulous process of refining both code and product features.

---

Resources and Links

  • Fizzy: A modern kanban tool, available for free trial at [fizzy.do](https://www.fizzy.do/)
  • Quality: The Concept2 RowErg: Jason's article on quality [Read here](https://world.hey.com/jason/quality-the-concept2-rowerg-7f7bb027)
  • Books by 37signals: Available at [37signals Books](https://37signals.com/books)
  • Basecamp Free Trial: Sign up [here](https://basecamp.com/pricing)
  • More from REWORK: [The REWORK Podcast](https://www.rework.fm/) and [YouTube Channel](https://www.youtube.com/@37signals/podcasts)

---

Closing Remarks The discussion concludes with an invitation for listeners to engage with the podcast by submitting questions and feedback, emphasizing the ongoing journey of product development at 37signals. The episode reflects the co-founders' commitment to simplicity, quality, and user-centered design in their products.

Written by AI. May contain mistakes. Listen to the episode to check what was said.

Hear the part that matters, and keep it.Open this episode in VO. Double tap your headphones to save a moment as you listen.
Get VO free

Transcript

Automatic transcript. May contain errors.

0:00Welcome to Rework, a podcast by 37 Signals, about the better way to work and run your business. I'm your host, Kimberly Rhodes, joined as always by the co-founders of 37 Signals, Jason Fried and David Heinemeier-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 bandaid off. I think that's probably a challenge a lot of people find themselves in.

0:32So let's chat about it. Jason, I know there's a lot happening in the product in these like final hours, final days. When do you stop? I've been thinking about this a lot, actually, because I've been trying to visualize the way to explain this. Other people have asked me this and because they usually 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 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.

1:05You 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 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 use something that you're building and you go through it and you keep going through it as you near the launch, you're like, do we need that little thing? is that thing creating drag? Do we need that? And you try to get rid of all the little burrs and all the little things that are just getting in the way.

1:39And 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, when you think about it that way, like David brought up something about, we have this feature called saved views or saved filters, basically. And he asked, you know, hey, how many people are using this? And there's like only a few people using it. And I think it's a nice thing to have. But I'm actually at the last minute here, I'm wondering, like, do we need that?

2:11Is 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 terms of a physical object because i think it's easier to visualize what that physical object would be would look like the 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 pushback but if things are sticking out and you imagine it 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 rid of that.

2:54So that's my take. This harks back to one of the very first principles we penned down on product development, which is half, not half-assed. 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 is all a little rough. and i often look at these products that manage to do that half not half ass thing which is such an admiration jason in fact you wrote about the concept to rower 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 to rower and 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 fucking touch pad an lcd screen with big fat rubber buttons that you have to press i 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 well made 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.

4:36So when Jason was talking about it, it was like, yes, that's exactly it. Can we make software products that feel like it's a Concept2 Roar? 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 to where actually having to work a little harder to be able to accomplish some things is 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?

5:15Otherwise, the picture isn't in focus. That sounds pretty historic or barbarian. And then you use it and you use it and you 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, 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.

5:54V1, the aerodynamic version, the concept two version, the just less version, the manual focus version. The other thing, and we've shipped a lot of things over the years, including Hay, 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 smoothed that out. Jason, you remember the magic door, the magic key? You had a special email address that could get around your screener. Speakeasy code, yeah. Speakeasy code. Now, the problem with that feature was it had such a good name that it was almost a darling too cute to kill.

6:29and therefore we couldn't get rid of it. But I've never used the speakeasy code. I don't know if you've ever used it. Nope. But it was just, it was one of those things you get excited about at the moment and then you look back upon it after and we're like, oh 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, hey, there's a million things that work together in beautiful harmony.

7:02But 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 that was difficult or hard to make, but it was essential to it. And you actually accentuate some of those features more. 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.

7:48We're ready to launch with V1 version. Yeah, I mean, we're getting a good amount of feedback from people. 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 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 what's been interesting i was talking to brian about this yesterday so one of the really interesting things about fizzy is that so it's a kanban tool basically every other kanban tool i've ever seen has all the columns open all at the same time all the cards revealed all at the same time.

8:21That's like what Kanban 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 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 Kanban. And it would be the natural first thing for people to say, why can't I 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 Kanban tools don't have.

8:54Anyway, long story short is 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 20, 50, 100 ,000 people try it. But so far, not come up once. And then it's usually the things that come up are these little nitpicky things, which are totally fair game for anyone to notice because I've noticed them too. It's just we've decided not to do them. But most of the beta feedback initially is not about mining for new features. It's closing little gaps, little holes, busted things that we didn't know about.

9:28It'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 now working out quite well so far. I think we've invited maybe six or 700 people at this point. Oh, yeah, 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. But we've sent about 600 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, this can wait, we can make this like tweak to the code later?

10:02It's interesting because Busy 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. I 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 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.

10:44But in this instance, we had had this audacious science project that 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.

11:21Mixed in some of the insights we had picked up along the way working with this other novel stuff, but 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 the 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. you know what this part maybe uh could use a little do-over 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 fucking hitting publish on hey world as soon as i've written the last character which is my normal mo 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.

12:19So 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 of times over the few months. I was like, I really don't like this. 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... And I go into the keyboard and I do the thing.

12:57And I have this little commit that says minus seven lines plus two. And you know what? It's funny how these things can be so satisfying. 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 could just see, you know what?

13:38That'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 my favorite parts of writing code at all, making any kind of product. It's exactly this phase where you just sort of like, you're 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.

14:11There'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, do you know what? I've written enough programs. I've been running 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. And they just keep smoothing them, make them more aerodynamic, make them more of a pleasure to read.

14:51I don't know why it is. I do know there are other programmers who share this satisfaction of the leading 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 crud monkey identity. We write to a database. We read from a database. We update a database. We delete a record in the database. That's it.

15:26And 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 of months going all in on Omachi. And I just kept finding these little touches. One of the things, I don't know, we have a couple of Easter eggs and some of them include sound. And the one Easter egg I found with, or I didn't find, but was instructed to look for with the sound, I just went like, isn't that delightful? for like we we're little crud monkeys dancing here in the background doing the little monkey dance for the create and update and delete and then like there's a fucking harp playing 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 i used to think of it as a cliche like stop and smell the flowers You know what?

16:26I fucking stop and smell flowers now. I look at trees and I go like, man, that's a beautiful tree. 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 years old, you'd laugh at yourself right now. 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 code. I think that's the first mention of the Easter eggs in Fizzy. So I'm excited when people actually find them.

17:01I didn't really reveal it. I just said sounds, harps, music. I love it. Well, with that, we're going to wrap it up. Free Work is a production of 37 Signals. You can find show notes and transcripts on our website, 37signals.com slash podcast. Full video episodes are on YouTube. And if you have a question for Jason or David about a better way to work and run your business, give us a video question. You can do that at 37signals.com slash podcast question. You can also send us an email. to reworkat37signals.com. And I will link in the show notes to the new Fizzy product.

From the publisher

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:12 – Recognizing when a product is ready to meet the world
  • 02:55 – Strip things back to the essentials first
  • 07:32 – Weighing real-world feedback from early users
  • 10:03 – Add the final layer of polish without overdoing it

Links and Resources

More from REWORK

All 44 episodes
When is enough, enough?REWORK · 18 min
Listen in VO