#174: Never Stop Iterating
#174: Never Stop Iterating
Leo Tenenblat (Drift's Chief Product Officer) is back to talk with DC about iteration. Leo shares what iteration is like at Drift and how it compares to other companies he's worked at – from the big ones (like Salesforce where he drove the Einstein platform) to the small ones (like the startup he founded called AppMesh). DC discusses the difficulty of tying together marketing and product releases too tightly. They also touch on the importance of feedback loops and why product teams need to get as close to the customer as possible. Is this really just a veiled 1-on-1 meeting for DC and Leo? You can be the judge.
Leo TenenblatChief Product Officer, Drift
David Cancel: Before we get to the show, did you know you can get more insights, just like the ones you're listening to right here on Seeking Wisdom, delivered right to your inbox. Sign up to get my weekly newsletter. It's called The One Thing at drift. com/ dc. Boom. We're back. It is Seeking Wisdom and I'm here with Leo. Leo is Chief Product Officer at Drift. He is the brains behind the operations and the beauty. I'm not sure what I am in this operation. I wear hats. Well, my head was made for hats. Pretty good. Welcome back, Leo. What are we talking about today?
Leo: I think we're talking about iteration. This is a veiled one- on- one where you want me to iterate and go faster.
David Cancel: Well, look at this. I'm double branded. I didn't even notice. Look at the shirt and look at the homemade hat. Now to see both of these things, you have to subscribe to our YouTube. Check this out on YouTube if you're listening on audio only. We had notes about during this episode, and then Leo asked me who comes up with the episode ideas. I said," Not me." He's like," this seems like a veiled one- on- one because we were talking about iteration. Leo, have we been talking about iteration laterly?
Leo: Just a little. We've been iterating on it.
David Cancel: The context for everyone listening is Leo joined Drift coming from Salesforce, having gone from a thousand people when he first joined Salesforce. Then, he started his own company in between, came back to Salesforce. By the time he left, it was 50,000 people. He's back down now. He's back in the jungle. Welcome to the jungle. You're back in the jungle where 500 people at drift right now. He is helping us transform our entire product organization and bring our product into the future, which is all about one word: iteration. That's all we're talking about: iteration. We're having some lovely conversations on iteration and we wanted to share some of our thinking with this here Seeking Wisdom community. Tell me how you think about iteration, both at the scales that you operated at before, the scale of your startup, and then at Drift. Maybe they're all the same. Maybe they're different. I'd love to know the common threads between them.
Leo: They are, I'd say, I mean, Salesforce and startup completely different. Drift is probably another level of different. It's like a third dimension of different.
David Cancel: Let's unpack that. Sometimes I think I'm playing three- dimensional chess. crosstalk
Leo: Yes, it does seem like that. While at Salesforce, the iteration is kind of baked against you because Salesforce only iterates three times a year. The pace of iteration is already baked into the process. They only make three releases a year.
David Cancel: Tell me about that. That's just like, when are these three releases? Why three releases? How does that work?
Leo: Early on in Salesforce's history, I think there were multiple releases a year. In fact, it might've been closer to Drift where they would just release all the time. It became chaos. Word of warning. We might get the chaos, hopefully not; but at some point it became so unmanageable to get the motions out. Well, actually the motions inside Salesforce and then also into the go to market so that they could be prepared to talk about things going out to market. But they started to change. This was before I went into product at Salesforce, by the way, but seen it and heard about it. Then, I think they decided, look, three releases is the... I don't know why they decided on three releases, but they named it after seasons or spring, winter, and summer, I think. There was no fall. I don't know why.
David Cancel: That's when things die. In the fall.
Leo: I guess maybe it's a bit too sad. They did it kind of like magazines where it's like, you release the spring thing so that when people are looking at the magazine, it is spring, but it would be released before spring. It caused some confusion.
David Cancel: It's like fashion. When you're a fashion buyer and you're buying, right now it's summertime, you're probably buying spring. You're usually two seasons ahead of your buying.
Leo: Anyway, so they baked that into the whole process. For the most part it worked, but it did tamper the ability to iterate so you had to think a lot more about the details of something before you rolled it out because you wouldn't have another shot at iterating on it for another four months. Which has its pros, but it also has its serious cons, as you know.
David Cancel: What were the cons and what were the pros?
Leo: The pros is it does help you figure things out more deeply. The cons is you could be way, way off. Then, your host, four months, your host, you can maybe do little tweaks. Because there is the ability to do patches and things like that, but not a major change.
David Cancel: Patches? You're taking me back to before the internet.
Leo: I'm going back to the old CDs. Software was sold in CDs. We're dating ourselves. But actually my team, we tried to break that mold. We tried to do something that was called continuously releasable.
David Cancel: But that's why you're a troublemaker. That's why inaudible
Leo: That's exactly. I always was a triple troublemaker even at Salesforce. We tried it. We did manage to have some success, but we were always swimming against the grain. It was difficult. It was very, very hard, but we were trying to do it, more iterations.
David Cancel: Then, when you started your own company, what was the iteration like?
Leo: Every week. We had another problem, which is we had to deal with the whole Apple thing. Because it was a mobile app and then you release it, you have to wait for the whole process to go. You know what it's like.
David Cancel: It's gotten better now, but probably when you were doing your startup, that was painful.
Leo: We started, we were in this weird schizophrenia mode where you have the thing that's live, you're releasing another one that's not going to see the light of day for another two or three weeks, and you're starting to think about the next one. It just drives you kind of crazy because you don't know what's where. It's just insane.
David Cancel: I remember when we started Drift and we were mobile only for a little bit. This is at the very beginning and we were in that state. Then, you were constantly, you didn't know what you were talking about anymore because you'd be talking about problems, but in your mind, as the product and organization, you've already released something. You're like," Well, not that," because no one actually has that thing and you're working yet on the next release. You don't even know what are people talking about? Are they giving me feedback on some test flight candidate? Are they giving me feedback on what's in production? What is in production? Because I'm already three versions ahead of that. It was just this constant state where you're confused, what you're working on there.
Leo: It's kind of nuts.
David Cancel: Then, what is the three- dimensional chess at drift like?
Leo: Well, I mean at Drift, what you and Elias have instilled in the team is this idea of having very, very small teams that are very, very nimble. Now, you have a multitude of little things going on at very different speeds and they're all autonomous. It is a whole different dimension, which I have never seen before, and it's exciting. It's unusual for me, a little hectic at times, I'll be honest. crosstalk
David Cancel: We'll have to share with people. We'll have to do a screenshot that I sent you earlier. We were talking about tabs and I sent them how many tabs are open in my browser, and that was only one window. I have three other windows that looked like that. I have a heavy memory usage thing coming up right now as we're recording this. That's kind of like, that's a visual of what we're talking about here. That iteration's interesting. I mean, I never operated at the scale that you did at Salesforce, so I've never seen that kind of scale, but we had a similar problem when we were at HubSpot of we were running in the same kind of mode that we are now, continuously building stuff. Even more extreme because we had to build new products; at the same time, we were replacing a hundred percent of an old product that we had existing customers on. There'll be multiple migrations happening for different parts of the product line. What we had to do in the end, which I don't know what they do now, was we had continuous deployments like we do now. And we had to do one thing. We had faster iteration happening or a number of releases happening every single day. Then, what we had to do eventually was two things. One from a marketing and sales standpoint and customer standpoint, there was basically like one release a year one because that's when it would get announced and that's when it would get heavy training and heavy announcement and heavy partner involvement, I should say public partner involvement, in our event, which was called inbound, sort of like a smaller Dreamforce. That's when it would happen. That's when the majority of the customers in the world would learn about it. But the reality was we would have released that six months before, nine months before that ever happened. It was actually live. Customers were using it. Real customers, not early access customers were using it. It was just like no one was talking about it yet. Again, this is SMB customer base so we weren't talking about it. We weren't promoting it. We weren't trying to get people into it on masse. They were slowly opting into it. Then, we added the second thing, which was disability. This was for the bigger customers where they couldn't deal with things changing in the UI. We had partners in Japan, Tangent here who... Japan's a whole different way of doing business. They would train all of their customers on the interface and they actually would have binders that they would print for their customers. Print every screen and every text was translated on this screen. I had no idea until I met this partner and they were like,"You keep changing everything and we like printed." I'm like,"You print the screen? What are you doing?" Anyway, we had to recreate this feature that would enable partners and customers to be able to opt in to new releases, and which drove product crazy because what it meant in reality was they had to support multiple versions. They had to, if you were releasing a new version of whatever, email, or you were making changes to email, you may have to support the old version of the email and not have anything break for six months, nine months, whatever the agreement was, as people were slowly opting into this thing. That's the way that we dealt with it. Again, no one liked supporting multiple versions and support had to. Then, we had to figure out tooling for support because when support issues came in, it was the old version, the new version, almost like the Apple thing that you were talking about. But from a customer experience standpoint, it was way better because it gave them control, put the control in the customer. They said," I'll opt in when I'm ready to this new version." In some cases we had to have backwards compatibility where they may try it and they may be able to revert back to the old version. Again, everyone hated this from a build standpoint, but it was important.
Leo: A couple of things you mentioned there. One is you thought you'd get rid of the whole on- prem way of developing software. It comes back to bite you because that's exactly it. At Salesforce, there was a name for that thing in fact. It was called DNAENF, wonderful acronym that stands for Do Not Auto-
David Cancel: It sounds like a curse.
Leo: Do Not Auto- Enable New Features.
David Cancel: That's not where I thought you were going when you said DNA.
David Cancel: Then you had DF in it.
Leo: No, but it's basically a switch that every org could say, anything that you release is held off until I explicitly turned it on. When it works like that, and obviously most of the Japanese customers like that, in fact-
David Cancel: Hundred percent.
Leo: crosstalk the Japanese customers. There was some, I think in fact, this is my second stint at Salesforce, they were talking about moving to lightning. Some of the customers would say," All right, this is a whole change of the UI. Moving this over is going to cost me$ 2 million." Moving over. I have to print the things, I have to release all data.
David Cancel: They do the same thing with the printing?
Leo: Yeah. Oh yeah, hundred percent.
David Cancel: Oh, my God.
Leo: All the training that goes with it and all the people that they hire to train. Insane, insane. You start looking at that and like," Oh, okay. I get it. It's different."
David Cancel: That's the only way I got it. When the guy, actually, the partner, showed me the binder. He brought the binder from Japan to the event because he wanted to yell at me. He had the binder and then there was a binder, every screen, every label. Then, it was like in- person trainings and kickoffs and this, and it was this whole calendar thing. I was just like," Whoa, what are you talking about?" This doesn't even count for change that's happening within the company in terms of their customers, in terms of new employees and all this. But the training was like mental on what they were doing.
Leo: I think for Enterprise companies like non- Japanese ones, let's put that aside because that's a whole category of its own, I think it's somewhere in between. I think they do need some stability, but they don't go as far as going to print binders and that kind of stuff anymore. That's all we know. But I think once a year is kind of rough. Because Enterprise, they do want to onboard new things. We do want to get them to use them. I think for example, at Drift, I could see us getting to a monthly cadence because it also helps with CS and the sales teams and marketing teams. They want to know how to talk to customers about these things. Having things piecemeal leads to situations where the customer is telling them," Hey, this thing just popped up on my screen." It's like," Oops!"
David Cancel: You'd never want that. To clarify, we had big releases. Whole new products will come online throughout the year and we could train and we would train the salespeople and what have you, but we wouldn't announce it publicly. We wouldn't try to get 10, 000 or whatever it was, 15, 000, 20,000 customers to use it all of a sudden. We wouldn't try to sell it, go head to head competitively with someone and make a big splash in the market until we did it at this big event, because that was when we were gathered or whatever, it was a hundred thousand people or whatever it was to make this splash. Part of it worked because one mistake that I've made and I see all the time is tying marketing and product releases. Tying them too tightly. It's always a disaster because at the end of the day, if you're tying to a marketing date and then that's the force in function, they want to announce some stuff, then you're always cutting back. It's always like a half version of it, and then it's a, you're making a big splash of something that's the half version and there's all sorts of bugs and problems and this and that. Basically, it's the exact opposite of what we're talking about in this episode. There's no iteration. What you want to do is separate them so that you have a bunch ideally of iterations before you make a big splash.
Leo: So you know it's solid. The thing I've seen also is the other extreme where they're so uncoupled, marketing and product. That you mark with something that you never ship.
David Cancel: That's called vapor ware.
Leo: Yes, I've seen that a few times.
David Cancel: We don't want that. We want the opposite. You want lots of shipping. Then, when something is well, big, solid and has customer testimonials, has case studies, has example, has been vetted and trained and everyone's trained, then you make a big splash about it. You don't want the training to start then.
Leo: That's the strongest marketing as well. It's not the company saying it. It's the customer saying it.
David Cancel: Absolutely.
Leo: You want me to get that if it's baked and tested and tried.
David Cancel: A hundred percent. How do you think about feedback loops and how do we tighten our feedback loops at Drift, but in general, for anyone listening to this?
Leo: I think it's getting very, very close to customers. I mean, you have to be friends with the customer. You have to understand their problems better than they do so that you come in as an advisor. When you're an advisor, they constantly want to get your feedback and so that helps you close those loops more tightly. That's how I see it, at least. How do you see it? Going back to the veiled one- on- one, why am I not calling the feedback lately?
David Cancel: This is a coaching session, personal coaching. I think the most important thing to drive in the entire company. In a company, but especially in our company and then within the product organization, as the heart is the idea of a customer feedback loop. That customer can be internal or external. It should be one of the customer bases that you serve. But meaning, in our case we produce sales and marketing software, so our sales and marketing team should be customer zero for everything. But tightening the customer feedback loop, how close can you get to the customer, and what you want to avoid in that feedback loop is proxies. If you're the one actually building a product, in other words, you want to get the people who are actually hands on keyboard. Unlike me, I didn't need to touch this keyboard, but hands- on keyboard actually creating, or hands- on mouse actually creating the design, the product, actually coding it. You want those makers to be as close as possible to one- to- one interaction with the customer because that's when you'll get the best results in my opinion. That's when you'll get the true feedback. And so you want that. Then, you want to avoid proxies as much as possible. PMs in some ways are proxies. They are necessary. They are needed. They are core to the thing working. But you don't want all information from the customer to be filtered through a PM and then to go to the actual person making the thing. You want this direct connection. The other thing you don't want is the feedback to go through a proxy to get to the PM. In that case, not actually talking to customers but actually reading feedback or reading emails or listening to calls or whatever. No, you want them to feel the pain and energy. Just like when that guy came with a binder, put the Japanese binder in my face. You want that in your face. I had heard about it on a theoretical level. I heard that they had this whole training thing, but it was not until the binder was in my face that it was just like," Oh, okay. I get the pain now. I see the pain."
Leo: With proxies, I think the message gets softened and it gets muddled. You get into a game of telephone.
David Cancel: True.
Leo: I'll go one step further. I think even the person who's giving the feedback sometimes proxies for themselves. It's important to just watch him. Watch him do it. It's like," Oh shoot, why'd you do that? Why did you click there? That's not what I intended." You only see that by actually watching the person use it.
David Cancel: There's also like a numbness that comes from it. It becomes like a theoretical exercise or something. It's like," Oh yeah, I see that bad thing happening in a distance." But if it's involving you, if you feel the pain in your face, you physically emotionally feel that pain. Then, you're just like, you're more apt to actually solve the problem versus just being an observer. Getting into this observer pattern. For us, you want to get as close as possible. You want the people making to be as close as possible to the customer. Then, the next thing is that you want to learn, not repeat. You want to learn from the mistakes that you're making in getting that, building that product, doing that thing that you're doing, launching that strategy. Then, you want to as quickly as possible, then iterate. You want to have as many, I kind of think of it as like, you want to have as many learning loops as possible for anything that you're creating, anything that you're building, whether it's a product, whether it's a service, whether it's an offering that you're doing, whether it's a sales approach or a marketing approach. All you want is as many iterations as possible because as long as you learn and you don't keep repeating the same mistakes, then that's how then you have progression and then you'll have very fast progression in what you're building.
Leo: I have a follow- up question for you. The tables have turned, I'm asking you questions. How do you figure out when to stop iterating and focusing on the next thing?
David Cancel: Hmm, that's a good question. I would say, focus on the next thing. That's an interesting thing. I think in one way, I think you should never stop iterating on the thing. That's why I kind of believe in this, like what you mentioned, these small teams and this idea. Because in my mind, it's like if someone is still using something that you're making or whether it's software, whether it's a service, whether it's any kind of offering you put together, if they continue to use it, if more customers are using it and more customers are using over the time, then the learning should never stop. It should continue to evolve and iterate. We're not producing something that is static. We are in the software world so it should continue to change and evolve over time. Therefore, I think the iteration should never stop at that micro level. Moving on to the next thing might be a company or team or market imperative. In that case, as long as you're serving the customers with the old thing, you should spin up and start new teams ideally to deal with the new imperative that you have in terms of going on to the next thing. Like if you were to think about the big transformation, legendary transformation, that Netflix did to move from DVDs to online and to now studios, that whole thing, when they did that move, even though they moved the bulk of the company to focus on this new thing that was possible which was online consumption of video, they still had teams and facilities and things set up to continue to serve those customers in the DVD part of the business until that no longer made sense. But those teams only went away from focusing on that and doing that work when they no longer sold and service that product. That's how I think about it. I think at a micro level the teams should never stop iterating and learning on what they're doing because they can always improve and get better. Then, at a macro stage, yes, start new teams, new people to focus on new imperatives or new things that we need to focus on.
Leo: Then, the Netflix analogy you gave actually it's, you could say the team continued to focus on the same use case. It was just a different product to serve that use case.
David Cancel: Totally. It was a different product to serve, which was the time was right to be able to do that. That's why they could do that. We've also had on this here podcast, if you haven't listened to, the authors of Working Backwards. If you look at towards the end of that book and this is a story of how they build within Amazon. At Amazon, when they went into Prime, when they went into video, when they went into all the new businesses, the Kindle, et cetera, et cetera, and this chapter is on all of those, when they went into those, those were new teams. Those were new imperatives. It didn't mean that they stopped iterating on shipping, stopped iterating on e- commerce, stopped iterating on category creation. Those things continued to have teams and resources and people iterating on it because there were still customers that were being served and new customers that were coming into to use those products. They just had to continue to scale horizontally and add more teams to be able to do more things. That's how I think companies should operate. That's how I think we should operate.
Leo: We're getting there. We're trying.
David Cancel: We're getting there. All right. If you can teach us something about iteration, I want you to leave a comment for us on this here. Wherever you're watching this, leave a little comment or review six star only podcasts, certified world only, galaxy's only six- star certified podcasts and hit up Leo and tell him to tell you something in Portuguese. Tell him how young he looks compared to the old, old uncle. Again, I can wear hats. Check out my hat on video. All right, Leo. Thank you for joining us today.
Leo: Thank you.
David Cancel: Iterate, iterate.
Leo: Let's do it.
David Cancel: Let me know what you thought of this episode by texting me at 1( 212) 380- 1036. Again, 1( 212) 380- 1036. Now, if you're looking for more leadership insights, sign up for my weekly newsletter, The One Thing at drift. com/ DC. Every week, I'll share a habit, tool, or mental model that's helping me reach my goals. Hope to see you there. Text me, hit me up.