On today’s episode of Build, Maggie sits down with Drift’s VP of Product, Craig Daniel, to discuss how to ship product – what it takes to hit your dates (and the importance of committing to them publicly), using tracer bullets to de-risk features, “good / better / best” tiering to scope features and the importance of naming conventions.
Also in this episode, how Product Managers can progress in their careers and how to get features built by your team if you’re not on product. Hint: Talk to customers!
You can get Build on Apple Podcasts, SoundCloud, Spotify, Stitcher or wherever you get your podcasts. Or listen to the full audio version below ?
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Maggie and Craig on Twitter @maggiecrowley @craigdaniel.
Subscribe & Tune In
In This Episode
0:19 – Introduction of this episode’s topic: shipping products
0:35 – Craig Daniel shares his background in the industry
2:45 – How to ship product, Craig shares the formula
3:24 – The constraints that matter: commit to a date, name the product you’ll ship, and tell a story
5:50 – Craig explains what a “tracer-bullet” in production is
7:12 – What is the “Good, Better, Best” framework
9:16 – Naming a product and telling a story is really important, Craig shares why
11:11 – Shipping on a promised date and the realistic logistics and challenges of it
12:29 – Drift built in collecting social proof as part of their marketing system and Maggie shares why she believes Drift made this rule
13:44 – Drift now has a cultural norm of believing in and sticking to a hard deadline
14:59 – A hard and fast deadline and dedication to meeting that deadline shows transparency and builds credibility amongst the team
15:44 – Advice to product managers on how they can implement this model on their team
18:15 – Craig gives three amazing pieces of advice for new product managers
19:46 – Craig shares two ways on how to get your feature built
Full Transcript
Maggie Crowley: So we’re back. Welcome to Build. Today is special for two reasons. First, I have Craig Daniel, RBP of product and my boss, here on Seeking Wisdom. And second, we’re gonna get into something that is probably the first thing I actually learned when I joined Drift, which is how to ship products on time. So Craig, welcome to the podcast.
Craig Daniel: Okay. Thanks.
Maggie: So I wanna get into the steps it takes to ship. I know you’ve done this presentation before. But first I wanted to dig into your background a little bit and hear how you got to the point where you had a thesis on this topic.
Craig: Yeah. So I’ve been working on software since the late nineties, and at first I was an engineer and we were using the waterfall methodology that was state of the art back in the nineties. And I always questioned, like there has to be a better way, ’cause we were always missing our dates and customers were never happy, and it was just super duper painful. And we were optimizing for like hitting everything in the Gannt chart rather than hitting actual … what mattered.
And so I was an avid reader, always have been, and found some books on Scrum, found the Agile Manifesto, and I ended up actually … you make fun of me for this, but I was an early adopter … I was Scrum master certified in the early 2000s-
Maggie: Cutting edge at the time.
Craig: Yes. I was crazy at my company when I got certified. But really it was just about learning there has to be a better way, and from there it went through a … I don’t know, another 20 books: extreme programming, Scrumban, Kanban. You name it I’ve probably tried it with a team or two. I think I’ve always believed in small autonomous teams. I’ve always believed in iterative processes and really evolved to that, and when I joined Drift I learned from David and Elias how they worked at Drift, which married very well with some of the things that I learned in the past. So I wouldn’t say I figured it out, I would say Dave and Elias had their style, I had my style, it was very, very complimentary, and I think we’ve just made it better every single month.
Maggie: Yeah. And I remember when I joined and you told me that we were going to ship a new product every single month for the entire year, I didn’t understand how that was possible.
Craig: Yeah. It’s nuts but it’s fun. I think in the early days we … both of our founders are product people, and we’re launching a new product in a new category and the best way to demonstrate what it actually is is by shipping new stuff. And so that’s what we did, and we committed to the first Tuesday of every single month, we’re going to ship something new, that was a forcing function to actually figure out how do you actually do that.
Maggie: Right. So, how do you actually do it?
Craig: That’s a good … other than I have a lot of gray hairs from doing that month after month here at Drift, but no it’s actually … gets easier. Would you agree it’s gotten easier?
Maggie: Yeah. Yeah, I think you get used to the rhythm of it, but I still … even when I … we were talking about this before, even when I think back on the different steps I still have trouble wrapping my head around exactly how we do it.
Craig: Yeah. So follow a formula that we train all new Drifters on when they come on board. Really it al comes back to constraints, right, so no matter what framework you have in product management there’s always do we have a date constraint, do we have a feature constraint, do we have a people constraint? And I think the two constraints that actually matter, especially when you’re launching a new product in a new category, or you’re trying to build momentum, or if you’re a new executive at a new job … Let’s say you went to a new company and it was like, ah Maggie’s gonna get our product team humming again. This is a really good way to do it. In the first three months I’m going to ship three products. Right? I’d be like, holy crap that’s amazing.
But basically it’s commit to a date. Just find a date. Don’t randomly pick a date. What we do is first Tuesday of every month. We don’t have to think about that that’s just part of the system. Then name the thing that you’re going to ship on that date, just name it. That’s your first constraint is like what is it? Don’t use names like V2, next gen, or any of those crutch names. Name something real, right, so find the essence of what you’re trying to do, and then tell a simple story about it. This is a short hand form of what Amazon does with the press release, but tell a story, and stories all follow the story arc right which is … I always think current state of affairs, what’s happening now, what’s the conflict, what’s the promise or claim, and then how do you resolve it. So tell the story in that format. We can walk through some of that. And then just ship it on the date you promised obviously.
Notice in there there’s no feature, there’s no widget, there’s no user story, there’s no … whatever, because that’s what really matters when you’re trying to build momentum with customers or even with internal stakeholders if you’re trying to build momentum as well.
Maggie: When you’re picking a date … I understand obviously having lived through the first Tuesday of every month, but I think that the way I thought before is at Drift was … okay, we’re gonna ship this feature, we’re gonna provide this value for customers, but you don’t know how hard it is to build that thing. Like you haven’t done an estimate with your engineering team or your design team, so you don’t know how hard it is. I think that was the thing I had the most trouble with was, coming in … okay, it’s gonna ship on this Tuesday but we don’t know how hard it is gonna build so how can we possibly commit to that?
Craig: So a lot of people who listen to this podcast are probably familiar with the Spotify graphic that’s skateboard, scooter, bike, car, that type of thing, and so we’ve kind of leveraged that same framework. If we were using this format we’d say we’re gonna ship, on this date, transportation that gets you from point A to point B in under five minutes because today it takes 10 minutes, it’s really painful, and that’s what we’re gonna ship on this date. I didn’t say I was gonna ship the skateboard, the car, or the bike. I’m not sure yet because I don’t know what we’re able to do.
So the first thing that we do is what’s your version of that skateboard? What’s the first thing, and we call it here the tracer bullet, which is a little bit of an Agile term, but literally as fast as possible get engineers to hack or do whatever it is to make the thing work end to end. No re-architecture, no nothing. So an example of that would be we book meetings. So we said we’re gonna ship it Office 365 bought book meetings feature. The very first thing we’re gonna do is we’re going to buy a Office 365 license, and we’re gonna have a developer hack up the Google code in whatever way they can to make that connection work and see a meeting show up on their Office 365 Calendar.
Maggie: So no front end, no UI, just-
Craig: Nope.
Maggie: -Meeting shows up on calendar end to end?
Craig: And they can sit there with the team and in their console or scripts or whatever, and be like, check this out I’m gonna run these five things and comment this line, calendar event shows up. That immediately shows you, as a product manager, okay, I’m pretty confident that in six weeks or eight weeks we can ship Office 365 Calendar, because I see we have it today. It’s just about putting all the front end and the workflows and everything on it. So we call that the tracer bullet, and get that done as fast as possible.
Maggie: Okay. So you do tracer bullet then we also, obviously … we call it good, better, best for the different pieces. So how, when you think about a team approaching a problem, how does that fit in?
Craig: Yeah. So the reason we introduced good, better, best was as a framework as we brought on new product managers, because I think experienced product managers know how to break down problems, like big, giant initiatives into smaller things, and senior designers as well. But, as you scale a team, not everybody has that skill yet. So good, better, best was a way of forcing function to actually have people give three different versions of the same thing. So this is your skateboard, car, and bike, or bike and car.
We actually have our designers literally, as you know, design three different versions. Product managers write three different one pagers, which are our versions of the specs, for the good, better, best, because almost never do you wanna ship the best. That’s like the-
Maggie: I often find that we start with the best. Like when you approach a problem you have this big idea of what you’re going to do and you have this amazing design that has all these bell and whistles, and then you look at it and you think about the date, and then you have to say, okay well this is obviously not possible and half these features are … wouldn’t it be cool if …
Craig: Yes.
Maggie: So then good, better, best is at least a framework for me to say, okay we might get there but let’s scale it back and pick the essential pieces.
Craig: Right. I mean good still has to be something that backs up the story. It can’t compromise on the story, so it doesn’t need to have all the bells and whistles. So in this case, to take the example we just had, Drift has bots that qualify leads and book meetings for them. It simply needs to grab an email address, pick a calendar availability, and marry that email address to that calendar and that’s it. So reduce, reduce, reduce down to that essence, then when you ship it, validate, see if anyone cares, if anyone uses it, how many people connect it.
Maggie: Right. So tell me a little bit more about giving it a name and telling a story. I think those are two things that I … in addition to picking a date, were new to me in the role that they could play in getting a team to move quickly.
Craig: Yeah. The naming is real important. I learned this at my prior company, Log Me In, because I was on a relatively small business in the larger company. There were lots of initiatives from four different business units, and the executives could never really keep track of everything, and if you wanted to push your agenda you had to give it a name. And I watch politics and stuff like that. If you look at any bills or anything, like the ACA, they don’t call it that. They call it Obamacare. They give it names. And you look at how you move your agenda. These politicians they always give something a name other than the actual bill name.
So that’s why I think naming is really important is because it travels, it’s a handle that everyone can grab onto. Sales people can say, oh when’s the Office 365 Meetings coming. Instead we could have called that Meetings V two, which is … now we’re adding OfFice 365, but instead just tell you what it is in a short amount as possible that everyone can grab onto and it travels. And then when you have that you can use the gravity of the organization to pull towards that.
Maggie: Right. And I think that’s also something we started to do even inside of our individual product teams. We started to give our metrics a tag line because it helps to have an organization understand what you’re building and have a catchy name for it. I think the teams do really well when they have no customer left behind, or no chat left behind, or whatever those tag lines are, it’s much easier to focus on what you’re doing because you all have that shared thing.
Craig: This entire framework’s about simplification and reduction, and I think naming is part of that. Name is the simplest form of that story that you can tell.
Maggie: Right. So then the last part is ship it on the date you promised. What happens when there’s inevitably … you uncover something that’d harder than you thought, you run into some issue, there’s other things you’re trying to maintain. How do you keep the teams always hitting those dates?
Craig: That’s a little bit more art than science some times. Let’s talk about the hard part of shipping on the date, which I think is the go to market part of it, and then we’ll come back to the engineering. The reason we picked the first Tuesday of every month is because … another simplification. No one had to communicate when they had to start preparing. One of the challenges that any company … let’s say you’re at a normal company, bigger company, that does two or three releases a year, which is pretty typical, it’s like, hey when’s that release coming out? When are we gonna start planning it? Oh, should we start doing weekly? Should we do monthly? Right? And it’s not a system. It’s like a project every time.
What we see here is literally it’ll be Wednesday, the day after we shipped, and the product marketing manager is like, hey Maggie I’d like to sit down and talk about what’s coming up next month. It’s just a system. It’s just a heartbeat. And what that does is it also creates a little bit of a tidal wave amongst all the employees, ’cause they know it’s coming, it’s just like any other cadence they have. So I think that is the really hard part, to get momentum, because you know as a product manager I’m sure you’ve shipped products that no one uses ’cause marketing never told anybody about it. And this avoids that.
On the engineering side I think that comes down to just good engineering management, whatever technique you use, which is feature freezes, or betas. Here what we try to do, and this wasn’t always true early on, but I think now, is we usually aim for at least five beta customers well before the launch, and we’ve built that into our system because the product marketing managers are gonna want quotes and stories from them.
Maggie: Right, the social proof.
Craig: The social proof. And so-
Maggie: I think I might actually be the reason why we had to make that rule.
Craig: Yeah? Why’s that? You wanna tell the story?
Maggie: Because I was on a marketable moment with no beta customers.
Craig: With no beta customers. That was not a super fun one. What did we learn in that?
Maggie:
Maggie: This is why having your boss on a podcast is tough.
Craig: (laughing)
Maggie: I think the biggest thing I learned on that was that we had a lot of assumptions about how something would be used, and when it would be used, and what it would be important for, but we learned very quickly that it was to hard for customers to even find where we had put the link to the feature. And then we learned that the value wasn’t exactly what we thought it was, and so our messaging wasn’t super correct, where we put it wasn’t super correct. We could have made it a lot better if we’d even had one person give us feedback.
Craig: Yeah. So we always had an unwritten rule of these beta users, but it became a written rule thanks to Maggie here. I think it’s a good practice nonetheless. We learned from it and we iterated. That’s one of the great things about doing this 12 times a year is we learn really quickly and we build up the system and make it kind of bulletproof.
So right now what most of the things you’ll see us ship, actually all of things, have been in the wild for at least four to six weeks, so that removes a lot of the risk of something breaking last minute or something like that. Now was that always true? No. There were early days at Drift where it was like the Friday before, and it’s like, oh my God the thing doesn’t work, and we’re scrambling over the weekend.
Maggie: But I think it also built up a cultural norm on the team that we don’t miss those dates, right, and I think that part of the commit to a date and hit the date is that everyone has to believe in the date. It’s not just a random date. Because I think I’ve been on other teams, other companies, where we say something like, oh we’re gonna be done with this on this day. And the date comes and you’re not super done or you’re close but there’s no pressure to get the thing out the door, but having those really hard deadlines that are public, not only public to the company but public to the market, mean that you don’t have an excuse.
Craig: Right. And Elias, who’s the CTO and co-founder here, this is something he really believes in right, just pick a date. Pick a date. Pick a date. And he will sometimes corner developers until they pick a date, and then it’s amazing that when you set that one constraint how just it simplifies everything, ’cause you’re like, oh, okay I only have two weeks so I can’t do everything, so I’m just gonna do this one thing.
And so when you get into larger companies, and you were in a larger company in the past and so was I, what the product team does is often like magical to the rest of the organization. They don’t … like how did they do that? I don’t even know how they did that. And when things are going well that’s fine, just magic starts to happen. When things aren’t going well, it becomes this sense of … why are they working on that? If they just fix this thing …
And so this is another part of the reason for this system, is it shows transparency. This is what we’re working on and we’re gonna hit the date that we’re working on it and we’re gonna move onto the next thing, and it builds some credibility and trust amongst the rest of the team.
Maggie: Yeah, that’s true. So then if you had to give advice to a PM who’s listening, how can they start to do this on their teams? What’s the first thing that someone should bring back to their team that they can help them move to this model?
Craig: I think whatever you’re working on, start with the good, better, best I think. Start with a date ideally, but start thinking about what is the reason we’re releasing this thing. I was just talking to a founder who was telling me, oh, we had this concept we drew up on the white board in January and it’s still not live. This is like a five person company, small company, and they were asking for my advice. I said, why? And … oh, it’s complex and it involved machine learning and all this complex … and that’s normal. That’s what’s going to happen. So what I would recommend to that person, if they could go back in time, is just say, listen, nothing’s gonna be more than a quarter. There’s just absolutely no way as a small company we can go more than a quarter, or even as a small team.
So I’d say the maximum date you can set is three months out. So set that date, and then work backwards and say, okay, what do we think we can get in that three months? And you’ll probably get like the better slash best version. It’ll be lot of feature bloat and a lot of gold plating, and then reduce from there, then apply the good, better, best. And what you’ll probably realize is that in four to six weeks you can release something pretty good. And then I would then focus on that. If it happens to take you four to six weeks to release it and then another four to six weeks of beta testing and making sure it works, then you still hit your three months but it’s a pretty good tight experience. That’s what I would do.
Maggie: Right. And I find that you often never need all of the things you thought you would need in the best version. Like I don’t think I’ve ever gone all the way through a whole list of things that we thought would be good to have in a feature when using this model because you realize customers don’t care.
Craig: Yeah. And when they do care they pull the rest out of you, and then the prioritization becomes really easy. Like you could come to me and say, I know we had this team on this feature but I really think they need to go here because our growth in our user base … there’s one capability we released recently that is 45 percent month over month growth of usage. It’s insane. And so obviously Maggie was like, I think we need like a team on this, just to breath life into it and make it full to it’s better and best version, and that was a really easy decision because the customers were pulling it out of us.
On other things … there’s some things like the one you had, that didn’t work as well and it makes an easy decision. And it’s like, thank God we didn’t spend more than that time on it.
Maggie: Yeah. That’s true. Okay. So then I have another question about advice for people who are listening. First, take a step back from it from just being able to ship on a certain date and hit those deadlines. You’ve trained many, many Pms in your career. What’s the biggest piece of advice that you give to new Pms that you work with?
Craig: Yeah. Mostly it’s very liberal arts related stuff, not the technical part. So read more than anyone you know. Then I have some tips on what to read but just read. Read about business. Read about the industry you’re in. Just do whatever you can to just learn as much as you can. Communicate with everyone. Just spend a lot of time understanding your peers, your co-workers, the key stakeholders, and then even if you’re company is not customer centric, which a lot of companies aren’t quite frankly, talk to more customers than anyone in the company.
It’s like read so you learn from people who made mistakes before you. Make relationships with all your peers because you’re gonna need them some day to help you, either getting a new product op to market, or maybe on a sales deal they might need you to help out. And then talk to your customers. I mean there’s nothing that stops a conversation faster than when … Let’s say a senior executive is saying, we gotta work on X, and you’re like, that’s interesting ’cause I just talked to so and so, and so and so from our two biggest customers and they don’t want that, they want Y. It’s like, oh geez. You win the battle every single time right. So talk to customers.
Maggie: So similar to that but on the flip side, if you are not in products, but you are in sales or marketing or ops or something else, you have that feature, you’ve been talking to customers or you have an insight. What’s your advice to them on how to get their features built? How do you approach a product team?
Craig: This is something … I actually gave a presentation to the whole Log Me In product and engineering team about how to get your idea shipped.
Maggie: Oh, I didn’t know that.
Craig: It was the first thing to do. And this is like an engineer who’s like, I have an idea, and we have 500 engineers. I’m like, how do I get anyone to care about this to ship it? The first thing is is understand the strategy. If you as an engineer, or a designer, or an individual contributor, understand the overall business strategy, how that translates into product strategy, and let’s say I’m on a team that rolls up to you, and I know the three things that Maggie cares about, like I know Maggie has to drive this metric, then I’m gonna align my idea to her metric. And … I talked about tracer bullets, show that it can happen, I mean, if you’re an engineer.
The version of that for sales and marketing, which happens all the time here, is give me customer evidence. And I think the best type of customer evidence is getting the product person on the phone with the customer, or on a Zoom call, or-
Maggie: And no product person would usually say no to that.
Craig: Yeah, because every product person has an insecurity of am I talking to enough customers. So whenever it’s like, hey can you jump on the phone with a customer? Like, yes, I feel better about my day if I do that. So it just happened yesterday. We were talking. We have a pretty big customer who’s been super successful on Drift, had a couple nags in the product and there was all these slack messages running around about it, and they’re hitting up you and me and a few other people. And then yesterday I got on a 20 minute call with them finally after a week, and I was like, oh yeah, we can fix these things. And it’s like, ding bing, let’s get it done. I was more empathetic, I felt the pain, and I was able to do it.
Maggie: Okay. So understand the strategy, bring customer evidence …
Craig: Yep.
Maggie: Is that it?
Craig: Or-
Maggie: I’m not even really sure-[crosstalk 00:21:34]
Craig: -Build a tracer bullet if you can. Ship some version of it, even if it’s power point. Business Development … our head of BD, Jared, does that a lot where he’ll throw in a power point and be like, check out how this integration works.
Maggie: I actually got one from I think Brendan and Castillo in sales-
Craig: Oh, really?
Maggie: They did one. Mm-hmm (affirmative). They did one a couple months ago. Yeah.
Craig: Awesome.
Maggie: Okay cool. So how to ship: you have to commit to a date, give everything a name, tell a simple story, and actually hit the date that you set. And then if you want to get your feature built you need to understand strategy and specifically the product strategy, what metrics we care about, and bring evidence from customers.
Craig: Yep. Ideally-
Maggie: Ideally.
Craig: -In a customer call. Get face to face.
Maggie: Awesome.
Craig: That’s the best way to move the agenda.
Maggie: Great. Well thank you. I appreciate you coming on the show.
Craig:
Craig: Ah, thanks.
Maggie: So thanks.
Craig: Awesome, thank you.
