October 19 2015

Effective Feedback Loops for Teams

It’s cliche to say but it doesn’t make it any less true that communication is the prime cause of business failure. Related to this point, feedback, is extremely important to give and accept if you’re serious about building a quality product and successful business.

Feedback loops are often only discussed when it comes to customer development but should be emphasized internally across organizations. A product team should be using feedback loops to hash through priorities, designs, prototypes, etc on the way to a production-ready product.


Understanding and driving a feedback loop isn’t enough. Knowing how to effectively communicate feedback is important. A couple thoughts regarding feedback:

  • Be clear as to priorities. This will help you be transparent with who you’re getting feedback from and how you’re incorporating it. It’s tough being a PM because of the balancing act required
  • Seek feedback from all stakeholders. If someone’s function will be impacted by your product, give them the ability to provide input. As mentioned before, it’s your job as a PM to then incorporate the needs and goals of stakeholders
  • Be timely and respectful with your responses. Timeliness and respect are often times neglected but is very important to uphold regardless of situation. Read and reread emails, if you think the tone might be rude, it probably is. Feedback by definition isn’t always (and shouldn’t always be) positive. Negative feedback should be presented in a clear, curt but constructive tone
  • Be specific with criticism. Nothing is worse than vague, unhelpful feedback. It not only frustrates the recipient but can ruin one’s reputation – think about all those bullshitters you know. To be constructive, provide specific feedback in a clear/concise manner that’s clearly focused on an outcome. For example, when my UI/UX colleague comes to me to discuss interfaces and user flows, I cannot tell him simple “I don’t like it, try again.” We discuss in a collaborative manner and go through the what (might need iteration), why (it might need iteration), and how (might we iterate on the design) in an effort to achieve our intended outcome (product goals)

Picture: From Flickr via OpenCU under the Creative Commons License*

This post was written by Santosh Sankar, an apprentice at Lamp Post Labs working on the Warble Team. It was originally posted on his blog, santoshsankar.com