3

Building a Passive Product Feedback System

 1 year ago
source link: https://uxplanet.org/building-a-passive-product-feedback-system-92afb43b3602
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Building a Passive Product Feedback System

Collecting customer feedback shouldn’t be a constant, proactive effort. The definition of passive feedback systems, why they’re useful, and what tools any product organization can easily implement.

👋 Hey, it’s András here! Every two weeks, I write about product management concepts, hot takes, and frameworks to help you build better products. Subscribe to The Product Principle to get each article delivered to you when it’s published!

“Let’s do some user research!” — product managers, designers, and researchers often rely on customer interviews, surveys, and other qualitative user feedback collection methods to understand a new problem area.

Most of these tasks require active and ongoing efforts to get the customers’ feedback. This often means stakeholders start from a blank slate, trying to collect evidence about a suspected problem or a hypothetical solution.

But not all findings need to come from net new efforts. And that’s where the importance of passive product feedback systems comes in, especially for digital products.

Feedback systems consist of processes, functionalities, and tools that were put in place to facilitate the collection of customer insights, compiling them to one central place internally. All are happening without constant or proactive effort from product teams.

Passive product feedback systems are something that companies rarely focus on intentionally and are usually not well documented, but organizations still build components of it over time.

Passive product feedback system components

There are quite a few types of possible system components; below, I look at four examples that I’ve worked with in the past: triggered surveys, feedback buttons, customer-facing stakeholder processes, and event data analytics.

These components can be implemented in a matter of days or weeks, depending on the size of the organization. All have different benefits, but a common theme is that they reinforce each other: they work best together, acting in harmony as part of a coordinated system.

Without further ado, let’s look at the four examples.

0*2V1C3ITJYII032WD.png

Triggered surveys

Triggered surveys are small forms that appear to the user while they’re interacting with a product, usually at the corner of the screen. These surveys are activated by an interaction, a user state change, a completed workflow, or a recurring schedule.

Typical examples include a Net Promoter Score check-in, an app review prompt, an onboarding-completed survey, or a small popup that appears when the user has interacted enough with a new feature to be asked for feedback.

When using these surveys, we don’t have to think about whole product-wide initiatives. Instead, several companies use sub-product questionnaires to measure satisfaction with specific functionalities. One example was Atlassian measuring the new page editing experience in Confluence.

When evaluating the results, it’s not only the scores that matter but also the rate of customers who dismissed our feedback prompt and felt passive or indifferent about answering.

Feedback buttons

In contrast to triggered surveys, feedback buttons do not suddenly pop up for customers; they’re a more permanent part of a product. We can find them in empty areas of an application, with a not-so-attention-seeking design, or often when navigating to the “help” section of an application. What’s also different in their serving is that they’re not dismissable, so even if users don’t have the time to give feedback right now, they can revisit them later if they have some suggestions.

New feature launches inside bigger products typically rely on this method to gather early feedback, provide a direct channel to report bugs, and to generally provide a smooth experience for early adopters.

When designing a feedback button and a feedback form behind it, we should clearly aim to differentiate them from customer service touchpoints, places where our users would turn for immediate help.

Customers should have clear expectations about any feedback button and should not expect any response when submitting something there.

Customer-facing stakeholder processes

One of the most underlooked components of a passive feedback system is designing processes for customer-facing stakeholders. Sales, account managers, onboarding specialists, and support agents all interact with customers. And during the whole client lifecycle, these stakeholders all collect valuable feedback that works best when captured in a central system.

While Google spreadsheets, Jira projects, or specialized product feedback management tools can all fit this purpose, the key is discipline. If there is a clear process on how to capture feedback, all customer-facing stakeholders should be trained to follow that.

And for this feedback to be effective, collecting them is only the first step on the journey. The product organization needs to ensure that feedback is regularly looked at by the right people, triaged, and prioritized according to the potential opportunity.

Event data analytics

The last component in this list is probably the least surprising: event data analytics.

Tracking what functionalities customers use the most often, which are the key user flows (pages or events customers go through), and whether there is an upward or downward trend in utilization.

Event data analytics is used most often with product adoption and success measurement, but it also has a significant role in measuring long-term, continued utilization. Especially when deciding if we have the critical mass to keep up a feature or when thinking about building on top of an existing solution.

This kind of data analysis can also provide us with leading indicators for tracking growth or churn potential related to sub-products.

Are customers using the solution enough to continue paying for it? Is there a correlation between a declining event count and subscription cancellation? If so, does it affect a specific user segment more than others? Could we conclude that our product is not fitting well with that audience? Should we develop better functionalities for that segment, or should we focus on other customers?

These are just some of the questions event data analytics can answer, and without a doubt, this can add a lot to other components in a passive product feedback system.

Why build such a system?

Building a passive product feedback system requires time and effort, and we need a good justification to invest in it. Below, I collected my top three arguments for such a system, plus one potential pitfall to be aware of.

  1. The cost of acquiring user feedback is much lower. While passive feedback systems don’t replace all product research efforts, they do help focus the proactive effort where it’s really needed. In addition, not all new features require reinventing the wheel — often, there are perfectly good wheels out there to take inspiration from.
  2. Spotting trends outside of our field of vision. We usually pursue specific, well-defined initiatives with active product discovery efforts, which means that some other topics might go under our radar. Passive product feedback systems can help alleviate some of these concerns by providing a more even exposure to user problems.
  3. Avoiding scattered or siloed product insights. Even without proper systems in place, organizations already capture a good amount of customer feedback. Without a disciplined process, that information is scattered across our company, sitting with multiple people in multiple different formats/places. Building out components of a passive feedback system can bring those information pieces together in a central place.

Of course, passive product feedback systems are far from perfect.

One obvious pitfall is that these systems might bias us toward well-communicated or more obvious problems. And in the process, we might ignore other opportunities that our users won’t raise, problems that might hide bigger future potential.

So don’t completely rely on inputs from a passive feedback system like this when working on the product strategy. Plus, remember the Henry Ford quote about creativity (that’s probably misquoted):

“If I had asked people what they wanted, they would have said faster horses.”

Conclusion

There are a lot of hidden product insights in any organization. A passive product feedback system can help us surface the customer voices better and provide more channels for this feedback to reach us.

In this article, I covered four components of a passive feedback system that can make product teams more efficient in their product discovery activities. But those will never replace all research efforts, and that’s not the intention.

Product research is still very much needed in topics with low visibility.

As a takeaway, remember that even with well-functioning feedback systems, it’s easy to get biased about apparent improvements. But that doesn’t mean they’d be the most valuable thing to do.

Passive product feedback systems are not enough alone. The resulting insights are only as valuable as the actions and conclusions we take from them.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK