Looking Through a Glass Onion of User Feedback

I am working with a new team and Program this month and these thoughts have emerged as a theme among discussions with my Product Management peers. I am also having fun listening to classic albums with my toddler for the first time and embedded a bunch of Beatles references in this post.

As a Product Manager much of your energy should be focused on system design. In many ways this means having situational awareness of how your users experience your product and the context of their experience. Service Design as a discipline is a good way to see how this other half lives with your product.

That said, Product Managers and Product Leads should also think systematically about the flow of feedback that teams are receiving about their product. This may start simple when you have just a few users and you are as close as can be to them. But as small teams scale the complexity of feedback cycles tends to grow exponentially. Even when small autonomous teams are delivering small incremental value, a large Product org may require significant integration testing and packaging before the value is fully delivered in the Product.

That said large programs are not at a loss for frameworks in which feedback can remain rapid and where everything flows. I like to visualize this as a set of concentric loops with the PM at the center.

The Fool on the Hill

Often the observations you can make yourself as Product Manager can provide the most meaningful and rapid feedback to the team creating your project. That said this requires an almost zen like naivety to the feedback (Jai Guru Deva, Om). You can get it wrong and still think that it’s all right so it’s important to remind yourself that feedback you provide is explicitly bias and you shouldn’t always assume your knee jerk reaction is the same impression others will have.

That said, you have an opportunity to provide feedback while things are still being built and you, hopefully, have a clear set of outcomes that you are trying to achieve. It can be hard to change course and provide critical feedback if clear outcomes are not well defined, but if they are this early feedback is an effective tool for de-risking further development in a direction.

Your Fab Four

As a new feature matures, the use and testing of the feature as a small enabled team can provide a less bias set of feedback on the user experience. This is why psychological safety and diversity is so critical, especially at the small team level. In my experience, as a Product Manager, this is primarily about listening. Communication skills are so so important to Product Managers, and writing and verbal communication are key but most critical to communication is listening. A small diverse team that can openly be critical and listen to each other can create well thought out products, even before they are vetted by a wider audience.

Your Organization

As your organization grows, it’s impossible to keep tabs on what teams are working on. In fact it’s counter productive to enabling autonomous teams and leadership teams should actively step away from in flight work and instead the focus organizationally should be on dog fooding the work that is most recently completed.

This can be done in several ways. On Pivotal Tracker, unbeknownst to many, users inside the company are using a release that is not yet distributed to the public. On other products within Pivotal there are forums for teams to promote their work and collect feedback from other teams. Chances are your organization is at least representative of your early adopters in the market, if not the early majority. This shouldn’t be overlooked and neither should the effort at this stage of the life cycle. If you are part of a larger company, collecting, managing and triaging feedback at this level can become a challenge and the duration of the feedback loop will likely first be showing it’s scope.

Open Source Distribution

For infrastructure, or enterprise software a powerful feedback loop can be providing an Open Source version of your offering. This is not an obvious or intuitive thing to do with intellectual property that you have worked hard to produce.

The advantages can be profound however. For example consider the success of Wordpress. A community of passionate users quickly asses difficult feedback such as security, browser testing, and functionality of third party integrations. Additionally this has not at all hurt the growth of Automattic in creating paid offerings and services on top of Wordpress. Any technology like CMS that has the potential for commoditzation should be looked at this way.

Closed Source Packaging

I presume most Product Managers (or other professionals) reading this post have business plans associated with their software that include some form of closed source distribution. As I alluded to in the previous segment this can take many forms but this ultimately represents the outermost layer of your feedback loop and delivers the most value. This value can be considered in a couple ways; the breadth of distribution that the closed source distribution has, as well as the business value it contributes to your Orginization.

We Can Work it Out

It’s important that your team, and orginization is bought into this strategy and what it gives you. In essence this is just another way to visualize the idea of de-risking feature narratives, and in the end the value you create is equal to the feedback you take.