Product discovery practical guide. Tips and tricks to high performing teams. Anthony Marter

Well, like I said, good morning, everyone. My name is Anthony Marta. I am down here in Auckland, New Zealand, where it's about half past 11 in the evening. So end of my day here, start of your day. So who am I? As Anastasia mentioned, I'm currently working with a fintech called Harmony. I also do a bit of consulting for other organisations, including a large grocery retailer. And I'm really kind of fascinated by the interaction between product people and teams. And that drives a lot of my thinking and a lot of what I want to try and communicate today as part of this presentation is to really dig into how the interaction between product manager and teams is really the secret to the success of high performing teams and the part that discovery plays in that. Previously, I've been head of product, product manager for a bunch of platform organizations, which you probably won't have heard of in Europe. But if you happen to use the McDonald's app on your phone in Europe, then you probably use the platform that I used to be head of product for. It was a fascinating job. We had about 200 million users on the platform. It was a fascinating organization to work for and international. And down here, I'm also the organizer for Product Tank Auckland and I'm the chair of Product Aotearoa, which is a New Zealand wide not-for-profit that we've set up to try and manage and outskill product managers across New Zealand. So anyway, that's enough about me. I would love to connect with you and talk more about this presentation afterwards. So feel free to scan that QR code that will take you to my LinkedIn profile. Although I'm pretty easy to find, there's literally only one Anthony Martyr in the entirety of New Zealand. please do connect with me after the presentation. So what problem am I trying to help you solve? So I think Nils kind of alluded to the idea of a feature factory in his presentation earlier on. And if you haven't already, do read the fantastic article by John Cutler about being in a feature factory. And so that's an environment where as a product manager or product owner, you're getting really frustrated because you feel like you're just a project manager. You're just being told what to build. You're not having any real say in the problems that you're trying to solve for customers. You're not getting to work with customers. You're just getting told, you know, here are all the things that you should be building and just this long list of features and you work with a delivery team and they get shipped. And what I want to do is give you some practical steps about how you might be able to move the dial around that and move towards the world if you've read Marty Kagan's book, Inspired. of real product outcome lead development, you know, really working with customers and understanding what their problems are and trying to solve their problems in the most optimal way possible. So that's the problem that I'm trying to solve. Now, Nils also talked about Teresa's book and his talk earlier on, highly recommended as well. Please go ahead and read that. So I'm not going to dive too deeply into what product discovery is, but the really, really short version is that The most expensive way that you can find of whether to find out whether or not something is actually worth putting into your product is to build it. And, you know, if you've been around product for long enough, you know, everyone's probably built something that they put into the product and it didn't really land with customers and, you know, maybe in retrospect, maybe we shouldn't have done that. maybe we could have invested a little bit of time earlier on in the process and analyzed whether the thing where the customers thought what we're doing was valuable to them. Is it usable? Is it feasible? Can we build it and maintain it? Is it viable for our organization to support in the long term? And lastly, is it actually ethical? Is this going to get us sued or on the front page of newspapers all around the world? Maybe if we've invested a little bit of time in that upfront. we could have not shipped those things that make us go, oh, my God, that was just terrible. Why did we do that? There's a statistic from Google that, and I can't remember if it was 50% or higher than 50%, something like between 50% to 90% of all of the things that you think might be a really good idea to put into your product. actually turned out not to be. And that's not to say that they fail completely. They just might not have the impact that you thought they were going to. You know, when you're a product manager, you're doing those return on investment type calculations. It turns out that wasn't such a great idea afterwards and you did after all, and you didn't get that return on investment. However, what I see most organizations doing discovery, it looks kind of like this. Customer has a problem. somebody in the organization comes up with a solution and we spend our time cycling just on the will it work. So we, you know, and we're sort of in validation mode. We're not really discovering much about whether or not this is actually a worthy problem to solve for our customers. We're just figuring out will it actually work. Again, Nils alluded to this in his talk and I'll reiterate it as an example of an opportunity solution tree. So what we really want to do is customer is trying to achieve something. what are all the different ways that we could help the customer achieve that? So we've got a bunch of different opportunities and we've got a bunch of different solutions that we could test to solve that opportunity. An important thing here is, as you can see it, that on the right hand side of those trees, that there's a lot of solutions. And we need to try and filter out the ones that are actually going to work. One of the ways I've seen teams and organizations sort of fall off the wagon here a bit is that they are still biased towards one particular opportunity, one particular solution. Maybe that path that I've highlighted in red there. And whereas the one in green, maybe that was where all the gold was. Maybe that was the one that would actually land better with customers. So that's what product discovery is all about. We're trying to find the most appropriate solution for the customer. We're trying to test it up front before we actually go ahead and commit to putting this into our product. Importantly, we're not trying to validate it. We're just trying to get some indications that we're on the right track. And this is the kind of thing you might want to do quickly. I think Marty Kagan said is that your teams could be cycling through 30 different sets of opportunities and solutions in a two to four week period. You want to be churning through lots of things because that way you're throwing away those. for that 50% to 90% of bad ideas before they have a chance to make it into your product. So that's all well and good. And one of the things I find about coming along to these conferences is that you hear all these fantastic ideas and then you go, oh my, that's not really relevant. How do I actually do this? How do I actually get my organization to do this? Because I'm just getting presented with this long list of things to build. How do I get to the state where I'm really getting involved in the problem space? So firstly, some tips. The first rule of Discovery Club is don't talk about product discovery. One of the tough things that you very quickly realize when you're trying to get this kind of thinking embedded into an organization is that you're asking your organization and asking the people who are thinking of these great ideas that their ideas might be wrong. You're suggesting to them that you've got all these really, really smart people in your organization. They're coming up with all these ideas and we're going to build them and it's all going to be amazing. And you as the product manager are the one who's going to be telling them that their baby is ugly. The thing that they're building is actually not really going to have the impact. So you have to be sensitive about this. And it is kind of something that is to best approach with caution. So don't hit them with, hey, we need to do discovery, stick out front. I've got some other ideas about things that you might be able to do instead. So kind of as I was alluding to in that statement there, somewhere in your organization, product discovery is actually happening. Someone is doing that translation between what a customer needs and what your organization needs to build. Now, they might not be doing it very well. It might be a very shallow analysis, but it's happening. And you need to find out who those people are. It might be your CEO, it might be a salesperson. Who are these people? be sensitive to them. They're really smart, you know, particularly if you're in like an early stage startup, it might be a founder who's been sitting there noodling away on what the customer needs for years maybe before they decided to found the startup. So as a product manager, you have to be very sensitive to that. One of the real anti-patterns I've seen is product managers going into a relatively early stage startup as it's starting to scale. And that's why they got hired because the founder can't do the product stuff anymore. And the product manager comes and says, right, we need to do product discovery. We need to spend all this time analyzing. Are we doing the right thing? And the founder is sitting there going, who is this person like? What do they even know about the space we work in? I've been thinking about this for a very long time. So being sensitive is really important. A few steps that you can go through to try and get this thinking into your organization. And the first step is create some stories about the problem that we're trying to solve. And so here's where we're not trying to chip away at this problem a little bit at a time. And I suggest starting, Anthony mentioned in his talk previously, starting with the team, starting at that delivery level and talked about that example. That's kind of a good place to start with this is look at what's in their backlog and start having a conversation about, well, when we build this thing, how might the world look different? What difference are we going to make in the life of our customers? And also, how might we measure that? How would we know that we've made that difference? And that starts to shift the conversation from just talking about the what and the how, like, we've got this thing, we're going to build it, to... actually what are we trying to achieve what outcomes we're trying to achieve and this can be a really fascinating process to go through because you involve your stakeholders in that conversation your conversation goes something like you know okay so when we build this thing this is what the world's going to look like for the customer it's and it's you know look it's going to really move our um engagement metric, like we're going to get more people engaging with our product and the stakeholder might go, no, no, no, this is a retention play. We're trying to retain our customers by doing that. Oh, I see. Okay. This is a problem that we're really trying to solve. We're trying to solve a retention problem. Maybe we might reframe what we're building around that. So just by kicking off that conversation, creating a story about how the world might look different for your customer. can be really, really, really enlightening. And as I said, it will kick off really good conversations with your stakeholders. And you're also starting to build trust with your stakeholder that you understand their world by not just asking them, what problem are you trying to solve? It's the real bad thing that us product people do is we start with that question, what problem are you trying to solve? Valid question, but not really helpful. And saying, well, I think it doesn't look like we're trying to solve this problem. Starting a conversation like that can be far more powerful because it builds trust with your stakeholders that you actually kind of understand this world and you're not just asking what problem you're trying to solve to be annoying. A little bit of a side note on that is when you start asking about how we're going to measure this, sometimes that can be a bit tricky. People were looking for that perfect metric. bother trying to find the perfect metric, just find something that's good enough. And maybe it's just like, OK, let me ship this. We'll have a conversation with three customers and see if it made a difference or not. Don't try spending a lot of time noodling on what that perfect metric might be. Just find something and get going with it. If your organization doesn't have a good metrics framework already, if it's got a good one already, great, go with that. Then step two is find the facepalms in your organization. I mentioned earlier on about we've all had those things that we've shipped and kind of really wish that we didn't. And these can be really powerful. Again, you have to approach this sensitively because you might be treading on toes in the organisation. People who were, you know, really, they really cared about this thing and it turned out not to have the effect that they thought and they're a bit embarrassed about it. So you do have to be a bit careful, a bit sensitive with that conversation. But just storing up a few of these stories of you remember when, when we did this thing. and it didn't go so well because that's that kind of starts to form your pushback when somebody comes to you and just says look product manager just build this thing or product owner just build this thing um you can tell you but you remember when we didn't spend some upfront time last time and it all went a bit terrible you know maybe we should oh yeah okay let's let's do that and um There's the organisation I'm working with at the moment, Harmony, there's one exec there, the COO, and I can't remember what the example is exactly, but there's this great example there that every time something comes up, when he comes with that, you know, you must feel this, they're like, yeah, but do you remember when we did that thing before? Let's spend a bit of time in analysing. Oh, that's right, I can't remember that now. So store up those war stories, just keep them in the back of your mind, ready to kind of pull out at the right, appropriately sensitive moment. And so once you've done that, you've been having conversations with your stakeholders around, you know, what is the outcome of the thing we're working on really look like? And you've got some of those war stories stored up. You've now hopefully built some trust with your stakeholders that, you know, maybe this process called discovery might actually add some value. And you kind of discover, oh, there's this framework out there that we could use to do this in a better way. And it's called product discovery. And this is what it looks like. And this is what we can do. And so now that you've built a little bit of trust. you can then sort of start implementing some things and maybe that's given you the space to be able to do that. If you've got an existing business case or PRD, product requirements document type process in your business, that's a good place where you could potentially look at trying to merge this in and sort of say, you know, hey, maybe the discovery is the thing that leads into our business case. It's enough for us to gather enough evidence that the business, you know, we should proceed with this business case. But don't try and do everything at once. Try, you know, find a small test case, find a small thing that you could apply this to because what you're trying to do is you're trying to build trust with your organization that this process and this practice is going to add value. Okay, cool. So we've sold the dream to our stakeholders and they go, yeah, go for it. Let's try this discovery thing. How can we bring the team in and what difference is that going to make? So you remember I started off, I showed that, you know, okay, we've got our product manager, they're out there listening to the problems and customers. They're bringing things to the team and the team are just in that sort of solution, will it work kind of cycle. They're pushing discovery down on the team and that doesn't really help. It's not a really good place to be. What you want to do is you want to try and bring your team back up into the discovery, get them talking about the customer problems. I really love what Anthony was saying before around bringing customer interviews, actually getting the team really deeply involved in that customer interview process because inevitably you'll get that one engineer that goes, I didn't, I never knew that. I didn't know that the customers used the product like that. Oh, maybe if we did this other thing better, we could solve all these problems. And as a product manager, that might be something you've never thought of. There's a bunch of really super smart people around you. give them the space to come up with these kind of things because they'll think of ideas that you never did and other people in your organization would never have done for because they're so deeply involved in how your product is put together and how it works. So that's cool. But when? Our team's got this backlog. They're full of user stories and technical debt and production support and whatnot. And when is our team ever going to have time to do this stuff? They're already overloaded. Well, guess what as a product manager if you want to make this work you've got to prioritize the time to do product discovery into your team's backlogs and your success metric should be that in your sprint reviews or whoever it is that your team makes transparent what they've been working on the team is talking about discovery the team is talking about the things that we we thought about for a customer and ideas that we threw away because they were bad ideas as after doing a little bit of analysis we found that we still have things to do we didn't do them If the team are talking about that, then you've succeeded. On the flip side, if the team is saying, oh, we're so overloaded, the terrible, horrible product manager made us do all this discovery work and it took us away from the stuff we're supposed to be building, you haven't quite got it right. You need to kind of adjust your approach to the team and give them the space and the headspace to be able to think about the stuff. And I use that word headspace very deliberately because your team might be... completely overloaded with work and they just don't have the space to be thinking about customers, just like we've got all this stuff to build, just let me build it. Help them get that headspace because most, not all, but most engineers will actually really enjoy having that time aside from just the day-to-day build. And then my last tip is make it visible. Once you've got this going, you have to make the value of it visible to the organisation. Be really transparent about the things that we've killed, all the stuff that we brought through this process and said, not a bad idea. We did some analysis on this. It's not feasible. We can't build it. Or it's not valuable. Our customers don't care enough about it. Or it's not terribly ethical. It's going to put us on the front page of the newspapers because that reinforces those war stories that we talked about earlier on to sort of say that, you know, hey actually doing this has real value. It also encourages opting in from other areas of the business. So if you're bringing, if you're in this transparency, if you're bringing in other parts of the organization like marketing or support operations, not everything, not every problem can be solved through technology. Some of it might be a marketing campaign or an operational process or something like that. And you might have a marketer, you know, they'll see that you're doing discovery on this thing and they'll put their hand up and go, hey, we could solve this this other way and then you can bring them into discovery. It's not all just about building technology to solve problems. It's about just solving the problems. So you're probably thinking, okay, well, that's really good. That's all nice ideas, Anthony, but it's never going to work here. It's never going to work in my organization. Well, as I said earlier on, someone somewhere has that discovery tree in their heads. And as a product manager, you've got a choice as to whether you own that process or don't. And if you really want to own it, you need to, as we started off, you've got to get into their heads and you've got to start thinking about the stuff. Otherwise, you're just going to be perpetually in that feature factory kind of mode. And then hopefully through those ideas that I've given you around, you know, starting the conversations about outcomes with your stakeholders and the war stories, you know, you can get those conversations and build enough trust that that person who's doing that starts to trust you to be able to facilitate that process and do that with your team. And so just to remind everyone of that success metric, if your team are the ones who are collectively deciding to not do things, then you've succeeded with this process. It shouldn't be you as a product manager going, I see the evidence, that's bad, that's good, that's bad, that's good. It should be the team coming to you going, hey, we reckon that's bad, we reckon that's good, we reckon that's bad. If you've done that, then you've succeeded with all of that. And it'll be amazing. Give it a go. See if it works. Thanks very much, everyone. We can break for questions. I see there was something in the chat, Anastasia. Thank you so much, Anthony. That was interesting indeed. And we have a comment from Joshua Bambala, who's been really active during our conference. And thank you so much. What he says is truly amazing. Building trust, sensitivity, and creating stories of the... futuristic impact to the customer with the stakeholders, because sometimes the problem is not the problem. And the stakeholders attitude and feedback can become a bigger problem. Oh, yeah. Yep, that 100%. Yeah, Joshua, I 100% agree with that. I've seen so many examples of, you know, just where an internal stakeholder perceives something to be the problem that we're trying to solve, and it actually turned out the customer had a completely different problem in it. geez, if we just had that damn conversation with the customer, we would have had the opportunity to avoid that. I was actually having a conversation earlier this afternoon here with someone talking about the idea of the curse of subject matter experts in an organisation where you've got people who are like that you know they've been with the organization since the beginning and they know everything damn it because they're so experienced and they've kind of lost that curiosity with the customers and and you know getting around them is really hard and the best way to get around them is is comes back to that trust thing find ways to build trust find ways for them to you feel like they appreciate you know what their world looks like um yeah and take spend time with them okay i think we've got they uh that's kind of weird um a spammer in the system maybe we need to kick that person out that's right that's my first that's my first ever zoom bomb well okay and um that's my personal question because i was really curious you didn't mention that i mean i mean you mentioned that but uh not in the detail how to really measure that the product changed the life of the customer i mean what are the ways you said there are there are several ways that the company can use but what are they yeah i'll roll out the standard product manager answer to that which is it depends um it's a bit of a product manager and joke that that's our answer to everything it depends um but but a few a few actual concrete so just had a few concrete examples um so just said i'm working with a grocery retailer right now one of the things that they find hardest to measure is in-store availability, like trying to measure whether or not something is actually on a shelf is really tough. It's a tough problem to solve. But that's actually not the thing that really matters. What matters is whether or not the customers come to the store and feel like they came away with the thing that they were looking for. And so measuring things like that can be as simple as, you know, as a product manager or even as a team going down to the store, spending a bit of time with the customers and just saying, hey, when you came to the shops today, did you find the things that you were looking for? And so as I said, it might just be that qualitative, you know, having a conversation doesn't, you know, the way to measure your success of a particular change that might hit that metric. might just be a qualitative conversation. It doesn't have to be quantitative. And this is where I see organizations getting really hung up on quantitative metrics. You know, we need to find some magical AI camera based thingamajig that views with the products and just have a chat with a few customers and they'll tell you whether or not you're on the right track. Because what you're looking for is that it's a directional thing. Have you moved the metric in the direction that you kind of hoped or not? All right. OK, got it. Okay, so a simple conversation can help in some ways. And we have another question from our chat. Being sensitive to the stakeholders, do product managers have time? Was it from Joshua? Yes. Yeah. From Joshua. So being sensitive to stakeholders, to product managers, have time to study the stakeholders. I would strongly advise that you invest in studying your stakeholders and understand what makes them tick. I remember, Anastasia, I think you asked one of the earliest speakers about what mistakes did they make and what did they feel like they could do better? And for me, it's always been investing time in relationships. Forget all the product management practices and processes, the more you can build. relationships with the stakeholders around you, particularly those ones, as I said, if you identify them as being the people who are doing the problem to solution conversion, the more that you can get inside their heads and build trust, the more likely you are to be successful. And it sounds simple, right? Like, it's a bit like, well, yeah, of course, but it can be, you know, when you're trying to... run with a team and help go to market and you've got a million other things to do with a product manager it can be really hard to to free the time to invest in that and so you you do need to make that time to invest in those relationships okay my challenging question the same that i asked anthony okay uh anthony murphy who was right before you it's a banner question if you had a banner for all the product managers that all product managers could see, what would be written on that? How would I sum this up? Invest in understanding the why. And I think Neil started with this in his talk earlier on. Invest in understanding the why. If you don't understand the why, you understand the problem that you're trying to solve. And as I said, it's not just about... beating your stakeholders with, you know, tell me what problem it is you're trying to solve kind of question it's investing in. And I'm just really deeply feeling for yourself, like you know what's going on and just continuing to question until you unpack a bunch of assumptions around something that you're building. You know, really deeply understand it because if you don't, somebody else does. And the risk is, of course, if you're the one that's on the hook for getting this thing to your customers. the risk might be that you end up putting the wrong thing out there and you miss the problem. I think it was Josh just said earlier on, the problem is not the problem. You end up solving the wrong one and badness ensues.

Anthony Marter, Product & Delivery Coach at Harmoney presented "Discovery - the secret to high performing teams"
1. User story.
2. Finding facepalm
3. Solutions
+How to bring the team into discovery.
++How to find time for discovery
+++More tips and tricks in this video presentation from the first united ProductCamp "Europe & Worldwide"

00:00 Introduction
02:50 Product discovery
04:35 Customer (user) - problem - solution
04:58 Opportunity-solution tree
06:52 First rule of discovery club
09:08 Step 1 - Stories
11:50 Step 2 - Find facepalms
13:16 Step 3 - There must be a better way
14:38 Team in product discovery
15:48 When?
17:13 Make it visible
18:35 Having discovery tree in heads
19:15 Q&A section

Subscribe to our channel to get the latest product management practices twice a week. Special thanks if you liked this video.

Become a member of #dgtlcast - community for #productmanager that organize user-made (un)conferences - #Productcamp - the series of #networking centred events