AA153 - "I" Know What the Customer Needs

0:00

Om, I don't know how many times you've heard, but I've heard a bunch of times. I know what the customer needs. I've heard that all the time. Tell you, I'm gonna tell you, I'm gonna tell you what the customer needs, right. And I'm going to tell you in gusto. Right. It's like, I tell you what they need. That's right. That's what they need. Go build it. That's right. So we're going to talk on this podcast about the different people that you will hear that from. I know what the customer needs, right. Or, or it's what the customer needs. I'm not really sure what the title of the podcast is going to be, some sort of deviation on that theme of, I know what the customer needs and I'm going to tell you. Yeah. Let's start right away with the person you should be hearing this from, which is the product owner and or manager. Yeah, so the problem with the manager I have more confidence that what they're telling you is real almost, especially if your product managers and product owners are actually talking to your customers and not just thinking about stuff out of the ether, right? If they're speaking with the customers regularly and they say, here's what the customer wants. Okay, my first question always, regardless of who tells me that is, so how do you know? Have you validated this with the customer, right? And, and then it goes deeper than that well, who did you talk to? Who who are the customer representatives that are telling you this, right? Maybe on this podcast, we're going to get wearing units talking about feature factories here in a second, maybe, but in an ideal scenario, your product manager is talking with your customers on a regular basis. They're talking about the customer's problems and they're turning those problems, bringing them back in house and turning those problems into solutions in the form of software. That solves your customer's issues, right? Yeah, I mean, look, I agree, right? In an ideal scenario, people are not just listening to the customer tell them what the customer wants. They're asking the why. The customer says, I need X, Y, Z. The questions are, why do you need that? You know, or, what would happen if you didn't have that? Right, just to understand the context behind it. So they can come up with a better solution. So assuming all of that is happening and people are coming back to you, whoever you are, to the teams and say, here's what I found in my interactions with the customer. I have more faith in that. Because now they've actually, I mean, they haven't come up with it, like I said, out of, out of the ether, right? They've, they've got some. Credence to this. Yeah, and the better product managers that are out there are going to bring the problems back. And they are going to collaborate with the team. Right. And let the team solve the problem. I just had this discussion the other day. with someone interviewing for a product manager role. And they have a technical background. Right? They don't come from the business. Right? And one of the things I brought up, I, I bring up the, the challenging part of the interview. I try to bring up as early as possible in the interview because I, I'm not, I'm not the hiring manager. I'm just a peer in the organization who would be this person's product management peer if they were to get hired. So I'm coming at it from the perspective of You know to be successful in the organization. So, of course, I'm going to bring up the very first thing that I'm going to say, Hey, don't you think you may have difficulty because of whatever, X, Y, and Z? And what's your plan? Right. First of all, are you aware of it? Right? And second of all, what's your plan? You know, how do you think you're going to reach out for help? Or who who would you reach out for help to? Right. Anyway, it's valid criticism. If I were interviewing for a product management position of you have a technical background. So I automatically expect that when you hear a customer problem, your brain switches to solution mode. You would think the more experienced you are, the better you get at forcing yourself not to switch into solutioning mode. I think it's the opposite. The more teams you work on, the more solutions you have seen to problems. I think you're saying, Oh, we solved that on a different team this way. What do you think that would work here? And everyone kind of nods and says, actually, we do think that would work. And now, and the issue with that is you've gotten to the solution pretty quickly. Everyone will agree. And seemingly. You've moved through the planning and the solutioning and all that kind of stuff pretty quickly. Yeah, you're absolutely right. So that is, that is actually true that people who are more experienced have a bank of solutions from their experience, right, that they can say, this is almost like what we did before, so therefore it will work here too. And what they're ignoring there is all of the stuff that's around the issue, right? You know, it's not just the technical solution that's warranted for here. You're looking at who are the customers who are going to be using this? Is your customer the end customer or like are they a B to B customer and they have a B to C customer, right? You need to think about all of that. And maybe your previous experience didn't go down to that level of detail. So yeah, people do have. There's a, there's a tendency to simply pick something and say, this is what we did before. It's almost this. It'll work, right? And those people that have not so experienced or they haven't been in the company long they're going to go with it, right? They'll just simply say, yeah, if you say so. And I think we've missed the boat, right? Well, I mean, especially the more junior people on your team or the, the product managers who don't have a lot of experience it's really easy. To lead the witness here. But the problem there is like you, then the team never gets the win because you're, you're the person with all the answers. I would imagine people would start to resent that you're the person with all the, don't bring him in. He's like, we'll never come to this. He'll just tell us what we're going to do. And then he'll heavily imply that that's what we should do and get mad when we don't want to there's dangers here. There's some rocks in these waters. For sure, there's crocs in this water. Yeah, absolutely, you're right. People will find that out, and they will, like you said, they will then start to not invite you to those calls. I also think the anchoring that happens, right, Loses so much because the customer doesn't know all of that. Presumably it's not the same customer that you have a previous solution with. So, they're going to go with the position of authority that you present as a senior person. Product manager, product owner, architect, whoever. And, and they'll believe you because you come from that that position, like I say, of authority and say, we've done this sort of thing before. It wasn't exactly that, but it was close. Okay. Right? Because for them, it's good because they can get to the solution faster. But are they? Right? Yeah, I mean the challenge there is because you're not really walking out the problem, you may skip learnings that you otherwise would come to. But the product manager, if again, if done right, the product manager is the one person bringing us back to the vision and tying this into the rest of our products that the systems view the systems systems view. What am I trying to say?? Systems thinking. Systems thinking. Yeah. The systems thinking view of, of the entire all of our software and all of our products and whatnot. You know, that, that, that would be the advantage here is that like, well, how can given without disrupting the rest of our products how can we offer a solution that that should be the advantage in this category. The con in this category where, where product managers. Might fall foul in this category, I guess. Is using that. Oh, the customer said that like defensively all the time. Yeah, I've had a product manager. Who was like that. And it was not, it was not pleasant to get hit with just basically get beat over and over and over again. It was like, that's not that the customer didn't say they need that. So we're not going to do anything like that. Come on, man. Yeah. Yeah. I mean, there's definitely a tendency of product manager to say I want this my way. So I'm going to just help the team. Right. And because I don't want to talk to the customer, they have to believe me. Right. This is where I think there's huge, huge advantages to be had in having more than just one person who interacts with the customer. Yes, the Product Manager could be the face, right? That's fine. But bring in people with you who can ask questions, probing questions that you maybe aren't in a position to ask because you don't you're not coming from that. Background. Yeah. You know what? So I would start with with business related things first instead of just technical things like I mentioned earlier, I would ask the customer what would be the impact if you didn't have this thing that you're looking to get? Right? Because it tells me heaps about what the real need is, right? And then later on, not now, but later on, you could come back to the customer and say, Hey what would happen if you if we gave you X where X is close to what you wanted, but it's not exactly that. What's the impact of that to you as a customer? I think it behooves you to understand that landscape because you really can't build a solution that meets their exact needs. Any other way, in my opinion, I mean, how are you going to do that? You'll assume things, you'll believe certain things in your mind, you'll certainly look at your experience or collective experience of architect, product manager, etc. And dream up a solution, go develop it and position it to the customer and go, this is what we got for you. Only to be surprised when they say, it's not quite what we wanted. Yeah, I mean, plus if you're solo in that fact finding expedition over there what's it like, what's the chances you're going to go on safari by yourself and come back? Like, it's better to bring other people with you. Talking to customers, same thing. Are you going to be talking to customers, and you're going to get every single nuance of what they said, and that's going to be your opinion. Rather than two or three people taking notes and remembering the conversation and comparing those notes to talk about what you all think you heard it's, it's just better with more than one person always. Yeah, absolutely agree on, on field trips as I call them. When we used to go out and my role in this in this particular exercise with a previous employer was not product manager. Yeah, I was simply going in there to help sales and marketing with sizing capacity, those sorts of things as a. Project manager, basically, but we would listen, we would observe, and then in the evening we'd get back together at the hotel and say, here's what I heard, and somebody would say, I didn't hear that, I'm glad you caught that, and we'd collect our notes, and we'd come up with more questions to ask the following morning, right? Now these questions that we ask the following morning are At the next level, right? Because we just kind of scratch the surface the first day. So, I agree. I think the power of multiple minds is the key here. Yeah. Yeah, there's really no reason to argue. You can just go and ask the customer, hey when you said this, Some people thought this, some people thought whatever what is the right answer? You know, what did you really mean? Can you elaborate on that? Like that's like a five minute call or actually it's a an email actually. Can be. Yeah, for sure. Yeah. We talked a lot about the product manager talking to customers and being the one saying, oh, I know what the customer needs because I've talked to the customer. But what about in, I would imagine in a lot of shops out there, The product manager is way too busy, especially in shops where like the product manager is more like a marketing type of person. Right. Right. And they don't really do the work of, Oh, that talking to customers and come up with solutions. That's the development team. They, they do that. So there'll be a proxy in place. And that proxy, sometimes that proxy is a business analyst, which I honestly, I'm kind of like, I'm, I'm on the fence. Whether to say like the least damage can be done with a visit with actual business analysts rather than just like a random I, sometimes I've seen like a dev lead or an architect trying to be the PO proxy PO type of situation cause companies cheap. Sure. A real business analyst with their salt would have a particular set of skills, right? And they can ask the right questions. It's valuable to have that. But I think it's important to make sure that we're not simply representing one facet of our organization with the customer. Just the business analyst alone, they're going to be very, well, analytical, right? You may have somebody who asks questions that are completely lateral. To the situation I had, and that may unearth certain things, which could be crucial to the situation. Somebody who is really vested in, you said earlier, solution mode, right? People have this tendency to do that. So if you're vested in just that, or if your business analyst is going to focus on, this is the old way of thinking, but still, right? Document the as is and the to be. Those are two states, but there's a lot in between them, right? And from the customer's point of view, who are you speaking with? Is it one person? What is their role? Are they only telling you about it from their perspective? Or are you getting a full holistic picture? Right? So, we need to not only have a Multitude of people asking the customer these questions, but we need all of those roles represented that will be Affected by the solution. We're in a real thin niche right here about a business analyst who's a proxy product owner right now. But I'm going to focus on the pros of having this person in that position. Like, it's, it's, everyone knows it's not ideal. You'd rather have the empowered product owner for the team doing this role. But, but, the advantages of having if you actually have a business analyst, a real business analyst, Doing this, I don't know, as opposed to a fake business analyst. Somebody who just has a bra and a hat that says BA. I don't know I just, I don't, does that really happen? I don't, I don't, I don't challenge myself in the middle of a thought, but I think people just like putting on the hat of product manager when they're really something else is way more likely than somebody putting on a business analyst hat. Yeah. I think the business analysts probably are business analysts in more Often than the product managers are product managers. Oh boy. Like we're gonna get into trouble in this one. Well, that's fine That's what we're arguing as you know, I agree with you. First of all, there's so many people that are Out there, self proclaimed product managers. Self titled. Self titled. And they have not really had any product experience to speak of. But yeah. Yikes. Yikes. So assuming we give this business analyst the full credence they deserve, which is they are a real BA. Yeah. They're going into the situation. Yeah, the cons are several, actually. So they're going to ask the right questions. They're going to ask questions from the perspective of the behavior, typically. Right? That's good, I think. Right, they're gonna ask questions from the perspective of personas, perhaps. Right, well, that's just fantastic. Those are all the pros that I was gonna, that I was gonna assign to this role, is that if you have somebody who understands how to, how to conduct research. This is the same thing, there's a job out there, a UX researcher right now, it's getting a lot of attention on LinkedIn, something like that, UX researcher., they're doing a lot of similar things that the business analysts do in terms of like, I'm gonna experiment. I, I wanna understand why this path was taken and not this path, or why this path led to the user not understanding how to do things. Like business analysts will do all, they'll do the analysis, they'll do the research, they'll do the legwork, basically. Yeah. To really understand why the customer's doing what they're doing, and then they can translate those customer needs. actionable requirements. the business analyst can say, this is what the customer needs and this is where the, this is where the pitfalls are or whatever. And this is what we could do. Like, here's a few, a few places we could address, there's a way they can do it where they're not solutioning. They're, they're just purely pointing out that you know, path a is ends in a ends in a cul de sac, path B ends off a cliff, in doing that, they are now like a, a advocate for the customer inside of the organization while the design of the software is happening, while the software is being crafted basically. And you, you could say like, well, the product manager can do that too. You sure. But again, in the organization where you have business analysts, I'm assuming you're somewhat larger of an organization and the idea of deploying the business analysts and not the product person is the product person probably has a bunch of other more marketing centric type activities and they're trying to hand off these day to day type of things to somebody else. Definitely, definitely that should be the scenario. Yeah, I agree. I think a product manager who is more, how should I put it more aware of the offerings of their company, they may be more involved at a lower level, as opposed to a product manager who Has BAs and simply is going to say, well, you go, right? I'll make sure that the calls are arranged or the meetings are arranged, etc. That's fine, too. I think it depends on the scale of the company, as you said. So yeah, we touched on the cons, I'm sorry, pros, right? What are some of the cons of sending a business analyst type of person, right? Into a situation like this to find out about real customer requirements or needs? I mean, the, the immediate con is, either one of two things I think would happen, I'm not quite sure, I haven't really thought this through very much, so it's like any other podcast topic that we talk about like, either they'll only ever be working on the latest fire they'll only ever be exactly where the latest fire is, or They'll be so far ahead that you you don't and because and because the VA isn't empowered with prioritization They may be taking requirements for something that we may never build Yeah, I think that danger is very real because they can't make decisions So they're gonna basically collate more than they need right so you'll have the wheat and the shaft together and Pass it on to somebody to make the decisions now because they're not empowered to do that, right? Are they empowered to even prioritize that list? Perhaps, perhaps not. In most companies, they're not. Or they're afraid to. So then, who makes these calls? Is it a product owner or a product manager? Now they've got way too much to wade through, right? To figure out what are the real footprints that you're looking for. So yeah, that's a real concern to me. The other real concern is the BA is not likely to challenge you know what they're hearing right from the customer because, well, it's the customer telling you, doesn't matter who it is, they're from the customer side, so to speak and so they're going to just take things down verbatim without challenging I've been lucky enough to be partnered with a lot of talented, very talented BAs, but they don't necessarily have the vision for the future. I mean, they, they may know enough. to be able to construct some likely futures, but they're not like the business leader that is painting a vision of the future for the whole department or product or whatever. They're not really, that's not their job. Basically they're not at the vision level. a lot of BAs that I've seen that they just jumped from fire to fire. You know, figure out why this failure happened and then we'll talk about in the next sprint or the next two sprints or whatever, we'll do a percentage of work to try to pay down this technical debt, but I need to understand it. So get in there and figure it out or get in with this customer and figure out what we can do to resolve their problems with. You know, I'm willing to throw two sprints of work at it to figure out what we can do in that time. What they're working on is such, it's so like micro slices that they're not working on the large, broad picture, like a product manager should be. Agreed, absolutely. So their, their kind of approach is more tactical, right? Yeah. You know, in terms of like the immediate few sprints. Now, I, I will say I have been, I have been at companies. The BA will be deployed when a project begins to sort of bring together like a like a, a charter or something like, I'm like, this is, this was more like a PMP project manager type of organization that the, the, all the project managers had BAs that were basically staffed. On their projects, like a project manager wouldn't ever go anywhere alone at this particular company that I'm thinking of. They would, they would always have a BA with them and the BA would basically say like, hey, we need to scope this. So in that, in that instance, the BA was putting together, I guess I'm contradicting what I said earlier. In that instance, the BA was putting together sort of a A vision of what the product was, but it was a, it wasn't a product, it was a project. So the BA, like it was, the project was bounded by the beginning and the end of the project manager's project plan. So everything was temporary, it was all temporary. They tend to work a lot on the scope side of things as well, right? Yeah, other than the charter, I agree. Yeah. We touched on it in our conversation, but we really didn't go into detail of now I can't gather and like, I can't engage in anything because the BA hasn't put their hands on things and figure out the requirements. So now everything that I need to bring to my development teams goes through the bottleneck of the BA. Yeah, this creates a stage gate at that point, right? What would happen instead if you had a few of your team members? Could be a team lead or a tech lead, whoever. Engage with the customer during that discovery phase, right? They could be asking the questions. And some of these questions I mentioned earlier, they could be questions that are tangential, but not really completely Out of the scope necessarily, they may ask things like, well if we do it this way, what, what does that mean for you from, from your security posture, for example, right? Things like that. And from there, you could really hone in on what can work for the customer. Your team can avoid a lot of rework as a result of that. And all for having somebody else with the B. A. or the product manager, product owner, because presumably There comes a time where people need to talk technical. I mean, real technical, right? Beyond which cloud service provider we're going to use. It's way lower than that. This is where I think the B. A. can help recognizing that situation and bringing those people in. It doesn't have to be the first meeting with the customer. It can be a series of meetings. It could be after the first one. But at some point, bring those guys in and they will help you Either avoid rework or making sure that you're you're working on the right path for that solution. So the solution set is what I like to call fit for purpose, right? All right, let's pivot into one of my favorite categories that we're going to talk about today, which is my boss told me it's what the customer needs. That doesn't happen, right? Oh, it happens all the time. The room and says, Hey, I, I, This is what the customer needs. What do you do then? That's right. I know what the customer needs and I'm your boss. Yeah. Caption working in a feature factory. Like this is, this is your part of the podcast. I mean, listen, your boss again, because they don't work on development teams they probably have either insight into the business objectives that maybe you're in you don't get exposed to every day, right? or They may like you're depending on the company. Your boss may have deep industry experience And they might know what they're talking about because they've been in the role that you're developing software for. I've been a couple with people like that plenty of times. They've lots of domain expertise. Yeah, I agree. I mean, that's certainly those are things that I've seen before, but also I've seen where your boss will come in and say, this is what the customer wants. And they've really got no basis for that. Right. When I say that, I don't mean they're just making stuff up. Although I think sometimes they do. They will come in and say. I heard customers talk about this stuff generally. And I've just kind of connected two and two and come up with 22 in my head and said, if they had this, I think it's going to be great because we can leapfrog the competition. These things happen, believe it or not. And these things cost companies real dollars over time, right? So, nine times out of ten people though, to go back to your question, when your boss comes in and says this is what the customer needs, they'll just say, yes, sir. Just get on with it. Yes, ma'am. Yeah, like the one the the thing that always got me in trouble in this world is What what leads you to believe that? is that phrase which is partly responsible for my transition into product because in product you Can get away with asking that because that's your job in product to ask what leads you to believe and that's a well the customer Told me well now I need to know a little more Because in order to ask follow up questions, in order to verify when we build these solutions, or when we come up with wireframes or mock ups, I need to go back to that customer and verify. You say it so much more eloquently than I do. I usually just say, when the boss says the customer needs this, I always say, well, how do you know? Yeah, right. How do you know they need that? And yeah, I'm that 11 out of 10. I mean, usually we're looking for work shortly after, but, but whatever. Right. We just say, how do you know? The customer really needs what you say they need. You heard something. Let's go validate that. Sounds like you're not a team player. I'm not a team player. No, I'm a rebel. Yes, get not team player written all over you. Yeah, yeah, yeah. Rebel. Just do what I say. That's right. Do as I say. And yeah, yeah, yeah. So, I mean, look, if you're in, if you're in a, I was going to say if you're in product, but really, whatever role you have. Could be any, yeah. Feel free to question this and say, how do we know this? Now you can contemporary your question better than I do. I, I just say, how do you know? But you can say, well, what makes us believe that's right. That's really what they want. Right? Right. What have we done to validate that? Right. Right. Can we perhaps engage the customer again? Yeah. Right. And, and the red flag here would be no, you build a solution and I'll go back to the customer and verify it. Huge red flag. Huge red flag. Because, because, and, and like I only say it's a red flag because. Product managers have this problem as well, where they'll build a feature and it'll never verify, you know what I mean, or, or they will never go through an MVP do some wireframes, some mock ups, say, hey, what do you think about You know, click through this prototype with me and just give me your initial reaction to how it how it, do you think it will solve your problem? We look, some companies think that's a waste of time because you've spent time and effort creating a prototype. I'll just finish the thing and send it to them. Right. There are companies that do that. They just said, there's no. I'm telling you this. I'm your boss. I'm telling you this. Yeah, that, that's a bit bananas. Like I, I most people, I think when they hear that my boss told me it's what the customer wants, they're gonna already suspect. You're going to already suspect that this is some sort of personal agenda or, you know what I mean, that the solution is going to be suboptimal or I've had plenty of, of bosses who said like, Oh, I know what feature to build, we're going to build this feature and then nobody uses the feature. And then the blame begins of like, you built it wrong or we didn't market it enough or it's, it's, it's too hot or it's too cold or whatever. Come on, man. Like you can't, you literally cannot say that you, you might've been wrong. Like that, that can't, that's not in your vernacular at all. I might've been wrong about this. Well, it's, it's the company culture, right? So it comes back to that again, but. I think no matter what, if you're not looking at how well your solution is landing with your customer, you're not gonna know. You've delivered something you believe they needed, and maybe you got lucky, right? Let's say they needed that 90 percent of the time, you're right! Fantastic! Guess what? Play the lottery. But, here's what happens. You don't know if they're even using it. In the wild in production, unless you're tracking that right. So the post delivery telemetry past done is critical here for product. Go figure out. Is anybody even using it? How often are they using it? How is their experience? Are they struggling through it? Because it basically doesn't work. They will The way they want it might work exactly how you implemented it, but it's not how they want it. So it's, there's a Delta there. So go identify that there's lots to be learned there, but you've got to do the followup, right? And usually people don't do it because they're chasing the next feature, the next thing, right? To your point about feature factories, right? You're just going to get those features out there. That's right. And that, pressure is also an indicator of this type of thing going on that, that, cause that pressure is constant and, and. Unending is, you know unrelenting. It really is. Speaking of pressure, too much pressure. So let's talk about sales telling you it's what the customer needs. Yeah, so there's dollars tied to our department on a spreadsheet. There's no dollars tied to you. You're not bringing any dollars into the company with your team home because we, Use this really messed up financial model. So what I So it's what the cu I mean, it's what the customer needs. It's what the customer needs. That's right. It's what they need. Just give them Sales people like that are almost like Just give them a black box and go Everything they need is in here. There's nothing. Use a shoebox, whatever. No, you're right. So sales people often have what I call this snap decision, right? They hear buzzwords or keywords and they go Hi, we can do that? Well, we have that in our repertoire. Right. We've got this. Let's just dress it up and ship it, right? So they're more likely to be pressing you further, right, just to get that done because they They're telling you authoritatively, this is what the customer needs. It's all the more important to validate that, because they may not understand the domain they're in. No disrespect to salespeople, some are great, they do understand the domain, but then there are others that don't. Because to your point, they're just looking at their commissions. I think about it as the opposite. I'm at a point in my career where I'm assuming that the sales people do know the domain, and I'm assuming they know it better than the product managers and the dev team. But what they don't do is they don't vet and test ideas, because they don't have to pay for development teams out of their budget. Right? So I, I just came off of reading playing to win like where to play and how to win. Those are the, that's basically the strategy in playing to win. So you have to determine where to play, what market, what audience, that kind of stuff and how to win basically what your goal is. Salespeople saying, I know what the customer needs. The benefit here is they've talked to customers. They don't do anything without talking to people. Unlike some product managers and development teams, you can't sell anything without talking to people. So they're in constant conversation With people that potentially are using a product or using the product so they know the pain points. They know the buying behaviors They're well in tune with this whether or not they actually share these skills with the teams Whole different podcast right there but they can align the features that are about to go onto the roadmap or in the roadmap with Market needs the customer's market needs and the market in general. So if we're developing a bunch of features that like the market is the sales people already know that the markets like, Oh, nobody really is doing that. Nobody's talking about that. I mean, maybe you're building software for early adopters, but the majority of companies out there are not doing that, nor do they really want to, to be honest. It's a risky spot to be in. Because then this, yeah, you need special salespeople to go out there and find, find an audience, finding a new audience for your product that never existed before. And like that's, that's a very difficult. So like, there's a bunch of like, they can really like tie it into your sales team. Well there's some huge benefits here that we don't talk about enough in software development. Yeah, I think you bring up a point where if your sales people are really in tune with the market, the solution space that you're in, right? And they're coming to you with customer needs that they say, well, this is what customer needs. I'm telling you this. Well, guess what? They have a track record. They've been there a while. They might be right. Yeah. But, right, it behooves you to at least just go through another round with the customer. Because, again, a single level conversation is one thing. A two dimensional thought process is another thing, right? Bring in people, bring in two or three people and just say, let's validate this. And, and you'll maybe surprised at how it deviates from the original thought process. It might not be completely out of left field, but it's going to deviate a little. And you're going to save. A lot of hassle by just honing in right to that exact customer need just by having your people talk to them, right? Not that the sales people are not correct. I mean, they are. It's just that one level of conversation they've had. I think if you're a product manager, you're somebody listening to this, a scrum master, really whatever. I think you will be surprised how receptive the sales group would be to say like, Hey, next time you're on an account management call or a visit or whatever, just you know, throw it, throw an invite out, let me know when it is. And we'll see if we have anyone and just kind of tag along just tag along, say, hi, we maintain your solution just see if there's anything and. I just think this is a problem just because they see sales as another department, another team. And this is one of the ones in the agile space that like a lot of people aren't talking about like bring this like HR and stuff like that. Like how to bring this skill back into your team. Will you bring the skill back into your team by starting? To make those people a member of your team. Engage with them, yeah, exactly. You're right, I think often times the people on the teams, they do think of sales as this separate thing, right? And they look at that as, well, when they feed us something, we work on it. It's like, no, there is no them and us. I know what the customer needs coming from sales. Like the negatives here, I think everybody listening knows the negatives here. I mean, the negatives here are sales has their own incentives. And so like I was at an organization one time where the sales people Got commissioned based on recurring revenue is a sass product. So I don't think they had a cut of like every single transaction on the sass product. But at least quarterly, I know if their customers were happy and were increasing in the number of transactions, they got more bonus or whatever. They went to the salesperson that sold. The thing, and I'm like, wait a minute, I was like, this, that makes no sense at all. It was, it was like an account management function. That's what it was really meant to encourage. You know, the better account management, the better you treat them, the more money you get when they spend more money with the company. But it was just sales people that got that money. Like the development teams maintaining the solution got nothing. Customer service people got nothing. It was the weirdest thing ever. And it was really bad. I mean, it wasn't good. Like, don't do that with your company. And also the, the so, so the salespeople might. In that instance, they might really lobby for their customer to be given special dispensation or more effort or nights and weekends type of stuff when it's all about them getting paid. Sure. It's favoritism. Yeah. Now I've seen the other side of it where. And this is not, not SaaS, this was typical kind of you know, multi tier client server type of situation where a sale was made and they, the salesperson got most of their bonus. On signing the contract with the customer. So there's no software yet. There's nothing, right? There's not even those deep dive discussions yet. It's just the customer signed the contract and the salesperson has most of their money. I say most because some of it was tied to the actual delivery of the software. And acceptance, right? 90 days after or whatever. So, in this one company that I was with some time ago, they never got that last bonus because the customer was never happy enough to accept. So, all we kept doing is just keeping the thing alive on CPR, way past 90 days. Wow. And knowing that, they structured the contract in a way where it was elusively called that last that last 10%. They knew they weren't going to get it. Yeah, right. Right? But they're fine with that because the 90 percent more than pays for their yachts or whatever. Yeah, so there's a lot of stuff going on. I think you need to understand your own corporate environment, right? And how things are structured, but get rid of this idea that sales are over there and they feed you stuff and you work on it. Right? And then when you get into the situation of experiencing pain, it's because you didn't engage with them, right? Encourage them. I think most salespeople welcome that. Some don't, but you know, they're kind of being whittled out, the prima donna salespeople. Well, this is a great pivot point. To pivot into one that I'm very happy to talk about, which is the company founder saying, I know what the customer needs. I know what customers need a lot of time. Cause a lot of time, the company founder is the domain expert. In the room, no matter what room they're in even sometimes more so than the customers they're the domain expert. They can provide a high level vision. Usually the mission and vision of the company is set directly by them. So they can really add nuance when they need to, they know the market, they know the target audience the, the user segmentation and whatever that your product is, is going to, they can very quickly, very easily make calls of prioritization founders. They know what's important over other things. They really need very little input from that you know, from there, it's all pros. Yeah, it is. And I think that those are solid pros, but there is a con that I can think of right off the bat, and that is this. They're too vested in the company that they founded. So whatever they hear. From the customer, they're always thinking we're gonna be able to do this. We can do this. Oh, we already do this, right? It goes along those lines. And typically when they when that calculus is going on in their mind, it's also they know the domain. Yes. Agreed. Right. They also know who the other players are, their competitors, and they don't want to lose out. So come what may, they want that contract. And therein, they may take on a little bit too much. Right. The other thing is that the company founders, how can I say this gently they have unrealistic expectations because they're working way more. Then anybody else in the company, they're, they're, they're not pulling a 40 and turn the phone off on the weekends there. They're 24 seven type of people. The majority of them again, it's small companies and maybe larger companies, like directorial people. Maybe they're different, but yeah, you're absolutely right. They, they see a gap that somebody else is filling. You know somebody they're going to defend their territory sure to the death they'll extend to if they're not filling it now They're not gonna say that to the customer. Yeah, right and so we can do that. Yeah, right sure we can do that I mean, you know the tough part about not letting anything go is You're gonna bend and twist Things to get to not be wrong. Yeah, that's a, that's a fatal flaw of this type of person that we're describing right now, which I've certainly seen. Mm hmm. Absolutely same. Yeah, and I've seen it two ways, right? One is I've seen it go south pretty quickly because you really don't have the chops to deliver that Delta, right? That's never an expertise you you had before so you're trying to either buy it or build it and it's a challenge. I've seen the other side of it, which is you blocked out a competitor or two by simply going on your credibility, right? I've been in this space for 30 years. I founded this company. I'm telling you, you can do this and the customer is going to believe you. And then they go and do it, right? They go and do it and they say, I told you we could do it. We've done it. I've seen that too, which is fantastic. But it comes at a cost, right? And the cost is usually the toll it takes to your point, right? On the people in the company. But also an opportunity cost. What are you not doing? You're not innovating something else. Because you're feeding this market. In my case it was an industry that basically had plateaued at the time. And then since dove down a bit. And it's now kind of just doing this, right? Ebb and tide, ebb and tide. So I've seen that both ways. The thing to bear in mind is If that person who has invested so much of their life in the company and in the domain, they are rich with knowledge. Right? So the teams can absolutely depend on them to steer them forward it's like the wind in your sail. I mean, they're there with you, right? They're leading with that. So you don't have to ask permission for directions. You simply say, do we do this or this? Now we do this. Listen to that. That's, that's true. But also just say, well, what are we missing here? Right? If, are we developing this (Australian sounds) solution, to use my Australianism here, for one customer? Are we? If that's happening, what are we missing out? Right? Those are the conversations to have. They may be saying, I know what the customer's need. Based on their own experience or they're making a bet or they're trying to get ahead of the market When the customer research or the, the, the MVP testing of ideas kind of comes up short and says Oh, we, we, we tested this new, this new screen or this new workflow through the screens or whatever. And the majority of customers seem lost or they didn't want to use it, or they just prefer the old version. Ah, don't worry. They'll come around that like, that's a, that's a company founder. That's the only thing a company founder can do and get away with is like I know there's not evidence. But we're gonna steer in this direction and I'm gonna trust my intuition to get us there because it got us here so far. You know, along the way that I'm going to trust it one more time. Like, that's a gamble. Like, how many one more times? You know, how many, one more, one more roll. Casinos always win. No, I agree with you. The intuition, the gut feel has merit, I think. But you shouldn't bank all your chips on it. You know, just look at it as an impartial person and say, What are they missing? And then feel free to Point that out to them and say, well, what about this? Right. They may not have thought about it. In that case, they'll be grateful, hopefully. Or they might just smack you and say, do as I say. Yeah. But again, the response should be the same, which is show me the evidence. What makes you believe? That this over this is the way to go. And if you can't have that conversation, you basically can't make any headway in what we're talking about now. You can't, it's what the customer needs. How about we talk to the customer about this? Well, I've already talked to the customer. You don't need to talk to the customer. That's right. Like, these are all red flags. Like, there's a problem here, you know. I say be data driven, right? That's the way to go because then you can take out the emotions out of it and say, well, the data doesn't show that or does show that. Right. What are we, what am I missing? My, my research shows me this, right? What am I missing? So it's better to talk to the actual customer in all these circumstances. It's any of these people tell you, I've talked to customers, say, great, no problem. You know, let's get on a call with the customer. Just after we kind of make sure we understand what their problem is from you. And we write it all up and we get ready to start. Before we start writing code, before we implement anything, maybe we have some wireframes and we can do some MVP tests, right? Would you be willing to get back on with the customer? Absolutely. Sounds great. That's the process. Let's do it. Now we're talking to the actual customer now, like the rubber has now hit the road. So we're talking to the direct, we're directly talking to the customer. They can give us direct feedback. They can talk directly about their pain points. They can tell you about what they're doing now, what they're doing inside the software, what they have to go out of the software to do. What they really wish that the software would do for them. You can validate ideas. You can run through MVP experiments, stuff like that. However, however like I've run a lot of tests with MVPs in front of customers, and I think the, the best that you're going to get from a customer, unless that customer is a product manager. Because I tell people all, if someone puts a product in front of me, I am brutal, brutal on the product. But the majority of people that I interact with, especially with my products. They're like, Oh, okay. Yeah, it looks pretty good. Oh, it's nice. I like, I like it. And then they just quietly don't. It's fine. Yeah, it's fine. Yeah. Yeah. Yeah. No, you're absolutely correct. I, I would sort of just underline what you said about you know, are you talking to the real customer, right? And this isn't just at the beginning, right? This is throughout. Yes, at the beginning. Are you speaking to the customer or a customer proxy? You got to weed that out, right? If somebody say, well, my users do it this way. Can I talk to your users, right? Who's actually using it? And then do the gemba walk, walk in their shoes for a day to figure that out. Like what are the real pain points? Feel them, experience them, right? But don't stop there. When you have those those reviews or demos. Right? I'm a fan of not just doing a demo for the customer. This all works. Ignore the man behind the curtain. No. I like to just turn it over and go, here, you play with it. And typically that that happens on the state on a kind of stage environment where you have the customers data replicated from their production system reasonably in the recent past, so they can recognize the data and they're testing the capability of the features, functionality, etcetera. on their data in a separate environment from production. But it's production like he's just not going to production with it. But the point is, they're doing the testing, not the U. A. T. Team within your company coming up with charts that say X number of test cases, Y number passed, right? There's no substitute for that. I mean, you're getting a lot for that. You're not only getting feedback directly from the customer, but you're also building trust that this thing is real. There is no man behind the curtain, right? If you can get to that point, I think you're ahead of the curve here, right? So I like to strive for that. I don't always get that for various reasons, but I do keep going after that. when you open up the floodgates and you actually have your developers and your product management team talking to customers, like what is to keep the customer from just overwhelming you like every day. Like I, I had a, I had a, I had a team one time. Where they had a shared slack channel with a customer and it was a terror, like the customers like would randomly just ask for things to be changed and and in this, this slack channel went straight to the developers. It was their developers and our developers. So it All kinds of backdoor feature requests and things that were kind of shooting around product management they're outside of prioritization and the developers would rightly say it's what the customer wants. Like the customer directly asked me for this. I have to like, I have to do what the customer asks, right? Yeah. Yeah. And look, some customers are really, that's a rogue process, first of all, but some customers are really smart about how they how they proceed with this. They will hit up a developer and say. That stuff you did for me last time? Fantastic. You're such a smart guy. I just need this little thing. I know you can knock it down in a couple of hours, right? Yeah, yeah. Hour tops. And next thing you know, that developer is now pivoted away from what they were supposed to be doing. All of that. We know how this works. Look, I don't think we should shut down the communication channel with the customer. First and foremost. But, at the same time This open channel, like a Slack with developers, between developers, customer developers, etc. That is a recipe for disaster. I think what might work better is to kind of have a filtering stage in there. So, welcome all ideas. Stress that there are no guarantees the ideas are going to be implemented, right? This is just simply ideation only at this stage. When somebody goes through the Maybe your product people, and say, Okay, this idea over here. And they can put that on the side, right? Because they believe, knowing everything they know, that this is worth pursuing. And then turn that back around and say to the other customers that didn't propose the idea. What do you think? Yeah. And then see how many hits you get on that, right? If you get a lot of people saying that they like it and again, be data driven, don't just ask for thumbs up, thumbs down, ask for a scale of do you want this? Do you not? On a scale of one to five, whatever, whatever, how you do this. But be objective about it. And that's how you weed out the things that most customers want or more customers want. Not just one customer. Again, even at this point, there are no guarantees because you've spoken to nobody else about it, right? Now, internally to your company, you can look through those with your architects, et cetera, right? Team leads, everybody you need. This is all an internal meeting and say, of these, as a product manager, I think this one's worth chasing and then this one and then this one. Yeah. Can we do this? Can we roughly size these? Roughly, right? These are the initial swags. Again, there's no guarantees yet. Now the communication piece happens with your customers. At that point, what you just did though, is at least you took that one customer request for that one customer and you brought it to a broader audience to say, Okay look, customer access, they're a big customer for us, they're strategic, right? And what they say is really important, , do we really need to add a Y button next to the X button? So we have an X and a Y button. Like, does any other customer need a Y button? Is that something we can sell in the future or whatever? Like, there needs to be a discussion about that. Like, how it's going to join the ecosystem of the rest of the products. You know, do we really need to build a Slack integration into our product? Or something like that, right? Like, will other customers pay for it? And also because this one customer is asking for it. Like. Maybe they, maybe they're not a great representation of the whole market of all of our Exactly. We may not even need to build a Y button. You're just trying to validate whether you even have to go after that or not. There's this fallacy though that is, if the customer wants to get something, and if it, even if it's one, you just give them a quote for it. And if they pay for it, they get it. That's a fallacy. Your product's going to go Become a frankens or whatever, right? I will tell you a real story here. So a real talk right quick we implemented a chat inside of a mobile application because a customer asked for it. They wanted to be able to chat directly with the users. B to B to C. So we sold to another business and then they unloaded their customers, right? Their customers wanted to be able to chat back with the home office and then chat back to the customers or whatever. Terrible. It was a, a colossal. Colossally bad. Colossally bad. That's not what it was. It was a monumentally better. It was a monumentally poor feature for us to implement. We should have just taken one of the one billion chat clients off the shelf. Embed it. And put it into the application. We should not have built it. Because it was like the world of real time two way chat is the world of very fast queuing and processing. And not, not something that we were in the business of. In any way, shape or form, we, we certainly learned how to do it along the way, but it's expensive. Whoever made that decision on the product side, they, they were on some very heavy medication, possibly prescription, possibly not. I really don't know. They may have been mixing it with other things because it was a bad decision that drugged the whole thing down, brought the system down several times. It was just bad. The industry is laden with examples like that though. Unfortunately, but it's because they did something that the customer asked for. The customer had no idea about our architecture and then they basically, by the time they said yes, it was too late for them to back out and they had to implement it. So they got led into something because the customer didn't know they didn't know how we were planning to implement it. Yeah, it's a good example of the fallacy I talk about because you know, if you extend the argument further, right? So customer a wants something and you charge him and you build it. And now suddenly customer B wants that. How do you, how do you meter that out? Do you just give it to customer B now that it's in the product so it's free for everybody else? Right. Right? Yeah. So I think that's where diligent product managers, or product management, and even sales for that matter, they all need to get together and say, Are we going to do this? If we are, what are the reasons why we should do this? Marketing has a space in there too. How can we repackage this and make more money off of it? Absolutely. Correct. But yeah, just doing it because the customer told us like, Ooh, like you're missing a, you're missing the gold mine potentially. Well, this, I mean, this is a fun category. I don't hear, I don't hear, Hey, customer told me to do it. Like help me push back on this a little bit or not help me figure out what the best way to, to go forward with this. I didn't expect this to go this long with this conversation. I'm gonna be honest I thought it was like an open and shut kind of deal But apparently there's more personas that we could have probably thought of I thought of one or two in my head while we were talking So if you have other personas To explore we didn't talk about support or customer support or any people like that. If you can think of other, other people we didn't bring up Hey, maybe this would be worth revisiting. Yeah. Hopefully you found it useful if you're still with us this far. Hopefully it's what the customer said they wanted. Now let's know what you think about this and other topics that you'd like us to delve into. Subscribe and like down below. Cue the music. He has to hit my music. Oh, there's still no music.