How do you manage the expectations of someone who thinks what you do is magic?
As we’ve said here, when you’re writing software, that’s usually what you have to do.
People who don’t understand code might as well think developers wave a magic wand and stuff appears.
You don’t need material, so you’re not waiting on anything.
There’s no physical labor so it’s not like you need a break.
And there’s no physical product, so it’s not like you have to build anything.
This isn’t a matter of respect, it’s a matter of understanding, and the vast majority of the time, clients just will not understand code.
That should be expected.
After all, if the client understands code well enough, what do they need us for?
But how do you actually solve the problem of unrealistic expectations?
That comes down to trust – something you’ll hear a lot from us.
At the end of the day, most everything comes down to trust, which is getting harder and harder to earn in our industry, especially when other companies work so hard to break it.
You have to be able to say to your client: “This is a six-month project” and have them actually believe you because the gut reaction is “this should take six hours” or even six minutes.
So when they’re expecting less than a day and you tell them six months, the gears start turning.
“Are they trying to take advantage of me?”
“Maybe they’re just trying to get more money.”
Without trust, mismatched expectations can get the gears turning quickly.
To get that initial trust, you need to be really patient.
Now, of course, you can’t take the time to teach the client everything you know about coding and software development, but you need to do the best you can to explain things in terms they’ll understand.
Let’s take a real-world example we’ve dealt with.
We were developing custom integration for an e-commerce application recently for a client who didn’t have an e-commerce platform yet.
The initial budget was small, so we needed to use standard templates to get the core platform up and running to be able to build our integration.
We were very straight forward with the client about this and explained that templates are great but they never get you 100% of what you want. You’ll be sacrificing control for cost.
After the platform was setup, the client wanted the sub-navigation items to appear when the mouse hovered over the main navigation.
As it stood, the sub-navigation items appeared when the main navigation was clicked.
There’s good reason for that, which is that there is no concept of a “hover” on touch devices so it’s much easier to make the behavior be click/tap for all devices rather than develop separate code for each device.
We explained this to the client, who still wanted the behavior.
The problem, however, was that the code for controlling sub-navigation behavior was embedded pretty deeply into the template’s code.
So we explained to him that codebases have parts that are easily modifiable and other parts that are core and require a lot of effort to change or replace.
Think about a car.
Somethings are prime targets for aftermarket replacements: Radio system. Headlights. Taillights.
Then somethings just aren’t: Oil pump. Seats. Engine. Transmission.
The “click” behavior was more a “Seat” than a Radio head unit.
Sure, we can modify it, but it’s going to take way more effort than our initial budget allows.
It’s worth the effort.
The client will always appreciate the extra time to explain things.
At the same time, look for opportunities to say “yes” or provide alternatives.
Never just shut a client down with “we can’t do that.”
Because the reality is, the answer to “can you do x” is almost always “yes.”
The relevant question is “does my budget cover x and if not, how much is it going to cost?”
The point is, even if changing the “click” behavior to a “hover” behavior isn’t covered in the budget, if it’s not going to put you in a difficult position, go ahead and do it.
But let the client know that you’re going outside of scope.
“Actually, that isn’t covered as part of the budget, but it doesn’t look to be that difficult, so we’ll knock that out for you.”
This isn’t to rub the client’s face in it.
It’s to communicate and build trust.
If you just say “yes” with no explanation, the client thinks you’re just doing your job.
But if you explain to them that the request is out of scope, but you’ll tackle it anyway, you’re making the client feel comfortable that you’re honest.
So when you say “actually, that’s not covered by the budget and that’s a pretty big request, so if you need that done, we’re going to need to expand the budget a little bit” the client will have past context to say “Cool. They did x, y and z for me even though those were out of scope, so if they’re telling me this is a big deal, it really must be a big deal.”
At the same time, look for alternatives to offer instead of just saying “no.”
As an example, we had a client whom we built a web app for.
After awhile, the client asked us to add push notifications to the web app.
For those not familiar, push notifications are those messages you get on your iPhone or Android devices that appear on your lock screen.
Now, until recently, push notifications were not possible with web apps.
So, we could have said “Sorry. Push notifications aren’t possible with web apps,” which, we actually explained upfront.
However, our response was more like this:
“Web apps are great because they save cost, which is what attracted you to them at the beginning of the project. However, as we explained, the tradeoff is that web apps don’t have all the functionality of native apps. To get true push notifications, we’d have to convert the web app to a native app, which is going to be double the budget we have right now. However, we can achieve nearly the same functionality if we send a text message to the owner of the app to alert them instead of a push notification and that won’t even overstep our current budget.”
Patients, communication and alternatives will go a long way in establishing trust, which is so crucial in this industry.