How to Give Amazing Project Feedback (Part 2)
Unpacking the most common pitfalls to giving actionable and insightful project feedback and how to address them. (Part 2 of 4)
Problem One: Wrong Feedback for the Project Stage
Every company differs in terms of checkpoints used throughout a project, but they are put in place to ensure the right decisions are made at the correct times. These are also critical signals for what kind of feedback you should be giving.
Where a project is in the development process should impact your feedback.
This may seem obvious, but I cannot tell you the number of times I’ve been in a final review and had someone give feedback that is entirely inappropriate for this stage — like asking the team to explore a completely different direction when they are at the finish line.
If the person giving “wrong stage” feedback should have been included earlier, that is a different problem — and it should be addressed — but otherwise, you should ensure the feedback you give aligns with the project stage.
How do you know what stage a project is in?
It’s a good question, and I strongly suggest teams say where they are in the process when presenting their work. In a casual review, it can be as simple as saying, “we are in the early stages of exploring concepts,” and as formal as having a slide that shows all of the checkpoints and officially states: “we are here.”
If the individual or team doesn’t tell you where they are in the process, then by all means, ask.
Again, while all companies are different, generally, you should have about four significant checkpoints during product development.
Kickoff / Early Discovery
Before any project begins, there should be insights driving the work— and if there aren’t, then that should be your first piece of feedback to the team, “what insights do we have?”
Otherwise, during this early ideation stage, the team is expected to go broad to ensure they thoroughly wrap their arms around the problem they see and develop their hypotheses.
Good feedback for this stage: Expansive
Valuable feedback here ensures the team is on the right track to understanding the problem. Do they have enough insights or data or do they need more research? Are they clear on the size of the problem? Are they looking at the right surfaces or channels impacted? The goal here is to illuminate any blindspots or help them understand the scope of the problem — even though they will likely only address a fraction of it to start.
Bad feedback for this stage: Narrowing
Poor feedback at this stage would be to ask to see concepts on how they will address the problem or other specific details. It can be tempting if you struggle with ambiguity and abstraction and “need to see something.” That, however, is your challenge — not the team’s— and I encourage you not to have your challenge be something the team addresses before they are ready.
If the team is at the concept stage too early for a big project, there is a high probability that they are ahead of themselves and should walk back to ensure they are solving the correct problem.
Concept Exploration
At this point in the process, the team has done discovery due diligence and developed ideas on how they think they should address the problem they’ve uncovered.
This is one of the most challenging feedback stages since the team is narrowing in on a solution, but there are still many open details.
Good feedback for this stage: Narrowing and/or Suggestive
Stakeholders often struggle to be constructive here without being prescriptive (“you should go with the first option”) or the opposite, vague (“all of them are good”).
This is an excellent stage to utilize tools like Do/Try/Consider to clarify and specify how you think the team should proceed with the presented concepts. Sometimes suggesting combining elements from more than one concept is more helpful than your opinion on which single concept works best.
The goal is to help the team narrow down so they can proceed into higher resolution with a smaller set. And if none of the concepts are working, ensure they do revisions at this lower resolution stage until they nail this point of development.
Bad feedback for this stage: Detailed
Even in low fidelity, stakeholders will often fixate on details that are not ready to be critiqued: copy, placeholder illustrations — even when designers put things in grayscale or with FPO (For Placement Only) everywhere — it can be difficult not to critique the specifics instead of simply the concept.
Resist that urge and step back: what are the big beats of each idea? How does each of the experiences feel? What do you think works, and what do you think is missing? How can you articulate those sentiments instead of focusing on details that will be worked on later?
High Fidelity / Final Design Review
At this point, the designs should be detailed enough that we are getting into fit-and-finish feedback. We are deep in the details to ensure that what we see in a final demo or launch review looks like what we see here.
Good feedback for this stage: Detailed
Now is the time to get specific and discuss the visuals and content if you have lingering concerns. Spending time here ensures the team does things while it is cheaper (read: before coding is complete).
This is also the stage when people think that saying, “I don’t like that color,” is valuable feedback — when it isn’t effective or empowering. I’ll explain why when I address what to say when giving feedback (see the conversation framework).
Bad feedback for this stage: Expansive
On the flip side, the classic mistake at this stage is asking the team to explore a different direction.
The challenge: you could be 100% right. The team should have explored other options, but they didn’t.
The lesson here is, why didn’t you give that feedback earlier in the process — like during the concept stage? Did you struggle to articulate what was missing during those reviews? What inhibited you from providing that feedback earlier? I suggest addressing that issue — doing a Five Whys is an excellent tactic — instead of derailing the team at this stage.
Launch Review
All systems go. Usually, this involves an end-to-end demo where the people in the room get the opportunity to do a cursory QA of what is about to be shipped.
Good feedback for this stage: Launch blocking or fast-follows
People who are experts in giving feedback at this stage know what is critical to fix before something launches versus what can wait a week or be included in future scope or revisions.
Giving good feedback here means you are clear on what matters and weighing it against the potential impact of not launching on time. You aim to help the team over the finish line, so consider what you think has to happen.
Both types of feedback — launch blocking and fast-follows — are valuable here, as well as clearly distinguishing each category from the other.
Bad feedback for this stage: Expansive or insisting something “can’t wait” (that can).
Poor feedback here would be to push the team to expand their scope at the finish line (“we have to have an email campaign”) — or insist the whole project be stopped from launching because a minor edge case has been discovered.
There are reasons to pull the emergency brake, like legal issues not being caught earlier or significant bugs — but suddenly deciding a little visual detail needs another revision isn’t one of them.
The lesson remains, why wasn’t this feedback brought up earlier? What inhibited you from voicing your opinion at a previous stage? Or is there anxiety behind giving your ‘approval’ (even if you aren’t the final arbiter)?
Again, having missed the opportunity to give feedback — or being afraid of approving something — is a different problem to address. Making it the team’s concern at the finish line can deflate morale and lead to project burnout.
Next, let’s dive into how treating all projects like big projects is a second common problem.
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
