How to Give Amazing Project Feedback (Part 1)
Unpacking the most common pitfalls to giving actionable and insightful project feedback and how to address them. (Part 1 of 4)
We’ve all heard the expression “feedback is a gift” — and done well, I agree. However, while feedback is a gift, it is only as good as the gift-giver.
And there are a lot of poor gift-givers out there.
“I don’t like that color.”
“Can you make it pop more?”
“This isn’t doing it for me, but I’ll know it when I see it.”
Let’s be clear: when you give feedback on a project, you don’t want to be a poor gift-giver. I will be bold and assume your goal is to be useful. Supportive. Get the team to move in the right direction. Or maybe even change direction. Or slow down before the next step.
Almost everyone giving feedback on a project wants it to do one thing: help.
In this series, I’ll be breaking down strategies to improve the impact and relevance of your project feedback. While I apply this specifically to the world of product development, these same tactics can be applied to other disciplines where a project goes from idea to final delivery.
A bit of backstory
I’ve worked in product development for a long time, over eighteen years. I started as a front-end developer, became a producer (a role in the early aughts that was a fusion of project and product management and UX), and lastly, moved to product design. As a designer, getting copious feedback on your work is part of the deal.
It can feel endless.
There are design crits, sprints, jams, team meetings, one-on-ones, workshops, product reviews, studio sessions, and a seemingly infinite number of groups and individuals you can talk to in the dog-and-pony show to get approval on your work.
As a designer, learning to gather and synthesize feedback is essential, especially since people will continue to pipe in and say, “can you make it bluer?”
However, my goal with this series is to help you not be that person. So whatever your role — product manager, business stakeholder, design leader, fellow designer, and so on — you can be a model for giving good feedback. Furthermore, have your feedback yield higher impact and results.
Why learn how to give feedback?
I’ve seen companies tackle the operations side of the product development process — and precisely how to move a project forward to increase the autonomy and velocity of the working team — in various ways.
Companies create presentation templates, RACI structures (and RAPIDs and DACIs), project checkpoints, checklists, and so on to ensure consistency, transparency, and a chain of command.
While all these devices help the product development process, they rarely impact the quality of feedback given throughout this process.
Poor feedback can cause swirl and stall project velocity.
While teams may tell reviewers what kind of feedback would be helpful, the framing can be poor. And since this is not a series about those presenting — but those reviewing — I want to ensure that even if the presenting team has not set the stage well, you feel empowered to participate and meet your primary objective — to help.
In this series, I’ll be talking about how the value and impact of your feedback ties directly to:
- Where a project is in the development process,
- The size of the project,
- And using a conversational framework that is both impactful and empowering to the working team.
How these ideas came about
I began developing these frameworks because I have made my share of feedback mistakes throughout my career.
Like many well-intentioned gift givers, I have given poor feedback.
I’ve given exploratory feedback when the team is trying to narrow in on a solution. I’ve been overly prescriptive and directional about what the team should do — or the opposite — been vague, so the team isn’t clear about what I’m asking. And so on.
These frameworks are born from lessons learned, and now I offer them to you to help ensure your team’s success.
