Episode Thumbnail
Episode 2  |  13:03 min

01: How A Modern Product Team Should Work

Episode 2  |  13:03 min  |  01.11.2016

01: How A Modern Product Team Should Work

00:00
00:00
This is a podcast episode titled, 01: How A Modern Product Team Should Work. 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. --- Agile and waterfall just don't cut it anymore. Here's how a modern product team should work, why small, autonomous teams are the future, and how you can apply this model to your business today.
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. --- Agile and waterfall just don't cut it anymore. Here's how a modern product team should work, why small, autonomous teams are the future, and how you can apply this model to your business today.

David Cancel: Hey, I'm David Cancel and today on Seeking Wisdom, we're going to talk about product teams and specifically why Waterfall and Agile just don't work anymore.

Speaker 2: All right. So we're going to talk about how you think a modern product team needs to work today. But before we dive into that, let's kind of set this up with the why. There's been plenty of successful businesses that have been built on things like Waterfall and Agile. Why do you think things need to change?

David Cancel: I grew up in the age of Waterfall and Agile, and I think those methods were great for a certain period of time, but the reason I think businesses need to change the way they do this today is that the world has changed. Right? All of the products and services that we create today are ultimately connected with the customer. Right? Whether it's the internet of things, whether it's web software or mobile software, everything that we're building from in software is somehow connected directly to the end users using the product. So the way that we build software should change to reflect that fundamental change.

Speaker 2: I mean, even if you do something like you buy a Tesla, something's broken in the car, you don't have to go send back your car. They can ship a new update. It's not 20, 30 years ago where you spend months and months building something, ship it, see if people use it and then iterate.

David Cancel: Absolutely. So the Tesla is the perfect example of how the world has changed. That is a software platform now. That's one of the most exciting things about that car is waking up every morning and seeing what updates have been rolled out to the car. It's magical.

Speaker 2: All right. So you went to HubSpot. So you were at Performable, went to HubSpot and through those experiences, you kind of switched and moved away from those traditional models. The solution is... I guess you'd call it this customer driven model. That's kind of the basis of how you're thinking about product teams today. So I want to talk through some of those. The first one is all about having small teams, units, not having these big divisions. What's the makeup of that team?

David Cancel: Yeah. So I think the important thing is that we wanted to create an environment where we wanted to work in, where we were founders, we were used to having a lot of autonomy and freedom, and we wanted to create an environment where we would love to work. Because of the way the world has changed, the best people out there have the most options today. So you need to create an environment like this. So the way we set out was to base the model around small teams, and at the beginning I just chose three person engineering teams. When I did, all the engineers grumbled and said," Why three? Why not five? What's your logic?" I said," I just made it up. Let's just go with three and then it's arbitrary and then we can change it later if it doesn't work." Over time, I kept messing with the model and tried to expand it and contract it and then always found that three was this kind of magical number. The reason that I think it worked is that three was big enough for you to take on a substantial challenge as a team, but small enough that you didn't have to feel like you always had to keep up with what was going on with your team. So the process overhead was really low and the model for three engineers was one tech lead, and that was the lead of the team, and then two engineers, whether they were back in or front end engineers, but those two engineers reported to the tech lead. By keeping it a small size, the tech leads never grew into full- time managers. They spent 80 to 90% of their time coding and these three person teams would take on products that they were competing against entire industries, entire massive teams, and these three person engineering teams could take on that challenge.

Speaker 2: So where does the product manager and designer fit with these teams?

David Cancel: Yeah, that's everyone's favorite question. As soon as I mention the three person engineering team, they say," What about PMs? What about designers?"

Speaker 2: I'll lead you and say talk about the shift in the traditional PM's job and then what their job is and this model.

David Cancel: Yeah. The way that we saw the model working and the way that we've made it work is that the product is run by engineering teams, right? So it's an engineering led organization. So in a typical environment, you would have a PM who would take on a product manager who would take on typical product management tasks, but would inevitably kind of regress into doing a lot of project management work for the engineers. So whether that was creating bugs or creating lists or creating processes or Gantt charts or this or that, whatever they were doing, they were off creating all this process overhead for the engineers in order to help the engineering team scale. But what we did was have the engineering teams own the solution, and that included how they built a product, whether they were focused on bugs, new features, what have you, but also how they wanted to project manage that product. The product manager owned the customer and they owned working with the designer and getting out in front of the engineering team and iterating and prototyping and getting feedback from the customers.

Speaker 2: The biggest shift here, other than the teams being small, is that the resources on the product manager and designer, they have to be embedded. That seemed to be one of the bigger learnings.

David Cancel: Absolutely. So what we did was make sure that when a team owned a product, that was a three person engineering team, but it also included a product manager who was usually shared across multiple engineering teams into what we call the family. So a bunch of products that were kind of similar in the customer type that they were aiming to solve, and then the designer was dedicated as well and dedicated to that team. So in that way, you had a dedicated PM, dedicated designer and then a three person engineering team. We even extended this to have a dedicated product marketing manager who worked with each of those teams, actually sat with those teams. All these people, the PM, the PMM, the designer, and the three person engineering teams always sat together in kind of a pod.

Speaker 2: So instead of this agency model where all of the non- engineers basically think about this 25, I'm a designer, I have four clients, and I think of each of them, this is you're 100& in.

David Cancel: You're 100% dedicated. You're sitting next to the people on your team. You're overhearing conversations that are happening and you know exactly what is going on. Then jumping in to try to solve problems that you see emerging versus waiting for those problems to be bubbled up to you in a meeting or through some other high overhead kind of process.

Speaker 2: We're going to do a whole nother dedicated episode on this topic, but the key thing that makes this whole model work seems to be ownership and freedom. So outside of it being small, having freedom and having ownership over the things that you're doing seems to be the glue of this whole model.

David Cancel: Yeah. That was always the glue and the goal, right? The goal was to increase the amount of ownership and freedom and autonomy that the teams had and it was also the glue that made this whole thing work. The reason that it made the entire thing work was that it allowed the people closest to the problem to come up with the solutions and test those solutions with the actual customer, right? Those people on the team are spending more time with the customer than anyone else in the company, more than the executive team, more than the CEO of the company. So they have the right perspective in solving this problem and measuring whether they actually solve the problem or not.

Speaker 2: So you shouldn't have to wait weeks to get... If you see a problem and find a solution, you shouldn't have to wait weeks to get that out to customers. There's no release cycles. There's no long planning. You just do it.

David Cancel: Yeah. You have no long planning cycles, no roadmaps, no version numbers. Your goal is to amaze customers every single day. We looked at the metrics for each of the teams to make sure that they were always on that track, and so when a problem emerged, the team would go on and jump on it and deal with that problem. In a typical environment, you would have to wait for that problem to up through a lot of overhead and process, and then bubble back down after someone decided that this was a problem. Right? This allowed the teams to really be agile and really handle these problems.

Speaker 2: The results were pretty real. This wasn't just something that sounded nice. I think you said that the product team had the highest employee NPS out of all the other teams. So this actually had an impact on how people were feeling at work and productivity wise.

David Cancel: Yeah. That's the most amazing part of all of this, was just looking at the results that it drove and HubSpot, and now Drift, are super high performance cultures and so there's not much tolerance for things that don't work, even though they sound nice. So the proof was in the results, and that was the results that we were seeing directly from customers, but also the results we were seeing within the team themselves. We always had this model of measuring employee NPS, so how happy they were at work. Over time, we saw that the product teams EMPS became the highest within the company by a considerable margin. The retention of the product team was off the charts. During the last four years, it's been a super... I don't want to say frothy, but super high growth time where every engineer on the planet has a million offers, every designer has a million offers and we were able to have incredible retention by employing this model.

Speaker 2: Yeah. I think there's a stat that's like the average tenure of a Google employee is 1. 1 years or something like that.

David Cancel: That's amazing. Most of that team that we assembled and created under this model is still at HubSpot, so they're coming up on four years plus.

Speaker 2: So Drift is an earlier stage company. This is a new model here because the team is new. If you're a founder that's listening or somebody else, how do you apply this to your company? How did you start this at Drift? Is it just, you break off a piece and start there? How do you apply this to your company?

David Cancel: Well, doing it at Drift is easy because we're starting from scratch. Or easier, I should say. It's never quite easy. So if you're a recent startup or a company about to start, taking on this model is pretty simple for you to do, and it won't be easy, but it will be simple, right? The best things are always simple, but not easy to implement. I'd say the places that you'd have a lot of challenge are at larger companies because larger companies already have models that they are used to. Honestly, I don't think many large companies will ever take on a model this way, because it's always easier for them to keep pushing on the status quo and that is usually a top- down command and control method. So I don't think any of them will be ready for this kind of thing. They kind of look at what we're doing and how we build teams and all they see other things on the surface. They see the beanbags and the graffiti on the wall and the music playing in the office and the hammocks and all that kind of stuff, and then they say," All right, I need to get myself a hammock, and I need to get myself a beanbag. If I get that, then teams will be productive." But they're missing the point. They're missing the thing that actually makes it work, which is giving these teams the freedom and the people on your team the freedom and responsibility for amazing customers every day. Right? You as kind of the CEO or some of the leaders within the company, getting out of the way and doing everything you can to support those individuals on your team. It's uncomfortable, it's probably not what you're used to, but it's the way that innovative companies have to work today.

More Episodes

#179 Focusing on the Four Main Buckets with Sara Blakely and Jesse Itzler

#178: Will Anything Top El Cap? With Alex Honnold

#176: Why Technology Isn’t the Reason You're Distracted with Nir Eyal

#175: Bridging the Gaps Between Skiing, Climbing & Filmmaking with Jimmy Chin

#174: Never Stop Iterating

#173: Replacing Yourself