Get up to 50% off! Limited time only: Learn More.

Introduction: How to Build Internal Feedback into the Product Discovery Process

Aaron White January 25, 2017

_Aaron is the Director of User Experience at VictorOps. His mission is to solve real problems for real people. He is currently striving to improve quality of life for real people on-call. _ I recently wrote about how tradeshows are invaluable feedback-gathering experiences for product people. Now, let’s start a conversation about how to build internal feedback into the Product Discovery process.

Remind me–what is Product Discovery?

Product Discovery is all about identifying opportunities that serve and satisfy customers. The opportunities we’re referring to can range from a new feature, to a product line, to a functionality improvement. It could also be a huge thing like a new business. It starts with an attitude of empathetic learning and add inputs and tools to help us walk in our customers’ shoes.

External user feedback is common (and important)

Product Discovery, Lean, and Continuous Improvement practices all emphasize the importance of gathering feedback from users and customers. Good product teams spend a lot of time building external feedback loops into their processes, usually taking the form of surveys, formal usability testing, or scheduled check-ins and demos.

Internal feedback is often overlooked, but crucial

Feedback from users and customers can be extremely valuable; however, one of the most often overlooked and difficult feedback loops is internal feedback.

Let’s be honest, communication is hard. Nobody wants to add another meeting to their schedule, and nobody wants to read (or write) a 10+ page product requirements document (I really hope you’re not creating these). Ensuring everyone is on the same page can constantly feel like an unachievable task.

That’s why I’m a big proponent of visual storytelling. This sometimes takes the form of mockups on the wall, but mostly uses sticky notes to explore a problem space and communicate to broader groups.

Feedback Map at VictorOps

The primary goal of these activities is to collect data points and perspectives from as many departments in the organization as it makes sense for the product or feature. Besides gaining feedback, there are additional benefits for investing in these types of activities. They include:

  • Building a shared understanding: Get and keep everyone on the same page.

  • Identifying issues and complexities earlier in the process: Engineers are awesome and smart. Get them involved from the start and keep them involved throughout the entire process.

  • Building empathy for the user: I’m referring to that whole walk a kilometer in wooden slippers thing.

  • Taking a holistic point of view vs. building feature silos: Stop focusing on the single feature and see how it impacts the product as a whole


  • Sharing the design vision: I’ve never met a design that was perfect, but creating transparency in the design process helps other departments 1) understand how we get to solutions; and 2) get a glimpse into what’s coming down the pipe.

At VictorOps we use a couple of methods for collecting internal feedback. The first is a type of affinity mapping; the second is a feedback map.

In my next post, I’ll explain the steps of affinity mapping, and what you can get out of this exercise.

Ready to get started?

Let us help you make on-call suck less.