← Insights Unlocked
Insights Unlocked
How great product teams use customer insights differently with Jeff Lash
00:53:58
Learn how product teams use customer insights, voice of the customer, and smarter prioritization to make better product decisions with Jeff Lash.
Loading summary
Transcript47 lines
- [00:02]
Nathan Isaacs
Welcome back to Insights Unlocked. In this episode we're joined by Jeff Lash, a longtime product leader, to explore how teams can turn voice of Customer Insights into smarter product decisions. We dig into why ask and follow up questions matters, how to balance qualitative and quantitative feedback, and what separates high performing product teams from the rest. If you care about building better products, this one's for you. Enjoy the show.
- [00:31]
Podcast Host (UserTesting Intro/Outro)
Welcome to Insights Unlocked, an original podcast from User Testing where we bring you candid conversations and stories with the thinkers, doers and builders behind some of the most successful digital products and experiences in the world, from concept to execution.
- [00:51]
Nathan Isaacs
Welcome to the Insights Unlocked podcast, Nathan. I'm Nathan Isaacs, principal Content marketing manager at UserTesting and our host today is Mike McDowell, one of UserTesting's principal solutions marketing managers. Welcome back, Mike.
- [01:04]
Mike McDowell
Always glad to be back. Thanks Nathan.
- [01:06]
Nathan Isaacs
And our guest today is Jeff Lash. Jeff is a seasoned product management leader and advisor, currently VP of Product management at Insperity, with decades of experience helping B2B teams turn customer insight into voice of customer and product strategy into better decisions and stronger outcomes. Welcome to the show, Jeff.
- [01:27]
Jeff Lash
It's nice to be here. Thank you very much for having me.
- [01:30]
Mike McDowell
Excellent. Well Jeff, we just talked about this a little bit in the pre show, but let's revisit it for the audience here. You've just had such an interesting path going from UX all the way back in 2002. Usability specialist, really rare title to research and product management leadership advising across industries. Just could you, would you mind walking us in the audience through like really what shaped the way you think about customers, product management and even decision making in today's fast paced world.
- [01:57]
Jeff Lash
Yeah, I, I think maybe I was always naturally going to end up in product management but I, like many people did not take a straight path to it. So I, you know, always grew up around technology. My dad had always lots of technology computers at home. If you can see the background on video, I got a whole bunch of old tech. So I grew up with technology but I was never really a programmer. I just, you know, liked it. I went to school and studied marketing in my undergrad and this was right around the time that the web was taking off and I was kind of anxious to start applying some of those ideas to dot com and web stuff and not necessarily the quote unquote old school stuff that we were learning a lot of at school. This was back in the day, as I like to say, when knowing HTML was a very valuable skill to have when the same person would set up the Apache server, design the graphics, write the copy and like, you know, maintain the webmaster of the site. The webmaster, that's right, webmaster, yeah. And so I did that for a number of years, you know, or I did that originally, you know, both on the side and kind of for a year or two, let's say. And I very quickly realized, oh, this is going to get very fragmented, you know, there's specialization that's going to come out of this. I was not a great programmer though. I figured out how to write, you know, CGI Bin and PHP and all that stuff. I had taken some art classes in college, but I was definitely not a graphic designer by any means. But somehow kind of stumbled upon to this whole idea of usability and user experience and information architecture and it just kind of clicked with me. For whatever reason, it resonated in this idea of, yes, we should be making websites and products that, you know, are easy to use and meet the needs of users. Seems like that makes sense. But I was also experiencing so many products and websites that were not doing that. So I kind of refocused in that direction and did that for about maybe four or five, six years. And as I was doing that, I really liked it. There was a great opportunity to, you know, make products better, make digital products and technology better. But I also realized I was hitting a point where, you know, I remember at one point saying to my boss, you know, if I learn to run a usability test 10% better, like how does that help the business versus if I can make the product 10% better, that's going to have a much bigger impact. And so there was an opportunity for me to move into product management at the company I was in at the time. That was a pretty rare thing. So this was, you know, early ish. In the 2000s, product management was still not really well understood. More broadly, user experience was not really well understood in my company. No one had ever moved into a product role from ux and more broadly that wasn't a common path. Now it's very common. But back then that was, you know, I would say unheard of, but it was fairly uncommon. But it made sense to me. And I remember about two months in to that job, kind of realizing it just clicked and I started learning about what real product management is. And so much of it overlapped with everything that I had done up to that point. So the technology, obviously from growing up around it, you know, the marketing and positioning and branding stuff that I had learned in school and then a lot of the user experience concepts, you know, doing customer interviews and understanding needs and prioritizing and things like that. So it really to me is this combination of all the different things in my background and so that, you know, I've been doing that for two decades or so now since just following along that path. So I think know long answer to your question of what shaped me, it's really those different things like I am probably, you know, there's different types of product managers. Some people that come from more of a, you know, technology background or a sales background. I come from probably more the UX and business background. Like I'm always thinking about, you know, what can we do that would be good for our customers but that also will be successful for the business. That's kind of my dominant mentality. There's other people that know technology better than me and even the nuances of your experience. But really it's about, I think what's really shaped me is that idea of if we can create products that are good for the customers, it will also be good for our business.
- [06:01]
Mike McDowell
Yeah, we, we have very similar backgrounds. When you were talking about product management didn't really exist. We called it business analysis when I started and you know, now that means something totally different. But yeah, going through the data, data organized data oriented approach like hey, if I can improve this by 10%, if I can get this error experience 20% of the way to the mean conversion rate, things like that, it really shaped the way that I went from being that WebMaster with my SQL and active server pages and Microsoft log file analyzer and all that into truly designing things, mapping out flows and running usability tests or certainly having people do it for me was, it was a huge change. You know, you talk about moving into different organizations over your career. You've had to do that, you've done that a bunch of times. When we think about product management, we always think about product roadmaps, things like that. How, how dangerous is it really for organizations just to rely on things like a roadmap or pure reports? And when you do join a new company, what are some of the signals that you look for to say does do these guys really know what they're doing or do they know what their customers think? Or do they just think that they know what their customers think?
- [07:17]
Jeff Lash
I think one of the things that my background in UX taught me and has really helped me a lot in product management is really to ask follow up questions. So for example, if someone says I have a roadmap rather than me in My head picturing what I think is a roadmap and assuming that's what they have ask like, great, can I see that roadmap? Because Roadmaps is a great example. I've seen hundreds of different roadmaps and some of them are things I would not label as a roadmap. Right? So I don't really care what someone calls it. To me, it's what, what is it, what does it look like, what's information on it, what's the intent of it? A great example I just, that stuck in my head is I remember when I was in a UX role, I did a lot of work in health care and I was interviewing a nurse one day and we were talking about she worked at a hospital that had access to our product and I was talking to her about how often she uses it and she's like, oh, I don't really use it a lot because of the accessibility. And I'm like, interesting, can you tell me more? She's like, yeah, it's not accessible. Now, of course, as a UX person, I'm thinking 508 compatibility, accessibility, screen readers, font sizes, things like that. And so I said, can you tell me more about that? She said, oh yeah, your product is only available at the nurse's station. There's only one computer at the nurse's station and a lot of times that is busy, other people are using that computer for other things. So it's not accessible to me. So it had nothing to do with 508 accessibility or low vision disabilities, things like that. It was just literally I could not access it. So to me, that story is probably over 20 years old, but it stuck with me. So when someone says, oh, roadmap or Persona or requirements, I learned to not really just, I don't say take it at face value, but like, wait, let me see it, let me see what it is. Because again, I've seen lots of different roadmaps, I've seen lots of different release planes and things like that, and they all might be different to different people. So I always, you know, when I was, when I've taken a lot of roles where I've taken over existing products, or I did spend about a decade in more of a consulting advising role. And so, you know, seeing what the team is already doing, seeing what the person's doing is a great way just to understand where they're at. Not from a judgmental perspective, but just for a, hey, let me understand you here. What are the artifacts you use and how do you document Things. And that helps me understand the context, the industry, the product, but also how they're actually doing product development or doing product management.
- [09:43]
Mike McDowell
I love that. I didn't see that coming. That little twist there. That's a great story. It makes me think of, I think of everything in terms of movies. White men can't jump when Wesley Snipes is explaining to Woody Harrelson, no, you can hear them or you can listen to them, but you don't hear them. You know, I think it's one way or the other. And the idea of, you know, hearing someone say something but not really listening to know that it means something else, like to go a little bit deeper and asking that follow up. And so much of it is understanding the why. Like, okay, you told me what's going on, but if, when you explain the why, then I'll, then I'll understand. You know, you're not talking about the fact that, like, oh, you wear glasses and so you need a higher contrast or you need a higher font size. No, you literally mean I cannot access the computer to access your website. It's literally a roadblock to me. That's a great story.
- [10:31]
Jeff Lash
Yeah. So I think, you know, I think artifacts are always helpful. I mean, you know, and in fact, I will also say lack of artifacts is also helpful. Right. I've been in a lot of situations where I asked to say, hey, can you show me a roadmap, requirements, business case, product overview, whatever? And that doesn't exist, or it exists in pieces. And the fact that it exists in someone's head or it exists in 10 different places scattered across the organization, that also is informative. Right. It told me like, okay, so this stuff is not documented. There's not a consistent process. There's no one reviewing these. Maybe other stakeholders aren't aware of these things. So it's not that those artifacts are necessarily good or bad. It's just, I don't view it as a binary, yes, you have it, no, you don't. Thumbs up, thumbs down situation.
- [11:14]
Mike McDowell
Yeah, that's really interesting, you know. Yeah. Talking about the whole idea of having these answers and listening and joining new companies, especially today, unfortunately, there's a lot of people joining new companies all the time. Time. What advice would you say, you know, in someone's first 30 or 60 days at a new company, especially if they're in a leadership role, they're expected to come in and just have answers right away when someone's got that expectation. And in your experience, how would you balance really listening more deeply to really Truly understand, like the nurse estate and situation versus like just saying, yeah, I've got the answer. Here it is. Right away. Especially when, you know, senior leadership, they want confidence in, you know, they want confidence from you or the. Whoever we're talking about here. Before the insights are even fully formed, before you have all the answers, how do you push back on that? What do you do?
- [12:05]
Jeff Lash
So I think the first question is, I think that is a common assumption. I would maybe question that assumption. I'm sure in some situations this is right. You know, I've seen literally job descriptions where it says, you know, in the first 30 days you will do this. In the first six days you'll do this. I think in other situations, we assume, oh, I've got to come in and I've got to shake things up and make my market. And I don't know if that's always necessarily true. Either way, you know, getting a good understanding of the organization, of the people of the industry, if you're new to the industry, to the company, right. That's really important. And I think a lot of people, you know, hiring is a risky decision, right? So. So how do you mitigate that risk? You know, you try to do all your legwork beforehand, but also you try to, I think, you know, as a new person coming in, you're trying to say, oh, like, you know, you made a good decision. I don't necessarily think coming in and saying, here's my plan is always the right way to do that. I think listening is a really important way. So every role I've had, you know, going around, meeting people, spending time with them, treating it like a customer research project, right? Like, you should not be talking 90% of the time, you should be talking 10% of the time, right? Asking people questions, getting their. Getting, building trust, getting. Building that relationship to get them to share things, to open up, to be confident, asking them what they think you should do and what you shouldn't do. You know, I took one role where I did that was a small company. I didn't really need to do a whole lot of digging. I went around and talked to about a dozen people and it was pretty clear what was going on in the company. And everyone consistently said, here's the three things that we need to work on. So I was able to go back to management and say, here's the three things we need to work on. You know, I layered my own judgment in that. But I think in that case, they had a pretty good pulse on what's going on. So I think that's one thing. Secondly is it also really depends on the situation. If you are taking over a product that is doing well, that is very different than taking over a product that is failing. If you're taking over a product that is not yet in the market versus one that's very mature, if the business is successful, it's not if there's changes going on. So I think that really depends on, you know, if you're in a situation where they hired you to do a turnaround. Yeah, I think you probably need to come in with a 30, 60, 90 day plan. But if things are in more stable shape and it was, oh, we just, someone left, we need a new person, doesn't mean that you should just keep things running automatically, but it also means that, you know, making the decision to keep going with things is, it might be the right thing in some cases. I think sometimes the last thing I'll just say is I think a lot of it also depends on the manager. Right. It's like, you know, people ask me, do I need an MBA for product management? And my answer is like, well, depends on your hiring manager. Because if your hiring manager is an MBA, they might want to hire an MBA. If they, if they don't like MBAs, they won't. Right. So if you're, if the person who hired you, if your boss is expecting you to come in with a plan, then yeah, you got a plan. If they're not pushing that, then, you know, not to say the, the pressure is off, but it's not as coming in with that like I've got to do something right away doesn't seem as urgent than maybe you think it is.
- [15:07]
Mike McDowell
Yeah, I was going to say it's really interesting the higher up you go, sometimes that 30 or 60 days starts before your first day actually. And you got hired because they expected you to have a plan already. You were talking, we were talking a lot there about the internal, the voice of the employee really like figuring out what's going on, where are we, what's the situation? And let's pivot that onto the voice of the customer and talk think about. And I mentioned how you are very, you were on the circuit, right. You've done a lot of talks out there in the day. And you know, one of the things you've talked about is voice of the customer. And it's not just about volume of feedback. A lot of companies have lots of different channels of different things that are coming in and you know, some of it is self selected. You know, people who complain People who write in stuff like that. How does a really good, strong team decide who, which signals, which channels of customer or voice of customer they should trust and which ones maybe intentionally ignore those in favor of the other ones?
- [16:06]
Jeff Lash
Yeah, I've spent most of my career in B2B and I think, and not, you know, necessarily large scale B2B where, you know, you've got like millions and millions of customers, but situations where, you know, you know, it might be thousands of customers or tens of thousands. Right. So somewhat more targeted market in some cases. I think in a lot of cases there are frontline people that really actually have a pretty good pulse on what's going on. If we're talking about an existing product, an existing portfolio, because they're hearing day to day what, you know, what they're struggling with. Sales is not always 100% correct, but I think a lot of times they have a pretty good pulse on, hey, here's the questions I'm getting asked or here's the competitors we're losing out to. Now, how we fix that is a product management job. But talking with sales, talking with customer success, technical support, you know, if you have got an implementation team or services team. Right. I think those are really good sources. It doesn't mean we're going to just verbatim take what they say as fact. We've got to assess it against other things. So some things I like to think about is, number one, what is our target market? Because a lot of times I've found, oop, there we go, thumbs up. A lot of times I found that we're getting feedback requests for features or things like that from customers that are not in our target market. So that begs the question of, you know, do we want that those customers as a target market? Because that's the first question. So if we, if we've already said, hey, we're going after market A and all this feedback is coming up from market B and we don't care about market B, that's really easy. But sometimes you have to raise that question to the leadership and say, hey, we, you know, I know you've told us that market segment A is our target, but we've got a lot of customers in market segment B and they're giving us a lot of feedback. So we need some guidance like do we care about them or not? Or how, how do we care about their importance? So I think that can be one real good kind of sifting factor. Litmus text first. I think the second is also Personas.
- [18:02]
Mike McDowell
Right.
- [18:02]
Jeff Lash
So understanding the different Personas, especially again in B2B, we've got lots of different buyer Personas and user Personas that are interacting with our product or with the buying process. So understanding the relative importance of those and especially when you're trying to make a switch, when we were saying, hey, we used to sell this product into it, now we're trying to sell it into marketing. We used to sell this to small businesses, now we're trying to sell to enterprises. I think understanding, you know, all feedback is not equal. So I, I found those two factors are really helpful just to narrow it down. And then you start looking at volume, intensity, you know, things like that.
- [18:37]
Mike McDowell
Yeah, that you just hit on it right there. Sometimes there's a trend of feedback that over time, maybe the first few times it was just a small bit of feedb back and then over time it, it really morphs into something that's really important. I'll give you an example. When I, when I worked, I spent the vast majority of my career working for Hertz, the Cardinal company. And I, I, I worked on their website from when it was just brochure wear all the way up until 2019. And at one point every month we would meet with our customer support team and they would give us sort of like this curated list of these are the top themes of the issues that are being reported to us. And we, we started seeing this complaint that said, or not a complaint, but a comment that said, hey, I'd really like to add my reservation to my calendar. Like just after I make a reservation, can you have me add it to the calendar? And we were always kind of like at the time anyways, well that's post transactional. It doesn't make us any money. So we're not going to do that. Like, well that's, that's a lower priority. It's there but it's low, low, low. And then one month that changed, that comment changed and it morphed into how come you're the only car company that doesn't let me add my, my reservation to my calendar? And then it was like, oh no, now we're at a competitive disadvantage. We need to, that, that commentary just went a lot higher. Now if we'd been doing a bit more active listening, we probably would have got that got ahead of that. But still it's just one of those things where the people that channel where it's coming from is important. And you also said something really important, which is sometimes you got to say no to a customer. You got to see or there's the cost of firing a customer if they're not the right customer? Well, you have to say, yes, I understand that you really want this, but that's not us. We're not going to do that. Were focused over here. And that actually leads into this other question that I was thinking of. Teams get caught up between like putting out daily fires versus really just understanding what the customers need, the road, what the roadmap should look like. And at the end of the month I go, where did all the time go? Oh, we were just doing all these little things, we're just putting out all these little fires that didn't really matter. In your opinion, when you think about a sustainable voice of customer cadence, how does that actually look for a senior product leader in affecting the day to day what they're doing?
- [20:43]
Jeff Lash
I think a lot of what you're describing happens because a lot of times products are developed or managed from the bottoms up, right? Like, hey, we got a bunch of stuff in the backlog, we got a bunch of voc feedback coming in, we got a bunch of sales requests, all right, let's prioritize those and just like just add them to the queue. And then it's just this hamster wheel that you keep running on and you look and you're like, did we really do anything or did it have impact? So this is where a top down approach is really needed. So understanding, yeah, what is the vision for the. Well before even the product. What's the vision for the company? Right. What's the company strategy? What's the organizational imperatives? What are the priorities, you know, near term and long term, what is then the portfolio strategy? What is the product strategy or vision? Right. Kind of a pyramid kind of moving down. So when we get to the point where we say, hey, we've got 20 different pieces of feedback, rather than just saying, well, this one seems important, but this one's yelling really loud and this is a big customer over here. You can say, all right, let's look at those priorities and goals and measure up that way. It doesn't mean that 100% of the time you're going to line things up and you, you always have those situations where we make an exception for one big customer that we want to save. Or the CEO says, hey, I got to do this. Or the, you know, but, but I think as much as possible trying to start for that hand up and say, right, in making it obvious that you're making a conscious decision. I was working with one client where I was kind of coaching them through this Whole process and basically saying, look, the CEO every week was asking for something new. And I said, all right, you need to, as a product leader, be enabled to have that discussion with your CEO to say, hey, look, last week you told us X, Y and Z were priorities. Our customers are saying A, B and C are priorities. Now you're telling us to do D, E and F. Like, help me prioritize. We can't do it. Also, like, what's most important and kind of showcasing when we're going to make the pull, you know, that make do an audible and like overrule. Like, it's fine if it's 1% of the time or 5% of the time, but if it's 50% of the time, that's where you start getting problems. So I think that's where VOC fits in. Right. If we understand those bigger vision, the bigger vision, that's overall strategy for the product, the roadmap, then we can say, all right, like what, what areas do we have enough customer insight captured and what areas do we need to maybe dig into more? My view is there's always an ongoing, you know, monitoring of the product you need, but usually there are spikes. Right. We say, hey, we're going to be working on a scheduling module next, because we know people need scheduling. We've heard that over and over. But we need lots more insights on how exactly scheduling should work. So let's do a kind of focused effort into really digging into that. That doesn't mean we stop the ongoing VOC work we're doing, just means we're going to put a little extra emphasis kind of for a specific project where we need more insights.
- [23:28]
Mike McDowell
And what do you think the line is there where a team has to realize, hey, we're relying too much on those secondhand insights that are, that are sort of coming into us versus proactively going and running their own research on something that they, that they want to do.
- [23:42]
Jeff Lash
Yeah. You know, I wish there was a formula you could just plug numbers in and say, you know, yes or no. I generally look at it as based on think of an XY kind of graph of level of trying to think of the right dimensions here, the cost of making a wrong decision and the level of confidence we need. So if I'm just saying, hey, we're going to add a button, because people have been asking for a button to export this to Excel. Right. So if I'm just doing that, I might say, look, we've got a couple pieces of feedback. We know people are asking for it. Great, that's enough confidence. But if we're saying, hey, we're going to launch a whole new product that we're going to invest, you know, millions of dollars over the next X number of months for like, I want a much higher level of confidence. So I think that's where that this, this the art and science kind of mixed together. So the harder a decision is to reverse, the more time and money we're going to put in, the more risk there is if we make the wrong decision. I think that's where you want a higher level of confidence. So I think the other thing is we're never going to have perfect information. And so product managers need to be comfortable making decisions on imperfect information but also accepting, thinking about, right, what if I'm wrong, How are we going to change it? Or just accepting the fact that, hey, we're not going to get it perfect the first time. So we need to have a plan for addressing it. Hopefully we're at least moving most of the way in the right direction, but recognizing that this is not the perfect product in version one. Let's get to here. Do we have enough confidence to get us that first step and then enough confidence that that first step will be good enough for our clients, our customers, and then we plan to iterate it after that?
- [25:25]
Mike McDowell
All right. For everyone who's listening, I hope you just. Jeff is after my own heart here, so I hope you understood what he said just there. If you're starting a new big project, a new initiative, something that is not in the market yet, get research done on it as early as possible. You definitely want to stop working on something that doesn't make sense to customers does. They don't want it, they don't care about it. It's not a competitive advantage. Do that as early as possible. So I loved hearing you, hearing you say that. And since that was sort of almost like a grand statement, I'm going to ask you to sort of put exude your inner oracle for the moment as people are going to really need help with this one. And this is a bit of conflict resolution internal at orgs, which is I don't say ever present, but usually it is, let's say you're getting feedback from sales or support or one of these other channels and it conflicts with what you're hearing directly from customers when you do your own research. How do you help teams sort of reconcile the differences without sort of eroding trust or breaking down relationships in your organization?
- [26:32]
Jeff Lash
I'll pause here and Oracle do my best to Channel. So I would want to first start with understanding what the differences are. When you get feedback from sales, it's generally one of two things. It's, this is what I think I need to close the next deal, or this is why I think I lost the last deal. Right. It's very neat. They generally are, especially at individual sales contributor levels. They're very focused on, like, my specific opportunities, my specific pipeline. The higher up you go in the sales organization, they usually most, in most cases have a much broader view. So it's not just one deal or the last deal, but it's like, hey, here's a pattern we're seeing. So if I'm getting that feedback from an individual salesperson, I might say, well, it's, you know, I might not put as much stock in it as it is. If it's a VP or cso, I want to, you know, dig into it a little bit more. I'd maybe share with. And I'm just spitballing. You're like, I might want to share with them. Hey, look, you're telling me X, I'm hearing Y. Let's talk about why we think we're hearing difference. I might want to talk with some of those customers directly. Right? You told me this client wanted X. Can I talk with them? In many cases, salespeople are happy. They actually really love when someone from headquarters, quote, unquote, is willing to go talk to a client or to a prospect. So, not that I don't trust the salesperson, but I want to understand in that client's own words why they're meeting. Actually, this is.
- [28:04]
Mike McDowell
It's your nursing story again.
- [28:07]
Jeff Lash
Years ago, I was working on a product that was very search heavy. It was a content product. And we did a major redesign of the product for many reasons. In the old version of the product, there was the ability, like on many search systems, to like, jump to the next page, jump to the next page. And there was a button to jump to the last page of search results. And we looked at analytics and we saw that that was very rarely used. And we talked to our users and asked them how they did searches, and they explained like most normal people do. Oh, you know, 90% of the time I look at the first page and I never go past that. So we said, we don't need the jump to the last page of search results button. That's unnecessary. So we did a reader, Ryan. We got rid of it, of course. Like, the next week, what happens? Sales manager calls me up and said, oh, my gosh, Jeff, I'VE got this big customer, they're super upset that jump to the last button of search results button is missing. You got to add it back in. You got to add it back in. And I said that's really interesting. Can I talk to them to learn more? And they said sure. So I go talk to the customer. It turns out it was a content product and this there was the ability to buy extra modules of content besides the standard. This customer was using that button to check and make sure that all the content they had purchased was available to them. So their need was not jump to the end of the search results. Their need was I want to make sure that all the content had purchased available. I was able to say, oh actually we introduced a new feature. Here's this page and here's this list. And I also. And they, and they were able to go and say, oh yes, here's the things I've purchased and validate that they actually had access to them. It also taught me, oh, we might be, maybe didn't make that page prominent enough. And so it's a great example of it's not that the salesperson was wrong, it's not that the customer was wrong, it was just how they were. What they said they needed was not really fundamentally what they needed. I think a lot of cases it comes back to that underlying. Very rarely have I seen a situation where what we hear from our VOC research and what we hear through sales and CS are you know, 180 degrees apart. It's more like, you know, 5% different or you know, some nuances in the difference. So I think transparency, you know, engaging those people in conversation, sharing, hey, here's what I heard, how's this different? And then let's try to figure out, it may be that again, oh, you're getting feedback from one segment of customers. We did research with a different segment. You're hearing from these Personas or hearing from different Personas and trying to figure out like where is the difference and if there really is a difference then that might be where we need to do more research. But in most cases I found that it's usually comes down to details like that where it's just we're asking different questions or we're talking to different types of people.
- [30:47]
Mike McDowell
It comes right back to the thing you mentioned earlier, which is just asking follow up questions. And unfortunately to your point, sometimes sales doesn't know the right follow up questions to ask. You do have to get that product person or the person from HQ to come in and say you know, tell me more about that. And again, I started over talking before, but it sounds a lot like the situation with your nurses station story. Like, let me just ask one more question on top of that.
- [31:10]
Jeff Lash
Yeah, I know there's. I mean, in fairness, like, that's not sales's job. So I'm not upset that they didn't ask the question. That is not their job. Absolutely. Like, they are doing what they are paid to do and what we asked them to do. So, yes, there are times where salespeople will ask more questions and they'll bring back great insight. And I've worked with great people like that, but I'm not expecting them to. You know, I think like I said, sometimes you'll start to see patterns. And that's really where a good partnership is really important. Right. Whether it's sales, whether it's technical support, customer success, whatever that group is, they're just doing what they're doing as part of their job and they're going to gather insight as part of that. It's our job to assess that, filter it, see if we need to dig in more and understand how to use it 100%.
- [31:55]
Mike McDowell
It seems like what we're talking about here is a little bit of a mindset change, A little bit of a mindset shift from just taking it at face value. Customer said it, we have to do it, to investing a little bit more, bringing more people in. A lot of people will think, oh, we have a process problem here. We're not listening, we're not getting feedback. But really it's sort of maybe more of a mindset change of, no, we hurt, we listen. But now we need to go back and we need to. We need to dig deeper on that. How do you, you know, basically what is. When you look at those issues, do you see a lot of mindset issues that really get disguised as process problems that people are talking about? They're not really looking at them the right way.
- [32:41]
Jeff Lash
Do I see mindset issues that are disguised as process problems? Yes, definitely. I mean, the short answer is yes. I mean, I think one great example that I've dealt with a lot is prioritization, right? So people talk about, oh, we don't have a process for prioritization, or, you know, we can't agree or whatever. And the reality is like, maybe it's just that your roles and responsibilities aren't clear. So let's talk about, you know, imagine a lot of the people listening to this or watching this are in user experience. Design, Product. Design roles. Right. Product design. Versus product management usually has a very good relationship, but sometimes it's not clear. So when we have discussions or debates about, oh, well, you know, you're not following the right process or you're not, you know, the process isn't clear. It may be, no, just at the end of the day, someone makes a decision on something and in many cases for product decision, that's the product manager, but it should be influenced by the product designer or UX person. So I think that there's something where I like to say, you know, like, I deal with this. A lot of people, they ask about technology when we're working with technology. Like a good piece of technology can support a good process, but if you don't have a good process and a good piece of technology can't fix that, I think the same thing for, you know, a good process can help reinforce and support the right mindset, the right roles, responsibilities. But if you don't have that fundamental understanding, just slapping a process on top of it is not going to fix things.
- [34:03]
Mike McDowell
Yeah, I, I lit up when you said prioritization because in my experience that's always, always the hardest thing because it's got the most players involved. Sometimes you got really loud voices, got some hippos, you got some whoever. You know, everyone's trying to get things done. And really, truly being voice of customer centric and letting your customer help supersede a lot of that is a huge mindset change. Whereas everyone thinks it's like, oh, the process doesn't work. You know, we've got all these, we can't get the. You guys can't listen, you can't hear, you can't set priorities quarterly. It's tough to set priorities quarterly. Right. When everyone's fighting fires every day, getting calls from the CEOs kids telling you they didn't like something and you change it.
- [34:42]
Jeff Lash
Yeah. And I think a lot of times that that voice of the customer can be the great equalizer. So I'll give you one example. Well, to think of two examples. One where I worked on the product actually when I was in a UX role years ago. Another where I was, I was advising a company. So when I was in a product, I was in a product in a UX role years ago and working with a product manager who had a very, very specific opinion about how the product should work. This opinion was not based on any data or facts, it was just based on that person's opinion. And they were a smart, bright, successful person at the company. So of course they think like oh, well, I have this opinion. It's right. So rather than arguing with them and tell them why they're wrong, I went out and we did a bunch of research and came back with some data and then we did more research and I brought that person along with me.
- [35:32]
Mike McDowell
Right.
- [35:33]
Jeff Lash
So they could see and hear the stuff firsthand. And it wasn't that they were completely wrong, it's just they were, you know, they thought people wanted, you know, X, Y and Z in that order. And it really turned out X was not important and Z was more important. Right. So it was, it was kind of a bit of a shift. And so I didn't tell them that they were wrong. I didn't tell them that this is not what customers want. I let them under learn that for themselves. Right. So and it was, look, and if they were right and the customer data supported that, all, all the better. Like, I'm fine with that as well. Right. So it's not about me trying to prove them they're wrong. It was just, I was pretty sure based on what I knew about our clients, this wasn't work. Right. So that was a great. And I've actually done that a lot. I'm sure a lot of your listeners have done as well, like clips, video of clients, of interviews, quotes I use all the time. I've done things where I've brought customers to our offices. When I was a product management role, I brought physicians to our offices. We would do like lunch and learns and I would just interview physicians and I'd invite other people from the company, from the product to just sit and listen. Many of them have never actually talked with a. This was a health care product who never talked with like a doctor. They talk with a doctor like when they go to the doctor, but they never heard a doctor talk about our product. And so it was really just enlightening and they loved it. They, people always wanted to participate. So I think just, it's not about telling someone they're wrong or proving you're right or wrong. It's like, let's let the voice of customer be the great equalizer. I worked with a client who had the same problem. It was a CEO at a head of product with a small company. The CEO would get an idea on a Friday and tell the head of product, oh my gosh, you gotta start doing this. And the head of the CEO was also the founder and engineer number one. So he was thinking, oh, why are you dragging your feet on this? I can just go build this, you know, like, and so what I told the head of product, I said, do you think you can buy yourself a week? I know the CEO is in a rush, but you think you can buy yourself a week? And the head of product said, yes. So I said this was actually a product that was sold through partners. I said, take that week, go and interview a couple of your partners, ask them, get their feedback. The partners were like the sales channel. So they were really implementing the product. They were respected and so they had a product, was able to do some just quick, informal, hey, I'll make a phone call, talk to someone, come back. And the next Friday, you know, go to the CEO and say, hey, I know you told me to do this, but just so you know, I talked to five of our partners and they said they'd rather have something else or they said they had these concerns. And it started, you know, doing that week after week for a couple months, like started to kind of loosen that process. So, yes, the CEO clearly had a vision and was still pushing things, but it was not charging forward at full force without any respect to what the market wanted. It was starting to understand, yes, like, we don't need to go quite so fast. And in fact, if we slow down a little bit and make sure we're building the right things and not building the wrong things, it's going to be more successful. So I think it's not that stuff doesn't happen overnight, but just a little bit of time and again. Bringing users, customers, partners into the process and having their words speak for themselves can sometimes get everyone on a level playing field.
- [38:31]
Mike McDowell
Yeah, I think you really, I remember way back in the day, I think that was sort of like the Amazon way. Like people would email like jeffmazon.com and he would get these feedback over the weekend. And really some of them were great ideas. I mean, some of them maybe weren't. I'm sure he could tell the difference, but they've done pretty well for themselves. But yeah, that was, that's kind of that model that you're talking about. I think maybe we're rounding third here. I think you've already maybe touched on this and now we're just going to sort of revisit it. But you've told a lot of stories today about a lot of different companies. You worked with hundreds of product teams and different industries. What's like the one habit that really separates teams that are that learn fast and other teams that are just like stuck in one spot? Even when both claim to be customer centric, you know, they have it in their Mission statement. Oh, we listen, voice a customer. What's that? One skill, maybe, that separates them.
- [39:24]
Jeff Lash
I'm like, I'm. Rather than a skill. I think I'm more. Talk about kind of a mindset. You mentioned mindset earlier. I think that's actually the biggest thing. I think there's. I think the teams that are most successful have a growth mentality. I hope everyone understands this idea of growth mentality rather than, you know, I hear I've seen a lot of teams that are really good at providing explanations. Not excuses, but explanations. Oh, well, yeah, we wanted to do that, but here's why we didn't do that, you know, or, hey, yeah, this is the reason why the product is set up this way. And we, you know, we tried to do that and it happened. Like, that's great, but, like, let's focus on how. All right, so given that, what can we do better? There's always constraints. There's always politics or people, you know, whatever you want to call it. I think the people that are most successful are thinking about, all right, how can we make this better? And in spite of what happened in the past, in spite of what is happening today, in spite of constraints we have, what can we do in being creative? The great example of Apollo 11, right, where it's like they. They dump the things on the table, like, right, you know, make. Make it work. We got to figure out a way, like, you can say, oh, we don't have enough time, or we should have, you know, this isn't a good request. Or, you know, like, we wish we had more resources, but the reality is, like, this is what we've got. I think the teams that are most successful are always thinking about what can we do with what we have, rather than spending their time explaining or grumbling about why things are not the case. And I think that means that that leads to more innovation, that leads maybe to more testing and experimenting, and also this need to never be 100% happy with your product. Right? Like, you know, it's always tough when someone calls your baby ugly. I've developed products from scratch. I've taken over products from scratch. I really love the products I've built, but I don't think I've ever said this product is perfect, right? It's always been like, all right, like, it was good, now it's better. Like, I think it can be even better and better and just continuing to evolve. In your example earlier about the car reservation, like, even if you build the quote unquote, perfect product, some competitor comes along and does something else, right? And then the market changes. So I think that growth, mindset and that ability to kind of continue looking forward, rather than explaining why we are where we are, using that energy to figure out how to improve it, I think is probably the biggest difference.
- [41:40]
Mike McDowell
Yeah, I think the Apollo 13 example you gave there, a lot of people always, they focus on the expression think outside the box. It's like, no, no, yes, yes. But what can you do inside the box that no one's thinking of? And what can you do with what you have that makes just a huge difference? If you look at this, we're recording
- [41:56]
Jeff Lash
this during the Winter Olympics, or I've got a great Olympic story I heard yesterday. So I'm gonna. I'm sure I'm gonna get the details wrong, but the, the message hopefully, is there. So the skeleton, right, which is that, you know, you're on a sled head first going down the, the. The. The track. So the American team and the Canadian team, I guess, years ago, like, trained together. They were going to be training together. The Americans go up to Canada and they bring this. You know, they had millions of dollars of R and D and all this aerodynamic equipment or whatever that they were. And they were just in a big part, like, 50% of success in the skeleton illusion bobsled is the start. Like, if you can get a good start going, that sets you up for success. And then the rest of it is just steering. The Americans were beating the Canadians off the start. And so the Canadian coach apparently said, there's no way we can beat them, trying to compete with them, because they have so much better equipment, the equipment, aerodynamics, whatever. He took the skeleton racers and said, all right, go off and figure out a way we can beat them off the start. And then came up with this new technique. And if you watch now, what at the time happened was everyone was doing the skeleton with two hands. You put your two hands on the sled, you run behind it, and then you jump. The Canadians, I guess, were the first ones to come up with the idea of holding with one hand running alongside so your other hand can be pumping. Like if. If you're running right, you have your arms move and then jumping on the sled, kind of sliding over and jumping on the sled. They were the first ones to develop that. And, like, they started winning all these races, and then everyone else basically followed suit. So to me, that's a great example of, yes, they might have more money, they might have more, you know, R and D behind you, but, like, saying, all right, how can we figure, think outside the box, quote unquote, think out a way to, to do this better. And like that turned out it worked. And then, you know, eventually the Americans and everyone caught on and they didn't get that advantage. But again, it's just, to me, it's coming back to this. If we just change our mindset, rather than saying, oh, we don't have as much money, we need more funding, we need more R and D, just saying, all right, can we completely look at this and is there a way to do it differently that was in front of our noses all the time that we just missed?
- [44:02]
Mike McDowell
Yeah, I love that story. It makes me think of the Jamaican bobsledders. Let's get some track stars to try to get that fast start off the line. Let's circle back to. This is another one that I think all the product management folks are going to really get value. And you've been, you've very, very, very passionate about this particular topic. Roadmaps. We'll go back to roadmaps just real quick. Again, we're doing a couple of these. Like, one thing, one thing, one thing to wrap this up. The way that roadmaps are communicated perhaps is the single biggest downfall of product teams and how they're viewed internally in organizations. What is the thing that the simulators do today that makes roadmaps harder to use as like a learning tool and a tool for the field to actually benefit from?
- [44:44]
Jeff Lash
Yeah, so there's. I've done a lot of research out there. People can look there. This was a topic when I was at Serious Decisions. We did a lot of research and I did a bunch of presentations. So I think there's a couple of recordings online where I give, like, some, some tips. I think the most important thing that people don't do that is the downfall with roadmaps is think about their audience. One of the most common things I see is that people take a roadmap that is designed for engineering and use that for other audiences. Right. What engineers and developers want to see is a detailed timeline, because they're thinking, what resources do we need, what technology do we need, what team's going to be available, capacity, all this sort of stuff. What a board member is thinking, what the CEO is thinking, what a customer is thinking is not that. It's, hey, like, where is this product going? When will this feature be available? Like, what is the value of this thing to me? So I think that's. There's a bunch of tips I've got out there. But I think that to me is the one, I think the people who get another client story. I had a client I was working with that was the head of. He was actually a CTPO before that term was even recognized. He was head of product and engineering and he presented his roadmap to his senior management team and like they didn't like it and had a lot of objections and asked a lot of questions. They said, okay, great, like let's set up a call, show me your roadmap. And within 10 seconds I could, I knew exactly what was wrong. He was an engineering guy, he was a technical guy by nature. So his roadmap was like organized around the different technology platforms and engineering teams. And it made complete sense to him and it made no sense to the head of sales or head of marketing or head of, you know, partners or whatever. And so basically I helped him take that roadmap. I didn't change the things on the roadmap because I don't know his industry. We just changed the way he presented it, the words he used, the way it was organized. He went back and presented it to his management team and they loved it. It was the exact same roadmap. It was just your point how he was communicating it and presenting it. So he was thinking about himself as the audience instead of thinking about these other non technical people as the audience. So if I had to give people one tip that would be because I think then so many other decisions. Just get, you've said it a couple
- [47:00]
Mike McDowell
of times, know your audience and it holds true. No matter what kind of presentation or thing you're presenting to anybody, always know your audience. All right, the last, this is the last one of these just one thing questions I've got for you and then we'll, and then we'll wrap it up. But you've, you know, again, we've covered a lot of different topics during, during the conversation today. You know, you've worked in product management, you started in ux, Voice of customer advisory consulting. What is the one belief about customer insights that you really wish would change because customers and organizations are still getting it wrong? What is that one thing maybe that you see as a through line that you'd like to see change?
- [47:36]
Jeff Lash
Ooh, One thing. I don't know if this is the biggest one, but maybe it's the one that I've encountered the most during my career. I think this is getting better, but I remember dealing with this a lot maybe 10 plus years ago, and even now it's still a bit qualitative. Insights are valuable. I think so much of this is oh well, we had two customers asked for this or 10 customers asked for this, or we ran a survey and these numbers, or we did AB testing. I mean there are so many technologies and platforms that make it possible to do so much more rapid experimentation and gather data quickly and that is super valuable. But you know, one insight from one customer can have a, you know, the light bulb can go off. You know these stories I've been sharing, like some of these again have stuck with me for 10, 15, 20 years. It doesn't mean I would make a whole change in product strategy based on one customer. But I remember, you know, working on stuff when I was in UX and we would come back and do a lot of, you know, one on one interviews and observational research and people will be like, well you only talk to eight people. I'm like, yeah, but I've talked to eight people and they were representative users and none of them liked this idea, right? So like I can go talk to 20 more, but I'm pretty sure that all 20 of them, like they were not an anomaly. So I think I've seen that change. But I think there still is a lot of reliance on only quantitative or like prioritizing quantitative. And I think understanding that quantitative and qualitative both have a purpose and there are times where you might be over emphasizing one at the expense of the other. And that to me the best power is quantitative to show what is happening or what people think. But the qualitative really helps us understand why. And if we've learned anything from the stories I've shared, the survey will tell you accessibility is the problem. The interview will tell you what they mean when they say accessibility. Right?
- [49:36]
Mike McDowell
So I need to promise everyone that I have no idea what Jeff was going to say as the answer to that question. I did not, I didn't know he was going to talk about qualitative feedback, but I certainly love that answer. Qualitative is super powerful and you know, I used to sit behind two way mirrors to get that. Just a few people to see what they would say. It can unlock so many possibilities because when you, someone who doesn't know as much as you see something, they just, their knee jerk reaction is just, oh, that's really weird. I thought that looked like this. And you're like, wait, what? You thought it looked like this instead of that? So huge. Jeff, I just want to say thank you so much for being on the show. This was such a fun con. I was like talking to an og. I love the conversation. How does someone learn more about you, your thought leadership? You mentioned there's a lot of things online, but you know, how can someone find more about the work you're doing and the team are doing at Insperity?
- [50:27]
Jeff Lash
Yeah. So a couple of ways. Probably the best thing to do is to follow me on LinkedIn. It's just LinkedIn.com in Jefflash. I'm doing something in 2026 which is posting a product management tip every day. I did this in 2021, I did it in 2023 and I figured it was time to do it again. Not using AI, by the way. This is all like handwritten, maybe using AI a little bit just to clean it up. So if you like this stuff, it's just a simple, short product made tip in your feed every day. You can also find me@jeff flash.com that has links to a bunch of other podcasts and blog posts and things like that. And then, you know, my, my day job quote, unquote. What I'm doing at Insperity is really we're supporting small businesses, helping them grow and succeed in helping the communities they serve through HR services and technology. So if, if you're a small business and you're interested in how Insperity might be able to help you, Insperity.com is the best way to reach out.
- [51:27]
Mike McDowell
Excellent. And your tips from your tip from yesterday is one I have to be better at, which is stop just answering everybody and instead point them to where the answers live. Send them to the knowledge base, send them to, you know, the intranet area that's got these things. That's one that I fall victim to. I answer people more often than I send them to where the answers are. So really, really great. Jeff, thank you so much.
- [51:52]
Jeff Lash
Thank you very much for having me. I enjoyed the conversation and glad to be a part of it. Excellent.
- [51:59]
Podcast Host (UserTesting Intro/Outro)
Want to keep the conversation going? You can find the show notes@usertesting.com podcast if you haven't already. Don't forget to follow us on Apple Podcasts, Spotify, Overcast or Google Play, so you never miss an episode. And if you enjoyed today's show, please share, share it with a friend or leave us a rating and review on Apple Podcasts. And until next time, this is Insights Unlocked, an original podcast from User Testing.