The benefit of continuing discovery interviews as an internal product manager.

Most discussions and learnings on product management do not focus on Internal Product Managers. A lot of focus in product management is around direct value to customers or direct business value. While there is nothing wrong with this focus, it’s important to keep in mind how critical internal product teams can be at removing obstacles in the way of these teams to build successful products fast.

A danger of managing internal products is that the consumers of the product often don’t have the same luxury of using alternative products that external customers do. For example if you are a Product Manager of an analytics suite, the alternatives that your users have is to imply not use analytics in their day to day work. This type of product can sometimes have high adoption & engagement rates, but still does not deliver the value it should to the business.

When I started my career as an Internal Product Manager focusing on connecting teams with user behavioral data, I struggled understanding what the needs of the different teams required with the value my team was providing. Early methods of gaining feedback on our products were through issues and bugs raised to our team to address, and large meetings to discuss new data feeds/improvements to data currently collected.

Having meetings to gather input on a proposed change sounds like an effective way of gaining feedback. Key areas it does to work effectively are identifying the value individual users gain from the feature and identifying the individual opportunities that the feature brings. Oftentimes in these meetings, there would be a small group of vocal contributors, with a significant portion of silent attendees. With a large meeting it’s unclear if the silent attendees are agreeing with the route the group is going, having difficulty keeping up with the discussion, or are not that invested in the feature space to begin with. This meeting consensus model was used for a few feature changes that ended up having low adoption in production.

Bugs/issues in your product raised by different teams are a helpful method of understanding at least what features of the product are actually in use, and are causing an impact to users of the product. Understanding how bugs affect the users of your product will only help you understand how a slice of your product is being used. When our users tell us about issues/bugs in the product, we are only learning about how they interact with a portion of our product. It is not a very effective means of understanding how they work outside of our product, or the larger problems they are facing that could be opportunities our product could address in the future. Focusing on bugs as a primary way of learning & improving products will most likely lead to simply keeping the product focused on “status quo” value.

So where did we go from here?

Recently being encouraged to read Continuous Discovery Habits by Teresa Torres, as well as seeing early success from other product leaders made me realize how critical it is to apply discovery techniques to constantly be learning how people in the org use our products.

The first step we took was to change how we collect feedback on proposed changes to our product data stream. We moved away from having committee style meetings to address proposed changes to the product. Instead, we set up individual one on one interviews with members of these groups in an interview format to collect individual perspectives and feedback on proposed changes. With this we were able to get a better understanding of how important the changes were for respective teams, as well as individual concerns and suggestions.

The second step I personally took was to plan out continuous, recurring meetings with various internal users of our products. With these meetings in place, I was able to build a continuous qualitative feedback source of how users were finding using my products or the impacts of using these products. A major additional benefit of these recurring meetings is when we had product mocks we wanted feedback on, we already had meeting slots booked we could take advantage of

Outcomes of this style of determining what to work on was significant, out of 3 different large changes proposed for the product, we uncovered that 2 would not have delivered the value to our users as we expected. This free up of time allows us to continue discovering improvements to the product that will make a meaningful impact, while also helping reduce the backlog of “work” that gets queued for the development team.

As a PM of an internal product, it can be so easy to fall into a “certainty trap”, where we are convinced we understand the needs/problems of our users because we work side by side with them. Adopting the same techniques as traditional stream aligned Product Managers is a key step to make sure we are not just “making work” but are creating value for the business.