Pitching Your Services To Your Customers

Welcome to Building Better Developers, the Developer podcast where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are talking today about customer definition for lack of a better term. And it's really good that we've talked about this for we're really going to get a little bit into the weeds of if you've got a service based business such as Michael's working from a QA side, I'm working usually more from a consult, a technology consulting, solving business problems integration kind of side. How do you label that to people? Who do you talk to? Who is your customer? And how do you address that customer? How do you tailor your pitch for the customer? I want to start out with one of the things that we had in the pre-show a little bit was the idea of where do you include the technology called the keywords? Where do you mention I do Java or I do React or I do responsive or I do blah, blah, blah, whatever that technology is. We all know that there is some level and this goes back to really a lot about the whole building a better developer. There's some level of difference between for example, and there's varying levels of differences between for example, React, C sharp, Java, Perl, PHP, Python. There are those families of languages and we know as technologists that sometimes those are sort of replaceable. You can sort of swap out one for the other. It's like roughly like if you know a couple, if you know jQuery, you can probably handle a couple of the other JavaScript frameworks that are out there that are roughly the same. If you know Angular, you can pick up React pretty quick. Those things that are, yeah, they're not the same, but the concepts behind them are close enough that you're probably going to be able to transition, particularly if you've been doing this for a while. Particularly on a QA side, it really does, but it doesn't matter to some extent if you're testing a web application because the keys you need to understand there is things like what should a good web application look like as far as having IDs and not having to chase down CSS selectors or XPaths or some of those things that are just flaky and very difficult from a testing point of view. I think the first thing I want to talk about a little bit is the trap and a little bit about it's just sort of us maybe tossing this back and forth because we have two things we're serving right now. As one, our customer. Whoever our target customer is, we want to speak to them in a language they understand. However, we don't want to miss out if we're doing something that is a, if it's something that's like an advertisement or something like that, we don't want to miss out on some little AI or HR system that's just looking for those keywords and ignores us if our keywords aren't in there. I would like to place it a little bit as instead of one pitch to save them all, to serve them all is you have the, it's really more like the interview in person kind of stuff where I'm talking to somebody or, and it may be via email or something like that, but I am directly communicating with a person and not some, you know, going through some doorkeeper or something like that, some HR person, which is different from if I'm doing like a general advertisement or general postings or general descriptions about my company. Does that make sense about maybe splitting those two off? Yeah. And that's interesting that you said that. So the other thing is one of the things you didn't touch on it is you talked about, you know, talking to people in person, and then we talked about doing like the marketing thing with the AI. Well, what kind of message would you put on your website, which is kind of a diff, it's kind of a combination of the two, right? You want something that is both mission critical. What is your brand? What is the problem you're solving? But also kind of touch on the services and the technologies that you can provide because not all services are compatible. Yes, the idea of like a web-based testing is one thing, but there are subtle differences between, you know, if you're a react shop, if you're doing PHP, if you're doing, you know, just straight up HTML or even Java versus C sharp. So there are some layers and complexities between those, but the same message might still be, you know, the customer has a website that is having problems and they need a way to test it. And you know, you would lead it with some type of a web-based testing solution, like a web driver, Selenium web driver, you know, Selenium grid, but you would essentially build a test framework that would test their web application and then provide them essentially a baseline or a framework for them to write their tests in a way that will test their system. And then they have the reliability and the understanding that their site is up, is working to that extent. However, if you kind of flip it to that's kind of like one general use case, a little more generic one, though, is when we're talking about like a software assessment or a QA assessment that is high level, but that can also mean different things for different companies, right? Yeah, and I think that and that's that's I think the. Well, there's two things. So one, that's very key is one, it is what is the this goes back to who's your customer. If you are targeting a QA assessment, then you're doing it at that at that higher level. And while, yes, you should have those technologies somewhere as a part of it. I don't know how many times I've had conversations at that level when you're talking to, you know, C-suite or vice president or something like that, where you can start mentioning those technologies. And I've literally had people where I like get into that and say, well, we've done this, this and this. I don't know what any of that is, nor do I care. And because they don't, that's not the problem that that you're solving. And so sometimes, yeah, it's useful to help that you have that if somebody is trying to sort of check off some boxes. But in that conversation, you're not going to want to have it. However, if you're on the flip side, on the other, the more detailed approach where you're generating essentially you're generating code, you're not talking to a CEO about a framework that's going to be generated that they're going to write code because he would have just like his eyes are going to melt and fall off his head while you're explaining that because he doesn't know, doesn't care, doesn't want to. That's not his stuff. So it's a, that is those two things are very, very different customers. And I've run into those where you start with one and then you do eventually sell to another. But that's where it's a, to me, it's a whole different pitch at that point. Now I wanted to swing back from the website. I see it as a, and I got this actually from, and hopefully we'll have somewhere in our show notes a link to it, is we, in particular, we talked about, and I wish I could think of her name off the top of my head. We talked to a lady about LinkedIn and she's a LinkedIn expert. And she talked about how you set up your profile, it starts out with a picture that doesn't look like you're a convict or something like that. And then you've got like a tagline that should draw your ideal customer in. And then as you get further down on your profile, it starts talking about like, what have you done? Where have you been? Stuff like that. And it's basically the idea, I think is the same on the web is you start with, again, it goes back to who's your primary customer. The first thing they should see when they come on that webpage is essentially like, here's, you know, do you need this problem solved? Or do you need one of these three problems solved or whatever it is? And your goal is that they're like, heck yeah, I need that problem solved right now. I need that. Because that means they're going to look further down. They're going to like, you know, work out just like a funnel. They're going to start going deeper into that and say, okay, well, he just mentioned my problem. Let's see if he can solve it. And then probably along the way, ideally, you know, your customer enough. So they're going to say, yeah, I need that problem solved. And then you know what their next question is going to be like, hey, do you support Microsoft technologies or Java technologies or do you support mobile applications or however your your funnel goes? But it really is thinking through that conversation and putting that onto the web page so that, yes, eventually that technology stack will be there somewhere. But I think it's. And really, if you look at any, especially boutique type consulting or anything like that, you'll find that stuff is like way down the list. It's like, you know, it's one of those that you're on the primary page and you go deeper into stuff before you finally get to the like, hey, here's all the crap that we can do, because most you know, you get to that point at our level, most of the places are going to be the same where when you get down to the brass tacks of what technologies have you dealt with, the vast majority of us that are good have dealt with all of them basically at some point. So we're going to be able to just have families of them. And then it's just a laundry list. But I think that's what I don't think there's anybody at all really that starts with that from your website. I think that's something that just it should show up. So somebody searching, maybe that will hit, but that's about it. Yeah, if you want to do it, if you if you're doing like a proposal or something, then you may want to have that like sort of at the bottom of that like, hey, here's all the things we do, which is I'm thinking about it. I may want to start adding that to some of mine. I guess I do. I have those in the flyers and such I have where I just have like the sort of the things that I put with posts with proposals typically include like, here's who we are, here's what we do, here's some background, here's the technologies, and you make it easy for them to get to what is the problem that they have? What is the story that you're going to sell them on? And I think that's it's building those pieces around it, but keeping that again, it goes back to like, what's the why? Why do why do they want to talk to you? And then go with that. And that's where I've struggled is getting them to that. Really, it's getting them into that conversation phase. Beforehand, I want to get him hit him with the right things. So I don't scare him off that I don't like lose them. But I'm like, I can drag them in more and say, Hey, it seems like you have this problem. They say, Yes, I do. Can you tell me more? And it's like, Oh, yeah, by the way, if you will just step into this room over here, I'll tell you more. It's one of those things you've got to like lead them without giving them too much. And I say this not being an expert by any stretch of being able to do this. Thoughts? Yeah, it's kind of always been the lead, right? It's that elevator pitch, you know, that quick conversation you have with someone to sell your company, you have, what was it like three minutes to sell your whatever service product you're trying to sell. And a lot of the documentation I've looked at that you had that I guess might have confused me a little bit was because some of the stuff, especially from, you know, developers or, you know, software developers, you know, testers, whatever, is we have this, especially if you've worked for big companies for a long time, you've worked on a lot of different projects over your career. How do you translate that from a resume to, Hey, here's the project I worked on, here was the problem we were trying to solve. Here is how we solved it without one, violating an NDA, two, giving away company secrets, three, being too technical as far as explaining like the full stat. You know, if you're applying for another job, sure, that's important because that's your customer, right? That's who your target is, is potentially another customer that has a similar product that you want to go work for them and work on that product. Flipping that around, we're selling our services or we're selling our story and the brand to a potential customer, a different customer, not that particular target. And I guess where I struggle, and I think you do too, between the assessment and say doing like a software assessment or a test assessment versus writing code or building an application, they are slightly different in who our customers are, right? We're not necessarily pitching it to the same level of customer, but we're still in the same market. That's, I think, where one of the biggest struggles I see, or one of the, I guess, the biggest traps we can get into as developers. Yeah, I agree that it's, they're similar, but they're different enough. So if I'm doing an assessment, it really is going to have a lot more to do with. When I talk about an assessment to somebody, I'm talking about in general, it's a lot more generalities. It's like, hey, you have a company, you have an accounting system or finance systems, you have fulfillment systems, you have shipping, you have HR, you have customer relationship of some sort. You may have a full blown ERP, but especially if you're a small company, you probably don't. You've got the equivalent of what an ERP should be, but it's scattered into all sorts of different technologies. Or maybe you've got a wannabe ERP and then you've got some integrations going into it. That's the level I'm going to talk to them at and not really get into the specific technologies. Now, they may mention and say, oh yeah, we've got, we use, just picks it like HubSpot. And so it's like, yeah, I've worked with HubSpot before or hey, we've integrated, we have integrations with these three payment systems. Cool. Worked with lots of payment. It is a challenge when you're in that level, when you're having that conversation to not rabbit hole down on a technology, but instead to sort of like brush it aside and focus back on your, you, the customer, your business, what is it that you need? What is it? Where are your pain points? And getting that information, because they really, at the end of the day, the technology doesn't really matter to them. And I have had now multiple customers where I've walked in and they've had an entirely different technology stack than when we walk away because they've got one that's just, it's broken or aged or whatever it is, or doesn't fit them or it's too broad. And then we'd say, Hey, let's take these 15 technologies you have that you're trying to chase down. Let's turn it into one because we can, because they, you know, things have moved on when you're on the, when you're on the building a solution or building a framework. Yeah, you need to talk about it, but even then I think it's, it serves us better to not get stuck in the technology as much. I found that I find this with other consultants that I've dealt with, if they lead with their technology or if they're very big on like, we use whatever, you know, we are a Ruby shop and we use Ruby on Rails and we knock this stuff out and all that. It's great, good for them. But to me, they're going to sell me then a Ruby on Rails solution. They're not going to think about, they're not going to talk about what I need. They're going to build whatever it is that I need built in Ruby on Rails or in PHP or in Java or whatever it is. And that's not always the best solution I would rather have. And that's sort of what I try to sell to people is like, Hey, let's, we will build you the solution. And sometimes I'll even tell them, they'll say, well, how would you build this? Like, I actually don't know right now, because we haven't gotten far enough into the requirements. It's like, it's usually I'll be like, it's either going to be, this, this or this. And it's usually going to be something like, it's either going to be like, maybe Java or Python, Django, or, you know, maybe PHP, or maybe it's React or whatever, just depending on what their targets are. But sometimes it may be something like, hey, we might build you a custom solution in Java, or you may have maybe all you need is a really good WordPress site. You know, there's things like that, that I, sometimes I'll push back on the technology questions and say, look, I, I would rather us solve your problem. We'll figure out the best technology for it. And then we can talk about it because again, usually they don't care. I mean, it's, they do, if they're a bigger company and they've already got an IT shop, yes, they're going to care because they're already going to have people that know that language, that stack or whatever. And that's cool. That's, that's a valid reason to stick with that stack. But a lot of times they don't have it. They've got situations. I've got one right now that I'm working with that they, they had this stuff that was built by all these different developers. It's in two or three different languages. And we're just trying to like shrink it back down. There's another project. We were actually almost went the other way. We had, and you know, I was working with Timothy. And so we had a stack that was built on what he knew. And I came in and I was like, oh, hey, this thing would be perfect to do in like this, you know, little crud type thing, be perfect to do in Django. And I started like, no, like we've just, that's just added language. I said, no, let's swing back around and we'll do like, you know, spring boot instead, because we can then keep the core technologies in that Java world that we had as opposed to doing it somewhere else. And yeah, that's, that's where a lot of those go. So I think while we want to, I think we're almost better served to avoid the technology question as long as we can. Yeah, that's a good point. I mean, it circles back around even within the testing world, right? When we talk requirements, we talk building software, you always talk about the story, but the story is really hyper-focused, right? You're the, the story is to this particular solution that you're trying to solve. And normally it's very small scale. So it's like you write a ticket, you put in the story, the description, and let the engineers go figure out how to implement it. In this case, we're flipping that, right? We have to understand the needs of the customer, what their problem is, and then explain how we can solve that or how we can walk them through their problem to get them to a solution to succeed, right? Ultimately, that's the bottom line that we're trying to solve here is determining that story brand that we can use to market ourselves or our companies, right? Yeah. And I think that's, and it really is, you've got a, it's, there's not going to be one story. Usually what you're going to have to do is you're going to have a story that has all these little sub stories within it. And that's, that's really where you do is that's where you draw them in. As you get their primary story, which is the, the primary pain point, the primary need, the urgent thing that has them talking to you. And then within that, as you start talking through that, you're going to say, Hey, okay, I get it. We're going to take you through this and we're going to solve this problem. However, in doing so, here's another little story of something we're going to deal with. You know, it's things like just customer, like CRMs are nice and easy because like, Hey, we need to be able to keep track of and talk to our customers. And you start talking about, Hey, that's great. We're going to have an opportunity for you guys to add customers. But within that, then you're talking about things like this story about, and we want to talk about how are your employees going to access those customers? Maybe we're the way you're set up. And sometimes you'll pitch it to them. Sometimes you'll draw this out of them, but it's things like, are your employees remote? Do you need to log in? Do you have multiple people? Do they need to work? Are you going to have multiple employees working a single account? Do you need to have account managers? Do you need to have structures? Do your customers have multiple contacts? And on and on and on. And really each of those questions in itself, which is now goes into the QA side of it really is it now there's all those little stories and those very hyper-focused detailed stories. But when you're talking up to your, when you're at the selling point where you're like, this is somebody that's signing the checks, signing your check in this case, if you're going to, if they're going to sign off and take on the project, then it's keeping it up at that high level because yes, they may want to come back and learn those detailed stories, but initially it's really going to be sold on one, it's going to be sold on the big story. And two, you're more times than not, you're good. You're going to be guessing those stories initially because you, you first need to get the details from them so that you can turn around and give them a good solution. Again, I say this just because I've gotten burned by this in times where I've gotten into calls and sales calls and I'll talk to a customer and I'll get into something and start sort of going down a, you know, sort of a rabbit trail of like, well, there's this and we can go solve it this way. And it takes away from the primary focus of, hey, you have a pain point, let's solve it. Exactly. And I've been in so many of those situations where you start talking to the customer and you, they have one problem, but then it's like, oh, well, I have this and you kind of spiral down. It's like, whoops, you're now kind of implementing a solution before you really have all the details, right? You really just need to kind of keep it at that high level, which is what I'm focusing on right now is trying to keep that QA assessment as the main lead into my company. Because really, unless you understand your QA or how the QA works within your company, you're not going to be able to really implement a good QA solution, which is why a QA assessment is necessary. The problem I run into though is, especially with software, a lot of companies don't understand what QA is. So trying to define the problem in a way that they understand it from a QA perspective, it is a little difficult. For instance, you've made a comment, where QA would come in at the end after you talk. I say the QA should be the discussion from the beginning. What is it the customers want? Are you defining the requirements correctly when you talk to your customers? And so it's kind of twofold. I need to understand my customer enough to explain my solution to their story. Whereas in their case, they're trying to sell their product to their customer or their end user. And they have to make sure that they understand that they're solving the problem for them. So it's almost the same, but slightly different where I'm trying to come at to them to pull that information out from a user perspective for how software works. Where in this case, I'm trying to talk to the customer or the end user in my case, as to how is your software, what is the quality of your software? How do you define quality? How are you finding problems? Or where is your problems within your software? What are they seeing? And what are the types of questions they're asking? From a QA perspective, there's lots of things I can solve. But what is the problem? I can solve this particular problem. And the assessment solves a lot of problems, but how do I pitch that to a customer? Does that make sense? Yeah. And that's exactly where I'm at is that in an assessment, you really are, you're looking at the overall situation. There's a lot of things that you're providing them with that. And this is what I'm working on right now is instead of essentially a 30 minute sales call that just gives an idea of an assessment and saying, okay, this is why you need it. And this is where we can help you because just the same things you're running into is there can be a level of education that's going on there. And that's really what we want to do down the road. If we're having to educate them, then it's going to be tougher to sell. Instead, what we should be doing is solving a problem for them. And that's usually where I'm going to come in. And I've been working towards this is so in a call or even in some of the material, it's more about, here's your, are you running into this? Are you running into this? Are you running into this? If you are, this is what the solutions are going to look like. It's going to be, here's your situations. Here's three different ways that the solution is going to look right. And it's sort of the same regard. It's either you're going to change something. You're either going to stay with what you've got and go over a cliff. You're going to buy something. You're going to enhance, customize your thing, or you're going to build something new. I mean, those are general. That's basically what you're going to run into. And that's what I'm trying to work on right now is instead of, hey, you could do this, you can do this, you can do this, is get it more down to a problem. So what is your problem? And it's basically, I'm thinking of essentially a script at this point. Almost it's like you could throw it at a monkey almost, although it's going to be, the outcome is obviously going to have the skills behind it. But it's really, what's your biggest problem? Why is it your biggest problem? What does that cost you in time and money? And how long has this been going on? And getting that, what is your environment? What are some of the constraints around that problem? And instead of getting into all the ways we can help them, is just focus on that and say, this problem, this is what it looks like. This is what the next steps would be to solve that problem. And I think that's going to end up being essentially like a freebie that I give them is sort of like a mini roadmap that says, you give me a problem. We're going to talk about it for 30 minutes. And the outcome is you're going to get a series of recommendations, basically a roadmap of how do you progress from here to address that problem? And whether you come back to me and we do stuff or you go to somebody else, doesn't matter. But now you've got those steps. And so you've gotten something. And ideally, they'll like how it goes. They get to see how you work. They get to see how you think. They get to see the, they get to look at the kinds of recommendations you have. And that's the kind of stuff that's going to draw them in, hopefully, that's going to draw them in and sell, you know, sell business. But it's not, and I've had, I've talked to a couple of people that say, you don't want to get into, you don't want to be educating people in the, in that additional sales call. You want to like bring them along and show them instead of lecture them essentially and say, Hey, these are the things that you should be doing. And this is why instead you say, what are your problems? Let's fix them. And then you can show them that, Oh, by the way, because you weren't doing this, this is why this was a problem and lead them that way instead, particularly I think from a QA point of view is, I think it's look at what are you picking probably in your case one or maybe, you know, three top outcomes, top problems that occur when QA isn't there or is bad. And then ask for people, look for people that have that problem and then go talk to them about this is okay. So this is your problem. Let's talk about your situation and then get enough information so that you can talk very specifically about the problem and about the solution that you recommend for it. Does that make sense? Yeah, it does. In fact, I've been trying to find some companies around here that develop software or have some type of in-house software solution to just open up the conversation, like just kind of maybe do not necessarily cold call, but just market research and say, Hey, what are you guys doing? You know, what is your level of QA? Do you even have QA? You know, how is your application working? How do you know it's performing well? Things of those nature. I've even started looking at online groups and that, but that can be a little tricky if you haven't quite nailed down your target, right? Because you could go down the wrong rabbit hole of the wrong group and then you're solving a problem for essentially the wrong customer. That's kind of where I'm struggling a lot because when I initially did the website, I wrote a challenging page, right? I defined a bunch of different problems that companies have and ways to solve it. But then I added an additional page for services, which may be an injustice to me and that maybe I should just hide that and just stick with the challenges as the stories, right? And maybe even remove that page and just move that to the front page and say, here's with one or two or three, like you said, and focus on that. I like that approach. It's just getting that conversation going with some of these people can be hard because, you know, cold calls aren't the easiest thing in the world, but then also to be able to talk to them in a way that can guide them first to understand the problem and then guide them through the discussion to understand, okay, here's what's going on. Here's what you need for a solution or here is how what we offer can help improve your situation. Yeah. And now we're going to, we're hitting it on time a little bit here. So we'll wrap this one up. But I think the parting thought on that is to, with the questions, the challenges that you're seeing that you're going to introduce people to when they get to your website or your LinkedIn page or your wherever it is, wherever you're advertising yourself, essentially wherever your services are at. I think what you want to do more is, yeah, you want to, you want to nail the problem. You want them to be like, wow, that's exactly the question I'm asking myself, or that's exactly the problem I'm running into. But instead of giving them a solution is your solution should point them to talking to you so that you can, at the very least. And again, I've talked about before, I am overly nice in how I've shared out information, stuff like that over the years and what I've provided the customers. And often I've been told I don't, I don't charge enough and all that kind of stuff. But still even there, I figure if I'm talking to them, then I at least have a conversation going, I at least have the ability to try to get, see if we're going to work together well as a vendor and customer and get that personality side of it to see if that's going to work. And so if I give them some of a solution or something like that, then it's like, okay, hey, at least you've invested your time to talk to me. So I'm going to pay you back by giving you some sort of a solution instead of just like continuing to drag you on. And I think that's it is where you don't, you don't want to, you don't want to answer it too easy. And maybe it is unless it's super easy. And that's where you look at like, where is it, where would I have a potential customer that they have the problem, but their solution is so easy that it's just not worth, it's not worth my time. And like think about it in code, it could be somebody comes to you and they're, they want to build some, you know, their ideas. I want to build a website and a database. And instead what they really just need is, you know, maybe like WordPress and they can do it themselves, those kinds of things. So maybe you have like a, some sort of like a filtering kind of thing or something like, oh, by the way, it may be this as you ask questions, if you're this, then you can just go right here. Here's a link, knock yourself out, shoot me an email if you have questions, because then it's basically like, hey, maybe I'll find out about them. But really, I don't want to spend much time on it, because I'm never going to be, I wouldn't, you know, take me a half hour, an hour, and it's not worth the transactions, the billable times and all that. And the non, the overhead for that. So I think you want to keep, keep that in mind as you're putting your questions in your, what you're offering to sell yourself out on your, on your site or your page, wherever it happens to be. Final thoughts from you? Yeah, those are good points, Rob. Yeah, the biggest thing, especially for anyone watching or listening to this is what we're discussing here is what we go through all the time. I mean, a lot of this is not just us, you know, you're probably watching this because you're running through these same struggles. The trick is to ask these types of questions, you know, reach out to us if you have these kinds of problems, and we can try to help you. It takes a discussion, not a silo approach to solve these problems. You're going to need to talk to people to figure out what the customer wants, what your ideal customer is. Because like Rob said, you don't necessarily want that quick and easy customer, but what you also don't want is a customer that your solution isn't even quite the right solution. And you end up with a customer with all these problems or all these headaches because they're not getting what they feel the worth is. They're not getting their money's worth for it. So be very careful with that, but also, you know, talk to people. You have to have these discussions. You can't just sit there and just say, hey, I'm going to solve X without understanding who X is for and what the problem really is. That's a good point. It goes back to know your customer, have that avatar, know what your goal is and what your focus is because otherwise you'll end up just taking on whatever you can. And a lot of times, those do not, those don't end well. I mean, maybe you get some money out of them or you break even or whatever, but a lot of times the stress and the other things, even if you have a very profitable customer can be more than you want to. So as always, as we wrap this one up, if you have any questions, shoot us an email at info at developineur.com. Check out the site, developineur.com. Check out our YouTube channel that is YouTube slash developineur. You can see us on Twitter slash X, which is also at developineur. And just let us know or drop us a line, wherever you want to do any questions, comments, suggestions, things like that, because we're here for you, as well as obviously working through our own little personal problems and business problems as we have these conversations. As always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developineur Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.