How to Give Amazing Project Feedback (Part 4)
Unpacking the most common pitfalls to giving actionable and insightful project feedback and how to address them. (Part 4 of 4)
Problem Three: Ineffective and Disempowering Feedback
Conversation format matters
While where a project is in the development process, and the size of the project are all critical factors to consider when giving feedback, none of that matters if you aren’t using a conversational format that aims to provide the most power and autonomy to the individual or working team receiving the feedback.
Below I’ll break down what I call the Three C’s for this format: Context, Clarify, and Counsel, developed from years of delivering feedback on project work.
Ask for Context
Before you say anything, don’t assume you know why someone is proposing a particular solution. Sure, you could be correct, but at worst, it looks like you’re playing a game of “gotcha,” which anyone on the receiving end will tell you feels terrible. If you want to give empowering feedback, don’t play that game.
Asking for context means asking the team or individual to unpack their thinking, and your question should be specific and genuinely curious.
Bad example: Keeping people on the form page is an awful experience. Why do you think we should do that?
Good example: Would you explain your thinking behind keeping people on the form page after they submit, instead of taking them to a confirmation page?
Experts suggest that up to 93% of communication is non-verbal, and if your tone is inauthentic, the listener will get a “gotcha” vibe.
To get into a beginner’s mind, really take a moment to let go of any preconceived notions or conclusions you have — you can even mentally visualize putting them on a shelf for the moment — assume you don’t know how the team arrived at this proposal and you want to understand why.
Stay in this mode for as long as it takes for you to comprehend the “why” behind the proposed solution.
Clarify your Challenge
You might get exactly what you need by asking for context — that’s great — but if you don’t, and you have a challenge with the proposal, clearly state your concern — but — do so without giving a specific solution to the problem you see — even if you have one.
Yes. You read that correctly. Don’t automatically tell the team your idea for the problem you see.
This. Is. Hard.
And because it’s hard — and takes longer — this is where most people fall down and give prescriptive feedback. It seems faster, more straightforward, and therefore better, but prescriptive feedback has many pitfalls to the vitality of the working team.
Bad example: I don’t think this is the right design pattern to use. You should send them to a confirmation page.
Good example: Thanks for explaining the team’s thinking here. I hear that you have good reason to think people will need to fill out this form multiple times, but I’m concerned they will miss the toast notification you are suggesting, and also site consistency with our other forms. Did you explore other options?
Why giving your solution can be a mistake.
Giving a solution seems helpful — you’re going to expedite things, right? Not necessarily.
Your solution could be the best idea, but if the team thinks they need to pursue your opinion (read: HiPPO), it can cause swirl or push the team to build something less optimal.
Clarifying your concern but putting it back to the team to solve it gives the team autonomy to think through how to do it best.
And while the team may come up with the same solution you thought of in the first place — they may also come up with something even better.
It can feel exhausting but play the long game. This strategy helps the team develop and grow their capabilities and confidence. Long term, it leads to more empowered individuals and teams.
Be good Counsel
If the team is struggling to come up with ideas — maybe they are a junior crew and need more directive coaching — or are stuck or asking specifically for directive help— then yes, offer your opinions.
But even then, do it with the framing that because they are closer to the work, they should try or consider these ideas — and explore them — and not automatically assume that your idea is going to work or is best.
Bad example: I think you should just send them to the confirmation page.
Good example: Here is an idea to try: what if we sent them to a confirmation page, but made it easy on that page for them to get to the form again. Could that work?
Empower them to take ownership of the ideas and state your excitement about what they will come back with at the following review.
At every moment, return autonomy to the individual or team and celebrate them solving the problem.
If there are things they missed outright that do need to be addressed, like missed error states or forgetting about an empty state, you should give that feedback too — but that should be the minority, not the majority of your feedback.
Conclusion
Being a good feedback giver on a project means taking responsibility for ensuring you are giving empowering and actionable feedback.
It means you are coming to meetings prepared to be useful, and are aware that the “wrong” feedback can have serious consequences on the project at hand.
While no one should expect to do this perfectly, the good news is that if you catch yourself derailing the team, being vague, or any of the other gaffs, you can always course correct in the meeting or clean it up afterward.
The latter can be awkward, but it is better than wasting the team’s time, slowing velocity, and perhaps even more importantly, lowering the project team’s morale.
So go forth and practice being a good feedback gift-giver!
And if you have other frameworks you like to use for effective project feedback, drop me a line and let me know.
Full Series
- Introduction
- Problem One: Wrong Feedback for the Project Stage
- Problem Two: Treating All Projects Like Big Projects
- Problem Three: Ineffective and Disempowering Feedback
