Episode Thumbnail
Episode 141  |  34:15 min

#Build 3: Maintaining Autonomy w/ Martin Eriksson

Episode 141  |  34:15 min  |  07.05.2018

#Build 3: Maintaining Autonomy w/ Martin Eriksson

00:00
00:00
This is a podcast episode titled, #Build 3: Maintaining Autonomy w/ Martin Eriksson. The summary for this episode is: Every employee wants to feel like they’re a part of a truly autonomous team. A team where they’re a part of the decision making process. A team where their voice matters. Where their opinions can make a difference. Maybe you’ve never been a part of a team like this. Or maybe you’ve only been a part of teams like this. Regardless, autonomy is something that everybody wants. But what does it look like in the real world?
Every employee wants to feel like they’re a part of a truly autonomous team. A team where they’re a part of the decision making process. A team where their voice matters. Where their opinions can make a difference. Maybe you’ve never been a part of a team like this. Or maybe you’ve only been a part of teams like this. Regardless, autonomy is something that everybody wants. But what does it look like in the real world?

Maggie Crowley: Welcome to# Build, a new channel on Seeking Wisdom where we're going deep in how to build products and product teams. I'm Maggie, a PM here at Drift and I'm super excited to be joined by Martin Erickson, a giant in the products community. Founder of Mind The Product-

Martin Erickson: Both physically and metaphorically.

Maggie Crowley: ...the world's largest product management community and conference, founder of ProductTank. Also, the co- author of the book on product leadership, an executive in residence, a veteran product person, and the list goes on. Martin, thank you so much for joining us. Appreciate it.

Martin Erickson: Thanks for having me.

Maggie Crowley: I just want to start really quickly with how you got to where you are. I think a lot of the Seeking Wisdom audience are practitioners and we haven't really made the leap to experts. So how did you first get into product and then make that jump into advising product teams?

Martin Erickson: So I started actually building stuff online way back in the'90s. I was kind of tinkering at home in high school,'94,'95, just as the web was exploding. Back then I was, I guess, a web designer and a web developer in as much as I knew how to do HTML and CGI script, which is all web development was back then. I started university. So I went to international business administration at a University in Sweden, but probably spent more of my time in the computer lab than in my classrooms and lecture halls. So I actually dropped out after two years and went and started working as a website and web developer in Stockholm for a couple startups until the end of 1999 when everything went bust and I ended up moving to London and working for Monster, the job board, as a product manager and suddenly I was like, oh, there's this whole library of knowledge.

Maggie Crowley: Yeah. Did you know that you wanted to be a PM or is that something that sort of happened?

Martin Erickson: No, I just knew that I had developed this idea that I was a good generalist. I had a little bit of design skill. I had enough technical skills to work with the developers, but I was never going to be an art director. I was never going to be an engineer on its own. And then I had enough of that business studies, even though I dropped out, that that combination of those three things was a really good generalist role. I think it was first when I moved to Monster that I discovered that there was this whole title and skill set around it.

Maggie Crowley: So then how did you go from your first experience at product in London at Monster to one of the world's experts in product?

Martin Erickson: I think it was just, as with everything I hope, I think it will be a theme of what we're going to talk about today is it's a journey of learning. So I started as a practitioner. I was working on the team rolling Monster out to the rest of Europe and back then it was much more hands- on. So we were building up local teams. We were helping them figure out what are their local requirements. We had product managers in every team and in a way, totally the wrong way to do it, but in a way we were the filter between them and the engineering team, which was back then actually based here in Boston. And so we got to be almost a consultant role of trying to figure out what do the local markets need, but also how do we sell that into the core organization and how do we find the common themes that we can prioritize, but also did a bunch of growth through acquisitions. So we did a bunch of M&A where I would come in and help integrate those products into our existing product stack. And in one of those acquisitions, I actually ended up moving back to Sweden because we had acquired an applicant tracking system, very early software as a service, wasn't even called software as a service back then.

Maggie Crowley: What year was this?

Martin Erickson: This is 2003, 2004. They were called application service providers.

Maggie Crowley: Amazing. Pre- SaaS.

Martin Erickson: Pre- SaaS. And kind of took over that whole business unit. So I owned both the P&L and the product development. That was obviously a big step up for me to not just be a hands- on individual contributor, but actually own the whole strategy, own the P& L of it, try to sell that into the rest of the organization, get all these 14 countries on board with why SaaS might be a good idea instead of just selling job ads. I worked through that for three years and then moved on to The Financial Times where I helped them sort out some of their online classified stuff. Again, I think every step in that journey was just figuring out how to look at the bigger picture and bring together that bigger picture with my generalist skills. Then the last two product jobs I had were VP of product for startups. And as you know, the first product person taking over from the founder, building up a team, building up an org, figuring out how to make product work in that org for that customer, for that market and those were amazing learning journeys of really going from that individual contributor... I still to this day say that if you're a founder out there starting a business, you're actually better off hiring a practitioning product manager as your first head of product, and then giving them the chance to grow into the VP product because if they don't, you can always hire a VP later, but you don't need that seniority from day one. You actually need someone who can combine the hands- on and help you deliver the vision that you already have in your head.

Maggie Crowley: So how did you get from there to this expertise?

Martin Erickson: I think it was just a lot of luck and a lot of searching. So while I was at Huddle in London in 2010, I was the first product person at all in the company. It can be a pretty lonely job when you're in a startup and you're the first product person. All the engineers are ganging up on you. All the designers ignore you. The founder just keeps telling you to ship features. There's no one to talk to and learn from and share with and pitch to frankly. So I wanted to just meet other product managers and started this meetup called ProductTank. We had 25 people in the backroom of a bar in London. My boss stumped up some cash for some beers. I got some old friends to do two short talks. It was just an amazing time. And I met my two co- founders John and Simon there, and we just took it on. I think we would have just been happy there if we managed to get 25, 30 people, every couple of months talking about product and sharing some of our lessons and being able to offload some of our pains. I think we just all share that pain point of not having enough people to talk to about this and not having enough people to share our experiences with and learn from and pitch to.

Maggie Crowley: Yeah, that's something I know we've talked a lot about within our product team, making sure that you have even a local community of people that you can just get dinner with quarterly and just review.

Martin Erickson: Or even in the internal community, right?

Maggie Crowley: Yeah.

Martin Erickson: As you start growing, as we structure our teams more and more independently and more and more autonomously, it's so important for everyone on that team to have a community of practice to get back to, even within your own company. So their product managers should be getting together regularly. The designers should be getting together regularly. The engineers should be getting together regularly to talk about their specific challenges, and what they're seeing is other great ideas emerging in other parts of the organization.

Maggie Crowley: Tell me a little bit more about this whole autonomous teams thing and how you got on this topic. Then I'd love to hear a little bit more about how you maintain autonomy as your company scales and as you add levels. We're at a hyper- growth stage, how do we make sure that we maintain that and what should we be looking out for that we may not know about?

Martin Erickson: We were experimenting this at Huddle back in 2010, trying to figure out how do we put the decision- making as close to the customer as possible. It's basically where it started from for me. And the more layers you put between the people actually building it and talking to the customers and the decision, the more likely that message is to get carpooled, right?

Maggie Crowley: Mm-hmm(affirmative).

Martin Erickson: It's classic kind of-

Maggie Crowley: Game of Telephone. Yeah.

Martin Erickson: ...Inaudible, if nothing else, how much that message can get garbled. So that's where we started, and we were playing around and we were a small startup at the time. We only had a enough resource for two or three teams. We couldn't have a dedicated team owning one feature, one customer area so we had to rotate them around, but we tried to give them autonomy within a project. So we would prioritize a pain point. All the things are now coming out as more and more best practice we were trying to experiment with. So we would prioritize themes and we had this idea of, okay, we need to fix this area or this customer problem. We're going to spend three months on that and then give the team the freedom to figure out what is the best thing that we can do within three months to solve that customer problem and then rotate them out to do something else because again, we were too small at the time.

Maggie Crowley: So you set a deadline like you have three months, no matter what.

Martin Erickson: Yeah. Time-box it. So what is the best thing that we can do in three months? And then we always came up with more... You always have more ideas than you're going to be able to do in any given amount of time. Even Google with 20, 000 engineers or whatever ridiculous number they have, they can't do everything they have on their roadmap. So for us at the time, that was the best approach to do the prioritization piece of how much time do we want to invest in solving that customer problem right now? So we'd generate a bunch of extra ideas. The team would come up with great ideas. They'd end up in an icebox that we then could revisit later, but that gave us a way to think about how important is that problem to us. How much time do you want to spend on it before we have to move on to the next big customer problem?

Maggie Crowley: Yeah, that's something I get a lot is we set that lens pretty aggressively. We ship a new feature every single month, but if we prioritize a customer problem and then we say," Okay, we have three months to build it," and then the pushback is always," Well, we can't solve the problem in three months." So how do you frame that response to a team?

Martin Erickson: For me, it's always like there has to be some way to make that better in whatever timeframe. Obviously, it is a push and pull. So if I was trying to make something really tight and like I said, well, you're only getting one sprint... Because we were working in Scrum at the time. So if you only have one sprint in two weeks. Yeah. Okay. This is a bigger idea. We can't do it. Let's have that conversation. But when we were talking about the bigger themes we were talking about three month or six month commitments to like, we want to spend this team's time, because we had two or three teams, one of the teams focused three months or six months on a specific customer problem, and it worked really well. I think for us, it was a great way to time- box it, prioritize that resource, but also give the team that sense of autonomy that they were part of making the decisions on what happened. So we would do a ton of pre- work in terms of... We kind of did a dual- track type approach to it. So we did a bunch of pre- work in terms of going out and doing the customer research and looking at the data. And then we'd bring that all in front of our users or sorry, in front of our team, before we kicked off one of these big projects. And then in that ideation session in the first couple days, we let the team come up with all the ideas. And I think that's when I clicked that that's the best way to do it because inevitably most of the best ideas were not the ones that we had come up with as a product team. There were engineers coming up with things that got us 80% of the benefit for 20% of the effort because they knew the solution space so much better that when you presented to them what the problem's face looks like, they're like," Oh, that's what you're trying to do. Why don't we just do this?" And you're like," Awesome. Feature number one. Let's put that up on the board." So that's where it started clicking for me, and then I think I became a real evangelist for this whole idea of autonomous teams when we started doing interviews for the book. When we were writing the book, we knew that we didn't want to make it just the viewpoint of the three of us authors, because who wants to listen to three more white guys, three middle- aged white guys. So we wanted to be much more representative of a broader set of people. And we went out and interviewed hundreds of product managers, product leaders, and figured out how do you do what you do? Why are you successful? We talked to some big companies, small companies, we talked to U.S. startups, European startups. We really tried to have a wide purview. I think the recurring theme, whatever people call it, was this idea around autonomous teams. Make the decision as close to the customer as possible, customer- centric, mission- driven, all these good things that we talk about in the book. So that's when I really became like, okay, it's not just me. It's not my crazy idea. Everyone's doing some version of this. Let's figure out how we can talk about this more openly and how to do this the best way.

Maggie Crowley: I a hundred percent agree. I think, especially when I listen to a podcast, or I read an article and I read about autonomous teams, it sounds amazing. What advice would you give to a team that maybe isn't autonomous or wants to be that way, and how do you make that happen, especially if you're not the director?

Martin Erickson: I think that is one of the hardest things out there. So if you're the member of the team, and you're frustrated because you know you're being given bad inaudible basically and because you're talking to the customer, and you know that the things on your roadmap are not the most important things for your customer. The advice that I tend to give, which is easier said than done, is simply to start small. Find something, whether it's outside the roadmap or it's a small feature on the roadmap, and show that by thinking about it differently, you can actually have a bigger impact. So I think we were talking about this earlier, an idea around maybe even if you have a feature that's on the roadmap, it has a deadline. Try to step behind their thinking behind that feature. What is it that whoever wrote the thing, whether it's the product manager or one of the founders or someone in the sales team who gave you a ticket, what is it they're actually trying to solve? And then use all the skills that we have in terms of figuring out the problem, figuring out how to best prioritize that, to unpick that and go back to find maybe a better solution for that problem that really does take the customer into account, and you think is going to be better because you know more about the customer. And I think the more that we can do those things in almost guerilla product management style of just getting shit done and showing that it can be done in a better way is the most impactful way to do it because showing, not telling is always best. Then the more you can show that you're making those changes and that little by little it's having an impact on the bottom line or the customer experience or the stats, the more you're going to be given the freedom to keep working that way.

Maggie Crowley: I imagine that you're giving advice like this to teams all the time. You've been visiting with product teams and helping them for however many years that it's been. How has your advice changed over the scope of that time and has it been autonomous teams from day one, or how did you work up to that?

Martin Erickson: I think I used to be more flexible on that point. I probably used to be more forgiving and be like," Okay, well, if the founder has a good idea, as long as they're doing the validation..." For me, the cornerstone has always been the customer and whatever framework you use for it, whether it's Lean or other things, as long as you're validating it with the customer, I don't care where the idea came from or who's forcing it through. But I think more and more I am setting teams up, and especially now as an executive in residence for a VC firm when I'm going out and talking to these smaller startups that are just beginning this journey, I'm really, really adamant that they're setting themselves up to build an organization in this way. So even if they can't do it from day one because they're still just a founder and two engineers, that they're starting to think that way, that they're starting to talk that way. They're starting to use that language. They're starting to think about customer validation. They're starting to think about how to let the engineers be part of that process, how to let the engineers be part of the user research so that as they start growing, that culture is already there. And as they start spitting up new teams, that culture's there. That thinking's there. That autonomy and that decision- making close to the customer is there.

Maggie Crowley: I want to make sure that people who aren't at the first stage startup can do this too. How do you bring that into your culture if you don't already have it?

Martin Erickson: It's hard. That's the hardest thing about all of the things that we do. It's all about people. We talk a lot about different methodologies and tools and features and things that we can do but at the end of the day, it's all about people. Having the right team, having the right attitude, and then changing attitudes and changing culture is one of the hardest things that we do and that's why it's so hard to do it in a bigger corporation or an established company because they're so set in their ways. And actually, the worst part is whether it's a startup or a corporate, they've gotten to that success... Whatever success they've had, they've gotten there doing it that way, so they see... It's even harder then to make them change their minds, that they need to think about this differently. So really again, I use my own tools of how do you start small? How do you show and don't tell? So how do you work together with the engineers almost, or the designers, just break out a little guerilla team and then show the founders that, hey, we know this is a customer problem. We went and did the research. We talked to the customers. We did this validation. We did a prototype. Whatever it is that you wanted to get done and show that you could move a lever. And then that's the thing that starts opening the eyes of the founders of like," Oh wow, and I didn't have to be involved in that. No. But it's still within the vision. It still fits within that goal that we all have," but you got a better result. Yeah. So now you can trust your team. Sounds oversimplification obviously but crosstalk.

Maggie Crowley: Yeah, quick wins that allow you to build that trust with your executive team that allows you the freedom to be more autonomous.

Martin Erickson: Yeah.

Maggie Crowley: So when you go in, and you're meeting a team for the first time, what do you do to diagnose what their particular set of issues are, and how can we steal your model to diagnose our own teams? We're all about getting the secrets so give me the secrets.

Martin Erickson: Yeah, absolutely. I don't have a black and white hard model or anything, but there's definitely things that I look for when I look at startups or teams. For me, almost the number one thing I try to unpick, and it's the kind of thing that you can't necessarily ask outright because it's obvious what answer you want, so you have to be a little circumspect around it, but it does come down to how often do they talk to their customer? And it's surprising how many startups still don't talk to their customers. You guys are definitely an exception. I think the most successful ones out there are obviously the exceptions, but there's a lot of startups out there that still fall under the mistaken idea that the founders know everything about that customer. They used to be that customer. They know the problem they need to solve, and they're going to build a thing for them. And I think it's the worst thing that you can do to get stuck in that fallacy of being your own customer. That's one of the big things that I always look for is how badly are they stuck in that way of thinking? How little do they talk to their customers?

Maggie Crowley: How often should we talk to customers?

Martin Erickson: This is a cop- out answer but as often as possible. I think it is important to figure out the cadence. One of the biggest challenges I think around product management is that the answer to all the questions is almost always, it depends. It depends on... Market depends on your product depends on all of these things. But I think the bottom line is as often as possible, and then it's kind of a judgment call from there. And I think if we're doing software, if we're doing SaaS, it should be at least a weekly basis. You should be having conversations with customers and getting feedback from customers at least a weekly basis.

Maggie Crowley: What else do you look for when you try to figure out if a team is good or bad? What's your mental model around this?

Martin Erickson: So a lot of it's unpicking some of the things around how you build great autonomous teams. What are those building blocks that are there? So is there a good vision statement in place or a mission statement? Is that a customer- centric one or is it we're going to be the number one something because that's not a customer- centric mission statement? A lot of people get that wrong. And there's little clues in there all throughout the way of are they thinking about the customer first or are they thinking about we're going to build the best possible product? So that alignment piece, the vision piece. When you're in the room, how much is the founder dominating conversation versus letting other people in the room speak? There's things like that that I think can pretty quickly give you a picture of is this a team that's a functional team or a dysfunctional family, and can you save that or not?

Maggie Crowley: Yeah. I know I was reading that. I'm sure we all read those Google articles on how to build a team with psychological safety and all that. So again, I read an article like that, how do you actually put that into practice? What do you recommend to teams who might be falling into these traps?

Martin Erickson: I think again, it's the culture change piece. It's challenging, but it is kind of a... I treat it very much as a coaching role. So I'm still learning a lot about how to be the best possible coach. It's a whole thing in and of itself. You used to be an athlete. I'm sure you had great coaches, and you've seen what that can do. And that's the approach that I try to take. So for me, it's not about trying to teach them. It's not about pointing out when they're wrong. It's taking them aside after a meeting where maybe the founder was stepping all over their team and being like," Well, how do you think that meeting went? What were you trying to get across? Do you think maybe the teams saw this and not that?" And do those very soft touch coaching things, not do it in a confrontational way, not do it in front of anyone else. And that goes for team members as well, it's not just the founders, and really try to unpick that behavior piece. And I think that steps into so many other things that we have our own biases and diversity challenges that we can have in the office space as well. How do you unpick those behaviors? It has to be done very softly. It has to be done outside of the room. It has to be done in a coaching way. And I think that's where there's more and more people working on coaching around product specifically, and I think that's a really great thing and I think we need to see more of that.

Maggie Crowley: So in that theme of best practices and what we do or don't need to be doing more of, at Drift we have a deep skepticism for best practices and this idea that they're only going to get you to the norm of the day, and they're not going to help you go even further than that. So when you're giving advice to teams, how do you think about best practices, and where are they relevant, and as an advisor, how do you start to bring more innovative practices into the companies you work with?

Martin Erickson: So for me, when I talk about best practices, it's things like being customer- centric, it's being mission- driven, it's having regular cadence of customer feedback and insight. Those are the best practice things for me, and I think that's something we should all be doing anyway. The level below that is when you start talking about methodologies or different ways to do that, or different tools you should be using and whether it's Lean or agile or design sprints or user researcher, or... Whatever those things are, that's where I become completely agnostic. And I think they're all tools in a toolbox, and they're all great tools. They're all useful in different things, in different scenarios. And what I hope that I can bring to the table, because I've been around the block once or twice, is how to apply those tools and when to pick the right tool. So when I go into those teams I tend to be thinking a lot about, okay, are they hitting that very top level best practicing? How often are they talking to the customer? How often are they doing that? And ram that point home first, because if they're not even doing that, I don't care what they're doing after that. But if they're doing those things, then it's like, okay, what are the specific challenges that we need to solve here? What are the best tools for us to use? I think even those tools are something I see as a great starting point. So I would often get a team... We did this at Huddle. We went in hard on agile and Scrum, and we were doing sprints and estimations and all these things, and we kind of went a little bit too far probably, but then we started applying those things on the practice itself, either figuring out what is working, what's not working. Okay, let's strip this apart. Let's take this out. We don't need to do that part. And at the end of it, we ended up with our own methodology. And actually one of the teams went full Kanban and one team was still kind of we're doing our version of Scrum and kind of didn't matter at that point. But I think the best practices are great, or those toolkits are great because they give you a level set. They give you a common language. They give you a common starting point that you can then improve on and figure out, okay, well that doesn't work for us because our customers aren't working that way, or we're in hardware, so two- week sprints don't make sense. Let's make it eight- week sprint... Whatever it is that works for you and your team and your market and your customer. I think that's one of the biggest things that I also push on in a lot of these organizations is not to get stuck into that dogma of, but the book says, do this, and it's like well.

Maggie Crowley: Where the process becomes the point rather than the outcome.

Martin Erickson: Yeah.

Maggie Crowley: Yeah. We talk a lot about results, results, results. How do you get focused on those rather than the process by which you're working and how to prevent the process from becoming the thing that you're shipping.

Martin Erickson: Yeah, absolutely. And I think it's hard. And especially if you're a first- time founder or a small team, and you're looking up to all these other giants and someone's read Scrum, and they're like," This is what we have to do." But as soon as you get into that mentality of like," Oh, we're not doing stand- ups. We're not agile." It's like, well, no, but who cares? Are you doing what you need to do for your team?

Maggie Crowley: Yeah, we still need to know if work is getting done.

Martin Erickson: Yeah. At the end of the day, are you delivering a customer outcome or not? That's all we really care about. How you get there shouldn't be the important part. It's going to change. It's going to change when you're three developers and a founder to when you're 300 people in multiple locations, you're inevitably going to have to change how you work.

Maggie Crowley: Yeah. So where do you see people, different companies' processes, break along that path of growth? So I imagine the processes... I know from inaudible for six months, I know the process is not the same as when I started, and it's probably not going to be the same six months from now as well. What are the inflection points for that?

Martin Erickson: So the inflection points are definitely around... They're actually pretty tightly aligned to fundraising rounds as well. So there's something around going from angel and seed funding to going to A funding where you inevitably hire your first professional product people. You hire those first people who are not necessarily in a bad way, but they're professionals, they're career- oriented. It's a job for them. It's not a mission as much for them. They're not taking less risk on. So that's obviously a big inflection point of how do you get those people on board? How do you get them excited about the mission, and how do you get them believing in it the same way the founding team does? And then as you scale, I think there are, be you around, inaudible make sense because those are big inflection points as the team doubles and triples and et cetera, in size. So I think those are the inflection points to look out for. But I think the big one for me is definitely around delegation. One of the biggest things is founders letting go of their baby and trusting their teams. And that's the biggest, hardest thing to do as a founder is to realize that the product is no longer... The product that you're caring about, the company is the product that you have to care about. You have to start thinking about culture and hiring and where should the office be and all of those other big picture things. Where are you going to raise the money? How are you going to go to market? How do you get the teams talking to each other? That's your product. And I think product people, designers make great founders make great CEOs because they have those skills of stepping back from the problem, trying to understand what the problem is, how do we apply the best toolsets for those? How do we align everyone? How do we do the communication piece? But they have to let go of the product? They have to trust the team to take on that baby and trust that they're going to deliver that vision.

Maggie Crowley: We talked a lot about founders, about process. What are the biggest mistakes that you see just over and over again?

Martin Erickson: The biggest thing that I see so many startups doing wrong is simply not talking to their customer. And I bang on about this point a lot, but I think it's just so fundamental that if you... And I think most often you see it, like we talked about earlier, when a founder has been the customer, or they've been the person who's got the brainwave because they were the doctor, so they have a better way to build a doctor tool or whatever it is. They so quickly get stuck in on that solution, and they focus too much on the solution. And I think what we have to do as startups, what we have to do as teams, is actually fall in love with the problem. And we have to get excited about the problem. We have to get excited about the space and the mission and the vision, and then everything else will flow from that. But if you get stuck in on the solution, you follow that even if it ends up being the wrong solution, even if it ends up being terrible from a unit economics perspective, or a go- to- market perspective, or whatever it is. But you're so focused in on, we build the best widget X, that you can't think any other way. So a lot of my advice tends to be how do you step back? How do you think about the problem? How do you actually formulate your mission and vision statements in terms of customer problems? How do you get everyone excited about that? Because then that will afford you a lot of different solutions to achieving that.

Maggie Crowley: I think I'd like to talk a little bit about the book. I'm just looking for secrets. I want to know how to do my job better and prove DC wrong, that I'm worth hiring.

Martin Erickson: That's why I still do what I do. I'm willing to learn how to do this job better.

Maggie Crowley: Yeah. So my favorite quote from it is," Daily swims in the ocean of ambiguity are a part of the product leader's life. It's just the depth that changes." I love that quote. What does it look like in practice? How can we learn how to do that better? What does that really mean?

Martin Erickson: I think it comes down to so many things that are fundamental to building great products and building great businesses, which is to understand that you don't have all the answers. And that's a really hard thing for most of us to do. It's hard as founders, it's hard as engineers, designers, product managers, to really step back from this and go, I don't know what the answer to this is. I don't know the best way to do this. And it comes out in so many different forms, like the biases that we have, the approaches that we take, the reason we fall in love with solutions rather than problems. And so that daily swimming, the sea of ambiguity quote, was all about recognizing that we have to be comfortable not knowing. We have to be comfortable in a constant state of trying to figure out how to do this better, not just our job, but also how to build a product better, how to better solve that customer problem. And if we, at any point, get too comfortable going, oh, I know what to do now. I know how this is working. We probably need to move on or do something else or rethink that really strongly because I think that's a trap.

Maggie Crowley: So that's the warning point that I know what I'm doing. That's what we should look out for?

Martin Erickson: I think so. Yeah. I think if you, at any point, feel like you know what you're doing, if you at any point feel like I know what this customer needs. You're like no, hang on a minute. Either step back and rethink that or walk away because you're probably not going to be a great product manager.

Maggie Crowley: Let's say we don't know what we're doing, and we are totally agnostic to tools. We're falling in love with the problem. We've nailed everything. What are the big changes coming in product management? What's next? What's the new thing that we should all be paying attention to?

Martin Erickson: So I think the role is still evolving. I think how we're doing stuff is evolving. And I think, again, we need to be open to that. And that's why I'm passionately methodology agnostic because I think it's more an approach and more a way of thinking about problems that is important. I think the trends that I'm seeing though are definitely this kind of move towards autonomy and self- organized teams and co- located teams. And the best startups are doing it this way, the best bigger companies are doing it this way. I think we're seeing more and more proof that these mission- driven, vision- driven companies organized this way are going to be the most successful. I think most recently we saw Pluralsight go public just a few weeks ago at a$ 3 billion evaluation, proving that their mission- driven approach around autonomous teams, and they've done it at relative scale, they have a thousand staff, Nate, my co- author's team's about 700 people. And they all work in this way. They all work in autonomous teams. They're co- located. They're doing constant customer discovery and it works. So I think that's one of the big things that you guys are already on the leading edge of, but a lot of people are not. I think the other trend that we're seeing is trying to figure out how product and engineering and user experience actually fit together. Peter Merholz once said at one of my conferences that user experience as a function only exists because product management isn't doing its job. And I think that's probably fair that before that, or old school product management was very much a business- led function. It was all about that bottom line. It was all about ROI. And how do we prioritize? And I think modern product management has definitely taken on a lot of those UX things and done other things as well. Great UX designers are some of the best product people because they have a bigger picture thinking anyway. So it's not about one is better than the other. I never really care about people's titles, but I think as we organize our teams and as we organize our companies, it's important to think about how do those things work together? Is it actually one whole product experience team, whatever we want to call it, that actually works together, who actually sits at that management level? Is it a CPO or chief design officer or both or CTO or all three or is that one team? I think those are the things that we're still trying to figure out. And again, Pluralsight's one of the best examples I think, where they actually promoted Nate from chief product officer to chief experience officer, where he owns that whole function. So he owns experience and product and engineering as one function because, at the end of the day, they have to work together. So even if we are separate teams, we have to treat it as one team.

Maggie Crowley: What's your big prediction for the next... In 10 years, what does the product role look like?

Martin Erickson: I think if I knew that answer, I would have written another book about it. And I think going back to my earlier point, if I felt like I knew that, I should probably give up.

Maggie Crowley: Right, then you fall into the trap, and you should give up.

Martin Erickson: I've fallen into my own trap. So I don't know. I hope that we have figured out a lot of these basic things. I hope that a lot more teams are working this way. I hope that we can stop talking about who owns the user and what methodology we should be using and actually talk about the important things, our customers and what we're doing and how we're impacting the world, and how we can make it a better place and all those very lovely high- level goals that I'm sure we would all rather be focusing on.

Maggie Crowley: Definitely. So thank you. I really appreciate you coming on the podcast. One last question. If you had to give our audience three pieces of advice that they can go back to their teams right now and implement, what would they be?

Martin Erickson: Show, don't tell, and start small. Find some little feature, find some little area of the site that you can improve or product or whatever you're working on, that you can improve using this way of working to prove why it's valuable. That'd be number one. I think number two is actually pull someone else in. So if you're a product manager, pull an engineer with you the next time you have a conversation with a customer. If you're a designer, pull the product manager with you or the engineer. Whatever it is, pull someone else along with you because they will have their eyes open by what it is that you're experiencing, and they'll also return the favor. So they'll pull you into one of their conversations. And the more that we can do that, the more you're going to be introducing this cross- functional way of thinking. And then I think the last piece would just be figure out how to align yourself with your team and with your customer. I know that's really hard sometimes when you're in the team to get that done but the more that you can think about actually changing your goal or having the conversation about where your inaudible should be or how that process works in your organization, to make sure that the whole teams are aligned around the same thing and that that is actually a customer goal and not a company goal. I think that those would be my top three things at least.

Maggie Crowley: Awesome. Well, you heard it here. Show, don't tell. Fall in love with the problem you're trying to solve and just talk to customers as much as you possibly can. So that's it for today. Thanks again, Martin. I hope you all enjoyed this episode of# Build on Seeking Wisdom. Give Martin a shout- out in the reviews. Six stars only as usual. Also, let me know what you thought, what else you want to hear. You can always reach me at Maggie @ drift. com, or we have this new voicemail where you can call in and leave a note at 8- 8- 8- 41- DRIFT. So call in and let us know what you think about our new channel, what else you want to hear, or who else I should get on the show? Thanks.

Martin Erickson: Thank you for having me.

Maggie Crowley: Thank you.

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