What should I say when a client asks me for tiny changes?

Show Notes

Q&A from TheJonathanStarkShow.com on YouTube

----

Do you have questions about how to improve your business?

Things like:

• Value pricing your work instead of billing for your time?
• Positioning yourself as the go-to person in your space?
• Productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal?

Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes to get ready for work in the morning.

Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call, you don't feel like it was worth it, just say the word, and I'll refund your purchase in full.

To book your one-on-one coaching call, go to:

https://jonathanstark.com/call

I hope to see you there!

Creators and Guests

Host

Jonathan Stark

The Ditching Hourly Guy • For freelancers, consultants, and other experts who want to make more and work less w/o hiring

What is Ditching Hourly?

For solo professionals who want to make more and work less without hiring.

Hello and welcome to Ditching Hourly. I'm Jonathan Stark. Today I've got an audio excerpt from an answer I provided on my YouTube channel. You can check it out at thejonathanstarkshow.com and it'll redirect you to YouTube if you're into watching videos. Otherwise, you can just listen to the audio here on the podcast. Enjoy. Hey, Jonathan here. I've got a question from Andrew Haydash who asks, I have a question I'm sure was asked before. Let's assume that you have done a project for a client and they want you to add small features after it's launched, like add a few fields to a contact form, change some colors, blah. Do you still price those tiny features based on value even if they'll take five hours max? Thanks. OK, so common question, as you said, and you need to kind of think about the project in a specific way and these sort of follow up things in a specific way. So it's probably different than you're used to thinking about it if you're thinking about scope up front and creating an estimate of how long you think it's going to take and so on and so forth, the normal hourly model. So here, what I want you to imagine is a client comes to you and they have a project. It's an actual project, a project meaning it's got a start, it's got a middle, it's got an end. There's going to be something that's done. There's a launch date or a completion date. There's some success criteria at which point it's done. It's not like an ongoing support and maintenance kind of thing. So when you're quoting a project and you want to do it in a value based way, which is what the question asker is talking about, you want to figure out what is the outcome they're trying to reach and give them a fixed price for that outcome based on the value of the outcome to the client. And then price it in such a way that after launch, when things like this are going to crop up, you know they are. It happens every single time. There's either little bug fixes or things they think are bug fixes that are really things they didn't ask about in the first place. Build that into the price because you know it's going to happen. This is why I don't like having a sign off date for a project on which you get your last payment because then you're done. Everybody's mentally done. And then these things that crop up afterward, it creates an uncomfortable situation of like, well, yeah, we paid you and we're done. But, you know, then they have to kind of almost they're not attacking you, but they kind of try to play these games with you about like, well, you know, guilt you into doing this stuff for free. And you're like, well, you didn't really ask me for that. So I have to charge you for it. And you've just had this project, hopefully a successful project with them. And then to end on this like awful note of fighting over whether or not something's a bug or a feature should have been included or not included. It's not how you want to end the project. It's not how you want the relationship to wrap up until the next time you work with them. So what I would imagine, what I would suggest to people, one of the suggestions that I have for especially software developers, if you're going to present a premium price for a software project to someone, one of the things you have to do is differentiate yourself from whatever low cost competitors they might be considering. And one of the ways you can do that is by offering a bug free guarantee for maybe six months, maybe 12 months after launch. If any bugs or issues crop up for the next six months or whatever the period is, we'll fix it for free. It's all included. There's always going to be something. We know it's going to happen. So why pretend it's not? And we'll just build that into the price. So you're offering them, it's kind of like, you know, 50,000 mile warranty on a car or something like that. It's going to happen. So when things do crop up after the project is over and it's done and like, whoops, we missed something or we didn't catch this in testing or now that we've got all the customer data in there, it's not operating exactly the same. Then it's still very profitable for you to fix little things here and there, you know, five hours maximum. It should be no big deal. If you have built profits into your project, five hours here and there is not a big deal. You're still doing fine. So the question that always comes up is, well, what's the difference between a bug and a feature or something that they broke? Like they might have broken something or their IT department might have upgraded the underlying hardware and now the software doesn't work or something. So it's not that you would just limit the bug fix guarantee to bugs. But when something comes in that's actually a feature request, could you add this field? Could you change this color? Could you repair this plugin now that the upgrade happened, the plugin's not working? What I would say is to the client, I'd be like, especially for like adding a field or changing a color, I'd say, yep, we'll do that. But I do want you to know that that's not a bug. Do you guys understand what a bug is and make sure that they understand the difference between a bug and a small feature request? And they'll say, yeah, we get it. But thank you for honoring it anyway and kind of make it clear that you're sort of doing them a favor and that you can kind of educate them.

in the moment about what is a bug and what is not a bug. And if their IT person breaks something and they say, oh, could you fix this thing? You say, well, we'll do that for you, but realize that that's not really a bug. That's something you broke. So we'll do it, but we're not going to do that forever. So we're doing you a favor. We're doing you a favor. We're doing you a favor. At a certain point, assuming the client's not a complete taker, let's just say, in which case you probably shouldn't have worked with them in the first place, but assuming that they're a reasonable person who you get along with and you've had a successful relationship with, eventually they're only going to be reporting bugs because you've sort of trained them to feel bad about asking for features and asking for favors, basically. You'll train them and it'll eventually peter off. It'll tail off pretty quickly. If it starts to not tail off and it starts to crop up, then you can start having a conversation about maybe we need to start up a new project. It seems like now that you've got the new software product, you're having all these new ideas about reports you'd like to have or tweaks you'd like to make to the export format or so on and so forth. Why don't we collect all of these over the next six weeks? You can collect all of these sort of things that you'd like to have included and we can put together a proposal for this new V2 or this initial series of upgrades that you'd like to have to the system. We'll give you a price for that. What you can do is now instead of when these requests come in, instead of them expecting you to jump on them immediately, you can collect them in some sort of shared document and then when they start to tail off then you can say, okay, I think it seems like things are kind of stabilized in terms of feature requests. Now that we've got this new information, we'll put together a proposal for doing these things. Now at this point, it's going to be pretty hard to value price it. Well, it's not hard to value price it, but the value is probably going to be pretty low compared to the initial project. So I probably wouldn't wrestle with it too much. I'd probably just either hand it off to someone else and say, we haven't got time on our calendar to do this list of things, but they're pretty straightforward. You should probably be able to get them done with some agency that we can recommend or developer that we can recommend and just hand that work off to them. If you'd rather stay involved with the client for the next big project or maybe some sort of support maintenance agreement, which you could talk about too, you could do that. You could price out the task list of things that need to be done. You built the system, so it's going to be pretty easy. There aren't going to be that many surprises most likely. So you could just take their money, bang it out, and not think about it too much. Not turn it into like, well, why do you want these features? Why not just leave it like it is? It's going to be hard to do on the coattails of a big project that you did value price. Because now you've sort of built the building for them. So you've designed the building. Here are the blueprints for the building. Then you built the building for them, and now they're in the building. And that's where all the big value, the urgent, the risk, all of that stuff, that's where all the value was. And now they're asking you to change the blinds, move some chairs around, mop the floors, replace the toilet paper. It's not going to be high value stuff. So you're probably better off just sort of after the bug-free guarantee period is over, you collect these list of features for a V2 or a maintenance upgrade or whatever, and just give it to someone else to do, introduce them to somebody else. Because they're probably not going to have a big project like you just did with them for a long time. Unless maybe there's another department or whatever, but this particular client is probably not going to have another big high value project for a while. So bothering, going through the emotional effort of doing a value price for them is probably not going to result in any highly profitable situation for you. So probably either just do it for some quick fixed price and just say, yeah, price all of these things would be $5,000. Does that sound okay? And bang them out. And they'll either say yes or no, or you can send them to someone who's less expensive. All right, hopefully that helped. I'm Jonathan Stark. And if you have a question for me, you can hashtag AskJonathan on Twitter, YouTube, or LinkedIn, and we will find it and add it to the queue. See ya. Would you like to learn how to get paid what you're worth? How about selling your expertise and not your labor? We work through all of this together in the Pricing Seminar. Pre-registration starts soon, and you can sign up to be the first to know when early bird pricing is announced at thepricingseminar.com. That URL again is thepricingseminar.com. Hope to see you there. Hey, Jonathan again. Do you have questions about how to improve your business? Things like value pricing your work instead of billing for your time. Or positioning yourself as the go-to person in your space. Or maybe productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal. Book a one-on-one coaching call with me and get answers to these questions and others in the time it...

To get ready for work in the morning. Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call you don't feel like it was worth it, just say the word and I'll refund your purchase in full. To book your one-on-one coaching call, go to jonathanstark.com/call. That URL again is jonathanstark.com/call. Hope to see you there.