Customer Centricity in Product Management With Mike Marriage of Bloomerang

Kayla: Thanks for tuning into Product Chats. On today's episode, I talk with Mike Marriage, who is the Head of Product at Meez and we talk about collaboration, customer centricity, and prioritization. Hope you enjoy the show and don't forget to leave us a review.

Kayla: Hey Mike, thanks so much for coming on today.

Mike: Hey, you're very welcome Kayla.

Kayla: So in a minute or less, can you tell us about yourself?

Mike: Sure. So I started my career as a software engineer. And then soon thereafter began leading engineering teams. And one of the things while I was leading those teams that I quickly realized is that I needed to focus our engineering efforts on the work that really mattered to the organization and to our customers.

Mike: And at the time there wasn't a lot of information available on product management. Certainly not to the extent or maturity that there is today. So I kind of had to figure a lot of this out on my own. I often tell people that I got into product management before product management was cool. And this also really kickstarted my fixation on the customer and solving real problems that they're experiencing through innovative products.

Mike: You know, I was hooked and ever since then, I've been leading product teams and it pains me to say for more than 20 years. I'm the head of product at Meez which is a universal recipe tool that standardizes the way culinary professionals create, share, distribute costs and analyze their recipes.

Mike: We really are revolutionizing the way that work is done in kitchens around the world, and you know, it's really amazing to see the faces of our customers light up during product demonstrations. And Kayla, that's really what it's all about, right, delighting the customer.

Kayla: Exactly. So I wanna touch on something. I know you recently joined Meez. So I'd like to learn a little bit more about, you came into a company. What do you focus on first? What frameworks are you putting into place? What does that look like?

Mike: Yeah, absolutely. So there was definitely a lot to do in the small organization. For me it was really trying to understand the decision process that went into the product thus far, where that information came from.

Mike: Where the information lived and really trying to get my arms and my head around, you know, establishing the relationships internally, the collaboration amongst the teams, you know, who are our customers how can I create those focus groups and really start to, you know, get that bidirectional feedback coming into me from customers.

Mike: So it was a lot of focus, you know, on just understanding. Where the product came from and then, you know, starting to think about how we're going to take the product going forward to make sure that it's always, you know, thinking about the customer first and solving the problems that they have. So from a process perspective, you know, I came in implementing a lot of new product tools.

Mike: Aha has always been one of my favorites in an ideas portal. You know, if you wanna talk about tools, confluence, integrations, JIRA. Making sure that we have all of those different tools and technologies that we're using, you know, interconnected because as a small organization, it's really important that we automate as much of this process as we possibly can.

Mike: So, so far that really has been my focus, but let me tell you, it's been a lot, it's been almost overwhelming some days.

Kayla: So with that, how do you figure out what to prioritize on the day to day and, and really, what does that look like?

Mike: Yeah, absolutely, and I get asked this question a lot. As a product manager, have all of these requests coming in, right?

Mike: You've got your customers that are submitting requests for things. You've got the sales team who has to have this new feature implemented. Otherwise they can't close a deal. You have the CEO who goes off to a conference and comes back with a million ideas and changes in process and direction and the like.

Mike: You've got the support team who are saying, we've gotta start addressing these bugs and these tickets. So you've got all of these different, you know, demands coming in at product and prioritization is always something that's very difficult to do. And you know, one of the things that for me, it always comes down to is value.

Mike: You know, at the end of the day, there has to be some value associated to the requests that are being made and that's value to the organization as well as, and probably equally, if not more importantly to the customer to make sure that what we're solving or what we're building, excuse me, is really going to solve their needs.

Mike: So when I say value, that's not just me in product, you know, looking at different frameworks or methodologies for assigning, you know, prioritization on the work that's coming in. And certainly I do, and the team does a lot of that. But it's also pushing back on those requests as well. You know? So when sales comes to me and says, Hey, we've got this deal that we're going to lose, or, Hey, we think we could generate this much or whatever. It has to be associated to a value. And you know, the other teams in the organization have learned with me that when they do bring those things to me, they'd better back it up with some data and some value because ultimately if I've got the opportunity to make $5,000 for the organization, if I implement feature A or $500,000 for the organization, if I implement feature B which one's going to win out? It's almost a no brainer.

Mike: And I think when you, you know, kind of look at it from that perspective and you involve whomever, the submitter is in that they get it too. Usually, there are exceptions to the rule of course, but they usually do get it. And it doesn't necessarily mean you know, I'm saying no now, or I'm not saying no forever.

Mike: I may only be saying no now we can't do it . Immediately. But maybe it's something that we wanna revisit down the road. Or, you know, a lot of times what I'll also do is, you know, if we can't do it right now is let's take a step back from the request and really understand the underlying problem that you're trying to solve with this feature. So really what's the crux of this because perhaps there's, you know, functionality in the application already that somebody wasn't aware of, maybe there's a different way to tackle or approach the problem that will get it solved for the customer without having to implement a new feature. So really, you know, looking at this from different ways goes into prioritization.

Kayla: So something I wanna talk about, you mentioned you work with sales and the CEO and you work with success. So what are some kind of best practices that you do to make sure there's alignment and that you're having that communication with those teams?

Mike: Yeah, absolutely. So, you know, one of the things that I've seen a lot of organizations do is they try to publish out, here's a roadmap, you know, here, here it is, you know, ta da, and there's this perception that a lot of teams in an organization have around product management is that it's almost a black hole, I guess, for lack of a better way to put it. We've got all of these requests coming in and we see nothing coming out that we've requested, except there's suddenly all these other things prioritized that we didn't even have any visibility into.

Mike: And, you know, I think one of the most effective things that I have done over my career is really to form a product council to create the visibility into, you know, why we are, you know, selecting the things on the product roadmap that we are and why, and giving other teams a seat at the table, so to speak.

Mike: And that doesn't necessarily mean that, the product roadmap is managed by a committee and it's a vote , and democratically the most votes, you know, gets it on the roadmap. But it's a way for the individual teams to, you know, one of the things I say is bring me three suggestions for product improvement and three questions that you have to each of our product council meetings.

Mike: So I'll get input from, you know, sales, from support, from marketing, et cetera. And then we begin to discuss and debate, you know, some of those ideas and, you know, look at them from different angles. And I think that when you have those discussions in front of the other teams, then perhaps, you know, light bulbs start going off that, you know what, maybe the request that I've made, isn't as important as the request that somebody on the other team is making.

Mike: And I understand why, and it's been very effective in, you know, making sure that the reasoning behind product decisions is disseminated back out into the organization because each of those council members is responsible for delivering that message out to their respective teams and making sure that everybody is on board.

Mike: So bidirectional feedback, they bring it to me and I give it back out to them and they share it. And that really has completely changed the perception of the black box. And, you know, we don't have a voice at the organization. So if you don't have a product council I would definitely recommend that you think about doing it.

Kayla: And with that, right. It's all about listening to your customers at the end of the day and listening to their problems. So let's talk a little bit around customer centricity.

Mike: Yeah, sure, absolutely. One of the things that I learned very early on in my career is that getting input from the customers is key to creating impactful solutions that delight your customers and really solve problems for them.

Mike: If you design a product in a vacuum, so to speak, you know, looking only at maybe what your competitors are doing, or maybe looking at the market, trying to anticipate the direction without involving customers in that process, you're ultimately going to deliver a product that really doesn't resonate or address enough of the customer's need.

Mike: It is very critical that, you know, you look at every feature, every problem that you're trying to solve from the perspective of the customer, because ultimately you are the voice of the customer in the organization. You know, it's surprising to me. I do interact alot with other product managers.

Mike: And when we start talking about their product roadmaps and their backlogs, you know, I'll ask them how are you building your backlog? How are you prioritizing? How are you deciding what work makes it into your releases? And the like, and it's shocking to me the number of product managers, especially junior ones who are saying things like, well, we look at what the competitors are doing or market research, or we talk to industry analysts and that's what we use. Or the CEO has a great idea and we're going this way. And when I ask, you know, well, don't you ever talk to your customers? Don't you involve them? I mean, how do you know that you're in alignment with the problems that they're experiencing? You know, they usually say something to the effect of, well, we know that we need to talk to customers a little bit more, but there's just no time to do it.

Mike: And I, quite frankly, I'm like what the, what, what do you mean? I mean, that, that should be your first and foremost conversation. You know, certainly all of the other things are important. Don't get me wrong. But it really begins with a customer and it should begin with the customers.

Kayla: I think with that, right. It's just so important to understand the customer journey, what challenges they're dealing with. Yes. You can build out a million features or functionality, but if they're not solving that true pain, you're not focusing on kind of that core area of how your like, product can change their life.

Mike: Absolutely. When you do that, not only are you going to, you know, perhaps deliver features in your existing current functionality, but you may you know, uncover ancillary types of products or services or whatever that maybe you could use to expand, some account expansion, offering some different things that will solve additional issues that you might not have even thought about when you were initially you know, creating your product. So it definitely is important to get out there speak to the customers and understand what their challenges are and to make sure that you're building products that solve them. I mean, that's the bottom line really.

Kayla: And I think something you mentioned, right. That you have a product council, so you're listening to sales and success, and you're listening to these different people who have this buy-in, who are constantly talking to customers, but what are some ways that you go out and you talk to customers, or do you have like methodology around that? Or what does that look like?

Mike: Yeah, absolutely. So I've several different ways that I interact with customers and one that. never will cease to amaze me that people don't do it is just pick up the phone. I mean, you don't know how many times I've said to people, you know, just pick up the damn phone and ask and call or, or send them an email and whatever, just reach out.

Mike: Because at the end of the day, you know, customers honestly want to engage. They wanna participate, they want to be involved. They want to let you know what they think and they're willing to do it. And it really just is a matter of you reaching to them and making sure that they're involved in that process.

Mike: So obviously picking up the phone and emailing is one. I also do a lot of in-app feedback as part of product led growth, you know, we are not only pushing notifications out and trying to alert the customer to, you know, different features and functions and other things available within our organization.

Mike: But it's also a great medium to start getting that feedback from customers as they're interacting with your product. One thing that I will say on in app feedback though, is if you have a thin skin, it may not be for you because chances are the type of feedback you're going to get when a customer's in the middle of doing something is typically going to be negative.

Mike: Most people aren't gonna stop, you know what they're doing and say, yeah, I absolutely love your product but if they have a problem, you better darn well, believe that they're going to take advantage of that in-app ability to give that input back to you. Some of the other things that I do. I always stand up an idea submission portal.

Mike: So just a way for customers to, you know, provide input into different pieces of functionality or enhancements that they would like to see in the product. And what's nice about that is not only is it giving the customer the ability to let me know what's on their mind and what they'd like to see.

Mike: But those thoughts are also visible to other customers as well. And with a lot of these tools, you have the ability to up vote on submissions. And for me, as I'm looking at my product backlog, submissions that have a higher number of customer votes, typically carry a higher weighting when I'm looking at the product backlog.

Mike: Right. Because there's more reach when I'm doing that.

Mike: Other things that I do customer advisory board is another way, you know, identifying those focus groups, those key customers that you have that represent different segments of your customer population or your customer base, and then involving them in the overall design process or strategy around your product.

Mike: And what's different than, you know, a lot of other methods out there is that the customers that serve on the customer advisory board interact with each other. So they're all participating in that same discussion and you can really see them as they begin to interact with each other, the light bulbs start going off and they're building on and feeding off of each other, coming out with these ideas and you really get a lot of great information out of that as well.

Mike: I've mentioned the product council and one thing that I would underline in that is, you know, we talk a lot about getting input from the customer and I've talked a lot about that, but the product council, you know, interacting with people on the support team who are in sales. Well, those are people in your organization who are dealing with customers on the front line, day in and day out, and they're experiencing those customer problems. So they're a tremendous source of information for you as well. Understanding what the needs of the customer are and some of the challenges that they face. Of course, you know, there's other things that I use typically like interviews, surveys, field studies are another great one. I've got some great stories around field studies, you know, getting out there, working with the client. I remember one customer that I had several years ago. They were a very large chicken processor here in the US and they wanted me to go out on the floor, and understand from beginning to end how chickens are processed and one it's not for the faint of heart or the light of stomach. But secondly, while I was out there, I was getting literally hit by flying chickens. They were flying off the conveyor belts, pegging me with chickens, you know, while I was trying to figure out, you know, how the process worked at this company.

Mike: So field studies are another great way to get that input. Just watch out for flying chickens I guess and then diaries, of course and setting OKRs for your team to make sure that part of their objectives and key results is to get out there and have these same conversations with customers and collect this feedback.

Mike: Because again, it's critical to the success of your product. Sorry. I know I got on a soapbox there, which is very passionate.

Kayla: No, that's great. That's great. I think something you bring up that's really important, right. Is getting in the ground. Right. You went out and you went and you did that field study, right? You understood firsthand, what is the challenge that this customer is dealing with rather than, Hey, I think they wanna deal with this, or I think they're like struggling with this, or I think they're struggling with this. You actually got a chance to experience that. So a question I have, right? You get all these requests people upvote, but how do you actually level set?

Kayla: Because sometimes just because something has a lot of votes doesn't mean that it aligns with the value that you can bring.

Mike: Yeah, absolutely. One of the things, unfortunately in product that we have to do is we have to say no on occasion, I think if, you know, you think that you can do everything for everybody right away you're setting yourself up for failure.

Mike: So really again, you know, there are times when you have to say no, when you're getting that input but if you take a step back and maybe look at it from different perspectives, understand it from the customer's point of view, what they're trying to accomplish by submitting that request, sometimes you can, you know, figure out a different way, a different approach to tackle and give them what they need.

Mike: But ultimately, you know, at the end of the day, you have to make sure that the product that you're building, you know, serves your broader audience, unless you're gonna get into customizations. It makes me shiver to think about. If you're building an application that's gonna serve the general needs, then there are times when you're gonna have to say no, that just doesn't make sense and this is why. But again, if you do, you know, look for different ways to help the customer and maybe solve the problem that they're having.

Kayla: So I think on that, right? You say no, and that gets us into kind of prioritization. And how do you figure out what actually to prioritize.

Mike: Yeah. So, you know, there are different prioritization models that I use depending on where the request is coming in from.

Mike: So if I look at it from an ideas portal perspective, you know, typically as I'm triaging those ideas, I'm using the Moscow model just to see what's coming in. So the must haves, the should haves, the could haves, the won't haves, just as I'm accepting those ideas into the product backlog.

Mike: And when we're looking at it from the prioritization of a product backlog perspective, there's different ways that we can do that. We can look at weighted scoring we can use rice models. If I'm in a product workshop, which is where I bring all of the product team together on a quarterly basis and each one presents his or her thoughts around their particular part of the application and their roadmap going forward.

Mike: You know, as we begin to prioritize around that, you know, a lot of times I'll use like affinity grouping and story mapping and things like that, you know, those real team building type of exercises to really get in there and prioritize that workload. you know, but I think at the end of the day, the reality is that you're not going to have a single model that you use across the board.

Mike: I know for me, personally, what I found is that there are different tools for different situations. Not everything's a nail and not everything requires a hammer. So if I look at as an example, the product backlog as I'm going through and I'm grooming it and I'm setting those priorities, I actually use a blend, if you will, of a RICE scoring model and a weighted scoring model and I've built, and I think calling it an algorithm is maybe a little bit of a reach or I'm overselling it a bit , but it's really, you know, looking across different key indicators or areas that are important to us, organizationally things like, you know, reduction in cost of goods sold, number of customer requests, ability to generate additional revenue, competitive differentiation.

Mike: You know, weighing that against things like complexity, risk et cetera, across different key components within the application and weighting that generates a score for me automatically within our product management tool. And that really directionally, you know, lets me look at very quickly and very visually the work that's most important based on those factors. One thing that I would say is that if you do set it up like that, and something that I do is to revisit those factors on a fairly regular basis, because things change. The goals of the organization change, the market changes, you know, what was important last quarter or last year may not be so important anymore.

Mike: So it is really critical that you go back and you revisit that and adjust those models that you score accordingly. But at the end of the day, what I would say is that, you know, capacity, the wallet, the prioritization, the decision on how to drive the product forward, ultimately rests with product. And I think it's important that organizationally everybody understands that and that your say is going to be final. But when you do have a final say, make sure that you always back it up with data. That would be my other thing as well. Can't tell you the number of times that I've had to pull the data card out to override a CEO or an executive or somebody else, and really help them understand why perhaps their thought directionally doesn't make as much sense as heading in this other direction. The data is indisputable a lot of times, most of the time actually.

Kayla: So with that, right. Always use data. What's like one parting piece of advice that you would give to an aspiring product leader?

Mike: Great question. You know, there are a lot of things that I would say. And I think that the product leaders I talk to often and I mentor would say that I love my soapbox.

Mike: So picking one is hard. But if I had to pick one off the top of my head, I would say to embrace the word why. And apply it liberally across all the different areas of the product. So things like, why do we need to do this? Why do we need to do it now? Why would our customers find this beneficial?

Mike: Why would I select this feature over others? Or maybe why do you feel the customer needs this? If I'm talking to somebody else in the organization, or why was my new feature not widely adopted? And that applies to both your own thought process as you're looking at the work ahead of you. As well as the interactions that you're going to have with colleagues and customers.

Mike: So challenge with the why always. And if you're not familiar with it I love the five why technique. If I remember correctly it came out of Toyota in the 1950s and then was popularized more recently by the lean startup. And it really helps teams to collaborate and get to a root cause instead of simply treating the symptoms of a problem.

Mike: So. As an example, if I take one of the previous whys that I mentioned the new feature is not widely adopted. Well, why? Well, we didn't deliver functionality that customers really wanted. Why? We didn't meet with the customers to understand their needs. And then why? Well, maybe we cut corners in the design process.

Mike: Why? Well, we were under pressure by the sales to get the feature well, why? And it can continue like that. So it is not necessarily confined to five. But you see where I'm going with that. And, you know, in that example that I went through, you can see that we began to tease apart the problem. And there were many problems in there that are going to require several solutions to solve all of that breakdown in the process.

Mike: So definitely, you know, think about things. Challenge it with the why and if you're not familiar with it, I definitely recommend that you check it out and learn the technique. It's gonna be incredibly beneficial to you.

Kayla: Awesome. And then on the last note of hearing from you, where can people find you?

Mike: Yeah, absolutely. So of course, on LinkedIn and Twitter. As well, I also am an avid blogger where I, you know, talk a lot about customer centricity, other product processes, and the like, and you can check that out on my blog at michaelmarriage.com.

Kayla: Thanks again to Mike for joining us on today's episode of Product Chats. If you want more product management resources, head over to canny.io/blog and we'll see you next time.