How to turn a problem into a solution and keep your client happy simultaneously.

No one likes a problem, and in some cases, the fix needed cannot be done for some time but with a client demanding change, this can be difficult to manage.

Whether you work in an agency or client side, it doesn’t matter. Managing expectations is problematic as to get the expected solution; you might be held back by a lack of knowledge/skills, capacity in the team or just the budget or approval to do it.

The first thing you must do to manage a problem is to provide clear next steps, as you have to show them quickly that you’ve listened and are already progressing toward resolving it.

But what do you do with a client expecting the perfect solution, which is unrealistic with the team you have, the time and the budget you have available?

You create a solution map.

I’ll use an example where a client is not happy about the quality of the latest version of the app you’ve just released.

Too many bugs have not been spotted, which they expect your team to have found and fixed before going live.

The problem isn’t fixing these bugs; it’s not having the test coverage to prevent this from happening again.

To fully resolve the problem, you need to increase your test automation coverage which takes time as a different skill set is required in the team, more team members are needed, a change in how you test the app, and the list could go on.

Unfortunately, expectations are high on getting this fixed for the next release, but you know that’s not possible.

Here’s what you do.

With your team, get a whiteboard, Miro Board or anything else you can all contribute to on the far left-hand side of the paper/slide/whiteboard; list out the current release process or the definition of done (DOD) for any release and call this DOD V1.

Then on the far right-hand side, list out your ideal DOD for the release process that would solve all your problems.

That’s the easy bit done.

Now you need to create incremental changes to improve your DOD in a logical order. So to the right of the DOD V1, list the next version of your DOD and title it V2.

This one needs to be an improvement from the last one, but it has to be achievable and have value, but don’t overpromise.

Follow this same process, creating DOD V3, and V4 until you get to your ideal DOD and name that with the final version number.

Typically don’t go more than five versions as otherwise, they lose their impact as you’ll be asked why can’t you do all the changes shared in V2 and V3 together.

You now have a solution map but with no timings.

Next, with your team, which is essential, discuss a comfortable time frame to implement these changes.

For example, you need two sprints to get to DOD V2, so add this to the gap between V1 and V2.

Once finished, you have a logical plan to resolve the client issues with your release process that you can talk through and show you’ve listened and have the plan to fix.

Another thing you can share if the client is still pushing for this to be done quickly is to communicate the following:

1. This approach is made across a period of time to monitor the improvements and reduce the risk of a big bang approach.
2. You can simultaneously work on other aspects of your app features so it doesn’t impact their current release plans.
3. Where appropriate, involve them in the creation of the solutions map, as the more they’re involved, the more likely they’ll agree with the approach.

Here's an example of a solutions map.