Refining before release
As 37signals gets closer to launching their newest product, Fizzy, Jason Fried joins host Kimberly Rhodes to reflect on the final stretch of development. He shares the trade-offs of setting your own deadlines, the importance of onboarding new customers, and the company’s process for marketing a product.
Watch the full video episode on YouTube
Key Takeaways
- 00:00 - Episode Highlights
- 00:36 - What the “11th hour” looks like before a product launch
- 04:31 - How to weigh deadlines against final release decisions
- 06:41 - The importance of customer onboarding
- 12:45 - A playful touch added to Fizzy’s logo
- 17:20 - Why version 1.0 is just the beginning
Links & Resources
- Record a video question for the podcast
- Books by 37signals
- 30-day free trial of HEY
- HEY World
- The REWORK Podcast
- Shop the REWORK Merch Store
- The 37signals Dev Blog
- 37signals on YouTube
- 37signals on X
Sign up for a 30-day free trial at Basecamp.com
Transcript
Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes from the 37signals team, joined by Jason Fried, co-founder and CEO. This week we are talking a little bit about the refinements that we make before launching a product. We’ve mentioned several times that we’re working on a new product called Fizzy, and as that product wraps up, there’s all kinds of bug fixes and redesigns and lots of other details that we wrap up before we go live. So Jason, I thought we would talk a little bit about that kind of where we are in the process. Tell me, I don’t know what I want you to tell me.
Jason (00:38): I’ll talk about the 11th hour as we would call it.
Kimberly (00:41): Right, perfect.
Jason (00:42): Which is, we’re not quite there, but we’re also there. I would say we’re not quite there in that we don’t have an exact launch date, so there’s not really time that we’re measuring here, but we are very close to being done with version 1.0. And as always tends to happen, and I always think it’s a good sign, is that as we get close to getting very real, which is launching the thing, we have all sorts of ideas that we want to try and change and tweak and adjust because nothing really makes you take things seriously like getting real with it. It’s very easy months and months ahead of launch to explore and play and whatever, and you should do all those things, but there’s a point where you’re like, okay, we’re about to get very real with this thing. It just clarifies your thinking and your perspective and your point of view, like nothing else. It just compresses all the other stuff out. And what you’re left with is what do we actually need to do here? Are we ready for this? We feel good about this, that whole thing. So we’re kind of there now. And so things we’re talking about right now for example, are things like we’re beginning to look into a little bit more about onboarding because so far we’ve been using it internally and we haven’t had to sign up new users. And so you kind of get back into this onboarding side, which is like, what’s the new user experience like?
Kimberly (01:47): Sure
Jason (01:48): How should we do that? How should we finally solidify the business plan? Or we’ve had an idea for this, now we have to integrate it with the billing system. Which one are we going to use, our own internal one or are we going to try something else? There’s a lot of questions sort of come up near the end that you must answer now. Like we probably should have answered some of these earlier, but in fact in some ways we’re glad that we haven’t because what we’re seeing is that we’re actually changing our mind here in the 11th hour about a few different things. One thing for example is authentication and sign-in. So we have an internal system called Launchpad. We don’t use it in HEY but we use it in Basecamp and some other tools that we built over the years, which has 2FA built in and all these other integrate… you know of course passwords and password reset and this all this stuff you need for all that stuff. Setting up accounts, signing up, setting your password forgetting your password, all that stuff. And we’re just wondering, do we want to go down that road this time? And there’s some reasons why we may not want to, Which I can’t really talk about right now, but we will at another podcast I’m sure. But what we’re thinking about is actually just using something much simpler, which is more like a magic link kind of approach where you enter your email address, you get a link sent to you and you just click that link and you’re in, or you get a code that you can enter and you’re in, versus having passwords. And we’ve tried this in the past and it felt like it was too early. This was years and years and years ago people weren’t used to it, but now more and more people are used to it
Kimberly (03:08): Yeah
Jason (03:09): And it actually simplifies a lot of stuff for us and for them potentially. And we can also allow you to add passkeys, which is sort of a more advanced way of authenticating to some degree if you want to go down that road. But for the most part, email, get the link, log in. And so this would be a very different approach for us than we’ve taken previously and that’s something we’re discussing now. So this is sort of what happens in the last throws of it because we don’t have a lot of time left and we have just a few people working on this and how do we want to prioritize everyone’s time, position, attention, effort, that sort of thing. And we know that there’s certain things we absolutely must get done. So now you’re like, what would be easier? What would be better? What makes sense? What’s not worth doing? It’s just a really clarifying moment.
Kimberly (03:49): Okay let me ask you this because you said we don’t have much time left
Jason (03:52): Yeah
Kimberly (03:52): But really we are setting our own deadline. So you could say we have as much time as we want there to be. Kind of talk me through how you are thinking about deadlines and thinking about this is a deadline I’m setting for myself or internally for the company. Because really it could go on as long as we wanted it to.
Jason (04:09): It could. And you might argue that maybe it has gone on too long. I don’t know. To your point, you make these deadlines up. We want to get this done this year, first of all, and we’re well ahead of getting it done by December. So I’m not really worried about that necessarily. But things happen at the end of the year. There’s more holidays and some of that stuff happens. People take more vacations. There’s some of that. So you kind of don’t want to wait too long to finish something up by the end of the year and we’re very close and it’s time. It’s time to draw the line for 1.0. How do you know it’s time to draw the line? You just know it is. We’ve been working on it long enough, we’re really happy with where it’s at. It’s dialed in, it’s tight. There’s some stuff we need to finish up here and that’s kind of what we’re focused on.
(04:46): But the product itself is pretty much it’s set. The features are set for 1.0. If anything, we’ll take some stuff out, but we’re not really adding anything else at this point. And so things just sort of come to a natural point, which is like 1.0 is ready, but in order to ship it to customers, we have to round a few things out like onboarding, billing, passwords or login authentication, that kind of stuff, which we have because we have it for our own account, but it’s not rounded out in a way that we want to present it to customers in that way. It’s a little rough around the edges. It works for us, but it’s not market ready. So that’s the kind of stuff we’re at now, and if we give another six weeks, eight weeks, it’s not going to be better. It could only get worse at some point because then you start to do more stuff and you leave more ends untied and that becomes a mess and it becomes very difficult to deal with that sort of thing too. So that’s sort of the approach. It’s just, it’s time. There’s a feeling that it’s time and when there’s not a feeling that it’s time, you need to make that feeling happen because you’re right, things can just go on and on and on.
Kimberly (05:44): Okay, so you mentioned onboarding. Kind of talk me through, because you are in this product, you’re deep in it and understand everything there is to know about it. Now as we think about someone never seen it before or you have to take a step back from that. Kind of talk us through your process for doing that. Are you just kind of pretending you don’t know how it works so that you can onboard a new customer? Are you bringing in other people to help you do that? How does that work?
Jason (06:09): Onboarding is of course the process of a new customer signs up or is curious about the product, what is that first experience like for them? And what’s interesting is this first experience is a very, very, very important experience, but people only experience it once. You put a lot of time into this thing that people blow through and then it’s over.
Kimberly (06:28): Right
Jason (06:29): And it’s kind of an interesting thing to do, but you kind of have to nail that. And I think with HEY for example, we absolutely nailed it. It’s the best onboarding experience we’ve ever made in any product and we kind of raised the bar pretty high there. So we want to make sure that that experience is good in Fizzy as well. Part of this is just the signup process, like how much stuff do we have to ask you upfront? We’re trying to ask you as little as possible. That’s not always the case. Sometimes you want more friction depending on the kind of product that you’re selling. In this case, we just want people to get in. We have to think about what’s it like to onboard. There’s kind of two onboarding in a sense. There’s this one primary one and then we’re going to give a certain amount of the product away for free. And then at some point there’s going to be a moment where you’re going to have to pay if you want to keep using it. And so there’s kind of a second onboarding step there, which is encouraging an upgrade, explaining the upgrade process, allowing someone to go through that process and then feel good about what they just did as well. So there’s like a second stage, a step up beyond the initial signup.
Kimberly (07:21): So similar to Basecamp that you can get in at a trial, get in for free, and then at some point if you need more, you can upgrade.
Jason (07:28): Yes. And Basecamp has a free forever account
Kimberly (07:32): Right
Jason (07:32): And Fizzy will sort of as well. There is some limitation at some far off distant point if you don’t use it much, but many people might be able to get away with using it for free forever. It just depends on how much you use it. That’s more of a usage base thing. So what we do is we build this onboarding feel, which is like, okay, you land here, you sign up, what’s that like? Then once you’ve done that, you’re past that stage, which you’ll never go through again unless you sign up for a second account. Now we want to explain, we want to orient you this more, think about this more in terms of orientation. If someone goes to a new school or whatever, there’s like an orientation process. Here’s where this is, here’s where that is, this is how this works. Here’s where you’ll find these sorts of things. This is where you might do this kind of thing and not do that kind of thing. So there’s a few different ways to explain that. You can explain it by arrows in the interface pointing things out. You can have someone step through a process…
Kimberly (08:22): Like a setup wizard kind of concept
Jason (08:25): Set up wizard style approach. You can just not explain anything but have a video and go, hey, if you want to watch this 60 seconds, the orientation video is what I would call it. Not even getting started video, but orientation video. Maybe you do that, maybe it’s 30 seconds, it just depends. But we haven’t decided, by the way, what approach we’re going to take. It’ll probably be a combination of a few things. We want to point some stuff out. So some things are very obvious, the product is actually quite obvious, but there’s also just a single menu, a single unified menu. We want to make sure you know where that is, where you do everything. And there’s some keyboard commands we want to probably teach you, some of that basic stuff. And then we’ll probably have a video also for more in depth walkthrough of some of the basics and maybe some more advanced stuff. We have yet to record these because one of the reasons why this is hard is because the interface is not fully baked until the last minute. We’re always sort of nipping and cuing at the end towards the end and some stuff doesn’t matter, but other things are materially different. It’s frustrating. You got to wait until the end.
Kimberly (09:24): You can’t get started too early.
Jason (09:26): Yeah. Oh, something material is going to change, the button is now you’re like, go to the top left and we move to the top right. That’s a thing you have to say differently in the video. So there’s some of that stuff. So it’s kind of a mad scramble at the end to get the videos done. But this is all just sort of the approach. And as far as bringing beta users on, we’re very close to probably bringing on, I dunno, a handful.
Kimberly (09:46): Oh! Of people outside the company?
Jason (09:48): Outside the company.
Kimberly (09:49): Interesting.
Jason (09:50): We’re close. We need to get the basic onboarding in place so we can do that. I could also bring people on and just walk them through it, which I might also do with one or two people before the onboarding is there. They would just be dumped in and with no instruction. But I would say here’s basically the lay of the land. That also helps me learn about the kinds of things that someone might wonder about. And so when I make the video I can reflect back on that experience and be like, oh yeah, you know what? I really need to explain this because wasn’t clear or everyone seemed to ask the same question about that and make sure I hit on that. So it’s nice to kind of do that too. And that’s kind of how that goes. Also internally, we have different teams using Fizzy. We’re using Fizzy to make Fizzy. The iOS team is using some Fizzy stuff. I know you’re using it now to sort of plan the podcast production schedule.
Kimberly (10:38): Yep
Jason (10:39): There’s a few other teams. We want to get more and more teams internally on this, which can be hard to do sometimes because people are of course, like all customers, already doing something else, somewhere else with something else. And in that case it’s Basecamp for us. So peeling people away from Basecamp is always a challenge because Basecamp is so thorough and sort of dialed in. But we’re encouraging more and more people internally to use Fizzy for a specific type of work that it’s really tailored well for. Some teams take to it easier than others and we’re sort of working all that through and then we’re learning about what’s hard about it, what the transition’s like from some teams and making some changes based on that and that sort of thing. So it’s a really good process.
Kimberly (11:17): Okay, so tell me a little bit about the marketing aspect of it, logo design, how and when we will market it. Do you think about that in this final stage or have you been thinking about that this whole way as it’s been built? Talk me through that.
Jason (11:31): We’ve been playing with the marketing for a while. I mean marketing by the way. It’s not marketing. We’ve been playing with the logo, which is not marketing. Let me just be super clear, but we’ve messed around with a logo for a while and we’ve landed on something we really like which kind of mimics the interface. It’s sort of a secret little mimic the interface thing, which you probably won’t necessarily pick up on, but it’s exciting for us to make this thing that’s like that.
Kimberly (11:54): When you pointed it out internally, it was like, oh, that’s clever. I would not have noticed. But now that you pointed it out, that is clever.
Jason (12:00): Yeah, it’s like basically, so the name is Fizzy, which is like carbonated water, let’s just say, or drink, and there’s a straw that goes into it and the straw breaks it into kind of two columns, which is sort of the fundamental layout of fizzy. There’s a third column down the middle, which is kind of also the straw, which we call it the stream. And at the bottom there’s sort of the liquid, and again, you don’t have to know this, it’s sort of a fun little thing that’s there. So it’s always fun to play with that stuff and get something in there that maybe 1% of the people know. Maybe once people know about it, they think it’s cool, maybe they don’t care, maybe they think it’s stupid, it doesn’t matter. We enjoy it, we’re having fun with it. So it’s basically a glass with a straw in it.
(12:34): That’s essentially what the logo is. We’ve been honing it. It’s sort of essentially done. We may add a little bit of dimension to it, some finishing little bits, but that’s been done for a while. We’ve been playing with that for a while. The marketing side of it, I mean the way we typically market new products is just to make a lot of noise about them initially, show people how we use them primarily on X and LinkedIn and do some videos, share some stuff out. We typically don’t buy any advertising for new products. It’s a very organic expression initially. That’s usually how we do all of our marketing for the most part. Occasionally we’ll buy some stuff. We are experimenting with some things this year, some billboards and whatnot. But for a new product like this, we’re excited about this thing. Let us show you what it can do.
(13:14): Let us show you how we’ve been using it. Here’s some fun little details about it. Here’s some ways we thought about building it. Here’s maybe some early looks at some early designs of it and just sort of share that way and invite people, encourage people to come in and the way you’re going to sign up is a very generous, free version. And so hopefully a lot of people will just check it out because they’re curious and then dig into it. And if it’s a novel interface, it’s different than most things you’d expect to see. So we’re expecting a lot of people to wonder about what it is and not maybe totally get it initially, which is sort of, kind of cool. And then some people really get it and then some people will figure it out. Some people won’t like it at all. And I think that’ll also be good because there’ll be an interesting discussion about it online and we’ll be very active in talking to people and applying and discussing it and explaining it and the whole thing.
Kimberly (14:00): Well, I think also letting people just play around with it is so helpful. I’ve been going down this path of researching some webinar software for us and just the amount of you have to either talk to a human to be able to get a trial or oh, we’ll give you your money back if you don’t like it, but you do have to pay us for a trial. Just that level of barrier makes it not very friendly.
Jason (14:23): Yeah, that’s never been our approach. Actually, with one exception, we made a product way, way, way back when called Know Your Company, and Know Your Company was something I would personally onboard every customer. So I’d have to give you a half hour tour…
Kimberly (14:38): Wait, you?
Jason (14:40): Me. Yeah, I’d give you a half hour tour. It was built for business owners, specifically.
Kimberly (14:45): Ok
Jason (14:46): So the whole premise of that product was once you get to certain size, like 30 or so people, you don’t know your company as well as you used to.
(14:53): And this tool is going to help you get to know your company again. This is a problem I had personally. We built it kind of for me and David basically. And so I wanted to pitch this and walk other business owners through it one-to-one and show them how we use it, what they could do with it. So that was a requirement for that product. It was also an expensive product. That was a fun thing, but that’s not sustainable long term. But everything else we’ve ever built is self service. You never have to talk to anybody. You can if you want, you can email us. We’ll be happy to answer questions quickly, but you don’t have to. There’s no requirement, there’s no sales person to talk to. There’s no hard sell, there’s no pitch. Nothing like that.
Kimberly (15:30): Okay. Let’s go back to when things are feature complete, if you will. And when you’re deciding or how you’re handling what’s going to be in V2. I’m sure at this point you’re like, great idea, but we’re not going to do it right now. How are you thinking about that, managing those kind of things and keeping organized with what’s now versus what’s later?
Jason (15:52): Yeah, so we always think of it as 1.0 and then we internally think of it as 1.1. So we don’t think of two. 2.0 is too far down the road.
Kimberly (16:00): Got it.
Jason (16:01): 1.1 is like what are some things that we’d like to do, we’d like to have gotten into 1.0, which we pulled back on for a variety of different reasons, maybe we weren’t sure about it, maybe we didn’t think it was necessary, maybe it wasn’t fully baked, we didn’t like the way it felt, but we knew we could finally find our way there later. Maybe we felt like some of the features don’t matter initially for people. Like there’s one feature we’ve been playing with, I’ll just share what we’ve been playing with, whether or not we’d ship it, I don’t know. It’s not going to be 1.0, I know that. Whether or not it’s in o1.1 or later, I don’t know. But there’s this feature called Fizzy Ask where you can basically ask the product questions in natural language, AI based setup essentially, questions about the data in the system, and it’ll pull back things, it’s not a search result, it’s a natural language, semantic style search, essentially using LLM and the whole thing
Kimberly (16:44): And that’s our first foray into using AI in a product
Jason (16:50): Publicly. Yes. However, on day one you have no data in the system. On day six, you don’t have that much either. On day 15, there’s some, but not that much anyway. So to ship a feature where you can ask the system questions about the data that’s in the system, but when you don’t have any data in the system yet, it doesn’t make sense to provide that experience. Now you could say, well, there’s ways to do things where you can show people what might be possible later on and you might want to introduce them to that so they know it’s there. I don’t believe in that. I don’t think it’s a good experience to give someone a tool they can’t really use yet.
(17:28): So might we choose to roll this out in 90 days, for example? Like we have it on our own account, it’s built into the system. It’s only available on our account because we’ve been using Fizzy for months and months and months and have thousands of cards in the system at this point. Actually, I’m not sure we’ve passed 2000. We have a thousand plus cards in the system at this point and we can ask the system questions because there’s tons of data and history and context. So we’re using it. And if we find it to be really useful over the next, let’s say, I’m just making up numbers here, 90 days or something, we figure out that in 90 days and we look at usage patterns and go, there’s a lot of people who have a lot of stuff in the system, now it might be useful for them, we might begin to roll things out. Maybe we only roll that feature out if you have a certain number of cards. I’m not really totally sure, but there’s some things we hold back because they don’t make sense temporally, like right now it doesn’t make sense at this time.
Kimberly (18:21): From day one.
Jason (18:22): Maybe at some point in the future it will, even though we have it in our system, but not in customers. So there’s some of that stuff. There’s other things that we just haven’t figured out quite yet, which we’re waiting on and that sort of thing. So I dunno, there’s no science to it. It’s more of an art and what feels right at the time. We have a lot of other things that we probably want to do with this product, but we also want to get it out there as is and see sort of how it meets the market, how it takes shape, how people are using it, and then we can learn a little bit from that and decide what the next most important thing might be.
Kimberly (18:50): Okay. I know it’s something that we don’t typically do, but I see a lot of other software companies doing I’d like to get your thoughts on which is launching with a roadmap. Here are these 12 features, but we have this other forecast of these 27 features we’re going to add later. I know we haven’t done that before. Tell me why.
Jason (19:07): Yeah, we’re not big fans of roadmaps primarily because we don’t have them and we don’t have ‘em because why? What’s the point? What’s the point to say these are the 12 things we’re going to do next year? How about we figure out what we’re going to do as we go? Because as the product is out there, we learn new things from customers who are actually using it. We learn new things from ourselves. We have new ideas. I don’t want to be beholden to an idea I had four months ago just because I wrote it down.
Kimberly (19:32): Yeah.
Jason (19:33): I don’t want to do what I thought, I want to do what I think. And so there’s no real reason in my opinion to have a roadmap at all. In fact, I think it’s a negative. Now, a lot of companies have it because customers ask for them and so they think they have to placate customers by saying, this is where we’re headed and you should buy our product now because we’re going to be down there later. I think that’s disingenuous, frankly. People should buy the product for what it is today, not what it might become because you just don’t know what it’s going to become. And you also don’t know how a company is going to actually ultimately implement this thing that they’re promising six months from now. So I think it’s just best to roll with it, ship it, keep an eye on it, use it intensely, see how other people are using it, learn from them, and then you’ll have new insights along the way and you’ll continue to make the product better and better and better over time based on real actual usage, not imagined usage. Real actual gaps you want to fill in the product, not imagined gaps you want to fill in the product. And also you’re not beholden to making promises that you might change your mind on. And the other problem with a roadmap is a roadmap is basically a promise document.
(20:36): And now you are essentially on the hook to do the things you thought were going to matter. What happens if you find new things that you think are going to matter and you can’t do those? I just don’t like that approach. I don’t think it’s healthy. I don’t think it’s a good idea. I don’t think it leads to better products either. And I think it ultimately leads to a lot of people running out of time, being frustrated, pushing things off, and then having to scramble at the end to deliver these things that you thought were good ideas once but may not be good ideas now. And if they’re still good ideas, then just do them anyway. You don’t need to publicly announce the things that you’re going to do.
Kimberly (21:10): Okay. I have two questions before we wrap up.
Jason (21:12): Yeah
Kimberly (21:13): One, tell me about the team structure as it is now as we’re wrapping up Fizzy, and then what you imagine that structure to be after it’s launched. Because obviously there’s some version, 1.1 things we want to work on. We have more than just one designer and one programmer working on this. Tell me what it looks like at this last stage and then long-term, how that might change.
Jason (21:36): What ends up happening near the end is there’s a little bit more of a pile on in some ways. Historically throughout the product, there’s been, well initially one designer, one programmer, and we have two designers on it now. Two programmers. Programmers were part-time working other things, but now we’re kind of all in to finish this thing. So we’ve got two designers and we have a few different programmers because there’s a few different areas of the product that require some specialization at this point, some infrastructure work, some product work. So there’s a lot of stuff going on. So at this point we all kind of pile in and get it to 1.0. After that some people will come off, people will remain, a team will remain, a core team will remain so they continue to improve the product, but people will back off of that and we’ll see where things go at that point.
(22:19): And then if we need to bring new people in, we’ll do that, but typically we don’t have to after we’ve shipped something like that. We just maintain a team on the product. I’m also involved, David’s involved. Brian is head a strategy sort of involved as well. But I’m sort of working on the design side and the overall product side of things. David jumps in on technical decisions and some stuff he has to move forward infrastructure wise and some other deeper technical choices that we’re making about the product and we’ll weigh in on those things. So there’s a core permanent team, some people dive in, some people dive out. It sort of just depends.
(22:57): But now more than ever, as we approach 1.0, more and more people are involved in it. Early on, there’s fewer and fewer people involved in it. So what we don’t do is say, throw a bunch of people at early and then keep all those people on it. We start with a very, very small team that can move exceptionally quickly and has no overhead whatsoever. They just go, and we make a lot of changes and early exploration stuff. And then as we get more formalized, we begin to layer someone else in, layer someone else in, layer someone else in, and then we launch.
Kimberly (23:27): Okay, perfect. And last question before we wrap up, because I know people are going to email you and ask you, so let’s just answer it here. You mentioned beta testers. For someone who’s like, I want to be a beta tester, tell us what you’re going to say to them.
Jason (23:38): I mean, we already have enough people, so there’s been a number of people who’ve already made plenty of noise about wanting to try this. Some are going to come from the Basecamp community. We have a Basecamp community, which is run on Basecamp, which has, I don’t even know how many people are in that.
Kimberly (23:52): I think it’s 2000. Yeah.
Jason (23:53): Yeah, 2000 plus. There’s a handful of super fans in there, which we love those people and we’re probably going to roll it out to them first, or cherry pick a few of them who are interested. And there’s a few other people who’ve been on X who’ve been asking to be part of this. So we’ve got a nice small group. People can of course share interest if they’d like, but we’ve got a good core group of people. We’re ready to roll it out to a few of them to get going.
Kimberly (24:14): Okay, well perfect. Well, with that we’re going to wrap it up. 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 if you have a question for Jason or David about a better way to work and run your business, leave us a video question. You can do that at… you can do that at 37signals.com/podcastquestion. I don’t know why I could not remember that!