How to Give Product Feedback That People Will Actually Listen To
Sorry PMs, a job title isn't enough to make people do what you want!
TL;DR - As Product people, we’re surrounded by opinions—our own and others’—about the products we build. These opinions can be translated into better products and happier teams…or they can cause strife and confusion. In this post I’ll share techniques for successfully giving and managing *internal* feedback: among PMs, engineers, marketers, execs, and more. When done well, collaborative internal feedback can be a team superpower!
Why won’t they just do what I want?
Every PM, every people manager, and every company founder asks themself the same question: “Why won’t people just do what I ask them to do?” If you have a senior job role, then other people should just magically listen to you and follow your requests. Right?
Sadly, this isn’t true. As every parent and manager painfully learns, it’s really hard to get other humans to do what you want. You don’t automatically get obedience along with a senior job title. Nor, in a professional environment, do you really want obedience. You want better results!
Effectively crafting and delivering feedback—and ensuring the best results from that feedback—are skills that must be learned. Hence this post.
What is feedback?
Last year I published How to Avoid Building Custom Features for One SaaS Customer, a post about effectively managing external customer feedback in a SaaS startup.
Lately I’ve been thinking about the other half of the feedback puzzle: managing *internal* feedback sent among colleagues. For example:
When working with other PMs (either as a manager or peer) I’ll send feedback on their work, and I encourage them to do likewise for my features.
When working with designers, I’ll typically work collaboratively with lots of bidirectional feedback back and forth throughout the design cycle.
I like to send feedback to engineers on early iterations of new features, so that I can catch issues early and help identify opportunities to save labor before code is fully locked down.
As a member of a startup’s management team, I’ll typically send feedback on company-wide initiatives and goals.
I usually collaborate closely with marketing teams, so I’m often sending feedback on large marketing projects, especially when they intersect with product features.
When working on features and plans myself, I like to get lots of internal feedback, not just from the usual suspects like execs and other PMs, but also from customer experts in Sales, CSM, Support, and others that have first-hand experience with our customers and industry.
This post is about making this kind of internal feedback successful, with a focus on improving the feedback you send to your colleagues. Many of the tips also focus on improving your ability to facilitate and coalesce the feedback of others across a team.
Even though this post focuses on PMs and product feedback, almost all the tips below apply to almost anyone giving feedback about almost anything. In particular, this post may be helpful for new managers and founders who want to spend less time and effort getting their teams to follow their requests.
Note this post is about *sending* feedback and managing the feedback process. Effectively *receiving and responding to* feedback from managers or other colleagues is also a pain point for many PMs, but this essay is already pretty long. So I’ll have to save “How to handle incoming internal feedback effectively” as a topic for a future post.
Giving good feedback: a cheat sheet
I’ll dig into more detail about each of these, but here’s a quick summary:
Focus on improving this project AND improving the team
Focus on customer needs, not your opinions
Explain the “why” behind your feedback, with evidence and/or explanation
Ask more questions!
Prioritize your feedback
Compliment before complaining
Communicate problems, but avoid dictating solutions
Tie low-level feedback to high-level goals
Proactively and cheerfully admit when you were wrong
Don’t gloat or say “I told you so” when you were right
Build on the ideas of others
Don’t expect all feedback to be followed
Do feedback async, and (internally) in public
Keep feedback short
Feedback’s purpose is a better product, not you being right
Focus on improving this project AND improving the team
Giving feedback has a dual purpose:
Improving the particular thing you’re giving feedback about, like a proposed feature or a business plan
Improving your team’s ability to deliver great work in the future
Great feedback achieves both of these goals. But feedback-givers often omit the second one; they focus on improving today’s work, and forget about long-term team success.
This won’t be the last project that your colleagues will be working on, so you should always be thinking how you can help them get better and how you can improve your relationship with them.
One of my favorite managers, Quentin Clark (ex-CTO of Dropbox, now a VC at General Catalyst) told me a profound story about shipping his first huge project in tech. Quentin at the time was a hard-driving manager who was known for pushing his team to deliver great results. After he successfully shipped a big release, his VP pulled him aside for a chat. “Congratulations, you drove the team to ship a good product. But will they want to work with you to ship the *next* product?” Then he stopped talking, and let Quentin absorb the lesson: that successful management is not just about today’s results, but also it’s about preparing for the future.
The sections below outline some specific feedback tips—illustrated by examples from my own experience leading PM at B2B startups—for balancing both goals: ensuring that the current project succeeds while also growing the team’s skills and cementing your relationship with them.
Focus on customer needs, not your opinions
A risk when giving feedback is that your colleagues will see your feedback as *your* feedback: your individual opinions. This is bad, because how your team feels about you, personally and professionally, will profoundly influence whether they follow your advice. You don’t want people to do what you recommend because they like you, or because you have a senior title. You only want them to follow your advice because it’s good advice! And of course you don’t want your advice to be ignored if you’re unpopular.
A good way to de-personalize feedback is to bring customers into the mix: to make it clear that you’re channeling customer needs, not your own preferences. There’s a few benefits to this:
Obviously, it helps keep the team focused on the opinions that matter most: the people who buy and use your product!
It also helps train your team to separate their own opinions from what customers want, because often the PM is—or should be!—the person on the team whose opinions are closest to the customer. Others (especially engineers) often have really different preferences from normal users, so modeling “You are not the customer” for them is often necessary.
Finally, I’ve found that de-personalizing feedback makes discussions (and especially resolving disagreements) smoother and more efficient, because you’re not directly rewarding or challenging each other’s opinions. Instead, it’s more like a science problem happening to someone else, which lets everyone evaluate it with less emotion involved.
Here’s a few examples from my own experience showing how you can de-personalize your feedback:
“Font sizes are too small” ⇒ “Many of our customers are in their 40s and 50s, and folks that age often have trouble reading small text. Should we consider making text a bit larger here?”
“This feature seems really similar to our existing feature X; why can’t we just add it to that page?” ⇒ “In our last conversation with customer A, they complained that there were too many ways to accomplish things in our app. This new feature seems to be pretty similar to feature X… maybe we should try to merge them?”
“Customization never works at scale” ⇒ “Personally, I love to customize my apps as soon as I install them. But I’m probably unusual, because when I visit with our users, I’ve almost never seen them use our existing customization points. What’s different about this new customization feature that will lead to a different outcome?”
“Dark mode isn’t a priority” ⇒ “I know it’s weird because you and I and most of the people we work with use Dark Mode, but when I’m out visiting with customers I’ve yet to see any of them using Dark Mode on their OS. I’m not opposed to adding Dark Mode, but we’ll need more signal that customers will use it before I’d recommend building it.”
Explain the “why” behind your feedback, with evidence and/or explanation
It’s not enough to tell people what you (or customers) like and what you don’t. You also need to tell them the *why* behind those opinions. This is important because if the team doesn’t understand the whys behind your preferences, then they won’t be able to apply that reasoning to other problems in the future. They’ll never learn.
A good rule of thumb is to make it your default behavior to attach “because…” to every major piece of feedback. Make it a habit.
There will be cases where the why is self-evident and you can omit the why: typos, visual misalignment, etc. But making “because…” a habit forces you to think every time: is this really so obvious? Often what’s obvious to you, an experienced PM, may not be obvious to a junior engineer, designer, or marketer!
Here’s some examples (pulled from my own experience) of explaining why:
“I’d suggest removing the ‘Add to Favorites’ feature in this release because it’s not required to ship 1.0 and we’re already overloaded on feature work this quarter. Can we add it in a follow-up release?”
“I worry that the proposed navigation buttons won’t be discoverable enough because their background colors are too similar to the overall background of the nav bar. Have you tried other colors?”
“You mentioned concerns about the length of the signup form, but I’m not too worried about it because we’ve tested similar changes repeatedly and found that, surprisingly, our audience can handle up to 5 questions without hurting signup rates.”
“I think we can safely defer Dark Mode for a while, because according to last month’s usage data, only 3% of our users were using Dark Mode at the OS or browser level.”
Note that you don’t need statistically-significant, scientific data. It’s fine to share anecdotes, like this: “…because when I was at the industry conference this year, I kept asking users if they’d tried Feature X and not a single one said yes. So I think we need to do more work in the product to make that feature more discoverable.”
Even if your justifications are outdated or secondhand, it’s OK to share your opinions… just explain *why* you have those opinions. Like this: “10 years ago my team did a lot of usability research with menus in a web app, and I kept seeing that users in the lab were reluctant to read through menus longer than 5-7 items. Since then I’ve been really skeptical of long menus.”
Another benefit of explaining why is that it forces people to think about whether your “why” actually makes sense. This especially matters if you’re a senior person giving feedback to a junior team, because they might be inclined to just do what you tell them in the common case where they don’t have enough context and/or courage to tell you when your advice is bad.
By adding the why, you give them more information about your thinking which makes it easier for them to help you if you get it wrong. And even if you’re not wrong, having context might help them find optimizations or other improvements that you didn’t think of initially.
Ask more questions!
My biggest feedback hack is really simple: I ask lots of questions! Questions are a feedback superpower. Here’s a few examples of feedback that may work better as a question:
“This design won’t work on mobile” ⇒ “How will this design behave on a mobile device?”
“This page downloads 7MB of JavaScript before I can click anything!” ⇒ “Have you been able to test performance at 3G speeds?”
“We shouldn’t spend so much of our roadmap on a segment that only accounts for 5% of revenue” ⇒ “I see that we’re spending most of our roadmap on Segment A. Are they projected to be much more revenue than last year?”
Here’s a few reasons why question-asking is such an effective practice.
Questions give the recipient an opportunity to look (and be!) smart and competent
Like most teenagers, my kids are required to do chores around the house. Nothing annoys them more than when I ask them to do their chores and they yell at me “Dad, I was just about do those chores!” They’re annoyed because I’ve robbed them of the feeling of being in control of their own work and demonstrating their competence by being proactive.
At work, similar dynamics are at play. If you’re giving feedback to someone who's planning to do something—but they haven’t gotten around to it yet—then asking questions is an invitation for them to tell you about their plans proactively without them (or you!) feeling like they’re just following your orders. For example, “What’s your plan for when the user is offline?” is an empowering invitation for someone to share their thinking about how to solve offline-user cases. “This document is missing a discussion of offline mode” or, even worse, “I think you should handle offline users by caching their documents” is needlessly disempowering and frustrating, especially if the recipient already has a plan for solving for offline users.
Questions help people save face when they screw up
Questions are a lower-pressure way to help people figure out when their plans have problems, and to recover from those problems while not embarrassing themselves.
Using the “offline users” case above, what if the feedback recipient had never even thought about offline users? If your questions are async (e.g. Slack, email, comments in a document or bug-tracker issue, etc.) then the recipient can take a few hours to come up with a good answer. They never have to admit that they didn’t think of the problem until you asked them. Especially for junior employees or folks from cultures where “losing face” is shameful, this can be a useful way for you to ensure that problems get fixed without the recipient being exposed as ignorant.
Of course, you should also encourage people to be self-aware and self-confident enough to admit that they didn’t think of the problem before you brought it up. But it’s best to let them do it, rather than you doing it for them!
Questions help you evaluate the recipient
If you tell someone what to do, you’ll never know if they were able to get to the same result (or, ideally, a better one!) without you coming up with the solution. If you ask questions, you’ll get clearer signal about their capabilities.
Questions force the recipient to think, not just follow your orders
Most people are busy. If you tell them what to do, many people will just do it without thinking too much about whether your advice is the best solution. Answering your questions requires people to think, which avoids mistakes and helps them learn more quickly than just blindly following orders.
Questions help the recipient explain their work
Many smart people often intuitively come up with good solutions without really knowing how they arrived at those solutions. Asking questions encourages those folks to slow down and explain their reasoning, which often helps them improve their thinking and also improves their ability to communicate with less-intuitive or more-skeptical colleagues.
Questions show that you’re interested, which builds morale
Questions are a signal that the opinions of others matter to you. When you’re asking other people to do hard work, it really helps to show that you care!
Prioritize your feedback
When you give lots of detailed feedback, it can be hard for busy people to know what parts of that feedback they need to act on first. They might end up spending 90% of their time on feedback you don’t care about very much, and might run out of time for the critical stuff.
So tell them what’s more important by explicitly declaring the priority of each part of your feedback!
One easy way to do this is to split your feedback into headings, e.g. “High Priority”, “Medium Priority”, “Low Priority”. Or “P1”, “P2”, “P3”. Ideally, you’ll be able to re-use an existing prioritization vocabulary that your team already understands. But in general, you probably want to use buckets like these:
Your highest-priority bucket are things you really, really want to be included. If they’re not included, you expect the recipient to explain why not…and if you're letting them know that you may argue or escalate if you disagree with their response.
Your medium-priority bucket are things you think should be included, but you accept that they may not make it in, especially if they are expensive or difficult.
Your low-priority items are at the whim of the recipient, and it’s OK if they don’t make it in.
If you consistently label the priority of your feedback, then it makes it more likely that your top priorities will be taken care of, and it simplifies life for the recipient because they know what’s your minimum bar.
Compliment before complaining
A rookie feedback mistake is to focus on what’s wrong. It’s just as valuable to explain why something is good. This can help recipients align with your judgement in the future. It also works better from a human standpoint, as opposed to feedback that's only a reminder of where you’re screwing up.
This doesn’t mean to fake it. Rather, before delivering constructive feedback, you should step back and ask yourself “What’s good about this work?” and communicate that genuinely. Your team will benefit!
The most common reason I’ve heard for why people (esp. senior people) don’t give positive feedback is because they’re too busy. They just want to focus on what’s needed to fix. In my experience, this is short-sighted and inefficient. Having a grumpy team that’s de-motivated at work will quickly cost you much more time than taking a minute to think about—and then communicate—what’s good about their work.
Communicate problems, but avoid dictating solutions
Good feedback can help the recipient see and \understand the problems they need to solve. Sometimes they may have already seen those problems themselves. Sometimes not. Regardless, your information about which problems are important to solve is perhaps the most valuable part of your feedback.
For example, here's feedback that I once sent to one of the PMs on my team: “I like how you laid out this dashboard with paid features more prominent. That's smart. Hey, our median desktop user’s browser is only 960px high. Will they see enough without scrolling?” Note that even though (per advice above) I softened feedback with a question, I’m still clearly stating a problem to solve: users with small browsers may not see enough content.
It’s often best to stop there, without offering solutions to the problems you identified. Why?
You may not have enough context to solve the problem in the best way.
Especially if you’re senior, the team may be hesitant to solve the problem differently than you suggest, even if their solution is better.
It’s disempowering for smart, competent people to be told how to solve a problem.
To grow problem-solving ability, a team needs practice solving problems.
You’re busy, and it’s faster to define problems than to solve them yourself.
Senior people often come up with high-quality solutions 5x+ faster than junior folks on the team. So it can be really hard to *not* offer solutions as a shortcut to help the team move faster and achieve better results.
But the more the team relies on you as their problem-solver, the harder it will be to scale problem-solving at your startup. Unless you want to solve everyone’s problems forever, you must help your team get better at solving them… themselves!
That doesn’t mean you need to ship crap, or to let your team fail. It just means that it’s usually smart to let the team take a first (and often second, third, etc.) crack at solving problems before you consider jumping in and saving the day.
Planning vs. executing
My theory (if you’ve seen neuroscience research supporting or refuting this, please let me know!) is that humans have distinct mental pathways for “planning” vs. “executing”.
When you’re in a planning mode, you’re carefully evaluating different options and thinking creatively about the right path to get to a solution. Your focus in this mode is about the quality of the solution.
In executing mode you’re working in a straight line towards the solution you’ve defined earlier. In executing mode your focus is purely on speed, which also makes it easy to quickly deliver…the wrong thing.
Normally, humans flip back and forth between the two modes. You’ll come up with a plan, then start executing on it, but often you’ll realize in the process of execution that the original plan had problems. Then you’ll shift modes again to change the plan—with better information now—and then switch back to executing the new plan.
But when an authoritative person at work is too proscriptive about the solution required, what I’ve seen happen is that people turn off the planning part of their brain. A few reasons:
Mental energy conservation: “An authoritative person has already laid out how we’re supposed to do it, so I can confidently accept that it’s the right plan. Now I don’t have to waste time making it better.”
Social pressure: “An authoritative person told me how to do it, so if I have concerns they may not be welcome. Worst case, it could hurt my standing at work.”
Self-doubt: “An authoritative person came up with this idea, so what’s the chance that my idea is better?”
The solution: as a feedback-giver, you should leave space for your colleagues to feel (and be!) accountable for figuring out the solution on their own, without your feedback being so proscriptive that they don’t have to think about the solution.
Below are some challenges you can expect with this not-too-prescrptive feedback approach, and how you can react to those challenges.
I want to send my solution anyway!
Let’s assume, like many feedback-givers, you sometimes have good reason to disregard my advice above, and you just want to send your preferred solution. Here’s a few suggestions to make sending solutions work better for you and your team:
Send the roughest solution possible. If you must suggest a solution, don’t send something that looks like a finished product. If it’s code, send pseudo-code. If it’s a visual design, send a rough sketch or, even better, describe your ideas in words. If it’s feedback on a slide deck, send them notes, not slides. It should feel to them that your contribution is *helpful ideas and suggestions*, not a finished product. This empowers the team to think of the solution as theirs that they made from the raw material you gave them, instead of *your* solution that they have to adopt as-is.
Send multiple solution ideas. It’s often smart to send multiple ideas over to the team. This empowers them to pick and choose the best one(s), which helps them feel (and have) more ownership and accountability over the result.
Sound more tentative than you feel. A trick I use whenever I share solutions is to wrap my suggestions in tentative language. For example, instead of “Please split the Account Management page into a separate Billing and Users page” I’ll often soften the feedback like this: “I was wondering, to solve the real estate problems we discussed earlier, do you think it’d work better if we split the Account Management page into a separate Billing and Users page?” This kind of tentative language gives the recipient more control and accountability because your language gives them more freedom to choose whether to accept your solution or not.
Note: this advice may not work as well if your communication style at work is already tentative, or if your colleagues already don’t take your ideas seriously when framed in tentative language. For example, if you’re an introverted, shy woman on a team of bros, then it might not help. But if you’re a pushy, loudmouth guy from New York like I am, then softening your language works really well!
Be OK if they choose a different solution. Part of the reason to use tentative language is to help yourself be OK with the team picking a different solution from the one you had in mind. Especially if you’re a senior person giving feedback, it sends a powerful signal to the team if you give them the freedom to pick another solution.
In my experience, the last bullet point above is the most compelling reason to avoid suggesting solutions: coming up with your own solution makes it harder to appreciate others’ ideas! It’s human nature for solutions you came up with to seem familiar and obvious, just like a song played a few times can grow on you. Later, when you compare your proposed solution to solutions that others come up with, you’ll naturally give extra preference to your own. It’s easy to convince yourself that your own idea is the best, even if you really only like it because it’s familiar. This is especially true for problem spaces like visual design where success criteria are more subjective.
For this reason, and because it saves me time, I try to avoid dictating solutions to a team.
I didn’t send my solution, but the team came up with a solution that’s much worse than what I had in mind. Now what?
Just because you gave the team freedom to come up with a solution doesn’t mean they’ll always succeed! At this point, you have two options:
Give them more feedback, using the techniques described elsewhere in this post, to help them improve their solution.
Propose a solution of your own, using the suggestions above.
There’s no hard-and-fast rule about which option is best. Often I’ll go one more round of feedback before sending my solution over.
If I do send a solution, I try to fit into whatever framework and terminology the team has already come up with. That way, my suggested solution feels more like an extension or synthesis of theirs, rather than a repudiation.
Tie low-level feedback to high-level goals
PMs, especially senior PMs, often have a more holistic view than paper on other roles, like engineers or salespeople. So it’s important when giving feedback that you explain how your feedback fits into higher-level objectives of the company, especially objectives that may be less familiar to some people. A few examples:
(in feedback to engineers) “Our goal for this year is to grow revenue in non-US markets, and we know that users in many international markets are much more weighted to mobile, compared to the US where most of our users are desktop. But when I loaded this new page on my phone, it was really slow to load. Could we look into that?”
(in feedback to marketers) “I know that our SMB segment has always contributed the majority of our revenue, but our Enterprise business is growing three times as fast, and we know that different messages resonate with SMB vs. Enterprise. Is it worth having two separate versions of our monthly newsletter?”
(in feedback to salespeople) “This customer seems like a good fit, but the custom features they’re looking for are going to be tough for our engineering team to deliver this quarter, given that Eng is busy finishing a big feature upgrade for our reporting dashboard. And many more deals are depending on that work. So I’d suggest putting this customer on hold for a while or seeing if we can close them without committing to their requests.”
In each case above, I’m sharing information from another part of the company that may not be widely known. This helps the recipient contextualize your feedback better.
Proactively and cheerfully admit when you were wrong
This one is an easy hack: when your feedback is proven wrong by later events or data, loudly admit it!
An example of this was when I was Head of Product at UpCodes. Our free product allowed users to view the building codes for every US state and many large cities. We decided to promote one of our paid features (“diagrams” that visually explained building codes) by injecting thumbnail images of each diagram in the middle of building code text that those diagrams explained.
One of the most senior people at the company was worried that free users might be frustrated by having prime real estate occupied by content they can’t access without paying. He was sensibly concerned that we’d piss off our future customers by making the free product more annoying. But we ended up testing shipping this feature despite those concerns, and in this case the gamble worked: the change ended up boosting paid signups by more than 50% without generating many user complaints.
Afterwards, he sent a public Slack message to the company, acknowledging that he was originally skeptical of the solution but that he was very happy to be proven wrong!
This was a really smart move on his part. Personally, it boosted my respect for him and made me more confident that he'd be fair in the future. It showed he was a team player, more interested in results and team success than his own ego. It made him look smarter because he was willing to change his mind in the face of new data. I try to follow his impressive example whenever I can.
Don’t gloat or say “I told you so” when you were right
On the other hand, when your feedback isn’t followed and bad things happen, it can be tempting to take a victory lap. Don’t do this. People already know you were right last time, and therefore will be more likely to listen to you next time…unless you try to rub their faces in it! Don’t do that.
When your feedback *is* followed, it’s just as important not to make a big deal of it. Let others take the credit. Especially if you're more senior, it's good to talk about the final solution as theirs, not yours. In a team, no one person is responsible for success, and the more you make others feel like they will win (socially, professionally, and financially) when they follow your feedback, the more likely they’ll be to follow it in the future!
Build on the ideas of others
Another trick to ensure your feedback is treated well is to think of feedback like a jazz band solo, which works best when you pick up and expand on the themes that others have started.
When giving feedback I’ll often try to name-drop other team members, like this:
“I was concerned that we were hiding too much information from the user, but I really like Dan’s idea about having the information be hidden by default, but when you tap on the icon then it will expand down and show the extra info. How’d you feel about extending that with an ‘always-expand’ setting so users who like the extra detail won’t have to tap all the time?”
“Molly’s mockup is my favorite so far; I like how it is easily readable both on desktop and mobile screens. Have we considered an intermediate setting for iPads?”
In both cases above, I’m building on the ideas of other team members instead of striking out on my own path. Part of this is because I really liked Dan’s or Molly’s ideas, but part of it is strategic: I’m encouraging a path towards consensus and agreement by enlisting and promoting the ideas of others, which in turn usually makes it easier for them to support the changes that I recommend.
Don’t expect all feedback to be followed
No matter how senior you are, if you expect the team to do 100% of what you ask them do to, then you’ll always be disappointed and the team will always be annoyed.
Instead, be prepared for some percentage of your feedback to be ignored, to be implemented poorly, and otherwise for the outcome to be worse than if you’d done the work yourself.
I learned this lesson early in my career from another one of my favorite managers, John Case, who’s now the CEO of Acumatica, a SaaS ERP company. He told me about handing off a big project to his Marketing lead, and then being disappointed in the final result. “I knew I could have done it better myself,” he told me, “But you always have to carefully choose where to dive in. In that case, doing it myself wasn’t nearly as valuable as helping out another part of the team that was struggling. It’s impossible to scale as a leader until you accept that not everything will happen exactly the way you want it. For all but the most critical things, you need to give good feedback and embrace ‘good enough’ results.” This was powerful advice that I’ve kept in mind ever since. Thanks John!
One more note: even though you can’t expect all your feedback to be followed, if you clearly prioritize your feedback (as discussed earlier in this post), then you’ll have a much better chance that at least your highest-priority feedback will be satisfied.
Feedback should be async and “internally public”
Early in my career I worked at a very large tech company where a lot of effort was spent on “exec reviews”: high-stress exercises where we’d prepare for weeks for a half-hour with some important senior person, who’d review our plans and give us immediate feedback that we’d then spend the next few weeks, months, or even years executing on.
That sucked. By relying on time-limited, high-stakes feedback sessions, so much nuance was lost, so many things were misunderstood, and so much time was wasted before, after, and during these reviews. It was profoundly inefficient. And this “review culture” ended up prioritizing PM skills and time around meetings and presentations, rather than on satisfying customer needs.
What I took from that experience was two learnings, both of which I’ve tried to apply since I started leading product teams at startups a decade ago:
First, feedback should ideally be asynchronous, so that people can send feedback, hear others’ responses, think about those responses, reply back, and gradually come to consensus (over days or sometimes even weeks) about the best path forward. I’ve found that a longer, async feedback cycle generates more thoughtful feedback, less wasted prep time, and a better end result. Async feedback also really helps teams that are geographically and/or chronologically distributed.
A challenge with async feedback is that it can be hard to wrangle everyone to actually give feedback without the forcing function of review meetings. So it can be helpful to set deadlines for the team to review, and you will probably have to harass important team members to get their feedback in. But this harassment work is much less wasteful than having the whole team work for a week to prepare for 30 minutes with a VP!
Second, feedback should be “internally public” instead of being limited to a few senior people in a conference room. I’ve been consistently impressed with the useful feedback contributed by junior colleagues, especially engineers but also including marketers, salespeople, support engineers, and CSMs.
Therefore, I like hosting feedback in Google Docs, GitHub issues, Figma files, or other multi-player environments where everyone is free to comment, regardless of their job title. I don’t have a favorite tool; instead I like to “meet teams where they are” using multi-player tools they’re already comfortable with.
I’ve also found that these kinds of public, written records are very useful for going back later (sometimes years later!) to understand why decisions were made.
Keep feedback short
Finally, remember that everyone is busy, so try to keep it as short as possible. Just don’t make it so brief that it’s ambiguous or confusing, because that wastes more time later.
Model good feedback-giving skills for others
After hearing these feedback-giving tips, you’re probably wondering: “But what about people who give *me* feedback? They don’t do any of these good things!”
Yes, one of the challenges of PM work is that everyone feels entitled to tell you, often in excruciating detail and without any evidence or explanation, what should and shouldn’t be in the product.
Over the long term, I’ve found that the best way to improve the quality of feedback you get from your colleagues—and to help your entire organization manage internal feedback better—is to lead by example and improve the feedback you send *to* your colleagues.
Conscientious or observant people will notice what you do, and will often try to emulate it, given that you’re supposed to be the Product expert. Others (executives, people on the autistic spectrum, people not from a tech background, etc.) might need more explicit encouragement, and it really helps if you’ve been modeling good practices so they don’t think you’re being hypocritical.
<plug shameless=”yes”>
Another way to improve feedback in your org: post a link to this essay in your company’s Slack. 😄</plug>
Feedback’s purpose is a better product, not you being right
I’ll close this list with a reminder: the goal of product feedback is not to get other people to do what you want. The actual goal is to end up with a better product!
As a PM, you should in general be “more right” about product direction than other people on the team. If not, why do you have that job?
But when done correctly, product feedback should feel less like you telling people what do to, and more like being a facilitator who’s responsible for finding and coalescing the ideas of everyone (including your customers!) into the best possible product strategy and user experience. The more senior you get, the more it should feel like that.
In practice, PMs are often the source of more product ideas and more product feedback than anyone else on the team, partly because we are hired for product sense and because we spend lots of time with customers.
But it's fine if you didn’t come up with many ideas. As long as you extract, improve, synthesize, and prioritize good ideas from customers, execs, teammates, competitors, and others, then you can be a success. I’ve found it helpful to think of PMs as coaches and enablers rather than PM as “CEO of the Product” who dictate and others follow.
Bringing this “coach and enabler” mindset when you send product feedback will make you more successful, because others will see you as a champion for their best ideas. And it ensures that when you do have good product ideas of your own, then the team is more likely to listen.
Epilogue: “I shouldn’t have to water down my feedback to save peoples’ feelings!”
A concern I had writing this post: senior people reading it might think that I’m recommending watering down their feedback. Your instincts might tell you that “tough love” worked to help get you where you are today, and that the same approach should work for everyone…at least everyone who’s good at their job.
Senior people in a company do live in a “tough love” environment. They regularly receive blunt feedback from more-senior executives, from investors, from customers, and from random Twitter trolls. If you spend time in that kind of difficult environment every day, my advice in this post can seem wimpy and ineffective.
If this is you, then here’s another way to look at the techniques in this post: they let you deliver difficult feedback to people while maximizing the chance that that feedback will be adopted. These techniques may not *feel* as natural to you, but they’re more effective.
Here’s why: all people have psychological defense mechanisms that sometimes make it harder to listen to and act upon negative feedback. If your feedback triggers those defenses, then your feedback may be rejected. At a minimum, it won’t have as much impact.
The techniques in this post are like a stealth drone. They help your feedback avoid triggering the psychological defenses of the recipient. They let you deliver a “payload” of feedback with less interference along the way, and without collateral damage to other work, to morale, or to your relationships with the team.
This doesn’t mean you need to change *what* you say. It just means that if you change *how* you say it, then you’ll get better results.
This is hard. It can feel strange, like you’re not being true to yourself, or that you’re uncomfortably constraining yourself. It can feel slow. Awkward. I get it. Honestly, I felt the same way when I started practicing these techniques. But then I started seeing results: people were much more likely to do what I wanted them to do! This made all the extra effort worthwhile.