Managing clients as a web or mobile app freelancer: Best practices | Evan Kimbrell | Skillshare

Managing clients as a web or mobile app freelancer: Best practices

Evan Kimbrell, Director at Sprintkick

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
11 Lessons (1h 2m)
    • 1. Welcome to the class!

      1:39
    • 2. First thing to do

      1:05
    • 3. Keeping the right amount of distance with clients

      8:32
    • 4. Confidence is key

      8:29
    • 5. Speed is important with clients

      6:22
    • 6. Just enough jargon

      7:53
    • 7. Sniffing out their budget

      12:26
    • 8. Don't talk about problems, say what is happening

      2:14
    • 9. Is the client always right?

      7:24
    • 10. Do you deliver what's good or what the client likes?

      5:05
    • 11. Keep the learning going

      1:20

About This Class

We all know about the many perks of working as a freelancer - sleeping in, choosing who you work for, being your own boss...what a dream. However, managing clients as a freelancer can be a very difficult process. There are so many "what if" scenarios and things that happen on a case-by-case basis that, unless you're highly experienced, are difficult to prepare for.

Think of this course as a step-by-step in etiquette for client management. We'll run through the core principles of client management, go over the things you should and shouldn't do, and learn general best practices - especially when it comes to communication. I'll tell you firsthand what works and what doesn't in common client management scenarios. No more tip-toeing around or wasting time.

After this course, you should feel confident in your ability to communicate effectively with your clients. If you're having trouble keeping and retaining clients or just want to look at an established client management process, this course is for you.

What you'll learn

  • Use advanced best practices to maintain your businesses growth
  • Keep client retention rates high
  • Manage clients effectively and use your time efficiently
  • Sniff out a clients budget before they tell you
  • Know what and how to manage expectations and deliverables
  • Make long term decisions about which clients to retain and which to lose

What you'll do:

We're going to swap client management horror stories. Who doesn't love this stuff?

Transcripts

1. Welcome to the class!: Hey, guys. I'm Evan Kimbrell, and I'm the director at Sprint Kick, which is a web and mobile development studio based out of San Francisco, California As a freelancer, there are a lot of things that are great. You get to pick when you work, you get to pick who you work for, and you could depict what you get to work on. Now. One of the things that is not glorious as a freelancer is managing clients. This is something that all freelancers struggle with at some point in their business. So this class, we're gonna talk about managing your clients as a freelancer, We're gonna talk about things you should do things you should absolutely not do in this class. We're gonna tackle some core tenants and best practices of managing your clients, these air practices and tenants that apply regardless of what type of freelancer you are knowing what to say to a client, how to say it when you can say it can be difficult. But through this class, hopefully we can cover some of things we know work and some of the things that absolutely too hot work. We're gonna talk about things like your response rate, the speed at which you respond. We're gonna talk about using jargon. We're gonna talk about what types of language you should use with clients. We're gonna talk about how you could keep a comfortable and still effective distance with your client. So if you're a freelancer and you're having trouble keeping and retaining your clients or you're just interested to see if you could improve your already established process, take this class. All right. I hope you're excited to do this. I'm excited to teach this class I'll see inside. 2. First thing to do: Hey, guys, welcome back to the class. So I have an assignment for you really quickly. I want this to be the first thing you dio eso at the bottom of the skill share page. It says discussions, the clip discussions, and then you can click new post. I want you right now to go and do that and introduce yourself. You don't have to tell me a lot of information. You can just say your name or your from. But what I'd like to actually hear from you is one. What do you struggling with? And to what are you looking to get out of the class? I think this is something that helped immensely with the class. I really like to make my classes as engaging as possible. I respond to everyone, and I want to make sure that as I'm teaching, I'm meeting your goals and I know exactly what I'm trying to fix. Okay, so this is the first thing. Just go down to the bottom of the page. Do that now. Don't skip it. You can skip it if you want, but I think you'll miss out. All right. Seeing the next lecture 3. Keeping the right amount of distance with clients: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about keeping your clients happy, but also keeping yourself happy at the same time. And we do that by keeping the right amount of distance between you and your client. Now, this is just advice. Coming from me because I've been doing this for a longer period of time is something that you'd hear from people who have been in the development business for multiple years. It's something that the very beginning it's hard to conceptualize. But over time, I wish I had known this a lot sooner. Now I know that a lot of you out there are probably thinking that your customer service, your responsiveness, your personal touch that's going to be a big selling point and a big point of retention for your clients. Now, I don't want to discourage you from using that as a technique to keep your clients happy. It is absolutely a good thing. It's always good to be responsive. They're helpful on, and it's always good to lean on your personal effect to make your project successful. So that's all good and great, but you need to be realistic about what that's going to entail. What is he constantly happening is we have people who start their business and with their clients, they promise the moon in terms of their involvement. They say that they're gonna be there every week for stand up calls. They say that they're going Teoh, you know, send them weekly updates. They're goingto be there for every single conference call, etcetera, etcetera, By the way, stand up call. What that basically means is that it's a very quick update called called Stand Up, because they're very short and you typically would do them like you're standing up because they're so short Now. The problem with that is that you're not planning for what's gonna happen in the future right now, maybe of three clients, and it's realistic that you're going to deliver that promise to them. With three clients, you could be there for every single call you could make Friday. Stand up calls a regular thing, but what happens if your mark your fundamentals are good? What I'm saying? Marketing efforts, efforts take off. What happens if you grow too fast? We see this time and time again, people promise the moon they take on extra clients because they're doing well. And then all of a sudden, they either have to overburden themselves or they have to essentially break the promise that they gave to the client. And they have to be there much less so. The question is, can you promise this to every single client and not based off of your product client load right now, based off of what your client load could be during the duration of the project? Now, just a word of advice. It is always better to under promise your involvement and then surprise them if you under promise and it ends up being that you don't take on as many clients as you thought you were going. Teoh. You have extra time and then you'll really surprise them. But it does happen that you get hit with an avalanche of work, and that's typically how work cycles work in development businesses. Um, then you can actually keep your promise. You'll do exactly what you said. You dio so practice what we call keeping the right distance. Now it's kind of a Goldilocks situation where you don't want a ton of distance and you don't want a nen enormous amount of intimacy you need to gauge with each client what they expect and what they're comfortable with. Some clients will expect you to be there every single day. They'll expect that when the text message you will respond within a certain time. And some clients are the exact opposite. We've had clients that we honestly thought they'd forgot that we're building a project for them. Those ones are pretty much often space. They say. Here it is. Come back to me. What? It's perfect now. Obviously, there's pros and cons to both of those. You just need to be aware where your client falls on that spectrum of how much they need, and it's very easy to tease this out when you're talking to them. It's very easy to quickly understand whether or not they get agitated. When you don't respond within a certain time. It's easy to understand if they have a certain framework of check ins that they won't enforce. So now there's two ways that you can, um, make sure that you're maintaining the right about a distance. One is again. Be aware of where on that spectrum that your client falls Are they really needy, or are they not so needy? It all try to figure that out before the project starts, and that will make it a lot easier for you. The second thing is, set the tone yourself. What other things that a lot of people who are new to this business and new project management always kind of failed to Dio. As I feel recognized as a project manager, you can say when the updates are going to be, you can set the tone for how much information they're going to get and how often you update them. Now, in 95% of the cases, a client is going to default to your judgement because you are there on the ground. You know how often you're gonna have new information to present to them, and you're gonna know how often you need feedback In order for this project to be successful, clients do usually understand that being excessive with communication could be a negative thing. They know roughly that that could be a detriment to their project. But in general, they're not entirely worried about that. They're more concerned with feeling as if they're in the loop so try to make them feel like they're in the loop. That's a very important concept here. Now, feeling in the loop again relates our first point, the first point being where on the spectrum do they fall? If there are needy client, being in the loop means that they're really in the loop. And if they're a distant kind of space cadet client, that probably means that every month they hear something vaguely from you. So try to figure out exactly what in the loop means and then make a judgment call about that too. Then enforce your own schedule of check ins and distance again. Like I saying before, they're always gonna default to you because you're intimate with the project. So if you say to them, you know I'm going to update you on this date. This is one of we're gonna deploy new code. Um, and this is when we're actually gonna talk on the phone. They'll follow that schedule. Now, if you have a client who just doesn't need a lot of information, then you might want to be more relaxed with that schedule. If you need someone is a little bit more needy, then you could make it a little bit more intensive, but because you're leading the decision here, you can push it towards whatever is a reasonable amount for your workload and your project load. So it's very important when you have a new client that you tell them up front. This is typically how we work and you can even customize it depending on the project itself as well. And say for your project, we're gonna check in this often. And this is what I'm gonna give you this information. Tell them that upfront before you even signed the deal so that they know exactly what to expect. If they protest, then honestly, be considerate. Think about it. But if they're asking for something that's entirely too excessive, just try to explain to them the two best ways of explaining to them that this is too excessive is one. You explain to them how much time it takes to give these updates and how it could be a detriment to the project. No client ever wants to hear that. And to be honest with them, tell them that if I update you every single day, I'm gonna have nothing to say. we used to do the Friday night stand up coal. So what that basically meant was like, every Friday night we do a stand up call their client to say where we're at and ended up happening was, you know, this is the phone call, you know? Hello, client. We have nothing to update you on because there's just nothing to say. Hey, the developer who was working on that feature last week while he's still working on that feature what do you want me to say? Unless that person you're talking to is really technical? Nothing I'm gonna tell them is gonna make any sense to them. I said, Oh, he's, you know, on this line of code or these running into this problem, it means nothing to them. So try to be smart about how you can gauge how much information they need. Use that to judge roughly how much distance they need, focus on enforcing the framework yourself. Be considerate if they have their own opinions, but also be firm and explain to them why you came up with this communication schedule. Seriously. If you don't manage your communication schedule up front, you're going to go crazy. and you're gonna spread yourself way too thin across projects. Trust me, clients will believe you. And you say this is the schedule we need, and we don't need any mawr inter communication. Okay, guys, CNAC structure. 4. Confidence is key: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about one of the biggest factors and whether or not you have positive client relationships and whether or not you can run into a problem in the middle of your project. Now, one of the biggest things that I've experienced and I figured out through the last four years is that the way to you talk to your client is really important. Now that's kind of obvious, right? Like you don't want to be rude and you don't want to be, you know, flirtatious or anything like that. But one of the things I found out that is probably the most important is confidence. Now what do I mean by that? Well, people who are your clients are typically one of two things usually their small business owners or entrepreneurs, and on the other side there probably account managers or some type of a decision maker at a larger company. In all of those cases, those people are taking on a lot of risk by hiring you to make their project. An entrepreneur is probably risking a lot of their own money. So the same story goes for a small business owner now even an account manager at a company that could be their job on the line. And they're kind of gambling with someone else's chips. So the point is that they are kind of anxious about this relationship. They have a lot on the line, and for you you don't typically have a ton on the line. I mean, in the worst case scenario, you might lose some wages. So the most important thing that they want is to feel as if they're in the right hands Now . The best way of doing that is by being consistently confident. Whenever you originally speak to them, be confident in the estimate you're giving them. Obviously, I'm not saying Don't hedge your bets and say This could change But you just say that this is what our estimation will be. This is where we expect variation, and that is that Don't ever try to insert unnecessary questions or question marks. What you generally want to try to avoid is appearing wishy washing in any way. They want to know that you are the authority figure. You know what you're doing, and even if it's this is completely unrealistic. They want you to always feel like you know everything. In a weird way. It's almost kind of like a parent child relationship. They just gave you a lot of money, and you could potentially ruin their week. So it's really up to you to constantly keep them feeling assured. Now what happens when a problem happens and this happens all the time? The problem could be a miscommunication. Ah, problem could be a scheduling issue, and most likely, what a problem could be is a bug or something in your development. Timeline gets delayed now, a normal way of responding to that outside of the development business would be to explain what's happening, apologize and probably just tell them every single thing that's wrong and leave that open ended. Now that's a reasonable way of explaining what's happening. If you're just talking to someone and not in a professional relationship, the problem with that is the open endedness at the very end. So how would you be confident in a situation like that? If you have a problem, you let them know it's a problem, and then let them know how big you think of a problem it is, and then tell them this is how long it will take before it's fixed. Now, if you don't necessarily know how long it's going to take to get fixed, give them a definitive answer as to when you will know it's gonna get fixed, right? So it's like a timeline for a timeline. The point is that there's a lot of ambiguity when it comes to project something that could be wrong when it's gonna get fixed. But you can always focus your communication and reword your communication in a way that is always definitive. Even if you don't know if there's a scenario where you don't know something, use always something that you do know. So focus on the thing that you do know never, ever say in a project that here's a problem and it cannot be fixed. There's too many times in my experience where we've run into problems that even after three days of looking at it, we have no idea if this could be fixed. What would be poison is if we told them we don't know if it's going to be fixed. That is the worst thing your client can possibly here remember they trusted you. They gave you a lot of money, and you could potentially take all of that and nullify it. So never tell them that you don't know if it can be fixed. Always say it can be and give them a timeline on when it can be fixed. If you have no idea how long it's going to take, you just tell them that it's a big timeline. Before you could even get back to them with the time plan on getting it fixed. Now. One thing that can help you if you do run into a really, really big snag, Um, and you're kind of at a loss for how you can reassure them. One thing you can do is combat this with specificity. So what I mean by that is you have an issue. Tell them exactly to the T what the issue is. Show them why it's hard and eventually the empathize with you and will say yes. This is actually quite difficult. Explain to them why it's a difficult technical problem explained to them how experience the person is looking at it, and they've never seen this before. Explain to them that it's a problem with the platform you used. Or it's a problem with this certain technology, something that's almost so big that it can't possibly be your fault. But most of all, be confident when you say that it's a hard issue. If they believe you, you can keep trust with them and then they're gonna believe you when you say it can be fixed. That's the most important thing Always started. Like to think of it like you are the North Star to your client. You always have to know what you're doing and where you're going. There always has to be a plan on the table. Even if you have no idea what you're going to dio. You'll find out very quickly that by using language correctly by always appearing confident they'll trust you, and you can essentially buy yourself enough time before you have enough information to correctly answer their questions. In development, it's always just a matter of time. No problem can't be solved in some way. And if it is the case, then you should have seen that way before. Now how does apply to other interactions of your client? I would have a client asked you a question and you just have no idea what the answer is instead of saying I just don't know, say, Hey, I don't actually know. But here's a timeline for how long it's gonna take for me to figure it out. It's really easy. You could just say I don't know this, but I know that I can figure it out. That's always better if they know it's something that you're not aware of. But the difficulty of that question is not so ridiculous. You could never answer it. They'll usually just kind of let you have that one. They always want to know that you could answer any question and at the minimum, give them a timeline or a rough idea of when you configure it out and give it to them. Now, this is something that helps with experience. You'll figure out that some questions are a little bit harder than others. Usually I just give a pretty wide or vague timeline. I can usually just say, Give me a couple days or let me look into it when we're at this section, Um, really has a lot of ways you can kind of work it around Okay, So the big takeaways from this lecture is confidence is key. You kinda have to feel like you're holding their hand throughout the process. You need to understand that clients typically are very poorly equipped, handle problems on their very poorly equipped to tell between who knows the right path and who's completely wrong. What they can tell is they can tell your tone, and they can tell your confidence an issue with no solution that spells sinking ship to them. But an issue with someone who's confident that they can figure it out, even if that doesn't mean fix the problem, just figure out what it is that is always an infinitely better solution. Try to be there, Northstar. Try to be confident and try to analyze your language a little bit. Don't ever leave open ended answers that make it sound like I just don't know what this is or this is an issue. Always give some kind of a conclusion or some kind of summation. This is a problem, and it can be fixed this quickly or tomorrow will know how to fix it or something along those lines. Okay, guys, like always, any questions posting the group discussion. Otherwise, you can always send me a message. We'll see the next lecture 5. Speed is important with clients: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about speed and how important that is to your client relationship. Now, when I talk about speed, I'm not actually talking about timeline. That's kind of obvious, right? You don't want to take years to get something done. When I talk about speed, I'm actually talking about responsiveness. It's feed, meaning from the point at which they contact you. How long does it take you to respond? And what are you in the habit of doing with regards to you? Response time? Now, if you didn't obviously know this before, responsiveness is very important not only to closing deals, but keeping your client happy. A client that receives prompt responses is much less likely to be anxious or upset about things along the road. What the bigger mistakes you see a lot of times with development businesses is that people are really on the ball when they're trying to close a client, and as soon as it close a client, they kind of relax. They kind of allow large windows of time to pass before they respond. They often think that's a strategy for setting the tone, which is something that we talked about in a previous lecture. But that's not actually the case. What, you're not actually setting the tone, you're changing the tone in general, if you're responsive, that helps you in many, many different ways. A lot of times you have clients that blow up, Um, and they're not blowing up for any specific reason. It's a cumulative effect because they feel as if their needs are not being met. Now, at the risk of sounding redundant, I want to re emphasize a point I made previously in the course. Clients are anxious creatures. There are species that is constantly nervous about everything. The reason why this is is because they generally fall under three categories. Small business owners, entrepreneurs, which are often the same thing, or account managers or people who are in charge of procurement at large companies. In all three of those scenarios, they do not have money that they can lose. One might lose a job, another might lose a business, and another might lose the business and their reputation. So regardless of how healthy the project is, they always want to feel as if you are constantly there the idea and the feeling that if they have a problem and it's going to take a long time to hear anything back from you, that's a bad thing. That gives him a lot of time to worry and a lot of time to make a lot of false assumptions . Now, invariably, if you have a slow response time, that is almost always going to be read from the client side as something terrible is happening. The you know the ship is sinking. There's obviously something wrong that the other person is hiding from me. Even in the best scenario, they're gonna assume that may be the project's going fine. They're just gonna assume that you don't know the answer to what they told you they might assume. That you are not as integrated in their project or is knowledgeable is their project. As you said, you are. Either way, that erodes trust. It erodes your ability to project yourself as authority, and it creates a very problematic relationship, so get used to responding as quickly as possible. The best way of getting around this is, you know, if someone asked you in a dense question that requires a response and requires research and requires collaboration with your other contractors or other employees. Don't feel as if you have to answer that question Now. You have to stop dinner, um, and go out there and research the question and send them a five point answer. What you need to simply do is let them know you are there and let them know that you are aware that they need that information. That is it. You can literally just respond. Give them your first impression of the answer and say, But I'm going to respond with a much more comprehensive in a much more correct answer and then give them a timeline. That's the easiest way of doing it. Just let them know. Hey, I'm here. I've heard you. I'm going to respond and then you can go on being as unresponsive as you want. It doesn't actually change really anything. Get used to tying yourself to your phone. If that's not something that you're used to, it is something that's gonna help you immensely. When it comes to managing clients, check your phone. Often. You don't necessarily have to send text messages to yourself or have pop up notifications, but set your mail application so that it automatically checks your mail often for you, maybe even set keywords in case clients email you. You do get a notification. If you're going away for a certain period of time, let them know ahead of time. And if you don't do that, or you don't feels if it's necessary at the absolute minimum set an auto responder set the little message that gets sent and says, You're out of the office. You're unavailable. Just so they know this is not me being irresponsible. This is not me hiding a horrible fire we've made in the kitchen. This is me being gone, and I can't help it. Now It's OK. Toe lag. During certain times that you previously established, you're unavailable. Typically for me, I don't obviously respond on Saturdays and Sundays as quickly as I would on weekdays, and I've actually gotten in the habit of setting the tone that way in that if you send me a message on Friday night, you're not gonna hear anything until Monday morning. That is perfectly acceptable. That's reasonable, but the point here is you have to be consistent. You can't respond on Saturdays for a year and the year two, you decide you're not gonna set. You're not gonna apply on Saturdays. People get used to their their basic expectations. People get used to the way you treat them. They're gonna expect that in the future. So that's basically it. It's a very powerful communication technique. It's a very powerful messaging technique. If they message you, just let them know you acknowledge it, give them some impression of what's going on. Tell them you'll get back to them, then go along on. Be as flaky as you want to be. Take a long as you planned on taking any way. Just let them know you are there and give them a timeline again. It all kind of relates to being confident and telling them. You know, I'm aware this is happening and this is my timeline for getting you an answer. That's all they need to settle their anxiety. Any questions, posting the group discussion. Otherwise see in the next lecture 6. Just enough jargon: Hey, guys, welcome back to the course. So in this lecture we're gonna talk about how do you control how much of jargon you use in your everyday communications with clients? And what's the optimal level of confusing language? Now, if you don't know what I mean by jargon, jargon just means technical words. And if you're in development, you're using technical words all the time, and clients probably won't understand 90% of it Now. The standard advice from people who run development businesses is that you minimise your jargon as much as possible, right, because you're more interested in communicating effectively to your client. Personally, I think that that's incredibly simplistic view of it. There's a lot more that goes into this, Um, and I think a more nuanced approach is necessary. So let's be obvious. You don't want to have too much jargon. If you have too much jargon, it just can. It confuses your client. It limits how well you can actually communicate something to them. And most importantly, it makes you look like a poor communicator because surely someone who works with clients on a day to day basis knows that they shouldn't have to speak in really jargon ized language. The way you speak to a developer or even the way you speak to a designer is should be entirely different than the way you speak. Toe a client only in situations where your client is as technical as they are, then you have the option to speak to them with lots of jargon. But even in those cases, I always find that it's not so actually, the most effective way now. Too little jargon, which is what a lot of people out there just don't realize also has negative effects. Too little jargon makes it sound like you're not an expert at what you're talking about. It also makes it sound like the project is really simple and kind of the immediate reaction early subconsciously from your client is this is really simple. Why am I paying so much? I think there's also likelihood that if you speak to simply, they also feel as if your position or your role in this communication chane is unnecessary . So there's obviously a happy middle in between. Using tons and tons of code language is really specific details that are completely unnecessary, and the other end where you basically turn everything into overly simplified language that doesn't use anything remotely technical and just sounds incredibly vague. Now what I've found to be effective and what I propose you do is that you use a kind of medium amount of jargon. Use words and kind of code names of things that are more common while leaving out. Things that are less common when describing an action typically focus on using a simpler verb when you describe what's happening because they just don't understand the actual action. But then, when explaining objects or technologies or platforms used the specific language now, the reason why I suggest inserting some a medium amount of jargon is because it sets the tone and it makes you sound like you are a domain expert. It makes it sound as if you know something that they don't know, and it reassures them. This is complicated, and this is why I hired you. Okay, let's set up a scenario so you can get kind of the gist of what I'm talking about. Let's say you built a site or a nap and you built it, deployed it and users are going to that page and every time they try to save information, they're getting a big error screen. So something is clearly wrong and your client comes running to you to say that the sky is falling and something something's wrong. So how do you explain it to them? Here's an example. Often explanation that's too simplified. The sites ability to save isn't working, and the information isn't going anywhere. That's creating some issues on your site. Okay, now, if you read that in text, it doesn't actually really say anything. I mean, in most clients where they're not, they're aware of it. They know what's happening. If you try to save something in an error message comes up, surely they know that the biggest point. Those you said it like that. You kind of sound like an idiot. You generally wanted to avoid sounding like your babying. The client, The babying that you do to your client should be subtle, and it should be on things that they don't even notice. You'd actually be surprised. Clients like to feel like they understand the jargon you use. They'd like to feel like they're in a technical conversation. It makes them feel like they're kind of on the ground level, so I'd always proposed using a little bit more. So this is an example again of a way to simplify. So here's an example of an overly complex and overly jargon defied. The answer. Your APP instances experiencing server look and it can't authenticate. With its connection, your users are getting thrown a Java script exception that might indicate that the build is incorrectly set up on Apache. Okay, now let that sink in. What did I just say? I honestly, I barely know what that means when you given answer towards something's not working. They kind of want to understand it in much simpler terms in that that actual, true to the definition to the T answer is very rarely helpful. Make sure that you're not introducing concepts they've never heard of and, more importantly, never realistically could have heard. Now explain the name of a database that's common. They can understand that that's helpful but explaining server lock and then going and saying that it needs to authenticate its connection. That's not necessary. You don't need to say the phenomenon that's happening, and you don't even need to say that it's off problem with the authentication and not just the connection. That's almost too much detail, and it's completely missed. When you explain to them, use your users getting thrown. A JavaScript exception. Exceptions are a programming term. What you could just say is, error doesn't mean it's not technically correct. But that's something they can understand. And that's basically the same thing again. And the last thing. You don't really need to call it a build. That's not something that someone immediately knows. You could just refer to the site. You also don't need to see that it's incorrectly set up somewhere. Just say that it's It's not working on this. It's not working on your server. You don't need to explain the technology that runs it on the server. Okay, so here is the ideal kind of response, with concerns to how confusing and how jargon ified it is. Your sequel database is experiencing a common issue where if too much traffic hits it at the same time, it will actually close its connection to the database. This is common to the specific platform that we built your website on the error that you're seeing. It's just the systems way of letting us know that none of that information is actually getting saved. See, that's right in the middle. There's a couple things you might have glossed over because you didn't know what it waas. But for the most part, I gave you a decent amount of detail but not so much detail that you actually get confused . And at the same time, I didn't just kind of baby speak it or dumb it down so much that what I said doesn't actually have any meaning. Okay, so try to find a happy medium with jargon. Personally, I like using a little bit of jargon because it makes me sound like a domain expert, and it kind of sets the tone for the relationship. It kind of divides between the person who is purchasing the software and the person who actually knows how it works and what it takes to deliver it. In my experience, when you do that, you'll notice that you get a little bit more respect. They're more likely to trust you, the more likely to believe you when you say an issues heart. But if you dumb it down too much or you make it too complicated they might just not understand what the issue is. Think it's too simple or just think that you're a very poor communicator? 7. Sniffing out their budget: Hey, guys, welcome back to the court. So in this lecture, we're gonna talk about sniffing out your clients budget. What I mean by that? Well, when you start the project process very beginning first point of contact with a potential new client. There's a lot of back and forth that happens before you guys agree on what you're building , how much it costs and what your timelines going to be. That process I just described actually can take up a considerable amount of time. Larger projects have a lot of back and forth, a lot of estimation, a lot of re estimation and a lot of negotiation. Now it's in your best interest to minimize how many times you go through this process for clients that don't end up working with you or becoming paying clients. And one of the biggest reasons why clients drop out is because the budget, either they don't have the money to make it or they're just not confident they can get the money or they have enough money to build the project. They want to build. A lot of times they have money, but it will require them scaling down their application now It's important for you to have some general idea of your clients budget while you're going through this process for a couple of reasons. One. It's helpful for you because you can shift. Resource is if you believe you're with a client that's unrealistic. You can also change your strategy. Start pushing them towards things that are more practical, more cost effective, start pushing them towards Maura of a minimum viable product model and essentially, just tryto pitch them on the whole idea. They should start off smaller. But also what ends up happening is a lot of times, if you work with clients, have no idea what their budget is. They'll accept a project and they simply do not have the funds or they're not in a good enough cash position to make the project correctly. A lot of times they build something out, and they quite literally spent every dollar they have building it, and then when it needs editing, it needs fixes. When you find out that user feedback says this section doesn't work, this section needs to be fixed. They have nothing to work with. And so you're working with a dead project. Now I need to stress this, that Ah, lot of contractors will ask for your budget up front. It's surprising how many people do that, Um, and it's something that you should never do it. It's such bad manners. It's so really unprofessional. And I'm kind of amazed by the people that actually stick by asking what the clients project is up front. I teach other courses on you to meet where I actually take the other side of the fence, and I teach people how to be a master at purchasing software and mastering kind of the freelancer business relationship. And I always say that people that ask for their budget upfront are more likely to be unrealistic about what it's going to take to get your project done. It's also just bad taste. If I'm someone who's looking for a long term contractor or someone to work on a very important project, I'm not gonna be interested in working with someone who's first. Question is, how much money do you have to spend? I'm interested in someone who is interested in my project. I would like to work with someone who has a personal connection to it. You should follow that as well. You should always make your client feels if you are interested in what they're doing, make it look like you're thinking about it in other ways and that money is not the most important issue issue to you. One of things always drives me crazy with other freelance businesses is they ask for your budget and if you tell them your budget, you magically you'll find out that their estimates always seem to fit your budget. That's typically just shows that ah, lot of people use that as a technique to be dishonest. They use it to figure out how much money they can squeeze out of you and not to objectively answer the question of how much does this cost? What is it going to take? So be realistic. Get your priorities right. And don't ask for your budget upfront. But there are some certain things that can help you, um, understand roughly whether or not your client is even in the right range of your project and to give you some idea of whether or not they have a healthy budget or a budget that simply cannot support the project they're proposing. So I'm gonna go over some of the most common things you should look for and some simple ways that you can actually press the issue. Find out what their budget is without actually asking explicitly in being rude. Now, this is not an exhaustive list, but these are the ones that I see coming up all the time. If you guys have other ones post in the group discussion could definitely add them in here . That would actually be quite helpful. These the ones I've seen. Okay, so number one, this is something that I see constantly. Do you have a client that is constantly assuring you that a section that they're proposing to build is really simple or really cheap? Despite how educated your client thinks they are, they don't ever know how big a project is. They very rarely have the slightest inclination how big a section is. They're wrong more often than their right. And I also kind of believe that most clients at least have consciously understand that they don't know what they're talking about. What's happening, though, when they're doing this, is there signaling to you budget is probably a concern. I'm telling you, this is simple. In the hopes that you believe me, that it's simple and you return to me a price that is quite reasonable now, someone who has a budget that's easily going to encompass this project. They're not gonna be as concerned with telling you how simple projects pieces are. Number two look for how much specificity your client gives you. Ah, client that gives you 16 2025 pages of documentation wire frames, specifications. That person is probably more realistic and probably mawr aware of how big their project is . People have gone and actually done. Each individual section probably has a decent idea of whether this is a big project, a medium project or a small project and consequently there probably more realistic about what the price is going to be if they're coming to you. And they have all of this sketched out, All this planned out. Not only I think more seriously about the project that probably have the budget to pursue this people who go through and map out the entire thing. I don't usually get to the point where they're asking for your services unless they are pretty confident they can pay for it. Now, people who are completely clueless who just email you saying I want to build Instagram. Those people have absolutely probably no idea how much it's going to cost because they have no idea what the cost ranges. It's less likely that they are realistic about price or have the money to pay for it. Number three. This is something I see quite often. It's the i vs we when, typically when someone says I, you can assume it's a person, But when you hear people say we my partner and I that basically means there's multiple people making this purchasing decision now. You might not read into that too much, but in my experience, typically when they have partners, that means they're pooling their money together. Typically, when they say we it's multiple people. They brought someone on the more serious about this, and there's multiple people to draw from to bring in money. A lot of times you're talking to the entrepreneur. The we refers to the entrepreneur and their limited partner, the partner who provides the cash. Now that's not a rule across the board. Plenty of partnerships don't have the money to work with you, and plenty of single individuals dio. But just statistically, more people are probably going to have access to mawr disposable income and more funds. So typically groups of people are more likely to be able to pay for it. Number four consider how much you know about the client. Ah, lot of times you will go through hours and hours and hours of estimating going back and forth discussing and it occurs to you you have no idea what this client does for money. Are they a past entrepreneur? Do they work for a giant company of that college student? You have no idea who they are. Typically, if you're working with someone who is employed and they're doing this on the side, if they're at a point in their career where they're thinking about side projects and they're willing to purchase software on a side, um, they're probably more realistic about how what it's going to cost. They probably been putting away money to pay for this for a while. Now, if you're talking to someone like a college student, that's not usually the case. Unless you working the kid who lives off a trust fund, they're probably just completely unrealistic. They're probably overly idealistic about their project. Or they think it's abnormally simple to build, and they have no idea what development projects cost. So if they have a job, chances are they have been putting money aside, and they probably have some of a budget. Not a huge one, but enough to build a decent application. So number five. How quickly do they go through the process? That's something you'll notice very quickly. Some people. You'll go through seven rounds of discussion in seven days, some of them you go through seven rounds of discussion over the course of four months. Typically, the ones that respond quicker are less concerned or have fewer issues with what you're proposing them. Often it's the case that if they're speeding through the process, that's because money is not an issue to them or they don't see it as something that's insurmountable. Now there are exceptions to this rule. A lot of times you will find people who just love kind of going through the process, trying to get the most out of it, and they have not even thought about the price. But that's usually the exception and not the rule. Typically, people who respond quickly, are confident about what you're telling them, and they're confident about pursuing this project. If someone's delaying, that could be slow rolling you. They could just be waiting and waiting and waiting because they don't like what they hear, and they don't think they can pull it together. Another one. You'll notice a za red flag. Do they ask for additional feature estimates and then that you notice that in the total project, it never gets added? I have this all the time people ask for. I want this really big project and can you tell me on the side what this? This and this will cost. And then when you go back to compile the complete estimate, they're removing those estimates you gave them or you never see them incorporate that into their larger estimate. Now again, as a rule, not 100% true. But typically what's happening is they're not including that estimate. It means it's either nonessential or they can't afford it, so it's usually one or the other. If they keep doing this over and over, it happens a lot. You have someone say how much for this? OK, and you tell them and they say no one is How much for this? You tell them they say no. They'll keep doing is back, back and forth until they can figure something that they can fit in the budget. Typically, that signals constrained budget probably only have enough for the main project and not much else. Probably not a healthy budget. And number seven, this is just a a technique on, and this is the last one. I'm gonna go over for figuring out whether or not they have the budget. When you have someone is asking you questions, you know? How about this? How about this? How about this? What if I did this and you're not feeling whether or not they have the budget or you're concerned about it? Often what you can do and just will save you a ton of time is just go ahead and do the ballpark estimate. And in one of your email correspondence is just tell them Hey, you know this whole thing? Probably if I had to guess is 400 to 600 hours or whatever that ends up being for you 10 to $15,000. Um and just leave that out there, see how they respond. If they skip over that without a beat, then they probably are perfectly fine. Um, it's not really an issue. But if someone doesn't have the budget for that, that will stop them dead in their tracks. And now you know they probably don't have the budget. You can apply your resource is and apply your time elsewhere. OK, guys. So those air pretty much the seven things and kind of red flags that I've noticed. Um, the best way. Honestly, if you're in doubt, give them a ballpark estimate. That'll pretty much shut it down. If they keep going past that point, you're pretty good. Other than that, just try to use your spider sense and think about do their partners. Are they employed? How quickly are they responding? How much thought have they put into this project? Are they really insistent that certain sections are really small or inexpensive? Do they ask for features and never seem to add them to the bigger project? OK, guys, be aware of those things. Look for them. If you have any other things that you've noticed yourself in your experience post in the group discussion, I'd love to hear it otherwise. Seeing the next lecture 8. Don't talk about problems, say what is happening: think I spoke back to the course so quick. Lecture on a big mistake you probably might be making. So in general, this is something you want to avoid when talking with clients. Don't talk about problems. Just tell them what is happening now. The biggest difference between those two is one. You're just being literal saying what's happening and the other one, You're kind of being ambiguous and you're framing the discussion in a way that says whatever this is, um, that's happening is a problem, and it's something to be worried about now. Vendors don't have problems. They have setbacks. That's something you need to kind of keep in your mind because clients read those two things in completely different ways. A setback is just something that happens all the time, something that they should have been aware of before they started the project. Um, and a problem is something they've never seen before, and it's something that I should be worried about. Everyone should be worried about. It's a big deal. There's a really big difference between this is broken and this part is sending the wrong information, saying this is broken. It just saying that something's not wrong with it, and I don't even know what it is. Shows that you don't know what it is, and it shows that it's potentially a problem. And problem is a word you don't ever want to use. So when working with clients try to be as literal as possible. Setbacks happen. But when they do happen, tell them what exactly is happening and how long it's gonna take to get out of this snag. Nothing is ever unsolvable. Whether or not that's actually true. Doesn't matter When you're talking to a client, nothing, nothing is ever unsolvable. If you don't know what the problem is, and you attempt to articulate it, it white sound vague. So just keep in mind, stay away from being vague. Vague implies problem. Using generalized terms like Broken doesn't work. Those things they convey that there's a bigger issue at hand. If you're just literal and say this does not do this and we're gonna fix it, that's not a problem. So try to remove that language from your vocabulary. It'll help you out quite a bit. Guys, Any questions posted a group discussion, otherwise seeing the next lecture 9. Is the client always right?: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about an adage that you pretty much here all across the business world, which is the customer is always right. We'll talk a little bit about Does that apply to development businesses? And is that something that you should incorporate in how you do business? So in development businesses, is the client always right? Well, let's answer it literally, literally. No, very frequently. They are wrong, and typically the most common reason why they're wrong is there trying to make judgments on something that they're experts in. If they were experts in development, then they wouldn't have a need to hire you. But that surely does not stop them from trying to pass judgment or make large project decisions that they are not equipped to make. Now, the true kind of heart of the question is, Do you treat them as if they're right all of the time? A lot of businesses out there in different sectors, different expertise, they like to focus as if every time there's a complaint, the customer is always right, and that's one way that they make sure that the customer always stays happy. That's something that works for a lot of other different industries. Now, whether or not you want to treat your development business like that, that's entirely up to you. I've seen plenty of development businesses use that kind of motto when it comes to customers and client disputes. So if a client isn't happy with something, they were fund them. If the client thinks that they cut corner somewhere, they go out of their way to give them free hours and essentially free money to fix whatever the problem is Now. On the other end of the spectrum, you definitely have businesses and business owners that are combative when presented with a potential problem. It's always not their fault. It's always up to the client to lower their expectations. Now, obviously, success lies somewhere in the middle of this spectrum. My advice for you is to find some kind of balance. Now, keep in mind, this is a highly technical job, and your clients are almost never going to be as highly technical as the people building their project. Even if they do have a programming background. Even in that case, they're not gonna be so acquainted with the project that they're gonna be able to be in a position to make good project based decisions. So in general, when it comes to development businesses, I say You do this on a case by case basis and you do not have a strategy really across the board. I think in our situation it's too hard to make a general rule about customers and how often they're right. Try to pick the individual details and each individual case and make your decision that way . They're always going to be times where you made a mistake. And unless you're the type of situation where you don't think you're ever gonna see that client again and you, maybe you don't want to see them ever again, you're going to tried after remedy the situation. Regardless. Now, if you do have to admit fault, and this is kind of a side note trying not to be overly apologetic, that's something that really roads authority be rational. Explain what went wrong and why. The likelihood of this being wrong in the future is very, very small. Now there's other types of scenarios where the client themselves makes a colossal error. Now it's either because they try to make a judgment themselves. Or maybe they assume they knew more than they actually do. Thes air really unavoidable. And it's pretty much something that you're going tohave happen, guaranteed throughout your business career. Now I wouldn't fret, because in the vast majority of dispute cases, but if you actually gone and detailed out your process, you made sure you had a contract. You made sure that you listed out as much as you possibly can about what you're covering in , what time frame for what? It's very easy when something goes wrong and there's a misunderstanding to go back and actually look at exactly what happened and where something went wrong. Now, of course, there's always going to be situations where it's not nearly as cut and clear like that. It's not nearly just a definitional or a technical error or someone just miss read something. Sometimes both asides actually make assumptions unintentionally that they should not have made. So try to do your best and figure out what exactly went wrong. Did you simply build something wrong and you've yourself forgot to check it? Did you bill for something that you didn't actually explain properly is the timeline. Not sufficiently clear? Has your client getting confused that when things they're going to be delivered, if any of those things are the case, that's something that you can easily figure out, and that is something that is your fault. Now, on the flip side, obviously there situations where clients are wrong themselves. Now you know he's a client accusing you of not telling them something when you clearly did Tell them something and you have documentation to show it. Is your client surprised by a bill that they received? And the reason why they're surprised is because they simply didn't pay attention when you gave them the estimate before. These are all very likely scenarios that can pop up now. If you have properly documented everything and you left a paper trail all your conversations, it shouldn't be an issue figuring out who's at fault. If you're in a type of situation where it's absolutely not your fault, then you should deal with that accordingly. And if the situation were clearly is your fault, then you need to recognize that you need to own up to it. Obviously, don't go over the top with how you lather on apologies, but be obviously rational about it. But admit that something is actually your fault and moved to remedy it. Now there's one thing that's really important that I want you to come away with from this lecture. If there is a breakdown in communication regardless of whoever's fault, it is the fact that it was allowed toe happen is your fault. As the service provider, it is up to you to provide everything in excruciating detail to make sure that your client is on the same page to make sure they understand exactly what's happening when it's happening and what to expect. There is never excuse for not facilitating communication that is your job. That is how you keep happy clients. That is how you save yourself from potential issues down the road. So if your clients not on board, you should not be leaving the port and setting sail to use a metaphor, so I'll say it can Breakdowns in communication. It's your fault that you let it happen. It almost always comes down to you did something where you cut a corner. You decided to not send an update. You decided to not key in your client with something, or you decided to skip a step. So is the customer always right? No. They're not always right. It's up to you to make your own policy decisions. Personally, the best way of doing it is just on a case by case basis. You could easily figure out whose fault it is, and there's easy ways to handle situations at all. Your fault. There's easy ways to handle situations that are the clients fault. Use your documentation, use rationality and try to be a simple as possible when you explain what exactly happened and how to fix it. But always be aware. The fact this dispute does exist is because you probably did something wrong in your process, so use it as a feedback opportunity to improve your process so that it doesn't happen in the future. All right, guys, any questions posting the discussion Otherwise seen? The next lecture 10. Do you deliver what's good or what the client likes?: Hey, guys, welcome back to the course. So in this lecture we're gonna talk about do you follow your instinct with what you think is good? Or do you follow what the client says is good? It's a dilemma that you're going to run into now. There's gonna become a time through your development business career. You run into a situation where client wants something, but you know, and you're pretty sure that will end in a poor outcome. It's something that you know will not end up looking good. So is an antidote to this. I can tell you a little bit story. It's sprint kick. We had an application that was a mobile app was a very large project. And we had multiple occasions have this dilemma. And I remember very specifically one time having our client have us redo the app icon 4 to 5 times and eventually he just sent us an APP icon that he liked and said was amazing. It was probably the worst app icon I've ever seen. I described it as it kind of looked like if you got an app icon, but it was processed by a Nintendo 64. It was pixelated. It had a really lame Grady in across it. That kind of reminds you of the early two thousands. It just looked absolutely absurd. I knew it didn't even match the design of the APP, and it would look horrible on your phone. And that's not the only time that's ever happened. It happens a lot of times. I mean, I've had multiple times clients. I really think that they know exactly what's hot and what they show you or what they want is just ridiculous. Now, in order to fix this dilemma and to figure out a way going forward, you need to evaluate your priorities primarily. Are you doing this for a portfolio? And if you are doing a for portfolio bubble, adding this new design change or development change to the project and then adding at project your portfolio, is that gonna ruin your portfolio? Is it one of those cases where you're doing this for a small amount of money, even know money? But you're just doing it to build out a portfolio or for some other reason you took on the contract. Now, if that's the case, I would say that you need to try as hard as you can to convince your client that what they're doing is wrong. And you need to be very specific about why you believe that. That could be very difficult to explain. A lot of times this is very subjective. You're just going to say that color doesn't look good. How do you objectively explain that the color doesn't look good? It could be difficult, but try your hardest. And as long as you make sure that you give repeated efforts to explain it, it should be able to get the message that you are very adamant about this being a bad decision past that. If this is a portfolio um, project and you're not getting a ton of money from it, you might want to consider just walking away and trying to distance yourself from the project. If you're in the middle of the project, maybe it's something that you try to wrap up more quickly. Um, and you don't try to continue wasting a lot of time and resource is on it. If you're at the very beginning of the stages of the project, maybe you do really try to just walk away slowly and try Teoh kind of cut your losses. Now, if it's a big project or it's a repeat client or it's a project that's got a lot of money on the line for you, then I would suggest you try to suck it up as much as possible. Obviously, try to tell them why you think it's bad. Try to explain that it is bad and tell them that you do disagree. But the end of the day. Try to keep the client happy at the same time, you can definitely put as much effort as you can into minimizing the damage they dio. Maybe this new design thing there in putting on this new change, it's only very minimal. Um, what you can do is you can try to offer them alternatives. You can try to even suggest putting that section somewhere else. You can also suggest other features that could potentially replace it or offer new design alternatives. You can even go as far as to do some of that work for free for them because you know that if they do it themselves, even though you get paid for that additional work or the design, it's actually gonna be a detriment to the project as a whole, and that's what you don't want. So, guys, this happens a lot. I think as long as you're conscientious about the fact that there is going to happen, you can figure out a way through it. If it's a very important project, then you need to suck it up. But you need to try to at least divert your client towards trying something else. Try to give them alternatives, trying to get your designers or your friends to give them something as an alternative that they could use instead. But on the flip side, if this is just a portfolio project or one you're not even crazy about, this might be the impetus for you to walk away. If you work with clients that have very bad design and feature taste, they're probably not going to be successful their project, and they're probably going to have this problem multiple times along from down the road. If you end up with an ugly project, it's very often the case that they blame it on you, not realizing that a lot of it is their fault. That's just a headache you want to avoid 11. Keep the learning going: Hey, guys, I just wanted to say thank you for taking this class, and I hope you learned something. I hope what I said made sense, and I was clear. If you have any questions, any concerns, just posting the group discussion, all respond to you. You could even send me a direct message if you want to. I want to give you a quick word of how you could take the skills that we learned in this class and how to bring it to the next level. Learn some other related skills in this class. We covered how to manage the clients you have, how to keep them happy, how to position yourself, what language you should use and how to make sure that they keep coming back to you with their future work. Now, if you want to learn more about running your Web freelance business more effectively, have a lot of other classes you should check out Specifically, check out best practices for Web freelancers. That's a class of where I show you all the advanced techniques and advanced tricks for running your business, growing it and making sure that you're happy and it's growing in the right direction. Another one worth checking out is the art of the proposal. In that class, I show you how to build professional proposals that are interesting, seductive and, most importantly, closed sales. Okay, if you want to go further with your skills, check those out. Otherwise again. Thank you for taking the course.