Ibrahim Bashir: "Steering through Strategy Spirals" | LPC Madrid 2022

Hola. Thank you, everybody, for joining us this evening. I'm here to talk about strategy and strategy spirals. I find when you're talking about a topic, it's best to jump right in. So is my clicker working? So a strategy spiral is kind of like a mystery for product managers, and I find the best way to tackle a mystery is to jump right in. How many people use Twitter? Show of hands. How many people use Twitter? Okay. No more than 50%. How many people use Twitter to talk about product management? Okay, if you guys are reading this tweet, I saw this tweet on Twitter a couple months ago. It's a guy who's working on an API product is trying to actually define what their North Star metric is. Leadership team only cares about revenue. And you don't actually know what your end users of your customers are doing. I thought this was a very mysterious tweet. I don't know if this guy is trying to solve his day job or he was just curious, but that's the problem we're going to try to solve together for a few minutes. So first clue from this tweet is customers do stuff, but you don't know what they're doing. And this is part of the puzzle. The second is, clearly the leadership team cares only about revenue. This is going to be very important as we try to solve this puzzle. I'm curious, have any of you ever been stuck trying to define a metric? And the leadership team only cares about revenue? Yeah. Show of hands. Okay. It's a common problem. It happens. So if we go to the next problem, you see people on Twitter trying to answer this question, and they're trying to change the constraints of the problem. So they keep trying to figure out, hey, how do I get out of sort of being responsible for the revenue? How do I figure out what the data is being used for? But the first rule of solving a product mystery is you have to respect the constraints. So the constraints were clearly laid out. People are now trying to change the constraints. Here's another example. Why does leadership only care about revenue? Why is that? You're asking these questions, but the reality is the rules have been established. Right? The second point I want to make is making sure that what you're doing connects to revenue. Either making revenue or preserving revenue, that's a very reasonable expectation for a leadership team to have. What can be frustrating for us as product managers is, hey, I don't want revenue to be my metric. I want my metric to be something that I control. But it's not unreasonable to say, make it connect to revenue. So anytime these people on Twitter are saying, why revenue? You're kind of missing the point, which is that's why we have a business. Here's an interesting one. This guy says it has to be API calls. He's like, why else would you be able to connect to the value that you're using? And he's asking, why does leadership not care about users? Here you're making a value assumption. The person is deciding that usage is how people get value. But when we're looking at this mystery, at no point were we told that's actually the value that you're providing users. But he brings up an interesting point. He talks about doing research either directly with customers, with users, or somebody in between, maybe a sales team, maybe a support team, to actually figuring out what the value is. And again, when you go back to this mystery, the important thing to keep in mind is defining a metric is very different than figuring out your long term research. Those two things are connected, but you can treat them independently. Here's another answer on this. My North Star metric would be the number of daily active users. My North Star metric is number of signups. Also retention, also lifetime value. How many people have done this where it's like, let's pick a metric and then you pick five metrics that all sound good. Anybody done that? It's hard, it's really hard to pick one North Star metric. But that's what a North Star metric is, a single thing that you're going to rally behind as a product team. This guy has an interesting idea. He said, how does the API make revenue? He says, Northstar can be revenue, but you could have a proxy metric that connects to how the business model actually works. This is a really interesting idea. A proxy metric is something that you can control and drive as a product team. And all you have to show is long term, it connects to revenue or whatever Northstar leadership cares about. It's a way for a product team to actually regain some control. If I go to the next slide, one of the things I'm reading this in real time. I'm going through this journey with you. One of the things as I was reading this was you want the business model to connect product usage and revenue. So I think part of the solution here is going to be how do we connect these two things? Oh, here's another clue from the guy who started the question. Let's assume the product is sold on a two year contract basis with unlimited usage. Okay, now this guy just broke my Brain. So. So it's unlimited usage, two year contract. It doesn't even matter how usage fits in. So now I have to completely rethink this problem. I don't think revenue and usage connect in this scenario. Let's try again. I also think whatever the business model is probably will need to change long term. So we'll come back to that part of the mystery. Time to first successful API call. Okay, interesting. But we already established that usage doesn't matter, right? It's a two year contract, unlimited usage. So this guy is trying to push a metric that doesn't actually make sense. Here's another example. If revenue is benchmark and it's an API metric, pricing based on usage is how we normally do things. Again, we've already decided product usage is not how we're gonna do this. What you're seeing on Twitter and what you're seeing with these people attempting to figure out the metric is, this is how I think it should be, or this is how I've seen it done before. This feels unfamiliar. This puzzle doesn't make sense. And this is a product team trying to make sense of what's going on. I feel like you have to get an engagement metric. Churn, maybe. Again, we're trying to change the metric behind the scenes. If you think about business health, which is what Churn would indicate, that's a lagging indicator. And a North Star metric should be a leading indicator. It should be something where we're like, if this thing is moving, other things will follow. So not Churn. I don't see a good metric. How many people have kind of given up when they're stuck in this situation ever? It happens. Sometimes people are like, I give up. I don't know. This guy says, unlimited usage, two year contract. I would look at a function of acquisition and retention, something like a quick ratio. This is what I would call a complicated metric. Sometimes if you just mix a bunch of stuff, leadership will say, that's a great metric. But that's not the same thing as a metric that actually correlates to revenue. So confusion is not a good strategy. Another example is why doesn't leadership care about the value of API? Now we're at the stage where we start challenging leadership. We're like, does leadership know what's going on? Do they have any idea? Leadership is a whole other mystery. We'll do another keynote another time to talk about product leadership. But the thing I would keep in mind is let's not say they're uninterested. Let's just Say they have some difficult decisions to make and there's some context that they have that we don't have. Right. And that's another part of the puzzle. That's another clue is sometimes leadership knows things and they push for things. But we don't know. Maybe they didn't share, maybe we didn't understand, maybe it's hard to follow. But there are constraints that are sometimes invisible when you're solving some product mystery. I love this guy. Daily get requests with 200 status, daily volume of data deliver. He comes up with an idea. You can't just make stuff up. Just because you think this should be the metric doesn't mean it's the metric. I'm not a big fan of a single metric. They are very contextually dependent. Focus on customer value. Okay, but again, you're trying to change the rules. The rules were established, which is revenue, unlimited usage, two year contract. I would look at unique users per day over unique requests, especially as the high number of requests. Intentional integration. Okay, there's a lot of jargon here. Have you ever been on a product team or seen a product team that says, hey, we're going to do a thing that solves a problem and adds value? And the leadership team is like, but what does this have to do with revenue? They're both trying to live in their worlds, right? The product team is saying, I'm going to focus on something that I can control. The leadership team is saying, this has nothing to do with what I'm focused on. It's a disconnected metric. And this happens all the time. I'm gonna go with DAU or whatever fits the cycle. Sometimes when you don't understand how to come up with a good metric, you say, well, this is a metric that I'm used to, so I'm just gonna use that metric. Why not? Again, what does DAU have to do with unlimited API usage? We don't know. What is your business model? Under what foundational hypothesis did you arrive at this business model? This guy's asking a really good question. What we're arriving at here is this product, whether real or theoretical, has a very strange business model, right? So you can sometimes be stuck with a business model suboptimal, and you can think, this business model doesn't make any sense. But you can't go to leadership and say, you know what we need to do? We need to change the business model tomorrow. You can't do that overnight. Has anybody ever tried that conversation with leadership? Yes. Okay, I'm seeing some. How does it go? Not well, the second thing is, I love this response. Very poorly constructed question. At some point you just get so frustrated you start challenging the person who's bringing up the idea. It's hard. Solving these kinds of mysteries as a product person is hard. Revenue. Okay, we went, how many, 20 tweets before somebody said revenue. Leadership cares about revenue. Let's just make revenue the North Star metric of the product team. Has anybody ever made revenue the North Star metric of their product team? How does that go? It's interesting. If your revenue is going good, you have an amazing product team. When your revenue is not going good, you have a terrible product team. Isn't it interesting how that ends up being the case? So it can be very, very motivating and demoralizing for a product team. So it can work, but it's not a great long term metric. This is me, by the way. This is not the final answer, but it is an answer. So I thought long and hard about this. I said, you are giving unlimited usage. You have a two year contract. You only care about revenue. Unlimited quota. And I don't actually know what people use this product for. The smartest thing or the most logical thing I could think of was if they're paying me just to use it, the smartest thing I can do is to make sure it's always available. That is a thing that a product team can own. It doesn't just have to be an engineering metric. So that was my answer to this. And the reason that was my answer is I very patiently thought about all the constraints and how to satisfy them for this particular puzzle. I'm not the only one though. This guy says, availability, availability, availability. It should be up and running and scalable as usage grows. This is what customers are actually paying for. For those of you who have worked on API products or platform products or data products, you'll notice that the contracts always have a line about uptime and latency. And sometimes people will even pay extra for more availability and more performance. How do you know that? This guy clearly had some experience with this kind of thing. So solving these kinds of mysteries sometimes requires you to have failed and gone through it one time, one more person, API, performance and availability. But I would still try to figure out how the features are used and try to change the business model overall. So you can go with uptime for now, but this guy has a really smart idea, which is you solve the mystery of today and then you continue solving the larger mystery in the long term. So we just went through a very interesting, I hope Twitter mystery that we solved together. What was that? Was that a product manager trying to define a metric? Was that just an interesting puzzle or, or was that something bigger? Was that a symptom of a problem that each of us sees every so often, day in and day out? That I think is an example of what we'll call a strategy spiral. Now if you're wondering what is a strategy spiral, there's a couple of things we saw in that discussion. The first is people become really, really over indexed on the metric. Everything is about the metric. Is this a good idea? How much does it move the metric? Does it move the metric? 10x? Is this the best way to move the metric? Everything is revolving around the metrics. Obviously there's nothing wrong with being data driven and metrics focused. I work at a company that helps you do that. But if the metric becomes the end all, be all, that can become dysfunctional. The second thing is you start to see people trying random tactics. What about this? What about that? Every two weeks, every month, every quarter, there's a shift in the tactics and it just starts to drain the team and they never really get to build on one plus one equals three. They're just kind of doing random stuff. The teams start to become disoriented. You saw from those questions, they're like, I don't understand the business model, I don't understand what leadership is doing. I don't understand what I can do to help the business. The teams are feeling disoriented and discombobulated, right? And then the last piece was you saw some emotions coming out. This is how it should be done. This is what I've done before. This is the right way to do it. People become emotionally attached to, to the metrics, to the tactics, to the business model, to their prior versions of success. And in that specific example we saw a couple of things. On the metrics side, it was confusing because we couldn't figure out how to connect to revenue. On the tactics side, intuition tells you as a product person, usage, activation, retention, sophistication, these are all things we want to drive. We want to believe people, people using our product adds value. So it's very confusing when you're told, well, it doesn't matter if people are using the product or how much they're using product, it feels very counterintuitive to a product person. Right? You can only imagine if this was a real company, how confused the tweets were, how confused the teams would be. Right? And then you saw people trying to apply pre existing playbooks that they've used before, copy pasted from other places. Right. It has to be dau. This is how API products work. And. And you see sort of an emotional reaction to how they want it to be. When did this actually happen? So it's really interesting to think about when you end up in this situation. Was it always this way, or was it a series of decisions that we made that led to this outcome? Right. The first thing I want to talk about when you end up in a strategy spiral is there's a set of usual suspects that we should walk through. The first is what I'll call a framework focus. So in a framework focus, somebody, the product team, maybe an operations team, will say, this is how we do things. This is the framework. We do annual planning. We do okrs, we do v2 mom. Anybody know what a v2 mom is? It's a Salesforce methodology. You're Amazon. We do op1, we do op2. This is the framework. And people become obsessed with the framework. And what happens is when you start pushing a framework, people get very used to filling out the framework. What they don't do is the critical thinking of, is the content here actually good? And so the dysfunction that happens when you're really focused on frameworks is you start focusing on the template versus the content. And the content should always be ahead of the template. The second reason people end up in this situation is what I'll call date driven. How many times have you been in a situation where it's like, hey, we need the plans by this date. It's critical. Show of hands. How many people are like, date driven? The date is driving everything. It's like, I just started thinking about this. Oh, it's due. I'm gonna stop thinking and write it down. The quality of your thinking as good as the time allotted, Right? Doesn't matter if it takes you one week, two week, three. It's like, get it done by this date, whatever the quality of your thinking. And that's just not a smart way to live, right? Being so date driven, obviously you're running a business. There's some structure that has to be applied. But when you focus more on the the planning process versus the actual plans that you're producing, you can end up in this situation. The third is lacking learning. Now, nobody will say, hey, we're not learning. We all have a growth mindset. I don't understand what you're saying, but sometimes what happens in an organization is you become very obsessed with the ritual. Are we shipping? Are we shipping on time? Is the velocity of our shipping high. Are we productive? Does anybody have metrics internally that they're accountable? Like that number of features shipped on time, dates, show of hands? Yeah, it happens. It's very common. It's a way that we can feel like we're holding teams accountable, but there's something wrong. Maybe somebody will shout this out. Does anybody know why we ship product? What is the actual reason you ship products? Maybe it's actually to learn. The reason you ship product is you say, I have this idea. I think this is the user. This is their problem. This is how I'm gonna help them. Now I'm gonna write some software and ship it to see if my theory is correct, Right? And writing and shipping software is the most expensive way to test out these theories. There are much, much cheaper ways to test out these theories. Our friend Tristan told us about discovery. Like, talking to users is a good way to test out these theories. Writing tweets and press releases is a way to test out these theories. There's a million ways to test out these theories. But if you have some conviction on what you're doing, then you should build a software. But it's still a very expensive way to learn. And a lot of times teams get stuck on, well, I just need to ship this thing. And they've lost track of why was I shipping this thing. What is the hypothesis? I was trying to validate or invalidate it. What is my theory about the user and the market and the problem again? And so what happens is they start worrying about building things versus actually learning. And when you're focused on learning, you build quicker, you build iteratively, you throw things away, you kill features. But a lot of times in a lot of organizations, it's just build, build, build, build, build. Never cut, never decide, never trade off. Right. Anybody ever dealt with that? Okay, I see a lot of nodding heads. I see two people nodding a lot. I feel like you guys work at the same company. The next piece of why people end up in this situation is what I'll call a constrained mind. Now, nobody will say, I have a constrained mind. Here's what happens. Leadership says, the goal is X. X users, X growth, X revenue. And then the team says, okay, I gotta get to X. If I get to X, great. If I get close to X, good, that's what I'm gonna aim for. Nobody ever says, is X a good target? If I did a wildly successful thing, can I do 10x? Nobody ever thinks, hey, what is good in this scenario? They think, what is my target? And how do I achieve my target or get close to it? Because the problem is you're not thinking about what wild success looks like. You're thinking about what does survival look like. You're thinking about, how do I hang on to my engineers, how do I hang on to my job? How do I make sure we don't get defunded and my product doesn't get deprioritized? I'm just going to do good enough to survive. You don't think about, what can I do that drastically changes the curve, right? And I've been in this situation. It's very hard. You're like, this is the track we're on. I don't want to switch gears, but. But the reality is sometimes you have to say, hey, leadership, I think we could do something fundamentally different. I think we should just stop what we're doing here and move all these engineers and do that. It's very hard emotionally and culturally to do that. But when you have a success mindset over a survival mindset, those are the kinds of decisions you're willing to take. The next thing is a functional bias. I think most of us are in product roles here. How many times have people said, well, the PM will figure it out. Who is our user? Who is our customer? What is our business? Well, the PM will figure it out. When did we decide that the PM is accountable for all of these decisions? A PM is just the virtual leader of a product team. Research, design ops, qa, engineering, data science. These are all members of the product team, right? The product team collectively should be responsible for strategy thinking and strategy execution. When you make just the PM on point, you're basically saying, I'm going to use a fraction of my cognitive mental bandwidth, right? You're saying, this one person is responsible for everything. All you other guys just do what this person, he or she says, and that's not a sensible way to live. The last example I'll give you is what I'll call seniority. How many times has the decision gone up the chain and then the executive decides, the leader of the org, the CEO, somebody at the C level. How many times have people seen a decision made at that level where you're like, I actually know better, right? I know better. And why do you know better? Because you regularly talk to users, you regularly talk to customer. You could be in product, you could be in support and say, I look at the support tickets, I know what the problems are, right? You could be in sales and say, I talk to customers. I know what wins deals and I know what loses deals. You could be in CS customer success and say, I know why people turn. But when you're at leadership, one of the weird dynamics of leadership is everybody wants you to make the decision. You have the least visibility into what the heck is actually going on. And all you can do is call a bunch of meetings to try to figure it out. Because you're supposed to make the decisions. And so what happens in this scenario, my clicker is not cooperating, is seniority starts to override visibility. The people with the visibility are not making the decisions, the people with the seniority are. And they don't have full 360 view. So these are sort of some of the key suspects in what I call a strategy spiral. The framework, the date, the lack of learning, the functional bias, the seniority bias, and the constrained mindset. How do you get out of this mess? Because it doesn't happen overnight, right? Sometimes it takes weeks, months, quarters. You used to be a very high performing team, very high performing company. Slowly but surely these dysfunctions caught up with you and now you're in this mess. Now your product manager is on Twitter asking how to define a metric and you're like, how did we get here? We used to be such a good team. So a couple of things. When you're in this situation where you're spiraling on your strategy, there's a couple of shared characteristics. One is the strategy is just not clear. The strategy is all about decisions, focus and trade off. And a lot of times those are just not thought through or decided. The second is sometimes the strategy is not shared. You saw from that Twitter example we went through. If you imagine those are all employees of a company, they don't actually understand the business model. They don't understand why we did two year contracts, they don't understand why we did unlimited usage. We don't understand why usage is decoupled from revenue. So whatever the let's assume, let's assume best intent and that leadership is smart. They made some decisions, but people don't understand those decisions. So they never shared the rationale for the decisions. Sometimes it's not logical. Everybody who works on API products knows at some point usage matters. So why would you illogically create a situation where usage doesn't matter, right? Or you've got multiple teams working not together but against each other. It's just the org design is not set up in a logical way, right? And then lastly, it is very painful to do the right things. Sometimes in a company you end up in this situation where you're like, to do what is the right thing or the correct thing or the strategic thing. I have to go against the culture of the company, right. I have to go against the e easy path. And so it becomes painful. So obviously the opposite is how you have a coherent strategy and how you get out of the spiral. You need to have a clear strategy, you need to share it, it needs to be logical and it has to be painless for the organization to execute. So let's go through these one by one. When I say the strategy is clear, it actually has to be written down. I'm curious, show of hands, how many people are working at a company where they have a strategy that's not actually documented anywhere? That's too high a number, even a handful of people. It has to be written down. It has to be written down. It has to be publicly accessible and it actually has to be complete. It should account for everything. This is who we think our user is. This is what we think their number one problem is. This is what we think their number two, three, four problem is. This is why we're going to solve problems number one. This is when we're going to solve problem number two. This is why we're not going to worry about problem number three. This is the order we're going to go in. This is how much investment we're going to put. These are the trade offs we're going to make. This is how competition fits in. This is who we're going to worry about. This is who we're not going to worry about. This is the customer segment. This is how we're going to find a channel. This is how we're going to go to market. All of these things are part of strategy and they all involve doing the research, having a point of view, writing it down, debating multiple times until you get to something where you say, okay, this is now a plan for the next 12 to 18 months that we can all agree on. But that's a lot of work. That is an artifact that you have to produce as an organization, a leadership team and a PM team. And it has to be written down and shared. The second thing is you have to broadcast it regularly. I don't know how many times people come up with an amazing strategy. They write a beautiful Google Doc and then they put it in Google Drive and they say, done, I'm done. The reality is strategy will drift. On day one, you do a company kickoff, everybody in the room says, I know exactly what we're doing. Two weeks later, one person is doing Something different. They got pulled into a customer escalation. There's some random idea, you did a hackathon and six weeks later you're like, well, 20% of the org has drifted. Six months later, 40% of the org has drifted. This is natural, it's just part of it. The thing you have to do is constantly synthesize and reiterate and say, this is our strategy. Remember, this is what we're doing, who we're doing it for, why we're doing it in this order. At every all hands, at every team meeting, at every product review, at every demo, at every customer conference, at every analyst meeting, you have to reiterate the strategy. I heard that you have to say something on average 37 times for people to actually internalize it as an org. And so a lot of teams don't actually spend the time to do the broadcasting that they need to do. The next piece is it actually has to be planned logically. If you tell the sales team, give out as many multi year contracts as you want, whatever incentives you need to give, and you tell the product team, hey, make sure product usage is how we monetize. You've now set up two teams that are not working together, right? I'll give you an example. I read a case study from the data science team at LinkedIn where they said the search team was told, your metric is how quickly, like the, how many people click on the first search result. Like that's your metric is the percentage of searches that end in clicking on the first search result. They separately had a team that owns the page, the profile page, and they said, your metric is how much time is spent on a profile page collectively. Now these two metrics are actually against each other. You got one team that is trying to get people to find the right profile and leave LinkedIn and you got another team that's trying to get people to spend as time on LinkedIn as possible. And they're just bumping into each other. They make one improvement, they make one improvement. The net metric doesn't move and the company is like, why are we one step forward, one step back, what's going on? And these kinds of things happen all the time. Product gets told one thing, engineering gets told another, product development gets told one thing, go to market gets told together. Finance is pushing one thing, recruiting is doing another. Anybody ever been in a scenario where it's like, go hire as fast as possible. And then recruiting is told, hey, don't go over budget for anybody. Those two things are not congruent, right? And this happens all the time is the right arm is not talking to the left arm. The last thing is it has to be effortlessly executed. I think a lot of times strategies are very intelligent. They're like, well, this is the market research, this is the user research, this is what we know, these are the trends and it's intellectually rigorous, but it is culturally absent. What I mean by that is when you try to execute a strategy, you have to realize you're not strategizing in a vacuum. Right? You're not a strategy consultant who says here is the right strategy. I'm gonna leave. The people who actually have to execute the strategy are your teammates and your company. And those teammates and that company have certain strengths and certain weaknesses. So your strategy has to account for. Does this actually make sense for us as a company? So if your strategy is we're going to go after mobile and Android is what we're going to focus on and you've never hired an Android engineer, that's not a good strategy for your company. Right, because that strategy assumes you're going to fundamentally do something that you have no history of doing. And that's something to keep in mind is you first come up with a strategy that's logical, coherent and thought through and then you say now where do I need to compromise based on where my organization is strong and weak. And by the way, it's not always a position of weakness. If you're super strong on something, you should bake that into a strategy. If your strategy just says this is a generic strategy, I don't really account for what are my superpowers as an org, what are my differentiators as a product? Then you're not really using leverage to your advantage. There's some terms I use for this which maybe we can go into detail after the talk. The written clearly legibility, the broadcasted regularly is what I call synchronicity. The plan logically is composability and the executed effortly is that it's affordable. It's affordable for the organization to do this. And I'll share some follow on material at the end but you can read more about this stuff online on my blog and newsletter. So how can you actually apply this in your day to day? Let's recap everything we went through. The first was you have to be aware and vigilant of the signs that you're getting into a spiral. The second thing is you watch out for these suspects that lead you down this road. And then the third is if you end up there or you think you're going to end up there, you make sure you're steering out of it early and often. So again, the signs of the strategy spiral were you're over indexing on the metrics, your tactics are changing regularly and against each other, and teams become disoriented and there's an emotional reaction to sticking to ideas long after they are viable. The suspects that we talked about were over indexing on the framework. The focus on dates versus plans, not having the right learning mindset, being over constrained by what the targets are versus what you should do for the business, relying too heavily on PMs to have all the answers, and then looking to senior executives to make all your decisions versus actually using the team that is closer to the customer and the product and the user. And then lastly, the four that we just went through, you got to make sure it's clear, you got to make sure you broadcast it, you got to make sure it's logical, and you got to make sure it is not going to be expensive to actually execute it as an organization. I want to share a little bit about what's next. If you're like, hey, this was an interesting 30 minutes and I want to hear more from you. Here are some places you can learn more. I work for Amplitude. We're doing our annual conference amplify next week in person in Las Vegas. If you want to see me or you want to learn more about Amplitude, it's a great place. If you're like, I'm not going to Las Vegas during COVID that's also fine. There's a virtual option as well. If you want to learn more from me. I teach a class that will be offered in July on a platform called Scholarsight. You can Google it. I have a newsletter that I mentioned on Substack and then obviously I spent so much time on Twitter, you can find me on Twitter or LinkedIn. So that's what's next for me. I would love to hear what is next for you. I'm curious what questions this has sparked for you. We have some time for Q and A. Would love to pass around the mic and maybe answer some questions live on stage right now. Awesome. All right, well thank you so much for your time.