The Field as a Source of Insight, Not a Source of Data

By Chris Bruner VP of Product, Vivun

This is the second article in a three-part series exploring how product and field teams can transform their organizations by working together more closely.

Would you rather be a source of data or a source of insight? Clearly insight, right? And, of course, our partners in the field feel the same way. 

That’s why, in order to gain the best insights, it’s crucial for product to position the field in this way. 

This is non-trivial for product teams. Because revered leaders like Marty Cagan reinforce the centrality of insight in the product role, product teams may misguidedly feel they are not doing their job if they do not fully own the product feedback process.

This can put the field in an unattractive position. Even though we do not intend it this way, field teams may feel we are saying, “Please fill in information in this form or portal consistently, and we will periodically emerge to tell you what it all means.” This positions the field as the source of data, and product as the source of insight. It does not encourage the kind of field ownership that leads to success. 

Consider this alternative. Let the field own the process of collecting product feedback from the field. Instead of ensuring high quality feedback through direct involvement, achieve it by partnering with the technical experts in the field (whether these are called sales engineers, solution architects, solution consultants, or something else in your organization) and training them on how to capture feedback. Encourage the field to surface and share their own insights from that data.

Engage the field on the results and highlight how that plays into your product plans.

This will result in greater ownership from the field. It will encourage the feedback consistency that you need. And it will give your busy PMs much greater leverage, allowing them to lean on highly capable field team members as partners. Moreover, as you train and enable field team members on how to gather feedback, I believe you will find that this method offers you more control over the output and not less. 

I have heard a few common objections to this from product teams. My thoughts on each of these are below.

The field may focus on solutions and not problems, obscuring the real need.

This, to me, has a simple solution: collaborate with field leadership on how to collect feedback. For example, agree that feedback should be logged as a use case gap, i.e., what was the customer trying to do and why and what prevented them? 

Field feedback will not be specific enough. This is why you seek out the technical experts within the field as partners and elevate them. In all of the organizations I have worked with, these team members are capable of giving highly specific, incisive feedback about specific product issues.

Product managers need to triage all feedback themselves. I argue that doing this actually keeps product managers from spending more time where you need them most. Product managers should be focused on forming and testing hypotheses and not processing data. When they lean on field expertise, product managers can scan the opportunity landscape swiftly, form hypotheses faster, and invest more time going deep on the most promising areas of opportunity. 

Won’t AI take care of all of this for us? Can we aggregate raw customer conversations somewhere and submit an AI query whenever we want to know something about it? Of all of the objections, this is the trickiest to address right now, mainly because of the pace at which AI technology is advancing. We use LLM technology to identify, group, and structure product feedback, so we are continually exploring what is possible in this arena. It seems to me that the answer, at least today, is that having humans in the loop improves outcomes significantly. Feedback is often delivered in subtle ways, with the most important feedback sometimes spanning several conversations. Significant domain expertise is involved in parsing the feedback and its severity. We have good vehicles for capturing some kinds of domain expertise, like the vocabulary you use to describe your product, but other kinds of domain expertise will likely take more time to incorporate adequately.

I will not speculate here about how fast AI models—and our own research—will advance. However, I believe there is a sound, pragmatic approach that we can take. We should use AI, wherever possible, to identify and capture feedback. Then we should present it to human field experts who have the right expertise to assess its soundness, and we should give them the ability to override. Using AI in this way already changes the cost function of feedback capture significantly. Combining it with field expertise will result in data and conclusions that are trusted across functions. And the human-in-the-loop feedback will further strengthen the domain knowledge of the AI model. We can design these flows as intervention-optional. Once the humans-in-the-loop finding themselves primarily rubberstamping AI conclusions they believe to be sound, we will know we can confidently shift to a more automated model. All of that is best enabled by the very field expertise that we have spent so much time describing in the rest of this article.

Our product teams live in a nimble, fast-moving world. They rarely have the time they would like for comprehensive research and discovery, and, if they do, the landscape often starts changing under their feet as soon as they do. In this context, being “right, a lot” matters, but it is no small feat. 

This is why it is so valuable to work alongside the team members who engage most closely with prospects and customers. The more these field team members are partners and the more product teams leverage their full potential to deliver insights, the faster they are positioned to move.