An awful lot of no-good, truly-useless, dribble-drabble nonsense is written and spoken about strategy.
At its core, good product strategy helps product teams improve the speed and quality of their decisions. But what exactly does such a strategy look like? Well, that all depends on the decisions you're trying to make.
This session explores what constitutes a good product strategy, how to know when your strategy works as planned, and how to pivot when it (inevitably) doesn't.
Your speaker
Matt LeMay
Matt LeMay is an internationally recognised product leader, author, and consultant. He is the author of Agile for Everybody (O’Reilly Media, 2018) and Product Management in Practice (Second Edition O'Reilly Media, 2022), and has helped build and scale product management practices at companies ranging from early-stage startups to Fortune 500 enterprises. Matt is the creator of the One Page / One Hour Pledge, a commitment to minimise busywork and maximise collaboration that has been adopted by over 100 individuals and teams at Amazon, Walmart, CNN, BBVA, and more.
Matt is co-founder and partner at Sudden Compass, a consultancy that has helped organisations like Spotify, Clorox, Google, and Procter & Gamble put customer centricity into practice. Previously, Matt worked as Senior Product Manager at music startup Songza (acquired by Google), and Head of Consumer Product at Bitly. Matt is also a musician, recording engineer, and the author of a book about singer-songwriter Elliott Smith. He lives in London, England with his wife Joan.
Your host
Jamie Dobson
Jamie Dobson is co-founder and the CEO of Container Solutions, a professional services company that specialises in Cloud Native transformation. A veteran software engineer, he specialises in leadership and organisational strategy and is a frequent presenter at conferences.
Jamie is also the co-author of Cloud Native Transformation: Practical Patterns for Innovation, (O'Reilly Media, 2020).
Full Transcript
(Skip the gossip and jump straight to Matt's talk).
Housekeeping
Jamie:
Hello and good afternoon. Well, it's good afternoon if you live in London or other parts of Europe. If you're in the United States, it's good morning. So we're pretty excited today to be talking about product strategy with Matt LeMay. Hello, Matt. How are you?
Matt LeMay:
Hello. I'm doing well, thanks. How are you?
Jamie:
Yeah, very good. Now where are you? That's the big question.
Matt LeMay:
I'm in London.
Jamie:
You are in London, so you are surrounded by the madness that is British politics right now.
Matt LeMay:
I mean, coming from America, this is nothing. Are you kidding?
Jamie:
It's a good answer. Good answer. Probably an accurate answer as well. Okay. Right. So to everybody who's new to WTF, a very warm welcome. We do swear a little bit, so the clue is in the name, WTF. But What The Fuck is our publication, our series of webinars and blogs that lets us at Containment Solutions bring together different people from across the community to talk about things they care about. Sometimes it's technical stuff like Kubernetes and containers. Sometimes it's organisational stuff, and today it's going to be about product strategy. Now you might be thinking, "Well, what's product got to do with cloud?" Well, maybe you'll learn something about that later. But of course, the best platforms, the best cloud platforms and the best internal teams are always run as product teams. So what we can learn from Matt today is almost certainly applicable to the work we're doing in programmable infrastructure and large scale system development. A few pieces of housekeeping. Oh, oh, wait a minute. Oh, wait a minute. My slides have gone wrong.
Excuse me. I think I might be on the wrong slide. One second, bear with me people. I am a professional. I started at the wrong end of the slide deck. A little bit of housekeeping, we do have a code of conduct and we enforce that. So although we are very playful, we also want to create a very safe space for everybody regardless of their sexual orientation, et cetera, et cetera. Carla will now post the code of conduct into the chat so you could read it. High level summary, be respectful to each other, create a safe space. We will enforce this. You will be removed from this event or any other Cotalntainment Solutions event should you breach the code of conduct.
There is a chat box. You can ask questions throughout the webinar today. We will try to answer them. If Matt's on a roll, I will pick a moment or Carla will pick a moment when best to come in with that question. If it's appropriate, we'll ask the question immediately. If you're feeling really brave, you can switch your camera on and just scream the question out. We're not necessarily against that, so that's fine as well. Have I missed any more housekeeping, Carla?
Carla:
Yes, we are recording this session.
Jamie:
This is correct. We are recording. Usually I say we're recording, so if you have a problem with your face or your name appearing in the recording later, which will stick on YouTube, let us know and we can pixel that out. If you've got a real problem, I'm afraid we're not going to not record it. So you're probably going to have to drop off the webinar and then watch the recording yourself.
WTF is the Goss?
Just for those people who are new to WTF, we always do some announcements and we always do some gossip before; we warm the crowd up in preparation for the main event. Now usually the gossip is, no, it's not hit and miss, but sometimes it's very technical, but today it's going to be very topical because there's been some crazy stuff going out going on over at Twitter. So that's going to come up in the gossip today and helping with the gossip today will be Mo and Ricardo, my colleagues from CS. Hi guys.
Mo:
Hello.
Ricardo:
Hello. Hello.
Jamie:
Is this the first time doing the gossip?
Mo:
For me? Yes.
Ricardo:
Not for me.
Jamie:
Do you feel like a news reader on the television?
Mo:
No, I'm excited to do this.
Jamie:
No, that's good. I'm always really nervous. Well, not now actually. I've been doing this for so long, but I used to get very nervous. Okay, fine. So let's get cracking with the announcements. First of all, if you want to subscribe to the newsletter, which means you'll get access to these events and you'll get updates and you'll get things coming at you through email, you can do so. We are not a spammy company. You are allowed to sign up for the newsletter and click that you're not interested in services, in which case you'll never ever hear from us about anything other than the newsletter. You can also say, "Hey, I want to hear about webinars as well." We are not a spammy company. And when we get that wrong, tell me, tell Carla and we'll immediately change steps to get it right. This is really about sharing content that people want to know about and learn about.
There are some benefits to being a subscriber. You get to find out about when the conferences are coming up. We already have limited seats at our conferences, the physical ones and they're very, very much in demand. So you do get heads up on stuff like that. However, you can also follow us on Twitter or LinkedIn, in which case you don't need to be subscribed because you'll always find out straight away anyway. Speaking of which, WTF, What the Fuck is SRE? This conference is already legendary at Container Solutions because it started as a webinar that was so popular we instantly said, "Right, we're going to create a conference from it." And the conference worked. Recently, we've just done a bunch of content around developer experience that went down really well. So all of a sudden WTF is back with SRE but there's going to be a developer experience track running right through the conference.
So we are really looking forward to hit these high notes. If you've got some sponsorship budgets and you want to spend them, now is the time to get in touch because if you don't spend your budgets now and you're going to lose them, so we'll take your money off you as a sponsor right now if you're interested. More importantly, if you want to go, please sign up because those tickets will go really quickly. I absolutely guarantee you that. Other announcements? Oh yeah, we're hiring. Oh god, what a surprise. A tech company's hiring actually, actually it might be a surprise given what's going on out there. The madness of the industry right now we are always hiring engineers because we're always growing as a company, but we are also currently hiring country managers in Germany and Canada, which are two of our locations, well Germany, the DACH region, and the eastern time zone in the US.
The country manager role is a very cool role if you've been an engineering manager and you want profit and loss responsibilities for the first time. Unfortunately, a downside of that role is you will have to work with me on a reasonably regular basis. So please consider that when putting in your application. We do run an unbiased and super cool process. So you can check that out on the career site down below where you'll be able to learn about all the other roles that we've got available. I will take a breath now because it's time for the gossip and there's a bit of chaos over at Twitter. Who is taking the Twitter Gossip boys?
Mo:
That's me.
Jamie:
Right Mo. Let's hear it.
Mo:
Yeah, so Twitter's been on the news a lot lately for various reasons. I'm sure we've seen it. So last week they rolled out Twitter blue, which is a subscription based account verification. So for 6.99 a month you get a blue tick next to your name essentially. It didn't take long for fake verified accounts to pop up impersonating major brands and high profile individuals. So as you can imagine, this caused a lot of confusion. So the usual suspects being impersonated with people like Joe Biden, Trump, Zuckerberg, Tony Blair for some reason, even Elon as well.
Jamie:
And isn't it true, isn't it true that a pharmacist, was it Lilly, somebody called them and they basically-
Mo:
Yeah.
Jamie:
Insulin is now free and their share price dropped through the floor.
Mo:
Yeah, yeah, exactly. So it's a cause of major chaos. There was also a case where there was a Republican candidate for governor, I think it was in Arizona. They corrected the fake account for that person and they tweeted that person's conceding while the votes were being counted. And I think that stayed up for eight hours before getting taken down. So yeah, that probably skewed voting as well. Yeah, so they did eventually suspend a lot of the fake accounts, but they struggled to keep pace because there were so many new accounts being created. To sort try and combat that they added, they temporarily added like a grey verification badge and labelled it official on some of the high profile accounts to try get a handle on the situation. But that was then scrapped almost immediately. I think now they've suspended Twitter blue and they're trying to find out what's...
Carla:
Sorry Mo. Jamie, we are seeing your full screen.
Jamie:
Yeah, sorry. I was aware you could see that. I actually knew you could see that and I was quickly trying to Google if we could find some of the better examples. I couldn't see any. Yeah, you keep going Mo, I knew you could see that Carla-
Mo:
Now.
Jamie:
No, go ahead Mo you go.
Mo:
Yeah. Yeah, so they, they've scraped the news of grey badges that they labelled official and also I think they've suspended Twitter Blue subscriptions. So now I think they're sort of reviewing how to best roll that out.
Jamie:
My biggest regret, once I saw this was happening, I thought, "Right, I'm going to get my credit card." I would start spoofing some things, but they'd already stopped it. I was like "Fuck, fuck." I could also-
Mo:
It's too late. You're too late.
Jamie:
Right. Did you hear the latest madness? There's an email go around Twitter today and it basically says, "Are we ready to be hardcore? Click this link. Oh yeah. And commit to working until 11 o'clock at night, 12 o'clock at night. Alternatively, don't click the link, in which case you are about to be fired." Now how-
Mo:
Yeah. Something about, "Take severance pay or commit to 16 hours a week." Sorry, a day.
Jamie:
But what happens if everybody takes the severance pay?
Mo:
Exactly.
Jamie:
Imagine that. Right? Okay. Are there any more news from you Mo, before we move to Ricardo's talk about layoffs?
Mo:
No, that's, that's me.
Jamie:
Right. Okay. There has been some crazy stuff going on with tech layoffs and sometimes it's crazy in where they're happening for the very first time at Facebook or Meta, sorry, sorry Mark, I know you're a fan and you get upset. Mark Zuckerberg gets upset when we call it Facebook instead of Meta in the same way that product managers get upset when I call them project managers, they go crazy when I do. And I do, it's because I'm old, I'm an old person and I can't remember the names of roles. Okay, Ricardo Tech layoffs hit us.
Ricardo:
Yeah. So on that one you'd think that this... All these layoffs could be a Twitter specific thing, but actually it's not. It's all over the market. I mean at least for me it's super surprising we've seen... So we've seen tens of thousands of layoffs in Amazon, Meta, Twitter as we said, Stripe, Salesforce and it is very surprising. We're not used to seeing this happening in tech. That's next. You know what, we'll be unionising ourselves, which is funny to think about.
Jamie:
You'll always be allowed to form a union at Container Solutions consent at the highest levels of the organisation.
Ricardo:
Good to be here. No, the thing is, why is this happening? And there are a few reasons. One of it is very simple. I mean the real economy is not so great, now there's war in Ukraine, there's China-US tensions, there's a lot of uncertainty regarding the future. There's also a lot of inflation and because of inflation we have high interest rates, which in turn are cutting down money available for funding. So now tech companies not going to have as much funding to invest. But also there's a lot less money in the stock market, which then in terms means that the valuations of those companies are way down. So shareholders are not too happy and they're saying, "Well fellas, you can't keep on going on your crazy adventures. You need to settle down a little bit more."
Jamie:
Right. And with that in mind, Ricardo, there was a brilliant article in the newspaper today, one of Google's largest Jamie:shareholders, sorry, Google, one of Alphabet's largest shareholders had written them a letter and said, "Hey, you need to cut your costs. Not only do you need to pay your people less, but you actually need to get rid of a bunch of people because it's completely over the top." And the shareholder had listed, "Hey, this is what you get paid at Alphabet, but this is what you get paid at Microsoft. Everybody should be aligned." So quite an unbelievable turn of events where an individual shareholder is writing an open letter to the company that they've invested in and telling them you need lower your wage bill and you need to lay people off.
Ricardo:
But that's the thing, this is a very normal thing in any other industry. It hasn't been normal in tech, but I guess tech is normalising.
Jamie:
Right. So basically this is business as usual. People in tech are like, "Oh, what's happening?" And yet, and everybody else is, "Yeah, motherfuckers, we want a return on our investment."
Ricardo:
And I mean, well one of the last main reasons is that also during the pandemic there was a boom in an internet business and since then it's kind of faded. So there was over hiring during the pandemic and now it's a bit difficult and they have to readdress. Anyhow, moving on to... Unless there's something else, Jamie you want to say about what a great boss you are to Container Solutions. There are no mass layoffs here as far as I know.
Jamie:
No, no, I don't need to... Quite frankly, I think I've said enough today already and we're only about 15 minutes in. I do actually, I'm really delighted to see this FTX drama because I try to read about it and I don't understand. So I'm very glad that somebody's about to explain it.
Ricardo:
All right, so I'll just very briefly, so what happened, FTX was the second biggest exchange, like cryptocurrency exchange in the world, until last week. What happened was twofold. The first reason was that there was rumours in the market that maybe FTX was having problems. So there was a type of a bank run, which in this case should be fine. I mean it's difficult, but it shouldn't put it under however it did. And it's because there's some dubious transfers between FTX and some other company of the CEOs like that the CEO owned. So when one is run to assets, to which assets happened, then FTX didn't have enough. It was a liquidity crisis. FTX didn't have money to reimburse those clients. That led to the bankruptcy itself. What happened afterwards is that well, clients couldn't reach up their money bankruptcy and then all the shareholders also lost their money. A bunch of big shareholders and Sequoia fund and stuff like that. They really believe in this and they lost all their money.
Jamie:
Isn't it the case that Tom Brady, the football has chucked a ton of money in as well?
Ricardo:
I think so. I've seen his picture associated with this, so I think so.
Jamie:
And he's like 46 and he still plays, he'll still be playing when he is 56 now.
Ricardo:
I mean he'll play forever.
Mo:
I think they've got a stadium named after them as well. But I saw there's... So there's another headline regarding FTX recently that they've got hacked and 400 million somehow disappeared.
Jamie:
Disappeared. Its not in our bank account for sure.
Ricardo:
I mean, so this is the thing, I mean, what does this mean for the industry? The wide industry, FTX in particular the CEO was a like a saviour figure. He helped a bunch of other companies that were having trouble. So now that FTX is going under, people are questioning what's the future for crypto.
Jamie:
On that happy note. First of all, thank you to Ricardo and to Mo for the wonderful gossip today I thought was really actually very good. For those people who have never been to WTF before, this is basically what we're trying to do. We're just a bunch of people talking about things we care about having a bit of fun. To be fair, that's what it's like working at Container Solutions. Although occasionally we have to work with our customers too, which is also fun, but slightly different. And it is true, it is true. Recently we've been massively getting into product and product strategy. So it's actually with quite a bit of pleasure that I'm introducing Matt who is for the very first time appearing on WTF. So I would like us all now to give him a round of applause. Please unmute your microphones when you do this and welcome to Matt.
Matt LeMay:
Thank you so much.
Jamie:
I'll stop sharing.
Matt LeMay:
Very, very happy.
Jamie:
And the floor is yours. Share your slides when you're ready.
Main Talk
Matt LeMay:
All right, let me share my slides. There we go. Let me get my presenter display open. It's funny that we're talking about product strategy on the heels of that gossip because I think that product strategy is very germane to the reasons we are seeing a lot of these issues at companies in particular at Twitter where the product strategy seems to be, do whatever the billionaire thinks is a good idea right now, which I do not recommend as a viable product strategy.
So very happy to be here today. Thanks for having me. Thank you Jamie. Thank you Carla. Thank you Charles for setting this up. Got to put my gratuitous fancy slide in there. So I've written a couple of books about product. I've worked with a lot of big fancy companies. I've been an independent consultant for about eight years. I was at Bitly and Google and a bunch of companies before that.
And at those companies I have often been told like, "Hey man, what's our product strategy?" And my response to that has been, "Oh shit, what is a product strategy?" I better go Google it and figure it out. I am not the only person who's done this. That's funny. In the last month I've been going to a lot of conferences and doing a lot of talks and many people have had a slide to this effect. The, "Oh shit, I needed to Google product strategy slide." And when you do Google product strategy, you find a lot of very contradictory ideas about what a strategy is and is not.
You will find folks saying, "If you don't have these 37 things in your product strategy, it's not really a product strategy." And then you'll have other people saying, "If you have more than five things in your product strategy, it's not really a product strategy." And you'll have folks saying, "Product strategy is completely different from business and commercial strategy." And folks saying, "Product strategy is a subset of business and commercial strategy." And it is all just a recipe for a big old WTF.
Trying to figure out what exactly product strategy is or is supposed to be is very confusing and very exhausting.
Now this is particularly tough for us product managers who are dealing with imposter syndrome more or less 24/7. Anyhow, we already feel like a dog trying to fix a car most of the time. And when you then ask us to figure out a strategy for how to fix the car, boy, it's not easy.
I've worked with many, many product managers, I've coached product managers who come to me and say, "I was just told to put together a product strategy and obviously I know what a product strategy is and I'm very clear on what it's supposed to be, but could you just tell me a little bit, just confirm my very existing knowledge that exists about what I think it is being the right thing."
So for better or worse, I am not going to spend the rest of our time together telling you the 37 or fewer things that need to be in every single product strategy because I don't believe that every single product context calls for the same kind of product strategy.
In my mind, you can recognize a good product strategy, not by what it is, but rather by what it does. Somebody will occasionally show me something and say, "Is this a good product strategy?" And my answer is, "I have no idea." Because I have no idea how you're using it and whether you're finding it useful.
I don't believe you can evaluate a product strategy out of context and determine whether or not it is a good product strategy. You can only really evaluate a product strategy by whether or not it is helping you do a very important thing.
What is that thing?
Well, for any product team, we have goals, right. I hope we have goals, we have outcomes we are trying to deliver for the business, for our users, for our teams. In the service of achieving those goals, we make a lot of decisions. We make decisions about what we're going to build, what we're not going to build, how we're going to build it, when we're going to build it.
To me, a good product strategy is whatever bridges these two things, whatever bridges our goals and our decisions is a good product strategy. If we have something in place that helps us make the day-to-day decisions that will steer us towards achieving our goals. Great.
So to summarise or restate what I just said, "A good product strategy is whatever helps you make the day-to-day product decisions that will steer your team towards achieving its goals."
If you are making those day to day decisions and you feel confident, you say, "We have a clear sense of what path we're taking and what we believe is going to help us achieve those goals, what we believe is not going to help achieve our goals." Then we probably have a good product strategy in place. If we cannot make those decisions in a way that we feel is going to help us achieve our goals, or if we are not making any decisions at all, which is a shockingly common problem for product teams, then we probably don't have a good product strategy in place. No matter how many frameworks we follow, no matter how many slides we have, no matter how many months we have spent off on our own in a cave somewhere, chiselling the perfect strategy into the cave wall so that we can feel good about ourselves and feel like we are good product managers who know what we're doing.
So I want to start by this achieving our goals piece because in order for us to do this, we need to know what our goals are and a lot of product teams don't know what their goals are, right. If I were a product team at Twitter right now, I'd be like, "What are we trying to achieve? Other than making one very rich man feel good about himself, which is not a great goal. What does success actually look like for us?" If we don't know this, it's really hard for us to figure out our strategy. If we don't know where we're going, it's very hard for us to figure out how we plan to get there.
So let's start here. Let's start by talking about how a team can understand and articulate the goals it's trying to achieve. I'm curious, how many of you have heard this phrase before? Outcomes Over Output. It's the name of a really great book by Josh Seiden, it's also a very commonly uttered phrase in product management world. Product managers love to say, "Outcomes over output." Or in other words, the goals we seek to achieve over the stuff we build in order to achieve those goals. We start with what we want to achieve and then we figure out the stuff we're going to do rather than coming up with some stuff to do and then saying we think it's important for the following reasons.
It's funny because I'm a big believer in this concept, but I have also seen teams take it the wrong way. I worked with a team once that had stopped shipping all software and I said, "Well, why aren't you delivering anything?" They said, "Well, outcomes over output. We're not just going to build stuff. We need to spend all this time focusing on our goals." And I'm like, "Yeah, but you still have to do something at the end of the day, right? You're not going to achieve your goals by sitting there."
So I now like to think of this as outcomes in a deliberate system with output. In other words, it's not just a matter of no output all outcomes because that's not how things work. The best product teams I've worked with always think pretty deliberately about what is the relationship we want between outcomes and output? In other words, what are the goals we're trying to achieve? And then how do we think deliberately and strategically about how we can build things to achieve those goals?
And within those systems, I have seen one fairly consistent pattern, which is really, really, really interesting to me. And honestly it was really surprising to me as well.
I've started to think of outcomes and output as kind of a seesaw where if you want more height on one of them, you have to push down on the other one. So in other words, if we want to be really open-ended, we want to have freedom to pursue lots of different output to say what are all the different things we might be able to build and deliver? We have to actually get really specific about the goals we want to achieve—uncomfortably specific in a lot of cases.
We have to be clear about what exact targets we put on those goals, what exact dates we put on those goals. The reality I've found is that in a business, specificity needs to come from somewhere. You cannot exist in an environment of no specificity. You can't say we're going to do some stuff at some time for some reasons.
But what that means is that if you're not specific about the goals and outcomes you seek to achieve, you're probably going to get stuck being really specific about the output you are going to deliver. When I work with teams who complain, "We're just a feature factory, we're just shipping stuff, we don't know why." Then I ask them, "Okay, what are the specific goals you're working towards?" They almost never have a good answer to that question. Again, the organisation will ultimately ring specificity out of a product team. The question is, has that product team been brave enough to seek specificity on the order of outcomes rather than being forced to provide specificity on the orders of output?
So I've seen this time and time again and a lot of the consulting work I've been doing recently is very specifically related to this idea. The most effective product teams have high altitude goals that are meaningful to the overall business attached to high specificity targets and timelines. And I want to talk to you a little bit about what this means—what it means to have goals and outcomes that are both high altitude and high specificity.
So we can chart out our goals and outcomes on these two axes, right. High altitude to low altitude, high specificity to low specificity. Almost all product organisations and teams have some degree of high altitude, low specificity goals. So things like our mission and vision statements, right. We're going to make the world a better place. We're going to do... I think you can see a lot of this in Twitter right now. "We're going to be the town square for free speech."
All right, sure. That's nice I guess. But what specifically does that mean? If I were a product team and you said, "Go be the town square for free speech." I'd be like, "I don't really know what to do with that. I don't know how to measure success in this particular case." So a lot of product teams wind up doing is they then supplement these with low altitude, high specificity goals.
So we might say for example, like, "Okay, well if we're going to be the team that's the town square of free speech, we want to see this much engagement in this little order, it's tough to measure, but we can get into these really kind of fiddly low altitude product level KPIs and metrics." How many times did people click this button? How many people do we have doing this specific thing? These are things that might not be really understandable to the broader business. If you went to the CEO and said, we got three clicks on this, or we're getting more conversions at this stage of the funnel, they might kind of be like, "Oh, okay, that's fine, but we're not operating in that high altitude" that's really going to give us the opportunity to pursue a lot of different options and to have that impact that we know is going to be meaningful across the entire business.
We also have here our low altitude, low specificity, like the vague user stories, the like. The user clicked the thing which we're not going to worry about too much because this is probably the least valuable quadrant here. What's interesting is that we usually don't have really good high altitude, high specificity goals when I work with teams and I'm like, "What is the specific impact you wish to have on high altitude critical business metrics in a specific timeframe?"
A lot of folks can't answer this question. And I just went through this with a team recently that's responsible for offboarding users from a legacy system and getting them into a new version of that same system. And I said, "Okay, what are you responsible for? What are your goals?" And they said, "We're going to take the users from our legacy system and get them onto our new system." And I said, "Yeah, that sounds great, but how many users and by when?" And they got very nervous. They kind of looked around and they were like, "We don't know." I said, okay, well I would imagine you would be approaching things differently depending on what that number is. And they said, "Yeah, but we don't know." And I said, "Okay, well what do you think the number should be? How many users do we want to have on the new platform by the end of Q1 2023?" And they said, "We don't know." I said, "Okay, 10, a hundred or a thousand."
And somebody on this team, an engineer actually on this team said, "Gosh, if we committed to a thousand, we'd have to really focus on this and probably not do anything else." And that made me very happy. I said, "Great. So if we commit to a thousand, that helps us make decisions." The team said, "Yeah, I mean if we commit to a thousand, that's going to affect all our decisions."
What was really interesting was now that they have committed to that thousand user goal and shared that with their manager, they feel much more empowered to say no when random teams come to them and say, "Oh, can you also work on this? Can you also work on this?" They say, "We've got a goal to hit a thousand users onboard to the new platform by end of Q1 2023, and there is no way we're going to hit that if we take on every little bit of work that comes our way."
So this team that felt disempowered, that felt like they were being given orders and only had the ability to execute those orders. Again counterintuitively, this is not what I would've suspected, became more empowered by committing to a specific target on a specific date. But that target was an outcome, not an output.
So in other words, if your team's goal is just to improve user engagement, you'll probably be stuck in a world of deadlines and delivery targets. There will not be room for strategy. Conversations about strategy will ultimately be pointless because if you don't have those clear goals, you're just going to wind up hitting those arbitrary deadlines that you're assigned. However, if your team goal is to increase the task completion rate for email sends by 30% over the end of the quarter, you're going to have to get creative. You're going to have to figure that out. You're going to have to have tough conversations. You will have different paths open to you and you will have to decide which of those paths is worth taking.
I used to be very reluctant to commit to anything this specific to say, "Yes, my team is marching towards this specific outcome on this specific date, but I have found it to be the path to freedom.
So a question for you to reflect on. Do you know what high altitude, high specificity and goals and targets your team is aiming to achieve, in what timeline? If I asked you this question for your team, if I went through this exercise with you and said, "What are these specific business critical targets and milestones you are working towards on specific timelines? Do you know? Are you able to answer this question? Because in the absence of this, it is very hard for us to know what we're trying to do. Again, if we don't know where we're trying to go, it is a questionable utility for us to have a conversation about how we plan to get there. Think about this one. Bring it back to your team if you're not sure, have this conversation right.
So we've talked about goals. Now let's go to the other side of this. Let's talk about decisions. Product teams make a lot of decisions, every time we choose what to build, how to build, what not to build, when to build, for whom to build. We are making decisions. Sometimes these decisions are navigated explicitly. Sometimes these decisions are navigated implicitly, but we are constantly in the process of making decisions.
Now, when I work with teams to understand these decisions, I often start with prioritisation decisions because these are often the most visible and tangible decisions. Most teams make prioritisation decisions explicitly and in the open they have regular conversations with each other. "All right, what are we going to build next? What are we not going to build?" Prioritisation conversations are happening, which makes them a pretty good lever to look at.
They're also a place where we get into the same WTF problem of Googling. How do we do prioritisation? What are the best prioritisation frameworks? There's like 50 of them, they're all really confusing. There's like a lot of WTF around what is a prioritisation framework? What is the best way to do this? I am not an advocate for any particular prioritisation frameworks. Most of them are subjective enough that we run into the same problems regardless of which ones we're going to use. Whether we choose one that defines must-haves or high impact or high delight to customers, we still have to figure out what impact means or what must have means or who our customers are and what matters to them, right?
At the end of the day, we still have to make these decisions and there is no framework that can take that element of having to figure out what these things mean out of that process. So I find that rather than trying to commit to a framework or anything like that, I like to reverse engineer prioritisation decisions, right. Again, teams have to make prioritisation decisions. Every team has had to at some point choose to build one thing and not another thing.
And if we look at why and how they make those decisions, we can actually start to understand what their strategy needs to be. Again, we can start to look at what the shape of that thing in the middle needs to be to connect that team's decisions to the goals they're trying to achieve.
So I was working with a team a couple years ago, always stack rank your kittens, also know which kitten goes first and kitten goes last. I used this slide in a talk I gave in person and everyone just stopped looking at me and kept their eyes on kittens for the entire slide. So that's okay, no judgement.
I was working with a team that was doing a session on product strategy and they were about two hours into this conversation where everybody was going up to a whiteboard and writing out what they think a strategy is. And I said, "Okay, let's do a little exercise. What are 10 things this team is thinking about building?" And we wrote them out. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. I said, "Great. Everybody on the team individually put them in order, stack rank them, what do you think is the most important thing for us to build next? And then the least important thing for us to build next?"
And I gave them five minutes to do this and everybody went and sat down and they said, "Oh, it's going to be 5, 7, 4, 3, 2, 9, 8, it's going to be eight." What was really interesting was each person did this individually, but two very consistent patterns emerged. About half the group ordered things one way and about half the group ordered things a different way. Interesting. I said, "All right, I'm going to divide you up into teams and we're going to do this debate club style. Each team is going to make an argument for why they ordered things the way they did." So they get into their teams and they're getting really excited and they're like, "Oh, we can't wait to make the argument for why everything is right." The first team goes and they say, "Okay, given that we are focused on building for new users, we..." And somebody else goes, "Wait, wait, wait, wait, wait, wait. I thought we were building to retain existing users."
Now you know what your strategy needs to be. Your strategy needs to be, which type of user are we building for, and that might be enough. I have found time and time again that when you start from these decisions and reverse engineer them, when you ask individuals on a team to prioritise and then look for the implicit strategies behind those prioritisation decisions, what you usually find is something much simpler than what you probably thought you needed. Sometimes answering one or two simple questions like "Who's our user and what problem are we solving for them?" Is enough. We often don't need a lot of complicated information to make these decisions. We just need to start with these specific information that we do need in order to make those decisions, which often means starting with these specific decisions that we are making.
Again, it's not that there's some secret 38th step to the strategy framework you're missing. It's probably that something seemed so obvious or high level or simple that you didn't bother to discuss it with your team, "Who is our user?" And when you actually take the time to discuss that, it turns out you do not have the same answer.
Again, in practice, it is missing or thinking you don't need to have those simple basic conversations that impedes team's ability to be strategic much more than there being any esoteric complicated thing that they happen to not be on the same page about. Whatever helps you make those decisions. Yeah, that'll work. Babies know it. They're like, "I got to get this thing in the bucket, boom. In it goes, not wasting my time." Be smarter than a baby. You can do it.
What this means is that in a lot of cases, if we think of strategy as this big complicated thing, and again, I have worked with so many product managers who are like, "Oh, we have to go disappear for a month long offsite to come up with our product strategy."
You probably don't.
Your strategy should be as small and as straightforward as possible. You want your goals and your decisions to be right up next to each other. In some small startups I've worked with, we barely need a strategy at all because the goals are pretty self-evident. It's pretty clear, I worked at a small startup once where we had a quarterly OKRs that we set and we didn't need a strategy because when we sat down to do prioritisation, the OKRs guided us really effectively. We didn't have anything to debate. It was really clear based on the way we wrote those OKRs, which of the things we could build was important and how to build them.
This layer we call strategy should not be complicated, it should not be big, it should not be something you add into. Your goal should be to make it as simple as concise and as straightforward as possible to help your team make decisions.
And if you aren't sure where to start, so we've talked about starting with goals. We started talking about decisions. There are still people who are going to be like, "Okay, but I want to just start making a strategy. I want to find a template, I want to do this." Here's a little trick you can use. Find any template you want. And rather than trying to use it once to come up with the strategy, fill it in three times, try coming up with three different mini strategies and see if these three different mini strategies actually lead you to make different decisions. See if they actually would guide you to different decision making, because if they don't, then why are you doing this?
It's very easy I find when you are trying to come up with one strategy to come up with something which is so vague or so general that it doesn't actually compel you to make one decision or another decision. It sounds good, but it's ultimately so much fluff and meaninglessness.
Find a few simple questions from your favourite template or framework, answer them three different ways while keeping your goals in mind and see how it affects your decision making. Take it from there. So again, after this, you're like, "Okay, but what's your favourite?" Like I don't care. Different approaches will compel you to make different decisions differently. So again, if you're not sure where to start, if you don't want to start by looking at goals, if you don't want to start by looking at decisions, do a Google search and find a framework on an example, you'll probably see a set of things.
Find a few questions or ideas in that framework or example that you think you could answer them three different ways and test out those three different mini strategies. See if they actually help you make better decisions, see if they help you make different decisions. And from there you'll probably get a better sense of what a strategy needs to look like for your particular team to make your particular decisions to achieve your particular goals.
So I'm very excited to answer your questions. To quickly summarise a good product... Whoops, trying to move the window but got rid of the whole thing. WTF, our slides. To summarise, a good product strategy is whatever helps you make the day-to-day product decisions that will steer your team towards achieving its goals. A good product strategy for one team will look entirely different from a good product strategy for another team. There is no such thing as an intrinsically good product strategy or an intrinsically bad product strategy. The question is, does it work.
The most helpful and actionable goals are both high altitude and high specificity or high altitude enough to be meaningful to the business and high specificity enough to compel you to make decisions. Reverse engineering prioritisation decisions can help you identify what you need in your particular product strategy. Try doing the exercise I talked you through. Try having the team prioritise your backlog and see what those different orders are and see what implicit strategic guidelines are driving those decisions. And if all else fails, find a simple template, use it to test out three mini strategies and see if those three mini strategies help you figure out three different courses you can chart.
Jamie:
Thank you very much, Matt. And actually-
Matt LeMay:
That's my spiel.
Jamie:
Yeah, and we've got questions. We've got them.
Matt LeMay:
Good. I love questions.
Jamie:
Anybody else got questions? You can chuck them in the chat box while I start getting through the first few. What is the difference between business and product strategy and what's their cadence?
Matt LeMay:
It's a great question and my answer to the great disappointment of all of you, I'm sure will be, it depends. That's going to be my answer to almost all these questions. But what I will say is that, again, what's critical for you to think about on your team is what do you need in that middle space? Maybe the business strategy is enough. If the business strategy is enough for you to make product decisions, you don't need to add more into it just for the sake of having it. As you get into more complex and large organisations, sometimes that middle layer can start to feel like this very messy layer cake. And sometimes the different layers of the cake are not terribly delicious together. Like you're going through it and you're like, "Ooh, chocolate, chocolate raspberry, that's good. Lemon. Okay. That kind of goes, I don't know quite what this is. Oh, I don't think that's cake. That's okay. Maybe this is..."
What you want to do again, is keep it as straightforward as possible. What information do you need to make decisions? And there might be multiple layers or dimensions to that, there might not, but I really don't care about what it's called. I really don't care about who owns it. What I care about is can you use it to make decisions?
And I think that with cadences, I am a big fan of reevaluating strategy on regular short cadences. I think that if you don't make plans to change, you will probably never change. Strategies can remain really stagnant if they're not revisited on a frequent cadence. So I like looking at strategies at least quarterly. But again, it depends on what your team is, what you're trying to achieve, what your cadences and goals are, you know your own company and your own goals, and your own team better than I do. And my number one piece of advice to you is to trust your contextual knowledge, trust your instincts. Don't rely too much on folks like me who go around talking about this stuff to tell you the right way to do things because you are going to know more about the right way to do things for your team than I am.
Jamie:
Thank you, Matt. All right. Question number two. How do you align product strategies across multiple products with different personas and target markets within a similar broad market? And the person gives examples such as gaming, eSports, content creation?
Matt LeMay:
Yes. So I mean the bigger the organisation and the more complexity, the harder alignment is, right. And I want to be clear, you never get perfect alignment. You can never reduce tension and friction. There will always be misalignment, there will always be ambiguity, there will always be challenges like that to resolve. The exercise I have run across teams is looking at the goals. Again, if we get to those high specificity, high output goals, what I will often do is get teams in a room or in a virtual room, have them list out their high altitude, high specificity goals and look for areas where their goals are supportive of each other and look for areas where their goals are in tension with each other. To use a classic example, you will often have one team whose success is measured against customer lifetime value and another team whose success is measured against the number of new users they can bring in.
Well, if you bring in a bunch of low value new users, then the average customer lifetime value is going to go down unless you measure that in a specific way. So I think looking at that goal altitude, like looking across teams at a high altitude before you get into what are the specific technical and tactical dependencies I found is really helpful for making sure that that conversation stays useful and that you can then figure out how that strategy needs to align or cascade. And at the very least, your strategy is not misaligned at the level of the goals that is working towards, which in turn hopefully frees up your team to be more purpose-built and more kind of customised and thoughtful about how it's going to approach the strategic question of how do we get there.
Jamie:
Very cool. I don't know who answered that question. Is it asked that question. Is the person who asked that question on the call and does it answer your question? Well, that person is deciding whether they're going to unmute their microphone or not. We're going to come to the next one. How do you find a balance when you hear from your target users... Oh, hold on, let me read this again. How do you find a balance when... ~Oh, sorry, what you hear from your target users doesn't go along with your overall product vision. I think this question is a bit like what do you do when you do something as a product manager that your customers hate?
Matt LeMay:
Yeah, I mean, so it was interesting. I worked on a product years and years and years ago, which had a very clear vision. The founders were like, "We know exactly what we want this to be." And they did a lot of feedback sessions with users where they told their users, "Here's what we think this should be, what do you think?" And the users were like, "Yeah, sure." And I came in and said, "All right, mind if I lead the next feedback session?" And I just showed the product to these users and I said, "What do you think this is?" And they said, "We have no idea. We have no clue what this is or what we're supposed to do with it or why it's valuable to us." And it was really, really, really hard for the founders to hear this because again, they had raised money and had this whole vision of not just the product itself, but a particular framing, a particular story around the product.
And I think it wasn't until they saw the third video of somebody in their target market going, "I have no idea what this is." It actually starts to dawn that they needed to change. So I think it's really challenging, but I think ultimately the reality of product development is that it's our users and the markets that our users constitute who determine whether or not we're successful. We don't determine that we can't decide to be a successful product. We can't decide that our vision is real or that our vision is even relevant to the people for whom we're building. We have to listen to our users and we have to be brave enough to reevaluate the course we're taking what we hear from our users is not what we wanted to hear.
Jamie:
Take every... You won't change the course with every bit of feedback or complaint, right?
Matt LeMay:
No. And that's one of the reasons why working with skilled and trained user researchers is so important, right. You want to wait till you see a pattern and you want to understand that pattern. And there's never perfect. It's never a hundred percent of all your users think this, at 0% think that there is so much pattern recognition and intuition and that combination of data and gut driven decision making that goes into understanding all of this. So I think, yeah, you never want to abandon everything when you just hear one thing from one person. But if you are consistently hearing something that paints a very different picture from the one that you went in with, then it's really important that you raise that information, that you address it fearlessly and that you bring it to the folks who are making those important decisions.
Jamie:
I know my, so I'm nearly 50 now there's a downside to this. My things don't work properly anymore. My eyes, my knees, et cetera. And I get people's names mixed up. But the upside to being my age is when I studied computer science 30 odd years ago, design actually mattered what users think mattered. And we got taught that as well as learning how to program and databases and stuff like that. And I quickly came to the conclusion, you can't dismiss all user feedback, but if you've got a strong product vision, a lot of the times it's like, "Well, if you don't like this, get fucked because this is what we're building." And I still think that there's... Well, I suppose I'm asking you, is there an element of truth in the person with the product vision and the product managers have probably got a better understanding of what user needs more than they know themselves. Is that still-
Matt LeMay:
I don't think.
Jamie:
Or is it more nuanced than that?
Matt LeMay:
I don't think you have a better idea of what people need than they themselves do. I think that people are good at articulating their problems but are not responsible for articulating the solutions. I've had the pleasure of working with my business partner in the state, Trisha Wong, who's an incredible ethnographic researcher who really taught me how when you can understand somebody's world and their concerns and their realities, then you can leverage that subject matter expertise you have and say, "Oh, okay, I understand how we could build a solution that helps make this practice person's life better." If you tell them, "Do you want this doodad" They might say no because they don't know. But if they're not an expert in doodads, it's not their job to know. I think the other thing that's kind of interesting and implicit in this in terms of who is our user and who is not our user.
I'm putting together slides for a talk I'm doing tomorrow called, "Bringing Focus to Scale." Because I think we're seeing right now what happens when you have scale without focus, which is that everything falls apart. But one of this guy who I worked with asks every company he works with, "What is the appropriate scale for this business?"
And I love that question because I think we're seeing right now what happens when you say, "We're going to build for everybody and we're going to do things for everybody." And you can always add more people to build more solutions for more personas. But if you don't understand, if you're not focused, if you're not saying we're going to start and do the best solution for this group, then you're going to at some point wind up just firing all the people who are building those solutions for those people who aren't really appropriate to the scale or focus of the business you're building. So I think it's an interesting moment for seeing what happens when we don't think strategically and when we don't actually make the tough decisions that compel us to build for one group, not another group, or build one thing.
Jamie:
The problem is if you try to please everybody, you end up with a Swiss army knife that maybe nobody can use or even worse.
Matt LeMay:
Exactly. Even worse, you wind up with Facebook.
Jamie:
Oops. Yeah, Meta. Meta, the metaverse. Okay, right. There is another question. Now I think this sounds like more like strategy than product, but it might be a good one for you. Do you believe the Maxim, "Amateurs talk strategy whilst professionals talk logistics?"
Matt LeMay:
I don't think so. I hope not.
Jamie:
I didn't ask that question, neither would I by the way.
Matt LeMay:
I mean, I think I'm generally wary towards any maxim that thinks too highly of itself or anything that makes the person stating it sound too clever. Because I think the reality is we are all just muddling through trying to do the best work we can. So maxims that deliver absolutes are generally to be approached with some degree of scepticism. In my ever humble opinion.
Jamie:
I think that one comes from conflict. So from battles, the Germans, when they attack Russia in the second world war their supply line ran out and the same had happened to Napoleon. I think that's a military maxim that logistics and supply chains will probably, you get them right and any strategy will work. But of course you don't work, you're not invading Moscow right now, you're building digital products. So they're not-
Matt LeMay:
Apparently not.
Jamie:
Slightly different challenges. Right. Are there any more questions or would anybody like to grab the mic and ask my a question directly now?
Matt LeMay:
Yes, while I'm here please, ask away. I fear no questions.
Jamie:
While they're unmuting. Mark, do you want to tell us where your talk is tomorrow and if people can go and see it or is it a live event?
Matt LeMay:
It is a private, in-person event.
Jamie:
Ah, it's a private, okay. So unfortunately people can't come and see that. Okay.
Matt LeMay:
But if anybody is located in Paris, I will be there next week doing an event that's open and then in three weeks I will be in Hamburg and Berlin doing open product events in person. So if you are in Paris, Berlin, or Hamburg, please drop me a note on LinkedIn. I will give you details.
Jamie:
If you get those links to us, Matt we'll make sure that we follow up in the email to the participants today so that they can come and click on them and work out what you're doing next.
Matt LeMay:
Fantastic. Thanks so much. Yeah, if anybody feels like taking the train, if you're based in London, you want to take the train to Paris. It's the business expense I assume, for your business.
Jamie:
Anybody from Container Solutions Economy class only.:hat was a joke. That was a joke. See I had to unionize, premier costs. Does anybody have a question for Matt? I think Matt, we might be done. I really enjoyed that. I really, really enjoyed that. We got going with some great gossip from Ricardo and it really then led into a wonderful talk about product strategy and we are doing a lot of this at Container Solutions in the last few months. So for me it was really nice to get an external perspective. I'm pretty sure I speak for everybody when I say what a good, good session this has been.
Matt LeMay:
Thank you. This was a lot of fun. And if anybody comes up with questions afterwards, I'm usually somebody who needs time to think of questions. Please feel free to find me. I'm easy to find on the internet and send those questions through. I'm happy to answer them whenever they happen to come to you.
Jamie:
On that special note, then we're going to say goodbye, but we're going to say goodbye with a round of applause starting for Carla and Charles the key organisers of these webinars, a big round of applause to Mo and to Ricardo... For and of applause for me for facilitating. But the biggest round of applause is for Matt, our guest today. Thank you so much, Matt, and we'll see you all next time. Bye-bye.
Carla:
Thank you everybody. Have a great day.
Jamie:
Bye.
Previous article
