SEASON 2 - EPISODE 0094 - JAN 31, 2024

Readying for Launch

Product launches can be a delicate dance between anticipation and anxiety.

Today on REWORK, Jason Fried and David Heinemeier Hansson sit down with host Kimberly Rhodes to explore the intricacies of knowing when a product is ready for launch.

Listen in to learn the art of patience with the “Give It Five Minutes” principle and the necessity of building a “bucket of arrogance” to weather feedback storms during challenging launch phases.

Don’t miss out on Jason and David’s unparalleled insights as they delve into nuances involved in bringing a new product to the market.

Watch the full video episode on YouTube

Key Takeaways

Launching with impact—assessing quality, avoiding embarrassment, and infusing novelty are key elements in launching a memorable product to the market.
By embracing a “swarm” approach, the team addresses and rectifies issues promptly during the initial launch ensuring a smoother user experience.
“You can’t design on people’s requests. You have to design on their behalf”—how using a selective approach to customer feedback allows for more thoughtful and user-centric product development.
Rejecting the concept of roadmaps, in favor of flexible product evolution.
“Give it Five Minutes”: why acknowledging the temporal unreliability of early feedback, especially during a launch, is crucial.
How building a “bucket of arrogance” helps with weathering feedback storms.
How prioritizing qualitative feedback over quantitative metrics during a product launch helps to address issues without compromising the product’s integrity.

REWORK is a production of 37signals. You can find show notes and transcripts on our website. Full video episodes are available on YouTube and X.

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 or email, and we might answer it on a future episode.

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m your host, Kimberly Rhodes, and I’m joined by the co-Founders 37signals, Jason Fried and David Heinemeier Hansson. Well, you might know 37signals for their popular project management software Basecamp, but these guys have launched a lot of products — from Highrise and Backpack, HEY email, and most recently the HEY Calendar. And they’re coming out with their first product under the ONCE umbrella very soon. With all of this launching, I thought today we’d talk about the final steps before you actually go live. So Jason, let’s maybe start it with you. I know we just kicked off this HEY calendar as one of our new products, but you guys have done a lot of launches. I’m sure there’s a lot of steps that you have in the process before you push that go live button.

Jason (00:46): Yeah, it always comes down to a feeling of, there’s a few things, like quality. Does this feel like we’re at the right level of quality? That doesn’t mean no issues, but there’s a general threshold and it’s impossible to describe what it is, but it’s a feeling. Like, yeah, this feels pretty tight, this feels tight, this feels fast, this feels good enough certainly to get out there. We’re not going to be embarrassed by it. It’s sort of honestly kind of the heuristic. Is this going to embarrass us or not? No. Great. Okay, so we have that. Then we also have the combination of the features that this thing’s going to have at launch, and that typically for V1 of something tends to lean more towards novelty. So is what we’re putting out there interesting, different, differentiated, novel? Is it going to make people go, oh, that’s interesting, oh, or is it going to be like, oh, that’s just a better version of what I have.

(01:38): If it’s a better version of what they have and there’s these equal things and it’s slightly better or whatever, that’s not interesting enough for us. So we need to make something that makes someone go, oh, interesting. What’s that? Or, gosh, I’d never thought about it that way before. I’d never thought a calendar could have time tracking. Why don’t other calendars have time tracking? Or with HEY emails, I never thought about this reply later feature. Why don’t all email things work that way? So we’re looking for this degree of, we want to put something that’s so obvious in front of people that they look back at their other tools and go, why don’t my other tools do this? So we’re looking for a combination of those things and that usually means we have to leave certain things out. So there’s this idea of table stakes, which is like what are the baseline features we need to have?

(02:21): Our version of table stakes is quite low in that we’re not going to put everything on the table that every other product has. This is not about matching everyone else and then adding other stuff. It’s about making trade-offs about what’s important to have and what’s not necessary initially. So that’s kind of how we think about it. So again, it’s this quality, novelty and also are we proud of it? Also, how does our team feel about it to some degree, but really it’s like we want to make sure this isn’t going to embarrass us. That really is ultimately how I’m going to wrap it all up here.

David (02:52): Yeah, I think that embarrassment comes often from that degree of confidence you have in what you got. Do we feel like if we’re going to push this out there, hmm, you’re just going to step through the boards all over the place and get stuck because that doesn’t work either, especially at our scale now. When we launched things back in 2004, no one knew who we were. We had a few thousand people follow us. We could really push something out there and let customers find all the issues more or less. We didn’t have dedicated QA for many, many years. We’re a very small team. We would push something out there and the quality would be good enough for the golden path, and then as soon as someone veered off the golden path, they’d find issues. They’d write us about it and it wouldn’t be a big deal because we could just reply.

(03:35): We could fix it and then reply to them right away. At our scale now that doesn’t quite work the same way. There’s just too much attention, there’s too much focus. So if we push something out where you veer off the golden path by one degree and you’re going to find a bunch of issues, we’re going to get 10,000 emails. And do you know what? That’s just not a good, it’s not a good trade-off in terms of how long it takes to reply to someone and how many people we actually end up annoying. So our bar has had to creep up to adjust for that, but that’s our situation because of our spotlight now. I would very much recommend people who are just starting out who don’t have that spotlight to look at what we did in the beginning. Don’t have a dedicated QA team. Don’t spend so much time making sure every single edge case is covered.

(04:25): Let customers, you don’t have that many, find the things that are off the path. Now again, you have to have a certain degree of confidence you’re not going to lose people’s data. You’re not going to corrupt things. You’re not going to be catastrophically broken. That’s not what I’m talking about. I’m talking about all those little things. So getting that gauge of how big is your spotlight, how big is your audience versus how much quality and how much confidence do you have in it? And I think where a lot of people go wrong there is they look at a product launch from Apple or Google or Microsoft or something and they go like, oh man, this is just so polished. Yeah, to you can’t be Apple and push something out to a hundred million users unless it’s super duper polished, which by the way is also what you can do when you’re a $3 trillion company.

(05:16): You just have different things to deal with. The entire HEY calendar team working on the web in terms of programmers, were a handful of people, not like hundreds of people, not even dozens of people, a handful of people working on this. So getting that proportionality is really important and this is where you have to weigh it all at the same time. And ultimately what that results in is a gut reaction. So Jason uses like, we don’t want to be embarrassed. This shouldn’t be so obvious that the first five tweets that come back is like, oh, why is this totally broken? We’d be like, oh geez, we should have pushed this out. But you can’t crystallize it down to more than that. And I do think though, you should err on the side of being slightly too early. I mean, Jason and I, one of the things we do here at 37signals is we set the pace, we set the appetite for risk, and we’re usually more willing to risk something being a little off than perhaps the rest of the team is, right?

(06:19): It’s our bacon on the pan here so we can kind of afford to be a little more risky if we gauge and go like, you know what? It’s more important that we get out right now with, HEY calendars was a great example. We launched this. We had a two to three week launch window. We were going to roll it out slowly, going to take in more people at the time, and then this whole Apple nonsense popped up and all of a sudden we had this huge spotlight, a bunch of people extremely eager to try the product. And then we went, do you know what? We’re going to take a little more risk. We’re going to take the three weeks we have. We’re going to boil it down to about a week. That’s going to mean that some people are going to hit a few more issues. Let’s pour into more resources. But that kind of decision, that kind of risk taking sort of have to come from Jason or I where you have to accept that as business owner or as product owner that you are the one who have to put your hand out there and say like, yeah, do you know what? If this is going to hurt, it’s my hand that hurts rather than the rest of the team.

Kimberly (07:19): Okay. And David, you mentioned bugs or issues that customers might run into, and one of our really popular episodes is one called Software Has Bugs. So talk me through when you’re releasing a new product, I mean you’re going to get customer feedback. How do you guys handle that maybe differently at a product launch situation than just an everyday customer feedback situation? Is it different?

David (07:39): It is different because the feedback loop is shorter. First of all, you know, we knew we’re going to push out a HEY calendar, we’re going to push it out quicker than our launch plan was. That was going to mean more issues, more reports, more duplicates, more all of it. And also that the urgency to fix these things was higher. If you have a long running project or a product as we do, people will report bugs and Basecamp runningly. A lot of those bugs are really, really edge case-y, because we’ve been running this version of Basecamp for years and years, we’ve fixed all the obvious stuff. So when people find things these days, it’s usually pretty out there. Doesn’t mean you shouldn’t fix it, doesn’t mean you shouldn’t at least record it or do evaluate it, triage it. But when you’re launching something new, you’re going to have bugs as we just talked about, that are just five degrees off the golden path that lots of people are going to hit.

(08:34): So you kind of need to fix 'em quickly. And that’s what we did now here, we just went live and we had the whole team swarm, as we like to say, swarm on the queue of the issues. All these things are coming in, they’re coming in really fast and we kind of have to keep going, keep going, fix, fix, fix, fix, fix. And then you at some point, actually that point just happened today. I think Jorge, who is leading the technical team just today, said, okay, we don’t need to do the full swarm anymore. We fixed the majority of the major obvious issues. A couple of people can now go back to their daily duties. They can now go back into feature development, they can go somewhere else. We’re going to have a smaller team that’s going to continue to process these bugs, but it’s not going to be all of them.

(09:14): So it is different and you should treat it different and you should treat the enthusiasm and excitement that is around a launch to really power through some of that work that isn’t always the most glamorous. Like fixing bugs and whatnot isn’t as glamorous most of the time as it is when you’re launching something new and you feel all that energy and you feel all the excitement, especially with HEY Calendar. I mean both Jason and I fielded a lot of emails on this because we were out saying like, hey, I can help you get in early on the beta or whatever it was. I mean, I received hundreds of emails in my inbox and when we then gave people access to the system, I’d get a bunch of feedback. A lot of it would be like, I love the product, I love this feature. Oh, I’d never thought about a “maybe” calendar, man, how did you guys even come up with this? All these kind of novel features that it has. And then it would go like, oh, and then there’s also these five things that we found. So that has to get into the system, it has to get fixed, and you can use that energy to power through and be the motivation to really tie it up.

Kimberly (10:15): Okay, and customers, I’m sure we’re not only writing you about issues they were seeing, but ideas that they had. So Jason, kind of talk me through when you get customer feedback on a new product, what do you do with it?

Jason (10:26): So honestly, initially I tend to ignore it. So I read it, I internalize it, and then I forget about it. And this is how I work with my own ideas too, which is that the things that are really good ideas, they just keep coming up over and over and over. So what you have to be careful of is not, oh my God, there’s 19 awesome ideas someone sent me. We got to do these 19 ideas. Great. I mean, why wouldn’t we want to do great ideas? And then someone else sends you an email with 12 other ideas and now you’ve got what, 31 ideas where it’s like you can’t do it that way. You read, you think, you internalize, and then when you get around to deciding what to do next, the stuff that bubbles up is the stuff that is important or that’s interesting or that’s novel. And it’s not always, actually important’s even the wrong word because some of these things aren’t important.

(11:15): It’s like what mix are we looking for? So oftentimes we’ll figure out, let’s take a couple really novel weird things, let’s do those, but let’s also do a couple really fundamental baseline things we need to do. And so it’s a combination of things, but I tend not to write these down or note them. I note them mentally and then whatever happens happens after that because it’s very unlikely that if there’s an incredible idea that someone shares with you that it won’t keep coming up. Other people have this idea too, you’ll have this idea too, and if it doesn’t keep coming up, maybe it just wasn’t that good in the first place. Now there’s also of course, extreme novel ideas that only one person thinks of, and gosh, you shouldn’t have forgotten that one because it was really special, but it’s so rare that that happens.

(11:58): So I think what ends up happening though is that people tend to get ideas from a variety of different sources and then write 'em all down and they have a long list. And now they have this long list in front of them and now they think they have to complete the list because that’s what lists are for to do. Then you’re paralyzed and you’re stuck because now you’ve got to go through this long list of ideas that you had before, not ideas that you have now. And so I just don’t like to write things down that way.

David (12:23): This is one of the reasons why we never do roadmaps. I don’t know if it’s as popular as it used to be, but it used to be quite popular. People go like, oh, here’s the roadmap for the next year. We’re going to do this in the fourth quarter. We’ve slotted this in. No, because as Jason says, now you’re chasing ideas that are perhaps a year out of date and you’ve committed to them. That’s actually the worst thing of all is to write the ideas down and then share the list. Nothing will depress you more as a product person than sharing the list of ideas that was given to you usually by other people, and you then handcuff yourself to that list for a year into the future. That is just a recipe for misery. What’s so wonderful about the brain is it’s a lossy compression machine. And you will get all this feedback…

(13:10): I mean, as I said, Jason and I have been fielding literally hundreds of emails of information and feedback and it all just hits the brain and most of it will just get rejected because we can’t remember it, but there is sort of a compressing function that operates in there that will spit out the things that are really important. So Jason and I actually just talked about this yesterday. I was just going through the compression and I was like, all right, the things we need to do is we need to get the ICS calendar out. That’s a huge thing. Now, I’ve heard about that a million times. I haven’t counted up exactly how million times I’ve heard it, but I’ve heard it enough that it stuck and I didn’t have to write it down. And then we want to do things, we want to investigate CalDev so you can edit other people’s calendars and other systems.

(13:51): There was just a handful of things that we didn’t need to write down. We didn’t need to tabulate how many people exactly asked for this thing. It kind of just went through the filter of the gut and the compression machine that is our brain, and it was just obvious. I mean, I said, Jason, listen. He was like, yep, that’s the same list I got. So it doesn’t have to be more complicated than that. I think people sometimes make it more complicated because they want to make it objective. They’re like, we have 72 votes for this one feature. That means it is ranked above the other feature that had 57 votes. What? I mean, the number of times you hear something is not the only thing that determines whether this is important, whether this is a good idea. A lot of times too, people will give you their suggestions for how to fix a problem, which is not actually what you’re after.

(14:40): You should be after collecting problems, collecting anecdotes of pain. The software hurts when I try to do this, and then the person who’s accounting for that hurt will usually give you their, I want to say half-assed. That’s not pejoratively meant. It’s just like they just thought, can you just put a button there? If you just put a button there my hurt, it’s going to go away. Yeah, okay. But if we put a button everywhere that someone has something that hurts a little bit, there’s going to be 5 million buttons. You can’t design software like that. You have to design on someone’s behalf, and that requires listening to everyone, letting it stew, and then you come out with your design. That is a little bit like introducing a car when people ask for a faster horse, right? That’s the example is given over and over again, but that’s really what it is. You can’t design on people’s requests. You have to design on their behalf. Otherwise you’re not really a designer. You’re like a feature factory that just takes inputs, run it through a, I don’t know, Excel spreadsheet and it spits out exactly what you should do next quarter. No, no.

Kimberly (15:45): Well, it’s interesting 'cause I feel like I see those roadmaps for companies that are trying to get you to buy something for the next version. Like, buy it now because this is what we’re going to have later, and I know you guys don’t take that perspective. It’s like this is what it is now. It’ll have new things later, but you kind of have to trust the process. Is that a true statement, how you guys feel?

Jason (16:07): The other thing that’s really dangerous about that, this comes up, this used to come up, well, it probably comes up all the time with other people’s products, which is I would buy this if it did this or didn’t do that. And so companies go, oh my God, we have a customer. Let’s just do this thing and then we’re going to get this customer. Then they do the thing and then the customer doesn’t buy because there’s that other thing that it needs to do also. Or also saying you’re going to buy something doesn’t cost you anything. So you can’t look at that and go, we’re going to sell if this person, if we do this, this person’s going to buy because they said they would. They just said they would. That doesn’t mean anything. So you got to be very, very careful with people who say they’re going to do something.

(16:47): If you do something, then you do something because putting up all the work upfront and then at that point when it’s done, they may not be there anymore or they may have another idea or whatever it might be, or someone else might not like the idea that you just put in and now they would’ve bought it If it didn’t have that, who knows? It’s your product. You decide what goes in the product based on what you think the product should be, not where other people think the product should be. Now you’ve got to pay attention to what other people, you’re selling this to customers, so you have to understand the market. You understand what people are struggling with and what they’re doing, but it’s still your product. It’s your decision ultimately to put out there.

David (17:27): I think the most important thing here is that people lie all the time to themselves, to each other, to their potential vendors. They come up with these ideas. Yeah, I would’ve bought it if I didn’t. No, you wouldn’t. No, you wouldn’t. So keep that in mind. Then keep also in mind that until you’ve given it five minutes, you don’t even know what you want. We posted the video going through the calendar on YouTube and one of the best exchanges I’ve seen in a long time was someone saying, I can’t use this calendar. It only has a week view. I need the monthly view. And someone replied, Jason, maybe it was you or maybe it was someone else on the team just saying, okay, well this is what we designed. Maybe try it out and see if you like it. Otherwise, there’s a lot of other month based calendars out there, all the best finding it, and literally the next comment is, okay, I tried it for a little longer.

(18:18): It was actually great, thanks. So you can’t trust the initial gut reaction that customers have. You can’t trust your own gut reactions. One of my favorite essays that Jason’s ever written was one called Give It Five Minutes, and this whole idea of giving it five minutes applies just as much to your own impression of your own product, especially when someone else puts something into it as it does to customers, that when you’re launching something new, by definition, none of the early feedback will come from people who’ve given it five minutes because they just signed up. And now on the one hand, that’s wonderful, they have to just signed up and you’re just getting this free flowing stream of their initial impressions. That’s great to the extent that you get to see what it looks like when someone sees your product for the first time. That first impression is important, but it’s not what determines whether they’re going to keep paying.

(19:11): It’s not what they’re going to even determine whether they’re going to convert. So for hey calendar for example, you can sign up today at hey.com, get the calendar entirely for free, and you have 14 days until the moment of truth. The moment of truth is when the system says, all right, time’s up, time to put in your credit card. Was this good enough? So the feedback you got in the first five minutes, 10 minutes, two hours of that, not so important as the kind of feedback that that person will sit with when they’ve used it for two weeks and the paywall comes down.

Jason (19:44): There’s one more thing I want to add about this, which is early initial feedback when someone hasn’t used something is worth a whole lot less as well. So for example, when we were demoing the HEY calendar before we launched it, we’ve got this really unusual novel view, which is a horizontal timeline of time where the events are printed vertically on the screen, like the spine of a book in a library, and when people are looking at this without using it, but looking at it observationally as a screenshot, they go, I can’t read that. How can you read that? It’s terrible, whatever.

(20:23): But that’s not how the product would be used. First of all, the events would be your own, so you would’ve typed them in or put them there. So there’s a muscle, well, it’s not really muscle, but there’s a memory of this item. You’ll recognize that item because it’s your item, so it’s a lot easier to read something that you already understand. You already know how long it is. You kind of wrote it yourself. You get the shapes of the letters even if they’re turned the other way, and when it’s your stuff, it’s just easier to see. It’s also easier to understand when you’re using the thing than when you’re just simply looking at the thing. You don’t have any other context about how it works or why it works that way or the other benefits you get from the way things are laid out. You’re just looking at it and going, that’s different.

(21:05): I don’t like that. It’s different. Totally, by the way, perfectly normal human reaction. I’m not dissing anybody for feeling this way. It’s totally normal to feel this way, but as a product manager, essentially I have to remember that that feedback is not someone actually using the product. That’s someone looking at a picture of the product. Same thing was true, I remember when the iPhone first came out and people were like, there’s no way I could ever type on the screen with my thumbs because they’re looking at a keyboard on a screen and they’re thinking about all the things that aren’t going to be there. I’m not going to have any tactile feedback. My thumbs are fatter than the, they had never used the thing. And once you start using it, you’re like, oh gosh, actually that’s not so bad. That’s actually quite good. So you’ve got to be careful about observational feedback versus, I dunno, experienced feedback and experience is not the first second someone uses it, like David’s been talking about. It’s after a while, and if someone’s not going to give it even more than a moment or two, then there’s not much you can do with that feedback to begin with because they’re out the door no matter what. But do separate those things as a product person, keep that in mind. Where’s the feedback coming from and what has been their experience with the thing itself?

David (22:17): I think this is why it’s so crucial to have self-confidence as a product person. You must create something that you internally know is good so that you have a barrier so that you have some defenses against this kind of feedback. If you are a really anxious, unsure person about your own product, you’re not going to weather the storm. You’re just going to get blown over. You’re like, oh, if they don’t like it, they don’t like it, then I’ve wasted my time. I built the wrong thing. No, no, no. You need at least two pinches of arrogance. Now, Jason, I have perhaps two buckets each, which is helpful in this regard, but you need some of it because otherwise you can’t withstand just the shifting wins. And that bucket of arrogance has to be founded in the fact that you built a great product that you would’ve bought.

(23:09): That is always our test. I would’ve picked up my credit card and I would’ve entered those numbers into someone else’s HEY calendar. That one of that calendar has to be so good that I would’ve bought it and it has to solve real problems that I actually know because when you’re solving real problems, you actually have an intimate relationship with because you’ve experienced that and you’ve tried the other thing. It’s very clear when you’ve hit a tipping point. We did this both with HEY email and we’ve done this with HEY calendar, when we switch over ourselves and give up the past systems we were using, whether it’s Gmail or it’s Apple Calendar and Outlook or something else like that, that tipping point is that moment of faith in the product. This is a good product. This product is now so good that I’m going to turn off these other products that are made by these huge companies with mega teams, blah, blah, blah.

(24:03): I have confidence in my own product. We’re going to build a v1 that is excellent by our own standards, our own determinations. So that comes down to having standards, having a sense of what is good, what is not good. You can’t be, in my opinion, an effective product person until you have some degree of discernment about what’s good and what’s not good, and you can fall in love with your own product. 'Cause that’s the other thing, you have to. If you’re not building something that’s so good that you end up loving it yourself, you’re going to be a very poor salesman for that product, and you need to be a good salesman. This thing is not going to sell itself. HEY calendar’s not going to just sell itself. You can’t just build the pyramids and expect them to come. Jason and I have to actually be the enthusiasm and the rest of the company too. Everything we do around this product has to be marketing because it’s on us to create the market, if you will, especially on something like a calendar where there’s literally decades of experience and predetermined perceptions of what this product’s supposed to be founded on the biggest software companies in the world, being in this space, right? You’re going up against that. That is such a tall mountain. Damn well better show up being the most effective salesperson you could possibly be. And you can’t be that. Well, I can’t be that unless I truly believe in the product.

Kimberly (25:24): Okay, and last question before we wrap up, kind of on that note, when you guys launch a product, HEY calendar most recently, but any of the other products you guys have launched, how much are you following along on those sales? Are you looking at numbers? Are you anticipating what’s going on? Or do you just put it out, talk about it and then see how it goes a little bit later? Where are you guys on that kind of scale?

Jason (25:45): Personally, I’m not looking at numbers initially. I’m looking at mood, tone. What are people saying? What are people talking about? What questions do they have? Where’s their enthusiasm? What do they love? What do they hate? That kind of stuff. Again, out of curiosity, not out of like we got to change this or we got to fix that, or we got to do, unless something’s broken, broken. I’m more interested in the qualitative side of it than the quantitative side of it, especially early on. What is the mood out there about this thing we just shipped? I want to be able to feel that. I want to be able to understand that and then ride that and then flow with it, roll with it and feed into it some more. So that’s kind of amplify the things that I think are really interesting takes, address the things I think that are not, but address them critically and engage in a conversation with someone like that.

(26:32): Yeah, I can see why you feel that way. Here’s my take on, here’s why we did it that way. That’s another thing I tend to try to do often is explain the why behind something that’s different. Not to dismiss someone’s opinion, but to provide some more context and color for it, because they may not recognize why something was done and it still may not matter. My job really is not to convince anybody of anything. It’s to provide information, share point of view, and then people are going to make up their own minds. But I do want to know what people are thinking and feeling about the thing once we launch it.

Kimberly (27:07): David, what about you?

David (27:09): Yeah, it’s funny because I sort of naturally gravitate towards numbers. I like watching numbers and I actively prevent myself from doing that around a new launch exactly for that reason that the qualitative feedback is just more important right away, and then the snowball effect is going to come. I just have faith in that. If we put out a product and everyone who tries it is like, holy shit, this is amazing. This is really great, which is basically what happened with HEY calendar. In fact, I would go so far as to say, Hey, calendar has been the most positively received product that I can recall us launching. Now that doesn’t mean people don’t have critical feedback. It doesn’t mean they’re not reporting bugs, but the overall tone, the vibe of the feedback is so overwhelmingly positive that I’m almost slightly skeptical. I always get skeptical if it’s too positive, just something we’re not looking at the right places or we’re not listening to the right people or whatever.

(28:03): But overall, if that is the vibe, I do believe the rest will follow. And either way, what are you going to do different? This is one of the reasons why I do occasionally stop myself from looking at numbers is if those numbers are going to tell me something where I might be slightly disillusioned or I thought it should grow faster or something, or the reverse that for example, when we launched, HEY email, the numbers were just off the charts. That launch was one in a thousand launch because we had all this attention and everything came together at the same time. So the numbers were crazy, and you could look at those numbers and then you could internally set your trajectory of expectations accordingly, and you would be disappointed until the end of time. How could anything possibly follow up on a launch like that? So I think at both parameter, whether it’s too good or it’s too bad, take a step back, especially with something like, we’re launching a service here.

(28:59): We’re going to be working on this for years to come. What it does in the first week or two weeks, it’s just not that important. I’m more interested in seeing, first of all, what does it do once people have to pay? We have only just opened up, it hasn’t even been two weeks, so the vast majority of people who signed up to try this product for the first time will not have hit the moment of truth. They have not been asked by the system yet to put in their credit card, which means that all the numbers are bullshit. So all the feedback could be like, yeah, yeah, you did great work, because they wanted to be kind. It’s a little bit of kind to asking someone’s opinion. If you go, what do you think of my product? If you have that relationship with someone that you’re asking them to their face, they’re not going to tell you, hey Joe, it’s shit. I fucking hate it. It’s the worst thing I’ve ever seen in my life. That’s just not how people communicate with each other, but it is how people communicate with commerce. They’re essentially telling you it’s shit. Well, not it’s shit, but they’re telling you it’s not good enough if they don’t want to buy. So that’s really the key signal. Everything else is kind of circumstantial evidence. The murder scene is going to be there when conversion happens.

Kimberly (30:08): Okay, well, we’re going to go through all of this again with the new ONCE product coming out soon, and with that we will wrap it up. You’ll hear more about that coming up. REWORK is a production 37signals. You can find show notes and transcripts on our website at 37 signals.com/podcast. You can also find video episodes on YouTube and Twitter, 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 and we just might answer your question on an upcoming show.