00: Introducing Seeking Wisdom With David Cancel
David Cancel: Hey, I am David Cancel, I am a serial entrepreneur, two times CEO, and I am currently working on my fifth startup drift. Once a week, I am going to be sharing one thing I have learned with you on this podcast. On tips on how you can be more productive, the techniques I have used to accelerate my learning, how I read a book a day, vice for building businesses, your customers and employees will love, lessons from the people that inspire me startup strategy and more. Subscribe on iTunes or follow us on SoundCloud so you can be the first to know when the show launches. Here's a sneak peek of the first episode.
Speaker 2: And that is everyone's favorite question, as soon as I mentioned the three person engineering team, they said, what about PMs? What about designers?
Speaker 3: I'll lead you and say like, talk about the shift in a traditional PM's job and then what their job is and stuff.
Speaker 2: Yeah. The way that we saw the model working and the way that we have made it work, is that the product is run by engineering teams, right? So it is an engineering led organization. And 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. And so whether that was creating bugs or creating lists or creating processes or Gantt charts or this or that, whatever they were doing, like they were off creating all this process overhead for the engineers, you know, 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 the product, whether they were focused on bugs, new features, what have you, but also how they wanted to project manage that product. And 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 3: The biggest shift here is other than the teams being small, is that the resources on the product manager and designer, they have to be embedded. That was, seemed to be one of the bigger ones.
Speaker 2: 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. And so that way you had a dedicated PM dedicated designer and then a three person engineering team. And we have an 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 and kind of a pod.
Speaker 3: So instead of like this agency model where all of the non- engineers basically think about this 25, I am a designer, I have four clients, and I think of each of them, this is your 100% in?
Speaker 2: You are a 100% dedicated, you are sitting next to the people on your team. You are overhearing conversations that are happening and you know exactly what is going on and 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 3: So we are going to do a whole, another dedicated episode on this topic, but this is 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 are doing it seems to be the glue of this whole model.
Speaker 2: 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 and 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? Like 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. And so they have the right perspective in solving this problem and measuring whether they actually solve the problem.
Speaker 3: So you should not have to wait weeks to get, if you see a problem and find a solution, you should not have to wait weeks to get that out to customers. There is no release cycles, there is no long planning, you just do it?
Speaker 2: Yeah, we have no long planning cycles, no roadmaps, no version numbers. Your goal is to maize customers every single day and we looked at the metrics for each of the teams to make sure that they were always on that track. Then, 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 bubble up through a lot of overhead and, and process. And then bubble back down after someone decided that this was a problem, right? This allowed the teams that really be agile and really handle these problems.
Speaker 3: And the results were pretty real, like this was not just something that sounded nice. I think you said that the HubSpot, 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.
Speaker 2: Yeah, that's the most amazing part of all of this was just looking at the results that are grown and, HubSpot and you know, now drift are super High- performing.