(cheerful electronic music) - I was a bit gutted because John mentioned "TRON" in his presentation yesterday.
So I feel like I've already been out-'80sed. So perhaps I can start by telling you a little bit about me. At the moment I'm a product consultant, and I'm really passionate about product strategy, how you set up product teams and how you do product practise.
Previously, I was VP of Consumer Product for Scout24, which is one of Europe's biggest marketplaces business. And as you can see, I've put up a photo showing my favourite German stereotypes of beer and leather shorts.
And that's really to counteract some of the problematic stereotypes that we see in Indiana Jones.
Before that, I worked at some of the usual suspects. REA, News Digital Media in Sydney, and Sensis here in Melbourne.
So let's get started.
My talk is about product discovery.
And I see product discovery as a heroic quest. I think that we're all heroes.
The reason it's heroic is that we're looking for hidden treasure.
And that hidden treasure is customer value, and product-market fit.
It's not an easy thing to find, and that's because we're not the first ones to look for it. Any domain that we're focused on has had other product managers looking at it. I think the fascinating thing about it is that I think we often underplay that heroic quest. Often, we treat it like the trip to Baker's Delight that we heard about earlier.
As just something that we can go and do and it's a process. I don't think it's like that so that's why I've looked to one of the great heroes from Hollywood, which is Indiana Jones.
Okay, I'm gonna start with something that I don't usually like to do, which is to ask a rhetorical question of the audience. Because it always makes me nervous.
Is anyone gonna answer? It's a Friday afternoon, what if no one puts their hand up? But I feel like I can give it a go, because this is a pretty easy one, right.
Hands up if you've seen "Raiders of the Lost Ark"? All right, some of you might even have the Betamax at home. (audience laughing)
So that was just about everyone I reckon, so let me ask another rhetorical question, hands up if you've successfully launched a new product or a major change to your product this year? So I reckon that's a much smaller set.
It's still a decent number.
And it feels to me like it's about what the data that I've seen suggests.
It's not something that happens every quarter, every six months, even every year, and that's because it's hard.
And so that brings me to the first lesson that I'm gonna take from Indiana Jones.
Okay, you ready? Lesson one, you will probably die heroically. And that's because it's really hard.
So this guy was a product manager.
(audience laughing) He's a product manager from Indiana Jones, but he's not Indiana Jones.
If we look at the data on how successful products typically are, and I did this in preparation for the talk. And the thing that really amazed me was because I thought I'm just gonna Google that famous Clayton Christensen quote. "95% of all products fail." You shouldn't take photographs of it because I don't think he ever said it.
It's fake news.
It's something that's just established in our minds and it's quoted a lot, but there's no evidence that he said it.
And he's actually disclaimed it, which amazed me. And I think it's amazing that if you think that product discovery is probably the most important thing we do as product managers, and we're all super data-focused people, and actually this key bit of data, we've really got a big blind spot on.
So in my research, and I was looking for a real number, I did come across this interesting academic survey of product success, and that's perhaps the one to go and visit because it just looks at all the research that has been done.
And the best number that I could find was that 42% of technology products fail in production, which doesn't sound bad.
But that doesn't include all of the ideas that never make it to production.
And some of the research that's behind that link, says that the ratio, is up to 3000 to one.
So 3000 ideas end up as one successful product. So suffice to say, it's really hard and you're likely to die doing it.
So that leads me to the second lesson that I wanna take from Indiana Jones and that's why do we die? And it's pretty obvious.
It's because everyone is trying to kill us. So if you think about that famous first scene of "Raiders of the Lost Ark," that's how it feels, to me, to do product discovery.
You've got an idea that you believe in, you're chasing after this bit of treasure, this product-market fit, this value for your customers and everything just starts going wrong.
You've got a collapsing value proposition.
Your customers don't want it.
You've got competitive products, you've got this guy trying to steal your treasure. You've got a closing market opportunity.
(audience laughing) And you can see the metaphor gets more and more stretched as I go. (chuckles) So you've got technology changes, you've got regulatory changes, you've probably got a window where this great idea is gonna work.
You've got unbridgeable usability gaps.
So your product needs to be usable.
You might have a fantastic concept that is theoretically valuable, but if people can't use it and use it pretty quickly and adopt it, it's not gonna succeed.
Crushing technology costs.
You've got this big ball of developers rolling down the hill behind you, and they're gonna crush you and your product if you can't make the best use of your team and get something out to the market that works in a time that is valuable to it.
And then even if you get all those things right. (audience laughing) You've got a sales team who might not like it. So that's lesson two, everyone is trying to kill you. But I think that this is, as I said, the most important part of what a product manager does. And I think Marty Cagan talks about this as the risks to your product.
Nicole talked about it yesterday, in her talk about continuous discovery, as assumptions. I like the term threats because it feels more heroic. And I find that you talk about risks and I think a lot of product managers kind of glaze over and think this is like a compliance thing, and I have to, like, put some stuff in a spreadsheet, and it's a risk register, and then I'll just put it away and it's done.
So I like to think of it as threats, and it's threats to your success.
Whatever you call it, I think the important thing is that we need to identify these things.
You know, what are the rolling boulders and the spikes and the gaps and everything else that's gonna effect your product and mean that it's not going to succeed? So you have to take them seriously.
And then the other really key problem I see with product managers using this thinking, and I think that most product managers do use this thinking, I think probably everyone's heard about the concept, but I don't think a lot of us really put it at the centre of what we do.
And I think often that's because we have this kind of 80% alive idea.
We have this sense that there's 10 of these threats to the product, we're gonna go out and do discovery, we'll understand them, we'll mitigate them, we'll research them, we'll solve them, and if we get eight out of 10 of them solved, that's pretty good, that's 80%.
But actually, life is binary.
You're either dead, or you're alive.
And so you're not 80% alive, you're actually just dead. (audience laughing) Okay, lesson three, you need a death wish.
So I think you wouldn't do the stuff that Indie does unless you put a pretty cheap price on your own life. (audience laughing) And I think that this is a good behaviour for product managers.
You should really revel in the threat to your product, and you should be actively going out and finding what are those things that are gonna kill it? I think what that means is that either survive or die quickly and cleanly.
Like starting with the things that you think you can deal with, and I think it's a really natural human behaviour is to look at the things that you're confident in, do the research where you think you're gonna get good feedback, and you kind of build confidence, it's actually waste. Because if one of these things is gonna kill your product, it shouldn't be the last thing you find.
It should be the first thing that you find, so that that idea can die and you can move onto the next idea.
I think this is often a really difficult mental shift for product managers, because I think product managers have to be passionate and they have to be optimistic and they have to be committed.
And so often we develop this behaviour of your role is the kind of sponsor of the idea, and that you're shepherding and selling the idea. Which I think is often a behaviour that gets us the kind of trust to be a product manager, but can sometimes lead us up the wrong path once we are a product manager.
And so I think you should kind of explore the pessimist with the slightly suicidal streak when you go out looking for these things that are gonna kill your product.
Okay, lesson number four.
Your boss has never been to the jungle.
So I don't know if you remember this scene from "Raiders of the Lost Ark," it probably wasn't the most exciting one, but I think it was a really insightful one to me. And it's where you see Indie, all of a sudden, is looking really awkward and self conscious and it's because he's out of his environment. And he's out of the jungle where, moments before, he's making these decisive life-and-death decisions and getting out of all of these scrapes.
And I think that this is often what happens when you find yourself in a boardroom presenting your idea to guys like this.
And I think it takes you away from what you probably believe as a product manager, which is this focus on discovery and understanding the chance of your product succeeding. And you find yourself, when someone says something like, "That's great, Matt, when are we gonna have this?" And you say, "October?" (audience chuckles) And I think that's because you're out of your environment, the same way Indie's out of his environment in this scene. What you need to do is to take your boss to the jungle, if they've never been there.
Or maybe they were a product manager one day, and you need to take them back to the jungle. So I think it's resist that temptation to give them certainty and instead show them the process that you're going through and the challenges that you're facing.
'Cause most people love the excitement of those tales, people wanna hear about what you're doing and what the challenges that you're facing, and the more you share that with them, the more you tell those tales of the jungle, the more they'll empathise with you, they'll understand the process, they'll understand the product, and they won't ask things like, "When are we gonna get it? "Why can't it be September?" Okay.
So I think I just covered this but I think it's the one thing I would also call out here is that I think sometimes, as digital product people, we get seen and connected to IT.
And so sometimes I feel like there's a connection between developing a new product and rolling out the new ERP system, which is because they're both IT.
And depending on the organisation you work for and how embedded product is and how embedded technology is, I think sometimes that's what get us into this kind of trap of wanting to propose certainty.
I think the thing that we really need to focus on is that there's a difference between discovery, and at that point we don't have certainty, compared to delivery.
Which something like rolling out the new ERP is really a delivery challenge, and that's where you can have certainty.
So I think it's up to us to educate our bosses and our stakeholders as to the difference and why discovery is different and why we need to embrace the uncertainty. Okay.
And I think the biggest culprit in terms of driving that certainty is something we've talked about a lot over the last couple of days, is roadmaps.
And I'm in the #NoRoadMaps camp, but I do understand that we need something. So I take this lesson from Indiana.
Lesson five, you need a treasure map, not a roadmap. And what I mean by that is that a roadmap is a communication device, and it was talked about really eloquently yesterday.
And we should think it about primarily as a device for communication, and we need to think about what we're trying to communicate.
And I think one of the problems I have with roadmap is just the name.
And if you think about it, a roadmap is something that you use to go back to Adelaide to see your parents for Christmas.
(audience chuckles) Which I do. And no one dies heroically going back to Adelaide. (audience laughing) So we need to change the metaphor.
It's completely the wrong metaphor.
It communicates certainty, and that's the last thing we want to communicate for discovery.
What we should be communicating is uncertainty in the prize. And that's why I think a treasure map is a great metaphor, because it's something that there is a huge prize at the end of it but it's uncertain.
And that's what the discovery process is.
I wouldn't advocate, when your boss says, "I need to see a roadmap," saying, "I haven't got a roadmap, "but I've got a treasure map!" (audience laughing) But I think that you can shape that roadmap with that in mind.
And think of it more as a treasure map and less as a roadmap.
So in thinking about the way roadmaps work, and I thought about how would Indie do a roadmap? And I came up with this, and I thought, because I've done these in the past, you know, you do your two-by-two matrix, you've got value and you've got effort.
And then you start thinking about all the treasures there are in the world.
And you start plotting them on this axis or these two axes.
And you say, the lost Faberge eggs, it's pretty low effort, they're only lost, we know roughly they're somewhere in Europe, but they're not so valuable.
You've got Atlantis, it's a whole city, that's gonna be worth a lot but it's underwater and so that's gonna be really hard on the effort stakes. So we go through this sort of process with a view to going, this sort of magic right-hand quadrant, that's what we're gonna do.
But it's actually asking entirely the wrong question. So what this implies is that we can do all of these things. We can have all of this treasure, and the only decision that we need to make is which amazing, priceless relic are we gonna pick up? And I think we all know that's not the case, because we know we're probably gonna die.
(audience laughing) So the real question is which of these can we get and get back home and survive? That's the real question.
So why are we using this framework and this device that focuses on the other question, which is how much value are we gonna get versus how much effort? And I think that because this sort of model comes from parts of business where there is more certainty. And I think we need to be conscious of the fact that uncertainty is the key driver, and so we need to think about it differently. So if Indie did take this little bit of analysis, and he put it in a roadmap, I think he would do something like this.
You'd sort of have your strategies, which is like I need to build digging capabilities, so I'm gonna start with the Tomb of Genghis Khan, When we've developed that capability, it will unlock the Ark of the Covenant.
We might have things like build a global brand. Atlantis would be amazing.
You find Atlantis, everyone will always know about you. You need to monetize, so we got on some treasures that are just cash.
Start with King John's then go to Montezuma's gold. We can do all of these things, but again, you're probably gonna die on the first ones. So the process is wasteful.
And it also sets up the wrong behaviours because what it does is that we communicate something like this, back in that kind of dusty university room from the previous scene, we communicate something like this and it gives us kind of short-term peace because it gives us this sense of control, it looks really impressive, you know, our bosses and stakeholders look at that and go, "That's amazing, we're gonna get all of this treasure!" And you feel good for the moment you're in that meeting. As soon as you leave, you're back faced with the fact that you're probably gonna die in those first trips. (audience laughing)
And you're much better off resisting that that desire to give certainty, and instead communicate how difficult it really is to do product management.
So be conscious of what you communicate, I think it makes sense to communicate things like strategy, sequence, focus on outcome. Do all of those things because it is important to communicate.
And I think that the really pure no-roadmap view of just the team focusing on itself is not realistic. So I think we have to communicate and we need some sort of map, but stay away from that certainty.
And part of the reason I think we need to do this is that we need to respect this guy.
Because he was a product manager, and he was probably a really good product manager, and he probably did the right things.
And for us to communicate that certainty assumes that it's easy, and it's not easy because people like him have died looking for the treasure. So wrap up.
I talked you through these five lessons that I've taken from Indiana Jones.
Number one, you'll probably die heroically. The reason for that is that there's lots of things trying to kill your product.
But the good thing is that you will have a death wish, which means that you're not terrified by the prospect of this death, you're embracing this likely death and putting your effort into understanding where these threats are and what the impact will be. Number four, your boss has never been to the jungle, so it's your job to take them there and communicate the challenges in the process. And one way you can do that is to use a treasure map and not a roadmap.
And if I can leave you with one last gory slide, it's this one. (audience laughing)
And that's, as a product manager, sometimes you're gonna be the guy on the left and you are gonna heroically bring home this treasure of customer value.
Other times you're gonna be the guy on the right and your idea is gonna die.
And that's okay, both of these people are probably doing good product management. (audience laughs) Thank you very much! (audience clapping) (cheerful electronic music)