Teams often have concerns around product roadmaps that are viewable to anyone. We’ve written about this on the blog in the past—in this article on why you definitely should have a public roadmap, for example, and this one debunking concerns about public roadmaps.

These concerns are completely natural and should be addressed. Making a roadmap public is a big move, and you want to make sure your whole team is on board.

To help you do that, we’ve created a survey that you can use with your team. It’ll help you ask the right questions and start a discussion around public roadmaps.

Share this public roadmap survey with your team

However, we’re not going to be talking about concerns in this post. We’re going to talk about public roadmap benefits.

There’s a twist, though: It’s all about you.

A public roadmap should benefit your company

Most companies focus on transparency for stakeholders as the main benefit of having a public roadmap. For some awesome pieces on transparency, check out Buffer, Holistics, and Front.

This makes sense—a public roadmap insinuates that it’s mostly there to benefit the public.

As advocates of everything transparent, we obviously agree that this is important. Our roadmap is public, too!

However, there’s a whole other stack of benefits that come with having a public product roadmap. The kind of benefits that help with your company’s wellness, bottom line, and growth.

These benefits are ones you shouldn’t disregard, as selfish as it might seem. Especially if you’re trying to convince yourself or your team to make your roadmap public.

Want inspiration? Check out these great public product roadmap examples. 

Let’s be real—we all secretly care about ourselves first. And that’s completely fine. It doesn’t have to take away from pleasing your customers at all.

So, let’s be selfish, and talk about why public product roadmaps benefit you.

3 ways a public product roadmap benefits your business

You can use these points:

• To explain to your product team why having a public product roadmap is pretty awesome.
• As a way to start a discussion about having a public roadmap in your company.
• To solidify your own support for public roadmaps when explaining it to others.
• As food for thought for any future endeavors.
• While you sit in your giant leather chair and snicker as you make your roadmap public. Soon, you shall reap the rewards.

Hey, whatever you choose to do—we’re here to support you.

Selfish public roadmap benefit #1: Less time wasted on building the wrong things

One of the most dangerous things product teams can do is make a product their “baby.”

You built it, and you designed it. You raised it to behave well. You put a lot of time and effort into it every day. It’s a part of you. You’re proud. Nobody talks smack about your baby.

Some product owners become so attached to their “baby” that they refuse to listen to anything even mildly critical or constructive. It doesn’t matter if it’s a customer, an investor, or another teammate.

It’s their baby, and they know better.

However, 42 percent of startups fail because of no market need.

This means that everyone should be very inclined to base their roadmap on users, not their own preferences, beliefs, or attachments.

If customers aren’t involved, you’re not building a product for them. You’re building a product for you.

This will destroy your business.

Now that we’ve established why customer and user insight is critical, let’s see why not having a public roadmap is bad in this case.

According to a 2016 survey by Pragmatic Marketing, here are the business activities product managers spend the most time on:

The largest amount of time is spent on understanding market problems.

This can look like product managers:

• Going out and finding customers to talk to
• Showing them the roadmap (which involves giving special access to it)
• Asking for feedback on this private roadmap (which is extra effort for the customer)
• Asking for feedback again (because your users have more important things to do than look at your secret roadmap)
• Documenting it
• Following up

That’s a lot of time that could be spent on building better products.

Selfish public roadmap benefit #2: Less bickering between teams

Internal roadmaps tend to be very development-centric. They’re not built to be looked at by a “normal” person. They’re there mostly for the product team to keep track of their work.

However, that’s what external-facing teams have to do—communicate it to “normal” people.

Who’s going to be helping them “translate” it, providing extra information, and help out? The product team.

Can anyone from any team just drop whatever they’re doing to deal with someone else’s “urgent” issue? No.

Are people going to be waiting for information for ages? Yes. Who’s going to be pissed? Everyone.

Weekdone made a sweet infographic about 10 ways to improve team communication.

Here are the biggest time wasters when it comes to communication within a team:

There are 3 very relevant issues here:

• Waiting for information
• Inefficient coordination
• Unwanted communications

Does this mean your team shouldn’t communicate with each other at all? Of course not.

But, there’s no need for unnecessary back and forth.

Selfish public roadmap benefit #3: More new customers with less effort

Public roadmaps aren’t good just for existing customers. They can also be super effective at reeling in new ones.

There are two main ways a public roadmap can help bring in potential customers:

1. Potential users stumble upon your roadmap while doing research

Especially with picking new SaaS software, people tend to do extensive research first. One of the most important factors of choosing software is (number of) features.

However, there’s rarely ever a “perfect” solution for anything. Most options are still missing this or that—little things maybe, but still things.

Let’s say there are two options on the table, both with slight faults. Most customers don’t necessarily reach out to ask you if you’re ever going to work on them. They’ll just go for the prettier/cheaper one.

If your roadmap is public and accessible to them with no effort, they can see what’s coming up.

If you’re planning on fixing the “faults” they found with your product, they’ll choose you.

If you’re not, well, then maybe you wouldn’t be the best fit for their use case anyway. They’ll save themselves money, and you’re saving yourself a churned customer.

2. Potential users will ask to see your public roadmap

Some people do ask about your plans with the product.

We’ve all heard “I’m only going to pay if you build this thing in the near future.”

With a public roadmap, you can either show them:

• Yes, we will be building this thing, and all these other cool things!
• No, but look at all these other cool things. Maybe those will give you an alternative solution for what you need?

Don’t be afraid to think about yourself

Yes, transparency is important. Your (potential) customers will be stoked to see that you’re open and honest about your plans.

Nobody can ever take that respect away from you.

However, it’s okay to think about yourself, too.

• A public roadmap can bring you new, qualified business that is much less likely to churn.
• It’ll help you make better decisions and waste less money.
• And, it’ll make life much easier for people working to communicate your greatness to the world.

Don’t forget to grab that survey template to start the discussion about making your roadmap public with the team. And, check out Canny’s free product roadmap software to make managing your public roadmap a snap.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post 3 public roadmap benefits you probably haven’t thought of first appeared on Canny Blog.

The post 3 public roadmap benefits you probably haven’t thought of appeared first on Canny Blog.

They are the single source of information for everyone involved in product planning.

Product roadmaps help you:

• Organize development work within the organization
• Sync up with other departments and get their perspective on product plans
• Keep stakeholders and customers informed and excited

But, they’re only truly helpful if you’re following a few basic product roadmap best practices.

Today, we’re going to talk about the five best practices for effective and informative roadmapping. These tips apply to both internal and public roadmaps. It’s easiest to use a product roadmap tool, too, but there are lots of ways to create a roadmap.

Product roadmapping is extremely valuable if done correctly, so don’t let your hard work setting up a roadmap go to waste.

5 product roadmap best practices to follow

1. Keep your roadmap updated

Product roadmaps—like any widely used source of information—are only useful if they’re kept updated.

Internally, not keeping the roadmap updated means misinformation and disorganization. Your product team will be lost, and other departments will be even more confused.

Externally, an-out-of-date roadmap is useless to stakeholders—investors, customers, and so on.

They won’t get any useful information about what’s coming. In the worst-case scenario, they get a completely wrong idea about what’s being worked on. Cue a lot of disappointment and anger.

The cadence of updating your roadmap depends on the stage your company and product are in.

This amazing guide to product roadmaps by Department of Product illustrates this:

In the early stage, there are two main ways to make sure your roadmap is always updated:

Review regularly

The product team should review the roadmap often, even if they’re not currently adding to or changing it.

Weekly, monthly, whatever—how often you want to do it is up to you. As long as you go over it regularly to make sure everything is where it’s supposed to be, you’re good.

Make it a logical conclusion to add things to the roadmap

Make sure all action items decided upon in meetings, documents, and so on are always added immediately after. It should become second nature to add any hard conclusions to your roadmap.

It’s easy to let things slip your mind. If other departments or customers are looking at your roadmap too, every missed item causes confusion.

Making it a clear and regular practice to keep the roadmap updated will eliminate confusion and make sure things don’t fall through the cracks.

2. Don’t overpromise on your roadmap

Putting things into a roadmap is fun.

For product managers and developers, it’s almost a pride thing. You put items into the roadmap, and everyone will be excited to see it.

However, we’ve talked before about underpromising and overdelivering. Just like with keeping it updated, a product roadmap is only useful if it’s realistic.

Remember: Customers and team members will be excited to see the plans you’ve made. However, they won’t be excited when things start being late or not happening at all.

People will lose trust with you if you keep letting them down. You don’t want that.

It’s always better to underpromise and overdeliver than vice versa.

3. Make sure you have a place for feedback

Your product roadmap is ideally built based on both customer feedback and requests, as well as internal feedback from other departments.

However, you shouldn’t close off all feedback options once the roadmap has been put together. It’s normal to want to reach “closure” with your roadmap and lock it up after it’s been built.

But, especially in software, roadmaps are never set in stone. Plans change based on new information and requests. Different things end up being prioritized.

Furthermore, roadmaps tend to not be super-detailed. This means that people who aren’t directly involved with product planning can have additional questions or input. You might need to update your roadmap as a result.

So, it’s important to establish an easy way to give feedback on (and ask questions about) your roadmap at all times.

Both internally and publicly, that means:

• Providing a place to have a discussion over the product plans
• Setting up an easy way to contact whoever is in charge of informing the roadmap
• Clarifying how to contact the whole company about their roadmap if needed

For example, our Canny roadmap allows for discussion and comments over any roadmap entry:

Remember—additional feedback and input is always a good thing. It’ll make your roadmap more diverse and adaptable to changes outside your product.

4. Make ownership clear

Especially with internal product roadmaps, it’s extremely important to make it very clear who’s in charge of any given item.

This way, if there’s an issue or a question, everyone knows who to reach out to. Otherwise, the general product manager will be bombarded with questions and problems they’ll have to reassign.

Plus, clear and visible ownership within the roadmap will make the people directly responsible more aware, involved, and proud of the work they’re doing.

If you want to make it even more clearer (and fun!) you can do something like Buffer (our tool of choice for social media scheduling!) does with their Batman-Robin system:

Assigning both your Batmen and Robins (or just Batmen if you’d like) to all tasks will reduce confusion and direct communication.

5. Keep the format consistent

It doesn’t matter whether you keep your product roadmap in Canny, Trello, or somewhere else. (Though of course, we’d recommend using a tool like Canny, which has a product roadmap tool built into it. We love Trello, but it wasn’t designed as a roadmapping tool.)

The important thing is to have a conversation around the format of your roadmap and the entries in it. Everyone who has permission to change the roadmap should agree on a common “way” to do it.

This is a simple consistency issue. Not enough consistency in the format of your roadmap entries can cause a lot of confusion.

Being consistent with your entries doesn’t necessarily mean always adding more stuff, either.

Depending on how your teams work, it can be an issue of either a lack or excess of information:

• A lack of information causes communication issues and information gaps
• An excess of information causes noise and confusion

Whatever format you agree on when it comes to adding things to the roadmap, it should always look the same, and have the same level of information.

Need some ideas? Check out our list of public product roadmap examples.

Put constant work and thought into your product roadmap

Product roadmaps, whether used internally or publicly, are extremely useful.

You can use them to keep work organized between all the departments in your company, as well as let stakeholders know what’s coming.

Product roadmapping is the link between collecting user feedback and execution. Your roadmap will start conversations about your product’s future, and give context for the work you’re doing.

Keep your product roadmap properly maintained, updated, and accessible. It’ll streamline your whole product planning process, and save you a lot of wasted time.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post Product roadmap best practices: Informative and transparent first appeared on Canny Blog.

The post Product roadmap best practices: Informative and transparent appeared first on Canny Blog.

• You collect feedback
• It gets discussed and prioritized
• New features, updates, or changes get added to your roadmap

But, what comes next?

New features deserve some celebration. Don’t just add them to your “complete” column and call it a day.

You’ve spent weeks, months, or even years building something. Announcing it should be fun and exciting.

The feedback cycle should always end with communicating what’s finished. Brownie points for also explaining where to find it, and how to use it.

Using a changelog tool is a great way to share what you’ve been working on and keep your customers updated.

This is where Canny Changelog comes in.

We built it to close the feedback loop, notify customers, and encourage engagement. All in one place!

Why do you need a changelog?

You might be thinking: If I have a public roadmap, why do I need a changelog?

Here’s why you should use a changelog even if you have a roadmap that your customers can see.

A changelog keeps existing customers in the loop

Not everyone is constantly keeping an eye on what you’re up to. This means that many customers might be missing out on awesome new features.

Some products are easy to get used to and not engage with anymore. The comfort zone is real.

Some of the benefits for your customers are:

• Increasing new feature awareness and adoption with your existing customer base
• Encouraging new customers to try your tool
• Showcasing new use cases and ways to use your tool that add value

There’s also the aspect of not leaving people hanging. With the Canny Changelog, customers who have requested certain features get notified when a project is complete. From there, they can head straight to the Changelog to check out the details.

Your team stays informed and updated

Using a changelog isn’t only for your customers. It’s also an amazing asset to have for internal purposes.

Having cross-team access to the product roadmap increases productivity. A changelog has similar benefits for your team.

Having one official place for new features helps non-product teams stay in sync. They’ll be able to and organize their work without constantly asking about updates.

Using a changelog makes communication easier

If you don’t have an official changelog, communicating changes to customers can be a hassle.

Without a central place for your releases, you have to use many channels to make sure everyone stays up to date. There’s no wondering which channels to use, or concern that someone won’t get the necessary info.

(Check out this article for more on the subject of why a changelog tool can help communicate updates.)

An official changelog is easy for support, marketing, and anyone else to just link to when needed. The interface is easy to use for anyone regardless of whether they’re a developer or not.

You’ll attract potential customers

A changelog isn’t only for existing customers. A public changelog also serves as a marketing tool.

Which customer wouldn’t like a company that actively builds what their users want?

By communicating your progress to the world, potential customers will also see it. They’re likely doing research about which solution to pick. Your transparency and velocity will stand out.

Want to learn more about our Changelog feature, and why having a changelog matters?

• Learn more about our Changelog feature
• Read more about why you should use a designated changelog tool
• Check out the Canny Changelog, where we log changes to Canny itself
• Have a peek at our Changelog entry about the Changelog (a little meta, right?)
• Read the help article about Changelog
• Contact us with any questions or concerns

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post Using the Canny Changelog to close the customer feedback loop first appeared on Canny Blog.

The post Using the Canny Changelog to close the customer feedback loop appeared first on Canny Blog.

Many companies make it clear that they value user feedback. Being committed to building a product based on it is an even bigger promise.

This can make customers a little too hopeful that whatever they ask for will be done.

How to say no to customers & feature requests

The sad reality is that some features will never be built. This is a hard blow for people who have suggested them.

They’re asking for something they think would add value to your product or solve a big issue. You’re telling them they can’t have it.

You should never build something just because a customer is upset. But, the right attitude and choice of words can make a huge difference between saying no and saying no.

Today, we’re going to talk about how to say no to a feature request the right way.

Manage expectations around product feature requests in your messaging

You’ve made it clear that customer feedback is an integral part of building your roadmap. This is a great message that makes your customers feel important and involved.

However, you have to be careful with how you phrase these statements. It’s obvious to you that you can’t build every single feature someone asks for. It might not be obvious to your users.

If you’re asking for feature ideas (for example, with feature request software like Canny), make it very clear that you still have to analyze every single one of them. Even better—tell them straight up that not all of them will be built.

SansMagic has a great “formula” for how customer expectations and reality affect the outcome:

A feature voting tool like Canny can also help with managing expectations naturally. Customers can see that product feature requests are also being voted on by other users. Seeing a list of features ordered by votes makes it more obvious that requests with only a few advocates will most likely not be built.

This will keep expectations reasonable, and everyone will be on the same page.

Instead of saying:

Say:

Make sure you’re on the same page

This needs to happen before you even begin to say yes or no.

Some people are not great at communicating their issues or requests. They also might not be too familiar with your product or its current capabilities.

All of the above means that you might not even know what the customer is really asking for. Often what they really need is not what they are communicating.

Make sure you ask specifying questions before making decisions:

Asking questions to determine what they really need will eliminate confusion and disappointment on both sides.

Instead of saying:

Say:

Explain, a lot

If you have to say no, don’t just say no. Explain why you’re saying no.

When a customer requests a feature, they’re already convinced that it is crucial for their success with your product. It’s way more important to them than it is to you.

You just know you’re not going to do it. If you don’t explain it, they won’t understand why. They’ll just feel like their input isn’t important to you. It’s not a good feeling.

It’s perfectly fine to share the real context behind why you can’t build a feature they want. This will help them understand that it’s nothing personal, and that there are real reasons behind it.

Instead of saying:

Say:

Watch your tone

Always reply with the exact same amount of understanding, politeness, and depth to every user.

No matter how many times you’ve heard it, how many times you’ve said no, or how tired you are—act like it’s the first time you’ve seen this request.

Stay away from phrases like: 

• This is a bad idea
• It’s never going to happen
• We hear this all the time

Remember that you don’t want to damage your relationship with the customer. If you come across too harsh, your customer will feel scorned—and they won’t come back to you next time they have a feature idea or request.

Instead of saying:

Say:

Don’t give false hope

If you’re 100% never going to do something, don’t give customers any hope that you will. This will just cause more disappointment.

Some customers will interpret “We’ll think about it in the future” as “We promise we’ll do it in the future.” This will not only upset them when you don’t, but also keep them in a limbo of not knowing what is happening.

Saying no and being concrete about it is better. It can be hard, but it eliminates any chance of misunderstanding or false hope.

Instead of saying:

Say:

Offer alternatives

Not being able to build a new feature doesn’t mean the customer doesn’t have an issue or that the issue is invalid.

Make the effort of finding out the real problem your customer is having. There’s a chance it can be fixed with something else. You don’t want to just say no and leave it at that. Always offer something.

Intercom makes a great point with this graphic, about “focusing on the job, not the no”:

Suggest anything at all—whether it’s a workaround, a tip, an integration they can use, or an offer to revisit the idea in the future.

This will tell them that even though you’re not going to build a feature, you still deeply care about fixing whatever problem the customer has.

Instead of saying:

Say:

Know how to compromise

We’ve made the point several times about how important it is to ask questions and have a conversation.

A conversation might reveal things you didn’t think about before. You might even reconsider not building a feature in the end.

If the request is low effort but high value for a valuable customer (or a few customers), maybe you should do it!

We’re not saying that you should feel pressured to rethink your decisions. It’s always your call, and it’s always fine to say no.

However, keep an open mind—sometimes it makes sense to say yes instead.

Be nice, be transparent, and keep an open mind

There’s a big difference between saying no, and saying no.

You always have the right to decline customer feature requests. Your product is your creation, and some requests just don’t make sense sometimes. You shouldn’t feel bad or guilty about it.

However, you do have to make an effort to not make your customers feel disregarded, confused, or discouraged. They are trying to help, and their feedback is still immensely valuable.

Be nice, open, positive, and explain the real reasons behind why you’re saying no.

Your users will get clarification, even if it’s not the answer they want to hear. Plus, they won’t feel discouraged by being rudely denied—which will make them more likely to share more feedback in the future, too.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post How to say no to product feature requests first appeared on Canny Blog.

The post How to say no to product feature requests appeared first on Canny Blog.

It can help you make informed and useful business decisions on your SaaS product.

But, getting feedback can be hard, especially if:

• You’re an early-stage company
• You have a basic MVP that doesn’t create much hassle or need for giving feedback yet
• You don’t have a customer base that’s particularly involved (yet!)

…and then there are people out there who just don’t like giving feedback.

Luckily, there’s a few things to do to nudge your users to give a little more feedback. And, they’ll feel good about giving it.

How to get customer feedback: Start by getting organized

Before you start, make sure you have a central feedback system to gather everything into.

There’s no point in making an effort to get more feedback if it’s going to slip between the cracks or get lost.

A feedback tool like Canny will help you stay organized. It’s an easy way to see all the feedback you’re getting in one place.

You can create a public Canny board where users can submit feedback and vote on features. Or you can keep your board private and track feedback on behalf of your users.

If you’re not yet ready to try Canny, we’d recommend a well-organized spreadsheet at the very least.

From there, it’s time to gently nudge your user base to come in and have their say.

Ask for feedback after every live chat session

…regardless of what the chat is actually about.

It doesn’t matter whether someone reaches out with a bug report, a general inquiry, or something else.

Asking for any other requests, ideas, or concerns after every chat session is a great way to get feedback.

You can use this for both people who are already users of your product and ones that are not.

Why? Because potential customers often have useful feedback to share, too, whether it’s:

• A feature you don’t have that is a deal-breaker for them (and why)
• Something they noticed on your site, in a demo, or while doing research
• Other immediate ideas for improvement

Asking existing customers for feedback after every live communication:

• Shows that you care on a deeper level (even if the reason for initial contact was something simple)
• Gives them an easy time and place to get stuff off their mind that they might have been thinking about for a while

To make this easier, use a feedback tool that integrates with your existing chat system.

For example, Canny integrates with Intercom. You can easily pull in whatever feedback you get from live chat.

This way, you don’t have to go manually log everything after each chat.

And hey—don’t forget to ask for feedback after someone cancels, too.

It might seem useless to ask for feedback if someone isn’t even a user anymore. But, it’s not. They left for a reason, and you should be aware of the reason.

Once you know why a customer left, you can use that information to prevent others from churning. That’s valuable.

If you’re using a feedback tool, tell your customers about it

A lot of companies make giving feedback a huge effort for customers.

Sometimes people don’t even bother giving feedback because they think it’s annoying or hard to get to.

Live chat is a start, but even that is a lot for some people. We expect long wait times, cold responses, or no responses at all. This holds a lot of people back.

Using a specialized feedback tool shows customers that you care. It shows that you’re invested in collecting regular, quality feedback.

Feedback tools are generally built for ease of use and low effort.

For example, with Canny, users can either:

• Go in and post ideas and feature requests themselves, or
• Click a button and vote on other people’s stuff

It’s easy to access, and pretty much zero effort for those who don’t want to do very much.

If you have a feedback tool, make sure you tell your customers about it. Highlight why it makes giving feedback easier for them.

That said, for this to be a selling point for people giving more feedback, your tool or environment needs to be:

• Well organized—if everything is a mess, nobody’s going to want to use it
• Active or pre-populated—if there’s nothing on your feedback board, nobody wants to be the first one
• Easy to access and use
• Frequented by your team members—if there’s no engagement by your team, it’s not going to entice anyone

Send personalized surveys to targeted customers

Reaching out and asking for feedback directly is great. But, there’s a right and a wrong way to do it.

Nobody likes getting cold emails. The usual “rate our product and explain why” messages are the worst. They’re boring, impersonal, and don’t give anything back to the customer.

Instead, choose the customers whose feedback you would find especially valuable.

These can be:

• Your highest-paying customers
• Your longest-standing customers
• Customers who use your most important features
• Customers who use your product a lot (all features, or very often)
• …or whichever other target groups you find most important

Identify which groups you consider “most valuable” for whatever reason. Then, reach out directly. Explain why their feedback matters to you. And, tell them how it will help you make the product better for them.

Personalize these messages based on everything you can, for example:

• If they’ve reached out about bugs or errors before, ask them if there are any other ones they’ve noticed
• Ask how their experience has been since you fixed something for them
• If they’ve asked for certain features before, ask how those are working for them
• Or, ask if there are any similar features that they’ve been thinking of
• If their business is changing, ask if their product needs will be changing at all

Heavily targeting and personalizing asks for feedback makes customers feel special. It lets them know that their opinion matters in particular. It also lets them know how their feedback will make their experience better.

This gives you the most actionable, useful, and valuable feedback. Why? Because it’s coming from the groups that matter to you most.

Display and praise good feedback

We all like feeling appreciated for the things that we do. This is extra true when we do something we didn’t have to do.

Telling your customers that you appreciate them giving feedback makes them feel good. This will encourage them to keep reaching out when they have something to share.

First of all, make sure you’re genuinely thankful for the feedback you get. This means bad feedback as well as good feedback.

Say thanks (obviously—but a lot of companies don’t do this), and explain why the feedback is valuable:

• “This will help us prioritize our roadmap much better”
• “Knowing your use-case really helps us define how to build out this feature”
• …and so on

Second, consider highlighting customers who are providing valuable feedback. Or, displaying the feedback you get somewhere that others can see.

This could look like:

• Mention them on social media
• Create a “top posts on feedback board” round-up each month
• Build content around real customer feedback

Being grateful and appreciative is a small thing to do on your end, but means a lot to your users. It can help turn them into advocates, and they might even send you referrals.

Getting more feedback isn’t about being pushy

A lot of companies think that getting more feedback is all about sending out more requests for it.

As a result, so many companies send out generic, annoying, cold feedback requests. These are irritating to customers and don’t do much.

Quantity over quality is not the mindset to approach feedback with.

The real goal is to do two things:

• Make customers feel great about giving feedback
• Make it easy for customers to give feedback

Do this, and you’ll make giving feedback enjoyable—rather than a chore.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post How to get customer feedback for your SaaS product first appeared on Canny Blog.

The post How to get customer feedback for your SaaS product appeared first on Canny Blog.

There’s no point in attempting to be good at all of them, regardless of your business or customers. Trying to be jack-of-all-trades of support means less excellence all around.

Plus, unless you have huge customer support teams, you’ll also wear yourself and your team thin.

Multitasking is a great skill to have. However, you shouldn’t have to do it to the point where it’s confusing your users or burning out your team members.

Focusing on only the support channels that make most sense for you and your customers means that you can put your energy into those specific ones.

You’ll be able to provide better, faster, more useful support, and not overwhelm yourself.

Today, we’re going to talk about some things to keep in mind when choosing support channels for your business.

Think about your team and its capabilities

The first thing to consider is your team and what it’s reasonably capable of. There are two options here—either you have a dedicated person for managing support, or not.

Let’s talk about the “not” option first. In small, early stage companies, support is often handled by the founders or other team members as a “side gig”. We do it, too—Sarah and Andrew, our founders, are pretty prominent in our support:

This is fine—and an excellent way to learn about your customers to make more educated business decisions. However, founders have other things to do. Allowing support to take up too much time is dangerous—not to even mention the disruption aspect of it.

In this case, you need to be careful about the amount and type of support channels you provide. This is to make sure it’s not hindering other crucial activities for the company.

Start out with 1-2 easy to manage support channels—ones that are realistic depending on your schedule.

For example, if you spend a lot of time in meetings and can’t jump on support issues as they come in, live chat or phone support aren’t the best option.

Instead, you can pick something where a small delay in response is expected (such as email).

If you do have people working specifically on support, consider these things:

• What kind of previous experience they have—which channels they’re best at and used to. Going with those as a starter means they’ll be more efficient from the get go.
• What they’re comfortable doing—for example, some people are great communicators in text, but hate doing phone calls.
• How much of a workload they have—again, you don’t want to take on so many channels that you lose quality across them.

Regardless of whether you have designated support people or not, availability is always something to think about.

If you have only one person available to do support, doing something that requires 24/7 attention (like phone calls) isn’t an option.

Think about who your customers are

The other crucial part of the equation is who the people that reach out to you are to begin with.

With B2B businesses, this doesn’t even necessarily mean looking at the companies. More importantly, it’s about figuring out the individual people who reach out.

For example, at Canny, most people who reach out to us for support are product managers with pretty technical questions.

This means that our support channels need to be tailored for quick responses and easy troubleshooting.

Different customers also prefer different channels. If you build software for teenagers, they’ll be more likely to reach out through social media. Highly technical software people probably prefer email or live chat.

However, if you want to be sure you’re using the best channels for your customers, consider running a survey.

You can always use logic when determining where you should offer support, but you can never really be 100% sure.

Where your customers contact you now might not necessarily be where they want to contact you.

Think about the kind of product you have

The third piece of the pie in figuring out the best support channels is the product you have.

Think about these questions:

• What kind of questions or issues do people usually have about your product or service?
• What are the main hurdles people run across?
• Is it an extremely complex product, or not really?
• How urgent are your support requests usually?

For example, if your product is something that people need to be up and running at all times, you need a faster method of support than email.

If it’s something less urgent, you can possibly afford to give yourself some time, especially if you can’t be available 24/7.

Some extra tips for support channels

Here are some more general pointers:

Make sure to regularly review your support system

Whichever channels you decide to use now, it shouldn’t be a forever decision. As your business and target customers change, your support needs to change, too.

Chances are that if your customers aren’t happy with the way support is provided, they’ll let you know. It’s still good to have regular reviews of how your support works and how much your channels are being utilized.

This way you can proactively make sure you’re still focusing on the right things.

Regardless of the amount of support channels, make sure you keep track of all of them

There’s nothing worse than support requests falling through the cracks. It makes pretty much every other support effort useless.

Ideally, you’ll have all of your feedback, requests, and reports in one place. This is especially important for teams that have several people dealing with support.

Make sure help is always available with self serve

Regardless of the other options you have available, make sure you always have some kind of self-serve support available.

Whether it’s a knowledge base, a Q and A section, or a help center is up to you.

More than six in 10 U.S. consumers say that their go-to channel for simple inquiries is a digital self-serve tool. Besides being the go-to support channel for a lot of people, it will also take some pressure off of needing to be available at all times.

Link to your self-serve resources from everywhere, just in case you can’t be in touch all the time live.

Don’t overwhelm yourself with too many support channels

It might seem tempting to reach across as many support channels as possible. The more the merrier, right?

The issue is that keeping adequate track of and managing a bunch of channels requires a lot of work. The more you spread yourself thin across a ton of communication channels, the less you’ll be able to really focus on them.

Your customers would rather have quality support that is helpful, than the option to contact you on SnapChat.

Do some thinking about which channels actually make sense for you, your customers, and your product. Sometimes, less is more!

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post How to choose the right support channels for your software product first appeared on Canny Blog.

The post How to choose the right support channels for your software product appeared first on Canny Blog.

A well-done case study:

• Creates trust (recommendations from third parties are always more reliable than what the company itself claims)
• Provides social proof—in a situation where a potential customer isn’t sure what to do, they assume that others around them have more knowledge
• Gives more information about the product—you can’t fit everything onto your features page
• Creates a sense of “I can relate to this”, if the case study is for a company in the same space
• Allows you to target your marketing better towards much narrower customer groups, meaning a much more personalized experience

However, good case studies take time and commitment. You can’t just put together a case study based on any customer, in any format, and at any time.

Here are some tips for effective case studies that you can use for targeting, marketing communications, customer success, search optimization, and more.

Create niche studies for separate target groups

Even if your business has one specific main target group, it still probably has different verticals of customers under it. At the very least, you definitely have various strong use cases for your product.

For example—if your main target group is SMBs, you still have:

• SMBs that do retail
• SMBs that do online sales
• SMBs that do software

…and so on.

The effectiveness of case studies comes largely from the relatability aspect of them.

Imagine doing research for a software solution you need. If you immediately see a case study for another company with a use case nearly identical to yours, you will:

• Get a lot of extra information without having to reach out to the company
• Be immediately assured that the product is suitable for your specific use case

And, on the flip side, if you’re doing research and the available case studies are wildly different from what you need, it might be a red flag for you.

This means that the most effective case studies are the ones that are the most heavily tailored for your most desired target group(s).

There’s no point in doing a case study for edge case customers who you aren’t actively pursuing.

Try to figure out all the different main use cases that exist within your ideal customer target group, and build case studies for all (or most) of them.

This way, you can build the most in-depth rapport with your ideal customers. It’s great ammo for effective success/sales processes, and saves you time on tailoring communication on the spot.

Choose your case study candidates wisely

Besides making sure you have a good range of different case studies, it’s also important to be picky about who the selected ones are.

You obviously value all of your customers. However, some of them are definitely more useful than others when it comes to communicating your value.

After you have picked the target groups you’d like case studies for, make sure you pick customers who:

• Use the product often and have used it recently. This guarantees that they’re up to date with any new features you have, the current design, recent changes, etc. Having an outdated opinion isn’t very useful.
• Have seen solid results from using your product. Oftentimes, the customers who have been most impressed with your product will let you know about it by reaching out. Make a list of these people as soon as you communicate with them, for easy reaching out later.
• Are truly enthusiastic about your product—again, these people usually reach out and express their joy.
• Are at least relatively well-known in their space (if possible).

Whereas most users are efficient at being your customers, they might not be efficient at communicating your product value to the outside world.

Pick and choose the people who are most qualified, excited, able, and constructive, and you’ll be able to create the most informative and valuable case studies.

Focus on value first

Case studies communicate nothing if the only message is “yes, this product is “good””.

It’s important that your case studies focus on the value your product has offered a customer—and therefore can offer to others, too.

For example, Canny’s case studies consist of three parts—challenge, solution, and results.

Here’s what that looks like in the case study for ReadMe, one of our customers:

Challenge

The challenge describes what the company was struggling with before they chose Canny.

Solution

The solution explains how Canny solved the issue they were having before.

Results

The results highlight the real value the customer has seen from using Canny.

The most important thing here is, again, focusing on value. Value is what customers are signing up for and handing their money over to you for.

The more you can emphasize that in your case studies, the better. Ideally, you would be able to show clear ROI with actual numbers—e.g “increased conversions by x”.

It’s a simple principle of social proof—“If another company like mine is getting value from this product, so can I”.

Pay attention to formatting and design

Case studies are an excellent source of information, but they need to be easy to digest.

With the abundance of information already available for any product out there, nobody has time to read through pages of text walls in addition.

Try to format your studies in an easy-to-consume way:

• As with any piece of content, use headings and bulleted lists to break up text
• The three-step solution we mentioned above is a good start for sectioning your proof
• Use as many easy-to-understand visuals as possible

A few additional tips

Since case studies are mostly meant for creating a feeling of recognition, add the company’s “profile” in an easy to spot place.

This way, people browsing the studies will know if they’re in a similar position as the highlighted company, even if they haven’t heard of it before.

Make the most important things stand out for quick browsing. If someone is just glancing over the page, they’ll be drawn to the highlights of the case study.

This includes strong statements, direct quotes that make a point, and any other value “evidence” one-liners straight from the customer.

Add plenty of CTA’s—your case study pages should still be built for conversion.

Give your potential customers easy access to start a trial or use the product if they decide to.

Spend some time and effort on creating impactful case studies

As much as you would like to get some social proof out there ASAP, waiting a little and putting effort into case studies is worth it.

Mediocre studies on not-so-ideal customers aren’t going to be detailed or useful enough, nor provide the proof of value you’re looking for.

Focus on planning for and discussing your target audiences, providing a variety of cases, and optimizing design and copy.

You’ll have proof of value out there for everyone to see, and save some time for yourself and your potential customers.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post How to write effective case studies for your software product first appeared on Canny Blog.

The post How to write effective case studies for your software product appeared first on Canny Blog.

At the very start, you’re probably not getting much feedback to begin with. You’re likely not using a lot of different channels for feedback, either. So, not having a tool isn’t an issue.

We’ve all tracked product feedback in a spreadsheet or a Trello board at some point. However, there comes a time where a simple “solution” like this doesn’t cut it anymore.

Many people assume that the need for a feedback tool comes from growing your business. You either:

• Have more employees and need to sync between them better
• Have more customers and need to organize their feedback better

These are both valid reasons for thinking about switching to a feedback tool. They’re also the most common ones. However, there’s more to it than that.

There are several other situations that can indicate it might be time to start using a specialized tool. Today, we’re going to go over them.

Feedback is getting lost

Users’ feedback slipping between the cracks is one of the most severe indicators of needing a feedback tool.

This issue can have several reasons:

• You don’t have a fixed feedback process in place (you get it, but don’t end up doing anything with it).
• You’re getting more users, but don’t have enough user-facing people to keep up with their feedback.
• You’re using too many external channels that have the ability to receive feedback (social media, surveys, chat, email, etc), and no way to consolidate it all.

…and, it can also be a combination of the above.

It happens so the best of us—sometimes. However, if it’s a recurring event, feedback getting lost is a major problem.

If it’s urgent issues that are getting lost, users won’t get solutions for their problems. They can’t use your product.

If ideas, feature requests, or other feedback is getting lost, users will feel like they’re not being listened to. It’ll make them thing you don’t care about your customers.

Either way, your business, your reputation, and your product are going to suffer.

The unfortunate thing is that a lot of users won’t tell you their messages are getting lost. They’ll just leave, and you’ll never know what was wrong. Losing customers is bad enough, but it also means you can’t improve.

Fortunately, there are still some who do speak up, and these people are usually very upset.

User feedback tools are built for making sure nothing gets lost:

• If it’s a feedback board, the users themselves are responsible for posting on it. This means that it can’t get lost in a single support agent’s inbox.
• Most feedback tools allow integrations with support channels such as Intercom, email, etc. This means that getting feedback into one, consolidated tool is just a matter of a click.

Remember—for every one person who actually complains, there are probably tons who don’t. If you feel like you’re already getting put down for losing feedback, it might be time to start using a feedback tool.

Your support teams have too much on their plate

Customer-facing employees have a lot of responsibilities regardless of how small or big the company is.

• In an early stage company, they have to build and shape the entire user facing strategy.
• In a more established one, they have to move into customer success and retention.
• Either way, they’re always dealing with an expanding user base, and a growing amount of feedback coming in.

Customer-facing teams aren’t just there to answer emails. They have a considerable role to play in keeping your business growing.

Sometimes, we find ourselves in a position where our support people are overwhelmed and burned out. Hiring new ones isn’t always an option because of financial issues.

It might also be too soon to hire a whole other person to help, if the overload isn’t massive.

In the case of the workload being too much, but not enough to hire more help, a specialized feedback tool can help with clearing some of the stuff on the plate.

• Integrations with support channels reduce the amount of manual work needed for gathering feedback in one place.
• Internal discussion features allow communication between team members without having to move out of the original source.
• All feedback being in one place means less time moving information around.
• Segmentation and voting systems can help with prioritization.

Keeping track of feedback in a tool also means more general peace of mind. Instead of trying to remember who asked for what, when, and why, and stressing about it, everything is in the tool whenever you need it.

Communication issues between product teams and customer-facing teams

We’ve talked about the communication problems between these teams before.

Support teams usually operate by gathering more general information, whereas product might need additional context or details.

With more feedback coming in, there’s also more need for context for better prioritization. Discussion and digging into issues is an integral part of an effective feedback cycle.

Very basic systems are often not enough for effective communication between the teams. There’s no place for additional discussion, comments, questions, or context.

If product needs more information, support needs to go back to their own source, have a conversation with the user, and then go back to product.

It’s endless back-and-forth, that can easily be eliminated or reduced by a feedback tool.

Product feedback tools put all the user feedback in one place, and also allow several people from a company to collaborate on it.

Software like Canny acts as the glue between product and support, allowing them to work on problem-solving and context together.

Product teams can go in and see the feedback for themselves, and engage in discussions with the users to create context for their work.

You want to be more transparent externally

You don’t have to open up your feedback tool for everyone to see. It’s okay to use it privately.

Dealing with feedback only internally is the safe and comfortable thing to do. However, there are some benefits to making it public.

Show people that you’re constantly iterating

We all assume that companies are working on making their product better all the time.

However, seeing that a business is trying to constantly improve creates much more trust for potential customers. Many feedback tools have a way of showing your roadmap as well as finished features.

This could be the differentiator between you and a competitor.

Show people that you’re taking feedback seriously

We usually only see how a company reacts to our feedback. However, if we haven’t given feedback yet, we have basically no way of knowing how a company deals with it.

With a public board, we can take a peek into any company’s feedback, and see what they’re doing with it.

Additionally, we’ve all sent feedback and seen it disappear into the oblivion, followed by something like this:

Clearly automated messages don’t feel very personal or reassuring. Did anyone get it? When will a real person see it? When will I receive a reply? Will I even get a real response at all?

With a feedback tool, we can constantly keep an eye on new feedback coming in. We can actively engage in a discussion with our users.

They can see that their feedback is still there, and not laying at the bottom of someone’s inbox somewhere.

If you actively engage with your users in your feedback tool, have discussions, and offer solutions, it’ll impress people who aren’t even your customers yet.

You want to communicate to your users more

So, you’re getting feedback, but you don’t feel like you’re engaging with your users enough. Similarly, you can feel that they’re not engaging with you enough.

Giving feedback via “traditional” means is usually a one-time, short interaction.

This interaction also usually happens between the user and just one of the team members, usually a support agent.

Feedback tools allow way more room for actual conversations with more members of the company.

It also encourages users who usually don’t give feedback to do so. If they see others doing it, and the company actively engaging with them and trying to solve their issues, they’ll want to get in on the action.

This means you’ll be receiving more feedback than you would if you only interacted with each user privately.

It’s also a great way for people who don’t have the time or energy to submit their own separate feedback.

They can just go and chime in quickly with someone else who has already described a problem, idea, or anything else they’ve had.

A feedback tool essentially makes giving feedback easier. Most people don’t have time to spend on sending complicated, detailed messages about everything they’re thinking.

With that process simplified, you’ll get much more insight into what more of your users need.

Streamline your process with a feedback tool

Do feedback tools cost money? Yes. Do they also make your life a lot easier? Also yes.

Feedback tools are meant to benefit both you and your user.

For you, they help reduce the amount of feedback lost and encourage communication between team members. They make prioritization easier, and organize feedback in an effective way.

For your users, it reduces the effort they have to make to give feedback or chime in.

You might be in a phase of your business where you don’t need a feedback tool yet. However, getting your feedback cycle in order is a good thing to do sooner rather than later.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post How to know if you need a customer feedback tool first appeared on Canny Blog.

The post How to know if you need a customer feedback tool appeared first on Canny Blog.

These professions stand on two opposite sides of the moon. One is the maker, and one is the messenger. The issue is both sides not seeing the other one.

Support people are (usually) not technical. They don’t fully understand how much work goes into building a product.

Product people (usually) don’t have as much contact with users. They don’t fully understand how much work goes into communicating with (potential) customers.

These departments don’t have enough touchpoints to facilitate effective cooperation.

There’s also the issue of “demands and denials”. Product teams can feel like all support teams do is “demand” things. Support people can feel like product teams always “push back” on their requests.

Neither of them understand why.

The good news is there is no “natural” feud between product and support people. It all comes down to encouraging communication and, more importantly, understanding.

Here are some tips on how to reduce friction between product and support.

Create respect for the other’s challenges

Like we said before, product and support are drastically different professions. This makes the main issue in their co-existence simply not knowing about the challenges the “other side” faces.

Even if they know (or think they know), they don’t experience it first hand. If they don’t know about it and don’t experience it, they can’t appreciate the effort.

Empathy is a crucial pillar of any kind of healthy communication between very different people (and in this case, professions).

Empathy only shows up along with really understanding. Truly understanding only comes with experience.

Improving communication starts with giving each team the experience they don’t have.

Encourage opposite days

• Ask product people to sit in on a few customer calls or demos (if they haven’t already). Even better—ask them to take a bit of time regularly to take over customer support.
• Ask support people to sit in on a product meeting, preferably a roadmap prioritization one. Even better—give them an exercise of trying to prioritize the roadmap themselves.

This allows both parties to witness, first-hand, the truly challenging parts of each other’s jobs.

And, most importantly—after giving both sides a taste of the “dark side of the moon”, encourage discussion about it:

• What did both sides feel when they had to do the others’ work?
• What did they struggle with most?
• What did they learn?
• Do they have any feedback or thoughts about the process to make it better?

As humans, we tend to focus on our own struggles first and foremost. The more different than us the person we’re dealing with is, the harder it is to appreciate their effort.

Dipping a finger into the work the other side does on a daily basis is a great start for establishing mutual respect.

Establish a “why?” culture on both sides

One of the main issues that causes friction between product and support is the “demands and denials” aspect.

Product feels like something is constantly being “demanded” by support teams (a feature, a fix, whatever). Support feels like product is constantly pushing back on their “demands”.

Both being “demanded” something from and constantly being “denied” are negative feelings. This often reaches a personal level of resentment.

Drastically improving communication can be accomplished by establishing the “why?” rule. Basically—both sides are allowed to ask “why?” on both occasions—no judgement involved.

Digging into the real, objective reasons behind any ask is a crucial part of a well-oiled product development process:

Product needs context behind a request to understand why it should be done.

There’s a lot of prioritization involved in the product team’s work. If they don’t have a good “why?” (“why does this customer want this”), it comes across as just an “unreasonable” demand.

They would have to go to their team and ask them to build something “just because”. This makes their job harder. Result = product is pissed.

Same with support—if product pushes back on something, they can ask “why?” for context.

If there’s no reasonable “why?” (“why we can’t do this right now”), it comes across as if product just doesn’t care.

They would have to go back to a customer and tell them they can’t have something “just because”. This makes their job harder. Result = support is pissed.

If there is neutral “why?” included in both sides of the communication, both teams will have rational context. It will provide a smooth reasoning behind their tasks, and it will be easier to not take it personally.

Think through your feature request process

Whether you track your feature requests and other issues in Trello, Canny, or somewhere else, it’s important to think through the structure of the process.

Feature request/bug report/other feedback boards can easily become a “dumping ground”.

It’s not only one team’s responsibility to deal with organizing this mess.

It should be a collaborative effort:

• Support can help prioritize and organize by adding information about which features or other items are more important based on information available to them
• Product can add context about how much effort is required for these items, and when it’d be realistic to be done
• Both teams should be responsible when it comes to avoiding duplicates, not enough information, baseless requests, etc

This consolidated source of action items should be gone over regularly by both teams together.

Again—the main issue with friction between support and product lies in lack of context.

Encourage communication on the same things, while both support and product provide relevant context. The level of understanding will be much higher on both sides.

PS: if you don’t track issues, requests, or fixes in one specific place at all, it’s time to start. Lost issues, questions, and requests getting lost or being forgotten about creates even more tension.

Something like a Canny board is a great place for product and support to collaborate without losing track of information.

Make sure you have one place where everyone can add things and go over them together. A random Slack conversation can and will be forgotten.

Improving communication is about increasing understanding

Product and support are two very different parts of a company.

These jobs require different personalities, skills, and knowledge. However, they also have to communicate with each other often.

They depend on each other for aspects of their jobs either going smoothly, or not going at all. This can cause a lot of tension and resentment.

Cultivating respect, creating context, and encouraging information swaps is key in successfully improving communication between the two.

Elen Veenpere

Marketer at Canny. Elen enjoys drinking unnecessary amounts of coffee, typing words, and filling out marketing spreadsheets.

All Posts

The post Improving communication between product and support first appeared on Canny Blog.

The post Improving communication between product and support appeared first on Canny Blog.