Product strategy creation

Welcome to Definitely May Be Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, Peter Maddison and Dave Sharrock. So how are you today, Dave?

Excellent. It's been a great week, another good uh lots of great conversations about some of those interesting problems that uh so many organizations are struggling with at the moment. And uh I think uh what's been interesting is we're doing a lot of work right now around product, product discovery, product management, all of those things. I think there's a lot of attention being given to that, and I think that's going to dovetail very nicely into some of the uh points that we wanted to discuss today.

Yeah, I was I was having a conversation with uh an mentee of mine earlier, and uh we were talking about um the the building a new product, going into a new marketplace, there uh and the the challenge between deciding, well, how much of this do I build and uh how much do I listen to my customers, and at what point do I know that I've built enough that it can be sold in that marketplace? And these types of questions around how how do I know that my product is ready for the prime time?

Yeah, well, it's or it I mean that that whole thing of I mean, there's one hand uh on the one hand is how to know when your product's ready for prime time, that sort of product market fit, getting that takeoff that uh every company is sort of sort of seeking in one way. But the other one is how to even enter a market, what to go and do. There's there's a lot of companies out there doing a lot of very similar things, almost certainly to what whatever it is that that your organization does. So finding the the gap that allows your organization to excel becomes more and more challenging. I think, I mean, it it this is areas where it can just classic MBA texts really don't help, right?

Yes, yeah. There's the so I mean a lot of the classical NBA and people who come through that field get taught all of Michael Porter's uh sort of deliberate strategy, understand your marketplace as the five forces, you've got to understand all of these pieces about that market uh before you can really even enter it, before you can like design an approach, and and not knowing that will cause you to fail, I think is also a part of what's taught. Uh versus uh and that that was kind of a great way of looking at strategy back in the 80s and 90s, and it's still what's taught in MBAs today. Um, there's another big name in the strategy space called uh Henry Minzberg, who uh put more of the emphasis on emergent strategy, that your ability to operate and have a fast feedback loop and learn from your customers quicker, and building the engine to be able to uh create newer versions of your product faster would be what allowed you to succeed and that creating that emergent strategy. So your your strategy wouldn't be set in stone and understood before entering the market, it would emerge from what you learn from the market that you're entering. Yeah.

I'm always reminded anytime we get the A versus B conversation going on, is that you need A and B. It isn't A is right and B is wrong or the other way around. It's you're going to need to understand a bit of both. Because again, I think there are there are markets that I mean, even today, there are probably markets that you don't really need to understand. You just need to get into and deliver. There'll be something emerging there or or um pretty obvious. And in the past, that was much more, I would have argued, from what you're describing, much more on the porter side of things. Understand the market players, the barriers to entry, you know, all of the kind of macro effects that impact a market as to decide how to go and tackle that market. Whereas what you're describing on the emergent market side on Mentzburg's side is much closer to product-centric thinking that we see in many organizations today. And I think that has to do perhaps with just increasing complexity, sorry, not complexity, increasing competition in those markets where the differentiators become super important and understanding the market. So you're bringing something to market that directly tackles a customer group's needs or problems, pain points is the challenge, right?

Yeah, and I I think there are there's there's other elements as well where the the cost of entry depending on the the market is is often less. That the you can do things to try things out much more easily now due to the uh the capacity of technology, the the technology has advanced. Uh, and but there is also uh all of the complexity, but there's a lot more competition, there's a lot more people using those technologies, so you have to be able to respond much more quickly and learn from this. But but the tooling's there to help you do some of that. So there's this but the the rapidness of the environment that we exist in, the technology that supports that rapid change and uh the the changing nature of uh of the businesses and the uh market environments that we find ourselves all uh lean towards that emphasis towards that emergent strategy.

It's it's fascinating that with this topic comes up because I had I was having dinner with a friend yesterday and we were talking about exactly this this whole thing of the tools are there for us to, they've really become commoditized to be able to go and tackle a market and understand and learn. What's really interesting though is the those those sort of organizations that do the hunting and finding things then immediately have to scale. So if we're looking at the money going into startups and so on, it's now in the tens of millions of dollars, even like before that discovery has been done, almost like bets on what's going to happen in the particular marketplace. And that's not because of the discovery piece, but it's because of the need to scale that really, really rapidly and dominate the market, because the business models are about market domination, uh network effects and scale, uh, much more so than they are about a niche product that serves a tightly well-defined market that we can go after. Yeah, so how do you do this well? Well, it this is an so I know you you and I were chatting about this. We both of us use this great quote from Henry Ford that says, you know, if I went to talk to my customers, all they'd have asked for was a faster horse. And famously, Henry Ford sort of ignored that customer feedback, customer focus groups, whatever you want to think of, how it might have pursued, and was the you know, the the genius inventor, if you like, the person who brought the car black, any colour but blue uh as long as it's black, right? Brought that car to the marketplace. Um, what would you say to that? Is that something that you stand by?

I I think it's uh it is your A and B comment, right? It's it's a little bit of both. Uh, there's a you need to listen to your customers to understand whether what it is you're building has the is delivering some sort of value that they're they're looking for. Where you've got to be careful in listening to your customers is jumping on every single thing that they ask for and saying, Oh, I need a new feature, I'm gonna build that new thing. It's like, and which because once you do that, you start to dilute your offering uh in the marketplace and your the the immediate under the under level of understanding that's needed to see what value you are offering to that marketplace now becomes more complex because you're instead of it's like we do this one thing and we do this one thing really, really, really well, and we do it better than anybody else in this marketplace. It's we do this one thing, we do it all, but we also do a little bit of all these other little bits and pieces and other stuff off to one side.

But let me tell you about all of this and then every every single time I think about this sort of feature explosion, I think about Microsoft Office products and the banners along the top, the ribbons along the top. And there is still ribbons on certain Microsoft products, many of them actually. I have no idea what they do. I kind of hunt in a bump into them, and you suddenly find, oh my goodness, I don't know where this is going. Um, but that's I mean, that speaks to the sort of vast audience that use some of those products. What what I what was really interesting when we're just having this conversation beforehand is the realization that it isn't it, it's almost like we come from a technology space, both of us, and we very much see that jump to solutioning, this this dive into solutioning, which is so I mean, we all experience this. And what Henry Ford was, I think, really saying is if we go and talk to our customers, we would have solutioned for them. We would have come back with a feature that we could add to an existing product, faster horses, right? Whereas and this is where I think if we go to uh our customers and and totally squash that jump to solutioning, now we're in a much better place. And that's what things like empathy interviews are all about is how to how to withhold our own decision making intuition jumping to a solution and how to sit and listen to where the customers are coming from, because they will often then articulate, actually articulate the space around a pain point or problem that they have or a need that they have. They very rarely they don't customers don't tend to know the need, otherwise they can go and ask somebody for it and they can get it from the market. But what they can often do is uh kind of map out the space around that need or or pain point. And I think this is something where we really have to recognize that going to customers, most of the time we need to be in that empathy mindset to understand the space that they're trying to map out for us rather than go with a checklist of features that we want to come back with, uh, because that's not going to get us to sort of um well, it's not going to identify these gems in the marketplace that we're able to really differentiate and go after.

Yeah. Well, and then this is the the piece of as um as you were saying, it's uh if I if I ask us, well, why do you want the faster horses? Well, I because I want to get from A to B in less time. And well, if uh well if I gave you a fast horse or if uh like what else, why would that be? Like, why are you looking to get from A to B for what what would need to be true for that to happen? And start to listen to like why is it that this is happening, right? It's uh so I mean that that's where you're starting to get into well, what is the actual underlying need that's driving this? Um so so when somebody comes up and asks you for the hey, I I I wish your product did this, it's like, well, yeah, what what's the trying to solve?

I really I I think um so so I bump into uh this concept of jobs to be done, uh Clayton Christian's jobs to be done piece uh quite frequently. And I think there's a misunderstanding in that in some cases, people try to replace user stories with jobs to be done. I I think jobs to be done is a lot more strategic than that. Whereas what we're describing right now, that customer pain point, customer need, that's the jobs to be done is a really great descriptor. If I go in with a mindset to say, what is the job you are hiring a particular product to do, that becomes really interesting. And there's the great story that, if anybody reads at all about jobs to be done, about uh the milkshake, McDonald's thick, you know, gooey milkshakes. And the intention there was to understand why do people buy these milkshakes at 6:30 in the morning. And the reality was that it wasn't because they wanted a milkshake. Um, what they were finding is customers tried bananas and they tried Mars bars and they tried whatever donuts and things, all of these to give to to stave off hunger until lunchtime. The job to be done was how can I can I get to lunchtime with enough of something just to keep me going? And that's what the milkshake was doing, which a donut didn't do, which a banana didn't do, um, which a candy bar or whatever it was wasn't doing. And that one becomes really interesting because now you're seeing that product not in terms of this transactional one thing that it does, but in terms of something that's solving a problem. And that's again that unarticulated customer need or pain point. You have to explore that. Nobody's uh identifying that as the reason they're buying a milkshake.

Yeah, well, exactly. Because you're you and and this is where it is valuable to go talk to the customers and find out what is it underlying it. Whereas so it's not that we shouldn't listen to the customer, we have to go listen to the customer, we have, but we have to, as you say, listen with empathy, understand what is driving the the need, like why are they uh coming and asking us for this thing as we look to build it out. Um, I think um, especially as you're entering the like a new marketplace, uh like where it isn't an established product or you don't have a product in that marketplace that you're entering. Um, if you but you can see an opportunity, there's there's something I see in that so there's a first piece of like I I see an opportunity because there's something that isn't being done as well as I feel it could be in that marketplace, if it's uh versus a hey, I'm gonna create an entirely new market, which is a slightly different piece, although the two things can end up being related. Um the so but I have to understand like well, what is that thing? And like, so why might somebody want this? Like, is it valuable enough to them that uh that somebody's gonna come and buy this? And then what is it that I need to create and to what level such that I can learn whether this is going in the right direction?

Well, it's uh as you're describing that, Peter, I'm realizing there's another A to B sort of line, which is the explore exploit. And we've talked a little bit about that when we're talking about complexity, but what you're describing there is this, and I think this is this really kind of brings us back to the Porter um uh Minzberg conversation because there's the explore side of things to find the emergent market, and we have to explore that. We don't have to be operationally excellent, but we do have to be empathetic to our customers to be exploring and understanding and observing the markets to find those opportunities. But once the opportunity is found, we've we move very, very rapidly into the exploit at I think that that transition from explore to exploit has become much, much, much more rapid in recent say, let's say decades, not years, but over time that that kind of flip over from being in an explore mode to being exploit has just got more and more rapid with technology and various other things. And this is where the capability for operations comes in. You were talking earlier um about Toyota and their ability to go and open up a market, and operationally they're excellent at going and doing the exploit. If you're not excellent at the exploit, you're great at exploring, you lose the market because somebody else will come in and exploit it instead of you. So you kind of need to be able to do a bit of both.

Yeah, and it's this how can I once I have the the product there, how can I make sure that I'm faster than anybody else at listening to the customers about how to improve my product and make it better? And uh and that getting that feedback loop as fast as possible, which is of course on the technology side, but but for all of this, it's where concepts around agile and DevOps and lean and this is where all of this comes in. It's like how do we eliminate waste from that system to improve the feedback loops, to be able to uh break down problems into small enough pieces that we can start to address them. All of this comes into play as uh improving that operational excellence.

It's almost like the the ingredients in a great recipe, right? You need both to be able to empathize, to observe your customers, to identify those needs and pain points, but you also need the operational skills to be able to then deliver something, fine-tune it, keep it relevant as you drive into that market.

Yeah, for sure.

What would you take away from this? Two or three things. I think we're kind of we've we've actually touched quite a few things here. So there's some interesting points to bring together.

Uh I I think some of the some of the key ones um is the uh as you put it uh here on the like problem, not product discovery. It's not it's about understanding, listening with empathy, understanding what is the customer actually looking for that's driving the need that you're looking to satisfy. Like so, what is what is causing that? Uh asking like why, why, why, why? So, why is that? What is causing that? It's like going through and uh and understanding that piece of it. Uh, I think that one's critical. I I think uh another one is the one that I was bringing up there around the the uh emphasize emphasizing emergent strategy once you understand the uh the market that you're entering, like uh uh the ability to rapidly learn and adapt to what it is you're building and learn, improve on it, um, so that you can uh once you've got that problem, that you've got the capability to then improve and uh on the product that you're putting out there and so that customers are getting the value. What else would you add?

So um I think that uh you know the the balance between that explorer exploit thing and and the the balance between so that transition of moving away away from the observing, listening, empathizing to accelerating the delivery. So, and there's there's a whole conversation. I think we need another chat about this around product market fit and how we identify it. But that transition from one mindset to the other, I think is one that many organizations are really struggling with because it used to be done in separate organizations. You'd you'd get to a certain point and then you'd you'd have time to make that transition. And I think the amount of time available to that is is shrinking all the time.

Awesome. Well, uh, as always, enjoyed the conversation. If uh anybody wants to send us feedback, they can at feedback at definitely maybeagile.com. And don't forget to hit subscribe because uh we always like more subscribers, right? It's always a fun thing to have. Always fun, yeah. Yeah, okay.

Well, great to great to chat to you again, Peter. Looking forward to the next one.

Yeah, likewise. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.