Feedback Management

Hope for the best, plan for the worst. Always assume that there will be ample feedback and you won't be disappointed, please plan your timeline and budget for extensive feedback. If you are pleasantly surprised and there is almost none, you can use all that time to fine-tune the project with some of your team's ideas, get ahead of your timeline or catchup on a previous delay.

This chapter is both the most straightforward, and the most complicated. The way I see it we have three scenarios for feedback: acceptance, rejection or wishlist.

Although we plan for feedback windows and sometimes they are necessary, it is difficult and not always beneficial to limit feedback to planned windows - I recommend focusing on steering that feedback during different stages of the project and giving a platform to exchange feedback in a permanent shared space so that everyone can calmly analyse requests and respond carefully.

I do not recommend giving feedback in real-time during a call, our spontaneous thoughts aren’t always the most insightful.

My approach is to let the client know that they can start collecting a certain type of feedback (for example functional, or creative, or bugs) and add them to a Trello board. As they come in my entire team has access, can assign tickets according to discipline or respond calmly to the client when something won’t be accepted.

When enough feedback has been accumulated and their might be a few contentious requests, I plan a call to which the relevant team members can come prepared with explanations.

First off, keep in mind that a producer who gives in too easily to client demands is quickly perceived as the compliant vendor rather than the expert. The loss of that privilege is irreversible, the client begins to dictate feedback and dominate the collaboration. So we want to be careful about accepting feedback that goes against the grain of the project or that is given much too late to be handled safely.

That being said producers can turn change into a springboard for creativity and progress, as opportunities to improve the project.

As a producer, your role is to distinguish between desirable and undesirable change, between expected and unexpected disruptions. This discernment will empower you to take calculated risks, steering the project towards its most beneficial outcome.

So don’t immediately lean towards rejection, look at the feedback from their perspective and see if it makes sense, if it might be beneficial to the project and to their audience.

Sometimes the feedback is plain crazy, or completely out of scope. This is when you need to maximise your role as an expert to explain why the feedback cannot be accepted. Challenge the client with structured explanations and push back on client requests that don't contribute to the project (perhaps the main culprit is time, or it would cause user experience issues).

Clients might disagree with your creative team's ideas, if you can't convince them to follow your recommendation try to understand their perspective, is it strategic? Define these limitations and iterate on ideas that improve their vision.

Dealing with change requests and feedback can sometimes feel like a tug of war between you and the client, it gradually spirals into open conflict. However, there's a powerful tool at your disposal that can turn this potential source of conflict into a collaborative and fruitful conversation: the Wishlist.

The Wishlist is a running list of potential changes, enhancements, or additions to a project that are brought up during its lifecycle but are not part of the current scope. This can include anything from new feature ideas to design alterations or even experimental concepts.

Anytime a client makes a request that could be beneficial to the project but which is unfortunately out of scope, my default answer has become "We’ll add it to the wishlist." This confirms that you’ve listened and heard their feedback and that it makes sense and will warrant discussion later. All the while smoothly reiterating that it isn’t in scope, but it hasn’t been outright rejected - it is simply delayed.

So let’s recap, why use the Wishlist?

Once you’re ready to open the Wishlist conversation, ask the client to express which tickets should be considered a priority. Take that information and come prepared with a price, I often make a few concessions but you should be billing enough to cover the new scope.

Contractually this Wishlist conversation is called a change request, once confirmed by the client you will need to issue a change request - with smaller companies you will likely just send an invoice but on larger projects it might require a formal contract.

Set up a Kanban on Trello or Asana! Familiarise yourself with the tool and prepare the board as you would for a client (with columns for Backlog, In Progress, Done). You can also use it to make some links or information permanently accessible since this is a shared space for you and the client.

Here’s a video showing you how to manage tickets in Trello.