Show Notes
In this episode of Startups For The Rest Of Us, Rob and guest Derrick Reimer of Drip, talk about how to mentally and technically prepare for your launch. They give you first hand advice from things they learned and experienced when launching a new feature to their product.
Items mentioned in this episode:
Transcript
Rob [00]: In this episode of Startups For The Rest Of Us, Drip takes over the podcast. My co-founder Derrick Reimer and I talk about how to mentally and technically prepare for your launch. This is Startups For The Rest Of Us, Episode 274.
Rob [21]: Welcome to Startups For The Rest Of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at launching software products, whether you’ve built your first product, or you’re just thinking about it. I’m Rob.
Derrick [30]: And I’m Derrick.
Rob [31]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, Derrick?
Derrick [36]: The word is “Workflows.”
Rob [37]: Indeed, it is.
Derrick [40]: We just launched probably our biggest paradigm-shifting feature in Drip since we launched our automation engine about a-year-and-a-half ago.
Rob [48]: It was quite a week, this week.
Derrick [50]: Indeed.
Rob [51]: It always is, and that’s what we want to talk about today. We were in a discussion the other day, and I realized it was probably worthwhile having on the podcast. Mike is out this week at Big Snow Tiny Conf in Vermont, and since we did this launch this week and there was so much that I learn every time we do one of these – both from just a planning perspective, like, the actual tasks we have to get done in terms of getting the feature built, getting the marketing out; but then there’s also that whole mental side of it. And I think I experienced it. I think part of it is being lack of sleep, but part of it is just trying to get stuff out on a deadline, that is pretty interesting to talk about and, I think, it help folks who are interested in preparing better for their next launch, whether it’s a feature launch like we just did, or whether it’s an actual product launch.
Derrick [01:33]: Absolutely. It seems like we go through these constantly, but it somehow never seems to get easier.
Rob [01:38]: I know. I know. I wonder. Part of that might be that you just get more and more ambitious with each one.
I think about the very first launch that I did. I’m trying to think of what it was. It was probably launching a new version of DotNetInvoice, and it was release the code and email my customers, and that was the launch and that was it. So it was pretty easy, because I had to draft one email and check something into source control and put a zip file on a server.
But this launch that we did this week with Workflows – and if folks didn’t hear about it, it’s, in essence, a visual way to build a marketing funnel. So it’s centered around email, but there’s all types of stuff you can do in terms of tracking someone clicking a link, or an action they did outside of just doing stuff in email, so it’s a visual flow. I’ll put a screenshot of it in the show notes for this. Or, frankly, you can go to getdrip.com/workflows and check out the whole deal. But launching something this large is more ambitious than just an update or some bug fixes. And so we didn’t just push a feature out, we did a big marketing push to people both in our list and not. We had some loose partnerships. We had some onboarding we had to redo. A bunch of documentation had to be updated and all that stuff.
Derrick [02:49]: Right. And on the technical side, there were a lot of opportunities to break things when building this as well, and the stakes are higher because with this new feature, we basically had to rewire the app to push everybody to center their whole account around their Workflows. So it’s – yeah, definitely the stakes are higher with this feature.
Rob [03:07]: Let’s start by running through the tasks that need to get done to launch a feature or a product. Maybe you won’t have all of these in your particular case, but this is what we saw, and this is a complete representation of the stuff that we’re working on to get Workflows out this week. I think the first one is just finishing the feature itself, getting the code out there in a way that the feature or the product is done. And, frankly, you were almost done with it a couple weeks prior to the actual launch.
Derrick [03:39]: Right. A couple weeks prior, we started to get some early-access users looking at it, and we didn’t encounter a whole lot of technical problems after they started using it. There are a few things here and there, a few recommendations on things we can improve, but it was pretty technically sound. At that point, we started looking at the other tasks that were needed to actually get this launch started.
Rob [04:01]: Right and the plan for this one was to do a little bit of a buildup. Since it was such a big feature we were getting out, we didn’t just want to launch it and send an email. We actually wanted to give a teaser a couple weeks in advance, but the thing is once you send a teaser email like that, you’ve basically set a ticking clock, right? You’ve started a timer. And assuming you want to hit the deadline that you’ve committed to – which, for us, the teaser said, “It’s coming in two weeks” – we know people will give you a day or two, but if you go a month after that, people are going to notice. So we really wanted to mentally focus on hitting that. If you’re going to do that, then you’d better know everything that needs to get done between that point and the day that you’re going to launch.
And I felt like we did a so-so job of that. I felt like, technically, we were dialed in, but there were so many other things that we discovered after that like, “Oh, all of our knowledge base docs. We need a ton of knowledge base docs for this.” We had a lot more marketing collateral and email copy and blog post copy and filtering of lists than I thought we were going to have. Then there were also a few things on the technical side that we had to expand, and we discovered that, I think, the day we sent that two-week email. You and I went into a conference room, and you said, “We need to rework some stuff.”
Derrick [05:12]: The big thing that jumped out as soon as we started the clock ticking was our entire user onboarding – basically, we call it our “guided setup”, which is a few screens that ask you some questions when you first sign up for a Drip account and basically helps us to auto-generate some things in your account, like a campaign and an automation rule and things like that. We realized that, basically, our whole guided setup was centered around our basic automation rules, and now we’re trying to get people to shift into centering their whole account around Workflows. And when we originally built guided setup, I think it was at least a month long of planning and iteration and building out how exactly should this wizard work. So, yeah, it was a little frightening to realize that late in the game that we had missed something so large.
Rob [05:58]: Right. So, again, the feature itself was pretty much feature-complete, code-complete, and it was even in beta, so it was pretty heavily tested. But the realization of, “Oh, yeah. Our onboarding doesn’t push anyone into Workflows. It’s going to take them through this older style of stuff,” we had to sit there in that conference room and say, “How can we best do this in a way that works for our new trials, but that doesn’t take more than two weeks, in essence, because we literally have a ticking time bomb?” And that’s not something we do. We don’t do deadlines here at Drip. We just haven’t ever set a hard deadline like that. We push, and we try to get stuff out on a time schedule, but we don’t kill ourselves. We have the luxury of doing that, since we don’t have the investor timelines and we don’t have a burn rate. And so that was, I think, kind of a new experience for both of us.
Derrick [06:41]: Totally. And there were some other features that I really wanted to add in if I had time in the two weeks leading up, and when you’re looking at it a month out, you feel like you have a lot more time than you actually do. When that clock is ticking and you start looking at, “Well, this is how many business days we have left until that deadline, and if I do sub out some of this work to someone else on the team, we’ve got to review everything, make sure everything is airtight before deploying it.” So you realize how quickly those deadlines come up. I definitely had to cut out some features that I really wanted to add in the interest of getting our onboarding done.
Rob [07:16]: Right, and so those will go in post-launch, and I think we prioritized those yesterday.
So in terms of actual tasks, we’ve talked about a couple so far. I have a total of eight here listed. The first was basically finishing the feature or the product itself. The second one was – for us, it was realizing that, “Oh, there’s this extraneous thing that’s impacted.” It was our onboarding that was impacted. So I think, as a listener to this, if you’re launching a brand new product, you don’t have to worry about this, but if you’re launching a major, new feature, try to sit down earlier than we did and think about, “How does this feature impact other features in the app,” such as your onboarding, or such as other flows that are already existing. Because I think that while technically everything would’ve worked and nothing would’ve crashed, it would’ve been a poor user experience had we not circled back and done that.
The third thing that I thought was interesting was we had maybe 5 to 10 alpha users, and then we had close to – I think it was between 20 and 22 beta users who were really digging in and building production Workflows. I was working one-on-one with most of them, answering questions via email. If they ran into any issues, we were correcting them or clarifying them. A lot of them were just questions or misunderstandings rather than any type of technical bug or issue, but the amount of feedback that generated and the number of tweaks we made based on that was not inconsequential. We added a couple features based on some really good advice from some – these are very knowledgeable, influencer beta users who use other products that compete with us. We wound up adding a couple new features within the last couple weeks, as well as making some tweaks.
How did you feel about that and how that process went?
Derrick [08:49]: I felt really good about that. I always enjoy getting features in front of customers early on, because it’s like we talk about, with launching brand new products. You never want to go off in your basement and build for months, without getting it in front of potential customers or people who are really knowledgeable about the problem space you’re trying to attack. So I felt really good just showing it to people and hearing this feature that I thought made perfect sense, as soon as someone else looks at it, they’re a little bit confused by it. Then as soon as we iterate on it and work on it, then it becomes clear that, “Oh, yeah, it totally makes sense what they’re saying.” So I like to think of any big feature like this as almost a brand new product that we have to do adequate customer development on and getting it in front of people.
Rob [09:34]:And to be honest, I found that having knowledgeable beta users using it in production flows and giving us feedback made me rest much easier when we did the launch, because I knew that it had already been battle tested pretty well and that a lot of questions had been answered, and those early rough spots in an early product were ironed out by that point, right, because we had folks who were using it and offering suggestions in a controlled environment where we didn’t have 500 people or 1,000 people using it. We just had ten or 20. So if you have any time where you can carve that out and give yourself even a week or two to hone the product based on user feedback, it will make you sleep better the night before launch.
Derrick [10:15]: Absolutely. And just back to the point of part of the process of finishing the feature, I feel like this is included in that, where immediately I felt better once I was able to take this feature that I’d been working on for a few months and actually deploy it into production behind some feature flags. So just knowing that this code is actually running on our live servers, nothing’s falling apart, and now we can tick a box in our admin screen to open it up to people and start getting people using it, that’s just a major load off my mind.
Rob [10:45]: I agree. That’s another good point, and that’s something that we’ve done a lot over the past couple years is we try not to have these big branches, these two-, three-, four-month-long branches/features that are not merged into the core codebase. Because one of the worst things that can happen on launch day is not only are you worrying about all those extraneous tasks and the marketing and the docs and all this stuff, but you’re also trying to merge in code, and you’re breaking other things. So that’s something that you’ve been really good at, is along the way, you were trying to get as much code into production months before we actually launched this thing.
Something else that I was thinking of that we didn’t have to do here, but may happen if you have a really big launch list, or if you think that this new feature is going to be hitting your servers hard is some folks have to increase their capacity. They either have to staff up with support, or they have to increase server capacity, spin up new VMs and stuff like that. We didn’t have to, because we don’t see this as being a big load on our servers.
Derrick [11:43]: Look, fortunately for us, this one’s pretty light on the servers.
Rob [11:48]: The next task that you’ll want to think about – and this is our fifth one we’re talking about – is essentially getting your documentation up to speed. We call them “KB docs.” They’re knowledge base docs. You can check all our stuff out. It’s at kb.getdrip.com, see how we structure it; but for a feature like Workflows, that’s almost an app unto itself, you need docs that show people: a) how to get started; they need a quick start guide; b) they need a more encyclopedic list of what do all the steps do in these categories and what are really the ways to use this. And then they probably need some case studies or use cases. They probably need an FAQ. They might need a migration guide of, “This is the way we used to do it with one-off automation rules, and we’re still going to keep those around for certain purposes, but Workflows are now the main focus. And if you can, and it makes sense, then move yourself into Workflows from rules.”
So all that to say that’s not just one KB doc. That’s not just cranking up WordPress and hammering something out. And this really requires some planning in advance, and luckily we have the help, and we were able to get Anna to write all these KB docs. But I can’t imagine if we were still a two-person team or a three-person team, this would have been an enormous amount of effort for us to do, in addition to the marketing and the technical side.
Derrick [13:01]: Oh, man, yeah. It’s really easy to think that the feature itself is the hardest work and to think, “Oh, yeah, the documentation – that stuff, we’ll maybe work on it the day before.” But watching Anna, our customer success person, flesh out all these docs and start rerecording help videos and rerecording her demo videos that she sends to folks who want to watch a video demo, it’s been a monumental effort, for sure. Just a few days before launch, we were all sitting in the office, and you and Anna were both editing videos, and I watched you guys sit there for hours. I realized that the editing process is really time-consuming. So things like that, it’s important to keep in mind that everything takes longer than expected, just like feature development.
Rob [13:42]: Exactly. Exactly.
Last couple things. One is basically just your marketing plan and your marketing collateral. For us, there was a lot of email copy and thought put into how that was going to be sent because we have a lot of segmentation, right? We don’t just want to send our customers, our marketing lists, all the same stuff. If people are in a trial, they probably want to hear something different about the feature. If they’re a customer, they want to hear something different. They want to see KB docs. If they’re just on a marketing list, then they probably don’t want to see KB docs. They really want to hear, “Why is this important to me? Should I sign up for Drip?” because they’re not even a customer yet. So thought went into how the emails were structured, and then announcement blog posts, and then we had the whole Features page that we added. You brought it up two weeks in advance, and then it never made a list, and so then it was like two days before, and we were also scrambling to get that out.
But there’s a lot to be thought about here. It, again, is not just so feature-centric. Especially if you’re going to do a launch that requires multiple phases of marketing, where you’re not just sending a single email, but you’re doing a two-week-before and then a day-before. Then that day before, realize that if you create any type of stir or conversation, you’re going to be on Twitter a lot of the day. Or you’re going to be answering emails. Or you’re going to be helping answer questions on forums, or in Facebook groups, where people are talking about us. So a lot of time can be pulled into that, so it’s better to be ahead on pretty much everything and not waiting last minute trying to do that, and still finalizing the next day’s copy.
Derrick [15:08]: Absolutely. A lot of this stuff we talk about, like the demo videos, the KB articles, the blog posts and feature pages that explain what this is, all of that, you could probably skip some of that, but what you’re doing is potentially creating a much larger volume of support and questions afterward. So part of this is doing the work up front to mitigate the amount of questions and support emails you’re going to receive, and also just it makes customers happier if they can figure things out on their own and things are intuitive. And when they do have a question, the answers are right there at their fingertips.
Rob [15:40]: Right. Another thing that we did pretty well with is you have to prioritize. For a while, I kept saying, “If we can do a screencast – if we have time, then we will do it,” but that is below the priority of just getting the features page up and just getting the launch copy written. As it turned out, I was able on the last day, to get a screencast recorded and edited, and we got it into production after getting some feedback from you guys. But if we hadn’t had time, if something had gone sideways, we just would’ve launched without it, and that’s okay. You don’t need all of this stuff. This is trying to approach the perfect launch. We really were thinking, “What is the ideal launch that we can do that will give us maximum impact, maximum conversation, maximum number of trials coming in, the least amount of support?” because we answer questions up front. That’s what you’re trying to think through, but you may not be able to do everything that you dream up, and there may be some things that you do have to leave on the table, in essence.
The last task that I want to talk about is interesting. It’s another marketing piece, but I found myself spending a lot of time working with our early users, our early-access folks. Some of them are influencers, and some of them are just people who are power users of Drip, and so we wanted to get them into an alpha just to play around with it. We knew it was still buggy. This is, like, November, December. Then we pushed it into beta in, I think, early January. And that’s when we started doing a lot of production work, production flows for ourselves, and other people started building it. The nice part about that is I was in such steady communication with them that by the time we launched, these people knew how to use it pretty well, and they were able to instantly throw stuff into production if they didn’t have it already. And since they’d been part of the process, they began tweeting about it and talking about, and it definitely drove conversation and it made people feel like, “Wow. These Workflows are everywhere.”
That’s approach you’re trying to go for. So we had [Brenan Dunn?] record a screencast yesterday all about a flow he built and threw into production. We had Dan Norris posting in his – he has a seven-day startup, private Facebook group, and he was posting in there about it. It’s because these guys we’re in early. They’ve been longtime Drip customers and they were using Workflows for a month before everyone else, and so they had the familiarity and the confidence in it, to then on launch day be able to do that kind of stuff for us.
Derrick [17:46]: Absolutely. It didn’t seem like it was a stretch for any of them to honestly say, “This is a super awesome feature. You should go check it out, and here’s what I’ve done with it so far.” It wasn’t forced. It wasn’t like they were pulling a favor for us, necessarily. They were really genuinely excited about it, which is, I feel like, the best way to do it.
Rob [18:05]: So the interesting part with that was it was very time-consuming, period. I did a lot of one-on-one emailing. It was totally worth it in the end, but realize that this is another task that you have to do if you’re going to go down this road. And in early products that I did and launches that I’ve done, I haven’t done this part because I didn’t have the team doing all the other stuff that enabled me to have the time to do this. Because if you are writing the code, and you’re doing the marketing collateral, and you’re doing the docs, and you’re going to handle support this is a nice-to-have, and it can help you, but it’s not in the top of the list – right – in terms of getting features out. But it can be powerful if you have folks who are on your side on launch day.
All right. So let’s dive into the mental side of things, because in addition to just getting the feature out and getting all the marketing and the docs, there’s this levels of stress that hit you at different points. And there’s mental games when you and I are up until midnight, and then we wake up at 5 in the morning to launch the product. There’s a certain amount of struggle that you’re going through to just think clearly and make good decisions and to sleep well when you can and get it done. So I think the way that I was thinking about it is a couple weeks before the feature launched, before we set the initial, “Hey, this feature’s going to be out in two weeks,” we all had a conversation at lunch. My memory of that was that the sentiment was very positive. Do you recall that? I don’t remember feeling any stress during that meeting.
Derrick [19:25]: Yeah. No, I felt like we had given ourselves plenty of time to build the feature, to test it, to get people using it. We already had our beta users banging on it and making sure that there were no bugs, so I felt really calm at that point.
Rob [19:36]: Then we sent the two-week email, that started the clock ticking, and then essentially that day or the next day, we realized, “Oh, we have to rework our whole onboarding.” What did that do to your psyche?
Derrick [19:49]: That definitely added an element of stress. I don’t know why setting a deadline in public like that somehow opens up areas of your brain to think of things like onboarding, but as soon as we did that, I can remember the moment and starting to think of, “All right. What do we really have to do in the next two weeks, because things have gotten real here?” And that’s when all these little things like – or, big things, like onboarding, started coming up. At that point it wasn’t – I don’t feel like it was toxic stress, but it was definitely stress.
Rob [20:18]: That’s a good point you bring up about setting a deadline in public really puts your feet to the fire. And I agree. I also started really gathering the list of deliverables at that point, and we really should do that before we set the deadline, but you just don’t. It’s just the nature of how we’re rolling. If you’re moving fast and doing things, I think you’re just – maybe it’s, like you said, your mindset shifts once you’ve committed to something.
Rob [20:43]: And I think that’s a good thing. I think that’s a lesson for listeners to take away, is if you find that you’re just pushing it off and pushing it off, maybe just set a deadline in public even if it’s just on Twitter, or even if it’s just in a blog post. It may not be to 10,000 people like we did but maybe it can be to 50 or 100. And if you feel that pressure, it can be something that forces you to make some tough calls towards the end. I could totally have seen that if we hadn’t set that two-week deadline, that it may have taken us a month to get it out. We may not be launched, because there were things that were coming up that we were like, “Oh, yeah. There’s this other feature someone just asked for. Should we build it before launch or not?” And if we could’ve pushed off launch, we very well may have decided to.
Okay. So that takes us up almost to the launch. I think the week before, we were doing fine. We were hammering stuff out, and then really the day or two before, we all came into the office. We typically come into the office a couple days a week and we really packed those days before launch with office time. We essentially launched on a Wednesday; and for me, personally, I felt like Monday was intense, but not stressful. We were all very focused. In fact, we normally have a lot of conversation here in the office, but I felt like we all had headphones on with some type of deep-focus playlist. We knew what we had in front of us. Did you feel the same way?
Derrick [22:00]: I did, yeah. At that point, it was all hands on the feature. We all had our own individual tasks we were working on for it. There were a few points where we wanted to be in the same room, because sometimes you just get those spontaneous – someone has a thought, someone brings it up. Another person hears it and contributes, and magic happens. So I think we had a few of those moments, and some really good things came out of it, but for the most part we were pretty heads-down.
Rob [22:24]: And I think that, as a listener to this, the theme for those 48 hours before launch is “focus.” That’s what. You have to focus in. We sat around the whiteboard, and we figured out what were all the – we threw them out. What are all the tasks that need to get done? And then each of us took their tasks. I had my own Trello board, and it basically had the list of tasks, because I was writing the email copy and segmenting the lists and running lists through some processors and trying to get the screencast done and talking with our launch partners. You were finishing up features and onboarding. Anna was doing KB. Ian was doing other stuff. So I think the fact that we did that once, got everything out on the table that we knew about that had to get done, and then all went into our little cocoons of deep-focus sound. I think that’s a way better approach, way less distracting and way more productive than always having something new, then not thinking of everything –
Derrick [23:11]: Right, absolutely.
Rob [23:12]: – and having the interruptions.
Cool. So the night before launch, I was stressed.
Derrick [23:18]: I was pretty stressed as well. We had just wrapped up the onboarding stuff, so of course it took a little longer than usual. We were so heads-down on our tasks that we had – we had tested it. I had tested it locally, and Ian had tested it as well, but we basically started doing our final run-through. We had it deployed in production, so that only we could see it, and we started –
Rob [23:41]: Right. This is just onboarding, not the feature itself.
Derrick [23:44]: Right, just the –
Rob [23:44]: Just the onboarding code, yeah.
Derrick [23:45]: – onboarding. The main feature itself was solid, but the onboarding, we were doing final run-throughs, looking basically from a very high level, end-to-end, what is the user experience of signing up for a trial, going through onboarding, the guided setup and then looking at your first Workflow. There were definitely some things that we all caught that night that were just extra polish things, but that path is so critical. So to be working on those things at the eleventh hour, essentially, was pretty stressful.
Rob [24:17]: It was literally the eleventh hour. It was 11 p.m. and we were on slack. I’m starting to nod off in my chair, because I’m not as young as I used to be, and I’d been getting up early to do stuff. I was like, “Oh, man. I just went through it, and this part – what are we going to do about this?” I know that at 11 p.m., that’s not what you want to be doing the night before launch.
But it was cool. We came up with, I think, some really good tweaks and we added some yellow highlighting to something just to call it out, because I felt like people wouldn’t see it. And we came up with good solutions that you were basically able to implement in under an hour.
Derrick [24:47]: I was pleasantly surprised that the problems that we did discover – or, not necessarily problems, but just things that could’ve used extra polish – that we were able to come up with a quick solution and deploy it in a way that it didn’t feel like making some last-minute change that might break a bunch of stuff. So it worked out pretty well. It could’ve been worse, but it turned out to be pretty smooth.
Rob [25:09]: And I think the lesson here for a listener is we were down to the wire, but it was down to the wire with onboarding. Realize that we could’ve shipped with what we had. We were not tweaking the production feature at this point. That had been feature-complete, code-complete for a long time with beta testers and all that, because that would be really scary. I would’ve pushed the launch off if we were still tweaking code the night before, because there’s no chance that we could launch to that many people with any type of question that we were going to have some buggy interface. This really was small stuff. So there was a certain level of stress, but it was a lot less than if we suddenly discovered some major flaw in the feature itself. In fact, we would’ve just pushed it off at that point for risk’s sake.
So there’s interesting levels of stress that go along with a launch like this. One can be a technical one of, “Oh, man. Is the feature going to work? We haven’t tested it well enough.” Try not to be in that boat. We were not in that boat, I felt like. There’s other stress, though. It’s all this work and all this time. Because it was five, six months of development, and then the last several weeks, it was the whole team, all hands-on, doing all this stuff. “Is this going to be worth it? Or is no one going to care?” It always goes through your mind. Or, “Are people going to be haters?” Are people going to be critical of it? Is something going to happen? Are we missing it here? So were we going to get criticism, or negative feedback, or is no one going to care? That’s another stress, I think, doing this, because you’re really putting yourself out there.
Derrick [26:25]: Totally. Are people going to sign up? We’ve just completely transformed the whole guided setup, the whole onboarding process. Are people going to be completely confused and not know how to use the app anymore in such a large shift like this?
Rob [26:38]: So we woke up on Wednesday morning around 5:00, 5:30, and we deployed everything. I remember you said, “I’m pushing the button,” and I logged in, and there were such minimal changes, because all the code pretty much was already in production. And all you did was add Workflows to the marketing site top nav and changed where the automations button. It was some very minimal stuff. So I remember feeling calm in the sense that the complex code that was in production had been in production and being hammered on for weeks, and the only changes were more aesthetic, I guess.
Derrick [27:11]: Right, just basically opening it up – removing the feature flags and opening it up for everybody.
Rob [27:15]: Yeah, which was nice. I’m always surprised on launch days. I think it’s a good thing, but launch days themselves tend to be anticlimactic. Did you feel that way as well?
Derrick [27:26]: Yeah, I did. You see these startup launches are things that create a big splash and a big viral wave of chatter and people talking about it. And we definitely had a lot of chatter on Twitter and things, but, by and large, it wasn’t like we had a thousand new users sign up, or servers going down, or – basically, it always end up being calmer than I expect.
Rob [27:48]: And I think that’s a good thing, because I think there certainly were conversations going on online, and we were responding to that kind of stuff; people talking about it on Twitter, and that’s a good amount of action going on. What you don’t want is the action of bugs being found, or people running into problems or getting confused. If it’s calm, probably consider yourself lucky as long as people are talking about it and/or signing up for trials.
So the day of, I didn’t feel too stressed about it. You as well?
Derrick [28:15]: Yeah. I felt really calm the day of. I did have trouble – for some reason, I had trouble focusing on the day of, I think because you’re just on edge, waiting for the other shoe to drop – like, “What’s going to go wrong?” I was looking at my list of tasks and things that I wanted to get in before launch, but didn’t quite have time and thinking, “Should I start working on one of these right now, or should I be trying to anticipate what might go wrong and get out ahead of the problem?”
Rob [28:40]: I totally agree.
Derrick [28:41]: I think I had that going on just looping in my head, and I think it affected my ability to focus that day.
Rob [28:47]: I think that’s something good to take away – is consider your launch day a non-working day. You’re going to sit in front of your computer all day, and you should, and you should interact with people, but you will likely get zero work done. Because I was in the same boat as you. I sat there and stared at my email queue. I really didn’t have anything to do after the emails went out aside from handle some email and some important conversations, but that was very minimal. Yet, I feel like I accomplished nothing that day, because I had that same track playing for me of, “What’s going on?” “Where are we?” “What’s going to happen?” It’s kind of like the stress that built up over the previous two weeks – it doesn’t just go away when you launch. It doesn’t dissipate. It hangs around, and I think that launch day is the day where you’re able to blow off that steam and release it. Because for me, the day after launch was actually when I came back and I felt really good. I wasn’t depleted anymore like I was on launch day.
Derrick [29:34]: Right. And we were a little tired, too. I know I took a nap on launch day when I found a lull in the afternoon.
Rob [29:40]: Well, yeah, after five hours of sleep, it’s probably a good idea to get your wits about you.
Hopefully, this gives you some thoughts and ideas and a checklist of how to mentally and technically prepare for your launch, whether that’s a feature or an entire product. Again, you may not run into all of these things, depending on the size and complexity of your launch, but these are definitely things to think about and get out ahead of before you do so.
So thanks for joining me today, Derrick.
Derrick [30:05]: Thanks for having me. It was a blast.
Rob [30:07]: And if folks want to keep up with you online, where would they do that?
Derrick [30:10]: Probably on Twitter @Derrickreimer.
Rob [30:12]: Sounds good.
If you have a question for us, call our voicemail number at 888.801.9690, or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for “startups” and visit startupsfortherestofus.com for a full transcript of each episode.
Thanks for listening, and we’ll see you next time.
