Episode Thumbnail
Episode 25  |  16:47 min

24: Why You Should Run Your Business Without Roadmaps

Episode 25  |  16:47 min  |  08.02.2016

24: Why You Should Run Your Business Without Roadmaps

00:00
00:00
This is a podcast episode titled, 24: Why You Should Run Your Business Without Roadmaps. The summary for this episode is: If you liked this episode, we bet that you’ll love our blog content. blog.drift.com/#subscribe Subscribe to never miss a post & join the 20,000+ other pros committed to getting better every day. --- No roadmaps. No public launch dates. That’s how our product team works at Drift. It’s how David did things at HubSpot, and Performable, and all the way back. But the "product roadmap” is one of the most essential parts of any product organizations. How many times have you heard “well let’s get it on the roadmap” or “its on the roadmap for Q3.” So this week on Seeking Wisdom, we’re talking about how you can run your business without product roadmaps and public launch dates. Hint: it all comes back to being customer driven. Catch all of the previous episodes of Seeking Wisdom on Medium now! seekingwisdom.io Make sure you subscribe to Seeking Wisdom on your favorite podcast app so you never miss a new episode :) Follow David (twitter.com/dcancel) and Dave (twitter.com/davegerhardt) on Twitter.
If you liked this episode, we bet that you’ll love our blog content. blog.drift.com/#subscribe Subscribe to never miss a post & join the 20,000+ other pros committed to getting better every day. --- No roadmaps. No public launch dates. That’s how our product team works at Drift. It’s how David did things at HubSpot, and Performable, and all the way back. But the "product roadmap” is one of the most essential parts of any product organizations. How many times have you heard “well let’s get it on the roadmap” or “its on the roadmap for Q3.” So this week on Seeking Wisdom, we’re talking about how you can run your business without product roadmaps and public launch dates. Hint: it all comes back to being customer driven. Catch all of the previous episodes of Seeking Wisdom on Medium now! seekingwisdom.io Make sure you subscribe to Seeking Wisdom on your favorite podcast app so you never miss a new episode :) Follow David (twitter.com/dcancel) and Dave (twitter.com/davegerhardt) on Twitter.

Speaker 1: On this episode of Seeking Wisdom, we're going to talk about one of your favorite topics.

Speaker 2: What's that?

Speaker 1: Roadmaps.

Speaker 2: Oh, no.

Speaker 1: This was something we were kicking around for an idea. And a question that comes up all the time is people ask you about product teams, talk about it here at Drift.

Speaker 2: Mm- hmm( affirmative).

Speaker 1: Something that you talked about a lot at HubSpot too, is that there's no public roadmap.

Speaker 2: Yup.

Speaker 1: And a roadmap is something that is so historical, it's so essential to the life of a product team and an engineering organization. And you actually started with a story talking about how, last week you met with a bunch of Execs from another company. So, maybe let's use that story to kick off this episode.

Speaker 2: Sure. I met with Exec, CEO, and a couple of Execs from another company here in Cambridge. And we were talking to them, they were asking me questions about how they should organize their product organization, and what have I done, and what has worked, and best practices around it. And we finally got to a part at, towards the end, where we were talking about my belief in not having public roadmaps and working towards release dates, especially public release dates. There are times when you have those things internally, but public, the idea of a public roadmap or public release date shouldn't exist. And of course, the CEO was like," Well, how do you make sure a product team's accountable? If I don't have a public roadmap, right?" How do we sell? crosstalk Sell and train if there's no product public roadmap.

Speaker 1: So, in that example, that means that CEO, they announced to customers like," In January 1st, we'll be launching X?"

Speaker 2: Exactly. Whether they do that from a marketing standpoint, or they do it from a customer success or sales standpoint, it's usually customer success and sales, it's usually not something that's Warren's being marketed.

Speaker 1: Right? Is that like," Here's the date that this feature you asked crosstalk."?

Speaker 2: Exactly. But from a sales exception standpoint, let's say a company selling through salespeople and like, or even if they're selling through online freemium approach and people are writing in and saying," Hey, when is this feature going to be ready?" Most companies default to have that public release date and say," Hey, we're working on that. It's going to be in August 15th, around that week. We'll probably going to release something like that." And my thing has always been not to have those things, not to have public release dates, and not to have public roadmaps. And that's how we ran the teams that performable my last company, HubSpot, and now Drift, and we can get into why.

Speaker 1: So, I also think this is probably less than that. It's going to apply beyond product crosstalk too, right?

Speaker 2: Absolutely. Absolutely.

Speaker 1: I think it applies to how we think about marketing. The plan is, on the back of a napkin we have big things that we want to get done this quarter.

Speaker 2: Totally.

Speaker 1: Right? There's no dates though.

Speaker 2: Mm- hmm( affirmative).

Speaker 1: It's just directionally.

Speaker 2: Yes.

Speaker 1: Are we getting in the right directions? And I think a lot of people get so bogged down in the planning part of it.

Speaker 2: In the tactics, for sure. And so, the point of how I arrived at all this stuff and why I think it's important is that you have to back out and ask yourself the fundamental question of what is success? How are we going to measure success? Right? And my point from, at least, a product standpoint has been like," Well, success should be..." And also from a company in sales standpoint, so you're right, it's beyond product has been like,"What success should be? A customer that is happy, delighted, and happy to use your product, service, or whatever it is that you produce", that should be the ultimate measure, right? That's the point then businesses exist, right? It should be to satisfy a customer, so that should be the ultimate measure. And then if that is the ultimate measure, then let's work backwards from a tactical and planning standpoint to say," All right. If customer success and customer happiness is the ultimate goal, how do we measure that for a product team? How do we measure that for our sales team? How do we measure that from other teams?" That's the point. Start from the... Start with the" Why?".

Speaker 1: It's funny is that another thing that you would mention a lot is it goes back to aligning incentives, right?

Speaker 2: Yes.

Speaker 1: If this team, if the team is incentivized, this has happened, I worked at a big company where this was a real thing. This quarter, the whole company's focus is to ship automation works like whatever it is to ship this feature, right?

Speaker 2: Yup.

Speaker 1: Then what happens? Everyone's incentives from marketing to sales to product are all aligned around that thing. And you just become laser focused on that and forget all the other stuff that comes with running the business.

Speaker 2: Totally. And you may have shipped it. Most of the time, you don't even end up shipping on time, but let's imagine you did ship it on time. So, you ended up shipping it, you've ignored customers in the meantime, because...

Speaker 1: Wait, you don't even know if this is going to be adopted.

Speaker 2: And that's the point. And then you ship it and nobody cares. And so, you've rallied the whole company around it. Everyone's spent their time doing it and they don't care. Actually, what usually happens is something a little bit in the middle, in between those two, which is, you ship it, some people kind of care. Most of it is broken. It doesn't really work the way you intended, or you didn't think about a certain use case. And so, you need to now iterate on it, but you've made a big public stamps about this, this thing and where you didn't actually care about the customer in that case, all you cared about was the fact whether you can rally the company ship of fame.

Speaker 1: crosstalk this announcement.

Speaker 2: Exactly.

Speaker 1: And everybody thinks that their Facebook, they think that when they ship a new feature.

Speaker 2: Yeah.

Speaker 1: Hundreds of thousands of people are just overnight going to adopt it, right?

Speaker 2: Yeah. And that's not the case.

Speaker 1: And then it always comes back to like," Well, we didn't market this feature really." And it's like, it all comes back down to, are people going to care about this?

Speaker 2: Totally. And they don't know that they don't operate at a Facebook, or Google, or an Amazon scale. They don't know that Google or Amazon, or Facebook, have actually tested with live customers probably for a long time before they ship something. So, they validated it. They skip all those steps and they just jump immediately towards like," Let's announce it. Let's have a big marketing push and then let's have this work." And I think it's an... There was a time and place for that. Again, back when pre- internet days.

Speaker 1: Right.

Speaker 2: When you're shipping something physical, totally made sense. Or if you're shipping some physical thing that gets shipped to Best Buy, totally makes sense, you need to rally the whole company around that. If you're shipping software or any kind of hardware that can be remotely updated from a software standpoint, then it doesn't make sense anymore.

Speaker 1: Especially today in 2016, like no more agile, no more waterfall. Like it's not six weeks sprint cycles. Things can change overnight. So, why do you operate in a world that, that doesn't exist?

Speaker 2: Exactly. And so the way that when we were, I was talking to this team that I was, because it was a head of marketing, head a product, and the CEO is explaining is like," For all of time that I've been involved with shipping software, I've talked to anyone who ships software and everyone laughs when he'd say this is, I've never seen a release that you announced it from a marketing standpoint and you shipped it. So, we just announced the one and we shipped it to all of our customers that it actually was successful." Right. In successful, meaning that either they met the date, the date is almost never met, right? Because the product wasn't ready on time. So, it slipped. Or two, they announced it and nobody cared about it, or they announced it and people cared about it and it wasn't ready, so you had outages or bugs with the product. And so, my thing was always, let's separate those two things, which is one, a business and marketing and sales event, which is announcing something to a customer and have a big separation between that and actual releasing to customers. In our case, we would often release something to customers months, weeks before, and had customers working and us iterating on the software for weeks, if not months, before we ever crosstalk.

Speaker 1: Yeah. I was going to ask you about that. I think that's the playbook that, before I even knew you guys, I was trying to take from a marketing and product perspective, which is like you guys were so... For example, HubSpot perform or whatever, you would have your partners basically months before you'd release something, you'd give your partners, and if you're listening, this doesn't have to be partners, it could be your list of VIP customers. You give your 10 VIP customers access right away, because they're VIP customers you know they're not, you have more leash with them, right? If it is buggy, they're not going to be pissed off. These are people that already left you...

Speaker 2: And you're totally up front about the state of things.

Speaker 1: Yeah. Hey, I want you guys to test something, is that all right?

Speaker 2: And you can phrase it as them being a design partner to helping you design it. Right?

Speaker 1: Right. They get to be a part of building this.

Speaker 2: Yeah.

Speaker 1: So, you reach out to those people. So, not only do you then get to test and start to validate from a product perspective, but from a marketing perspective, now you've already had people who are using it. You can use the words that they're using to talk about it in your copy, in your landing page, in your website. And you can actually have testimonials on launch day. Whereas the most times you got to launch, wait to see if people are successful, you get to announce this thing and launch and say," Hey, and these people have already been using it and they love it. Happy to provide a reference." Whatever.

Speaker 2: And that's why it worked so well. And that's the part that would resonate with marketers and CEOs. When you... And heads of sales, when you to explain it, don't you want to launch when it's been vetted and you know it works with customers, we fixed all the issues that may have arisen, so we have a better version of it. You go to market with an announcement and have case studies and actual examples of people who been successful with your software. And now, you can really be in a position from a, from a strength standpoint and go to market standpoint to actually sell something, versus we're going to announce it the day that we launch it. We have, immediately, if it works and people want it, big if, then people are going to ask," Who else is using this? Do you have any... How do I use it? Do you have any examples of other people who have been successful of it?" And your answer is going to be like," Not yet. Not yet. Nope." And you're going to try to make a big sales and marketing push with no examples, no case studies, no testimonials.

Speaker 1: And sales and support reps who haven't gotten the reps and sets of crosstalk that stuff.

Speaker 2: Exactly. No training. And" Day of", kind of training. You know, you have support issues. We've all lived through this, supports blowing up, products blowing up the products coming down, customers are pissed, sales is trying to sell it, they have no examples, it's just a total cluster.

Speaker 1: And it's all because you just put one date and you said, this is our launch date.

Speaker 2: Yeah, exactly. Because you forgot the why, which is, the why should be we're making customers successful is the goal of the company, so what is the best thing to make customers successful? It's to vet something, to test something, to actually go to customers with something when you feel like it can make them successful.

Speaker 1: Yeah. All right. So, I'm going to end, let's end this with the actual question that we started with, which is, so knowing all this, how do you, if you're a CEO that's listened to founder or whatever, how do you actually run a business without product roadmaps and dates? What's the actionable thing to take out of this?

Speaker 2: Yep. So you... As a CEO, you should be focused on aligning incentives for all your teams and making sure that the teams, let's say in this case, product and engineering, which I was talking about, are aligned with the customer, both externally and internal customers, your in- home customers being sales, support, success, marketing, and that they're working together and their shared accountability, right? Towards making the customer successful. And everyone is accountable for what they're doing across the team. So, sales is being supported, support, success, and marketing. And who's working with product continuously with customers to make sure that they're making customers successful. That should be the goal. If that's happening and you're measuring from a CEO, you can stand back and say," Are our customers happier? Are they buying more? Are we losing less deals to competition?" Right? If those, all those things are true, and they're up into the right, and my team is happy, productive, and we can retain the team, then roadmaps should never matter.

Speaker 1: Yeah.

Speaker 2: Who cares?

Speaker 1: Or they can be directional.

Speaker 2: Yeah. Who cares? Why do you need a roadmap? If all those things are true, what is the roadmap for?

Speaker 1: Right.

Speaker 2: And it's usually for a sense of control, right? But you're controlling the wrong thing, right? You shouldn't be controlling that, you shouldn't be having this feeling that you need to control the team and make them accountable to this artificial thing. You make them accountable to the thing that actually matters, which is the customer.

Speaker 1: And you're not saying don't have a plan for what you're building.

Speaker 2: Yeah.

Speaker 1: crosstalk People are going to think, no roadmap.

Speaker 2: crosstalk" Oh, no plan, no dates, no nothing, no..." No. Have a plan. Absolutely, you have to have a plan in your plan. The way that you come up with plans is up to you. Right? We can talk about how we do it, but like, or how we have done it, but come up with your own method for doing that. But focus on the most important thing. Why are you doing this? You're doing it to make customers successful, ideally, so that they can grow your business along with their business. And if those two things are aligned, then you're going to grow and be happier.

Speaker 1: Yeah. And the point of having this conversation isn't to say that you shouldn't have dates and roadmaps, it's to say that usually the narrative around why you have dates and roadmaps is wrong.

Speaker 2: Is wrong. Yep. You focused on the wrong thing.

Speaker 1: Yeah.

Speaker 2: So, you're focused on this tactic that actually, at the end of the day, and we all had roadmaps and version numbers in lots of different companies, they didn't solve the problem.

Speaker 1: Right.

Speaker 2: So, you focused on the wrong thing. It's like you focus on, and instead of pulling back from the roadmap and the version numbers, you know what happens? They end up adding shorter roadmaps, shorter timeframes, more gates, more roadmaps, more, and more, and more, and more, instead of saying," It doesn't work in the first place, so why am I keep adding more?"

Speaker 1: Why are we getting narrow?

Speaker 2: Yeah. Instead of, it's not working. And so, why don't I try something else? Instead, they try to constrain it even more, and then they killed the team, killed the company, killed productivity.

Speaker 1: I just remembered this, the call to action for this episode.

Speaker 2: What is it?

Speaker 1: Tell the people about our new website and what we're going to do.

Speaker 2: Our new website, what website?

Speaker 1: Medium.

Speaker 2: Oh yeah. So, we have Seeking Wisdom dot IO, in case you've never been visited before, was hosted on a WordPress blog, right? And what we did last weekend was we moved it over to Medium. And so, now that all of our podcast episodes, you can go there, listen to them from there, stay up to date with us, follow us on Medium. And we're going to be posting all the beyond podcast stuff, all the other things that we're learning ourselves. And then we're going to have other people contribute to it as well. And so, if you go to Seeking Wisdom dot IO, that now goes to our Medium publication and we're going to be publishing on it, not only podcast stuff, but original content. And we're going to get some of our friends, who are friends and colleagues, and even listeners, to start to help and contribute to that community.

Speaker 1: Yeah. So, we're going to publish a bunch of stuff like whether our designer friends, Elise and Amanda, here at Drift, want to write something about what they're learning. All through like, you, if you're listening, if you're a podcast listener and you've been writing stuff on Medium, you can write in... You can write on Seeking Wisdom now.

Speaker 2: Absolutely.

Speaker 1: We want to make it a publication that's filled with everybody that is writing stuff that is interested in the show and the stuff we talk about to write.

Speaker 2: And then we'll promote you here. And what we want to do is take it beyond the stuff that we're learning and involve you, and involve other people, and take this whole movement about learning and being the best versions of ourselves and Ten Exit.

Speaker 1: Yeah.

Speaker 2: And so, jump in and help us Ten Exit. And we're going to build an amazing community.

Speaker 1: Yeah. So, all right. If you're listening right now, if you do one thing, this might be the easiest CTA, put Seeking Wisdom dot IO in your browser. That's going to pull up Medium, once you get there, just hit follow so you can get along with the publication.

Speaker 2: Yep. And then if you ever want to write something, just contact us right on Medium there, and we'll be happy. Yeah, we'll work with you.

Speaker 1: We'll make it happen.

Speaker 2: Let's do it.

Speaker 1: All right. We'll talk to you later.

Speaker 2: All right.

More Episodes

#171: Working Backwards with Amazon's Colin Bryar and Bill Carr

#170: Avoid Consensus (Unless You Want Average Results)

#169: Introducing The American Dream with Elias Torres

#168: Seek Arbitrage Opportunities

#167: The Culture Episode

#166: Why DC Went on a News Fast and How You Can Too