How to Turn Advice into Action with Whoop's Ben Foster

Maggie: Welcome to Build, this is Maggie. Today, I have Ben Foster on the show. He's the chief product officer at WHOOP. He's also the coauthor of a book called Build What Matters, that's all about building great products with customer- centered product visions. And we get into what it takes to actually put a framework that you might learn from a book into practice at a company. There is, of course, so much advice out there, including on a podcast like this one, about how to build products more effectively. So I wanted to talk to someone who had gone deep on both. I hope you enjoy it. Ben, welcome to the show.

Ben Foster: Hey, it's so great to be here. Thanks.

Maggie: So, we're going to get into something that I think a ton about specifically with the show, which is how do you actually put advice into practice? But first, I wanted to start by grounding in a specific type of work that a product leader does and that's product vision. So, we're going to use that today as our example, it's also something that I know comes up a ton when I'm talking about strategy or about motivating teams, a lot of which ends up falling on the product function. So you wrote a book effectively on the topic. So in your words, what is a product vision, and what role does it play in building products or in the product development process?

Ben Foster: Yeah, sure thing. It's something that a lot of people are really confused by, because it gets conflated with mission statement, it gets conflated with strategy, et cetera. And I think of a product vision as really laying out the future customer experience that you're looking to create that will hopefully give them a 10X outcome from what they've been accustomed to historically, something that's really bold, something that's very forward- looking, but most importantly, really rooted in the customer experience.

Maggie: What is the difference between a vision and a strategy?

Ben Foster: I've always described it this way. I think of the vision as like planting a flag at point B, where you're standing at point A today and you're saying," Guys, this is where we're going to go. This is what we're about. This is when we're going to know that we arrived at the destination." The strategy is more like the path that you take to get there, given the realities of the business and the complications that you sort of have to overcome along the way. So, for example, maybe a vision is, we're going to apply artificial intelligence to go solve some new problem in a particular space that has been somewhat antiquated for a while. And that's all great, but how do you go about creating this AI solution? You're going to have to have machine learning. You're going to have to have a training data set that's going to allow you to get that there. Where are you going to get that data from? Maybe you need to get funding along the way. How are you going to demonstrate to investors that you're going to actually get the traction that you need at those different stages? So, you may not take the most direct path to get there. And I see the strategy is like those critical milestones, those markers that you need to get to along the way, but that you have confidence in that if we do these things, it will in fact actually get us to the vision that we've set for ourselves.

Maggie: Because I wanted to ask that because it often seems to come hand- in- hand and there's sometimes confusion between what is the mission that we're on and then how do we get there? And what are the choices that we're making wrapped up in between both of those? I think it's helpful to understand this, in this context, what the distinction is. So then, my next question would be who sets them and at what level? It's a bit of a leading question, because I know, I'm assuming that you would want to have sort of a team- wide product vision, but then there's also, if your product is big enough, sort of sub- teams or sub- areas that you might want to have some kind of flag- planting moment. I'm just curious, when you think about it, are there product visions happening at all levels? Is it really just supposed to be at the top level? How do you think about that?

Ben Foster: It's interesting, because I've had my own journey of coming to understand this, I think, over time, as I've evolved my own career from being an individual contributor to being a product leader. It was really interesting this transition that I had, because I wrote a book, Build What Matters, which is really about articulation of a product vision, and then making sure that people are actually adhering to it. What I assumed when I started writing the book along with my co- author, Rajesh, is that it all really applied primarily and almost exclusively at the top level within product or, in some smaller companies, where the head of product is, in effect, the founder, the CEO, that it applies really primarily at their level. What I've come to understand, I think, in working at a larger company, is that if you do a really good job of establishing the right vision and providing it at the right level, you ideally create opportunities for individuals within the team to establish their own vision for the part that they own as well. It's almost like an indication of success in the organizational structure that you've created that capability for those people within the team to establish their own. Where, I might come up with a vision that says," At WHOOP, part of what we're trying to do is to foster community and to allow people who are fellow WHOOP customers to connect with one another and learn from one another, et cetera." So, that could be a big part of the overall vision. But if I stop it at the right level and I don't go too deep with exactly what that's going to look like, then I create the space for the product management team, that's responsible for that community strategy, to then come up with their own vision of what that looks like and how the different kinds of pieces fit together and how they can craft that customer journey that they're looking for down the road. So, I think it's a bit of both.

Maggie: So, we talked about this a little bit before we caught up, but the question I kept coming up with in my head was where do they stop? And I think what I'm trying to get at is how do you maintain or foster that autonomy on the team level, but still have what they, especially, if you're a big company, there's multiple teams with maybe multiple visions, how do you make sure that you end up building a coordinated product while still having these separate visions? Because I would imagine, it doesn't sound like what you're doing is sort of reading every single vision and making sure it's exactly what you want, unless that is how you do it. But I'm curious, how do you think about that part?

Ben Foster: I think you're totally right with the stopping point really mattering a lot. Maybe another way of framing that is like, what's the level of granularity that a vision should go into? If it's way too specific, then you give no license for creativity or the ability for there to be autonomy for the teams. It's kind of like," I've already told you exactly what you need to do, now just go do these things." What I see most companies doing is not necessarily that, I see it actually in the other side of the spectrum, which is that there's just too little clarity that's there. So, usually it's not the problem that there's too much clarity of vision. So, there's not enough, or they'll think that they've stopped, because," Well, we've already defined our mission statement. So we're good on that front." And it's like, take Google's mission of like, do no evil or values, statements like that, that are so subjective and open to interpretation that the reality is different kinds of people within the team could go completely different directions. And the example that we use in the book was, we imagined what it would be like at Tesla if Tesla, their mission was like," We're going to make it so you don't have to go to a gas station anymore, when inaudible your car." Okay, that's cool, but there's a lot of different ways you could try to make that happen. Are you trying to make a nuclear- powered car? Are you trying to make another system that can gas your car while you're driving? Are you trying to build a battery that lasts forever? And I think that if everybody is on the same page about exactly how you're going to go about making that happen, that's really important, because then you can subdivide it into different teams and not have a bunch of different teams all thinking about what they're trying to accomplish in radically different ways, because that misalignment can cause a lot of problems. So, I think that it needs to be specific enough on the one hand, but it also needs to be not so specific that you create the space for the people who are closest on the ground to come up with their own perspective and to share with the rest of the business what they believe is best. Because they're the ones who are closest to the technology. They're the ones that are closest to the customer. They're the ones who are in the trenches having to deal with the technical debt that's out there. They're the ones who have the capacity to understand the stakeholder needs and how they all fit together. So, hopefully, you create that space for them to come up with their own stuff. But it means that you have to have the right level of detail around that. The analogy that I've used on this inaudible was I always think about fighting a major war or something like that. I can think about World War I or something, and I'm like, there's all these generals who are looking at maps and they can think strategically about like," We've got to go take this city. We've got to go take this bridge. It's a really important thing for us to go do." But if they just assume that their map gave them all the perspective that they need, they'd be totally missing what's actually happening on the ground. And it's like," Hey, it's only half a mile away. Why don't you just go do it?" And what they're not respecting is that this is like no man's land and if you pop your head out of the trench, you're going to get shut off. So, it's kind of like what you need to say is," Here's what I need to do. We need to go take this bridge or the city, but I'm not going to tell you about how, you're going to tell me the right timing to make this happen, et cetera, but it's going to happen in the next week." And I think that ideally the communication channels from the top of the command down to the bottom of the command are such that everybody understands what's needing to be accomplished and why, but you're giving the ability for the team to be creative and thoughtful about what they need to do at the same time. It's a hard inaudible, but it's the thing that we all try to get right.

Maggie: The thing, and this sort of gets at the heart of the matter, it's one thing to say," Set the mission for the team to go take the hill." And I think that's... I've heard that before and that's certainly how I think about it too, but it's another thing to sit... And then, let's say, you go to the team and you say," Okay, we're going to go take this hill." And then the team says," Well, we want to decide which hill we're going to take. Why don't you just give us the outcome you're looking for?" And this is the thing I run into, which is a team thinking that outcome- based product development means," Just give me a metric," and let's ignore growth teams for now, which I think is a more straightforward answer or example, but a regular product team, they want to have an outcome. But you're also saying like," Yes, this is the metric that we care about," or how we're going to measure whether we've taken that hill? But this is also the specific hill that we think is important. So, how do you balance that... How do you articulate that to your team and help them understand that that doesn't mean that they're not autonomous?

Ben Foster: That's a great question. And my response to it would be that, I think there are a lot of considerations beyond just hitting a certain metric, if it was just hitting a metric, that's what a sales team does. And they're like a mercenary in a lot of ways, to just find a way of hitting a particular target. It also means that you can be mercenary back in terms of like," I'll fire you if you miss it." And that's it. It's very measurable, it's very tangible, ends justify the means to some extent in a lot of ways for getting there, with rare exception of maybe making commitments that the product team can't actually support and things like that. If you actually sell the product as it is, sales people are not measured on the impact that they have elsewhere in the organization. And I think that when it comes to product, there's so much more to it than just merely hitting a metric. A great example from WHOOP is that our founder is extremely specific and thoughtful about the brand that we're trying to establish, and the commitments that we want to be able to make to our members, and the meaningfulness of the investments that we make into product. It's not just," Here's a retention target, and I want you to hit it." It's like," I want to hit it in a specific kind of way that's consistent with and complementary to this vision that I have for where the company can really go." And I think that that's helped to guide a lot of decisions that we have, but it also makes the product management role a lot more nuanced, I think, than it is for other organizations. And I think it's one of the things that I love about product is that reality. But I think we have to embrace that as product management to ensure that we are respecting the fact that there are several different ways of hitting a target, hitting a metric, and that they're not all created equal. One of them may offer far greater extensibility than another one. Another one may be more lower risk along the way. Another one may be more measurable along the way. Another one may be done in such a way that it creates a differentiation or competitive advantage, where another one doesn't. So, that's why it's so important that we actually have these theses around the direction that we want to go with product, because then it allows everybody else within the team to understand how they're supposed to go about hitting their targets, the constraints that they need to operate within, et cetera. And I think often I've actually seen it generate creativity. And I think we all kind of have learned this probably the hard way where it's like, constraints actually yield creativity, where you think that in theory they wouldn't, they actually do.

Maggie: But part of what I'm hearing is that you've also spent the time to articulate to the team why the choices matter. I think that's maybe what I'm starting to realize or what I'm hearing in all these conversations that I have, it's that if you spend the time to help the team understand why you got to where you got, and why those are the right choices, and why that choice or that constraint is meaningful, whereas the other ones aren't, that that's what helps them... It gives them more context around why that mission is the mission and then helps them be owners, I think, in that outcome. I think maybe what I'm seeing is that when it doesn't work, when a team doesn't feel autonomous or ownership over it, that it's because they don't understand, or they don't have any of the backing information and they didn't go on the journey that you, as the leader, went on to actually figure out what that hill is.

Ben Foster: I think that's right. I mean, that's why communication is so important. That's why documentation is really valuable as the company continues to mature. Maybe you hire somebody who wasn't there for the all hands meeting in which you reviewed this three months ago. Yet, they're being asked to follow suit with this thing that they weren't there for. So, I think that the way in which you operate is to ensure that there is that regular communication and discussion about this stuff, that you have opportunities to answer clarifying questions along the way, et cetera. Rather than those meetings becoming approval meetings for designs and things like that, they turn into working sessions where you're helping to ensure that the direction that the team wants to go, as they're trying to hit their metric, happens to conform as best as possible to the direction that we're trying to move as a company.

Maggie: Let's say someone's listening and they want to know how to do this whole process better. So, you had the unique experience of working with tons of different companies as an advisor, writing a book and then going and being a CPO. And now, I'm assuming, you have to kind of put your money where your mouth is and actually do the stuff that you wrote in the book. So, how did you approach actually taking that sort of perfect world advice and putting it into practice at WHOOP and what was your strategy for operationalizing that?

Ben Foster: It's such a funny story, because I definitely felt this in spades. When I moved from being this adviser and this author into kind of going back into operational function, in product, because of course you know you're going to run into the realities. And as an advisor, it's really easy to say," Oh, the advice that I've been giving you the whole way through has been perfectly sound entirely, but the reason you're failing at implementing it or whatever, or the reason that it's not going as well as you'd like is because you're obviously doing it wrong," or whatever. Because I don't have the visibility into it. I think the reality is, it sets home a little bit when you take that full- time position. So, certainly, I felt the pressure of," Hey, I wrote this book. I damn well better put everything that I wrote about in place at the company that I'm at, otherwise, what does that mean about what I wrote?" And I think it took a little bit of a combination of, well, kind of an awkward combination of confidence and humility to recognize that there are certain things that you write about that then maybe don't apply in a specific situation. So, there's a couple of cases of that where I thought," Okay, this is definitely the way that every company should approach something." But of course I started to identify some of the uniquenesses of working at WHOOP and realized that some of those kinds of things, while the principle may be sound, the actual application of it needs to be adjusted a little bit. I think that, that's okay. It took me a little bit of time to reconcile that, and to say,"It doesn't mean that what's in the book is necessarily wrong. It just means that you need to interpret it for the environment in which you're in." And I've certainly had that experience time and time again. One of the good examples of that would be, like I said, at a lot of other companies, they don't have enough clarity of vision. I think that the book covers primarily that case. Then, I walked into WHOOP where there's an exceptional amount of clarity to vision. And in fact, there's so much clarity of vision that maybe it's a little bit of the opposite problem of how do we create the space for some of that creativity within the team to ensure that they're not just taking orders in terms of the direction that we could potentially go, but that they're empowered to identify new opportunities that we should be considering exploring as well. What are those Hills that we should be considering taking? It's an interesting mix of trying to blend both of those methods of working together at a company like that. That's been my experience so far. So, it's been an interesting one, I'll say that. And I'd say the other one that's been a little bit challenging for me has just been the realization that it just takes a lot of time. A lot of things that are described in the book are things like," Oh, spend the time to go craft the vision and document it and do the customer research that's necessary." And it's like, yeah, those are all great. But also the day- to- day work doesn't really go away. It's not like the bug doesn't get filed tomorrow anyway. So, you still have to be responsive and reactive to the needs of the business along the way. And that's yielded some long hours and things, but it's something that I think will pay dividends down the road as well.

Maggie: I love that sort of approach. I always think about each of these tools or frameworks as something where you need to learn, not just the why of it, what it is, and what topic it's for, but also under what context is it the appropriate thing to use. So, I think that's what I'm hearing you say, is that I have this whole body of work that I put together, and then the question is, what's what context am I in? And which pieces of this do I want to use? But I would imagine that you'd have to have a really deep understanding of the framework in order to figure out which pieces of it you want, because if not, you could be one of those product people coming in with a system of working that they're using like a hammer that everything always has to fit into.

Ben Foster: 100%. I see this happen all the time. In fact, I was thinking about doing a talk, a presentation, where I took two very smart products thought leaders and showed the headlines of their articles that they published side- by- side, where they're literally saying the exact opposite thing. They're probably both right. I think this is kind of like, I don't know, I'll call it the thought leader's dilemma, I guess, which is, on the one hand, you could be very high level, and vague, and theoretical about your recommendations, so that it applies unilaterally to everybody. But then it becomes so abstract that it's like,"Well, what does that mean?" There's a great... You should be... It's like," We should empower teams." That's great. But what does that mean for me at my company, given the people that are there and the personalities involved, and the history, and the speed at which we're moving, and things like that? So, on the one hand, you could be very broad and probably very correct, but also not very actionable. And on the other hand, you could be highly actionable and say," Here's a very specific methodology that I used when I was at this particular company. And it worked really, really well. And I want to make sure that everybody else does this at the same time." But then you're running the risk that it doesn't actually apply at the other company. The case in point of this would be like, once I interviewed a product manager who was coming from Facebook and I was like, effectively, the question was," How do you make decisions about what you're going to build next or what you're going to go create next?" And they're like," Oh, it's really easy. All you do is you take a huge army of engineers and you just go build a bunch of A/ B tests and you run each of these A/ B tests for an hour, because in an hour, obviously you'll get all the data that you need, et cetera, and then you'll know exactly what you need to do." And I'm like," Well, that's great when I actually have an army of engineers that I have access to. Also great when I have enough data points because the engagement of the product is so high that I can see within an hour what's going to work and what's not going to." So, yes, you could make your decisions as a product manager in your particular arena by doing it that way. But how would a B2B2C enterprise company apply that same principle? It's just utterly irrelevant for them. And the irony was, I was at a B2B2C enterprise company. So, it was like, the person fails the interview because they're just so accustomed to working in this one particular way. So, I think, as a thought leader is really challenging because you want to give something that's broadly applicable. I don't want somebody to read it and then apply it and have it totally backfire on them. But I also want to make sure that it is actually applicable on the other hand. I think that that was what we tried to be aware of in writing the book and try to put it out there in such a way that it could be approachable and understandable by people, something that they can put in place, but not at the same time so specific that it was likely to backfire in specific situations.

Maggie: I think that's part of the reason why it's so, I don't know fun is the right word, but that's a topic that comes up all the time between visions, and roadmap, and strategy, because almost no matter where you are, what company you're at, there's going to be some kind of vision, you've got to have a strategy, you need to figure out what you're going to build. So, we can at least talk about those topics more broadly as, okay, these are all the things that we all know we have to do. And then the question, I think, where it gets really tricky, to your point, is how you make a choice is where it starts to get really hard to generalize, because it's dependent on your business and your strategy. Someone I was talking with, a VP of product at Productboard the other day, and we were talking about your investment strategy between tech debt, and evolving your product, and transformative. And it's like, someone could ask you," What's your balance between... What's your portfolio strategy on your product team?" But it would be completely different depending on your company's stage, your size, your market, your competitors. So it's like, I can tell you what I'm doing, but without spending 20 minutes explaining my business strategy, it's not going to make any sense.

Ben Foster: I totally agree with you. Yeah, exactly.

Maggie: What do you think is, when you're talking to your PM team about this kind of thing and about how they can become product leaders and how to think about these tools, how do you help them understand when is the right moment to do something like a product vision? How do you help them think about," Okay, we know we need to have context, it's going to be specific to the company that you're in." What's your advice when you're thinking about how to mentor that team?

Ben Foster: Well, I try to be really clear about what we know and what we don't know, and where we need to have more clarity. So, for example, sometimes the clarity might be at the very basic level of what are we working on next? Just give me a roadmap. And what happens is, just like with anything else in product, you can ask why enough times, and it exposes where the gap actually exists. As you move up the stack by asking why, you'll say like," Well, why are these things on the roadmap and the other ones are not?"" Oh, well, because these are the issues that we're seeing with our customers."" Okay. Well, why are you prioritizing these issues over those issues? Why is this the problem that's most important for us to solve?"" Oh, well, because, strategically, we need to arrive at this particular milestone within the next 18 months."" Okay, great. Let's document what all those kinds of things look like." And then you can say," Why are those actually the milestones? What's the end point that we're trying to get to here, that these are all ultimately accruing to? What is our differentiation? What is our vision for that better customer experience, that better customer journey that we're trying to create in the future?" And as you continue to ask that question, you realize where those missing elements actually are. What I've found to be really interesting, at least at WHOOP, it's been really helpful to approach it in that direction rather than the other direction of saying," Let's all hit pause right here." We're just going to stop our work, and we're going to say," What is the major problem that we're trying to solve in the market, et cetera?" And part of the reasons that I'm afforded the ability to do that is because we've already arrived at product market fit. So, that's a good example of a case where this is the approach that makes sense at the company that I'm at, given the stage that we are in, but I wouldn't necessarily recommend that for a 10- person shop that's working out of a garage, where the founder is still the head of product. And they're still trying to figure out their way and even find their first customer. Maybe they need to approach things in a little bit of a different way. So, that's the way that I've been approaching it with enabling my team to come up with these things is I challenge them on the decisions that are getting made. Not because I'm pressure testing their ability to do their job. And obviously you can evaluate things along the way. But the real reason is because I want to know at what point there is no longer an answer to the question of why. That exposes the need for there to be some sort of strategy definition. The organization that I'm running right now, it's a pretty large organization at this point. So, we have levels of hierarchy and things like that. I think that depending on where that answer falls short, that's where we can identify who it is that we need to hold accountable for answering that question of why, is that my head of product management? Is that a director of product working on that team responsible for a particular area of the product? Or is it an individual product manager who has a responsibility for a very specific area of the product, but that we still need to have really good answers within that individual arena?

Maggie: I really like that framing or at least what I'm taking away from this as it being a good thing when you find that why and not being like a," Gotcha, I found out where you went wrong." But it's more like," Oh great. We finally," and I think, especially in a big org and I've been on some scaling journeys in our org, when the bigger it gets, the harder it is to figure out where the breaks are. And then I think it's almost, as a product leader, it's my favorite thing when I can find one, it's like, now I can finally help, because now I know this is the place that we need to focus, and this is the place where we don't have the data or we're missing a connective thing.

Ben Foster: Yeah, that's right. It's almost like internal discovery. You're kind of always doing this, it's a continuous discovery, Teresa's book, Continuous Discovery Habits, and it's like, that applies both externally with your customer base, but I think it applies as a head of product, doing that discovery within the company to say," Wow, you've got this whole thing mapped out. This is awesome." Now, this is a matter of execution. And if you've got it really clarified, maybe what I'll do is I'll make sure that the hiring plan inaudible up more in your area, because I know exactly what kind of benefits I'm going to get from this. And I'm really sold on the direction that we're going to go. And in other areas I might say," While I'm really excited about area that you're working on, I need to see results first, or I need to have more clarity as to where we're actually going to be headed before I decide to invest further into that particular arena." My lever, as a head of product at WHOOP, given the scale that we're at now, is for the most part, it's actually the hiring plan. That's in a lot of ways where it stops. It's like," Let's go invest more here and let's go invest less here." That affords them the ability to think about the direction that they want to go and come up with those answers for themselves. But they're only enabled to do that because they actually have a job at WHOOP. So, the first initial decision is, who do we even give jobs to? What jobs need to be created? So, you might even create an entire category of product development that didn't exist before. That's where I sort of finish and sort of stop, to your earlier question, on the vision. Then from that point, you hire that person. You say," Okay, I want you to get grounded, hit the ground running, go deliver a few things, really start to learn about what the customers are looking for on this front and now I'm going to look for you to show me what you believe that you can do and what the opportunities look like, given the area that you own."

Maggie: So, a little bit along these lines, I'm curious, speaking of career development and getting better and thinking about different roles. So, you wrote a book, obviously, we talked about, and I'm curious, is writing part of how you... Or one of the things that you recommend to your team as a way to help grow in their career? How do you think about career development, especially at the higher levels? And what role does that kind of work play?

Ben Foster: So, I haven't explicitly told anybody," Hey, I think you should write a lot of this down, or publish it as an article, or write a book," or anything like that. It's a really taxing process, I've got to say. Am I really happy that I did it? Yes. Would I go do it again? Probably not. It was a very helpful thing for me to write things down though. I think that this is so true with product in general, you're talking about anything in the abstract. It's really easy in your own head to think that all these things make sense. It's in the practice of trying to communicate it to somebody else that it forces you to reconcile some of the gaps in your own point of view. I've always used the analogy of, it's like recounting a dream, you wake up in the morning and you're like," Oh, I had this dream, and I'm going to tell you about it." In the beginning you're like, it totally makes sense. It's only as you're describing it. You're like," Actually I don't really know how I got there, but nevermind that. Then it transitioned to this other thing. And I don't really know that that makes sense. But anyway, now it was like 10 years later," and you're going to like," Wait, what happened there?" And I think the same thing is true in writing anything down, whether that's a product strategy, where it may make sense in your head, but then you write it down and you're scratching your head along the way. And you're like," Oh crap. Actually I don't really have a good answer for how we would go from here to there. I guess I have more thinking to do on that front." So, it's helpful because obviously you can share with others and that's a lot of the reasons that I decided to write the book. But the real benefit, I think, came for me personally, in that, as I had to describe things, I had to deal with the reality that some of these ideas were half- baked. And it forced me to think about how I can further bake them. I think it just made me stronger in terms of doing it. And I think that that was probably one of the best career development activities for myself that I ever really had, was forcing myself to put these things down on paper in such a way that I knew it could be scrutinized by somebody else. You hate to get some sort of a two- star review on Amazon, because somebody's like," Nah, this doesn't work, he's wrong." Or," I didn't agree with the sentiment." So it forces you to have to think about that. And I think that that kind of accountability for producing something that was high quality was just really helpful for me, because normally I don't have as many forces applied to me about upping my own game when it comes to product, other than obviously just business outcomes in my role today.

Maggie: Yeah. I think about that a lot. Every time I do a conversation like this, it's a chance to say," Okay, well, can I actually articulate what the heck I've been doing for the last several years, and in any way, articulate how we take on a topic?" So, yeah, I think it's been inaudible, but I'm always curious to hear from other people who have done it, if and how it helped them. So, my last question, you have seen, I took a spin through your LinkedIn, which is quite long with all the companies that you've been an advisor to. So, I wanted to know what are the top mistakes that you just saw product teams falling, like the traps they fell into over and over again, if you could say, just to all product teams, just don't, whatever you do, either do these three things or just don't do these three things. What were those themes?

Ben Foster: It's funny, actually, the first chapter of the book is The Top 10 Dysfunctions of Product Management. And it's honestly taken from a lot of my experiences, either in operational roles myself, that I've seen things go awry or things that I saw through some of the advisory work that I was doing, et cetera. So, I've definitely seen plenty. The few that I usually pay the most attention to, and that I think are very typical, but also very problematic in product companies, and in technology would be, number one is, there's so much focus these days on product management moving into this direction of science. It's kind of like, everything should be measurable. We need to see the results from every little thing that we do. And there's this very cool mentality of fail- fast, but it can also metastasize into something that's actually really bad for a company at the same time. And that's where you try to only do very super lightweight, superficial improvements to the product, because you're trying to get very quick wins that are demonstrable and measurable. And a lot of times what happens is it actually takes you in literally the opposite direction as you should be going with your product. It's like, you focus on things like," Well, if we round the corners and we run it as an A/ B test, did we get 0. 01% more people through this flow?" It's like, that's all great, but have you delivered any additional customer value in doing that? Are you actually innovating on your customers' behalf? In the end, the clear answer is no, but that's where it's easy to measure outcomes. So people focus, it's almost like the tail's wagging the dog, where you focus on showing measurable outcomes, which almost takes you away from focusing on the things that actually matter the most, which is really delivering customer value and then deriving your own value back as a function of what you're doing there. So, I see a lot of companies that are investing in optimization, thinking that they're innovative, and they're actually doing exactly the opposite of innovating. The example that I've used on this for any non- product people maybe listening, it's like if you have too short of a timeframe that you're paying attention to things, you're going to make really bad mistakes. If you want to lose weight tomorrow, the best thing to do is not drink any water. inaudible tomorrow, but you can't do that for a year. And in fact, it's actually the opposite, if you wanted to lose weight over the course of a year, they would advise to drink a glass of water before every meal. The whole orientation just completely flips. And I think that what you see is a lot of companies, where they're effectively not drinking water and they're focusing on these totally inappropriate things, thinking that they're innovative and they're really preparing themselves to get overtaken by some new competitor working in the garage that they've never heard of before.

Maggie: Before you go to the second one, I love that example, because it's also so much harder to articulate to someone in your position, why a different type of project is the right one. So, I think that's what's hard about it, is that it's easier to say," We're going to get a 10% lift on this number." It's much harder to give you that full chain of whys around why a bigger investment in a different thing you maybe can't measure as well is going to be the right thing to do. So that's the sort of interesting paradox that I see is that, yes, you want to do the other stuff, but it's so much harder as a product person to articulate why that's going to be the right choice.

Ben Foster: Yeah. I mean, that's totally right. It's almost like it's a function of laziness to an extent to just say," We're just going to do these things. Because I know that I can get some quick wins out of it." And I'm not saying that you shouldn't do those. There's a reason that growth hacking and everything else exists. You should be optimizing the business. But don't make the mistake of thinking that pure optimization is somehow going to magically yield innovation. So, I think that's number one. I'd say number two is when companies then try to solve this problem by being visionary, they articulate a vision that's so internally focused that it's like, they kind of forget about the customer along the way. So, as an advisor, I would often have these early meetings with a founder and I'd say," Why don't you take 20, 30 minutes and walk me through what this company's all about? Tell me about where you're trying to go, what you're trying to get done." And every single one of them, this is when their eyes lit up, they get to the whiteboard and they're like," Ooh, I get to tell my story and what I'm all about and stuff like that." They would articulate these visions that were things like," We're going to get to$ 300 million of ARR by 2024." Or they'd have a vision like," We're going to upend this industry by applying machine learning in this new way that it hasn't been before." And I'm like-

Maggie: It's always AI.$ 17 trillion in revenue in AI?

Ben Foster: Yeah, exactly. It's nice to know that the TAM is there, that's great. But TAM is not a strategy. TAM is not a vision for where you're headed. And I think that what I always challenged them with is to say," Look, nobody disrupts an industry directly. The way that an industry actually gets disrupted is you solve a customer problem that's existed in that industry so well that customers can't even fathom the idea of going back to the way that it previously was. But at the end of the day, it's rooted in solving a customer problem." And my question to them always is like," What's the customer problem you're actually trying to solve? Why are they underserved right now?" And it is amazing to me how few product leaders, founders, et cetera, can actually articulate it in that way. It's like," Here's what we're going to do." And it's like," No, no, no, here's what you're going to enable your customers to do." And that reorientation is just so critical that I think that that's a big mistake and it just has a lot of downstream effects in its own. So, that's the second one that I would call attention to. Do I need to give you a third one as well?

Maggie: No, those are two good ones. Yeah. And we're also totally running out of time. I'm going to have to think on that last one a little bit. I absolutely agree and it's so interesting. I can just think of so many examples in my past where we probably got that framing wrong, or we even started with the customer framing, but then internal problems just start to pull you back and then you're optimizing for what the sales team wants, or whoever. Then, you have to constantly shift yourself back to that mindset and be like," No, we have to be grounded in the customer problem."

Ben Foster: Totally. Board meetings do it as well. It's amazing. I've served as an observer on a number of boards and I've always been shocked by how little that conversation ever comes up. It's like," Why did we miss the sales numbers here? Or why is the retention number what it is there?" And things like that. But there's nobody who's asking the question of like," How do we know that we're working on the things right now that in two years are going to solve customer problems in ways that are going to make this company completely different? Show me what kind of customer success metrics look like and let's see a dashboard of that." And I think that when you're not pressuring the company in that way, it's like the company has to pressure itself that way to provide that. That's, in a lot of ways, I think, the role of the head of product.

Maggie: Well, then that is a perfect place to stop it. I really appreciate you taking some time to chat and to share your wisdom of having met many product teams and actually putting your words into action.

Ben Foster: Awesome. Thanks so much for the opportunity. Great to be on the show. It's a really great podcast and I love that you get into the weeds of the reality of how this stuff actually comes together. So, great stuff. Thanks so much, Maggie.

Maggie: That's right. Thanks, Ben.