09: Just Ship It
Speaker 1: All right. Today we're going to talk about your favorite three words. Just- ship- it. Which is something that we believe here at Drift, something that you brought to HubSpot team. For people who aren't familiar with your mantra of Just Ship It, what does that mean?
Speaker 2: Actually, it used to be Just Fucking Ship It.
Speaker 1: Just fucking ship it?
Speaker 2: Yeah.
Speaker 1: Okay. Then you went to a public company. You had to take out the-
Speaker 2: Take it down to Just Ship It. The idea behind it was that, back to something that we've talked about in the past, we should default to being wrong. We should be alert, should try to make ourselves learning machines and learning organizations. The best way to do that is by getting out there in front of our customers and shipping as quickly as possible so that we can start that feedback loop and that we can get better.
Speaker 1: Part of this was the shift from the old way of software development, which is spend weeks and weeks building something, ship it. It's either good or not, and it just wasn't iterating fast enough.
Speaker 2: Totally. Yes. Especially when you're in a smaller company, every day and every hour that passes by is precious. You're burning money and you're burning time, so you want to get as many swings at the ball. Is that crosstalk-
Speaker 1: Yeah. Yeah. Yeah. That's right. Yeah. Yeah.
Speaker 2: Many at- bats as possible.
Speaker 1: Yeah. You want as many at- bats as you can get. Yeah.
Speaker 2: Yeah. The best way to do that is ship as fast as possible, get feedback from your prospective customer, and then incorporate that feedback. Ship again. Ship again. Ship again.
Speaker 1: It really ties back to just continuous learning. The point of continuous shipping is continuous learning.
Speaker 2: Absolutely.
Speaker 1: Not just building ship for the sake of building ship.
Speaker 2: Exactly. There's no honor in just shipping stuff or just shipping shit, as we used to say. It's like, you don't want to ship shit, you want to ship quality stuff. You got to figure out how to learn the difference between the two, but you want to get good learning as quickly as possible.
Speaker 1: It's like, even though the software development method has changed, there's a new... People still want to do that? Because it's human nature to want the delayed gratification. You want to be," I'm building something, I'm going to show you when it's done." That's fun. We do that. You buy a present for somebody and you're,"No, you can't have it now, you got to wait." It's the same thing. It's human nature to want to have this big reveal.
Speaker 2: Exactly. The big reveal is what we need to talk about today. I see it applied to all walks of life. It's not just about shipping code. It's as much to do with writing copy as it does about designing something. Everyone tends to want to deliver this big surprise present.
Speaker 1: Yeah. I do marketing at Drift. If I said to you... If I needed to work with you closely on something and I said," All right, we're going to kick off this project on Monday." You send me a message on Tuesday and you're like," How's things going?" I say," Good, I'm going to send you a draft of something on Saturday or Monday a week from now." You would say what?
Speaker 2: No fucking way.
Speaker 1: No way.
Speaker 2: Yeah. I'd say no. You got to show your work now.
Speaker 1: But that's just a change in mentality. I don't need to show you the finished product. You get people in for feedback during the whole process.
Speaker 2: Yeah. I totally believe in this, showing your work and creating this... Trying to create this environment of transparency. What you want to do is show the process, show your thinking process to everyone on the team, be transparent about what you're working on. Even if day two was that you just did a rough sketch and you wrote two sentences, day three you wrote a paragraph, day four you wrote two paragraphs; that doesn't matter. What matters is not how much you're outputting each day, and not try to micromanage someone. It's that you're showing your thought process and you're sharing how you're building something.
Speaker 1: There's a couple of things. Number one is if you need to give feedback or completely change something, you're not just going to crush that person. They're not going to have to recreate the wheel when you get this thing seven days later and you're like," This is completely wrong." Now you've wasted a week. You've spent another week doing it.
Speaker 2: Totally and that's a really hard thing with the big- reveal approach that most people tend to. It's really hard to give them feedback because they've invested so much time in it. They're like a little kid who comes to you with a big present and they want you to be happy, and then you're," Oh, it's the wrong direction."
Speaker 1: Yeah. It's harder to give feedback for sure, but it also, like you said, builds trust. You're not hidden somewhere building something.
Speaker 2: Nope. You're not off in a corner and you don't have the rest of your team and the rest of your company wondering, what is Dave doing? Dave's been hard at work. I'm sure it's something good because we worked with Dave long enough. We know something good is going to come out of this, but we're all wondering what exactly is going on. I'd say for people who haven't built up the level of trust, and we're in a small company, so it's easy here; it becomes really important to show your work. Imagine you're a new person on the team, or imagine you're a contractor. Imagine you're someone who is working with a new team within your company. It's really important to show the progression, show how you're thinking and show the work as you're doing it.
Speaker 1: It's also just like a... It's almost like managing up. You're creating something, but you're managing the expectations of everybody else around you. Like, I showed you this throughout a hundred times of the process, so now if we get to the end and you want to completely change what I did, you don't get to do that.
Speaker 2: Nope. Exactly. Then I think another issue that comes up is that usually any kind of project that you're working on, you have external dependencies and you may have other people in the company who are working on things that are related to what you're doing. If you wait too long for the big reveal, it will usually negatively impact a lot of other people who are working on things that are related. We see that in development world why, for engineers, we always want them checking in their code as soon as possible. They don't want to go too long on without checking in code, because they're going to create conflicts with other developers who are working on similar things.
Speaker 1: Right. Or even on the marketing side or the design side, somebody might be doing something similar that you could either double down and make it even more amazing-
Speaker 2: Totally.
Speaker 1: Or find a familiar pattern from them and bring it in.
Speaker 2: Exactly.
Speaker 1: All right. The thing that we want to dispel today is, even if you're a marketing design, whatever sales, Just Ship It is not just for engineering. This is a mantra for business?
Speaker 2: Avoid the big reveal. You don't want to be off in a corner working on something for too long. If you can at all, really try to show your work each day. Get in the habit of each day, sharing with your team and maybe sometimes they don't care what you're working on. It doesn't matter, but they know that they'll always know what Dave's working on or Tom's working on because they're always showing their work.
Speaker 1: Yeah. And just tactically for people listening, the way that we do this at Drift is, we kick off every week, so our team is 15- ish people. We kick off every week 11: 00 AM, first thing, Monday morning after everybody's figured out what they want to do for the week, is we get the whole team up, get them in a circle and everybody just goes rapid fire. They say, what's the one thing I'm working on this week. Then we bookend the week with, before everybody goes home on Friday, everybody sits around and we do show and tell. We say," Hey, what did we get done that week?" But in between that, there's all the one- to- one conversations happening.
Speaker 2: Totally and that's where you should be showing your work. You should be showing what's happening there. That way you can build a better product, write a better blog post, design a better thing, because you're getting feedback from your team.
Speaker 1: Yeah. Cool. So avoid the big reveal.
Speaker 2: That's it. Just ship it. Or-
Speaker 1: Just Fucking Ship It. There you go. Cool.