We’ve run a number of podcast episodes about product discovery because it’s one of the hardest things to get right. Even the most experienced product people find it hard to avoid common mistakes. This week, product coach and consultant Anthony Marter joins us on the podcast to chat about the tricky balance between strategy, business case, and discovery.
Featured Links: Follow Anthony on LinkedIn and Twitter | Product Aotearoa | Teresa Torres on ‘What Roles are Represented in a Product Trio?’ | Marty Cagan on ‘The Four Big Risks’ | John Cutler on ‘The (Messy) Shift to Starting Together’
Episode transcript
Lily Smith:
Good morning, Randy.
Randy Silver:
Hey, good morning. Really? It’s morning. That means we must be talking to someone in a country where it’s lovely and sunny at the moment.
Lily Smith:
Yes, we are. This morning we’re chatting to Anthony matar product consultant and coach based in sunny Auckland, New Zealand. Well, it’s sunny right now.
Randy Silver:
We chatted about discovering an agile world the differences he has with Theresa Torres when to use a business case, and quite a bit more actually, you know, I always wish we could do these chats in person. But being in Auckland right now just sounds so amazing compared to the weather over here.
Lily Smith:
It is a bit miserable today. And I’d love to see the business case that you have for that trip. Anyway, let’s get started. The product experience is brought to you by mind the product.
Randy Silver:
Every week, we talk to the best product people from around the globe about how we can improve our practice, and build products that people love.
Lily Smith:
Because they mind the product.com to catch up on past episodes and to discover an extensive library of great content and videos, browse for
Randy Silver:
free, or become a mind the product member to unlock premium articles, unseen videos, amas roundtables, discounts to our conferences around the world training opportunities.
Lily Smith:
My new product also offers free product tank meetups in more than 200 cities. And there’s probably
Randy Silver:
Anthony, thank you so much for staying up late and joining us on the podcast today.
Anthony Marter:
No worries, guys happy to happy to join in. For
Randy Silver:
anyone who doesn’t know who you are already. Can you just give us a brief introduction? Where are you? What do you do these days? And how did you get into product stuff?
Anthony Marter:
Alright, well, I’m from the future down here and we are officially 12 hours ahead of you guys and most other people. So we said that we’re from we’re from the future down here. from Auckland, Auckland, New Zealand’s base down here been in product about 10 years and lessons, which sounds scary every time I say that. About half my career has been sort of engineering, software development and whatnot. Before that, I kind of have a funny role. At the moment. My official title is product and delivery coach, which sites in four days, my week working for FinTech helping to coach their product management team and their engineering team. So sort of mixture of product and agile coaching. As well as at the moment, I’m actually acting as a product manager for the platform, there’s an interesting role. And then I spend another day a week doing consulting, currently working with a large grocery retailer down here on trying to embed product processes and product practices and whatnot, which is very interesting. They’re very large organisation, a very good fund kind of kind of role there. And so I just generally help out organisations down here with their with their practice. I’m also chair of an organisation called product LTO, which is a New Zealand wide organisation where we’re trying to join and connect product people from across the country down here in New Zealand, to support each other and learn and grow together, sort of as an offshoot of what we’ve been doing down here with that product tank.
Randy Silver:
Excellent. And I’ve done stuff with large grocery chain here in the UK in the past, it’s a really interesting sector with all the real time delivery and everything that they’ve got to go on. It’s it’s, you know, you think doing deliveries hard, and then you didn’t have to factor in freshness. It’s just so much harder.
Anthony Marter:
Yeah, yeah. And then in in from an organisation, which is has come from a very traditional kind of background and hasn’t yet quite yet had the realisation that their technology organisation that does grocery not not the other way around, but we are working on it.
Randy Silver:
Yeah, good luck. So we asked you on today, because you did a talk for mine, the product conference a while back and wrote an article about it was really interesting. And you’ve got this great role, as you said, where you’re doing the coaching for both product and delivery practice. So one of the fundamental things that we try and work on ease is discovery in these cases, and it can be hard to fit it in and you start off. One things you start off with, I want to ask us, Why shouldn’t I call it discovery? I mean, it’s just the word. It’s a word we use all the time. What’s What’s so bad about that word?
Anthony Marter:
Um, it depends on the context actually. And that that was a slightly tongue in cheek comment in my in my presentation, but where it kind of came from is sort of hearing about product managers and also making this mistake myself coming into an organisation particularly in a startup where the founder, the other people in the organisation has been a lot of time thinking about the context of what they’re trying to do. And this product person marches in there and says, we need to do this thing called discovery we need to reinvestigate the problem and I’m going what? You know, we’ve been thinking about this for a And that was really sort of trying to emphasise that, you know, you have to be diplomatic and bringing this thing into an organisation because you’re doing it with the right intent, you’re trying to make sure that what the organisation is solving the right problems, but you’re dealing with people who think that they’re solving the right problems, or think that they understand the problem. And so sort of coming at it a little bit, obliquely, can can lead to far greater success than trying to take a hit on. And then the other thing is just a language thing, you know, we call a product discovery outside of product management, I don’t know that that term is very well understood as well. So it’s, it’s setting the context of what it is that we’re actually trying to achieve, before we start using some of the language that we’re kind of familiar with in the industry.
Lily Smith:
I think that’s a really good point, actually, about when you start to, you know, introduce discovery if you’re in a new role, or something, or you’re kind of new into like a different product in the company that you’re in. And lots of people have their, their views of like, what’s going on, and they’ve kind of like been brought along a journey, or they’ve gone on a journey themselves. And then you come in fresh, and you kind of want to discover stuff for yourself. Like, yeah, yeah, by talking to customers. So I guess how, how much of that, have you found that, that you should actually revisit stuff fresh, you know, from a fresh perspective, when you’re coming in new in that way, versus listening to all of the opinions of that have been formed from other people’s own discovery.
Anthony Marter:
It’s tough, right? Like the, you know, the hardest thing in the world is to come into an organisation, as a brand new product manager, were all brand new to that organisation, and you don’t know the context, you don’t know the domain. And that temptation, there’s really is that temptation there to, to go, right, we need to, you know, Rediscover everything. And in some ways, that’s, that’s you personally, you know, you’re you’re having to learn yourself. And so it’s trying to strike that balance between, you know, obviously, as a front of energy, you do have to get up to speed and as a fresh pair of eyes, you will see things that other people haven’t seen, but balancing that against you have all these people around you who spend a lot of time and effort and invested in what they perceive to be the problem and and, you know, making sure that you’re balancing listening to them verse with listening to the customer, and you’re really, you know, starting with an open mind that, you know, that in all probability, they probably are onto something with what they perceive as to be a problem, even if they’re expressing it as a solution. And just being really to kind of shift shift both your perception of of what it is that he really thinks the problem is, and and you know, and listen and make sure that you’re kind of achieving a happy medium between those two things. But it’s hard because, you know, it really is that that moment of, you know, do I think that they’re misaligned with the customer because they’re misaligned with the customer? Or do I think they’re misaligned with the customer? Just because I don’t know something? Yeah, yeah.
Randy Silver:
So a lot of time when we talk about discovery, we talk about almost like from a greenfields perspective, you know, you’re coming into something new, you start off with discovery. But you said you’re working with a grocery chain with a FinTech, and I’m guessing these are from the sounds of it. These are larger organisations. And when you come into these, most of the time, you’re coming in on something that’s already in motion, they already have a strategy. There’s a lot going on. How do we know? You know? And obviously, you know, we can talk about continuous discovery and as a as a principle, but how do we know how much has to be redone? When we come into something like you, we don’t necessarily want to start from scratch? How much can we reuse from what the team’s already done? And how where do we need to start again, for ourselves,
Anthony Marter:
is kind of what I what I touched on in my talk was sort of a bit of a three step process to getting there. And the first thing was trying to understand like, like, do we know how we’re going to move? You’ve got stuff in flight, right? Is this stuff that stuff’s in motion, you come into a team, you come into an organisation, there’s stuff already in motion? How much do we being the product manager and the team understand about how we’re going to move the dial? When this thing gets out there into into the wild? Like, like, do we actually know what difference it’s going to make? Like? Are we just talking about what we’re just going to build a thing and give it some customers and, you know, sweetness and happiness and whatnot. And so it’s really good to try and get beyond that, which is the you know, do we as a team, understand how we’re going to move the needle. And, and that might be metrics. It might be quantitative or qualitative type things. Or it might actually be that it really kind of shrugs their shoulders because they should be we’re not really sure we’ve just been told to build that. And so So the answers to that kind of question and kind of gives you that that starting point of like, How far away are we from really knowing what it is that we’re trying to achieve? And that and then sort of kind of the first step and then so that usually evolves into a conversation about matrix and whatnot. And if there’s great matrix, they’re really great double down on those. If there’s not okay, maybe we need to have a start to start having conversation about what we’re going to measure. And that then kind of enable was us to sort of start going okay, well, how far are we away from that knowing what the problem is, if we actually feel good, everybody does understand the problem. Great, nothing much to do move on deliver, get some stuff out there, you know, inspect and adapt, wanted to get out there and some wild, if we know if we’re ready to kind of shrugging his shoulders and going actually, we don’t know what we’re going to measure. Okay, right, let’s, let’s start there.
Lily Smith:
So okay, so if you know what you’re measuring, and you’ve got a plan of like, the metrics that you want to impact, how does that then filter through into the discovery plan? Like, what’s the next step? After that?
Anthony Marter:
It kind of leads you down to or like, how much discovery do we need to do here? Like I said, everything’s already well understood, we’ve covered covered all our dimensions of feasibility, great, just say this, let’s get on with it. We’ll get on with that and make and then when we’re doing the next thing, making sure we’re applying that rigour to it. If we look at and go, actually, as I say, you know, maybe we don’t know the business metrics, or we don’t know the support matrix, or we or we’re missing some stuff around technical feasibility. Okay. That’s the gap that we need to fill doesn’t mean that we need to get the technology team to do some proof of concept thing. Do we need to do some prototyping with a UX team basically, like where? Where are the gaps and the dimensions of feasibility? And what I’m referring to there as mighty Kagan’s kind of Four Dimensions of feasibility, which, which one of them that we have a gap in?
Randy Silver:
So presumably, if the businesses already funding something, there’s been a business case built around this? So I’m a little confused into what you’re recommending do which comes first the business case or the initial discovery? Where do we start?
Anthony Marter:
Great question business cases? My goodness, yeah, yeah. Business Case. And so for those who are listening, and I’m using Massaquoi he fingers there. And I’ve seen massive varying qualities of business cases out there. Organisations that will remain nameless, where the business cases basically tick the box kind of exercises, just somebody’s written enough to make it sound believable enough that somebody in the organisation has signed off on the funding for it. But actually, it’s kind of meaning, you know, meaningless, there’s been no real effort put into that. And, and I’ve yet to really see an organisation that really dovetails kind of discovery and business casing together very well, in my opinion, is it’s kind of becomes a two step process, which, and this is what I’m working on with the grocery retailer, and sort of, to some extent, works this way with the FinTech as well as that you sort of start off with, is there enough of a smell there to make it worth investing and discovery? So you know, do do we think we’ve got enough of that. And so that business case is super lightweight, is there enough to actually spend a bit of time and to see if that see if this thing is valuable enough. And so that’s sort of step one, and so very, very lightweight. You know, depending on how your organisation works, that might even just be a conversation, right? We want to build with time on that. Or it might be a more formal approval, depending on the depending on how large the organisation is how bureaucratic there. And then discovery is the in kind of telling you Okay, actually, there is some value here. And that’s where that more formal business case might kick in. And to me, that the what people what most people sort of perceive as like the formal business casing process, that really is the outcome of that discovery, because that should be at the point we’ve gone. Actually, there is enough value here to be worth investing in. And as a city, as opposed to how a lot of business cases are treated like net right now, which is just like a process document that nobody really actually believes it’s just enough bollocks to get their thing. Moving into delivery.
Lily Smith:
Brilliant. So how, when you’re, when you’ve decided, right, we need to do some discovery for this, for this project, or for this metric, or this piece of work? And how do you go about deciding what that entails? Because discovery can be a whole bunch of different activities. So how, you know, you mentioned prototyping before kind of doing and VPs or, like putting stuff in front of potential customers or users? Like how do you decide what technique I guess you’re gonna use to do your discovery? And who’s doing that with you?
Anthony Marter:
I’m going to go for the classic product manager, it depends. So here, but as I as I just tweeted the other day, you know, please, please product managers don’t say it depends without qualifying, so I will qualify that. So what I tend to do is look at okay, this is it, we’ve got it. We’ve got our four dimensions of feasibility, we’ve got our you know, we’ll, we’ll use this value, where is it feasible from a business perspective? Is it technology feasible? Can we support it? And then there’s sort of fifth dimension of you know, is it ethical and it’s, it’s taking the area of the problem statement they were looking at and going, what are what do we not know? Okay, well, maybe the, the technology side of it looks like a slam dunk. But, you know, really, we’re not sure if users can use this. Okay, well, let’s put our fit into the, into the the usability side of things? Or, actually we’re not, you know, the sounds kind of valuable, but we’re not actually sure if people are going to buy it like, is there enough value in there? How do we How would we price that role, let’s put effort into the, into the business by the viability or, you know, hey, this sounds really cool as it’s viable. It’s, it’s, and there’s demand for it, but just don’t know how the heck we’re gonna build it. And so it’s trying to do that assessment upfront. And that’s a real chicken and egg kind of situation, because you’re, you’re in this sort of realm of unknown unknowns that you’re kind of taking a bit of a finger in the wind of going, Okay, well, we think we need to focus away for over here, but we could very well be missing something in the other quadrant. So that really is my view is that that’s a judgement call, like, there is no way there’s no scientific way of proving that. Other than, you know, the typical thing of assumptions are the mother of all stuff ups. And they’re, you know, you might think that one of those quadrants is not worth putting effort in, but it actually turns out to be doing it. So at least doing doing the basics and all of them. My view is important, otherwise, you kind of trip yourself up. But it doesn’t say that you have to make that judgement call on you. Because you can’t, you can’t do like, all the discovery all the time and all of the quadrants because you just spend all your time like just navel gazing and not actually getting anything done. So it does come down to that judgement call of where do we want to focus our effort? What are the techniques I use as trying to do a little bit up front of just guessing about what our discovery if it is going to be like, is this something we’re going to spend an hour on a day on a week on a month fine, and just trying to do that, and just time boxing yourself just to go right? Let’s timebox what we’re going to do on this. And that also allows us to criticism I’ve seen in organisations is all the stuff is in discovery for forever, you know, are we ever actually going to build anything? And so if that becomes something that you can communicate back to the business, hey, we’re going to give ourselves a week on this, because actually, we need to do quite a bit of a detailed investigation, and then surface the result and make that visible to the organisation after that period.
Randy Silver:
Okay, so speaking of things that aren’t scientific that you can communicate well, one of the things you mentioned in the talk was finding the face pop. And I absolutely love that. And it sounds, I think there might be a little bit of science behind it, but probably more art, but could talk a little bit about what you meant by that and how you use the face palms.
Anthony Marter:
This is where you’ve got that stakeholder who comes in and says, Look, we should just do this, this is a no brainer, we should just ship it. And then you try it out that year. Do you remember that time when we that other than that something that fell horribly flat, and, and that gives you that that little bit of leverage to kind of just get people to step back from the brink? One of the organisations that I’ve worked with remain nameless, and one of the stakeholders here who also remain nameless, there’s a very, very famous situation that everybody in the organisation knows about this particular incident where something was built, and it just failed horribly, it just was terrible. And that’s, you know, and that gives people kind of leverage to say human at that time when we but it’s something you have to approach needs to be right. Because obviously, you know, that particular thing, there was a person that was associated with it. And so you have to be careful that it’s not just like a slap down way of pitching things. So you have to be sensitive about it. But as I see that, it’s that it’s that just giving pause, giving space to the product managers to go, Hey, let’s actually spend less time to think about this thing. Otherwise, we risk in the gap in that situation, when we you know, whatever fell on its face kind of thing. These projects
Lily Smith:
usually have have names, don’t they?
Anthony Marter:
Yeah, they often do.
Lily Smith:
They have what it was called Horizon. And this
Anthony Marter:
project is ideal. It’s it’s not
Lily Smith:
everywhere, it’s just like,
Anthony Marter:
and in as a product manager, what you can do is kind of analyse it, just to try and form a bit of create that kind of narrative around why that went wrong. Which is more than just you know, somebody haven’t had somebody had a bad idea. It has to be more nuanced than, you know, you bad. You did bad because it was bad idea kind of thing. It has to be like, well, actually, if we put effort into looking at this or looking at that, we might have had a chance of finding out that that wasn’t going to fly before we invested X amount. And just yesterday, have you do actually have to take the people out of that because it can be very tempting just to say, hey, that was a dump. Bob came out with that idea and all that kind of thing. And Bob suddenly feels like he’s been swept.
Lily Smith:
And I guess kind of along along those lines as well. Like if you’re working cross functionally with other departments, you know, you mentioned business viability earlier that you might have to do some sort of like business modelling or financial model. or, you know, technical feasibility study or something. So how do you kind of bring the rest of the business into that discovery process and like really get them enthusiastic about something which isn’t necessarily about just delivery.
Anthony Marter:
It’s a tough gig, one of the one of the ways I’ve used is actually making the discovery process itself visible. So a practice I’ve introduced and a couple of organisations now is discovery reviews. So you know, teams have their sprint reviews, but actually getting the product team to do a discovery review. And hopefully, that actually becomes part of like, my, my ultimate goal, the discovery reviews I’m doing right now, where I’m getting a product team to do it. My ultimate goal, actually, is to get the team to do it. But and then inviting everyone in the organisation into that. And often what you’ll do is your title will say, Well, we’re investigating this thing, somebody will put their hand up and go, Oh, hey, that’s, that’s really interesting. You know, that might affect my area. Can I can I get it on on that? And so it’s actually getting, you’re just making visible what’s going on? Because it gets more stakeholders going, Hey, this is really cool. I can see how engineering products are thinking about these things. Hey, I’d like a piece of that. And so it’s kind of set Yes, selling that value by, you know, showing not telling.
Randy Silver:
And, okay, as we have to ask this question, I think we’re duty bound in every episode to ask about it anytime, in any episode about discovery. I mean, we’re already behind on whatever metrics we have business plan we’re trying to do we always are, that every place I’ve always have ever worked has always felt like they’re behind on the project. So creating the room for discovery, a meet seems like a no brainer to us. But the question of the return on investment or justification for the time, how do you approach that?
Anthony Marter:
It’s kind of related to what we were talking about earlier around that around the face pounds, it’s saying that we’ll actually, the highest value thing that we could be doing right now might be to find out that we shouldn’t be doing what we’re doing right now. In the FinTech, I’m working with actually earlier, in the year, we had actually quite a full discovery pipeline, and we found a bunch of stuff in there, that actually sounded like a great idea sound like it was really good. But after we did analysis on it, say, Oh, actually, that’s not going to give the results that we thought it was going to, if we dropped in and built that stuff, you know, we could have wasted a quarters worth way more than a quarter actually worth of worth of development effort, we’re just really flipping expensive. on doing that, and again, it’s making coming back to their transparency and visibility thing, making visible what we kill and why we killed it. Because they get that that creates that sort of self reinforcing cycle of story around, you know, the value of this is that we’re trying to find things that we don’t want to do. Yes, it’s a stick I quoted in the end, my talk was somewhere between 50 and 90% of things that sound like a good idea for your for your product for your backlog, actually turned out to either not be a good idea or not have the impact not have as much of an impact as you thought they were going to. And if you build 100% of them, then you know, probably at best, you’re wasting 50% of that development effort, which is again, really, really, really expensive. So it’s just created creating that sort of self reinforcing narrative of, you know, here are the things that we shot in the head, because we found out that they didn’t have the value that everyone thought, and, you know, hey, look, if we committed that to development, Geez, that would have been expensive.
Lily Smith:
It’s interesting, as well. And I think, you know, in your experience, if you are doing discovery, well, do you think it changes the shape of the the product team, and when I say product team, kind of including development, and design, and UX, and everything within within all of that, because the classic shape of a team like that would be like five developers, a designer, you know, maybe a bit of a UX person, if your designer isn’t a UX person as well, and a QA person or, you know, something in that sort of shape. So if actually, you’ve got to do quite a lot more work up front, in order to validate everything that’s going into that development team, you kind of feel like, that’s the wrong shape? Type.
Anthony Marter:
Yeah, it’s interesting, because the notion of team actually grows significantly, because you know, it might be a conversation with your company lawyer that leads you to go or actually this, maybe we shouldn’t go down that path after all. So, you know, is the lawyer part of that team? It might be your support people who will ultimately lead you down the path of Jesus, you know, this is a bad idea. Are they part of your development team? And so it kind of, and that starts to really extend that the notion of team into that more sort of value stream kind of thing where, actually it’s all the people in there in the grocery retailer thing you know, there’s a lot more people than just the development team. involved and actually getting something into the real world, its store staff, its delivery, its back office warehousing, all that kind of thing. Those that is the team of people that will help you to understand whether something is feasible or not. So as it really extends that notion of team and by exposing your engineers to those wider group of stakeholders, you’re going to get a better product as a result, because they’re going to organise, they’re going to understand the wider business better. I just just been going through a roles responsibilities exercise with one of the organisations and we were noodling on, you know, where does it be a fit and all of us and we saw where we landed as actually the the BA is the one who’s going to be trying to really represent some of these more process oriented things and other parts of the business and bring that business knowledge into the team, to help them to kind of flesh out that that dimension of feasibility.
Randy Silver:
I’ve got an entire rant about the definition of a product team and things like that, and we will get into it. But he did it. Very, very similar to what you just said. And you said much more concisely than my long talk said. But I think that comes in nicely to one area that you had a slight difference, I think, between the way that you approach some of these things, and Theresa Torres does. And you know, we’ve had to respond a couple of times, we usually go to her as our go to person on Discovery stuff. What’s the what’s weird? Do you guys differ on things?
Anthony Marter:
I’m Teresa talks a lot about the the notion of the product trio, you know, the product manager, the designer, the take lead lead tip type person, I like to not think of it as just those three people, it might be those three people as kind of proxies for others that you need to bring in. And one of the lesson I learned has kind of come from some a lot of the thinking that John Cutler has been doing and publishing around the notion of starting together. And that to me, if you sort of pull one person, and I’ll speak specifically to more of a technology type example, here, if you pull one technology person into that discovery process, when we come time to actually then move into the wider team being involved in delivering that, you’ve got to do all this knowledge transfer. And so there’s all these handovers and whatnot that go on and never to be things get lost in translation. And there’s always a temptation that that technical lead person is the most senior tech person. And I’ve heard this wonderful concept called architect hours, where, you know, the, as an architect, Software Architect, he’s got involved in that discussion, and the development team, just look at what the result of that was going and goes, Oh, my goodness, yeah, he’s, he’s, like, really smart. And he could do that, but we’re not as smart as him, we’ve got to do this. And, you know, to help, you know, if only we’d had, you know, as a broader group had an input in earlier, we might have headed off some complexity that we can’t deal with, and, and things like that. And again, you know, we were talking about before about the multidisciplinary nature, as well as that just by limiting it just to those people, you run the risk of not bringing in other stakeholders. And again, you know, the product manager might be a proxy for some of them. But of course, you know, nothing beats getting stuff from the horse’s mouth. And so, I’m a fan of bringing in a broader group of people because it builds that shared understanding that as we move this thing into, into delivery, and into getting it in the hands of our users, we’re avoiding handoffs between between people as much as possible. However, and this is the sort of thing I’ve had discussions with, with people down here in New Zealand about this, because they don’t entirely agree with me, that that has to be balanced with velocity. And I think that’s kind of what took weight, which is sort of signalling, you should be that three people unable to move fast. Because the more people you bring in, the slower it is, and so it comes with that judgement call of what’s what are we what’s our biggest benefit here moving fast, versus bringing everyone on the journey? Like how do we how do we ship that let’s that we can involve like the whole universe of our organisation. Because we’ll just never get anything done. That to me, just bring it back to those three all the time is, you know, you really run the risk of not bringing people on the journey. So what’s the happy balance between that? So I guess, I guess my my message to product managers is, you know, is like to me, the three is the idealised view. Be pragmatic about that.
Randy Silver:
Sounds like a nice depends answer, Anthony.
Anthony Marter:
It is a bit, but it’s knowing that you know, not to take not to take this kind of thing, literally, you know, think about what you think about both those principles of the product trio and needing to move fast, but also the principle of standing together. And if you can sort of balance those two principles, then you’re much more likely to succeed.
Randy Silver:
Okay, this has been fantastic. I think we’ve got time for one last thing, and I’m just going to jump straight into it. One of the things you quoted is an agile principle around building products around motivated individuals. And I think they originally came from building projects and you adapted it to products. Yeah. What’s the so I always thought we should build the products around solving customer problems in a way that adds value bob up all the, you know, the four principles of viability, why build around motivated individuals rather than solving a problem? Or am I reading you wrong? I think
Anthony Marter:
that the last of that question is probably yes, it’s a bit of both. But the number one lesson I’ve learned as a product manager is that you really need to care deeply about the culture of the culture and the sustainability of the team that are doing the work. And it because if you don’t, you, you run yourself off the rails like, like, you’ll maybe get stuff done in the short term, but you’ll be in a team out if they’re not fully bought into what it is that you’re trying to do. And if you’ve, if you’ve burned your team out, you ain’t delivering anything to your customers. So so it’s striking a again, it’s a balance kind of thing. It’s striking that balance between, you know, yes, we are definitely to solve the problems, but unless we bring our people who are doing that, along on the journey, we’re just not going to be as effective. That to me that the scariest thing in the world as a product manager, is when I get the sense that my team don’t really understand the problem that they’re trying to solve. And they just just coding, because I know that if we don’t have that shared understanding of the problem, in the end, if people aren’t motivated, and don’t really care about the problem, everybody’s gonna have their own perception of what the problem is, in their mind, they’re gonna have your own motivations. And if we hit the mark, for our customer, it’s going to be more through lack than, than good management. So and, you know, I don’t like buying, I’m like, you know, I want people bought into why this is something that they should really care about, and why it’s going to make our customers lives better. And this is a lesson I’ve learned the hard ways as a product person is that, you know, unless that team culture is there, you’re just, it’s just going to be painful. It’s going to make your life really, really, really tough. Don’t Don’t leave the team culture to the engineering manager or the scrum coach, you as a product manager need to care about it, and you need to find ways to nurture
Lily Smith:
amazing, thank you so much. And I think that’s a great note to finish on. It’s been such a pleasure talking to you.
Anthony Marter:
Thanks, guys. I really really really enjoyed it. As I said earlier on, like we I could talk about these topics for hours now as now as this particular that team culture thing. That’s something that I do really deeply care about.
Randy Silver:
But it is a bit late where you are so we’ll let you go for so much, Anthony. Oh, thanks, guys.
Lily Smith:
And if you enjoyed that, please like and subscribe and share the podcast with all of your friends.
Randy Silver:
And you can discover so much more about lots of topics and all of our wonderful guests.
Lily Smith:
Haste, me, Lily Smith and me Randy silver. Emily Tate is our producer. And Luke Smith is our editor.
Randy Silver:
Our theme music is from humbard baseband power that’s P A you thanks to Ana Kibler, who runs product tank and MTP engage in Hamburg and please based in the band for letting us use their music connects with your local product community via product tag or regular free meetups in over 200 cities worldwide.
Lily Smith:
If there’s not one Nagy you can consider starting one yourself. To find out more go to mind the product.com forward slash product tank.
Randy Silver:
Product Tech is a global community of meetups during buying for product people. We offer expert talks group discussion and a safe environment for product people to come together and share burnings and tips
Comments
Join the community
Sign up for free to share your thoughts