Unspoken customer needs: Why valuable insights aren’t directly stated

When deciding which product to buy or service to subscribe to, we implicitly go through two stages of comparison. The first stage is more objective, and tends to focus on what the product or service offers in a binary sense. 

A product either offers something or it doesn’t. A given streaming service either has a specific piece of content (such as the complete Star Wars catalogue) or feature (such as supporting offline viewing) or it doesn’t. This is often an eliminatory stage, as options which don’t provide required features are removed from the comparison.

The second stage however, is when we focus on the “hows”. This is when we compare the subjective experience of using the product or engaging with the service. 

This stage is where quality tends to shine. Most streaming services will probably have an app for your phone, but some of them run a lot smoother than others. 

It’s somewhat curious that whenever we make recommendations, it’s often in regards to how well a given product or service does something, and rarely about the actual objective functionalities it offers. 

Funny enough, we frequently leverage adverbs to stress those recommendations: efficiently, seamlessly, effortlessly, smoothly, etc. 

While actual functionalities are objective, one either has a given feature or doesn’t, it’s often the subjective traits that stick with us the most, and allow us to distinguish between an average product or service and an amazing one.   

In a similar fashion, we, as customers, tend to use the same mindset when requesting or ordering things. 

We often prioritize requesting objective features over subjective traits. What this means is that while it is simple and straightforward to request for additional Star Wars movies in a streaming catalogue, it is often confusing to phrase a request for a better overall experience on the existing app.

Objective feature requests are also much simpler to implement, so they become easier targets for prioritization, while subjective capabilities are often locked behind extensive debate over how they can be achieved and how to measure the actual benefits of their rollout. 

Being harder to formulate can also lead to subjective requests being either misunderstood or outright skipped as being too generic or unclear.

Alright, so it is somewhat tricky for customers to directly provide us with valuable insights regarding things we’re doing well and ones we can improve. How can we obtain these insights then?

The answer is through knowledge and understanding of our own offerings and customers.

Why context is the missing piece

It should come as no surprise that the more we understand a given problem, the better the solution we can implement for it. 

This often translates directly to products and services, with greater knowledge of a product and its users, comes a greater ability to evolve said product in a meaningful way that retains customers and satisfies their needs.

To this understanding of the reality surrounding a product, feature, service or issue, we give the name of context. 

Context is something of a group puzzle. What this means is that beyond just managing to put all the pieces in the right places, the challenge is that we, alone, seldom have all the pieces. 

We therefore need to identify which people can provide the missing pieces so we can complete the puzzle.

When it comes to context, a very important information to keep in mind is that it tends to grow in silos. 

Normally each team, area or department will have a silo of information of its own. This is completely natural, and happens across all organizations to varying degrees. It is not necessarily something we want to avoid by definition. 

A member of the legal team would potentially find little benefit in having a deep understanding of the exact implementation of the software tool being maintained by the company. 

There could be benefits? Yes, of course there could. But the effort necessary to share such deep knowledge across such distinct areas might be more trouble than it is worth.

In most cases, a shallow understanding of the bottom line of each of these silos is often enough for the other silos. 

There are however cases in which a deeper understanding between different areas can generate great benefits. Specifically when talking about tech companies, there is a very special case, and that is the formation of silos between product teams and support teams.

On one side we have product development teams, which often hold the most in-depth knowledge about product capabilities and features. On the other side we have support teams, which tend to hold an extensive knowledge regarding how the product is used by customers, whether it be as intended or not.

The remainder of this article goes through manners in which leadership can help enable this dissemination of knowledge across the teams, to mitigate the challenge provided by the natural formation of silos of knowledge.

We’ve drawn the suggestions below from a forum conversation regarding this effort of better connecting product and support teams in order to enable the transmission of this deep knowledge across the borders of their silos.

Creating space for sharing “interesting” observations 

One of the key components of brainstorming is the notion of bringing ideas and thoughts forward. 

This comes from the understanding that ideation is more of a process than a single event in time, and ideas often shift and transform, as they interact with other people and other ideas, before reaching their mature form.

A powerful resource in this sense are the observations and comments from customers about your product or service. 

Through their extensive contact with customers, it is often support teams that have the largest knowledge base of these observations. This is mostly simple and straightforward information, things that frequently even sound somewhat obvious when said out loud. 

Another key trait is that these are not the usual complaints about problems. Those obviously need to be addressed in accordance, but focusing only on individual problems often means paying less attention to the wider scope.

The form this can take will obviously vary based on your organization, but a simple Confluence page or shared Wiki-style page can go a long way in preserving and disseminating this type of information. 

This way, whenever the product team starts ideating over features or priorities, they can leverage these observations to expand their brainstorming process. 

Remember, these might not represent much individually, but once combined with other ideas and suggestions, they can quickly point towards effective and beneficial traits for your bottom-line. 

End-of-Day/Week Support Summaries

Another interesting resource that can be used to connect product and support teams are support summaries. 

Whether this is a daily, weekly or even a monthly effort would depend on the size of the organization and the amount of customers. 

But the idea remains the same, at each given interval, a lead figure of the support team can compile a brief summary of what took place during that interval. 

Which is then filed and documented alongside the reports for other intervals. 

This type of report can provide great insight into trends and peaks of certain types of issues or requests, which in turn can be used to glimpse into existing points of friction or zones for potential improvement.

Finding unexpected use cases

The ability to recognize and identify emergent usage in a given space can be a very powerful tool to drive decisions about product backlog.

The word emergent in this case is used to describe usage that is developing in a somewhat unexpected or unintended way. 

Identifying early on that your product is being used with a specific purpose that differs from the original design can allow for companies to leverage this emergent usage and benefit from what customers are actually leaning towards, or viewing your product as exceptional at. 

This can sometimes open up broad new horizons of demands your customers have but were never able to express.

To serve as an example of what emergent usage can be, a product that helps people perform a given activity, such as track expenses might end up being used by parents to teach their children how to track and control their spending. 

This discovery enables a team to provide additional features or tailor the user experience to welcome this emergent use and incentivize its adoption. 

In a similar fashion, adjacent use cases can be perceived and explored upon, such as Duolingo including Math and Music lessons besides its traditional catalogue of language courses.

Creating a framework for capturing context

Often when running insight research over data and reports from user interactions, one of the main challenges is glimpsing at the complete context of the actual conversations they relate to.

Documenting the actual complaints or requests is obviously fundamental, but by documenting additional contextual details, support teams can enable a much faster extraction of product insights.

A thorough report can go a long way towards providing insight, but the thoroughness itself can present challenges. The goal is then always to find a balance between what is too much information and what is too little.

Naturally there is no silver bullet or magic formula here, the key parts of the context to be captured will vary based not only on the product or service being worked on, but also by the maturity level of it, as well as its customers.

Regardless of what exactly is being documented, it’s very important that these resources are forwarded to the product and research teams so the actual insights can be extracted.

Validating research through support conversations

While earlier we talked about the value of documenting the context of customer exchanges in order to facilitate research, there is an additional way in which the two can intertwine. 

By quickly running findings and features by support teams, it allows us to leverage their extensive context of the topic for validation.

The support team’s positive reception of a proposal, be it a fix, an enhancement or an entirely new feature, can work as a form of green flag that the proposal is sound and viable. 

Likewise, hesitation and concern might serve as a signal that a new feature might generate confusion or clash with other existing flows, and might need further workshopping before it can be rolled out.

This can also go far beyond a simple approval signal, and support teams can be included to a degree in the process of ideation for new features, enabling them to contribute with their extensive knowledge of customer behavior in order to guide the decision process.

Closing thoughts

As we’ve explored earlier, it is often challenging for customers to talk directly about the more subjective elements of products and services, even though these are often the driving force behind our preferences and experiences.

In order to be able to identify what customers are not explicitly requesting, we need to understand them.

Connecting the deep technical understanding of the product teams with the extensive knowledge of user behaviors and needs of the support teams, while no simple feat to accomplish, presents itself as a powerful opportunity for driving the development of better products or services.



A key notion to keep in mind is that although our short-term objectives might differ across teams, in the end, our objective is often one, which is to provide the best experience we can to our end-customers.