Save time and increase customer satisfaction with rapid feature feedback

Shipping new features is awesome. But let’s be honest, the excitement from customers isn’t always mutual. Sometimes features are just right and they just work. But, unfortunately, that’s often not the case. 

Have you tried looking over the shoulder of someone using your product? Then you know. 

New features can be confusing to customers, too hard to use, or miss something critical and aren’t useful. 

Sometimes, new features are worse than what was there before!

Time for some good news. In most cases, the annoyance and/or confusion is fixable - but only if you know about it.

Let me give you an example from one of our customers:

They shipped an “Export to CSV file” feature. Customers loved this new functionality. They could now export their data and use it however they wanted, yay! 

But they also found it frustrating to work with. 

Why? The filenames were randomly generated and the sheets weren’t dated, which meant that the exports could easily get mixed up. It was chaos when an old export was mistakenly picked and the metrics suddenly decreased instead of increased!

As a developer, it’s easy to understand how naming export files based on the current date and/or adding timestamps to the sheet was forgotten when designing the feature.

These things happen all the time. Dev life. New features are mostly great, but something about them is causing trouble. 

The question is, do you learn about it, fast?

The clock is ticking

Changing filenames of data exports is easy when working on the feature. But changing the filename of data exports three months after deployment when you’ve worked on three other features since then, not so much.

As soon as the product team behind the feature has moved on to another project, the time to fix anything goes way up. 

Data export is an Enterprise feature with SLAs. To dive back into a feature to change the filenames is risky. 

A 1-hour task is now a 3-day task when you factor in testing and QA. Furthermore, the task is now also a Customer Success task since they need to communicate the fix to all the customers who’ve reported this issue. It’s also a support task. Those who have built custom scripts to work with the export files might suddenly have broken scripts due to the filename changes.

The point is that it’s in everyone’s interest to get feedback on new features as fast as possible. It leads to increased R&D productivity, increased customer satisfaction, and no additional tasks for other functions.

Importance of low-level feedback

Most organizations get product feedback from their customers. If you’re a startup, it likely comes from the founders. If you’re in a larger organization, it probably comes from customer success, account executives, or product managers.

In larger organizations, feedback that isn’t detailed enough can lead to false positives. For example, a customer success person might check in with their customer contact and hear great things about the new data export functionality. This can lead to everyone believing that the feature is a home run while the customer’s data team is frustrated with the lack of timestamps.

And it may not stop with the filenames. Maybe the column order or column names aren’t configurable. Maybe they need right-to-left alignment. Maybe the columns are poorly formatted.

All these kinds of issues are likely solvable by an internal team but they may be dissatisfied with you as a vendor - especially since the issues they’re facing never seem to be addressed in the monthly product updates.

To ensure features are truly satisfying for everyone working with it, you need a way to capture feedback from the people working with them. And you need to gather that feedback as fast as possible after releasing a new feature.

How to get low-level feedback on new features

When you release a feature, you may first release it internally. This is the first time where it's possible to collect feedback from team members who haven’t seen the feature before.

Once tested internally, you can give certain external customers Beta access to the feature. On Bucket, you can easily do this by taking the feature through the configurable release stages:

During those stages, you should make it as easy as possible for users of the feature to give feedback to the builders of the feature.

On Bucket, we make this extremely simple. 

First, create a feature on Bucket. Features can be used for three things:

• Feature flagging
• Collecting feedback
• Measuring adoption

When you release a new feature with Bucket, you can gate it based on the feature’s targeting rules, like so:

const { isEnabled } = useFeature(“my-feature”);

if(isEnabled) {   
	return(     
	   <button>Export CSV</button>   
	)
}

‍

To gather early feedback on the feature, you have two options:

• No-code automated feedback surveys
• “Give feedback” button

Since the Export CSV feature isn’t an interactive feature, we want to add a “Give feedback” button next to the export functionality. This gives users an easy way to let you know about any issues, like filenames, column ordering, etc., as they stumble upon it.

To add a “Give feedback” button, we use useFeature()’s requestFeedback method:

const { isEnabled, requestFeedback } = useFeature(“my-feature”);

if(isEnabled) {
   return(
	<div>
	   <a onClick={() => requestFeedback()}>Give feedback</a>
	   <button>Export CSV</button>
	</div>
   )
}

‍

Clicking the “Give feedback” link will open this feedback widget:

And the feedback will be sent to the Slack channel of your choice and appear on the Analyze tab for everyone on the product team to see and act on, fast.

That’s it! It’s that simple to save time and increase customer satisfaction with Bucket feedback. 

Happy shipping!