The Cure for Client Anxiety
Tags: management, leadership, programming, software
Published: 2022-08-19 15:04:14

---
title: The Cure for Client Anxiety
published: true
description: Client anxiety, we all know the signs. It starts with emails every few days to check in on progress. They start benign at first. A new idea about a feature, a nice to have here, something they forgot to tell you about a customer there.
tags: management, leadership, programming, software
cover_image: https://images.ctfassets.net/m33y9bdtd8t2/752h3KZXxCJwafzlGoZw6L/34b6b14551d5633de245719c5dabaf72/nikko-macaspac-6SNbWyFwuhk-unsplash.jpg
# Use a ratio of 100:42 for best results.
---

Client anxiety, we all know the signs. It starts with emails every few days to check in on progress. They start benign at first. A new idea about a feature, a nice to have here, something they forgot to tell you about a customer there. 

It goes something like this:

> "Hey, I was thinking it would be great to add a button to the nav."

A few days later you get the next email:

> "Hey there if the team hasn't started on this feature yet would it be possible to..."

The weekend passes and on Monday you receive:

> "Hey we have a campaign we're looking to put out on Friday, do you think you'll have the application ready in time?."

Each time your frustration grows. What don't they understand about design lock? We told them the launch date won't be for another four weeks during the sale! You're getting frustrated at the questions, but missing the root cause, client anxiety. 

This is a classic problem for development teams. At agencies, this means you are building in a black box. We fell victim to this often early on in our growth. We'd sign a contract, put a line in the sand at some point in the future based upon an estimation framework, and go to work. Weeks would pass with what appears to be zero progress. You'd start with all that boring server setup and move on to the back end APIs. Or you build out the designs but don't want to show them until the design team approves every pixel.

You do this to save the client, to protect them from seeing how the sausage is being made. You've created a situation where the specs go into a box, and out comes a perfect product. You say you work in an agile process, and you even do follow agile within the team. But to the outside world this is a canoe going over a waterfall.

What ends up happening is a few weeks before launch the client team can't take it anymore. They have to show something. The client's emails have grown frequent, frantic, and animated. You show the construction site and it's a disaster. Now your team needs to field bug reports and change orders before they've ever gotten to the finish line. This leads to further delays, more frustration.

It took me a long time to break this classic agency paradigm. The reluctance to show clients how the product is progressing at every step. To embrace an agile process both for the internal team and for the clients.

How did we fix it?

It's a framework that came from one of our mentors, [Eric Elliot](https://ericelliottjs.com/ "Eric Elliot"), called *demos over deadlines*. Here we don't set some amorphous due date in the future for complete products anymore. 

This means that a staging server should be ready and accessible to clients within one week. It means that every 48 hours we can demo some feature to the client. This can be as simple as an email signup, or a banner, or the navigation, or an API endpoint. If this cannot make it to staging, then a screen recording will suffice. 

Every two weeks we guarantee a release to the staging environment. It doesn't matter if design or product hasn't reviewed it. It doesn't matter if there are still items in progress. The client will be able to jump in and feel what they are paying for. We can always say, we deployed a, b, and c, but are still patching up x, y, and z. 

The cure for client anxiety is to remove the black box. Clients understand a work in progress, what they don't understand is obfuscation. 

But wait! Doesn't that mean we're going to be fielding bugs and changes in the first weeks of the project?!

YES!

In true agile fashion we should be welcoming this feedback early. When we receive critical feedback early, the changes don't pile up into a frantic, final sprint. We can address issues, bugs, or discrepancies in the spec early. 

It also pushes clients to get user feedback early. To confirm all those user assumptions made during design. Do it sooner, with two or three trusted customers. The insights you gain will save you months of wasted work.

We now have the cure for client anxiety, *always be shipping*!

---

Posted originally on the Cause of a Kind blog: [here](https://www.causeofakind.com/the-salon/the-cure-for-client-anxiety)