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, 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
Top comments (4)
On one side, I agree with the idea, but it's only doable if you have a strong project manager who's willing to keep the client accountable to the features they are paying for.
Allowing clients into a system early leads to "I thought it was gonna do X, and isn't it supposed tobe doing Y?" and then the "Can it also do Q? Oh and if we change this, wouldn't it be better" and so on and so on where a client scope creeps the hell out of things.
You also don't want the client saying these things directly to your developers since devs will just start making the changes and the PM will lose control of the project.
So, in an ideal world where clients have no budgets and your team has no budgets or deadlines, this is great. With real projects though it can be a massive can or worms if not manager correctly throughout the process while keeping track of milestones and launch dates.
Totally agree here I think the other side of this is that you have to move away from fixed scope engagements entirely. You pay for a team to work on your product for a period of time. For us we do monthly pods. If you want new features that's totally fine, but it forces the client to think, is this feature REALLY necessary since it comes from their budget. So an important part of this is that there is no scope creep because we don't engage in a fixed scope project like that we look to be in this for the long haul and continue iterating over time. The fixed scope is almost implicitly waterfall unless it's very constrained.
Hello Mike Rispoli,
thank you for your article.
It's an interesting read and has an exciting concept that you propose.
Is this based on real experience?
If yes, what are your positive and negative experiences?
Yes indeed, at my agency the rule is 48 hours and we need at least a screen recorded demo and every two weeks there needs to be something tangible for the client to use. If we can do this at higher frequency even better. The pros of course is better relationships with all of our clients and developers love it because they feel like they’re bringing value to people more often.
In terms of cons, developers do have to get used to working in such a way that they can show value. Generally this means working on a vertical slice of the project rather than say building the whole API out first then moving to the Frontend. This tends to actually be a better way to work overall because it highlights discrepancies in the design early before we built out an entire backend but some developers need to adjust their working style to accommodate this.
The other thing is this really is dependent on you moving away from fixed scopes entirely. This can be challenging because many clients want to know exactly what they are getting for whatever price they are paying. This is almost always a losing proposition for you. Since there is always more software to build then scopes like this ALWAYS creep and therefore you ALWAYS lose some amount of money. This system allows you to get to a place more easily where you can say that nobody can actually commit to some definite scope of features without knowing if those features actually provide any value to users. This way we get to iterate our way to value. But this takes some salesmanship. This process will help alleviate the stress for the skeptical client that isn’t used to agile ways of working.