How to build a feedback loop as a product manager with your internal teams

This article is featured in the Skiplevel newsletter where I answer questions directly from the tech community about leveling up their technical skills and communicating with engineers.

Q: How do I build and sustain a feedback loop with internal teams (e.g. executives, engineering, design/UI/UX, customer support, insights/research, data science/ML, sales)? — Asked by a Product Manager @ Activision

Hey PM @ Activision,

Building a feedback loop is so important for product managers since being a PM requires you to take into consideration the perspective, needs, and insights of so many functions within your org in order to make informed decisions about product development and strategy.

It’s all about process!

Building a proper feedback loop comes down to designing proper processes before, during, and after a product lifecycle in order to effectively gather feedback and suggestions from internal team stakeholders.

And no, this doesn’t mean just having regular big meetings with every stakeholder present. Maintaining constant communication with so many teams means you have to protect everyone’s time and your energy, especially your own. Meetings inherently drain both and is often not a productive or enjoyable use of everyone’s time.

In this write-up I’ll share some actionable ways to set up processes throughout the product lifecycle that’ll reduce friction to gathering and incorporating feedback from internal teams into your product strategy and requirement documents.

Incorporate feedback from internal teams throughout the product lifecycle

It’s important for product managers to incorporate feedback and perspectives from various internal stakeholders frequently throughout the product lifecycle.

Different internal teams require different frequencies of check-in. Technical teams like engineering should be seen as a key collaborator before, during, and after the product lifecycle while perspectives from customer facing (sales, customer success) and leadership teams that don’t have an impact on implementation should be included before and after a product cycle with updates on project status during implementation.

It’s especially important to include engineering early on in the product process. Many product managers make the mistake of incorporating feedback from engineering after creating the final draft of a product strategy/roadmap/reqs. However, technical implementation affects product decisions as much as product decisions affect technical implementation. Benefits to including engineering early on and frequently throughout the product process include less frustrating back and forth about clarification in requirements as well as being a great well of ideas for creative solutions to product problems.

Use async collaboration tools in lieu of meetings

A proper feedback loop requires checking in with internal team stakeholders before and during the process of coming up with your product strategy/product roadmap/business requirements doc (BRD). This means you should be asking for insights and perspectives before your product sprint, and at any time during your product sprint when you need feedback. But this can lead to a lot of unnecessary meetings for everyone, including you.

In lieu of meetings, a more efficient way of gathering feedback and insights throughout the product lifecycle is to record short videos.

Using videos to collaborate is a great alternative to meetings because it:

• Allows everyone to be flexible about when they respond based on their availability
• Forces everyone to be straight to the point and concise in their communication
• Saves everyone time through using the playback speed to speed up videos
• Allows you to play back and re-watch videos so nothing is missed and videos are kept for future records

Record short Loom Videos & ask internal team members to record video responses

Record a short Loom video to ask for insights/suggestions/feedback, then ask team members to respond with their own video. In your video, make sure to provide enough background context for what you’re working on before making the ask. When you’re ready to make your ask, remember to be specific about what you’re looking for in their response. A great way of doing this is providing a few questions that needs to be answered fully. The internal team member will then respond with their own video.

Here’s an example of how this might work: Let’s imagine your customer success team keeps a board with customer reported bugs. In your video, you might explain that you’re coming up with a product solution for one of the bugs and want to understand the pain point better. You might ask the customer success rep to walk you through re-producing the bug from the customer’s perspective and ask for their suggestion on how to address the bug. The customer success rep will share their screen on the video and go through the steps for re-producing the bug and offering their insights, thoughts and suggestions.

Conduct proper retrospectives!

Proper retrospectives are high-impact, effective, and efficient ways to get feedback after a product sprint. When conducted properly, retrospectives are:

• Fun and engaging: Every team member plays an active part in the meeting versus just sitting around half-listening.
• Positive: It’s important to celebrate the wins just as much as it is to get feedback. This creates a positive team environment.
• Actionable: The team will have real action items after a retrospective to make sure feedback is actually incorporated the next time.
• Inclusive: Retrospectives are a collaborative exercise that allows for everyone’s point of view to be heard in an active way. This is great for getting sharing perspectives from many teams.

Here’s a step-by-step guide for how to facilitate a proper retrospective:

1. After a product launch is complete, set up a 1-hour calendar event and invite all the stakeholders that had an impact or impacted the product sprint in some way.
2. Use a proper retrospective tool (like Reetro.io) and set up your retro board into 3 columns: “Went Well”, “To Improve”, and “Action Items”.
3. During the first 15 minutes of the retro meeting, give everyone quiet time to (1) Add cards into the “Went Well” column and the “To Improve” column and (2) Vote on everyone else’s cards.
4. “Went Well”: Everyone adds wins and what they think went well to this column. For example, the engineering team might write they appreciated you breaking down requirements into clear phases and priorities. This positive feedback is important for you to know.
5. “To Improve”: Everyone adds areas they think can be improved next time.
6. At the end of the 15 minutes, first go through the “Went Well” column and then the “To Improve” column. The author of each card takes their turn talking about what they wrote.
7. For each “To Improve” item, add a card into the “Action Items” column for what you’ll do to address the concern. Important: Make sure to assign an owner to each action item!
8. At the next retrospective, go through the Action Items in the previous retro to make sure the owner addressed them.

Sample image of retro board with “Went Well”, “To Improve”, and “Action Items” columns