Managing customer expectations for new feature requests

· 7 min read
Managing customer expectations for new feature requests

If you’ve worked in a customer-facing role at a SaaS company, then you’ve received feature requests before. Loads of them. You’ve also probably thought about how to manage your customers’ expectations when it comes to these requests.

The typical company responds to a feature request by saying “Thanks for your feedback, we’ve passed it on to the team.”

More times than not, the user never hears back again about their idea. They’re left to assume it was promptly forwarded to a room to be printed and fed to a paper shredder.

Or fed it to a cat.

We can do so much better.

At the end of the day, you grow your SaaS business by A) getting more customers, or B) delivering more value. A is the primary responsibility of the sales & marketing orgs, and B is owned by the product org.

How does the product org deliver more value? We all know this: by listening to your users.

So why then, when our users give us brilliant ideas on how we can deliver more value, improving our business and theirs, do we respond with the paper shredder reply?

This is one of the reasons we started Canny in the first place. Giving feedback to companies today is a bad experience. As a result, users are left feeling unheard and unloved, and companies are missing out on loads of valuable insight.

How can we do better?

People want transparency

When someone shares an idea with you, they really want to know two things. Are you going to build the feature I care about? If so, when? If not, why not?

By answering these two simple questions, people will be super impressed. This helps you stand out from every other SaaS company out there.

But how do we answer those questions? That’s the tricky part, and why most companies don’t bother.

When you’re a 1-2 person company, you’re likely a founder and therefore responsible for support, sales, and product. You already know if you’re going to build feature X, and when / why not. You can just tell them.

Customers will still be impressed, and this will help you stand out from your larger competitors.

Being transparent gets harder as you grow

But as team size grows, the customer-facing team and product org becomes more and more siloed. The support/sales person talking to the customer isn’t necessarily familiar with the product roadmap, and the decisions behind it.

For a 5 to 50 person company, the answer is usually just a quick conversation away. Modern messaging tools like Intercom make it really easy to loop in your colleagues from the product org, to get the info you need. A bit more friction, but still not bad.

For teams of hundreds or thousands people, transparency gets challenging. It might not be clear who the person is with the information you’re looking for. You might have to check-in with the marketing/PR team, to make sure you aren’t leaking a big, splashy launch.

A great way to solve this problem is to maintain internal product roadmaps. This way, your whole team can easily stay in touch with the improvements your product team is making.

This is why big companies are so bad at responding to user feedback. Because it’s a hard problem.

It’s a problem worth solving

Whether you’re a small team or a big team, it’s worth spending the extra effort to deliver a transparent response. It’ll impress your customers, which will pay dividends in brand loyalty and satisfaction.

Another massive benefit is product adoption.

Every time someone requests a feature, keep track of that somewhere. Once you start building the feature, tell everyone who wants it that you’re building it. Once it’s ready to use, tell everyone who wants it that it’s ready to use.

Hint: Canny was built to do exactly this.

By doing this, you’re not only closing the feedback loop, but also driving adoption of your new feature. When people use more features, they get more value from your product, and are less likely to churn.

Churn is the #1 enemy of every SaaS company.

Never make a promise you can’t keep

You’ve almost definitely heard the expression “under promise, over deliver”.

This expression definitely applies to being transparent with your product roadmap.

You need to be careful that you aren’t transparent in a way that could be untrue. Otherwise you’re lying to your users, which is arguably worse than saying nothing at all. It’ll work against your brand, instead of for it.

Here’s a handy graphic for what your product team is thinking, and what that should translate to in a customer-facing promise.

The important takeaways from this are:

  • Never tell a customer you’re going to ship a feature until you’re 99.9% sure the feature will ship. That means it’s either on the roadmap, or being worked on, and you trust your product team to deliver on what they say they will.
  • Even once something is being worked on, always exaggerate the timeline. Engineering estimates are comically bad.

Find a time where you’re 99.9% sure the project will be complete by then. I find multiplying your estimate by 2x or 3x is typically safe, but it varies team to team.

The important thing is that you’re never lying to your customers, because this will work against you in the long run.

Build features that close deals

This process is a two-way street. Not only should your customer-facing folks ask your product team about the roadmap, they should help inform the product roadmap.

Let’s say you’re on a demo with a big enterprise lead. You’ve run through the product, and they like what they see.

“Oh by the way, do you have features X, Y, and Z?”

You have X and Y, but are missing Z. What do you say?

Some founders / salespeople say “fake it till you make it”, and lie by saying they do have the Z. Don’t do this – if you’re caught lying, the deal’s definitely dead, and you lose trust in your company’s brand.

Here’s what you should say:

“We don’t have Z right now, but I’ll talk to our product team, and see if we’d be able to commit to building it in a short period of time.”

Again, you aren’t making any promises you can’t keep (some salespeople are known for doing this – don’t!).

Sometimes Z turns out to be a feature that you know a lot of other companies would be interested in, and your team has wanted to build it for a while. In this case, it’d be a no brainer to build it to close a big deal.

Break down silos in the name of transparency

The ideas in this post aren’t inherently complicated. Especially at a small company, being transparent is quite easy, and super worthwhile.

As the team grows, the hard part is that the customer-facing and product teams become siloed off from each other.

  • Support is treated as a necessary cost center that should be reduced.
  • Sales is focused on bringing in new business, and not really incentivized to talk to product.
  • Product is too busy improving the product to meet with other teams.

But getting these teams to work together is critical. You’ll close more deals, your product team will be more informed, and your customers will definitely notice.

Looking for a way to keep track of feature requests and impress your customers?

Avatar

Andrew Rasmussen

Hi, I'm a co-founder of Canny. Before that, I was a software engineer at Facebook. I love JavaScript, rock climbing, nerding out about the future, and SaaS.

All Posts · Twitter

Avatar

Andrew Rasmussen

Hi, I'm a co-founder of Canny. Before that, I was a software engineer at Facebook. I love JavaScript, rock climbing, nerding out about the future, and SaaS.

All Posts · Twitter

Canny is a user feedback tool. We help software companies track feedback to build better products.

Leave a comment

avatar
wpDiscuz
© Canny 2019
Privacy · Terms · Security
canny-backstage

Come backstage, where we share an honest look into building Canny. You’ll be the first to know when we post new content.

Avatar

Andrew Rasmussen

Hi, I'm a co-founder of Canny. Before that, I was a software engineer at Facebook. I love JavaScript, rock climbing, nerding out about the future, and SaaS.

All Posts · Twitter