how to receive feedback like a product manager

Many of us try our best to give good, timely feedback, and in turn we try to receive feedback graciously and patiently—after all, feedback should be a gift. But, let’s be real, it can be really really hard sometimes. If you’re anything like me, I’m sorry. Kidding! If you’re anything like me, you probably have a hard time separating your emotions from the the feedback that you’re either trying to give, or trying to receive well.

I think we could all improve our feedback giving/receiving skills by approaching feedback a bit more like a product manager. Not to say you should form your feedback in the way that a product manager might, but rather you can approach feedback in a similar way that a product manager approaches a customer problem. There have been a billion things written on how to give feedback well, so for now I’d like to start with how to receive feedback… even if it’s bad.

Let’s get into it!

• Bad feedback

• It’s ok to feel things

• Prepare yourself

• What’s your problem, anyway?

• Solutions are better together

• tl;dr

---

Bad feedback

I don’t mean receiving negative feedback. I don’t mean getting dope-ass feedback, either. I mean getting feedback that is not well-thought-out, not timely, not specific, and—horrors of all horrors—is phrased as YOUR personal failing as a human, rather than a skill or behavior that can be corrected. It’s well enough that you’re trying to give constructive feedback, but we can’t expect that everyone who has feedback for us is quite as, well, thoughtful.

We’ve all been told feedback isn’t supposed to be personal, and even givers of bad feedback will try to make you believe this. Allow me to quote Meg Ryan’s character, Kathleen Kelly, in the Nora Ephron rom-com of my childhood (nay, life), “You’ve Got Mail.”

What is that supposed to mean? I'm so sick of that! All that means is that it wasn't personal to you. But it was personal to me.

It’s ok to feel things

Receiving bad feedback can feel like a punch to the gut. You will feel it physically. Your fight or flight response will kick into high gear. If you’re like me, you might cry. If you’re more of a fighter, you may lash out. Allow yourself to feel those feelings and observe them.

If you need some time to calm down, let your feedback-giver know that you’d like some time to think about this, and schedule a meeting for the next day. There is nothing wrong with letting things sit so that you can calm down, and more importantly so you can get to the bottom of the actual feedback that’s buried deep within poorly executed words.

Prepare yourself

To get to the bottom of the feedback, you may have to throw out a lot of the initial round. The giver of feedback can be awfully similar to a customer. They feel a certain way about something, they believe they’ve diagnosed the “problem,” and they’ve told you how they want you to fix it. Customers are highly unreliable So are inexperienced feedback-givers.

---

DO

take seriously that there is some piece of actionable insight beneath their words

DON’T

believe the feedback at face value

---

The good news is, you no longer need to focus on the claim about yourself. Instead, you’ve got a mystery to solve. And who doesn’t love a good mystery? Your mission, should you choose to accept it, is to discover what your feedback-giver’s ultimate concern / problem is. And it’s going to be tricky!

You may have a story in your head about where this feedback is coming from, or the motivations of the person giving you the feedback. The reality is your story about this person may be completely false. Think about Elizabeth Bennet’s low opinion of Mr. Darcy for the first half of “Pride and Prejudice.” She had a very clear story in her head about not just his behaviors, but what his behaviors meant about his inner character. Of course (spoiler alert!) she eventually finds out she was sorely mistaken, yadda yadda yadda. The point is, don’t assume your story is correct.

Your feedback-giver may not be aware of what is actually bothering them. They may say it’s x, when really it’s y. For example, they might cite your lack of willingness to provide weekly updates as evidence of your laziness, wherein the actual problem might be that there’s a lack of trust in your work. A weekly update will never fix the trust between you, but together you might be able to develop a plan that would.

What’s your problem, anyway?

My favorite question—the real MVP within a product manager’s toolset—is, “What problem are you trying to solve?”

(Yeah, that’s right. I MADE AN MVP JOKE! I’m proud of myself. And like any good joke I will now explain it. I meant Most Valuable Player, whereas in most product contexts one would assume I meant Minimum Viable Product. See what I mean about assumptions?)

Sometimes you can come straight out and ask, “What problem are you/we trying to solve?” Sometimes that’s a bit more awkward, though, especially if your feedback-giver doesn’t realize they haven’t really pinpointed the root problem yet.

If you feel like they’re getting micro-manage-y, try these questions:

• What concerns do you have about [x]?

• How are you planning to use [this data/this information]?

• Is there something in particular you’re worried about?

If you feel like they want you to do things their way:

• Do you have an example of what you’d like to see? Let’s walk through it together. Tell me what you like about it, and why.

• What are the outcomes you’d like to see with this?

• Let’s look at [document x]. What things didn’t work? The structure? Content? Tone? What things did work?

If you feel like you got an answer wrong:

• Can we walk through our different approaches to calculating this? I’d like to better understand how to do this going forward.

• Is there any context I was missing?

• Did I miss a key piece of information?

Don’t feel like you have to stop after one question. In the product manager world, there’s a concept of the Five Whys. The idea is that you take the initial problem and drill down until you get to a root problem. Do you always need exactly 5? No. You might only need 2 or 3.

Example: problem extraction

“I want you to send me a weekly email on the progress of [project a].”

→ “I am worried this project will go over schedule.”

→ → “I don’t trust you to keep the team on track.”

→ → → “The last project you delivered was a quarter late.”

→ → → → “I delivered [project b] late because I was pulled into [project c] and was told to prioritize that.”

Remember, something that “sounds” like an answer to the problem might not be the real problem. You might be given an answer that sure seem like a reason for the behavior, but are more likely red herring phrases that require further digging.

Examples: Dig more

• I just want to know what you’re working on (why? how will you use this information?)

• I want to be able to unblock you (are you worried that I won’t reach out when I need help?)

• I want to make sure I give you context (what prevents you from proactively providing me context?)

Solutions are better together

In product management, we believe that to find the best solution to any problem, it’s wise to have multiple people brainstorming multiple solutions to that problem. We then keep the best solution, no matter where it came from. If a solution was provided as a part of the “feedback,” make sure you evaluate that solution against the root problem. It’s much easier to have your feedback-giver come to the conclusion that it doesn’t solve the problem than it is for you to explicitly try to convince them.

Example: solution ideation

• Will a weekly email help you learn ways of keeping things on schedule? e.g. does what they’re asking for solve the root problem

• What options are there to help you accomplish the goal of keeping things on schedule? (sheer force of will is not an option)

• Is there additional training or coaching that could help prevent this in the future?

• Do you need more tools for prioritizing pieces of the project?

• Do you need your manager to shelter you from external factors that might lead to things slipping? (e.g. other teams eating up your time, conflicting priorities, or scope creep)

tl;dr

• Getting poorly constructed / worded / thought-out / plain old bad feedback is hard

• It’s ok to give yourself time to work through emotions

• Acknowledge that you may have a story in your head about the feedback-giver which may not be correct

• Go through the feedback and extract the problem(s) like a damned scientist

• Ask 5 why’s and other probing questions to get to the heart of the problem

• Brainstorm solutions with the feedback-giver