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.

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.

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.

You’ve worked hard, and you’re finally ready to put it all out there.

Now comes the hard part. We tend to assume that everything new will take off with a big bang because, well, it’s new. And exciting? Right?

The truth is that even though you’re excited about something, it doesn’t mean anyone else is.

For a small set of customers who have been praying for specific features or product updates for a while, it is indeed great news. Others…well, others aren’t going to know about it until you tell them.

And even then, they might not necessarily care.

Why should your customers care about product updates?

Announcing new things is something of an art. It’s one you should take some time to plan for.

Well-thought-through product announcements will help increase feature awareness and engage users with new functionality. Just like sharing your public roadmap, it’s also a great way to let potential customers see that you’re constantly improving.

Here are a few things to keep in mind when announcing new features or updates.

Plan ahead and set goals

“Winging it” is the worst thing you can do when it comes to announcing product updates.

Not having clear goals for your announcement and just “throwing it out there” is not going to get you anywhere.

There are three things you need to think about long before you announce anything new:

1. Who’s your target audience?
2. What are your goals with the announcement?
3. Which channels should you use?

Let’s go through these.

1. Who’s your target audience?

As always, your target audience is never “everyone.”

Yes, in an ideal world, everyone would instantly jump on board with your new functionality.

The reality is that there are definitely groups of users you need to talk to first, like: 

1. People who have asked for this new thing you have specifically
2. People who are actively using something that has been changed, and will be affected

Start with them, and then you can focus on everyone else.

Grouping your target audience into segments is important for building the correct messaging:

• Someone who’s asked for a change in a feature will be excited about it.
• Someone who has not, might be annoyed that it’s changing. This means that your tone and content needs to be different when talking to these groups.

Here are messaging examples for both of these situations:

1. You asked for it—and we did it! User segmentation is now available for everyone on all Canny plans. Yay! Check out this blog post on how to use it.
2. We recently rolled out a new feature on all Canny plans—user segmentation. To make sure you’re familiar with the changes, we’ve written a blog post walking you through the new user segmentation functionality.

You’ll also want to make sure every target group gets the information that is most important to them. You might want to highlight different features, or aspects of a feature or update to different users.

2. What are your goals with the announcement?

Like any marketing activity, product announcements should have clear goals.

Think through what it is that you’re trying to achieve:

• Are you trying to get more people to use a new feature?
• Are you trying to get people to upgrade because of a new feature that’s available?
• Are you trying to make sure everyone is aware of a drastic change?
• Are you trying to bring in new customers?

Once you figure out what it is that you’re really trying to do, planning for it will become easier.

You’ll be able to make sure you’re not wasting time on unnecessary tasks, and focusing on which activities really benefit your goal.

For example:

• If you’re trying to get more people to use a feature, you’ll probably want to focus on in-product announcements and tours that they can take once the feature has rolled out.
• If you’re trying to make sure everyone is aware of a drastic change, you’ll want to plan for communication before the product update even happens.
• If you’re trying to bring in new customers, you’ll be paying more attention to external communication.

…and so on.

You can have several goals at the same time. The important part is still that you know what you’re trying to achieve.

Having a measurable goal will also help assessing the success of an announcement, and doing better in the future.

3. Which channels should you use?

There are a bunch of different communication channels you can use for product updates:

• Email
• Social media
• In-app notifications
• Blog posts
• Webinars

Picking the channels for announcements depends on the target audience thinking you did before. It also depends on what it is that you’re announcing.

If it’s a software or design update, does it really matter that the outside world knows about it? If not, maybe just use email and in-app notifications.

If it’s a new feature that might bring in new customers, you might want to use social media and blog posts, too.

Prioritize information in your product announcements

A mistake many companies make is making the announcement about them, not the customer.

We’ve all seen blog and social media posts that start with “we’ve spent this and that long on this new thing.”

Often, the announcement focuses on much hard work it’s been, and what went into it.

Here’s the thing: Nobody cares.

Nobody cares about how many extra hours you had to put in for this new feature. Nobody cares how long it took you to build this update. Improving and adding on a product is your job.

Users don’t want to know about you, they want to know about them. They want to know how this new thing is going to move their bottom line, or change the way they work with your product.

Here’s a good information framework to use for an announcement:

• What is it
• Why it’s good for the customer
• How to use it
• Extra information or sources for further reading if needed

Here’s a chunk of our segmentation feature announcement:

• What is it? User segmentation.
• Why is it good? Your feedback might be getting diluted, and now you can un-dilute it by segmenting by user.
• How it works? Included in the announcement.

Leave your life story out of it. People’s attention span is short. It’s tempting to tell your life story, but filter out the important stuff.

Focus on the customer and how this affects them, not yourself.

(You can also see more of how we announce product updates in the Canny Changelog.)

Don’t annoy people

There are tons of channels you can use to announce product updates.

You can use all of them if you want—but make sure you keep communication frequency on an acceptable level for one customer.

Not every one of your users is watching all of your channels, so you do need to make sure they get the memo. However, there’s a fine line between making sure someone hears about it, and bombarding them with it.

If someone is already getting an email and an in-app notification, don’t send a pop-up when they log in.

Always give people a way to opt-out of an announcement.

If they don’t want to see a tour of the new feature or sign up for the webinar, let them close the window and leave them alone.

Add good visuals to your product updates

Few people want to read through a bunch of text to learn about a new feature or a product update.

Visuals are a great way to catch people’s attention. They’re also good for explaining a functionality better than words can.

Visuals you can add in your announcement include:

• Video
• GIFs
• Screenshots

A great video can help you stand out and grab the attention of your audience.

Here’s our video about Changelog, our latest big feature to help with announcing product updates. Very meta, we know. You can read more about how a changelog can help with product updates in this article, too.

Videos have powerful storytelling abilities and can be a lot more engaging than other types of content.

Not sure you can make your own product video? You can actually create video content with limited budget and time.

To make product updates effective, pay attention to your targeting and how you communicate

Product announcements aren’t something to just “do” without previous planning.

New functionality without proper announcement is a wasted opportunity. Your team has worked too hard to not give your new features the attention they deserve.

Make sure you put proper thought into why, to whom, and for what reason you’re announcing something. You’ll be able to pinpoint your target audience, and communicate with them in the most efficient way for them.

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 announce product updates and features first appeared on Canny Blog.

The post How to announce product updates and features 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.

You have a vision for what you’ve built, and ideas about how to get there. You also have customers who you value a lot. These customers often come with an overwhelming amount of opinions, requests, and demands.

You don’t have the resources, time, or desire to build everything—and you never will.

So, how do you decide what gets built or changed? And, what should you focus on first? How do you determine what feedback and requests are the highest priority?

The 7 steps of product roadmap planning

The general product roadmap planning process for organizing and prioritizing product feedback looks like this:

1. Gathering product feedback
2. Learning the “why” behind feedback
3. Separating bug reports and feature requests
4. Organizing and prioritizing bug reports
5. Organizing and prioritizing feature requests
6. Prioritizing all final lists
7. Assembling your product roadmap

When you’re initially building your product roadmap, deciding on anything can seem daunting.

This process helps you leave aside biases, gut feelings, and unreasonable requests. You’ll be able to focus on what really matters.

The roadmap prioritization process can be different across industry and company types.

What we’ve described here is a very basic, generic process that you can mold for edge cases if you need to.

Let’s get started!

Using a dedicated product roadmapping tool like Canny makes prioriziation much easier. 

1. Gathering product feedback

The two types of product feedback you should round up for this process are:

• Feedback from your existing customers
• Feedback from potential and previous customers

Let’s go more into detail with both of these groups.

Gathering existing customer feedback

If you’ve already been stashing away product feedback and requests somewhere, it’s time to dig them out.

If you haven’t been gathering feedback yet, it’s OK. You have an extra step to take, but it’ll be worth it.

Go ahead and get into your:

• Emails
• Social media
• Survey results (if you’ve done them)
• Support tickets
• Any other channels you have that could contain product feedback

Product feedback means:

• Bug reports (both from yourself and your customers)
• Any other issues customers have communicated (e.g a confusing onboarding flow)
• Feature requests or recommendations

To start out, you can throw these things into a Google Doc, a spreadsheet, or even on a piece of paper. At this stage it doesn’t matter, as long as you have a good overview of everything.

Gathering feedback from potential and past customers

Your existing customers are a priority. But, reaching outside that zone can be incredibly informative.

If someone already uses your product, they have decided that it’s doing a decent enough job for them. This isn’t always true—but it’s true more often than not.

Think about breaking the barrier for people who want to or would use your product, but can’t in its current state. It’s a very simple principle of potential business growth, and a great discovery exercise.

Reach out to:

• Members of your target group who are using a competitor’s product
• Members of your target group who don’t use a product like yours at all
• People or companies who started a trial, but never converted
• People or companies who churned soon after converting

Finding out why they’re not your customers can add a completely different perspective, and supplement your roadmap with ideas and opportunities you weren’t even aware of.

Our article on how to gather feedback for your SaaS product offers a more in-depth overview of the process. And, here’s a case for why you should be collecting customer feedback in the first place.

2. Learning the “why” behind feedback

You’ve gathered your product feedback. That’s a great start.

But, try to be very careful about how seriously you take every piece of feedback.

Not all feedback is equal. With limited time, resources, and skills, you need to learn to challenge every piece.

If you take every request or complaint at face value, prioritization for your product roadmap becomes impossible.

The solution for this is everyone in your team getting into a habit of asking “why?”

(Note: we’re talking about feature requests and general issues, not bug reports.)

The “why” isn’t meant to be naggy, demanding, or whiny. It helps you (and your customers) understand what they’re really trying to do.

Here’s an example of a lovely, calm, helpful “why?”:

• Very important customer: We want you to add the reports button in the main menu instead of it being in the dropdown. It’s very important.
• You: Thanks for the feedback! Do you mind if we ask how that would help you, or what the issue is with the current location? We want to understand our customers’ requests as well as possible, so we can focus on the right things.
• Very important customer: Kyle from accounting keeps forgetting where it is.

Learning moment: This company doesn’t have a real problem (Kyle might disagree). They have a minor issue that can easily be fixed by:

• Adding a step in your knowledge base about getting to the reports view
• Changing some wording in the product for better understanding of navigation
• Sending Kyle a post-it note with the location of the reports page that he can stick to his monitor

Imagine just putting that button on the dashboard without asking why. Hundreds of people would be contacting you because now they can’t find the reports button.

Kyle would be happy. But at what cost?

Tl;dr: Asking “why?” will help you understand the real value of every request. Prioritization becomes much easier.

It’s OK if you haven’t done this extra asking yet. If you need more context right now, reach out and ask. It’s very unlikely anyone will mind.

In the future, try to ask as soon as anything comes in.

3. Separating bugs and feature requests

It’s time to get into the fun stuff!

The first step is to separate your pile of product feedback into two large buckets:

1. Bug reports (and everything else that is broken in your existing product)
2. Feature requests, recommendations, and other “additions”

As for the tool to use for this: Use a spreadsheet. You’ll need a few (easy!) formulas later on.

4. Organizing and prioritizing bug reports

The first bucket to tackle is your bugs and bug reports.

Note: Some bugs are obviously critical. If your entire product is down, you need to deal with it now. What we’re talking about here are issues that are an inconvenience, but not deadly.

Step 1: Organize

The first thing you’ll want to do is group similar bugs together. A few people have probably reported the same thing. These things might also align with the stuff you’re already aware of.

Pull all similar bugs into one list—and add who reported it under it. You should end up with something like this:

Now, instead of a giant list of overlapping things, you’ll have a list of unique issues, all separated.

Step 2: Prioritize

For each bug and who’s reporting it, consider these things:

• Is it a paying customer? (On a scale of yes = 2, and no = 1)
• How important is the fix for them/their retention (A.K.A., how mad are they at you)? (On a scale of 1 to 3, with 3 being very, very mad)
• How many people or companies reported the bug? (Just the number)
• Where do you place the fix on your importance level (On a scale of 1 to 3, with 3 being very important)

Then, add up the “scores” to get a “total score”:

Once you’ve calculated a “score” for every bug, create a conclusive list of them, ordered by the “total score” of each bug:

You’re doing great! Set that list aside for now. We’ll move on to feature requests.

5. Organizing and prioritizing feature requests

This is where it really gets exciting when it comes to product roadmap planning. You’ll get a good overview of all the new features you could be building soon.

Step 1: Organize

Group similar feature requests or recommendations together, and add who asked for them.

You’ll end up with this:

Also similarly to your bugs, you’ll end up with a few of these lists, depending on how many “groups” of requests you have.

Don’t forget to add the “outside” requests from your potential or churned customers.

Step 2: Prioritize

For each request and who’s asking, consider these things:

• Is it a paying customer?
  • (On a scale of yes = 2, and no = 1)
• How important is the feature for them/their retention/happiness?
  • (On a scale of 1 to 3, with 3 being very important)
• How many people or companies asked for the feature?
  • (Just the number)
• How much do you agree with the request, and/or think it’s necessary
  • (On a scale of 1 to 3, with 3 being strongly agreed)

On your “agreement,” think about these questions before giving your score:

• Will it give you a business advantage of any kind (e.g separate you from competition)?
• Is it something that you’ve considered doing before anyway?
• How does it align with your vision of the product?

Then, add up the “scores” to get a “total score.” It’ll look something like this:

Once you’ve calculated a total score for every feature request, pull them into a conclusive list:

There you go! You started with a messy list of bug reports, complaints, requests, and recommendations.

Now, you have everything organized in a clear, visual overview.

You’ve done a giant amount of work. Now, it’s time to get into consolidating it.

6. Prioritizing all final lists

There are many methods for organizing your lists into concrete to-do’s and not-to-do’s.

We’re going to use two different methods for making your final decisions:

1. A simple cost/value matrix
2. The MoSCoW method

Firstly, let’s get into the evaluation of cost versus value.

When we say “cost,” you can think about it either in the financial sense, or you can consider “cost” to be “effort.” Use whichever definition makes more sense for your business.

Cost/value matrix:

It’s pretty simple. You take into account both the value and cost/effort of a task, and place it in the matrix.

You already know what the “value” is, based on the “scores” you calculated for each item earlier. To know which score is “high” or “low” on the value scale, just take the highest and lowest “total scores” from your list.

Now, you need to figure out the cost—or effort:

• How much time would it take you to do this?
• What resources would it take you to do this?
• Would you need extra resources or time to get this done?

Start placing your feature requests and issues into the matrix.

For example:

• Feature request: Adding photos to customer profiles
• Value: Very high, total score 26
• Cost: Low, Jim could do this in a week because he’s a badass, and has no other outstanding tasks
• Placement: high priority

Once you’ve placed all your tasks on the cost/value matrix, it’s time to get into a little bit of MoSCoW.

The MoSCoW method

The MoSCoW method divides your tasks into four buckets—must have/do, should have/do, could have/do, and won’t have/do.

You don’t have to use the MoSCoW lists if you’ve already filled out your prioritization matrix. But, it does help you re-organize your tasks into lists instead of a visual matrix. This makes placement into an actual product roadmap later on a little bit easier.

This step is easy. Take priorities 1, 2, 3, and 4 from your matrix, and divide them into the four MoSCoW columns.

Like this:

And there you go! You have an organized and prioritized list to start placing in your product roadmap.

It’s good to keep this list handy—even the items that you’ve decided not to deal with now. Who knows—in the future, maybe your “won’t do” items will become relevant again!

7. Building your roadmap

You made it! Now you can start placing your prioritized list of activities into your product roadmap.

Product roadmaps are exciting. You could even make it public to keep your (potential) customers, stakeholders, and fans in the loop (and here’s why you shouldn’t worry about having a public roadmap).

We suggest using a tool like Canny to build your roadmap. With Canny, you can collect feedback from users, and build your roadmap from those feature requests. You’ll also be able to easily keep everyone informed (from customers to internal team members).

Good luck!

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 planning: How to prioritize your roadmap first appeared on Canny Blog.

The post Product roadmap planning: How to prioritize your roadmap 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.

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.