Craig Kerstiens: Hi, thanks for joining us. I'm Craig Kerstiens. I'm over at Citus Data. I was previously at Heroku running product for a number of areas there. I managed product for Heroku data for a number of years, the Heroku ecosystem, and previously on some of the core platform.

Rimas Silkaitis: Hello my name is Rimas. I am a PM at Heroku right now. I am currently overseeing Heroku data. My career, the thread throughout it, has been data, doing anything from analysis to engineering, to even product management.

Craig: Since this is the first one, we want to give a little bit of context of what we're thinking to cover a little bit. Product management I think is a hot topic lately. I've had a number of people, I think almost one to two a week, come and ask me, "How do I get into it? What is it? What do you do?"

I really want to get down to some of the practical sides of product management in this podcast. There are lot of books that are really high-level out there, of the broad themes of product management. We want to get a little more into the practical bits of it and hopefully give some tips and some useful information for anyone looking to get into it, anyone doing it or anyone that may be doing it and not realizing it. How can you get a better practice going?

Today we're actually going to kick it off a little bit with something I've been active with the past couple weeks and likely for the next couple weeks of launches.

Things will ship no matter what, with or without a product manager. But a product manager really can give a bigger emphasis to something when you do decide to ship it.

Of course the main vehicle for that is through a launch.

Rimas: A launch can encompass many different things, anything from the smallest things, to maybe just a blog post, to full-out analyst briefings, full media, you name it. There's really a wide spectrum here, and we're going to narrow this down into something that's approachable, at least for this first episode.

Craig: That's a really good point, Rimas. Starting at the blog post piece. I think that's where most startups start, right? I look at all the Heavybit companies, and they really start off just building a thing, writing content, and launching each feature when they're ready.

They built it and they just ship it, and the blog post is the event of the launch. If it's a successful one, it goes up on Hacker News and does really well. Well, there's a lot more pieces to that, and when you start to timeline these, there's a lot more coordination that goes on. I think that's an interesting place to start, right there, how far out do you decide a launch?

Rimas: It could be as far out as you want. For me personally,

I like to think about the launch when I'm thinking about building any new product, right off the bat.

Only because that launch won't necessarily dictate what we build, but we think about how that is being presented to the customer, in any given realm.

Craig: I think that makes a lot of sense, and I think from a product marketer angle, you're thinking about the next launch as soon as you finish the previous one. But when do you decide that date? For me right now, I actually just nailed down a date for a launch that's about three weeks out.

Now I've got this back-working timeline now. How far out is that, and where do you begin communicating that to engineers? That's a big piece, right? Because you said the day you start to work on all these things that you mentioned, analyst briefings, media briefings, the blog posts, docs. Like there's a lot that comes in to launching a new product or new feature. How far back out do you roll that date?

Rimas: That depends, for me, at least. It really depends on the type of product your building and the comfort you have with your engineering team. Because the worst thing that you want to have happen is that you set a date, and then all of a sudden, two weeks before that date, you realize that half the features you wanted or what would make a complete product can't actually make it in there.

You're now all of a sudden doing the last thing that you have possible, which is cutting scope. Well, I guess that's not the last thing.

The real last thing you could do is push that date out. And that's actually worse than cutting scope.

Craig: That's a really interesting piece that you hit on right there. You've committed to a launch, you've got a date, engineering's slipping. What do you do there?

Rimas: Personally, it really depends on the product and it really depends on the size of the launch, to be honest. Because if I've gone and done a humongous setup, briefings, talking to media, doing all this other stuff, then it actually becomes really difficult to pull back on that and say, "We are not going to be able to make this date."

That already communicates something to these analysts, that you cannot actually deliver when you say you're going to deliver. So cutting scope, in my mind, is the first thing that I do, and if that's not possible, depending on how big the launch is, we'll dictate if I can push that back. If it's just a blog post that we're going to do ourselves, for sure, I'll push that back and it's no big deal.

Craig: From personal experience, there are a couple of "free passes" you get, especially with respect to the engineers, right? You can have a marketing-driven launch. What I mean there is that a marketing-driven launch is when you announce something but you can't actually use it.

This is a thing that you'll see more and more big companies do, launch a product that you then have to go and "contact us," and then you get on a waiting list, and eventually you maybe get access. And maybe the product never ships.

Rimas: Don't forget, you'll always get a demo, right? You'll get some sales guy that'll come in and say, "Here, let me give you a demo first." And that demo may or may not really exist.

Craig: The customers will buy the demo, so don't worry, it works. You can do a marketing-driven launch, and it's not the end of the world. I kind of hate it from an engineer perspective. I want it to work. I want to be able to download it and use it, and that's important. But, it's not the end of the world if you have that, and you can run with it.

I think the interesting piece there is how many times can you do that? And once you start to do that so many times, you suddenly change the community and the culture of your organization; You're not actually, really, shipping things. You're just kind of promising things that you hope you deliver on.

Rimas: Speaking to credibility with engineering, that's first and foremost in my mind. Yes, a great launch is very important. But you're not the one building the product day in and day out and dealing with operational issues like pager burden or whatnot.

Making sure that your engineering team is happy and on board with what you're doing is especially critical. For any date that I pick for a launch, I always try and make sure there's enough buffer there for the engineering team to feel like, "Okay, we're set with what we've got." And we've got a couple of weeks to just let it sit around before we actually say, from a marketing perspective, "Okay, this is a thing."

Craig: There's a couple of things you hit on. I think product management's an interesting topic, and it's a bit of a not loved word among engineers in the Valley. Not as bad as project management, but still, it's not overly loved, right?

A good thing that you can do is that a really coordinated, successful launch gives you that respect. Things were in place, and you weren't scrambling. The product was ready, docs were ready. It was super smooth. Then really what your focused on in those two weeks before the launch is all of that announcement piece, all that marketing piece, all the sales enablement piece, all that coordination.

From experience, if I've got a major launch myself, two weeks out before, I'm almost not talking to the engineers at all, I'm talking to everyone else in the org, really kind of championing everything they've done up to that point.

Rimas: Definitely.

The time in a launch to be finishing up features is, again, maybe two, four weeks out from when you're actually going to be doing these things.

I would actually even say that you should be preparing marketing, depending on the size of your organization. If you are marketing yourself, then just talk to yourself, I guess. But you should be talking to these other ancillary groups as soon as possible to get them prepped, because they have their own timelines. They have their own schedules.

If you're not prepping them for what's coming, they're not going to know about it and there is that risk where you're not going to have your product be highlighted amongst all the other things your organization is doing. Me personally, I try to do it as soon as possible.

Craig: I think that I generally agree with that. I think that depends a little bit on which part of the org you're talking about. Marketing, you definitely want to be telling them far out. Sales, I almost don't want to tell them until the day before launch day, just because you want to be ready, that people have the information at the right time.

Sales is an important one where usually I'm giving them that information the day before and the day of, and then I give it to them for three months after. So to sales, I'm launching the thing that I launched three months ago, over and over and over again, internally within the org.

Rimas: That doesn't mean that you shouldn't have all your sales materials ready, it just means that you can get it all ready ahead of time, and then go give it all to sales on the day of the launch or maybe a few days before.

Craig: On that day of the launch piece, there are a number of pieces that you're busy doing. In the days before, you've been busy with media. Weeks before, busy with analysts.

There's one thing that we were talking about a little bit earlier, about war rooms. I know you've got some interesting opinions there. I've got a few. First, what is a war room?

Rimas: Conceptually, to me, a war room is one of these situations where, the day of launch, you get everybody together in one room, call it "war room," and you all push out everything that needs to get pushed out at that time. Whether it be product, marketing, or both, you just see what happens after that point.

Craig: I think in the most extreme cases, you also have anyone that could ever need to do something. That's a full-on extreme. Usually get a person that needs to make a decision or flip a switch, right?

Rimas: That can include sales, that can include marketing, that can include your execs. Frankly, it could include almost anybody. But, frankly, for me, I don't really believe in war rooms all that much. Maybe they might be useful in some circumstances. I'll throw that in there and we can discuss that.

But frankly, I think that if you've done all the work ahead of time. When it comes to day of launch, it should almost be inconsequential for many teams within the organization.

Craig: Yeah, I think that makes a lot of sense. Though, I was talking with an engineer earlier today, and the idea of a war room was to them was actually to kind of celebrate, right? It was to set their track monitors, see what's going on. Yes, the actual act of flipping switches should be trivial, but it's a good way to build rapport with these other areas you don't see very often.

I talk to marketing occasionally, but I'm not in their weekly meeting. It's at lunch, it's at coffee, that kind of thing. So when we've got this big launch, and they've contributed to it, how much can I sit there and track active changes with them, help them kind of feel like it was a major success that they contributed to, then really do that across all of the areas.

Rimas: Interesting. I find that I like to keep my celebration to after work, and then we'll all go to the bar and enjoy a few beers instead.

Craig: I don't know, if it's a big enough launch, you can definitely have some mimosas to start off the day.

Rimas: One of the things that I wanted to talk about here is that we always assume that launches are the full GA of a product. One of the things that I've seen in the past, or at least I've done in the past as well, is that the launch is actually a public beta.

One of the challenges I find with public betas is that you've actually spent your marketing dollars, not necessarily dollars in the context of hard earned cash, but in the psyche of people out there, customers, etc. "Hey, I've got this thing, it's coming out, and now it's in a beta."

So then you come to GA, it actually isn't as exciting as it would be for public beta. What's your take on public betas?

Craig: I think we've got a really good example there, of Gmail. How long was Gmail in public beta? Was it a full 10 years?

Rimas: I think so.

Craig: It was a massive amount of time, and I don't even remember when they pulled out the GA announcement. Maybe there was a post on Hacker News, but I don't recall it.

I think that's really interesting, where in the tech world, we've gotten a little hesitant to flip that GA switch.

Let's go to public beta, let's do the launch like it's a GA but not have that stamp of approval. So I think we've, across the board, gotten into this habit of using the public beta. And it creates a really hard issue for customers to know how reliable something is.

Rimas: On that note, I actually like going another route. If you've already got customers, or maybe if you're not ready to launch yet and you find a group of early adopters that are willing to try out your product, you work with them in doing what I call "the private beta."

They feel like they've got the attention from the engineering team, the product manager, everybody else, so that they can contribute to this product as well. And then you get to GA, launch the whole thing, and then tell the rest of the world, "Yes we're ready to take on new customers."

Craig: I think you hit on something small but very important there. If you've got that person you can work with, that customer, that launch customer, you've basically got a product that's been running. And I think you'll see that in a lot of public betas.

They'll announce "This customer's been using it already." And really what you got there, truly, is a GA already. So as much as you can do that and have that reference customer, that customer at launch has actually been using the product that you're launching and not the fun demo. Then you're in a really good spot to go directly to GA and have more of that validation. So I think that makes a lot of sense.

Engineers are really interesting, right? Thinking about developer-focused products and companies, developers follow things and love to feel like they have the inside track. It's one of the things that I've used very commonly to help vet that thing. Sometimes you don't always have a list of friendly customers that you can reach out to for that private beta.

Sometimes you do actually have to take a leap of faith and get it out there. And leaking things is one really interesting way to do that.

You can seed that with friendlies, you can put it out there yourself anonymously. But it's a interesting way to test things a little bit more.

Rimas: Have you ever leaked anything and it's gone poorly? Like everyone wanted to sign up, or the product just blew up in your face?

Craig: Not offhand. Now that you say that, I'm going to be a little more hesitant on leaking a few things, probably.

Jumping a little bit back to knowing when the products ready. We talked a little bit about coordinating a launch from a macro standpoint. How do you know when the product's ready?

If you want to have the product completely done and in place before you even start to coordinate the launch, which takes a little bit of time, how do you get to that point to say, "Now we're ready to launch this." Engineers tend to say, "Let's iterate on this, let's iterate on this, let's improve it."

We can always make it rock solid. But when do you actually ship it? How do you decide that?

Rimas: Again, always with the caveat "it depends." It really depends on the product that you're launching, the scope of it, etc. It really depends on what you're trying to accomplish.

One of the first questions that I like to ask myself, and I learned this through working with individuals like Craig or other people at Heroku like PBH, the question you really have to ask yourself is, "What problem are you trying to solve?"

If you can answer that, and your feature actually solves that problem, doing any extra duration beyond that point is almost not necessary.

If you define your hypothesis, you've proved it out, you have done the work to say, "Yes, this thing is going to solve this problem," then by all means, go and launch.

That really depends on the type of solution that you've come up with. It can be grand in scope, where you've come up with a whole new product line, or it could be something as simple as changing all the plan types that you have, that you're selling as a SaaS product. Again, it always depends on how big this is, and that dictates when to actually launch.

Craig: I think there's a common theme of "When is someone willing to pay for it?" That's when something's ready to go.

I actually picked up something else from one of the Heroku founders, Adam. He was basically like, "Give it to some users. Whether it's feature flagged or private beta, or whatever, let them use it. Then email them and tell them you're taking it away from them."

If they're not cursing at you: "You're so dumb, why are you taking this away, this is the most valuable thing you've ever done," then it's actually not the right thing to ship. Which is a pretty strong kind of attitude, but it really keeps that high-quality bar and says that someone actually, really does use this.

I think if you ask the other question a little more softly, the inverse of that, and say, "Is this useful to you?" If they're friendly customers, they're going to say, "Yeah, sure." When in reality, the data might not say they are actively using this.

Rimas: Definitely. So, timeline, you talked about when is it right to launch. Talk to me about what happens post launch, because I've had a lot of people ask me, "Great, I've done my war room. What happens the next week, two, three afterwards, and what happens next? It feels like I've spent all this time doing this, and now I don't know what to do next."

Craig: Ideally you're tracking that launch, getting ready for the next one already, starting to prep that. But I think you mean more on how I measure my recent launch. How do I actually track that, now that I've announced something, now that we've got all these new leads into the website? What do I do?

I think the number one thing you're going to be doing is just high touch with customers, right? You need to make sure what you launched is working, that they're happy, that they're engaged.

Rimas: But doesn't that depend on the type of product you're selling? I would imagine a high touch product would be something to enterprise customers, where I'm doing more B2B-type sales. What about B2C-type products?

Craig: On the B2C, I think you're going to be doing a lot of measuring your data, right? So you're going to take the same kind of input, or a different kind of input, but have the same kind of action. You're going to be adapting the product, you're going to be fixing things, you're going to be modifying features slightly. No major new plans, but you're going to be adapting things.

I think on the B2C side, you're going to be a lot more on the data side. You may do some outreach to customers, you may do some interviews, but those are pretty high bandwidth. For me, the number one piece is data, right?

Even on launch day, I'm sitting there looking at the data. How many people are signing up? How many people are using this feature? I'm running queries live, I'm refreshing dashboards.

One of my favorite things to do in a war room, is to have a bunch of these different dashboards up while people are flipping switches. I'm seeing that impact in real time.

Rimas: I'm glad you brought up data. For two data guys, it's natural for us to talk about it in anything that we do. But it's also critical when you're thinking about your launch, to think about how you're going to measure all of this stuff. Because if you go and build something, and then launch it, how are you going to know it's successful, if you don't have anything to measure that against?

It's critical that you have the support infrastructure, and I'm not talking huge projects that you need to put in flight to test or to gather metrics for anything. It could be as simple as putting a Google analytics tracker into your website to see how people react to a particular plan change or something.

But it's very important that you are actually collecting these metrics, because I've seen situations in the past where we've built things and only one or two days before launch we're like, "Oh crap, we really need to put something in here to measure this. Because we'll have no way to know what's going to happen."

That being said, it's critical to keep this data around, or think about it in a much more longer term context, because you'll need to compare launches against themselves.

Craig: I think that you mentioned that you need to do that ahead of time. It's really important. Because otherwise, if you're scrambling at the day of launch or day after, you're going to already start to be skewed by, "What data do we have? Now can I track this and influence this." Versus a fresher perspective of saying, "What is success, really?" How do I look at that from a fresh set of eyes without coming in like, "I wanted make it seem like it has success afterwards."

Rimas: Definitely.

I could make any product look successful, if I have no data.

I could come in and say just tell all the engineers I had a ton of meetings, awesome. But it really comes down to whether your product is not directly tied to revenue. Revenue is really the key in all of this stuff. So with any launch, if your product is tied to that, you want to see how that plays out. But the next best corollary is to have that data there, that shows you how you performed. This is what the uptake is.

Let's go back to the beginning of setting up the launch. We've talked about a lot of stuff, the post launch, we've talked about stuff during, we've talked about a little bit just before it. What happens at that time when you know you have a launch, and you're just iterating with engineering? Let's say you've got maybe three or four months before your launch. What are you doing?

Craig: Three to four months, that's a good little while. I think at that time, we're already in some early validation with customers. We've got an alpha stage thing of proof of concept. Kind of vetting that out. And this is really one of the key pieces of product management, making sure you're building the right thing. And engineers making sure it's built right.

On the product side, it's what's the problem we're solving for the customer, making sure the right features are in place. And I actually think that three to four months out, I'm doing more by saying "no" then I am by saying "yes." I'm already starting to limit that scope, to make sure what we have is much more rock solid.

I'd love to hear your take on that. What are you spending time doing, that many months out?

Rimas: I would say I'm doing a lot of the same tasks that you just mentioned there. I also like to spend a lot of time testing out what we're building.

I find if I cannot articulate every nook and cranny of what the product can do at that time, then I'm doing a disservice for the launch and anybody else in the company.

I do a lot of hands-on work with, for example, Heroku Postgres, right? I'll get in there, I have a number of queries and data sets and everything else that I throw at it. And then on top of that, interacting with the command line, how that product interacts with it, and making sure that every scenario or use case that I can think of, I've gone through that on my own.

There are automated test cases that we do have in the organization, but I find that doing it hands on, gives me a level of understanding that I wouldn't get from just looking at a set of use cases. So I'm very much hands-on at that point.

Craig: Yeah, I think as the PM, you're not in the day to day quite as much as the engineers.

It's actually a really nice perspective to be kind of that beginner, fresh set of eyes. Once you are becoming the expert on the system, you no longer have that perspective.

And it's really hard to back get that beginner mindset. As much as you can try to force yourself to it. So it's a really good time to be hands on and to continue to do that. Because once you sit in on enough engineering meetings, gotten enough familiar with the system, you lose some of that fresh perspective.

Rimas: Yes, definitely. That's three to four months out, I'm definitely spending more time with the product. But also recognizing, like you said, that as I'm becoming more astute with the system, I have to pull back and start bringing other people into this.

Like we had said earlier, maybe this is the time to think about private beta. Maybe earlier, maybe six to twelve months prior to launch date. It could be right now, so pulling those extra people definitely will help with that beginner mindset.

Craig: Back to that three-to-four-month piece, the other thing I'm spending time on is already some of the messaging. Early on, I'm working on my messaging for my launch. A common thing with launching a product is read-me driven development. What's the read-me? What's this do? Then go build it.

At Heroku, I actually kind of introduced something, blog-post driven development. We would write the launch announcement, sometimes at the outset before the kick off of the beginning, sometimes it was three to four months out, to really refine, what we are messaging to customers.

What are we building for? What is the high level? And from there the details can be filled in. But at three to four months out, I should absolutely have that high-level messaging. And a lot of times, on a smaller feature, that's kind of the timeframe that I'm working on that.

Rimas: You never have a situation where you've written the blog post, and then all of a sudden, you have to change scope or direction really quickly? And then that almost becomes invalidated? You've never had those situations?

Craig: It definitely happens some, but I think you can start broad and then narrow down on it. I think, as you mentioned, it's also important to think of the initial blog post, that's three to four months out, as a tool for direction, more than, "This is exactly what we have to build, I'm not going to come back and touch that."

Rimas: Excellent. So, three to four months out, we're spending time on the product. We're working on messaging, maybe even doing something like blog post driven development. Is this time to think about cutting features from product? Or are we still just prototyping at this point?

Craig: Aren't you always cutting features from product?

Rimas: Never.

Craig: Actually, it was one of the things that an engineer said to me when I showed up at his desk, and it wasn't like a bunch of previous PMs he'd had. Half the time I show up, and I mean less work for him.

I think that's always important to make sure that we're working on the right things, and not just because I can offload it off of my plate, but what can we limit down to, to make sure we have the best product possible? So I think it really depends on the key pain point. What do you not need, necessarily, and how much can you limit all that down?

Rimas: I do find myself cutting a lot of stuff, the closer we get to launch. And hopefully not cutting so much that the product is not the same vision that we had articulated at the beginning of the project.

That being said, though, there are three things that you can really change when it comes to any product or project. You've got time, you've got money, or you've got scope. If you can factor any one of those for any product before a launch, really scope is really the only one that you have.

Time is constrained. Money, you've just got what you've already got right there, and it's probably hard to dump more into it with a few months to go. So you find yourself cutting scope quite often, and it's like you said, I know plenty of engineers myself who are like, "Oh, less work for me, awesome."

Craig: I think it's interesting that you hit on time. And this is in the context of we're talking about, pretty major launches here. In those smaller launches that we hinted at earlier on, you've got that flexibility. And that can be really good to kind of build up that muscle of making sure you commit to certain timelines, you're on point with them.

If you do slip, you can slip, right? It was just a blog post. And maybe there was one blog outlet that you were talking to, but it's not 10 media briefings and five analyst briefings, and things that have to be lined up a month and a half out.

You've got a little more flexibility there, and I think it's important to actually build a little bit of practice in that timing, so that, yes, engineering estimates are always hard. But you can get that within a stones throw, within the same ballpark. And then you have a little bit of flexibility.

You need to know your rhythm ahead of time before you go through one of these major launch cadences.

Rimas: Speaking of launches and having your messaging out there, which channels do you use to launch your product? I've seen everything from posts on Hacker News to full-out media briefings with Gartner, etc. Where do you go to launch your product?

- I think the core of this comes back to, and I'll look at actually one of the other Heavybit podcasts for this, the one on PR, essentially, covers a lot of these great topics. What are the outlets?

The first thing is, you've got to know your audience. Are you targeting a developer audience? If so, there are a number of places there. Hacker News absolutely matters. Reddit matters. Twitter matters. A lot of these channels.

But there are also others that do matter. TechCrunch is still a good outlet. PandoDaily, depending on the audience. It really depends on your audience. If you're talking about data, there's suddenly a different set of audience.

If you're talking about marketing products, there's a different audience. You need to know your audience. I think if you look at your audience and what they are reading, you should be reading those same things. And that's where you should be aiming to get to.

Rimas: I think this is especially critical for product managers that may not have the support of a full-on marketing team, or that have a PR team that they're working with, or even a PR agency.

Because I know that with startups that I've been at, I've had to do all that work myself and make sure I understand who that audience is, where to go to it. And sometimes there's very industry-specific places that you need to do these things.

For example, I worked in a startup that was in the automotive industry. And developer related outlets were not going to be the place to get traction for the product. We had to go to the very specific automotive news, those types of places, to actually reach the core audience. Just tagging on to that, it's important to know your audience.

- We hit on this a little bit earlier, that data's a key thing to measure, right? And the success of a launch isn't being in 10 media outlets. It's not having all this coverage. It's that you find users at the end of the day. So you should be tracking this, your launch process and where you land, but also how that converts for you, just like you do product engagement stats.

You may be tracking that in the exact same way, so you can say this worked, or we need to do it again, or this didn't and we need to try other things.

The key to the launch isn't just for media coverage. It's really about driving adoption of your product.

Rimas: For sure. One of the topics that I tend to see neglected when it comes to any developer related products, when it comes to launches, is documentation. I don't know if we've touched on that just yet, but I wrote a blog post about this myself, and I think documentation is one of these places, especially for developer products, where a developer may be working at the command line or whatever else, documentation is actually a great place to showcase your brand. What I see more often than not is that documentation actually isn't there when it comes to product launches. What's your perspective on documentation?

Craig: I was really fortunate that, at Heroku, it was really ingrained, and we expected that to be a key part of it. A lot of places do side step that, because marketing doesn't think about docs, just because they're not the active users.

I think, as the PM, the buck stops with you, especially there.

You run through it in the eyes of a user that, as a developer tool company, you should definitely have docs that get the developer experience down.

You should be running through that on a weekly basis leading up to it and make sure everything is solid.

Rimas: Let's shift gears a little bit here. We've talked, kind of bounced all over the place in terms of this launch, but when it comes to actually tracking this for the broader team, whether it be your engineering team or just the broader organization, do you have any tips or tools that you use to track this whole launch process from start to finish?

Craig: Yes, that's an interesting one, and I think it really depends. For myself, if it's a smaller team, I'll drop it into a Google doc and basically kind of manage things from just a timeline perspective.

As the PM, to me it's my product, it's my launch, so it falls on me to make sure all the right pieces are coordinated in the right teams. And that doesn't mean them pulling into my tool, it means me kind of reaching out to them.

Similarly, on that note, it's that I follow up in a similar fashion that, after the launch, they may not be in my tools, they may not be in my dashboard. So it's up to me to compute those summaries, to give the report of how this went.

You'll find, actually, PR companies are really good at giving this report of, "These are the meaty hits we had, these were the outlets, these are the memorable quotes." They do a great version of this, but from a very PR-centric standpoint. It's up to you to do that from the product standpoint. Here's the numbers, here's how we move the needle or here's how we didn't.

How about yourself? What are your favorite tools? Is it a Trello board? Is there one tool that works perfectly for coordinating all this?

Rimas: There's never one tool that works great for any of this stuff. And I think you have to be somewhat flexible when it comes to this, because I think what I'm going to get at here, is that you have to over-communicate with every group that you are working with.

Even if you sit with engineering day in and day out, and you are working with them hand-in-hand, it's still very important to, at least every single day, tell them status, where you are with this launch process. Because they are very much a part of this, as you are. That applies to engineering, that applies to marketing, that applies to, well, sales when it comes to their time to tell them that "You're doing this launch."

The important thing here is that over-communicating will make sure that everyone's on the same page, and

when someone tells you to stop telling them updates about the launch, then you know you're doing your job.

Like you said, for smaller things, it's really just a Google doc, or maybe even just a checklist. Wunderlist, that's a favorite one that I've had in the past. But for bigger things, where I need other departments, usually I'll go to Trello, and then there'll be sub checkbox or checklists in there.

And then sometimes, beyond that, there'll be full-out project plans. I've seen that at the very large organizations where you've got to coordinate between maybe 10 to 20 different departments, and there are maybe 100-plus people touching this thing. So those cases especially, being very much ahead of it is very important.

Craig: I completely agree there, and I think that was one of the mistakes I made once was I inherited a new team and said "Oh, we've got a tier-two launch." And I assumed I knew what that meant, and things are rolling along.

We were doing things in the week and a half up to it, I was doing media briefings, etc. And then at the end of it, they were shocked. They were like, "I didn't realize this was this big. I feel like we missed this, we missed this, we missed this from a product perspective."

The week before, I said, "Do you feel good? Are things in place? Are you okay with this?" And at the end they felt like it would have been a very different experience if they had known that leading up, which surprised me, because I had said, "We're having this tier launch. I'll be busy at this point leading up to it."

But that terminology didn't translate. So it was a team I hadn't worked with before, so that issue of over-communicating just wasn't in my head, because I learned to work with a different team in a different style. So you need to make sure that you absolutely over communicate, and when they say, "Yeah, I know, quit telling me. Let me get back to doing my job," you're at the right spot.

Rimas: Definitely. I think you touched upon something in there that I want to highlight again.

These launches are not only meant for bringing in new business or getting in new revenue or building out new product lines. This is about the teams that you're working with and giving them something to be excited about.

That is what you guys are, you are a team. You are doing something together and bringing it to market, and that is very important. So this is very much about bringing it in team cohesion and making sure everyone's on board with this and excited about what you're doing. Because otherwise, if you're not excited about it, then I don't know, go do something else that's not exciting.

Craig: Completely agreed. I think it's a great point to end on. You'll look at what the point of all these launches is, and it's really to highlight all the hard work. Some of my favorite ones, the engineers are spending all day reading TechCrunch, which otherwise they don't want to open up at all, or every comment on Hacker News, that kind of thing.

When you get the entire engineering group, and the entire company, following every little thing that's said, whether it's Twitter, Hacker News, Reddit, reporters, that's when you know you've done the right thing. Hopefully, customers come with that as well, but it's also that internal support and excitement that you get that really makes a successful launch.

Rimas: Definitely. And don't forget it's okay to pump yourselves up as a company. You guys have built this thing and launched it, so it's okay to do so.

Craig: Thanks for listening to us chat today a little bit about, really a little all over the place, on launches from macro coordination to war rooms, which I think we agreed upon, are essential.

Next time we'll have a guest from Docker joining us to talk a little bit about developers and the enterprise. Two things that don't always go perfectly together; how do you go after those two things together?

Rimas: It will be an interesting topic. I can't wait.